In the beginning
The first official HTTP specification, version 1.0, was released in May 1996 by a team led by Tim Berners-Lee, but the development of the web had been going on since at least 1989, and the first versions of Netscape Navigator and Internet Explorer had already been released before version 1.0 was official. Still, this version captures some core principles of Mr. Berners-Lee’s original intent for the web. One concept is found in the very first paragraph of the specification where it says, referring to the HTTP protocol “It is a generic, stateless, object-oriented protocol which can be used for many tasks.” The word we want to focus on here is “stateless”. Originally, HTTP was designed so that every request received by the server could be handled without worrying about any request that had been made before it. This design makes sense when your goal was to serve documents that allowed jumping between references and footnotes with a simple click, but HTML and HTTP had proved to be much more useful than this original use case. In order to build the kind of web we’ve grown to know and love, the stateless principal had to be set aside.
In the summer of 1994, a young engineer by the name of Lou Montulli was tasked to solve a problem. His employer, Netscape, had signed a contract to build an online store for a “small” company named MCI (they operate as Sprint now). Unless they wanted to handle the entire shopping experience with one or maybe two web requests, Lou needed a way to link multiple requests from the same user together into a cohesive experience. There were a couple of options suggested internally and on associated Usenet groups, but Lou settled on the idea of the cookie, a token offered by the server and managed by the client. Lou specifically wanted to let users control how they were tracked (https://montulli.blogspot.com/2013/05/the-reasoning-behind-web-cookies.html), although with hindsight, we know that the solution was not perfect.
With the cookie was born the user session, and with the user session came session attacks.
Break It Down
Internet security can often and usefully be broken down by attack techniques and the corresponding defenses that stand in the way of a successful attack. Some defenses are built in from the beginning based on expected attacks and are a credit to the designers.
The chart below is an attempt at a comprehensive list of significant attacks that will result in the compromise of a user session. In this context, compromise means the ability for an attacker to issue at least one request with the authority provided by the victim’s session token.
As you can see, there is a broad array of potential attacks, some of which allow the attacker to obtain the value of the session token directly, and some that can only be used to blindly issue a fixed request (or maybe a sequence of requests). You will also notice, that there are more defenses than attacks. Sometimes the defenses overlap completely and only one is needed against a particular attack, and sometimes there are special cases where it is better to implement multiple similar defenses. Fortunately, defenses nearly always require less work to implement than it takes to perform the attack.
In this series of articles, we'll step through each of the main lines of attack and the defenses available to combat them. By examining each one in detail, developers will be reminded of the potential risks and will hopefully be better able to chose the right defenses for their needs.
For more information about attacks that put a user's session at risk, and how to defend against them, consider the rest of the articles in this series.
Part 1 - Overview (this article)
Part 2 - Network Sniffing
Part 3 - Token Exposure
Part 4 - JavaScript Injection (XSS)
Part 5 - Blind Session Abuse
Part 6 - Post-compromise Use
Bonus 1 - JWTs: Only Slightly Worse
Bonus 2 - Device Bound Session Tokens
Errata
See a mistake? Disagree with something?