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

368

Chapter 11 

■

Attacking Application Logic

70779c11.qxd:WileyRed  9/14/07  3:14 PM  Page 368

---

Chapter 11 

■

Attacking Application Logic  369

The root cause was that the application was briefly storing a key identifier

about each newly authenticated user within a static (nonsession) variable.

After being written, this variable’s value was read back an instant later. If a dif-

ferent thread (processing another login) had written to the variable during this

instant, the earlier user would land in an authenticated session belonging to

the subsequent user.

The vulnerability arose from the same kind of mistake as in the error mes-

sage example described previously: the application was using static storage to

hold information that ought to have been stored on a per-thread or per-session

basis. However, the present example is far more subtle to detect, and is more

difficult to exploit because it cannot be reliably reproduced.

Flaws of this kind are known as “race conditions” because they involve a

vulnerability that arises for a brief period of time during certain specific cir-

cumstances. Because the vulnerability exists only for a short time, an attacker

faces a “race” to exploit it before the application closes it again. In cases where

the attacker is local to the application, it is often possible to engineer the exact

circumstances in which the race condition arises, and reliably exploit the vul-

nerability during the available window. Where the attacker is remote to the

application, this is normally much harder to achieve.

A remote attacker who understood the nature of the vulnerability could

conceivably have devised an attack to exploit it, by using a script to log in con-

tinuously and check the details of the account accessed. But the tiny window

during which the vulnerability could be exploited meant that a huge number

of requests would be required.

It was not surprising that the race condition was not discovered during nor-

mal penetration testing. The conditions in which it arose came about only when

the application gained a large enough user base for random anomalies to occur,

which were reported by customers. However, a close code review of the authen-

tication and session management logic would have identified the problem.