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,
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.