Fixing a Session

In essence, fixing a session is an attack inverse to stealing user cookies. The ability to steal user cookies is based on reading cookies with JavaScript tools; fixing a session is based on writing artificial values into cookies using malicious JavaScript code.

Situations, in which an attacker needs to write certain data into user cookies on a target site, can vary.

For example, suppose that an e-shop on the Internet pays its dealers bonuses for each client order. To distinguish, which dealer drew a particular client, each client is identified with a cookie that stores information about his or her dealer. A malicious dealer could exploit the XSS vulnerability to fix client sessions and reveal the system so that it believes he or she drew those clients .

Consider another example: An attacker can exploit the XSS vulnerability in a forum to fix sessions of the visitors of this forum so that the forum system believes these visitors are one person. All messages left by the visitors will be considered messages left by one person: the registered malicious participant of the forum (or chat or newsgroup).

I could speculate on the reasons for making such an attack; regardless, the attacker can do this. All systems that authenticate users by storing confidential information in user cookies are exposed to a session-fixing attack that uses the XSS vulnerability.

An expected result of such an attack is that all the visitors of a vulnerable page will obtain the rights and privileges of a target user whose authentication data are known to the attacker. The attacker can log into the system on behalf of this user.

To write desired data into a cookie of the target site, the attacker can use the cookie property of the document object. Cookies have a special format. The following functions make it convenient to write data into cookies:

 function fixDate(date) {            var base = new Date (0)            var skew = base.getTime()            if (skew > 0)                    date.setTime(date.getTime() - skew)    }    function setCookie(name, value, expires, path, domain, secure)    {            var curCookie = name + "=" + escape(value) +                    ((expires) ? "; expires=" + expires.toGMTString() : "") +                    ((path) ? "; path=" + path : "") +                    ((domain) ? "; domain=.ulib.org.edu" : "") +                    ((secure) ? "; secure" : "");                    document.cookie  =  curCookie;    } 

The setCookie() function sets cookie parameters to desired values on the current site if the domain value isn't specified.

When domain value is specified, it is possible to set a cookie theoretically on any site. However, many browsers can set cookies only on the current domain.

The fixDate() function is used to correct bugs related to dates in earlier versions of browsers.

If the attacker's browser can set cookies on any site, the attacker doesn't need the XSS vulnerability on the target site. He or she can launch the attack by luring the target user to a malicious HTML page that will set the desired cookie. In this case, the cookie can be set with JavaScript tools or with the header of the HTTP response.

The attack can be launched for either type of XSS vulnerability. For the first type, the malicious user should add a message containing JavaScript code that sets cookies. The message can be sent to all users or, in some cases, to a particular user so that the attack is targeted . For the second type, the attacker would create a malicious URL exploiting the XSS vulnerability. When the target user follows this link, his or her browser will execute some JavaScript code that will set the target cookie.

Consider an example of an attack exploiting the XSS vulnerability of the first type.

Suppose an attacker wants to write the SessionID=123446fd5vr5 parameter into the cookies of all visitors of the http://localhost/5/1.php page. As I demonstrated earlier, the http://localhost/5/1.php page suffers from the XSS vulnerability of the first type.

To implement the attack, the attacker can add the following message:

 <script>    function FixDate(date) {            var b = new Date(0)            var s = b.getTime()            if (s > 0)                    date.setTime(date.getTime() - s)    }    function setCookie(name, value, expires, path, domain, secure)    {            var curCookie  =  name + "=" + escape(value) +                    ((expires) ? "; expires=" + expires. toGMTString() : "") +                    ((path) ? "; path=" + path : "") +                    ((domain) ? "; domain=.ulib.org.edu" : "") +                    ((secure) ? "; secure" : "");                    document.cookie = curCookie;    }    dt=new Date();    FixDate(dt);    dt.setTime(dt.getTime() + 50 * 365 * 24 * 60 * 60 * 1000);    setCookie('SessionID=', 123446fd5vr5, dt, "/");    </script> 

As a result, the desired parameter will be written into the cookies of all visitors of this page.

A session-fixing attack can be launched in a similar way if the XSS vulnerability is based on improper filtration of HTTP GET parameters displayed on the page.

To launch the attack in this case, the attacker would create a malicious link and suggest that the target user follow it.

As in examples described earlier, the attacker can hide the attack from the user by creating a malicious page that would open the URL in an iframe element located in the invisible layer. Improper filtration of HTTP POST parameters also allows an attacker to exploit the XSS vulnerability.



Hacker Web Exploition Uncovered
Hacker Web Exploition Uncovered
ISBN: 1931769494
EAN: N/A
Year: 2005
Pages: 77

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net