WebApp Sec mailing list archives
Re: Custom session tokens and XSS
From: Stephen de Vries <stephen.devries () dcode net>
Date: Thu, 14 Aug 2003 15:10:56 +0000 (GMT)
On Thu, 14 Aug 2003, PortSwigger wrote:
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.
I think Ingo is looking at a different case here, which he explained in an offline email. IF the application assigned session ID's before the user authenticates AND the application maintains the same session ID after authentication, then an attacker could hijack a victim by: 1. Browse to the app and get a valid SID. 2. Create malicious email using his valid SID and passing it to the victim. 3. Victim clicks the link and uses the valid SID to authenticate. 4. The victim is now authenticated and the attacker knows the SID he's using. Of course, if the app regenerates SIDs after authentication then this attack won't work. And if the app only generates SIDs in the authenticated part of the site, then it won't work either. But apart from these conditios it doesn't make any difference whether the SID is stored in a cookie or a form field, they are both accessible by JS. cheers, Stephen
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 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)