the-web-application-hackers-handbook

240 Chapter 7 n Attacking Session Management
TRY IT!
http://mdsec.net/auth/379/
Vulnerable Mapping of Tokens to Sessions
Various common vulnerabilities in session management mechanisms arise
because of weaknesses in how the application maps the creation and processing
of session tokens to individual users’ sessions themselves.
The simplest weakness is to allow multiple valid tokens to be concurrently
assigned to the same user account. In virtually every application, there is no
legitimate reason why any user should have more than one session active at
one time. Of course, it is fairly common for a user to abandon an active session
and start a new one — for example, because he closes a browser window or
moves to a different computer. But if a user appears to be using two different
sessions simultaneously, this usually indicates that a security compromise has
occurred: either the user has disclosed his credentials to another party, or an
attacker has obtained his credentials through some other means. In both cases,
permitting concurrent sessions is undesirable, because it allows users to persist
in undesirable practices without inconvenience and because it allows an attacker
to use captured credentials without risk of detection.
A related but distinct weakness is for applications to use “static” tokens.
These look like session tokens and may initially appear to function like them,
but in fact they are no such thing. In these applications, each user is assigned
a token, and this same token is reissued to the user every time he logs in. The
application always accepts the token as valid regardless of whether the user
has recently logged in and been issued with it. Applications like this really
involve a misunderstanding about the whole concept of what a session is, and
the benefits it provides for managing and controlling access to the application.
Sometimes, applications operate like this as a means of implementing poorly
designed “remember me” functionality, and the static token is accordingly
stored in a persistent cookie (see Chapter 6). Sometimes the tokens themselves
are vulnerable to prediction attacks, making the vulnerability far more serious.
Rather than compromising the sessions of currently logged-in users, a successful
attack compromises, for all time, the accounts of all registered users.
Other kinds of strange application behavior are also occasionally observed
that demonstrate a fundamental defect in the relationship between tokens and
sessions. One example is where a meaningful token is constructed based on a
username and a random component. For example, consider the token:
dXNlcj1kYWY7cjE9MTMwOTQxODEyMTM0NTkwMTI=
which Base64-decodes to:
user=daf;r1=13094181213459012