About the Author

Chris Shiflett

Hi, I’m Chris: web craftsman, community leader, husband, father, and partner at Fictive Kin.

Session Riding

I recently discovered a PDF that describes something called Session Riding. Having no idea what session riding is, I decided to read it. From the introduction:

In this paper we describe an issue that was raised in 2001 under the name of Cross-Site Request Forgeries (CSRF). It seems, though, that it has been neglected by the software development and Web Application Security community, as it is not part of recent Web Application Security discussions, nor is it mentioned in OWASP's Top Ten or the like.

I agree that CSRF is an important topic that is not given proper attention. I consider it to be one of the most dangerous web application attacks, especially after observing the results of my recent PHP security experiments.

We prefer to call this issue Session Riding which more figuratively illustrates what is going on.

To be clear, session riding is nothing more than a new name for Cross-Site Request Forgeries - an attack that has been discussed for four years and for which there exists four years of documentation. Of course, I suppose that you would have to get a new name adopted if you want your PDF on the topic to be a top Google result.

In short: with Session Riding it is possible to send commands to a Web application on behalf of the targeted user by just sending this user an email or tricking him into visiting a (not per se malicious but) specially crafted website.

This is actually completely backward. With CSRF, the victim unknowingly sends requests of the attacker's choosing to the target site. The attacker does not send "commands" (requests) on behalf of the victim. To be fair, the rest of the document demonstrates a correct understanding of CSRF, so this is apparently an honest mistake.

Most of this document is good. The main solution presented (Solution 1) is very similar to the solution I usually recommend, although it is a bit weaker and focuses more on the session risk. I believe that it offers adequate protection, else I would refute it. I'll let you read the document and come to your own conclusions about its merit as well as the merit of the other solutions presented.

What are your thoughts about renaming known security concerns? Are there special cases where it might be appropriate? I plan to continue to use the original term - CSRF is a more accurate description of the technique, and inconsistencies in naming aren't going to help people better understand it.

About this post

Session Riding was posted on Tue, 25 Jan 2005. If you liked it, follow me on Twitter or share:


1.Aaron Wormus said:

If you have to choose between a technically accurate description, and a simple term which the programmers -- who are most likely to make the mistakes -- will understand, then I would say that using a simplified term could probably be an exception.

Tue, 25 Jan 2005 at 08:19:22 GMT Link

2.Jared Williams said:

Hmm odd paper.

Surely if using Solution 1 helps prevent CSRFs, then the same solution can be applied to the confirmation pages

by making the checked query string parameter in


to something unpredictable, but verifiable, using server side secrets.

As for the name, would've preferred them to stuck to the orignal.

But then would you have read it, posted about it, and therefore raised awareness a bit more? :)

Tue, 25 Jan 2005 at 11:01:05 GMT Link

3.Ben Ramsey said:

I prefer the term CSRF--I think it's the most accurate name. However, I think this term often gets confused with XSS or paired with it when it shouldn't be. So, I agree with Aaron on using the simpler term that is easier to distinguish and separate from XSS. Maybe CSRF can be the proper name for it, while "session riding" becomes the lay term or nickname?

Tue, 25 Jan 2005 at 14:59:15 GMT Link

4.Azmo said:

If CSRF had been a not widely adopted, and incorrect or unclear term, I would have understood the need for a name change. But IMO this isn't the case.

My thoughts on this document:


- on page 13 they explain how the use of cookies to store the secret key can competely void the use of a secret key. I think this is essential to note in any discussion of CSRF.

- page 14 describes how most confirmation pages can, and will, be circumvented.


- page 13 suggests the use of a single secret key, and adding this to every link and form. A site that's vulnerable to XSS might come under CSRF attack by it's own users if the secret key can be extracted from the URL. (Local Request Forging or LRF? Should we distinguish between the two?)

- although they mention the <img> tag being particularly vulnerable, I don't recall reading about the risks of ALL elements that cause additional requests to be made without the user's interaction.

Chris: do you have any information on preventing an application being used as a host to launch attacks to vulnerable sites? i.e. how do I prevent my (hostile) users from submitting images that 'attack' other sites?

Tue, 25 Jan 2005 at 21:38:12 GMT Link

5.Azmo said:

Of course, local attacks are probably easier to stop, because the administrator has access to both the attacking content, the targeted source code, and the insertion source code. Blocking a particular attack at any of these points might already be enough to stop it altogether.

But still... :-)

Tue, 25 Jan 2005 at 21:41:59 GMT Link

6.Mauro said:

[a late comment, but apparently google indexed this thread and made it popular rather recently...]

"To be clear, session riding is nothing more than a new name for Cross-Site Request Forgeries - an attack that has been discussed for four years and for which there exists four years of documentation."

Yes and no. The problem is right this: had CSRF really been discussed and understood, we wouldn't probably had a new name proposed for it. Also, "four years of documentation" is an exaggeration. Its coverage appears spotty at best.

Apparently a bugtraq post (though a very good one indeed) is not sufficient to leave a permanent trace.

Wed, 25 Jan 2006 at 11:40:27 GMT Link

7.Zefiro said:

What would be the solution you usually recommend? If you state it's more secure than the method presented by Thomas Schreiber.

Fri, 24 Mar 2006 at 18:03:22 GMT Link

8.SumSid said:

What about use of http referrer?

Fri, 07 Jul 2006 at 09:24:48 GMT Link

9.micha said:

While CSRF initially was not meant (or restricted) to sessions, session riding is a spezial case of CSRF where the session ID is transported using cookies. Note that the same threat applies to basic authenticatication, but not URL rewriting.

According "http referer": this could be a counter measure, and IIRC it's mentioned in the paper, but the http refer(r)er is not always available (faked or removed for various mainly privacy reasons).

Now also consider modern "controller" applications, where you always have the same URL and hence the same referrer. The referrer is useless in this situation. Eexcept if it changes some GET parameters for every call, but then you're back to the unique additional secret described in the paper, somehow.

If someone prefers CSRF or session riding is IMHO more a matter of taste. One might use the same argumentation -new obsolete buzzword- for a couple of other common used terms too. For example is XSS a form of parameter tampering, and it's missing input validation, and it's missing output validation, or missing data validaton, it's also content spoofing. And more worse, XSS is commonly used for what is simple HTML injection (no scripting involved) too. Anyway, XSS is what is commonly used.

Are all these terms obsolete? did someone complain about them? No! And that is good, 'cause each of them describes a threat and/or vulnerability in a special context.

If a developer has to design and implement countermeasures against session fixation and session hijacking (difficult though), session riding should also be considered. In such a context session riding is more convenient than CSRF. Does this make sense?

Sat, 23 Sep 2006 at 18:00:06 GMT Link

10.John said:

"I suppose that you would have to get a new name adopted if you want your PDF on the topic to be a top Google result."

If this was their plan, it seems to have failed. This page is currently the top Google result for session riding.

Wed, 27 Sep 2006 at 21:35:35 GMT Link

Hello! What’s your name?

Want to comment? Please connect with Twitter to join the discussion.