Re: Custom session tokens and XSS

[PortSwigger <mail () portswigger net>]

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.

Cheers,
PortSwigger