Cookie-based SQL injection

Did you say a "cookie" ?

A cookie, also known as an HTTP cookie, web cookie, or browser cookie, is used for an origin website to send state information to a user's browser and for the browser to return the state information to the origin site. The state information can be used for authentication, identification of a user session, user's preferences, shopping cart contents, or anything else that can be accomplished through storing text data.

Cookies are not software. They cannot be programmed, cannot carry viruses, and cannot install malware on the host computer. However, they can be used by spyware to track user's browsing activities – a major privacy concern that prompted European and US law makers to take action. Cookies could also be stolen by hackers to gain access to a victim's web account.

Where can I find my cookies?

Here is one way to get your stored cookies using your browser. This method is applied for Mozilla FireFox:

1. From the Tools menu, select Options. If the menu bar is hidden, press Alt to make it visible.
2. At the top of the window that appears, click Privacy.
3. To modify settings, from the drop-down menu under "History", select Use custom settings for history. Then enable or disable the settings by checking or unchecking the boxes next to each setting:

To remove all cookies, from the Tools menu, select Clear recent history... . Check the items you want to clear, and then click Clear Now.

Are you talking about a cookie poisoning-like attack?

Cookie Poisoning attacks involve the modification of the contents of a cookie (personal information stored in a Web user's computer) in order to bypass security mechanisms. Using cookie poisoning attacks, attackers can gain unauthorized information about another user and steal their identity.

Cookie poisoning is a known technique mainly for achieving impersonation and breach of privacy through manipulation of session cookies, which maintain the identity of the client. By forging these cookies, an attacker can impersonate a valid client, and thus gain information and perform actions on behalf of the victim. The ability to forge such session cookies (or more generally, session tokens) stems from the fact that the tokens are not generated in a secure way.

To sum up, cookie-based SQL Injection is far to be a kind of Cookie Poisoning.

Cookie variables as a vector of SQL Injections

SQL injection overview

A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.

All data sent by the browser to a Web application, if used in a SQL query, can be manipulated in order to inject SQL code: GET and POST parameters, cookies and other HTTP headers. Some of these values can be found in the environment variables. The GET and POST parameters are typically entered into HTML forms, they can contain hidden fields, i.e. information that is in form but not shown. GET parameters are contained in the URL and POST parameters are passed as HTTP content. Nowadays, and with the growth of Web 2.0 technologies, the GET and POST requests can also be generated by JavaScript.

Injecting malicious code in cookie

Unlike other parameters, cookies are not supposed to be handled by users. Outside of session cookies which are (usually) random, cookies may contain data in clear or encoded in hexadecimal, base64, hashes (MD5, SHA1), serialized information. If we can determine the encoding used, we will attempt to inject SQL commands.

function is_user($user) {

global $prefix, $db, $user_prefix;

if(!is_array($user)) {

$user = base64_decode($user);

$user = explode(":", $user);

$uid = "$user[0]";

$pwd = "$user[2]";

} else {

$uid = "$user[0]";

$pwd = "$user[2]";

}

if ($uid != "" AND $pwd != "") {

$sql = "SELECT user_password FROM ".$user_prefix."_users WHERE user_id='$uid'";

$result = $db->sql_query($sql);

$row = $db->sql_fetchrow($result);

$pass = $row[user_password];

if($pass == $pwd && $pass != "") {

return 1;

}

}

return 0;

}

The cookie contains base64 encoded form identifier, a field that is unknown and a password. If we use as a cookie 12345 'UNION SELECT' mypass ':: mypass base64 encoded, the SQL query becomes:

SELECT user_password FROM nk_users WHERE user_id='12345' UNION SELECT 'mypass'

This query returns the password mypass, the same password as we have to provide. So we are connected.

How to inject the code in Cookies?

There are many HTTP interceptors and HTTP editors that can intercept the HTTP request before it is sent to the server. Then the tester can introduce his malicious SQL statement in the cookie field.

It's like a get/post based SQL Injection, except that certain characters can't be used. For example, ';' and ',' are typically treated as delimiters, so they end the injection if they aren't URL-encoded.

Limitations of web application vulnerability scanners

Web application vulnerability scanners are not always capable of detecting all of the vulnerabilities and attack vectors that exist. In consequence, they may assert numerous false-negatives and false-positives. These were some of the results of a study named: "Closing the Gap: Analyzing the Limitations of Web Application Vulnerability Scanners" hold during the OWASP APPSEC DC 2010. The tests were based on many professional scanners: Burp suite professional, Acunetix, Wapiti, Grendel-Scan, W3af, N-Stalker, CENZIC, netsparker.

As far as cookie variable's injection is concerned, only 6,3% of the web application Vulnerability scanners had detected the implemented SQL injection vulnerabilities.

This rate looks like emphasize that the cookie vector is neglected when testing against SQL injections. Also, it's very low comparing to percentage of the detection of SQL injection in Form Inputs (59,7%).

Conclusion

Cookie variables sometimes are not properly sanitized before being used in SQL query. This can be used to bypass authentication or make any SQL query by injecting arbitrary SQL code. For the web application audits, cookie variables should be added to the list of parameters to be checked.

Sources

• Http cookie
• Ajfi html
• Cookie poisoning 
• [Amit Klein ] Hacking Web Applications Using Cookie Poisoning, 2002 Sanctum, Inc.
• SQL injection