|
|||||||||||
|
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,
On Tuesday 12 August 2003 22:02, Rob Morhaime wrote:
This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:07:54 EDT |
||||||||||
|
|||||||||||