Testing Techniques to Find the Sin

There is simply no replacement for a good code review focusing on SQL injection defects. But sometimes you may not have access to the code, or may not be an expert code reader. In these cases, supplement the code review with testing.

First, determine all the entry points into the application used to create SQL queries. Next, create a client test harness that sends partially malformed data to those end points. For example, if the code is a web application and it builds a query from one or more form entries, you should inject random SQL reserved symbols and words into each form entry. The following sample Perl code shows how this can be achieved:

 #!/usr/bin/perl use strict; use HTTP::Request::Common qw(POST GET); use HTTP::Headers; use LWP::UserAgent; srand time; # Pause if error found my $pause = 1; # URL to test my $url = 'http://mywebserver.xyzzy123.com/cgi-bin/post.cgi'; # Max valid HTTP response size my $max_response = 1_000; # Valid cities my @cities = qw(Auckland Seattle London Portland Manchester Redmond Brisbane Ndola); while (1) {  my $city = randomSQL($cities[rand @cities]);  my $zip = randomSQL(10_000 + int(rand 89_999));  print "Trying [$city] and [$zip]\n";  my $ua = LWP::UserAgent->new();  my $req = POST $url,  [ City => $city,  ZipCode => $zip,  ];  # Send request, then get body and look for errors  my $res = $ua->request($req);  $_ = $res->as_string;  die "Host unreachable\n" if /bad hostname/ig;  if ($res->status_line != 200    /error/ig    length($_) > $max_response) {  print "\nPotential SQL Injection error\n";  print;   getc if $pause;  } } # choose a random SQL reserved word, uppercase it 50%  sub randomSQL() {  $_ = shift;  return $_ if (rand > .75);   my @sqlchars = qw(1=1 2>1 "fred"="fre"+"d" or and select union drop update insert into dbo < > = () ' .. -- #);  my $sql = $sqlchars[rand @sqlchars];  $sql = uc($sql) if rand > .5;  return $_ . ' ' . $sql if rand > .9;   return $sql . ' ' . $_ if rand > .9;  return $sql; } 

This code will only find injection errors if the application returns errors. As we say, there really is no replacement for a good code review. Another testing technique is to use the previous Perl code, determine ahead of time what a normal response looks like, and then look for a response that is not normal or not returned in the Perl script.

Third-party tools are also available, such as AppScan from Sanctum (now Watchfire) (www.watchfire.com), WebInspect from SPI Dynamics (www.spidynamics.com), and ScanDo from Kavado (www.kavado.com).

When evaluating tools, we recommend you build a small sample application with known SQL injection defects, and test the tool against your application to see which defects the tool finds.