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

Chapter 7 

■

Attacking Session Management

191

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

---

C O M M O N   M Y T H

“Our token is secure from disclosure to third parties

because we use SSL.”

Proper use of SSL certainly helps to protect session tokens from being

captured. But various mistakes can still result in tokens being transmitted in

clear text even when SSL is in place. And there are various direct attacks

against end users that can be used to obtain their token.

Disclosure of Tokens on the Network

This area of vulnerability arises when the session token is transmitted across

the network in unencrypted form, enabling a suitably positioned eavesdrop-

per to obtain the token and so masquerade as the legitimate user. Suitable posi-

tions for eavesdropping include the user’s local network, within the user’s IT

department, within the user’s ISP, on the Internet backbone, within the appli-

cation’s ISP, and within the IT department of the organization hosting the

application. In each case, this includes both authorized personnel of the rele-

vant organization and any external attackers who have compromised the

infrastructure concerned.

In the simplest case, where an application uses an unencrypted HTTP con-

nection for communications, an attacker can capture all data transmitted

between client and server, including login credentials, personal information,

payment details, and so on. In this situation, an attack against the user’s ses-

sion is often unnecessary because the attacker can already view privileged

information and can log in using captured credentials to perform other mali-

cious actions. However, there may still be instances where the user’s session is

the primary target. For example, if the captured credentials are not sufficient to

perform a second login (e.g., in a banking application, they may include a

number displayed on a changing physical token, or specific digits from the

user’s PIN), the attacker may need to hijack the eavesdropped session in order

to perform arbitrary actions. Or if there is close auditing of logins, and notifi-

cation to the user of each successful login, then an attacker may wish to avoid

performing his own login in order to be as stealthy as possible.

In other cases, an application may use HTTPS to protect key client-server

communications yet may still be vulnerable to interception of session tokens

on the network. There are various ways in which this weakness may occur,

many of which can arise specifically when HTTP cookies are used as the trans-

mission mechanism for session tokens:

■■

Some applications elect to use HTTPS to protect the user’s credentials

during login but then revert to HTTP for the remainder of the user’s