Secure your sessions with Page Tokens
by Sangita Pakala, GCIH | Discuss this article »» (16)
Session tokens are used for maintaining the user sessions in web applications. In this article we go beyond session tokens to introduce an enhanced session management scheme using page tokens.
A major challenge faced by a web application developer as opposed to any other developer is session management. In non-web client server architecture, once the client connects to the server, the connection is open till explicitly closed. So, the server knows which user and which client it is talking to. Web developers do not have this luxury. Web server treats each request as a new one and serves a response. It has no means of distinguishing between clients leaving it to the developer to maintain different sessions for different users.
The simplest way to recognize a request as being from a particular user would be to send the password with each request. So if you log into a web mail application with the username email@example.com and password obelix, and click on the inbox link, obelix goes along with the request. The server displays your inbox. Simple it is but not safe as passwords can be stolen from the requests if the entire site is not on SSL. Since passwords are same till the user chooses to change it, an attacker who obtains it can use it in the requests to browse your inbox. So developers introduced a Session token. It is a random string assigned to you when you log in with your credentials. The server remembers asterix has been assigned say X. Now each request from your browser till you logout should contain X. The application has reduced the life of the token used to manage session thus raising the barrier for attackers.
The application can make it difficult for the attackers to guess the session token by making it sufficiently random and expiring it on logout. But once the attackers have found out the session token, the application cannot protect the user during the session lifetime.
When the developer community started thinking ahead of the attackers they came up with the idea of page tokens. This is an extension of the concept of session tokens. Just like by having a different token for each new user session, we made it difficult for the attackers, now we introduce a new token for each page that is requested.
Let’s see how it works. You login to the application with your username and password. After authenticating, the server assigns you a Session token. In addition to that, while constructing the page to be shown, it replaces the variables in the URLs of all the links within the page by random numbers - page tokens. The server maps the URLs to the page tokens it created. You are then served this page along with the session token. When you click on a link in the page, the server will serve the request after validating the session token and looking up the URL to page token mapping. The corresponding page is then shown.
For example, if a link in the page is:
it will be changed to:
The Benefits of using Page Tokens
Page tokens solve a number of security issues. Since a page token is much short lived, it is now more difficult for attackers to browse a user’s session. The page tokens present in a particular page are valid only till the user clicks one of the links. A soon as the server receives a new request, the old tokens are overwritten with a new set.
The application if desired can enforce a sequence in which the site is to be browsed. Since the request for any page needs to be accompanied by a valid page token, the user cannot type the URL for an arbitrary page and view it.
Variable manipulation attacks can be avoided if page tokens are used. Let’s take the example of an online banking application which uses only session tokens and not page tokens. Suppose in the Account Summary page there is a link for each of the user’s account. Clicking on a particular account sends a request to the server with the account number stored in a variable. An attacker with a valid user account, logs in, clicks on the link to view the summary of his current account number say 1000. He then captures the request in a HTTP proxy, substitutes 1000 with 2000 which is the account number of another user.
GET /accounts/summary.jsp?acc=1000&type=current HTTP/1.0 Referer: http://www.mybank.com/accountsummary.jsp Host: www.mybank.com Cookie: JSESSIONID=99iarjagr8210
The unsuspecting application displays account B’s summary. Now let’s introduce page tokens in this application and see what happens. When the attacker requests the Account Summary page, the application generates a page token for each of the links and stores in the mapping table. So, the URL that would show the summary of A has been replaced by a page token in the response.
GET /accounts/summary.jsp?pagetoken=23455453 HTTP/1.0 Referer: http://www.mybank.com/accountsummary.jsp Host: www.mybank.com Cookie: JSESSIONID=99iarjagr8210
Now, the attacker cannot modify the account number since it does not go as a variable in the request.
Implementing Page Tokens – The Details
How can page tokens be implemented? When a user logs in, the application assigns a session token and creates a temporary table for mapping the URL to page token and fills it with the page tokens for the URLs in the first page. When the next request comes in, it first validates the session token and looks up the mapping table for the user. If the token is not present, the request is not a valid one and the user is logged out of the application. If it finds the token, it looks at the URL and variables and knows what content to serve next. While constructing the second page, the application overwrites the table with the new page tokens and the URLs of the links to be shown on the page. So at any point in time, the application only remembers one set of page tokens for the current page served to the user. In addition to this, it also remembers the last request received, to serve the page again in case the user refreshes it.
Challenges of Page Tokens
However, page tokens increase the overhead on the application and are also more difficult to implement than session tokens. Session tokens can be implemented using the features available in most frameworks whereas for page tokens, the responsibility is on the developer.