187
edits
Firefox 3.6/PushState Security Review: Difference between revisions
Jump to navigation
Jump to search
Firefox 3.6/PushState Security Review (view source)
Revision as of 22:24, 3 August 2009
, 3 August 2009→Security and Privacy
(Created page with '== Overview == Implement the HTML5 push/pop/clear state API. '''Background links''' * [http://www.whatwg.org/specs/web-apps/current-work/#dom-history-pushstate HTMl5 spec] * [ht…') |
|||
| Line 7: | Line 7: | ||
== Security and Privacy == | == Security and Privacy == | ||
<ul> | |||
<li>Sites can change their displayed URL with pushstate, but they shouldn't be able to push to a new domain. HTML5 specifies standard same-origin checks here; these are already in the code.</li> | |||
<li>If site A calls pushstate with data object O, site B (of different origin than A) shouldn't be able to access O. This is built into the design, since the popstate event only gives a page back a state object set by another page from the same origin.</li> | |||
<li>A malicious site might try to flood the session history with many history entries. The spec allows us to place limits on the number of entries a page may create: | |||
<blockquote style="background-color: #fafafa; border: solid thin grey; padding:0.5em"> | |||
User agents may limit the number of state objects added to the session history per page. If a page hits the UA-defined limit, user agents must remove the entry immediately after the first entry for that Document object in the session history after having added the new entry. (Thus the state history acts as a FIFO buffer for eviction, but as a LIFO buffer for navigation.) | |||
</blockquote> | |||
Although a malicious site could spam the session history today by, for example, changing the page's hash, pushstate may be a more attractive attack vector because the page can remain completely responsive while the session history entries are being added. As a result, we may want to aggressively limit the number of states a page can push.</li> | |||
<li>Instead of / in addition to hard per-page limits on the number of remembered states, we may need to rate-limit pushstates. Otherwise, a malicious site could keep a user from going back by pushstating every 10ms to the same site. Its oldest history entries would constantly be dropped, but it would still own the history. We'd have to take care to ensure that the rate limiting doesn't appear to be arbitrary.</li> | |||
<li>We also have to try and prevent a site from DOSing the browser by pushing many large objects.</li> | |||
</ol> | |||
== Exported APIs == | == Exported APIs == | ||