Unfortunately for developers, in practice this
approach is no more secure than simply Base64 encoding a username and timestamp
concatenation. If the session ID appears as though it has been hashed, a username and
timestamp combination is one of the first things an attacker will try. By logging in to the
system, an attacker knows a username and the exact timestamp, which he can then run
through a hash function and compare to the cookie returned by the system. If the two
Figure 6-5 A simple session identi?¬? er analyzed in WebScarab
168 Hacking Exposed Web 2.0
match, the attacker knows the session ID generation algorithm and can compromise any
other session ID. Figure 6-6 shows an example of a cookie that is generated by hashing a
username and a timestamp, so that bad cookie values can appear random at first
glance.
Example
The following example shows how to use the WebScarab utility to analyze the randomness
of session cookies generated by a web application.
1. Install and run the WebScarab utility from OWASP, which is freely available at
www.owasp.org/index.php/Category:OWASP_WebScarab_Project.
2. Point the web browser at the WebScarab web proxy, which will be running on
the localhost at port 8008 by default.
Pages:
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314