HTML5 Tracker

Diff (omit for latest revision)
Filter

Short URL: http://html5.org/r/81

SVNBugCommentTime (UTC)
81More security problems with storage areas2006-07-13 07:51
Index: source
===================================================================
--- source	(revision 80)
+++ source	(revision 81)
@@ -13153,6 +13153,47 @@
   trivial to bypass this protection and access the data from any
   path.</p>
 
+
+  <h5>Public storage areas corresponding to hosts</h5>
+
+  <p>If a "<span title="public storage area">public</span>" global
+  storage area corresponds to a host, as it typically does if for
+  private domains with third-party subdomains such as dyndns.org or
+  uk.com, the host corresponding to the "public" domain has access to
+  all the storage areas of its third-party subdomains. In general,
+  authors are discouraged from using the <code
+  title="dom-globalStorage">globalStorage</code> API for sensitive
+  data unless the operators of all the domains involved are
+  trusted.</p>
+
+  <p>User agents may mitigate this problem by preventing hosts
+  corresponding to "<span title="public storage area">public</span>"
+  global storage areas from accessing any storage areas other than
+  their own.</p>
+
+
+  <h5>Storage areas in the face of untrusted higher-level domains that do not correspond to public storage areas</h5>
+
+  <p>Authors should not store sensitive data using the global storage
+  APIs if there are hosts with fully-qualified domain names that are
+  subsets of their own which they do not trust. For example, an author
+  at <code>finance.members.example.net</code> should not store
+  sensitive financial user data in the
+  <code>finance.members.example.net</code> storage area if he does not
+  trust the host that runs <code>example.net</code>.</p>
+
+
+  <h5>Storage areas in the face of untrusted subdomains</h5>
+
+  <p>If an author publishing content on one host wishes to use the
+  <code title="dom-globalStorage">globalStorage</code> API but does
+  not wish any content on the host's subdomains to access the data,
+  the author should use an otherwise non-existent subdomain name,
+  e.g., <code>private.example.com</code>, to store the data. This will
+  be accessible only to that host (and its parent domains), and not to
+  any of the real subdomains.</p>
+
+
   <h5>Implementation risks</h5>
 
   <p>The two primary risks when implementing this persistent storage
@@ -13184,6 +13225,15 @@
   <p>Thus, strictly following the model described in this
   specification is important for user security.</p>
 
+  <p>In addition, a number of optional restrictions related to the
+  "<span title="public storage area">public</span>" global storage
+  areas are suggested in the previous sections. The design of this API
+  is intended to be such that not supporting these restrictions, or
+  supporting them less than perfectly, does not result in critical
+  security problems. However, implementations are still encouraged to
+  create and maintain a list of "<span title="public storage
+  area">public</span>" domains, and apply the restrictions described
+  above.</p>
 
 
   <h2>Multimedia</h2>

|