the-web-application-hackers-handbook

Chapter 7 n Attacking Session Management 207
The simplest and still most common means of implementing sessions is to
issue each user 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 mechanism
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 this header:
Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55
This standard session management mechanism is inherently vulnerable to
various categories of attack. An attacker’s primary objective in targeting the
mechanism is to somehow hijack the session of a legitimate user and thereby
masquerade as that person. 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 provide
APIs that web application developers can use to integrate their own sessiondependent
functionality with this solution.
Some off-the-shelf implementations of session management have been found to
be vulnerable to various attacks, which results in users’ sessions being compromised
(these are discussed later in this chapter). In addition, some developers find
that they need more fine-grained control over session behavior than is provided
for them by the built-in solutions, or they want to avoid some vulnerabilities
inherent in cookie-based solutions. For these reasons, it is fairly common to see
bespoke and/or non-cookie-based session management mechanisms used in
security-critical applications such as online banking.
The vulnerabilities that exist in session management mechanisms largely
fall into two categories:
n Weaknesses in the generation of session tokens
n Weaknesses in the handling of session tokens throughout their life cycle
We will look at each of these areas in turn, describing the different types of
defects that are commonly found in real-world session management mechanisms,
and practical techniques for discovering and exploiting these. Finally,
we will describe measures that applications can take to defend themselves
against these attacks.