I have a created a simple CGI script running on a web server where a user can login using a username and password. The username and password are entered via a html form and the form POST's the data to the web server.

I log the logins and this is what I have found happened repeatedly - about 10 attempts

For username they are entering:

') declare @q varchar(8000) select @q = 0x57414954464F522044454C4159202730303A30303A313527 exec(@q) --

and for password:


Lots of slight variations. Here is another attempt:

username: John password: 1 declare @q varchar(8000) select @q = 0x57414954464F522044454C4159202730303A30303A313527 exec(@q) --

Is this some sort of SQL command? A stored procedure? What do you think they are trying to achieve?

Are there any tips on measures I should introduce to prevent this sort of thing happening?


3 Answers 3


There seems to be a good answer here and here.

1 declare @q varchar(8000) select @q = 0x57414954464F522044454C4159202730303A30303A313527 exec(@q) --

If we simplyfy the above we can get an idea of what's going on:

declare @q varchar(8000)
select @q = 0x57414954464F522044454C4159202730303A30303A313527
  • Line 1: Declares the q variable as a varchar with 8000 chars.
  • Line 2: Assignes the encoded string to the q variable.
  • Line 3: Executes the q variable.
  • Line 4: Comments out the rest of the injected query.

According to 2 the 0x57414954464F522044454C4159202730303A30303A313527 string is WAITFOR DELAY '00:00:15' hex-encoded. A timed Blind SQL injection attack technique which tells the server to wait 15 seconds before responding. Once the payload is injected, if the server takes 15 seconds to respond, there is a good chance it is vulnerable to SQL Injection. This can be further checked by increasing the DELAY time.


I am by no means an expert, but it seems to be an attempted SQL Injection. They hope that what they enter somehow is executed by your server, resulting in that variables content @q being run if they succeeded. I would guess it is a somehow encoded sql command, that "0x5741...." string. But i would think, someone here could shed much more light on this than i can.

Read up on SQL Injections and check if your code is good enough to be immune. I guess you could also implement a blocking mechanism (for the source IP for some time) if your code sees a certain amount of such attempts.


Welcome to the Internet. Running a public web server on the Internet means you will be attacked. There's really nothing you can do to prevent it. What you can do is try to prevent the attacks from succeeding. That involves secure coding practices, keeping your software up-to-date, and perhaps introducing some security controls.

This particular attack, as others have mentioned, is a blind SQL injection attempt. Try it yourself; if your server waits for 15 seconds before responding, then your CGI script is vulnerable. There are lots of resources out there about preventing SQL injection, so I won't bore you with the details here.

I would definitely recommend using some security controls for your site. You could try preventive controls like mod_security or detective controls like a web log auditing program. I only run a hobby site with one static page, so I have a hobbyist's solution: a custom fail2ban filter for my web log that detects a few common attacks and then throttles the connection to that IP. It's really nothing I'd recommend to a site that had real assets to protect, but it illustrates the point that you can make simple security controls yourself to augment the tried-and-true solutions everyone else is using.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .