Cross site request forgery is the one where the bad person sticks an image tag or some javascript or whatever on a page, and your privileges are used to do something. So my latest little experiment: out of the image urls your browser sees that have queries (the '?a=b&c=d&e=f'), how many are - just advertisement trash anyway - things you want where the request would work just as well with the query removed (e.g. forum software that likes to stick session ids on everything) - things that wouldn't still work but don't really matter (e.g. user icons) - things you need Here's a little bit of code that tries rejecting them. (If dillo had an option for such a thing someday, I imagine it would have a form more like "don't automatically load, and make it easier to know what the URL is before you load it manually")
On Tue, Sep 30, 2008 at 12:56:05PM +0000, corvid wrote:
So my latest little experiment: out of the image urls your browser sees that have queries (the '?a=b&c=d&e=f'), how many are
There's nothing wrong with that. Such an image URL is a simple GET request. Any web application doing a modification is broken by design and there are good reasons for allowing such URLs. The problem is allowing POST actions to a different site than the one issuing it. If you want to prevent CSRF, consider adding a warning for that (e.g. form action and current URL are not under the same second level domain). Joerg
Joerg wrote:
On Tue, Sep 30, 2008 at 12:56:05PM +0000, corvid wrote:
So my latest little experiment: out of the image urls your browser sees that have queries (the '?a=b&c=d&e=f'), how many are
There's nothing wrong with that. Such an image URL is a simple GET request. Any web application doing a modification is broken by design and there are good reasons for allowing such URLs. The problem is allowing POST actions to a different site than the one issuing it.
Isn't that part of the problem -- that broken sites are using GET for things they shouldn't? PS How about not sending cookies with queries for images?
If you want to prevent CSRF, consider adding a warning for that (e.g. form action and current URL are not under the same second level domain).
Joerg
On Tue, Sep 30, 2008 at 02:51:58PM +0000, corvid wrote:
Joerg wrote:
On Tue, Sep 30, 2008 at 12:56:05PM +0000, corvid wrote:
So my latest little experiment: out of the image urls your browser sees that have queries (the '?a=b&c=d&e=f'), how many are
There's nothing wrong with that. Such an image URL is a simple GET request. Any web application doing a modification is broken by design and there are good reasons for allowing such URLs. The problem is allowing POST actions to a different site than the one issuing it.
Isn't that part of the problem -- that broken sites are using GET for things they shouldn't?
CSRF is about both. Broken sites are broken sites -- not much to do about them. What I do worry about are properly written web applications, e.g. those that correctly use GET/POST, but don't have explicit protection about CSRF. The latter is kind of intrusive if the framework used doesn't allow that.
PS How about not sending cookies with queries for images?
Breaks if you are using session controll to decide what images can be accessed. Joerg
Hi, On Tue, Sep 30, 2008 at 12:56:05PM +0000, corvid wrote:
Cross site request forgery is the one where the bad person sticks an image tag or some javascript or whatever on a page, and your privileges are used to do something.
Sounds interesting. Just read the corresponding wikipedia entry.
So my latest little experiment: out of the image urls your browser sees that have queries (the '?a=b&c=d&e=f'), how many are - just advertisement trash anyway - things you want where the request would work just as well with the query removed (e.g. forum software that likes to stick session ids on everything) - things that wouldn't still work but don't really matter (e.g. user icons) - things you need
Here's a little bit of code that tries rejecting them. (If dillo had an option for such a thing someday, I imagine it would have a form more like "don't automatically load, and make it easier to know what the URL is before you load it manually")
To me the cross site request forgery issue looks more like an issue of the cookie system. Perhaps we should be more careful when to send out a cookie. What about not sending cookies with image requests, if the host of the image url is different from the one in the main page? What do other browser do about this? Cheers, Johannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Sep 30, 2008 at 12:56:05PM +0000, corvid wrote:
Cross site request forgery is the one where the bad person sticks an image tag or some javascript or whatever on a page, and your privileges are used to do something.
Johannes Hofmann wrote:
To me the cross site request forgery issue looks more like an issue of the cookie system.
No. CSRF is caused by browsers sending authentication credentials implicitly with every request to an host. Those credentials might be cookies, http AUTH headers, ssl client certificates or even your IP address in some (stupid) intranet solutions. Joerg Sonnenberger wrote:
There's nothing wrong with that. Such an image URL is a simple GET request. Any web application doing a modification is broken by design and there are good reasons for allowing such URLs. The problem is allowing POST actions to a different site than the one issuing it.
This is true, GET requests shouldn't be state changing. But there are ways to create POST requests automatically (most ''active content'' can do this) or by tricking the user into clicking on the submit button by styling them via css (this is called "clickjacking" nowadays... yay for more buzzwords) and using some social engineering ("click the monkey to win big $$$). Disallowing cross domain POST requests seems very restrictive but would solve the problem. Johannes Hofmann wrote:
Perhaps we should be more careful when to send out a cookie. What about not sending cookies with image requests, if the host of the image url is different from the one in the main page? What do other browser do about this?
Yes, I think this is the way to go. One need to decide when to send out authentication credentials (legitimate session) and when to strip them (CSRF attempt). Martin Johns and I developed a firefox extension [0] that does exactly this. Please see [1] pages 29 - 37 or [2] for more information. [1] is also a pretty good introduction to CSRF. Please note that the browser independent proxy solution is deprecated (but should work unless the twisted framework changed its api too much) and the firefox extension is somewhat unmaintained at the moment... Justus 0: http://www.nongnu.org/requestrodeo/ 1: http://www.informatik.uni-hamburg.de/SVS/personnel/martin/psj06johns-e.pdf 2: http://www.informatik.uni-hamburg.de/SVS/papers/2006_owasp_RequestRodeo.pdf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI41/IoPmwNWhsaZYRAhXNAJ0WbzFz51LEObLbF8/oEPkUuZtT4ACfbCNG KDOXrmHCAOyhR15a+p5tgR0= =Kokv -----END PGP SIGNATURE-----
Justus wrote:
Johannes Hofmann wrote:
Perhaps we should be more careful when to send out a cookie. What about not sending cookies with image requests, if the host of the image url is different from the one in the main page? What do other browser do about this?
Yes, I think this is the way to go. One need to decide when to send out authentication credentials (legitimate session) and when to strip them (CSRF attempt). Martin Johns and I developed a firefox extension [0] that does exactly this. Please see [1] pages 29 - 37 or [2] for more information. [1] is also a pretty good introduction to CSRF. Please note that the browser independent proxy solution is deprecated (but should work unless the twisted framework changed its api too much) and the firefox extension is somewhat unmaintained at the moment...
Having done some reading now: So for an HTTP redirect or an image request, A->B, I gather up the cookies that I would send when asking for B and discard those that I would not send if I were asking for A?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 corvid wrote:
Justus wrote:
Perhaps we should be more careful when to send out a cookie. What about not sending cookies with image requests, if the host of the image url is different from the one in the main page? What do other browser do about this? Yes, I think this is the way to go. One need to decide when to send out authentication credentials (legitimate session) and when to strip them (CSRF attempt). Martin Johns and I developed a firefox extension [0]
Johannes Hofmann wrote: that does exactly this. Please see [1] pages 29 - 37 or [2] for more information. [1] is also a pretty good introduction to CSRF. Please note that the browser independent proxy solution is deprecated (but should work unless the twisted framework changed its api too much) and the firefox extension is somewhat unmaintained at the moment...
Having done some reading now: So for an HTTP redirect or an image request, A->B, I gather up the cookies that I would send when asking for B and discard those that I would not send if I were asking for A? I am not sure I understand your question.
The basic csrf scenario is the following: 1. you log in to some web application hosted at good.org 2. with the same browser instance using another window or tab (or you just forget to log out and reused the same window) you visit evil.org 3. evil.org hosts an html page that triggers an request to good.org, either using an image/script/style/object/whatever tag in case of an GET request or using an form and javascript / css to submit the form 4. your browser sends any authentication credentials like cookies along with the request since they are associated with the target host thus allowing evil.org to change the state of your good.org account on your behalf The proper thing to do is to fix this on the server side, but since csrf isn't as widely known as xss many web applications are vulnerable to this problem. Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI5h9woPmwNWhsaZYRAiGUAJ42ZuicB6aYGYkrjDZj2lSRpB6h1QCcCJ38 +zhCOeq1aO0Q747/tfeAQoU= =4QtQ -----END PGP SIGNATURE-----
Justus wrote:
corvid wrote:
Justus wrote:
Perhaps we should be more careful when to send out a cookie. What about not sending cookies with image requests, if the host of the image url is different from the one in the main page? What do other browser do about this? Yes, I think this is the way to go. One need to decide when to send out authentication credentials (legitimate session) and when to strip them (CSRF attempt). Martin Johns and I developed a firefox extension [0]
Johannes Hofmann wrote: that does exactly this. Please see [1] pages 29 - 37 or [2] for more information. [1] is also a pretty good introduction to CSRF. Please note that the browser independent proxy solution is deprecated (but should work unless the twisted framework changed its api too much) and the firefox extension is somewhat unmaintained at the moment...
Having done some reading now: So for an HTTP redirect or an image request, A->B, I gather up the cookies that I would send when asking for B and discard those that I would not send if I were asking for A? I am not sure I understand your question.
The basic csrf scenario is the following:
1. you log in to some web application hosted at good.org 2. with the same browser instance using another window or tab (or you just forget to log out and reused the same window) you visit evil.org 3. evil.org hosts an html page that triggers an request to good.org, either using an image/script/style/object/whatever tag in case of an GET request or using an form and javascript / css to submit the form 4. your browser sends any authentication credentials like cookies along with the request since they are associated with the target host thus allowing evil.org to change the state of your good.org account on your behalf
The proper thing to do is to fix this on the server side, but since csrf isn't as widely known as xss many web applications are vulnerable to this problem.
I understand that there's a distinction between - dillo making the request on the user's behalf because he clicked a link or pressed a button or whatever, knowing the url. This request is made with the user's privileges. - dillo making the request on behalf of some code that caused a redirect or loaded an image (auth, css, javascript, etc. being implemented would result in further cases)... This request is sometimes made with some privileges depending on whether the requesting code has that privilege... So I want to be sure that I understand under what conditions the cookies can be sent. It seems that if the requesting url meets the conditions that would cause me to send it a cookie, then I either _did_ send it that cookie earlier, or it just gave it to me, so I would be (sort of) okay in sending that cookie in a request on its behalf. I see that rfc2965 also has some dot-based rules about "unverifiable transactions"... A bit of looking around the web gives me the impression that all of the various dot things that surround cookies have been an awful mess that don't map well to real-world trust boundaries. (This opera guy, for instance http://my.opera.com/yngve/blog/index.dml/tag/HTTP) Hmm...
On Wed, Oct 01, 2008 at 09:33:09PM +0000, corvid wrote:
Justus wrote:
Johannes Hofmann wrote:
Perhaps we should be more careful when to send out a cookie. What about not sending cookies with image requests, if the host of the image url is different from the one in the main page? What do other browser do about this?
Yes, I think this is the way to go. One need to decide when to send out authentication credentials (legitimate session) and when to strip them (CSRF attempt). Martin Johns and I developed a firefox extension [0] that does exactly this. Please see [1] pages 29 - 37 or [2] for more information. [1] is also a pretty good introduction to CSRF. Please note that the browser independent proxy solution is deprecated (but should work unless the twisted framework changed its api too much) and the firefox extension is somewhat unmaintained at the moment...
Having done some reading now: So for an HTTP redirect or an image request, A->B, I gather up the cookies that I would send when asking for B and discard those that I would not send if I were asking for A?
Sounds good. In which cases this will not discard all cookies? Cheers, Johannes
Johannes wrote:
On Wed, Oct 01, 2008 at 09:33:09PM +0000, corvid wrote:
Justus wrote:
Johannes Hofmann wrote:
Perhaps we should be more careful when to send out a cookie. What about not sending cookies with image requests, if the host of the image url is different from the one in the main page? What do other browser do about this?
Yes, I think this is the way to go. One need to decide when to send out authentication credentials (legitimate session) and when to strip them (CSRF attempt). Martin Johns and I developed a firefox extension [0] that does exactly this. Please see [1] pages 29 - 37 or [2] for more information. [1] is also a pretty good introduction to CSRF. Please note that the browser independent proxy solution is deprecated (but should work unless the twisted framework changed its api too much) and the firefox extension is somewhat unmaintained at the moment...
Having done some reading now: So for an HTTP redirect or an image request, A->B, I gather up the cookies that I would send when asking for B and discard those that I would not send if I were asking for A?
Sounds good. In which cases this will not discard all cookies?
Well... if we had two johannes.de cookies and one had the Secure attribute, then if http://johannes.de redirected to https://johannes.de, we'd send one cookie, even though the server will probably expect both, and it's not an uncommon sort of redirect, so it might be bad. But at undergraduates.uni-johannes.de, I lean toward not wanting to trust the requester more than I am really forced to. For that matter, I think the rules let you make cookies for a domain as wide as .uni-johannes.de ..or .co.uk... I don't know. Maybe what cookies do is fundamentally a hard problem, but sometimes it feels like they were quickly hacked together without much concern for anything. Or perhaps the controlling bodies had ad revenue in mind more than anything else.
I wrote:
Johannes wrote:
On Wed, Oct 01, 2008 at 09:33:09PM +0000, corvid wrote:
Justus wrote:
Johannes Hofmann wrote:
Perhaps we should be more careful when to send out a cookie. What about not sending cookies with image requests, if the host of the image url is different from the one in the main page? What do other browser do about this?
Yes, I think this is the way to go. One need to decide when to send out authentication credentials (legitimate session) and when to strip them (CSRF attempt). Martin Johns and I developed a firefox extension [0] that does exactly this. Please see [1] pages 29 - 37 or [2] for more information. [1] is also a pretty good introduction to CSRF. Please note that the browser independent proxy solution is deprecated (but should work unless the twisted framework changed its api too much) and the firefox extension is somewhat unmaintained at the moment...
Having done some reading now: So for an HTTP redirect or an image request, A->B, I gather up the cookies that I would send when asking for B and discard those that I would not send if I were asking for A?
Sounds good. In which cases this will not discard all cookies?
I should also mention that it does have the virtue of being easy to implement, so it wouldn't take much to be able to try it out. RFC 2965 mentioned not accepting the cookies that you get back from an untrusted request either, which is an interesting thought.
participants (4)
-
4winter＠informatik.uni-hamburg.de -
corvid＠lavabit.com -
joerg.sonnenberger＠web.de -
Johannes.Hofmann＠gmx.de