ID theft the XXS way

Opinion by Ken Munro

Attackers can gain access to sensitive information by stealing sessions on web applications. If you let them.

Attackers can gain access to sensitive information by stealing sessions on web applications. If you let them.

We've looked at cross-site scripting (XSS) before (SC, March 2007), but how do you actually go about using this to get into somebody's account on a web application?

Let's assume we have found a login to an ASP.NET web application and that it is vulnerable to XSS. Typically a session ID cookie will be set when the first request is made to a website. The user inputs their credentials using a login form and, when successful, the server side application remembers that "the user with this session cookie is authenticated" and displays different site content (personal details, order history etc). This is now an "active session" and that user will have authenticated access until they click "logout" or close their web browser.

Session stealing is possible where possession of an "active" session ID cookie value gives access to the authenticated application. Assuming that the ID value is random enough to prevent an attacker guessing it, a very basic session-stealing attack using the XSS vulnerability runs as follows.

Conduct a phishing attack against the application's users, either using email or instant messaging. This message will include a link that might look something like this: .location=""% 2bdocument.cookie;

If a user follows this link, the JavaScript being passed will execute a simple command forwarding the user's web browser to a third-party site ( with the value of the victim's cookies (for the domain) appended in the URL.

A script on "" logs the cookie value and forwards the user immediately back to the login form of the site. Smart users might spot this redirection, so this technique is fairly obsolete these days, even though there are more sophisticated ways to send the cookie value to

Now the attacker has the value of the ASP session ID cookie and can assume that the "victim" will log in to the application. The attacker can then visit that application and modify their session cookie to be the same as the victim's, giving access to the application and the victim's account.

A line of JavaScript such as: javascript:document.cookie= ; would have the desired effect when run from the address bar in a browser at the target web site.

The best way to stop this from happening is to ensure that your applications do not have any XSS vulnerabilities. There are a number of ways to help limit the risk of session stealing. Our exploit occurred because JavaScript has the power to access the session cookie value. There is a new facility that significantly helps improve cookie security: the "httponly" flag. When a cookie is specified with this flag set, the web browser will not allow JavaScript access to that cookie. Httponly is a great concept currently in Internet Explorer and will be implemented on Mozilla Firefox in the next release.

So what options are there to steal a session when the cookie cannot be taken remotely by an attacker using JavaScript? An attacker on the same local network as the target could feasibly sniff a user's interactions with a site to obtain an active session cookie if the site is unencrypted. To prevent this, authenticated requests should be conducted over SSL.

Some websites implement SSL encryption but neglect to separate the "secure" and "non-secure" content. To improve security the "secure" flag should be set in the cookie

Another way to protect users is to explicitly destroy and recreate the user's session cookie when they login. Since session hijacking occurs where the attacker does not know the credentials, the point where credentials are entered is the only place where the identity of the actual user is assured.

Session stealing is remarkably easy to do, particularly when combined with a spear phishing attack. It can give the attacker access to users accounts containing sensitive transactional information. It is also easy to mitigate, so beware.

- Ken Munro is managing director of SecureTest. He can be contacted at


Find this article useful?

Get more great articles like this in your inbox every lunchtime

Upcoming Events