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