52

What methods are available for testing SQL injection vulnerabilities?

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
John S
  • 621
  • 1
  • 6
  • 3

3 Answers3

55

There are a number of ways of testing an application for vulnerabilities such as SQL Injection. The tests break down into three different methodologies:

Blind Injection:

MySQL example:

http://localhost/test.php?id=sleep(30)

If this SQL statement is interpreted by the database then it will take 30 seconds for the page to load.

Error Messages:

http://localhost/test.php?id='"

If error reporting is enabled and this request is vulnerable to sql injection then the following error will be produced:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '"' at line 5

Tautology Based Injection:

http://localhost/test.php?username=' or 1=1 /*&password=1

In this case supplying a Tautology, or a statement that is always true provides a predictable result. In this case the predictable result would be logging in the attacker with the first user in the database, which is commonly the administrator.

There are tools that automate the use of the methods above to detect SQL Injection in a web application. There are free and open source tools such as Wapiti and Skipfish that do this. Sitewatch provides a free service that is a lot better than these open source tools. I can say that because I am a developer for Sitewatch.

Glorfindel
  • 2,235
  • 6
  • 18
  • 30
rook
  • 46,916
  • 10
  • 92
  • 181
  • 1
    Good post, but I get a "this site's identity can't be verified." warning when I try to click on Sitewatch's embedded link. I'm using Firefox. – Sarah Micj Feb 28 '16 at 17:34
  • Isn't there a string which would detect an injection in all the different database variants? – winklerrr Oct 06 '21 at 19:18
13

Its best to not test your site for SQL injection. Its best to just avoid the potential SQL injection. Never forming SQL queries by doing string processing yourself when there's user input. Use bound parameters in all queries (also sanitize all user data if it could be used in any harmful way and put sensible limits on queries). That is the query sql_execute("select user from user_db where id="+input_id) is unsafe (imagine if its input_id = "1 OR 1==1 --"), but stored_procedure = "select user from user_db where id = ? LIMIT 1;", sql_execute_with_param(stored_procedure, input_id); is safe.

Obviously, this is only if you are trying to make your own site safe. If you are trying to find flaws in other applications its another story, and potentially against the FAQ which states this site is not for black hats. But OWASP has a very good article on testing for SQL injection.

dr jimbob
  • 38,768
  • 8
  • 92
  • 161
6

If you're starting from zero I would suggest one of the following:

  1. Hire someone who knows what they're doing
  2. Employ an automated tool as an initial stop-gap. Some options include Burp Pro, ZAP, and SQL Map.

Keep in mind, however, that when you send strange and potentially dangerous input to a web application you have a significant chance of damaging the integrity of your application.

You can outright break your web app, or you can store strange input in the application's database that then gets pulled and parsed later in some way--and maybe even not by your application.

The general rule for this kind of testing is simple: you're not done testing until you've restored from a known-good backup. You should not consider your application in normal operating condition after automated injection testing until after you've done so.

Daniel Miessler
  • 605
  • 4
  • 3