RE: Custom session tokens and XSS

Why couldn't this be used for XSS? If the form field name is constant it would be trivial to write JavaScript to loop through the available forms on a page, find the token and forward it to an attacker. The attacker than then use the token for authentication and, theoretically, will be allowed in the application.

Unless I'm missing something here, this is ripe for exploitation unless the data is sanitized before being returned to the browser.

-dhs

-----Original Message-----

From: PortSwigger [mailto:mail@portswigger.net] Sent: Tuesday, August 12, 2003 4: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.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

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 Received on Tue Aug 12 18:20:48 2003