Integrity for sessionStorage

There are many different ways to think about security.  I prefer the following approach:

1. Define a set of threat models that describe the attacker's capabilities.  For example, the "man-in-the-middle" is a classic threat model in network security that represents an attacker who has complete control over the network but who has no control over network endpoints.
2. Identify a set of security properties that we wish our system to achieve.  Defining good security properties is a tricky business, and we're mostly going to wave our hands in this blog.  If you'd like an example, you should imagine something like "the attacker doesn't learn the contents of the user's email."
3. Determine whether an attacker with the capabilities described in the threat model could possibly defeat any of the security properties of our system.  We usually assume that the attacker knows exactly how our system works (e.g., because attackers can read W3C specifications).

This approach tends to be somewhat conservative in the sense that we underestimate whether our system is secure.  That's helpful when thinking defensively because being conservative pushes us to design systems that are secure robustly rather than systems that are secure by some happy accident.

So far, this post has been very abstract, but let's get concrete.  Recently, I've been corresponding with a number of Firefox developers about Firefox Bug 495337.  There are a number of technical details, but the issue boils down to the three factors above:

1. Threat model.  We're concerned with an active network attacker.  (I need to write a "foundations" post introducing the important threat models in web security, but I didn't want to write too many foundations posts in a row.)  Essentially, an active network attacker has full control over the network (e.g., they can intercept and spoof HTTP requests and responses), but have very little power over secure network connections (e.g., they can't mess with TLS connections).
2. Security property.  Here's where things get interesting.  What are appropriate security properties for sessionStorage (an API for semi-persistently storing data in the browser)?  I claim that the data an origin stores in sessionStorage should have confidentiality and integrity (i.e., other origins should not be able to learn or to alter data stored in sessionStorage).
3. Could possibly defeat.  That leaves us with the question of whether an active network attacker could possibly defeat the confidentiality or integrity of data in sessionStorage.  I claim that such a thing is possible in Firefox (via a somewhat elaborate sequence of steps) because Firefox's behavior deviates slightly from the specification.  Specifically, in some circumstances that an attacker can provoke, Firefox considers only the host portion of the origin, ignoring the scheme and the port.  By ignoring the scheme, Firefox lets a network attacker leverage his or her ability to control HTTP to disrupt the integrity of HTTPS data in sessionStorage.

Does this represent a "real" security problem?  Well, that's a hard question to answer.  Certainly this issue makes it harder to understand the security of systems that use sessionStorage.  Instead of being able to use clean abstractions like confidentially, integrity, and origin, we need to understand more details of how exactly an attacker can subtly manipulate sessionStorage.

Ultimately, complexity is the enemy of security.  Applied judiciously, threat models and security properties can help you understand the security of your system in simpler terms.