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

the server is also listening on port 80, running any service or content

whatsoever. If so, visit any HTTP URL directly from with an authenticated

session and verify whether the session token is transmitted.

■

In cases where a token for an authenticated session is transmitted to the

server over HTTP, verify whether that token continues to be valid or is

immediately terminated by the server.

Chapter 7 

■

Attacking Session Management

195

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

---

Disclosure of Tokens in Logs

Aside from the clear-text transmission of session tokens in network communi-

cations, the most common place where tokens are simply disclosed to unau-

thorized view is in system logs of various kinds. Although it is a rarer

occurrence, the consequences of this kind of disclosure are usually more seri-

ous because those logs may be viewed by a far wider range of potential attack-

ers, and not just by someone who is suitably positioned to eavesdrop on the

network.

Many applications provide functionality for administrators and other sup-

port personnel to monitor and control aspects of the application’s runtime

state, including user sessions. For example, a helpdesk worker assisting a user

who is having problems may ask for their username, locate their current ses-

sion through a list or search function, and view relevant details about the ses-

sion. Or an administrator may consult a log of recent sessions in the course of

investigating a security breach. Often, this kind of monitoring and control

functionality discloses the actual session token associated with each session.

And often, the functionality is poorly protected, allowing unauthorized users

to access the list of current session tokens, and thereby hijack the sessions of all

application users. 

The other main cause of session tokens appearing in system logs is where an

application uses the URL query string as a mechanism for transmitting tokens,

as opposed to using HTTP cookies or the body of 

POST

requests. For example,

googling for 

inurl:jsessionid

identifies thousands of applications that

transmit the Java platform session token (called 

jsessionid

) within the URL:

http://www.webjunction.org/do/Navigation;jsessionid=

F27ED2A6AAE4C6DA409A3044E79B8B48?category=327

When applications transmit their session tokens in this way, it is likely that

their session tokens will appear in various system logs to which unauthorized

parties may have access, for example:

■■

Users’ browser logs.

■■

Web server logs.

■■

Logs of corporate or ISP proxy servers.

■■

Logs of any reverse proxies employed within the application’s hosting

environment.

■■

The Referer logs of any servers that application users visit by following

off-site links, as in Figure 7-4.