Re: Custom session tokens and XSS

I disagree.

> Regarding existing session stealing XSS attacks, there is really no
> difference at all between a hidden form field and a cookie - both are
> equally accessible from within javascript. So if the attacker can induce
> any xss payload on the victim, it doesnt make much difference if you store
> the session token in a cookie or in a hidden form field. They can both be
> read by a javascript and then submitted using any common technique to a
> third location.

This "if" is the whole issue. Of couse, if the attacker can get as far as injecting arbitrary HTML/JavaScript into a user's page **which contains the user's existing session token** then the attacker can capture the token from within the form. But the problem for the attacker lies one step further back.

Take one typical way to exploit XSS vulnerabilities -- feeding the user a crafted URL containing JavaScript within the querystring. With conventional cookies, a user requesting this URL will receive a page containing the attacker's code, whilst remaining within their existing session (because the browser automatically submitted their cookie when they clicked the link). With a session token stored in a hidden form field, on the other hand, this will *not* happen. The user will make a GET request that does not contain any session token. The application will not associate the request with any existing session, and so the user's session token will not appear in the returned page. Sure, the attacker can execute arbitrary code, but the user's token is not there for the taking.

An alternative exploit would be to induce the user's browser to make a POST request (e.g. by sending them a suitable HTML-encoded email). Unless the attacker already knows what the user's token is, he cannot place it within the form data, and it will not be sent in the POST. Again, the application will not associate the request with any existing session, and so the user's token will not appear in the returned page. If the application requires that the POST includes _a_ valid session token, then the attacker can obtain one independently and place it in the form (a la session fixation), and the attacker's token will be submitted. Either way, the page returned by the application, in which the attacker's code will execute, will not contain the user's prior session token.

So some common ways of exploiting XSS don't work here. In *some* applications, it could still be done. In an application which receives user data and makes that data visible to other users, a malicious user could submit a XSS payload to the application (within their own session) which would later be viewed by the victim -- the attacker's code would be executed within the victim's browser in a page also containing the victim's session token, which could then be stolen. But the attack would depend upon this (comparatively rare) functionality within the application. (How many online banks let you post messages to other users? :))

> Bottom line:
> It is equally easy / difficult for an attacker who is able to induce xss
> payload on the victim's browser to steal any existing SID be it stored
> within cookie, hidden form field or URL.

No -- it is more difficult to exploit XSS vulnerabilities *for the purpose of capturing the victim's existing session token* if the application stores the session token in a hidden form field than if the application uses conventional cookies.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

Cheers,
PortSwigger Received on Thu Aug 14 10:35:19 2003