Re: [whatwg] Clickjacking and CSRF
On Fri, 20 Feb 2009 19:36:47 +0100, Bil Corry b...@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. -- Sigbjørn Vik Quality Assurance Opera Software
Re: [whatwg] Clickjacking and CSRF
On Mon, 23 Feb 2009 14:23:40 +0100, Giorgio Maone g.ma...@informaction.com wrote: On Fri, 20 Feb 2009 19:36:47 +0100, Bil Corry b...@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. Yes, a domain wide policy file might be good to have, but it could not entirely replace having a header settable for a single resource, not all web authors have access to the root, so it would have to come as an addition, an optional replace. If a domain wide policy file is used, it would make sense to have it in a format which can be distributed and applied locally, so users can patch web sites that don't do it themselves. ABE looks like a good candidate for all of this. A good candidate might also have to be implementable by the server, so that a server can look at the policy file, and determine which headers to send for any particular resource, including which resources to send no headers for at all. Presumably ABE would work for that too. -- Sigbjørn Vik Quality Assurance Opera Software
[whatwg] Clickjacking and CSRF
, the browser will use that setting for all requests, if not set, it will check individual resources with a pre-flight request. This would make it easy for legacy servers to become compatible. Note that W3Cs cross-site XHR has opted not to use domain wide policy files, that solution is not applicable to CSRF in general though, as it does not need to take legacy servers into account. To allow double requests, it would be possible to extend with a server header telling a browser that the information is the same whether the user is logged in or not, eliminating the need for a second, authenticated, request. This is suggestion, please tear it apart and use the best pieces of it to build something better. [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-February/018586.html -- Sigbjørn Vik Security Team Opera Software
Re: [whatwg] Clickjacking and CSRF
On Fri, 20 Feb 2009 16:00:09 +0100, Giorgio Maone g.ma...@informaction.com wrote: Sigbjørn Vik wrote, On 20/02/2009 15.46: There is currently little protection against clickjacking, the x-frame-options is the first attempt. Nope, it's the second and weakest: http://hackademix.net/2008/10/08/hello-clearclick-goodbye-clickjacking/ http://noscript.net/faq#clearclick I stand corrected. I was thinking too narrow-mindedly, from a browser vendor perspective. Frame busting is another existing alternative. -- Sigbjørn Vik Quality Assurance Opera Software
