Firefox 3.6/PushState Security Review

Overview

Implement the HTML5 push/pop/clear state API.

Background links

• HTMl5 spec
• Bug 500328

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:

  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.)

  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.
• 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

• What other modules are used (REQUIRES in the makefile, interfaces)?

Data

• What data is read or parsed by this feature?
• What is the output of this feature?
• What storage formats are used?

Reliability

• What failure modes or decision points are presented to the user?
• Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

Configuration

• Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
• Are there build options for developers? [#ifdefs, ac_add_options, etc.]
• What ranges for the tunable are appropriate? How are they determined?
• What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

Relationships to other projects

Are there related projects in the community?

• If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?
• Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?