Friday, September 25, 2015

Web Application Penetration Testing for Cookie-based SQL Injection

Web Application Penetration Testing for Cookie-based SQL Injection

Web Application Penetration testing has become popular these days and Cookie-based SQL Injection is a rare and very dangerous attack that the penetration testers often tend to miss out during the penetration testing .
Before we begin the tutorial it will be a good idea to understand what cookies are and why do the web applications have a high dependency on them .

Understanding Cookies 

Cookies are essential to maintain the state of user browser over a stateless protocol such as HTTP . The Primary functions of Cookie is :
  • session authorization
  • authentication token
  • or act as a temporary data container.
  • cookies are set to maintain state across multiple requests as HTTP itself as HTTP is Stateless Protocol . 
Thus, if an attacker were able to acquire a session token by attacks such as cross site scripting  or by sniffing an unencrypted session, then they could use this cookie to hijack a valid session.
Additionally, cookies are set to maintain state across multiple requests. Since HTTP is stateless, the server cannot determine if a request it receives is part of a current session or the start of a new session without some type of identifier. This identifier is very commonly a cookie although other methods are also possible.
Hence due to the sensitive nature of information in cookies, they are typically encoded or encrypted in an attempt to protect the information they contain.

Cookies For Penetration Testers

Cookies are an important feature of Web Applications and penetration testers must have a good understanding of Cookies from Security Point Of View . Once the tester has an understanding of how cookies are set, when they are set, what they are used for, why they are used, and their importance, the penetration tester must know how to test if they are secure. Here is a list of Attributes that can be set for Cookies :
  • secure – This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.
  • HttpOnly – This attribute is used to help prevent attacks such as cross-site scripting, since it does not allow the cookie to be accessed via a client side script such as JavaScript. Note that not all browsers support this functionality.
  • domain – This attribute is used to compare against the domain of the server in which the URL is being requested. If the domain matches or if it is a sub-domain, then the path attribute will be checked next.

SQL Injection 

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.
For More in depth tutorial on SQL Injection Attack please refer to the following Posts : 
  1. Web Application Penetration Testing SQL Injection Basics
  2. Web Application Penetration Testing Manual SQL Injection
  3. Web application Penetration Testing SQL Injection with SQLMAP

Cookie Based Sql Injection by Injecting malicious code in cookie

Getting further in depth for actually exploiting the Cookie Based SQL Injection for web application penetration testing , unlike other parameters used for SQL injection , cookies are not supposed to be handled by users. Outside of session cookies which are  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;
 }
From the above example of the cookie we can deduce that :
  • cookie contains base64 encoded form identifier
  • a field that is unknown
  • 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.

Injecting The Code Into 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.
Prevention : Cookie variables must be  properly sanitized before being used in SQL query.
This attack 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.
Posted by at