To add some context to the Frame-Options and CSP UI Safety directives discussion, here's my summary of the current and historical proposals:
HTML-based web applications can embed or "frame" other web applications. Unfortunately, if done in an unrestricted fashion, this can lead to various attacks, both on the embedded/framed application, or on the framing application (the "ancestor"). There are various extant, similar approaches to mitigating this, both deployed and proposed, and their names vary somewhat. This message is an attempt to list all the various names of, and briefly summarize, each approach. The approaches are: "X-Frame-Options" HTTP response header field "frame-ancestors" Content Security Policy directive "Frame-Options" HTTP response header field "embed-ancestors" of Content Security Policy UI Safety directives Details: X-Frame-Options: This was the first widely adopted solution to clickjacking, a header to instruct user agents to disallow embedding a resource in an iframe, or only allow it in top-level resources of the same origin. Developed independently by Microsoft in Internet Explorer, support for the header has been widely implemented in other browsers. https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ tracks the status of an effort at the WebSec WG to document the existing behavior of applications setting and user agents supporting X-Frame-Options in an informational-track I-D. (note: this specification is distinct from the "Frame-options" spec discussed below) In this draft, the supported parameters are: "DENY", "SAMEORIGIN" and "ALLOW-FROM". It's behaviors are specified to apply to content embedded through the iframe, frame, and object tags, as well as plugins that "appear essentially as frames". There is some risk of confusion induced by the fact that the draft includes the "ALLOW-FROM" parameter, which was added after the original X-Frame-Options "specification" (in a couple of posts on blogs.msdn.com) and is not uniformly implemented in the user agent population. Current implementations also do not consider "port" as a component of the origin, conflicting with [RFC6454]. Although the draft primarily specifies behavior implemented by web user agents regarding HTML rendering, it was accepted by the WebSec WG of the IETF rather than be developed in the W3C as the goal is primarily to document existing deployed behavior. Content Security Policy "frame-ancestors" directive: Early drafts of the W3C Content Security Policy specification proposed a "frame-ancestors" directive with functionality substantially similar to the "ALLOW-FROM" feature of X-Frame-Options, but required that the check be applied to all embedding ancestor resources, not just the origin of the top-level window. This directive was dropped from the CSP 1.0 as it was felt to be substantially different in character from the other directives in that specification. Frame-Options: https://datatracker.ietf.org/doc/draft-ietf-websec-frame-options/ tracks a standards-track effort in the IETF WebSec WG to update and remove the "X-" prefix from X-Frame-Options. The behavior specified is substantially similar with the addition of an optional "AllAncestors" flag which requires the same behavior as the "frame-ancestors" directive of CSP. Content Security Policy UI Safety directives: http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html is the latest editors' draft for a new set of directives for the Content Security Policy header that specify heuristic protections for clickjacking and some other classes of UI redressing. It has been proposed that the "frame-ancestors" directive, which was dropped from CSP 1.0, should be revived as "embed-ancestors" as part of the set of UI Safety directives, and that it should obsolete X-Frame-Options, that is, user agents which understand UI Safety directives should ignore X-Frame-Options if any such directives are found. For example, some web application authors may wish to allow embedding of resources if and only if the heuristic protections of the other UI Safety Directives are understood, and fall back to an X-Frame-Options "DENY" or "SAMEORIGIN" policy otherwise. -Brad Hill _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
