WebApp Sec mailing list archives
Re: Custom session tokens and XSS
From: PortSwigger <mail () portswigger net>
Date: Thu, 14 Aug 2003 15:16:34 +0100
I disagree.
Regarding existing session stealing XSS attacks, there is really no difference at all between a hidden form field and a cookie - both are equally accessible from within javascript. So if the attacker can induce any xss payload on the victim, it doesnt make much difference if you store the session token in a cookie or in a hidden form field. They can both be read by a javascript and then submitted using any common technique to a third location.
This "if" is the whole issue. Of couse, if the attacker can get as far as injecting arbitrary HTML/JavaScript into a user's page **which contains the user's existing session token** then the attacker can capture the token from within the form. But the problem for the attacker lies one step further back. Take one typical way to exploit XSS vulnerabilities -- feeding the user a crafted URL containing JavaScript within the querystring. With conventional cookies, a user requesting this URL will receive a page containing the attacker's code, whilst remaining within their existing session (because the browser automatically submitted their cookie when they clicked the link). With a session token stored in a hidden form field, on the other hand, this will *not* happen. The user will make a GET request that does not contain any session token. The application will not associate the request with any existing session, and so the user's session token will not appear in the returned page. Sure, the attacker can execute arbitrary code, but the user's token is not there for the taking. An alternative exploit would be to induce the user's browser to make a POST request (e.g. by sending them a suitable HTML-encoded email). Unless the attacker already knows what the user's token is, he cannot place it within the form data, and it will not be sent in the POST. Again, the application will not associate the request with any existing session, and so the user's token will not appear in the returned page. If the application requires that the POST includes _a_ valid session token, then the attacker can obtain one independently and place it in the form (a la session fixation), and the attacker's token will be submitted. Either way, the page returned by the application, in which the attacker's code will execute, will not contain the user's prior session token. So some common ways of exploiting XSS don't work here. In *some* applications, it could still be done. In an application which receives user data and makes that data visible to other users, a malicious user could submit a XSS payload to the application (within their own session) which would later be viewed by the victim -- the attacker's code would be executed within the victim's browser in a page also containing the victim's session token, which could then be stolen. But the attack would depend upon this (comparatively rare) functionality within the application. (How many online banks let you post messages to other users? :))
Bottom line: It is equally easy / difficult for an attacker who is able to induce xss payload on the victim's browser to steal any existing SID be it stored within cookie, hidden form field or URL.
No -- it is more difficult to exploit XSS vulnerabilities *for the purpose of capturing the victim's existing session token* if the application stores the session token in a hidden form field than if the application uses conventional cookies. Cheers, PortSwigger
Current thread:
- Re: Custom session tokens and XSS, (continued)
- Re: Custom session tokens and XSS Stephen de Vries (Aug 13)
- Re: Custom session tokens and XSS Ingo Struck (Aug 13)
- Re: Custom session tokens and XSS Stephen de Vries (Aug 13)
- Re: Custom session tokens and XSS Cyrill Osterwalder (Aug 13)
- Re: Custom session tokens and XSS PortSwigger (Aug 13)
- Re: Custom session tokens and XSS Ingo Struck (Aug 14)
- Re: Custom session tokens and XSS PortSwigger (Aug 14)
- Re: Custom session tokens and XSS Ingo Struck (Aug 14)
- Re: Custom session tokens and XSS Ian (Aug 14)
- Switching off scripts Ingo Struck (Aug 14)
- Re: Custom session tokens and XSS PortSwigger (Aug 14)
- Re: Custom session tokens and XSS Stephen de Vries (Aug 14)
- Re: Custom session tokens and XSS Ingo Struck (Aug 14)