[whatwg] Clickjacking and CSRF

[Giorgio Maone]

> 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;
>>> allow=*.opera.com,example.net;
>>> This incorporates the idea from the IE team, and extends on it.
>>
>> Have you taken a look at ABE?
>>
>>     http://hackademix.net/wp-content/uploads/2008/12/abe_rules_03.pdf
>
> 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. 
ABE is meant to be configured in 3 ways:

   1. With user-provided rules, deployed directly client-side
   2. With community-provided rules, downloaded periodically from a
      trusted repository
   3. As a site-wide policy deployed on the server side in a single
      file, much like crossdomain.xml

See http://hackademix.net/2008/12/20/introducing-abe/ and especially 
this http://hackademix.net/2008/12/20/introducing-abe/#comment-10165 
comment about site-provided rules and merging.
--
Giorgio

Sigbjørn Vik wrote, On 23/02/2009 11.42:
> 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;
>>> allow=*.opera.com,example.net;
>>> This incorporates the idea from the IE team, and extends on it.
>>
>> Have you taken a look at ABE?
>>
>>     http://hackademix.net/wp-content/uploads/2008/12/abe_rules_03.pdf
>
> 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?
>>
>>     http://www.w3.org/TR/access-control/#cross-site2
>
> 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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090223/3907a10b/attachment-0001.htm>