Removed frame-options directive.
authorbhill2
Tue, 18 Feb 2014 15:17:59 -0800
changeset 24 7e6b0d576e07
parent 23 6e5a766786c0
child 25 4a816d0de54e
Removed frame-options directive.
user-interface-safety.html
--- a/user-interface-safety.html	Thu Oct 31 20:39:40 2013 +0000
+++ b/user-interface-safety.html	Tue Feb 18 15:17:59 2014 -0800
@@ -104,17 +104,29 @@
 
 <section id=abstract>
 
-<p>This document defines directives for the Content Security Policy mechanism to declare a set of input protections for a web resource's user interface, defines a non-normative set of heuristics for Web user agents to implement these input protections, and a reporting mechanism for when they are triggered. </p>
+<p>This document defines directives for the Content Security Policy mechanism to
+declare a set of input protections for a web resource's user interface, defines 
+a non-normative set of heuristics for Web user agents to implement these input 
+protections, and a reporting mechanism for when they are triggered. </p>
 
 </section>
 
 
 <section id=sotd>
-<p>This is a Working Draft of the User Interface Security Directives for Content Security Policy. [[!CSP]] 
+<p>This is a Working Draft of the User Interface Security Directives for Content
+Security Policy. [[!CSP]]</p>
 
-<p>Portions of the technology described in this document were originally developed as part of <code>X-Frame-Options</code> [[!RFC7034]], the ClearClick module of the Mozilla Firefox add-on NoScript, [[CLEARCLICK]] and in the InContext system implemented experimentally in Internet Explorer [[INCONTEXT]]. </p>
+<p>Portions of the technology described in this document were originally 
+developed as part of <code>X-Frame-Options</code> [[!RFC7034]], the ClearClick 
+module of the Mozilla Firefox add-on NoScript, [[CLEARCLICK]] and in the InContext
+system implemented experimentally in Internet Explorer [[INCONTEXT]]. </p>
 
-<p>In addition to the documents in the W3C Web Application Security working group, the work on this document is also informed by the work of the <a href="http://tools.ietf.org/wg/websec/">IETF websec working group</a>, particularly that working group's requirements document: <a href="http://tools.ietf.org/id/draft-hodges-websec-framework-reqs">draft-hodges-websec-framework-reqs</a>.  </p>
+<p>In addition to the documents in the W3C Web Application Security working group,
+the work on this document is also informed by the work of the 
+<a href="http://tools.ietf.org/wg/websec/">IETF websec working group</a>, 
+particularly that working group's requirements document: 
+<a href="http://tools.ietf.org/id/draft-hodges-websec-framework-reqs">draft-hodges-websec-framework-reqs</a>.
+</p>
 
  
 
@@ -122,19 +134,50 @@
 </section><section class=informative>
 <h2>Introduction</h2>
 
-<p>This document defines User Interface Security directives for Content Security Policy, a mechanism web applications can use to mitigate some of the risks of User Interface (UI) Redressing [[UIREDRESS]] (AKA "Clickjacking") vulnerabilities that can lead to fraudulent actions not intended by the user. </p>
-
-<p>Content Security Policy (CSP) is a declarative policy that lets the authors (or server administrators) of a web application restrict the behavior of a document, e.g.  the origins where it can load its resources from or the ways it can execute scripts.  This document defines directives to restrict the presentation or the interactivity of a resource when its interaction with the user may be happening in an ambiguous or deceitful context due to the spatial and/or temporal contiguity with other content displayed by the user agent. </p>
-
-<p>A user agent may implement the core directives of CSP independently from the directives in this specification, but this specification requires the policy conveyance and reporting mechanisms described in CSP.  The interpretation of terms imported into this document from CSP may vary depending on the version implemented by the user agent.  For example, a <code>source-expression</code> in Content Security Policy 1.0 is at the granularity of an <code>origin</code> [[!ORIGIN]] but may be more granular in future versions of the core Content Security Policy.  </p>
+<p>This document defines User Interface Security directives for Content Security
+Policy, a mechanism web applications can use to mitigate some of the risks of 
+User Interface (UI) Redressing [[UIREDRESS]] (AKA "Clickjacking") vulnerabilities
+that can lead to fraudulent actions not intended by the user. </p>
 
