Session Riding

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

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

https://b2b.company.tld/webapp/dele...3&checked=1

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

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

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:

Positive:

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

Negative:

- 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

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

[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

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

What about use of http referrer?

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

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

"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