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

Having decided upon an algorithm for generating session tokens, a useful

“thought experiment” is to imagine that your source of pseudo-randomness is

totally broken and always returns the same value. In this eventuality, would an

attacker who obtains a large sample of tokens from the application be able to

extrapolate tokens issued to other users? Using the formula described here,

this will in general be highly unlikely, even with full knowledge of the algorithm

used. The source IP, port number, 

User-Agent

header, and time of request

together generate a vast amount of entropy. And even with full knowledge of

these, the attacker will not be able to produce the corresponding token without

knowing the secret string used by the server.

Protect Tokens throughout Their Lifecycle

Having created a robust token whose value cannot be predicted, this token

needs to be protected throughout its lifecycle from creation to disposal, to

ensure that it is not disclosed to anyone other than the user to whom it is

issued:

■■

The token should only ever be transmitted over HTTPS. Any token

transmitted in clear text should be regarded as tainted — that is, as not

providing assurance of the user’s identity. If HTTP cookies are being

used to transmit tokens, these should be flagged as 

secure

to prevent

the user’s browser from ever transmitting them over HTTP. If feasible,

HTTPS should be used for every page of the application, including sta-

tic content such as help pages, images, and so on. If this is not desired