Detecting SQL Injection Vulnerabilities from HTTP Errors

While testing for SQL injection vulnerabilities or attempting to take over a query, the attacker may face different HTTP status codes. Those responses may indicate that the SQL injection partially worked and therefore give precious hints to the tester. This section explains in which cases an HTTP error indicate a test is worth further investigation.

Server Error (HTTP 500)

Instead of providing a wealth of information through a detailed error page, the application may simply return an HTTP 500 Server Error. When this kind of error occur, it is better testing only one parameter at the time. You should also try different techniques to inject the parameter. This way, you will increase your chances to generate a crafted input that gets integrated in the original query without making it invalid. In addition, you should use blind SQL injection in order to extract more information about the system. HTTP 500 Server Errors are habitually pretty straight forward and do not contain details about the error, but with the help of blind SQL injection attacks you could get access to precious information.

Not Found (HTTP 404)

Generally speaking, SQL injections do not generate 404 errors. In fact, 404 and alike (400, 401, 403) are generated because the server could not find the specified resource (web page or file) for diverse reasons. Simply put, the error was thrown before the query was executed. You may face this kind of situation if you think parameters are hidden in script path (because of URL rewriting). For example you may think that the requested URL is rewritten as shown below.

If URL rewriting is not used, trying to craft SQL injection strings in paramA will likely create 404 errors. 

Request Timeout (HTTP 408)

Given you are using time-based blind SQL injection technique; an HTTP 408 error could indicate that you successfully achieved an attack. You might face this situation if you are using a long time delay and the web server hosting the pages you are testing has a short execution timeout.

Resource Found or Moved (HTTP 302 and similar)

The visitor will often be redirected to another page when the application code handles the error. This is a common practice to avoid presenting an error page to the end user and it also helps to get unnoticed since the user is transparently transferred to a valid page.

Tools like web proxy will be necessary to monitor the actual server response when this kind of redirection is used. Below is a simple example of a 302 redirection. Note that 301, 303 and 307 errors have similar results but the server response is a little bit different.

You need to know that this is far from an absolute indicator that the parameter tested is vulnerable. In fact, the application could simply detect that an SQL injection attempt was made and redirect the attacker to a default page without executing any query.

HTTP Error Overriding

You also need to be aware that it is possible for developers to return a custom error message or a custom error code whatever the HTTP error generated by the web server is. In this situation, any error code (500, 404, 400, etc.) could end up returning, for example, an HTTP 302 error redirecting to the homepage.

This technique is used to make the detection of SQL injection more difficult. It is not a common practice but it is possible that you face it while testing different systems.

References

For more information about HTTP errors you can consult the list on Wikipedia or the section dedicated to HTTP status code in the official RFC.