NetSPI SQL Injection Wiki

SQL Injection Detection

Injections can be detected in a number of ways. The simplest being adding a ' or " after various parameters and getting a database error returned from the web server. The sections below describe where to find and how to detect these parameters.

Parameter Locations

Browse the tabs below to see common injection points in various HTTP requests. Common injection points are highlighted in red

GET - HTTP Request

In a generic HTTP GET request (and most request types) there are a few common injection points. URL parameters, like id in the below request, cookie names and values, the Host header, and any custom headers are most likely. However, any content in an HTTP request can be vulnerable to SQL injection.

GET /?id=homePage HTTP/1.1
Host: www.netspi.com
Connection: close
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Upgrade-Insecure-Requests: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
X-Server-Name: PROD
Cookie: user=harold;

POST - Form Data

In a standard HTTP POST request with a Content-Type of application/x-www-form-urlencoded the injections will be similar to URL parameters in a GET request. They are located below the HTTP headers, but can still be exploited in the same ways.

POST / HTTP/1.1
Host: netspi.com.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 39

username=harold&email=harold@netspi.com

POST - JSON

In a standard HTTP POST request with a Content-Type of application/json the injections will be usually be in the values of a JSON {"key":"value"} pair. The value may be an array or an object as well. Although the notation is different, the values can be injected the same way as all other parameters. (Hint: try ', but make sure the JSON is using double quotes, otherwise you may break the request format.)

POST / HTTP/1.1
Host: netspi.com.com
Content-Type: application/json
Content-Length: 56

{
  "username":"harold",
  "email":"harold@netspi.com"
}

POST - XML

In a standard HTTP POST request with a Content-Type of application/xml the injections will usually be inside an <xmlObject></xmlObject>. Although the notation is different, the values can be injected the same way as all other parameters. (Hint: ')

POST / HTTP/1.1
Host: netspi.com.com
Content-Type: application/xml
Content-Length: 79

<root>
  <username>harold</username>
  <email>harold@netspi.com</email>
</root>

Detecting Injections

Detecting vulnerable parameters is most easily done by triggering errors and boolean logic within the application. Supplying malformed queries will trigger errors and sending valid queries with various boolean logic statements will trigger different responses from the web server.

Note: True or false statements should return different responses through HTTP status codes or HTML contents. If these responses are consistent with the true/false nature of the query, this identifies an injection.

Description	Query
Logic Testing	page.asp?id=1 or 1=1 -- true page.asp?id=1' or 1=1 -- true page.asp?id=1" or 1=1 -- true page.asp?id=1 and 1=2 -- false
Arithmetic	product.asp?id=1/1 -- true product.asp?id=1/0 -- false product.asp?id=1/abs(1) -- true product.asp?id=1/abf(1) -- false
Blind based Note: Detecting blind injection may require identification or guess-and-check of the DBMS to find the proper timing function.	See here
Error based Note: Logic testing and arithmetic with invalid syntax may also help cause errors.	See here