> 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's possible to write the Referer: filters in a way that only permit
allowed state transitions. I've implement this for Mailman (using
Apache rewrite rules), and the approach should work a broader class of
applications. I agree that it could be challenging in some cases
where the same page shows untrusted content and offers some form field
(think of a guestbook, but with more sensitive data).
> 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's possible to write the Referer: filters in a way that only permit
allowed state transitions. I've implement this for Mailman (using
Apache rewrite rules), and the approach should work a broader class of
applications. I agree that it could be challenging in some cases
where the same page shows untrusted content and offers some form field
(think of a guestbook, but with more sensitive data).
[ reply ]