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