Anne van Kesteren wrote: > On Thu, 07 Feb 2008 17:57:48 +0100, Close, Tyler J. > <[EMAIL PROTECTED]> > wrote: > > Anne van Kesteren wrote: > >> Actually, no, that is not true. Today you can issue > cross-site GET and > >> POST requests which is why I asked the question. > > > > A browser may issue a cross-site request, but some servers > are setup to > > recognize these requests and reject them; those servers > that don't may > > be vulnerable to Cross Site Request Forgery (XSRF) attacks. > The role of > > the server in rejecting these requests is what I was > referring to when I > > said: "browsers and sites cooperate to prevent cross-domain > requests". > > There is server-side cooperation in the prevention. > > Actually, a large number of servers are set up to process > them. Cross-site > <script> and <img> requests are pretty common. To serve > advertisements and > counters for instance.
Sure, and there are even cases of sites that can safely process cross-domain non-GET requests. This WG is trying to create a new way to do this, but the handling of accountability is... unclear. > > A key point in this issue is that today, browsers and > servers cooperate > > to *prevent* these requests; whereas this WG wants them to > cooperate on > > *accepting* requests. There are no accountability issues in > a rejected > > request, since the request isn't processed. There may be > accountability > > issues when requests are accepted. It seems the WG hasn't considered > > these issues. > > I'm not sure what makes you say that. Is the user or the Referer-Root site accountable for a cross-domain non-GET request? Does the proposed protocol make it possible for the site hosting the resource to correctly determine the answer to that question? --Tyler
