Pantek Library
Hosting Provided By
CybrHost
High Speed Hosting

Re: Custom session tokens and XSS

From: dafydd <dafydd(at)dsl.pipex.com>
Date: Wed Aug 13 2003 - 05:52:03 EDT

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,
Received on Wed Aug 13 07:15:26 2003

Do you need help?X

This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:07:54 EDT


Contact Us  Legal Notices  Order Services Online 
Pantek Home  Privacy Policy  IT news  Site Map  Pantek Library