--- a/user-interface-safety.html Wed Nov 07 12:36:34 2012 -0500
+++ b/user-interface-safety.html Mon Nov 19 16:30:24 2012 -0800
@@ -14,7 +14,7 @@
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
// Member-SUBM
- specStatus: "ED",
+ specStatus: "FPWD",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "User Interface Safety",
@@ -52,6 +52,7 @@
company: "Invited Expert", companyURL: "" },
{ name: "David Lin-Shung Huang", url: "mailto:linshung.huang@sv.cmu.edu",
company: "Carnegie Mellon University", companyURL: "http://www.cmu.edu/" },
+ { name: "Tobias Gondrom", url: "mailto:tobias.gondrom@gondrom.org", company: "Invited Expert" },
{ name: "Brad Hill", url: "mailto:bhill@paypal-inc.com",
company: "PayPal Inc.", companyURL: "https://www.paypal.com/" },
],
@@ -80,7 +81,20 @@
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
- wgPatentURI: "http://www.w3.org/2004/01/pp-impl/49309/status"
+ wgPatentURI: "http://www.w3.org/2004/01/pp-impl/49309/status",
+
+
+ // local bibliography
+ localBiblio: {
+"CSP" : "B. Sterne and A. Barth <a href=\"http://www.w3.org/TR/CSP/\"><cite>Content Security Policy 1.0</cite></a>. W3C Candidate Recommendation. (Work in progress.) URL: <a href=\"http://www.w3.org/TR/2012/CR-CSP-20121115/\">http://www.w3.org/TR/2012/CR-CSP-20121115/</a>",
+"XFRAMEOPTIONS" : "D. Ross and T. Gondrom, IETF <a href=\"http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01\"><cite>HTTP Header X-Frame-Options</cite></a>. Internet Draft. (Work in Progress.) URL: <a href=\"http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01\">http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01</a>",
+"CLEARCLICK" : "G. Maone <a href=\"http://noscript.net/downloads/ClearClick_WAS2012_rv2.pdf\"><cite>ClearClick: Effective Client-Side Protection Against UI Redressing Attacks</cite></a>. (Work in progress.) URL: <a href=\"http://noscript.net/downloads/ClearClick_WAS2012_rv2.pdf\">http://noscript.net/downloads/ClearClick_WAS2012_rv2.pdf</a>",
+"UIREDRESS" : "M. Zalewski <a href=\"http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_page_mashups_(UI_redressing)\"><cite>Browser Security Handbook, part 2</cite></a>. URL: <a href=\"http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_page_mashups_(UI_redressing)\">http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_page_mashups_(UI_redressing)</a>",
+"FRAMEBUSTING" : "Boneh, et al. <a href=\"http://seclab.stanford.edu/websec/framebusting/\"><cite>Busting frame busting: a study of clickjacking vulnerabilities at popular sites</cite></a>. URL: <a href=\"http://seclab.stanford.edu/websec/framebusting/\">http://seclab.stanford.edu/websec/framebusting/</a>",
+"INCONTEXT" : "Lin-Shung Huang, et al. <a href=\"https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final39.pdf\"><cite>Clickjacking:Attacks and Defenses</cite></a> published in the 21st USENIX Security Symposium Proceedings. URL: <a href=\"https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final39.pdf\">https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final39.pdf</a>"
+ }
+
+
};
</script>
</head>
@@ -96,17 +110,16 @@
</section>
<section id=sotd>
-<p>This is the First Public Working Draft of the User Interface Safety Directives for
-Content Security Policy.
-[<cite><a class="bibref" rel="biblioentry" href="#bib-XXX">CSP</a></cite>]
+<p>This is the First Public Working Draft of the User Interface Safety
+Directives for Content Security Policy. [[!CSP]]
<p>Portions of the technology described in this document were originally
developed as part of <code>X-Frame-Options</code>
-[<cite><a class="bibref" rel="biblioentry" href="#bib-XXX">XFRAMEOPTIONS</a></cite>],
+[[XFRAMEOPTIONS]],
the ClearClick module of the Mozilla Firefox add-on NoScript,
-[<cite><a class="bibref" rel="biblioentry" href="#bib-XXX">CLEARCLICK</a></cite>]
+[[CLEARCLICK]]
and in the InContext system implemented experimentally in Internet Explorer
-[<cite><a class="bibref" rel="biblioentry" href="#bib-XXX">INCONTEXT</a></cite>]. </p>
+[[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
@@ -123,9 +136,7 @@
<p>This document defines User Interface Safety directives for Content Security
Policy, a mechanism web applications can use to mitigate some of the risks
-of User Interface (UI) Redressing
-[<cite><a class="bibref" rel="biblioentry" href="#bib-XXX">UI-REDRESS</a></cite>]
-and Clickjacking [<cite><a class="bibref" rel="biblioentry" href="#bib-XXX">CLICKJACKING</a></cite>]
+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
@@ -136,13 +147,12 @@
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
+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 <dfn>origin</dfn> [<em><a
-href="http://tools.ietf.org/html/draft-ietf-websec-origin">ORIGIN</a></em>]
+granularity of an <dfn>origin</dfn> [[!ORIGIN]]
but may be more granular in future versions of the core Content Security Policy.
</p>
<p>Application authors SHOULD transmit the directives in this specification
@@ -155,8 +165,7 @@
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
-[<cite><a class="bibref" rel="biblioentry" href="#bib-XXX">FRAMEBUSTING</a></cite>]
+<p>Existing anti-clickjacking measures including frame-busting [[FRAMEBUSTING]]
codes and <code>X-Frame-Options</code> cannot be used to protect resources that
are intended to be embedded by arbitrary origins, and are insufficient to
defend against timing-based attacks involving multiple windows instead of multiple
@@ -289,18 +298,13 @@
<section>
<h3><code>frame-options</code></h3>
-<p class="issue">The functionality described in this directive is
-currently defined by <a href="http://tools.ietf.org/html/draft-ietf-websec-frame-options-00">
-http://tools.ietf.org/html/draft-ietf-websec-frame-options-00</a>, managed by the IETF
-<a href="http://tools.ietf.org/wg/websec/">Websec WG</a>. Movement of the definition of this feature to the current document has not been
-resolved and it may be removed from a future version.</a>
<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 to avoid many UI Redressing attacks by ensuring
-they are not embedded into other sites.
+Resources can use this directive to avoid many UI Redressing attacks by ensuring
+they are not embedded into potentially hostile contexts.
The syntax for the name and value of the directive are described by the following ABNF grammar:</p>
@@ -376,9 +380,8 @@
in the form of space-separated <code>option-name=option-value</code> pairs. </p>
<p class="issue">
-Also removed setting of <code>unsafe</code> attribute from the enforced directive
-because the event should be cancelled. Do we want to raise another type of event
-or allow a callback to be specified when an action is blocked?
+The <code>unsafe</code> attribute is not defined for the enforced directive
+because the event should be cancelled. Do we want to raise another type of event or allow a callback to be specified when an action is blocked?
</p>
<pre>
@@ -448,7 +451,7 @@
<p>The intersection of the computed rectangle with the bounding rectangle of the document's body
should be used as the reference area for the screenshot comparison check explained in the
<a href="#heuristic">Input Protection Heuristic</a> section, unless the UI event's target or one of its DOM ancestors match a
-<code>input-protection-selector</code> directive set in the same policy.</p>.
+<code>input-protection-selector</code> directive set in the same policy.</p>
<p>If the <code>input-protection-clip</code> directive is not set or provides an invalid value, the whole bounding rectangle
of the document's body must be used as the reference area for the screenshot comparison,
unless an <code>input-protection-selectors</code> directive is set in the same policy.</p>
@@ -519,16 +522,19 @@
Content Security Policy to <em>prepare a violation report</em>:</p>
</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>: [RFC4627]</p>
+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, add the
following keys and values:</p>
<ul><dl>
- <dt>ancestor-chain</dt>
- <dd>An ordered array containing all <code>host-source</code>
- <dfn>ancestors</dfn> of the protected resource. </dd>
- <p class="issue">Do not modify this to <code>source-expression</code> even if the directive is changed to reflect this, except from the same origin, otherwise information disclosure vulnerability.</p>
+ <dt>frame-options</dt>
+ <dd><em>No value.</em></dd>
+ <p class="issue">
+We cannot send the ancestor stack and origins without going outside what
+is currently allowed by the Same Origin Policy. Is there a safe way
+to provide more meaningful information?
+</p>
</dl></ul>
<p>If the violation is of the <code>input-protection</code> directive, add
@@ -539,8 +545,11 @@
<dd>The <code>type</code> attribute of the <code>UIEvent</code> that was blocked by policy.</dd>
<dt>touch-event</dt>
- <dd>A <dfn>boolean</dfn> indicating whether the event blocked by policy was a <dfn>Touch Event</dfn> [REF].</dd>
+ <dd>A <dfn>boolean</dfn> indicating whether the event blocked by policy was a <dfn>Touch Event</dfn> [[TOUCH-EVENTS]].</dd>
+<p class="issue">
+Need to harmonize with the new Pointer Events WG specs.
+</p>
<dt>client-height</dt>
<dd>The <code>document.documentElement.clientHeight</code> property
as defined in <em>TODO</em>.</dd>
@@ -572,7 +581,7 @@
<ul><dl>
<dt>blocked-target-xpath</dt>
- <dd>An XPath [REF] expression that returns the target <code>Element</code> of the <code>UIEvent</code>
+ <dd>An XPath [[!XPATH]] expression that returns the target <code>Element</code> of the <code>UIEvent</code>
that was blocked by policy. <em>TODO: describe the algorithm to do this here</em></dd>
</dl></ul>
@@ -585,7 +594,7 @@
<h2 id="sec-api">DOM interface</h2>
<p>This specification introduces a new attribute for the <code>UIEvent</code>
-interface introduced in DOM Level 2. </p>
+interface introduced in DOM Level 2. [[!DOM-LEVEL-2-EVENTS]]</p>
<section>
<h3><code>unsafe</code> attribute for the <code>UIEvent</code> interface</h3>
<dl>
@@ -683,6 +692,8 @@
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.
+ <p class="issue"> We should define terms here - e.g. "control image", "user image", to refer
+ to elsewhere consistgently</p>
<!-- 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.
@@ -798,13 +809,6 @@
of visual content made by the user agent or user-installed plugins SHOULD NOT cause the
<code>input-protection</code> heuristic to be triggered.</p>
-<p>The use of assistive technologies (such as screen magnifiers
-or color and contrast modifications to the display) MUST NOT cause
-the <code>input-protection</code> heuristic to be triggered. User
-agents that implement portions of that heuristic using
-operating system functionality may need to detect the use of
-such technologies and explicitly disable enforcement of this
-directive.</p>
<p>Many UI Redressing and Clickjacking attacks rely on exploiting specific features of user agents, such as repositioning of the browsing window, hiding or creating fake cursors, and script-driven scrolling and content repositioning. Not all attacks apply to all user agents in all contexts. User agents are free to optimize or not implement suggested heuristics when they do not apply, for example:
<ul>
@@ -820,7 +824,7 @@
permissive with user agents that implement UI Safety directives. User agents
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.
+presented in combination with UI Safety directives in a Content Security Policy.
For example, a browsing environment that deliberately chooses not to implement
UI Safety features because they interfere with assistive technologies SHOULD NOT deny
users access to resources on this account. User agents taking this stance SHOULD
@@ -848,6 +852,38 @@
rate of false positives, and perhaps to build a compatibility opt-out list of
sites or resources to further reduce the false positive rate.</p>
+<section>
+<h3>Accessibility Technologies</h3>
+<p>Certain classes of accessibility technologies such as
+screen readers will provide strong defenses against many classes
+of UI Redressing attacks by presenting the content to the user
+in a manner not subject to interference. Such user agents
+SHOULD set the <code>unsafe</code> attribute of the <code>UIEvent</code>
+interface as this may be interrogated by client applications doing
+feature detection, and SHOULD ignore <code>X-Frame-Options</code>
+headers when presented in combination with UI Safety directives in a
+Content Security Policy.</p>
+
+<p>Use of accessibility technologies MUST NOT cause
+the <code>input-protection</code> heuristic to be triggered.
+Accessibility technologies that modify the appearance of a resource,
+such as screen magnifiers or color and contrast modifications to the
+display have the potential to interfere with the <strong>obstruction
+check</strong>if not applied in a consistent manner to both the
+<strong>user image</strong> and <strong>control image</strong>.
+To prevent this inteference, user agents SHOULD apply accessibility
+transformations to the <strong>control image</strong>. If a user
+agent is able to detect that accessibility technologies are in use
+that cannot be applied uniformly as part of the <strong>obstruction
+check</strong>, the check MUST be disabled.</p>
+
+<p>User agents SHOULD provide a means for the user to manually disable
+enforcement of the <strong>Input Protection Heuristic</strong> if it
+interferes with their chosen accessibility technologies.</p>
+
+</p>
+</section>
+
</section><section>
<h2>Implementation Considerations for Resource Authors</h2>