Firefox 3.6/PushState Security Review: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| Line 23: | Line 23: | ||
== Module interactions == | == Module interactions == | ||
We use the JS library's native JSON parsing to encode/decode objects. Worker threads use the same library for a similar purpose. | |||
== Data == | == Data == | ||
== Reliability == | == Reliability == | ||
== Configuration == | == Configuration == | ||
== Relationships to other projects == | == Relationships to other projects == | ||
* Smaug is planning to / in the process of rewriting session history. I'm not sure exactly what that entails, so I'm not sure how it affects me. It's probably not a security issue, though. | |||
== Review comments == | == Review comments == | ||
Revision as of 22:28, 3 August 2009
Overview
Implement the HTML5 push/pop/clear state API.
Background links
Security and Privacy
- 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.
- 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.
- 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:
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.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.)
- 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.
- We also have to try and prevent a site from DOSing the browser by pushing many large objects.
Exported APIs
See HTML5 doc.
Module interactions
We use the JS library's native JSON parsing to encode/decode objects. Worker threads use the same library for a similar purpose.
Data
Reliability
Configuration
Relationships to other projects
- Smaug is planning to / in the process of rewriting session history. I'm not sure exactly what that entails, so I'm not sure how it affects me. It's probably not a security issue, though.