On 4/15/12 3:12 PM, Alexey Melnikov wrote: >> Dear WG participants, >> draft-gondrom-frame-options-02.txt and >> draft-gondrom-x-frame-options-00.txt (and their earlier version) were >> discussed in a couple of WG face-to-face meetings. I believe both of the >> documents are in scope for the WG Charter and I think there is support >> for working on them. >> >> As both of these documents are co-edited by Tobias, I will be judging >> consensus on them. draft-gondrom-frame-options is targeted to become a >> Proposed Standard, while draft-gondrom-x-frame-options will be an >> Informational document (as it documents existing header field). So I >> would like to start a one week acceptance call for these documents as >> WebSec WG documents. Please send me your objections or statements of >> support directly to me or to the mailing list before midnight GMT+1 on >> April 23rd. I have one nit with this document - the way it brings Cross Site Request Forgery (CSRF) into the discussion and positions X-Frame-Options as a "sometimes" mitigation for CSRF. We could probably agree that wording such as "In some forms of Clickjacking and CSRF an attacker tricks a user into clicking..." sufficiently limits the scope of the context. However I feel that CSRF in general is just completely out of scope - there are many attacks that might leverage framing after all. I also worry that some people may be led to believe that the X-Frame-Options header provides general protection from CSRF when that's absolutely not the case.
When Microsoft released this functionality with IE8, it was positioned as a protection against framing attacks, or Clickjacking, and not CSRF. I believe that's how many of us in the security community still view it - it's only a protection against CSRF in cases where framing is required to execute the CSRF attack. The two (Clickjacking and CSRF) can only be linked in that and similar contexts. I suggest that references to CSRF protection be removed to avoid confusion or that the wording reflect this narrow scope of the CSRF-protection (preferably the former). After all, CSRF is just one example of many other attacks that could leverage framing - e.g. we could include answering CAPTCHAs, certain forms of self-side XSS, and even information disclosure as equivalent forms of attack (like CSRF) that might leverage framing. Can we keep the document focused on the primary design goal - controlling/preventing framing - and avoid lumping in other forms of attack that might piggyback on such framing? Best regards, Chris Weber _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
