Session Riding25 Jan 2005
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.