RE: Custom session tokens and XSS

["Rob Morhaime" <RobM () nexcura com>]

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