Session Riding Attacks

By balaji

August 6, 2006

A session riding attack (also called a Cross Site Request Forging attack) is a technique to spoof requests on behalf of other users. It lets adversaries spoof online transactions, modify user details, siphon off funds. And that's only the beginning. In this article, we show how the attack works and the defenses we need to put in place. The key to understanding session riding is Cookie-based session management - the most popular form of session management. So, let's turn to that first.

A session riding attack (also called a Cross Site Request Forging attack) is a technique to spoof requests on behalf of other users. It lets adversaries spoof online transactions, modify user details, siphon off funds. And that's only the beginning. In this article, we show how the attack works and the defenses we need to put in place. The key to understanding session riding is Cookie-based session management - the most popular form of session management. So, let's turn to that first.

Cookie-based session management

In a cookie-based session management, once a cookie is set by a web application, the browser automatically attaches the cookie to every further request sent to the application.

For example, consider a shopping cart web application ( that uses cookie-based session management. Whenever a user login to the application, the application would assign a random and unique session token for the session and set it in the cookie. All further communication by the user would include this cookie as the browser will append the cookie automatically in the request header and send it to the application. Consider that this application also uses a form-based transaction for placing an order.

Order Form

The above form uses the GET method, meaning it utilizes query string variables in the URL for placing the order. So the request sent to the application will appear something like this: &manufacturer=Lenovo&product=ThinkPad+T60p&payment=COD&submit=Order

Now let's see how this feature of the browser is being exploited to carry out session riding attacks.

Exploring session riding attacks

The main factor that enables session riding attacks to succeed is the use of cookies by the targeted web application. This is because the session token used by the application for managing user sessions is available in the cookie that is sent automatically by the browser making the adversary's work easier.

The adversary first generates a malicious link that includes the URL for placing an order in the application. The adversary then sends an email to the victim with the malicious link. Alternately, he might lure the victim to his website, and the site sends a forged request automatically. When the victim clicks on the link in the email or visits the website, the request for placing the order is submitted to the application, leading to a successful attack. There is a prerequisite though: the user has to be logged into the application. Now let's see as to why the attack succeeded.

Say the adversary succeeded in luring the user into visiting the crafted website. The webpage will include an <img> tag with the URL for placing an order on the application, something like

<img src=" &manufacturer=Lenovo&product=ThinkPad+T60p&payment=COD&submit=Order" />

This URL above places an order to purchase an IBM laptop with Cash on Delivery option. When the user visits this page, the browser will parse the <img> tag and generate a GET request for the URL specified in the 'src' parameter. When this request is generated, the browser will also append the session cookie set by the domain when the user logged into the application.

On receiving this request, the application would validate the session cookie prior to posting the order. Since this cookie is a valid session cookie, the order will be posted by the application. Thus, the adversary has succeeded in placing an order for an IBM laptop on behalf of a user through the user's session itself. All this happens completely without the knowledge of the user.

Variations of the attack

Alternate HTML tags

In addition to the <img> tag that we saw above, an adversary could use any of the HTML tags such as <iframe> and <script src=""> that generate requests automatically. All these forged requests will also be appended with the valid session cookie by the browser and executed by the application. This is primarily because the browser cannot identify the appropriateness of the URL for the invoking tag as it sends the cookie merely based on the domain and the path. Similarly, the server cannot know which HTML tag initiated the request, as there is no indication of it in the request header.

Redirection on the crafted website

Unfortunately, browsers also portray the same behavior on redirects. Say in the crafted website, the <img> tag (or any other HTML tag) on the webpage may not contain the malicious request. Instead, the request may be a valid request for that website, but the response could be used to redirect the browser with the malicious link. In this case, the victim has no way of identifying when or where the malicious request got initiated.

Using popular websites as carriers

It is not necessary for the adversary to entice the victim to visiting the crafted website. Rather, the adversary can make any popular website, which allows HTML integration, as a carrier of the malicious requests. In such a case, the attacks succeed more easily as the victim trusts these websites. The worst situation is when the targeted application itself is made the carrier of such forged requests. In this situation, the fact that the user is already logged into the application leaves no chance of escaping the attack.

Protecting against such attacks

As we can see, the web application is not so much at fault here as an inherent feature of web technology is being exploited. But, as with several browser bugs, the web application is the one that has to handle it.

Some of the solutions include using secrets with URL/forms and performing URL rewriting. These solutions should be incorporated atleast while carrying out sensitive activities in the application.

Using secrets

While the simple solution of using secrets is very effective against session riding attacks, implementing it could actually be an overwork for the developer. Here a secret such as a randomly generated token is included with the URL or the form. This secret is generated only after the user has logged in and has the same properties as a session ID with the difference of being transmitted as a query string or a POST variable. When the request does not carry this secret or the secret does not match with the one on the server, then the request is not processed and the session is invalidated.

For the above example, if the URL for placing the order included a secret like token=5e623282ac628e2b5df7, then the request would have been: &product=ThinkPad+T60p&payment=COD&submit=Order&token=5e623282ac628e2b5df7

This would have avoided the attack, as the adversary couldn't have inject a valid token, leading to the invalidation of the forged request.

The most important aspect to remember while implementing this solution is that the secret should not be transmitted through an automated feature of the browser, but should be submitted depending upon the request.

Why not use the session ID itself for this purpose? Good question. But transmitting the session ID over a URL possesses other insecurities. In addition, any XSS vulnerabilities in the application could be exploited by an adversary to include the secret into the forged request. Hence, it is recommended that the secret should be separate from the session ID.

The concept of page tokens that we discussed in August 2005 can also be used here as the secret.

Performing URL-Rewriting

URL rewriting also helps to protect applications against session riding. We saw that the adversary could carryout a successful session riding attack as the URL to place an order was always the same with only the parameter values for the product being dynamic. Since URL rewriting inherently changes the parameters in the URL being submitted each time, session riding attacks fails to succeed.

In fact, several applications use URL rewriting for session tracking purposes as all the browsers may not support cookies or that cookies may be disabled on the browsers.

Strategies that don't work

We have seen several prescriptions that don't really work. Here's a quick cautionary note.

Implementing confirmation pages

Confirmation pages are used as an intermediate step to complete a command execution. This is primarily used to avoid the direct execution of a command submitted by a user by mistake.

While confirmation pages may be thought off as a protection mechanism, it actually does not avoid the adversary from carrying out the attack. This is because the use of confirmation pages only makes the attack a two-step process. Here, the adversary uses two links on the same page. The first link contains the URL for placing the order and second link confirms the order. The adversary could even delay the submission of the second request using a javascript. This way the application considers that the user placed the order first and then clicked on the confirm option on the response page.

In case, where the confirmation request carries all the details for placing the order, the adversary could as well skip the first step and directly use the second link to place the order.

Using POST instead of GET

While GET requests are easier to carryout session riding attacks, it does not mean that POST requests cannot be forged. If Javascript is enabled, the adversary could generate forged POST requests without user interaction, similar to GET. If Javascript is disabled, the adversary may have to lure the victim into clicking on something on the crafted website that will generate the forged POST request.


  1. Session Riding by Thomas Schreiber
  2. How to perform session riding test - OWASP Testing Guide
  3. Cross-Site Request Forgeries

Tags: Features