Subject: [websec] comments on -frame-options and -x-frame-options drafts

From: Chris Weber <[email-masked]>
Date: Wed, 18 Apr 2012 17:27:49 -0700

Sending this with a new subject as I think my comments could have been
better placed.

I have one nit with these documents - the way they bring 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 documents 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