RE: Custom session tokens and XSS

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

I think I may be misunderstanding this,  but if the attacker makes a web
request and gets a valid token, it will be a valid token for HIS session.
By creating a malicious email/web page with this token, the victim will be
opening the attackers session!
Any XSS in the page, will only have access to the attackers token - which
is useless from an attack point of view.


Stephen de Vries

On Tue, 12 Aug 2003, Rob Morhaime wrote:

> I do believe this setup would be vulnerable to a "session fixation" attack, as
> described in this paper:
> http://www.acros.si/papers/session_fixation.pdf
>
> Simple Example:
> 1) attacker makes a web request and receives a _valid_ token from vulnerable website.
>
> 2) attacker quickly creates a web page/email including a form with the _valid_ token in
> the hidden form field.  The action on the form points to the vulnerable website.
> The form also includes a bit of XSS.
>
> 3) attacker lures victim into submitting the form.  The victim is not redirected
> to login because token is valid, thus XSS has an opportunity to do it's dirty work.
>
> -Rob
>
>
> -----Original Message-----
> From: PortSwigger [mailto:mail () portswigger net]
> Sent: Tuesday, August 12, 2003 1:30 PM
> To: webappsec () securityfocus com
> Subject: Custom session tokens and XSS
>
>
> I have recently looked at a web application which maintains session state
> using a custom token stored in a hidden form field. Each page within the
> application is accessed using a POST request which includes the token.
>
> Several locations within the authenticated areas of the application exhibited
> XSS-like behaviour (i.e. client data submitted in form and URL querystring
> fields is returned unsanitised to the browser). However (as far as I could
> see) there was no way to exploit this to attack other users. Any request not
> containing a valid session token results in a redirect to the login page. And
> so assuming that only the user knows their own session token, only they could
> frame a malicious request that would succeed in injecting arbitrary
> HTML/JavaScript into their browser.
>
> The relevant difference from conventional session tokens (cookies) is that the
> custom token is not automatically stored and resubmitted by the browser as
> the user moves between pages. Rather, the browser only submits the token with
> any given request because the application has set the token within the form
> that generates that request. If the user initiates an arbitrary request
> (induced by an attacker) then it will not contain a valid token, and they are
> returned to the login page.
>
> Although the developers had chosen this means of maintaining session state for
> different reasons (to do with load-balancing across multiple web servers), it
> effectively reduces both the scope and impact of any XSS vulnerabilities:
>
> 1. Users can only be attacked using XSS vulnerabilities which appear within
> the unauthenticated area of the app, where a valid session token isn't
> required. If this area consists of a single login page, the task of
> addressing XSS problems is considerably reduced.
>
> 2. Attacking a logged-in user using any XSS vulnerabilities within the
> unauthenticated area of the app could not straightforwardly be used to
> capture their session token. Although the token is cached in the browser
> request history, it is not stored in 'document.cookie', nor could it be
> obtained using an XST-style trick. (Of course, there is plenty an attacker
> can do with XSS other than cookie-stealing, but this does prevent one of the
> easier attacks.)
>
> Of course, there may be downsides to this approach to session management, and
> I wouldn't recommend it without question, but I think it's worthy of
> consideration.
>
> Any thoughts?
>
> PortSwigger