Short URL: http://html5.org/r/81
| SVN | Bug | Comment | Time (UTC) |
|---|---|---|---|
| 81 | More security problems with storage areas | 2006-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>