Today we have received a security report from a security company (Qualysguard Consultant) who claim that they have found a sql injection vulnerability in the advanced search. I’ve searched for it but nobody noticed this vulnerability before, and I find it hard to believe this is true. But “safety first” so I wanted to check with you guys, what do you think? Is this true? I will copy the section of their report here:
SQL Injection (1)
150012Blind SQL Injection (1)
150012Blind SQL Injection
Finding # 85808521
Category SQL Injection
OWASP A1 Injection
WASC WASC-19 SQL Injection
First Time Detected 23 Apr 2013 10:04AM GMT
Last Time Detected 23 Apr 2013 10:04AM GMT
Last Time Tested 23 Apr 2013 10:04AM GMT
Times Detected 1
Blind SQL injection is a specialized type of SQL injection that enables an attacker to modify the syntax of a SQL query in order to retrieve, corrupt or
delete data. A successful exploit manipulates query criteria in a manner that affects the query’s logic. The typical causes of this vulnerability are lack
of input validation and insecure construction of the SQL query.
Queries created by concatenating strings with SQL syntax and user-supplied data are prone to this vulnerability. When any part of the string
concatenation can be modified, an attacker has the ability to change the meaning of the query.
Typical detection techniques for SQL injection vulnerabilities use a payload that attempts to produce an error response from the web application.
Detection based on blind SQL injection uses inference based on the differences among the application’s responses to various payloads. Blind SQL
does not rely on error messages, which is beneficial when testing web applications that trap errors.
How It Works:
The WAS scanning engine uses a well known methodology called “True and False” inference to determine if there is a blind SQL injection
vulnerability. Basically, it uses two payloads: one with a “True condition” and another with a “False condition”. If there is a blind SQL injection
vulnerability, the query with the “True condition” payload will cause the web application to return a different response than the “False condition”.
A good example of a “True condition” payload would be ‘ AND 1=1. Since 1 always equals 1, the condition is true. An example of a “False condition”
payload would be ‘ AND 1=2. Since 1 does not equal 2, the condition is false.
For example, let’s say there is a web application with a textbox that searches for customer names and displays the results inside a table. And let’s
assume that if someone searches for John there is one result only. When scanning for the blind SQL injection vulnerability, the WAS scanning
engine uses two payloads:
- True condition payload: This injects the string John’ AND 1=1 to issue the query “return John only if 1=1”. Since 1 always equals 1 the condition is
true. The result is John, which is the same result as using the string John.
- False condition payload: This injects the string John’ AND 1=2 to issue the query “return John only if 1=2”. Since 1 is never equal to 2, the
condition is false. The result is nothing or “No results found”.
With the results from the two payloads, the WAS scanning engine draws the conclusion that there is a blind SQL injection vulnerability. Even though
there is no one called “John’ AND 1=1” in the database the web application displays the information for “John” if a search is done with that query
These few lines demonstrate an insecure query that is created by appending the user-supplied data (name):
On Error Resume Next ‘ Page traps error and do not display it
Set oRSu = oCONv.Execute("SELECT fname, name FROM customers WHERE name = ‘“ & Request("txtSearch") & “‘“)
If oRSu.BOF Or Err.Number <> 0 Then
Response.Write “No results found!”
If no checks are performed against the name parameter, then the query may be arbitrarily modified and sent to the database as shown in these two
examples of a completed query:
SELECT fname, name FROM customers WHERE name=’John’ AND 1=1
SELECT fname, name FROM customers WHERE name= ‘John’; SHUTDOWN WITH NOWAIT
In the first case the database will return “John” since the condition AND 1=1 is always true.
The scope of a SQL injection exploit varies greatly. If any SQL statement can be injected into the query, then the attacker has the equivalent access
of a database administrator. This access could lead to theft of data, malicious corruption of data, or deletion of data.
SQL injection vulnerabilities can be addressed in three areas: input validation, query creation, and database security.
All input received from the web client should be validated for correct content. If a value’s type or content range is known beforehand, then stricter
filters should be applied. For example, an email address should be in a specific format and only contain characters that make it a valid address; or
numeric fields like a USA zip code should be limited to five digit values.
Prepared statements (sometimes referred to as parameterized statements) provide strong protection from SQL injection. Prepared statements are
precompiled SQL queries whose parameters can be modified when the query is executed. Prepared statements enforce the logic of the query and
will fail if the query cannot be compiled correctly. Programming languages that support prepared statements provide specific functions for creating
queries. These functions are more secure than string concatenation for assigning user-supplied data to a query.
Stored procedures are precompiled queries that reside in the database. Like prepared statements, they also enforce separation of query data and
logic. SQL statements that call stored procedures should not be created via string concatenation, otherwise their security benefits are negated.
SQL injection exploits can be mitigated by the use of Access Control Lists or role-based access within the database. For example, a read-only
account would prevent an attacker from modifying data, but would not prevent the user from viewing unauthorized data. Table and row-based
access controls potentially minimize the scope of a compromise, but they do not prevent exploits.
Example of a secure query created with a prepared statement:
PreparedStatement ps = “SELECT name,email FROM users WHERE userid=?”; ps.setInt(1, userid);
Parameter It has been detected by exploiting the parameter q
The payloads section will display a list of tests that show how the param could have been exploited to collect the
Authentication In order to detect this vulnerability, the scan required authentication to be enabled.
Access Path Here is the path followed by the scanner to reach the exploitable URL:
Request GET http://www.STORENAME.nl/catalogsearch/result/?q=1%20AND%20NULL%20IS%20NULL--
#1 Referer: http://www.STORENAME.nl/
#2 Cookie: c_enabled=; c_enabled=true; __utmc=65697405; __utma=65697405.-.-.-.-.1; PHPSESSID=ud9of0obpcfrhjpg0bhib7jnv0; ICO_auth=1;
#3 User-Agent: Mozilla/5.0 AppleWebKit/537.22 Chrome/25.0.1364.97 Safari/537.22 ForusP
Click this link to try to reproduce the vulnerability using above payload.
Note that clicking this link may not lead to visible results, either because the vulnerability requires context to be previously set (authentication, cookies...) or because the exploitation of the
vulnerability does not lead to any visible proof.