Re: Custom session tokens and XSS

[dafydd <dafydd () dsl pipex com>]

Thanks Rob,

Yes, the session fixation possibility does call for a qualification to my 
previous mail, but I think part of the point still stands.

By causing the user's browser to submit a form containing the attacker's valid 
token, the attacker can inject arbitrary HTML/JavaScript into the user's 
browser within the authenticated area of the application. However, this could 
not straightforwardly be used to capture the session token of an already 
logged-in user (because the page returned containing the attacker's code 
would obviously also contain the attacker's token).

Re the original possibility in session fixation vulnerabilities (where the 
attacker fixes the user's session token before the user authenticates), this 
would be blocked in the usual way -- i.e. the app sets a new session token 
after every successful login.

Of course, the usual caveat applies -- you can do more with XSS than just 
cookie stealing (e.g. presenting a trojan login form). But because cookie 
stealing attacks are normally so easy to perform using XSS and require the 
least amount of user naivety, using a session management mechanism that can 
withstand them does raise the bar by some extent.

Cheers,
PortSwigger


On Tuesday 12 August 2003 22:02, 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