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

Chapter 7 

■

Attacking Session Management

211

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

---

Log, Monitor, and Alert

The application’s session management functionality should be closely inte-

grated with its mechanisms for logging, monitoring, and alerting, in order to

provide suitable records of anomalous activity and enable administrators to

take defensive actions where necessary:

■■

The application should monitor requests that contain invalid tokens.

Except in the most trivially predictable cases, a successful attack

attempting to guess the tokens issued to other users will typically

involve issuing large numbers of requests containing invalid tokens,

leaving a noticeable mark in the application’s logs.

■■

Brute-force attacks against session tokens are difficult to block altogether,

because there is no particular user account or session that can be disabled

to stop the attack. One possible action is to block source IP addresses for

a period when a number of requests containing invalid tokens have been

received. However, this may be ineffective when one user’s requests orig-

inate from multiple IP addresses (e.g., AOL users) or when multiple

users’ requests originate from the same IP address (e.g., users behind a

proxy or a firewall performing network address translation).

■■

Even if brute-force attacks against sessions cannot be effectively pre-

vented in real time, keeping detailed logs and alerting administrators

enables them to investigate the attack and take appropriate action

where they are able to.

■■

Wherever possible, users should be alerted to anomalous events relat-

ing to their session — for example, concurrent logins or apparent

hijacking (detected using per-page tokens). Even though a compromise

may already have occurred, this enables the user to check whether any

unauthorized actions such as funds transfers have taken place.