So today at my job I notified a senior programmer that I found an SQL injection at our website. However, when I make an SQL injection, the page just returns 400, so I can't really see any errors or UNION SELECT some more info etc. That's why I guess a senior developer just said we're too busy to look into this now, and that I need to go back to testing other stuff (I'm a tester). Was he right? Is there no way to exploit an SQL injection that just returns 400?

  • The HTTP status code 400 means “Bad Request”, so your request was probably (syntactically) invalid. However, the programmer could have chosen to send this status code for whatever reason. – Gumbo Nov 9 '15 at 20:01
  • It is typically easier to exploit a SQL injection if you can correlate log entries with your activities. It's pretty hard to get log access in a production situation, but perhaps you can. – Neil Smithline Nov 9 '15 at 21:14
  • 2
    PS: whether or not there's an exploitable vulnerability, you need to take care that you don't violate marching orders from your employer. Being right and fired isn't a good outcome. – Neil Smithline Nov 9 '15 at 21:15
  • What makes your so sure you have found one? I think there needs to be more information added to your question such as which character sequences cause the 400. – SilverlightFox Nov 10 '15 at 10:15

Let's assume this is a valid SQL injection attack, and did actually make it to the database.

The fact that your query didn't return any data is really irrelevant. If you can execute arbitrary SQL, you can likely write to the database. This leads to nasty things like changing passwords, deleting data, dropping tables, etc. SQL Injection is far more than simply getting a web page to display data that isn't there.

Now, returning a 400 error really means nothing. It could mean your SQL injection worked, and the code just didn't know what to do with the database response and returned a 400 error. Or it could mean the injection failed and never got to the database.

If you have permission to write to the database during your test, I'd recommend trying to write a value to a table. Then see if the table was updated. If so, the developer needs to do something rather than brush it aside as this is a very serious vulnerability.


Errors such as 400 (and above) errors are thrown from the web-server side instead of the DB side. So your current query does not actually execute all the way yet. To correct it, you could possibly add linefeed characters such as %0A to the end of your injection test string. If you are on a windows platform you could try %0D%0A. These are HTML linefeed characters to assist with execution. E.g:

  • %0D%0AUnion%0D%0Aselect
  • %0AUnion%0Aselect

A better alternative is to use a SQL testing tool such as the tool from Acunetix or alternatively the tools listed on the OWASP website: https://www.owasp.org/index.php/Testing_for_SQL_Injection_%28OTG-INPVAL-005%29 These tools will be able to test a much larger range of possible injections than you could perform manually.

Glad your company got testers but wish the dev person did not just ignore the error.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.