Re: Whitepaper "SESSION RIDING - A Widespread Vulnerability in Today's Web Applications"

[Joseph Miller <joseph () tidetamerboatlifts com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 17 December 2004 3:36 am, Philippe P. wrote:
> Hello,
>
>
>
> I like this paper ( http://www.securenet.de/papers/Session_Riding.pdf ),
> but i would like to make some comments:
>
> - In chapter 6.3.1, you say a javascript can help to submit the URL 1) and
> the URL 2).
>
> I think it's not necessary to use javascript for that. It's possible to
> return a special page with an image with a bad link, and a new link to
> manage the next step. The next step make exactely the same, a page with
> image and next step. I think it's possible to make a complex scenario with
> this approach.
>
>
>
> -         In chapter 6, you propose countermeasures. But, your propositions
> are complexes. A better approach is to check the header Referer for each
> request with parameter. If the Referer is not compatible the the site, you
> can reject the request. It's very easy to install, and you can continue to
> use the HTTP cache.
>
>
>
> Regards
>
>
>
> Philippe PRADOS


Due to the increasing privacy concerns of many online, referer checking would 
be generally a bad idea.  Though they are not the majority, there are many 
who like to block referer fields and their voices can be very loud.  They may 
decide to protest the idea, or even worse, protest existing web applications 
after the fact.  Besides this, there are many websites that have a redirect 
script somewhere on their website.  So the attacker could send the link 
http://www.website.com/redirect?url=/actions/dobadthing which would often 
satisfy that requirement.  Your solution also does not address such problems 
as an attacker placing malicious urls inside of a web app such as a forum, 
which would be on the same website that the attacker was attempting to ride 
on.  This also would satisfy your url requirements.  It would be possible to 
double check that the referer was not simply from any web page on the website 
but only a trust web page, however this is not as efficient as using the 
'secret' method.

On a side note, the secret could be more complex.  For example, if your 
'secret' method is double-checking a url parameter against a cookie, you may 
not necessarily want to use the same for both.  If it were possible to sniff 
the cookie, one may use this in their url.  Yes, this would be very difficult 
in most cases, but since we are talking about security, it is very possible.  
Maybe a better approach would be to hash the cookie secret against the 
destination url and add that hash as the url secret added to the end of the 
url.   This would make urls become 
http://www.somesite.com/script?action=someaction&hash=[hash of cookie secret 
+ http://www.somesite.com/script].  This would become slightly more secure.

It should also be noted that not all urls in a web application would need to 
be changed.  It should only really affect web pages where actions would take 
place that require authentication or perform some action.  For example, if 
you were simply browsing a forum, it is not necessary that a view of a forum 
page be subject to such 'secret' authentication, but a posted message to the 
forum would need this.  This would help to lower overhead and coding of 
implementing such a system.

- -Joseph Miller
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBxuUzmXZROF+EADURArM9AJ4sET1gDn5f0MMBI6d4JGLjjxx3bACfWJJ+
vSs4bNe4v/Sgxvc/hedEEp0=
=Ib+b
-----END PGP SIGNATURE-----