-<p>Application authors SHOULD transmit the directives in this specification as part of a single, complete Content Security Policy, as indicated by that specification. </p>
+<p>Content Security Policy (CSP) is a declarative policy that lets the authors 
+(or server administrators) of a web application restrict the behavior of a 
+document, e.g.  the origins where it can load its resources from or the ways it 
+can execute scripts.  This document defines directives to restrict the 
+presentation or the interactivity of a resource when its interaction with the
+user may be happening in an ambiguous or deceitful context due to the spatial 
+and/or temporal contiguity with other content displayed by the user agent. </p>
 
-<p>In some UI Redressing attacks (also known as Clickjacking), a malicious web application presents a user interface of another web application in a manipulated context to the user, e.g. by partially obscuring the genuine user interface with opaque layers on top, hence tricking the user to click on a button out of context. </p>
+<p>A user agent may implement the core directives of CSP independently from the 
+directives in this specification, but this specification requires the policy 
+conveyance and reporting mechanisms described in CSP.  The interpretation of 
+terms imported into this document from CSP may vary depending on the version 
+implemented by the user agent.  For example, a <code>source-expression</code> 
+in Content Security Policy 1.0 is at the granularity of an <code>origin</code>
+[[!ORIGIN]] but may be more granular in future versions of the core Content 
+Security Policy.  </p>
 
-<p>Existing anti-clickjacking measures including frame-busting [[FRAMEBUSTING]] codes and <code>X-Frame-Options</code> cannot be used to protect resources where the set of origins that should be allowed and disallowed is unknown, where attacks might come from origins intended to be allowed by a use scenario,  or defend against timing-based attacks involving multiple windows instead of multiple frames.  Frame-busting scripts also rely on browser behavior that has not been engineered to provide a security guarantee.  As a consequence, such scripts may be unreliable if loaded inside a sandbox or otherwise disabled.</p>
+<p>Application authors SHOULD transmit the directives in this specification 
+as part of a single, complete Content Security Policy, as indicated by that 
+specification. </p>
 
-<p>The User Interface Security directives encompass the policies defined in <code>X-Frame-Options</code> and also provide a new mechanism to allow web applications to enable heuristic input protections for its user interfaces on user agents. </p>
+<p>In some UI Redressing attacks (also known as Clickjacking), a malicious web 
+application presents a user interface of another web application in a manipulated 
+context to the user, e.g. by partially obscuring the genuine user interface with
+opaque layers on top, hence tricking the user to click on a button out of context. </p>
+
+<p>Existing anti-clickjacking measures including frame-busting [[FRAMEBUSTING]] 
+codes and <code>X-Frame-Options</code> cannot be used to protect resources where
+the set of origins that should be allowed and disallowed is unknown, where 
+attacks might come from origins intended to be allowed by a use scenario,  or 
+defend against timing-based attacks involving multiple windows instead of multiple
+frames.  Frame-busting scripts also rely on browser behavior that has not been 
+engineered to provide a security guarantee.  As a consequence, such scripts may 
+be unreliable if loaded inside a sandbox or otherwise disabled.</p>
+
+<p>The User Interface Security directives encompass the policies defined in 
+<code>X-Frame-Options</code> and also provide a new mechanism to allow web 
+applications to enable heuristic input protections for its user interfaces on 
+user agents. </p>
 
 <p>To mitigate UI redressing, for example, a web application can request that a user interface element should be fully visible for a minimum period of time before a user input can be delivered. </p>
 
@@ -227,46 +270,15 @@
 
 </section>
 
-</section><section>
+</section>
+
+<section>
 <h2 id="sec-directives">Directives</h2>
 
 <p>This section describes the content security policy directives introduced in
 this specification. </p>
 
 
