Major update to input-protection and some typo fixes
authorGiorgio Maone <giorgio@maone.net>
Sun, 16 Sep 2012 02:07:01 +0200
changeset 7 4076f83eb939
parent 6 5606233e4ede
child 8 da6b42199939
Major update to input-protection and some typo fixes
user-interface-safety.html
--- a/user-interface-safety.html	Mon Sep 10 18:59:54 2012 -0700
+++ b/user-interface-safety.html	Sun Sep 16 02:07:01 2012 +0200
@@ -48,7 +48,7 @@
         // editors, add as many as you like
         // only "name" is required
         editors:  [
-          { name: "Giorgio Maone", url: "mailto:[email protected]",
+          { name: "Giorgio Maone", url: "http://maone.net/",
             company: "Invited Expert", companyURL: "" },
           { name: "David Lin-Shung Huang", url: "mailto:[email protected]",
             company: "Carnegie Mellon University", companyURL: "http://www.cmu.edu/" },
@@ -129,13 +129,16 @@
 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 from where an application
-can load resources.  This document defines directives to restrict display of
-or user interactin with a resource when it is in an embedded context.
-A user agent may implement the core directives of CSP independently from the
+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 uses the
 policy conveyance and reporting mechanisms described in CSP. 
-The intrepretation of terms imported into this document from CSP may
+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 <dfn>origin</dfn> [<em><a
@@ -210,7 +213,7 @@
 on a <em>per-resource representation basis</em>. Specifically, when a user
 agent receives a policy along with the representation of a given resource, that
 policy applies to <em>that resource representation only</em>. This document
-often referes to that resource representation as the <dfn>protected
+often refers to that resource representation as the <dfn>protected
 resource</dfn>. </p>
 
 <p>A server transmits its security policy for a particular resource as a
@@ -430,7 +433,7 @@
 are delivered to the resource. </p>
 
 <p>If set as part of a <code>Content-Security-Policy</code>, triggering of
-the hueristic should cancel delivery of the UI event to the target and
+the heuristic should cancel delivery of the UI event to the target and
 cause a violation report to be sent.  If set as part of a 
 <code>Content-Security-Policy-Report-Only</code>, triggering of the heuristic 
 should result in the event being delivered with the <code>unsafe</code> 
@@ -494,35 +497,37 @@
 </p>
 
 <pre>directive-name    = "input-protection"
-directive-value   = ["element-id=" name] ["ui-height=" num-val] ["ui-width=" num-val] ["ui-delay=" num-val] ["tolerance=" num-val]</pre>
+directive-value   = ["element-id=" name] ["ui-height=" num-val] ["ui-width=" num-val] ["display-time=" num-val] ["tolerance=" num-val]</pre>
 
 <p>If the policy does not contain a value for this directive
 or any of the optional values are absent, the user agent should apply default
 values as described in <a href="">Section XXX</a>. A user agent MAY ignore any
 or all values in <code>input-protection</code>. </p>
 
-<p><code>element-id</code> is the name of a user interface element in the DOM.
+<p><code>element-id</code> is the id attribute of a user interface element in the DOM.
 If the policy does not contain an explicit <code>element-id</code>, the user
 agent should apply protection to the <code>body</code> element of the resource.
 </p>
 
 <p><code>ui-height</code> is a numeric value that defines the height of the
-<!--user interface element-->viewing area to be used for performing the screenshot comparision.
+<!--user interface element-->viewing area to be used for performing the screenshot comparison.
 </p>
 
 <p><code>ui-width</code> is a numeric value that defines the width of the 
-<!--user interface element-->viewing area to be used for performing the screenshot comparision. </p>
+<!--user interface element-->viewing area to be used for performing the screenshot comparison. </p>
 
-<p><code>ui-delay</code> is a numeric value that specifies the delay time, in
-milliseconds, used in the input protection heuristic.</p> 
+<p><code>display-time</code> is a numeric value from 0 to 10000 that specifies how long, in
+milliseconds, the screen area containing the protected user interface
+must have been displayed continuously unchanged when the event is processed.
+If not specified, it defaults to 800. If a value out of the range stated above is specified, it defaults to the nearest
+value between the lower and the higher bounds.
+</p> 
 
-<p class="issue">Delay after display, or delay after mouseover?</p>
-
-<p><code>tolerance</code> is a numeric value from 0-99 that defines the
+<p><code>tolerance</code> is a numeric value from 0 to 99 that defines the difference
 threshold at which the screenshot comparison procedure of the input protection
 heuristic triggers a violation. A value of 0 indicates that no difference
 between the two images is permitted. A value of 99 provides little to no
-practical protection. </p>
+practical protection. Defaults to 0.</p>
 
 </section>
 
@@ -540,12 +545,12 @@
 by Content Security Policy. [REF - fwd compatible]</p>  
 
 <p>The core Content Security Policy specification provides directives to
-rectrict from where external content may be loaded.  As such, violation
+restrict from where external content may be loaded.  As such, violation
 reports include a <dfn>blocked-uri</dfn> key/value pair that specifies the
 attempted resource load that was blocked by the policy.</p>
 
 <p>As this is not applicable to the directives in this document, the
-following additional steps MUST be added to the algoritihm defined in
+following additional steps MUST be added to the algorithm defined in
 Content Security Policy to <em>prepare a violation report</em>:</p>
 
 </p>In step 1, when preparing the JSON object <em>violation-object</em>,
@@ -589,7 +594,7 @@
 
 <p class="issue">What standard defines these attributes?</p>
 
-<p>If the target of an <code>UIEvent</code> which triggers an <code>input-protection</code> violoation has an explictly-set <code>id</code> attribute:
+<p>If the target of an <code>UIEvent</code> which triggers an <code>input-protection</code> violation has an explictly-set <code>id</code> attribute:
 
 
 <ul><dl>
@@ -645,7 +650,7 @@
 <h2>Input Protection Heuristic</h2>
 <section class=informative>
 <p>This section is non-normative. The algorithm described here can be
-implemented mostly in terms of HTML5 constructs, but requries the ability to
+implemented mostly in terms of HTML5 constructs, but requires the ability to
 monitor and intercept actions in the rendering of a resource and delivery of
 events to that resource. User agents may apply equivalent protections using
 means more optimized for their implementation details, may ignore
@@ -653,56 +658,42 @@
 attack, (e.g. the cursor sanity check in a touch-only environment) or may implement
 some features in terms of the underlying operating system or platform rather
 than directly in the user agent.</p>
-
-<h3>Algorithm Description</h3>
+<ul>
+<li><h4>Preparation</h4>    
 <ol>
-  <li><strong>Listener registration</strong> - Register a "global" capturing
+  <li><strong>Listener registration</strong> - On the topmost window, register a "global" capturing
     event listener for mouse button, tapping, keyboard, drag &amp; drop and
     focus events, which must be guaranteed to run before any other event
     handler of the same kind and therefore be able to prevent any event from
-    being handled by the content, if needed. <em>CBC: in order to guarantee the
-    "first to process' event listener requirement and reduce registration
-    overhead, ClearClick adds its listener to the Mozilla-specific DocShell
-    object which is the immediate container of the topmost DOM window per any
-    given tab. A crossbrowser approach likely to work is registering the
-    listener on the topmost DOM window itself before any script has a chance to
-    run.</em> </li>
-  <li><strong>Fast-track bypass</strong> - Whenever the listener is called,
-    check whether the event target or its owner document are flagged as
-    "unlocked". If either is, return early. <em>CBC: ClearClick uses an expando
-    property to flag DOM nodes and windows, relying on a feature of Mozilla's
-    chrome-exposed DOM wrappers which prevents content from seeing or tamper
-    with expando properties set by privileged code. Other browsers may require
-    different procedures to safely annotate documents and other DOM nodes.
-    Furthermore, this and most of the remaining steps assume our listener can
-    examine and manipulate any DOM node or window independently from its
-    origin, bypassing SOP. This privilege should be granted by the listener
-    having being registered by privileged (browser extension) code.</em> </li>
-  <li><strong>Parent chain check</strong> - Check whether the event target is
-    either a child of a nested document or a plugin content element (EMBED,
-    APPLET or OBJECT). If it is not, or it is an embedded document belonging to
-    a same-site parent chain (i.e. it and all its parents are from the same
-    origin), flag the document as "unlocked" and return. Notice that the
-    original Clickjacking demo by Hansen &amp; Grossman worked despite the
-    Flash content being served same-site: since plugins may follow
-    type-specific origin policies, we never return early at this stage when
-    interacting with plugin content, even if embedded same-site.</li>
-  <li><strong>Rapid fire check</strong> - Check whether the previous event we
-    had observed was the same type on a document from a different origin,
-    happened within the past 800ms (quarantine time). If it was, we assume a
-    "Rapid fire" attack (e.g. the user has been tricked into repeatedly click
-    on the same or a predictable location in a fast succession while the
-    document gets changed under his mouse pointer) : halve the quarantine time
-    and go to step 8. If next interaction happens with a different document,
-    the quarantine time will be reset.</li>
-  <li><strong>Cursor sanity check</strong> - By querying computed-style with
+    being handled by the content, if needed.</em> </li>
+  <li><strong>Display changes tracking</strong> - whenever a repaint occurs in the topmost window or in one of its descendants,
+      create a record containing a weak reference to the document causing the repaint, the screen coordinates of the
+      regions being repainted and a timestamp detailing when the repaint occurred, and add this record
+      to a screen-global list named "Display Changes List".
+      Records older than the maximum value for <code>input-protection-hints</code>'s <code>display-time</code>, or whose document
+      is not alive anymore (the weak reference is possibly null), can be discarded.
+  </li>
+</ol>
+</li>
+<li><h4>UI Event handling</h4>
+<ol>
+  <!-- 1 --> <li><strong>Timing attacks countermeasure</strong> -
+  check whether the "Display Change List" contains a record whose repainted regions
+  intersect with the protected UI elements <em>and</em> whose repaint-causing
+  document is <em>different</em> than the protected one. If this is true, hinting at
+  a recent change (more recent than the <code>display-time</code> value) in the way the protected UI is displayed, with causes external to the UI
+  itself (e.g. an overlapping element in an ancestor document or a
+  floating window being suddenly moved away), assume a timing attack is happening
+  and jump to step 4.
+  </li>
+  <!-- 2 --> <li><strong>Cursor sanity check</strong> - By querying computed-style with
     the ":hover" pseudo-class on the element (if the target is plugin content)
     or on the host frame element and its ancestors (if the target is a nested
     document), check whether the cursor has been hidden or changed to an
-    possibly attacker-provided bitmap: if it has, go to step 7. This provides
+    possibly attacker-provided bitmap: if it has, jump to step 4. This provides
     protection against "Phantom cursor" attacks, also known as
   "Cursorjacking".</li>
-  <li><strong>Obstruction check</strong> - By using an offscreen HTML 5 canvas
+  <!-- 3 --> <li><strong>Obstruction check</strong> - By using an off-screen HTML 5 canvas
     element, we take two reasonably sized (300x200 on average, but growing or
     shrinking depending on document's inherent size and viewport constraints
     and hints provided by the <code>ui-height</code> and <code>ui-width</code>
@@ -712,23 +703,28 @@
     the other from the topmost window's. In the plugin content case, we ensure
     the former "screenshot" contains the element itself only. If the number of
     the pixels which are different between the screenshots don't exceed a
-    certain configurable tolerance rate (default 18%, or as set by the
-    <code>tolerance</code> property of <code>input-protection-hints</code>),
+    certain configurable percentual threshold set by the
+    <code>tolerance</code> property of <code>input-protection-hints</code>,
     return. Otherwise we tentatively assume the DOM element our user is
     interacting with has been obstructed or obscured by a UI Redressing
-    attempt. 
-    
-    <p><em>CBC: the screenshots are taken by using the
-    CanvasRenderingContext2D.drawWindow() method11, which is a
+    attempt.
+    <em>Existent implementation note</em>: in NoScript's ClearClick,
+    the screenshots are taken by using the CanvasRenderingContext2D.drawWindow() method, which is a
     Mozilla-proprietary extension of the HTML 5 Canvas API available to
     privileged code only, allowing the content of DOM windows to be drawn on a
     canvas surface exactly as rendered on the screen. The rest of this phase
     relies on cross-browser canvas features, instead, such as pixel grabbing
-    and data URL serialization.</em></p>
-
+    and data URL serialization.
+  <!-- 4--> <li><strong>Violation management</strong> -
+   If in report-only mode, turn the <code>unsafe</code> property of the event been handled to true and let the
+   event processing continue. Otherwise, prevent the event from reaching its target.
+   Create and send a violation report if a valid report-uri has been specified.
+  </li>
    
    </li>
 </ol>
+</li>
+</ul>
 </section></section>
 <section>
 <h2>Script Interfaces</h2>
@@ -811,9 +807,9 @@
 embedding context of the resource is hostile, and B might be able to attack A.
 </p>
 
-<p>Both <code>frame-ancestors</code> and <code>frame-options</code> provide deterministic protections within a single browsing window, but may not provide full protection in environments where multiple browser windows may overlap and be programatically 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>Both <code>frame-ancestors</code> and <code>frame-options</code> provide 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 hueristic 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>
+<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>
 
 
 
@@ -845,7 +841,7 @@
 <p>Some resource owners may specify a restrictive policy forbidding embedding in
 user agents that only understand <code>X-Frame-Options</code> but be more 
 permissive with user agents that implement UI Safety directives.  User agents
-that are aware of but choose not to implement any of the hurestics in this
+that are aware of but choose not to implement any of the heuristics in this
 document MAY still ignore <code>X-Frame-Options</code> when
 presented in combination with UI Safety directives in a Content-Security-Policy.
 For example, a browsing environment that deliberately chooses not to implement 
@@ -862,14 +858,14 @@
 calculate the user's view for the <strong>obstruction check</strong> phase of
 the heuristic.</p>
 
-<p>While this document describes a mechansim for resource authors to opt-in to 
+<p>While this document describes a mechanism for resource authors to opt-in to 
 User Interface Safety protections, user agents MAY choose to opt-in all resources
 to <code>input-protection</code> by default, or provide users with an option
 to enable such protections for all resources.</p>
 
 <p>In support of enabling default protection, user agents MAY, with appropriate
 user consent and privacy protections, gather large-scale data on when the
-heuristic would have been triggered, if it had been abled, for various values
+heuristic would have been triggered, if it had been enabled, for various values
 of the configurable hint parameters.  Such data would allow the user agent to
 determine what default settings can provide broad protection with an acceptable
 rate of false positives, and perhaps to build a compatibility opt-out list of
@@ -878,7 +874,7 @@
 </section><section>
 <h2>Implementation Considerations for Resource Authors</h2>
 
-<p>When possible, resource authors SHOULD make use of violation reports and the <code>unsafe</code> attribute to apply additional security measures in the application or during back-end processing.  Real-time meaures in the application might include requiring completion of a CAPTCHA [<em>REF</em>] or responding to an out-of-band confirmation when the UI Safety heuristic is triggered.  Example back-end measures might include increasing a fraud risk score for individual actions that trigger or targets accounts/resources that frequently trigger UI Safety hueristics.  To be able to do this effectively, it is likely necesssary to encode into the <code>report-uri</code> a unique identifier that can be correlated to the authenticated user and the action they are taking.</p>
+<p>When possible, resource authors SHOULD make use of violation reports and the <code>unsafe</code> attribute to apply additional security measures in the application or during back-end processing.  Real-time measures in the application might include requiring completion of a CAPTCHA [<em>REF</em>] or responding to an out-of-band confirmation when the UI Safety heuristic is triggered.  Example back-end measures might include increasing a fraud risk score for individual actions that trigger or targets accounts/resources that frequently trigger UI Safety heuristics.  To be able to do this effectively, it is likely necessary to encode into the <code>report-uri</code> a unique identifier that can be correlated to the authenticated user and the action they are taking.</p>
 
 </section><section>
 <h2>IANA Considerations</h2>