The Web Application Hacker’s Handbook Discovering and Exploiting Security Flaws

State and Sessions

The technologies described so far enable the server and client components of a

web application to exchange and process data in numerous ways. To imple-

ment most kinds of useful functionality, however, applications need to track

the state of each user’s interaction with the application across multiple

requests. For example, a shopping application may allow users to browse a

product catalogue, add items to a cart, view and update the cart contents, pro-

ceed to checkout, and provide personal and payment details.

To make this kind of functionality possible, the application must maintain a

set of stateful data generated by the user’s actions across several requests. This

data is normally held within a server-side structure called a session. When a

user performs an action, such as adding an item to her shopping cart, the

server-side application updates the relevant details within the user’s session.

When the user later views the contents of her cart, data from the session is

used to return the correct information to the user.

In some applications, state information is stored on the client component

rather than the server. The current set of data is passed to the client in each

server response, and is sent back to the server in each client request. Of course,

because any data transmitted via the client component may be modified by the

user, applications need to take measures to protect themselves from attackers

who may change this state information in an attempt to interfere with the

application’s logic. The ASP.NET platform makes use of a hidden form field

called the ViewState to store state information about the user’s web interface

and so reduce overhead on the server. By default, the contents of the ViewState

include a keyed hash to prevent tampering.

Because the HTTP protocol is itself stateless, most applications need a

means of re-identifying individual users across multiple requests, in order for

the correct set of state data to be used to process each request. This is normally

achieved by issuing each user a token which uniquely identifies that user’s

session. These tokens may be transmitted using any type of request parameter,

but HTTP cookies are used by most applications. Several kinds of vulnerabil-

ity arise in relation to session handling, and these are described in detail in

Chapter 7.