Click to get Security Testing Quote

Plynt Blog

Page Tokens, Session Hijacking and Cross Site Scripting

by Roshen Chandran  | 02 Oct 2005 | Comments

Do Page Tokens toll the death knell of Session Hijacking and Cross Site Scripting (XSS) attacks?

Huh, no… they just made Session Hijacking very difficult.

If you are new to Page Tokens, here’s the original article to read. Basically, Page Tokens are short-lived tokens embedded in every request. Unlike session tokens, page tokens are created and destroyed when a user moves from one page to the next. Further, all query string variables are replaced by a page token. The server just remembers which variables were replaced by the token.

For instance, the link that looked like this without page tokens,

<a href="/accounts/summary.jsp?acc=1000&type=current">Account Summary </a>

would now take this form with page tokens:

<a href="/accounts/summary.jsp?pagetoken=23455453">Account Summary </a>

What does this have to do with Session Hijacking and XSS?

Assume that a session token has been stolen by XSS (or any other attack!). The window of opportunity to hijack a session is when the session token is still valid, ie. until the user logs out.

Enter Page Tokens. Let’s assume that the session token and all the page tokens in a page have been stolen. What’s the window of opportunity to hijack the session? It’s now that narrow window of time before the user moves to the next page. That’s usually a very short time to manually hijack the session.

Does that eliminate session hijacking completely? No, it raised the bar by reducing the window of opportunity. One could arguably create automated attacks that hijack a session even in that narrow window. But, it just got a lot more difficult.

Sangita pointed out further benefits of page tokens, especially their ability to thwart variable manipulation attacks. Those are additional reasons you’d want to implement Page tokens.


Plynt provides penetration testing and code review services to clients worldwide. If you are interested, please contact us for a quote. We’ll get back to you within one working day.
Add yours.closed for this post.

1. Prasad | 29 Mar 2006 7:16 AM

This might be too late but if you get a chance to read this comment, please do reply.

I read Sangita's and Joe's thoughts about page and request tokens and I do agree with the brilliancy of the idea but I fail to understand your concern. In case of session tokens, they are written into cookies and XSS can be very well used in compromising the cookie and hijack the session leading, probably, to a replay attack or something.

But, in case of page tokens the case seems to be different to me. The simple dynamism of the technique of generating page tokens for every darn request serve in defeating session hijacking, ain't it ?

How, in a simplest case, can XSS be leveraged to defeat the page tokens (although I am a strong believer of the saying "Impossible is nothing") ?

2. Roshen Chandran | 29 Mar 2006 6:04 PM

Prasad,

Hope I understood your question correctly - "since page tokens are dynamic, how can a session be hijacked anyway?"

Let's assume a script picks up the tokens from a page and sends it to an attacker. Now he can hijack the session if the tokens haven't changed in the meantime.

Yes, page tokens are very dynamic - it changes when a user reaches a new page. But for the duration the visitor is on the same page, the valid page tokens for that session are constant.

Thus there is a window of opportunity - the time before the user moves to a new page. During that time, an adversary can hijack the active session.

Hope that's clearer.

Roshen.