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

Chapter 6 

■

Attacking Authentication

157

70779c06.qxd:WileyRed  9/14/07  3:13 PM  Page 157

---

C O M M O N   M Y T H

It is often assumed that multistage login mechanisms

are less prone to security bypasses than standard username/password

authentication. This belief is misleading. Performing several authentication

checks may add considerable security to the mechanism. Counterbalancing this,

the process is more prone to flaws in implementation. In several cases where a

combination of flaws is present, it can even result in a solution that is 

less

secure than a normal login based on username and password.

Some implementations of multistage login mechanisms make potentially

unsafe assumptions at each stage about the user’s interaction with earlier

stages. For example:

■■

An application may assume that a user who accesses stage three must

have cleared stages one and two. Therefore, it may authenticate an

attacker who proceeds directly from stage one to stage three and cor-

rectly completes it, enabling an attacker to log in with only one part of

the various credentials normally required.

■■

An application may trust some of the data being processed at stage two

because this was validated at stage one. However, an attacker may be

able to manipulate this data at stage two, giving it a different value than

was validated at stage one. For example, at stage one the application

might determine whether the user’s account has expired, is locked out,

or is in the administrative group, or whether it needs to complete fur-

ther stages of the login beyond stage two. If an attacker can interfere

with these flags as the login transitions between different stages, they

may be able to modify the behavior of the application and cause it to

authenticate them with only partial credentials or otherwise elevate

privileges.

■■

An application may assume that the same user identity is used to com-

plete each stage; however, it might not explicitly check this. For exam-

ple, stage one might involve submitting a valid username and

password, and stage two might involve resubmitting the username

(now in a hidden form field) and a value from a changing physical

token. If an attacker submits valid data pairs at each stage, but for dif-

ferent users, then the application might authenticate the user as either

one of the identities used in the two stages. This would enable an

attacker who possesses his own physical token and discovers another

user’s password to log in as that user (or vice versa). Although the

login mechanism cannot be completely compromised without any prior

information, its overall security posture is substantially weakened and

the substantial expense and effort of implementing the two-factor

mechanism does not deliver the benefits expected.