[whatwg] Clickjacking and CSRF
sigbjorn at opera.com
Mon Feb 23 02:42:18 PST 2009
On Fri, 20 Feb 2009 19:36:47 +0100, Bil Corry <bil at corry.biz> wrote:
> Sigbjørn Vik wrote on 2/20/2009 8:46 AM:
>> One proposed way of doing this would be a single header, of the form:
>> x-cross-domain-options: deny=frame,post,auth; AllowSameOrigin;
>> This incorporates the idea from the IE team, and extends on it.
> Have you taken a look at ABE?
I am not quite certain what you are referring to, the document is a ruleset for how to express what is allowed and disallowed. Do you mean that clients should be using a URL list, or that servers should be using this particular grammar to decide which headers to send with their URLs?
For a domain wide policy file a document like this might work well though.
>> For cross-domain resources, this means that a browser would first have
>> to make a request with GET and without authentication tokens to get the
>> x-cross-domain-options settings from the resource. If the settings
>> allow, a second request may be made, if the second request would be
>> different. The result of last request are handed over to the document.
> Have you considered using OPTIONS for the pre-flight request, similar to
> how Access Control for Cross-Site Requests does it?
Good point. Trying to use OPTIONS for existing servers might break them, a GET might be safer. Then again, OPTIONS shouldn't break anything, GETs might have side-effects where OPTIONS don't, and an OPTIONS reply typically has a much smaller payload than a GET reply. In the case of a reply to a pre-flight request where the user agents has cookies but the server replies that contents are the same with or without cookies, an OPTIONS request would require two requests, a GET only one. OPTIONS is probably more in the spirit of HTTP though.
Either could work, the idea is the same. Which would be better would have to be researched empirically, but OPTIONS might be the better candidate.
More information about the whatwg