We should remember that non-malicious cross-site-requests with cookies go on all the time. A simple peek at your cookie store (or turning on accept/reject of cookies) will show that many sites make cross-site-requests with cookies all the time. Banner ads on the web work entirely based on cross-site GET requests with cookies. There is no same-origin policy for cross-site IMG, FRAME, etc requests with cookies.
If browser vendors broke all cross-site GET requests with cookies a large class of web applications would break. The acronym XSRF might be new, but the attack vector isn't. We were just as concerned about malicious cross-site requests in 1998 when I worked on My Netscape as we are on the sites I work on now in 2008. The access-control specification isn't intended to be about enabling or disabling cross-site requests, but whether the same-origin policy applies to allowing the requesting application to see the contents of the reply to the request. If we assume that cross-site GETs with cookies that cause side-effects are already possible and aren't going away, then sites must be aware and defend against them. If we assume the sites have the ability and are defending against malicious XSRF, then whether that cross-site GET request with cookies comes from an <img src=""> tag for an XMLHttpRequest invocation seems like splitting hairs. The only "new" behavior that comes by adding access-control to cross-site GET with cookies is that user-specific data is that the return-results are visible to the requesting site. This means it is far easier to share data between site A and site B (which is the intent). Preserving cookies with the requests means that site B can give site A personalized data about the user. This is the privacy issue, not a security issue. The old Yodlee.com mash-up becomes far easier to implement and you can build a Yodlee-style mashup without holding proxy tokens from the sites or copies of the user's credentials (which is a good thing!). Much of the interesting data for mash-ups is user-specific data. The wealth of applications you can envision is really high. Everything from shared RSS feed lists, shared calendar data, share package tracking information, shared travel reservation data, shared stock portfolios, shared sports teams could now be available in relevant mash-ups. In conclusion, blocking passing cookies on cross-site XHR requests due to XSRF concerns doesn't seem like a valid reason as cross-site requests with cookies are already an important feature on the web for many valid use cases even though it requires some vigilance from the website developer. With that said, if cookies are enabled, the privacy implications of eliminating any friction for site A to share your personal information with site B are very real and worth consideration. --Brad Jonas Sicking <[EMAIL PROTECTED]> wrote: Close, Tyler J. wrote: > The widespread vulnerability to XSRF makes it clear that developers > aren't used to thinking about the implications of letting third-party > sites automatically use the user's credentials. That alone suggests > widening the number of cases to think about is dangerous. I am further > arguing that there is nothing to be gained in this widening. Viable > designs require the user's consent for Site B to issue a request to Site > A on the user's behalf. In such a scenario, Site B is claiming to Site A > that the user wants something. Designing the protocol such that Site > B makes this claim without giving Site A any way to verify the claim is > asking for trouble. I think the main reason CSRF is so common today is that sites just don't think about the fact that they can be getting requests that originate from other sites. It's to a much much smaller extent the fact that they realize that they can get cross site requests, attempt to protect themselves against it, but fail to do it properly. Do you know of any incidents where that has been the case? With access-control sites specifically opt in to getting cross site requests. So I don't really see how they would not realize that they are going to then receive those cross site requests. > Back to your privacy comparison, this is not about controlling what you > do with what the user told you, but controlling how you claim to another > that you speak on the user's behalf. cookies included in the request does not mean that you speak on the users behalf. It just means that the user is using your site. / Jonas
