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

176

Chapter 7 

■

Attacking Session Management

70779c07.qxd:WileyRed  9/14/07  3:13 PM  Page 176

---

of their visit, the application does not know or care who the user is. But, in

order to do business with them, it needs to know which series of requests it

receives has originated from the same user.

The simplest and still most common means of implementing sessions is to

issue each user with a unique session token or identifier. On each subsequent

request to the application, the user resubmits this token, enabling the application

to determine which sequence of earlier requests the current request relates to.

In most cases, applications use HTTP cookies as the transmission mecha-

nism for passing these session tokens between server and client. The server’s

first response to a new client contains an HTTP header like the following:

Set-Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55

and subsequent requests from the client contain the header:

Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55

There are various categories of attack to which this standard session man-

agement mechanism is inherently vulnerable. An attacker’s primary objective

in targeting the mechanism is to somehow hijack the session of a legitimate

user and thereby masquerade as them. If the user has been authenticated to the

application, the attacker may be able to access private data belonging to the

user or carry out unauthorized actions on that person’s behalf. If the user is

unauthenticated, the attacker may still be able to view sensitive information

submitted by the user during her session.

As in the previous example of a Microsoft IIS server running ASP.NET, most

commercial web servers and web application platforms implement their own

off-the-shelf session management solution based on HTTP cookies. They pro-

vide APIs that web application developers can use to integrate their own

 session-dependent functionality with this solution.

Some off-the-shelf implementations of session management have been

found vulnerable to various attacks, which result in users’ sessions being com-

promised (these are discussed later in this chapter). In addition, some devel-

opers find that they need more fine-grained control over session behavior than

is provided for them by the built-in solutions, or wish to avoid some vulnera-

bilities inherent in cookie-based solutions. For these reasons, it is fairly

 common to see bespoke and/or non-cookie-based session management mech-

anisms used in security-critical applications such as online banking.

The vulnerabilities that exist in session management mechanisms largely

fall into two categories:

■■

Weaknesses in the generation of session tokens.

■■

Weaknesses in the handling of session tokens throughout their lifecycle.