Re: Custom session tokens and XSS

[Stephen de Vries <stephen.devries () dcode net>]

On Thu, 14 Aug 2003, PortSwigger wrote:
> 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.

I think Ingo is looking at a different case here, which he explained in
an offline email.  IF the application assigned session ID's before the
user authenticates AND the application maintains the same session ID after
authentication, then an attacker could hijack a victim by:
1.  Browse to the app and get a valid SID.
2.  Create malicious email using his valid SID and passing it to the
victim.
3.  Victim clicks the link and uses the valid SID to authenticate.
4.  The victim is now authenticated and the attacker knows the SID he's
using.

Of course, if the app regenerates SIDs after authentication then this
attack won't work.  And if the app only generates SIDs in the
authenticated part of the site, then it won't work either.

But apart from these conditios it doesn't make any difference whether the
SID is stored in a cookie or a form field, they are both accessible by
JS.

cheers,
Stephen


> 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