-<section>
-<h3><code>frame-options</code></h3>
-
-
-<p>The <code>frame-options</code> directive indicates whether the user-agent should embed the resource using a <code>frame</code>, <code>iframe</code>, <code>object</code>, <code>embed</code> or <code>applet</code> tag, or equivalent functionality in non-HTML resources.  Resources can use this directive to avoid many UI Redressing attacks by ensuring they are not embedded into potentially hostile contexts. </p>
-
-<p>The syntax for the name and value of the directive are described by the following ABNF grammar:</p>
-
-<pre>
-directive-name  = "frame-options"
-directive-value = embedding-source-list
-</pre>
-
-<p>Unlike policies defined in Content Security Policy, the <code>frame-options</code> directive is not subject to the <code>default-src</code> directive. If this directive is not explicitly stated in the policy its value is assumed to be <code>"*"</code>.</p>
-
-<p>A host-source value in the embedding-source-list indicates an origin that is a valid <strong>ancestor</strong> for the resource.</p> 
-
-<p>If the directive-value contains the embedding-keyword-source <code>'deny'</code>, the resource cannot be displayed in an embedded context, regardless of the origin attempting to do so, and all other values in the directive are ignored.</p>
-
-<p>If the directive-value contains the embedding-keyword-source <code>'self'</code>, <strong>ancestors</strong> are in the same origin as the protected resource.</p>
-
-
-<section id="multiple-host-source-values"  class=informative>
-<h4>Multiple Host Source Values</h4>
-
-<p>Multiple <code>host-source</code> values are allowed primarily to enable scenarios involving embedded application compoments that are multiple levels below the top-level browsing context.</p>
-
-<p>Many common scenarios for permissioned embedding (e.g. embeddable payment, sharing or social apps) involve potentially many hundreds or thousands of valid <code>host-source</code> values, but it is strongly recommended against accomodating such scenarios with a static <code>frame-options</code> directive listing mulitple values. In such cases it is beneficial to generate this value dynamically, based on an HTTP Referer header or an explicitly passed-in value, to allow only the source(s) necessary for each given embedding of the resource.</p>  
-
-<p>Consider a service providing a payments application at <code>https://payments/makeEmbedded</code>.  The service allows this resource to be embedded by both merchant Alice and merchant Bob, who compete with each other.  Sending 
-<pre>Content-Security-Policy: frame-options https://alice https://bob</pre>
-would allow Bob to re-frame Alice's resource and create fradulent clicks, perhaps discrediting Alice with her customers or the payments service.  If the payments service used additional information (e.g. as part of a URL like <code>https://payments/makeEmbedded?merchant=alice</code>) to send individually-tailored headers listing only the <code>host-source</code> values needed by each merchant, this attack would be eliminated.</p>
-</section>
 </section>
 
 <section id="input-protection">
@@ -427,9 +439,6 @@
 <p>In step 1, when preparing the JSON object <em>violation-object</em>,
 add the following keys and values to the <dfn>csp-report</dfn>: [[!CSP]]</p>
 
-<p>If the violation is of the <code>frame-options</code> directive, no additional processing is required.</p>
-
-
 <p>If the violation is of the <code>input-protection</code> directive, add the following keys and values.  If a value is not set or applicable for the violation (e.g. pointer-height, if the violating event type is not a Pointer Event) the key SHOULD be omitted.
 </P>
 
@@ -532,12 +541,10 @@
 <section>
 
 <dl title="partial interface UIEvent" class="idl">
-  <dt>readonly attribute bool unsafe</dt>
-    <dd>This is a non-configurable boolean property of input event objects. The
-      value <em class="rfc2119" title="should">should</em> be "true" if a
-      violation occurred. The value <em class="rfc2119"
-      title="should not">should not</em> not be set unless triggered by user initiated
-      actions. </dd>
+  <dt>[Unforgeable] readonly attribute bool unsafe</dt>
+    <dd>This is a non-configurable boolean property of input event objects.
+      Set to "true" if a violation of an input-protection directive 
+      violation occurred for the event.</dd>
 </dl>
 
 <p>The <code>unsafe</code> attribute allows web applications to monitor and
@@ -1167,7 +1174,6 @@
 <section id="security-considerations" class=informative>
 <h2>Security Considerations</h2>
 
-<p><code>frame-options</code> provides deterministic protections within a single browsing window, but may not provide full protection in environments where multiple browser windows may overlap and be programmatically closed or moved by malicious content.  These directives SHOULD be deployed in concert with <code>input-protection</code> to provide additional protection in such environments.</p>
 
 <p>UI Redressing and Clickjacking attacks rely on violating the contextual and temporal integrity of embedded content.  Because these attacks target the subjective perception of the user and not well-defined security boundaries, the heuristic protections afforded by the <code>input-protection</code> directive can never be 100% effective for every interface. It provides no protection against certain classes of attacks, such as displaying content around an embedded resource that appears to extend a trusted dialog but provides misleading information.<p>