The HTTP 1.1 protocol itself is stateless (i.e., has no inherent support for persistent sessions). Yet many web applications add sessions to become stateful.

Why?

What is a session? What is statefulness?

How do they impact security on the web?

Sessions are a correlation of requests for individual web pages/data (“hits”) into a sense of an overall “visit” for a client during a time span, but also retain some memory between events. They typically consist of a session ID coupled with its data indicating current state. Classic examples include logins, showing previously viewed items, and shopping carts.

The reason why HTTP applications must add sessions is related to how software works: software often changes how it appears or acts based upon:

At each time, some inputs/actions are known to be valid and possible, while others are not. Without memory of history to define the current context, which actions are valid and possible, and therefore how it should function, cannot be known.

When software cannot function without memory, it is stateful. Many important features — denying access if a person is not currently logged in, for example, or shipping what has been added to a shopping cart — are stateful, and therefore can’t be supported by purely stateless HTTP according to the original RFC. Such features require that web apps augment the HTTP protocol by adding a notion of session memory via:

Because memory is an accumulation of input, sessions have security implications.

When sessions are not protected to prevent misuse, software can be used in unexpected ways by attackers.

For example, let’s say there is a vending machine. You must insert money first. If you:

the machine will do nothing. The machine is designed so that it must be in the state where it has received enough money before it will dispense the snack (or return your change).

If the vending machine had no notion of states, it would dispense free snacks or change — regardless of whether it had received any money.

While free snacks might make some hungry people happy, it is not the intended behavior. We would say that the vending machine is broken.

Similar to the working vending machine, in the TCP protocol, a connection cannot be acknowledged (ACK) or data sent (PSH) before the connection has been initiated (SYN). There is a definite order to valid operations, based upon the operation that preceded it. If a connection is not already established — not in a state to receive data — then the receiver will disregard it.

Similar to the broken vending machine, the naked HTTP protocol has no idea what the previous HTTP request was, and therefore no way to predict what the next one might be. Nothing is required to persist from one request to the next. While this was adequate at the time when HTTP was initially designed, when it purely needed to retrieve static text or HTML documents, as the World Wide Web evolved, this was no longer enough. Static pages evolved into dynamic CGI-generated and JavaScripted pages. Dynamic pages use programs to change the page. Scripted pages eventually evolved to fully-fledged multimedia web applications with their own client-server architecture. As pages became software in their own right, a need for sessions arose.

When a web application has its own native authentication, the session may correspond directly with its authentication logs — server-side sessions may start with a login and end with a logout/session timeout. Within each session, there are contexts that the software can use to determine which operations make sense. For example, for each live session, a web application might remember:

However, sessions alone are not enough to ensure that a client’s requested operations make sense. The client’s next page request in the session could break the web application’s logic unless requests are restricted to valid ones.

For example, a web application session may remember that a client has authenticated. But unless it also knows what pages that client is authorized to use, there might be nothing to prevent that person from ignoring the links on the current web page and entering a non-authorized URL into their web browser to steal secret information.

If they do not enforce valid state transitions and guard session IDs and cookies from fraud (including sidejacking attacks made famous by Firesheep) or cookie poisoning, web applications become vulnerable to state transition-based attacks — attacks where pages are requested out of the expected order, by a different client, or where inputs used for the next page are not as expected. While many web applications reflect business logic in order to function, not all applications validate state transitions to enforce application logic. Other web applications do attempt to enforce the software’s logic, but do not do so effectively. In other cases, the state enforcement itself has bugs. These are common causes of security vulnerabilities.