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

Chapter 6 

■

Attacking Authentication

145

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

---

In many cases, the application allows users to set their own password

recovery challenge and response during registration, and users are

inclined to set extremely insecure challenges, presumably on the false

assumption that only they will ever be presented with them, for example:

“Do I own a boat?” In this situation, an attacker wishing to gain access

can use an automated attack to iterate through a list of enumerated or

common usernames, log all of the password recovery challenges, and

select those that appear most easily guessable. (See Chapter 13 for tech-

niques regarding how to grab this kind of data in a scripted attack.)

■■

As with password change functionality, application developers com-

monly overlook the possibility of brute forcing the response to a pass-

word recovery challenge, even when they block this attack on the main

login page. If an application allows unrestricted attempts to answer

password recovery challenges, then it is highly likely to be compro-

mised by a determined attacker.

■■

In some applications, the recovery challenge is replaced with a simple

password “hint” that is configurable by users during registration. Users

commonly set extremely obvious hints, even one that is identical to the

password itself, on the false assumption that only they will ever see them.

Again, an attacker with a list of common or enumerated usernames can

easily capture a large number of password hints and then start guessing.

■■

The mechanism by which an application enables users to regain control

of their account after correctly responding to a challenge is often vul-

nerable. One reasonably secure means of implementing this is to send a

unique, unguessable, time-limited recovery URL to the email address

that the user provided during registration. Visiting this URL within a

few minutes enables the user to set a new password. However, other

mechanisms for account recovery are often encountered that are inse-

cure by design:

■■

Some applications disclose the existing, forgotten password to the

user after successful completion of a challenge, enabling an attacker

to use the account indefinitely without any risk of detection by the

owner. Even if the account owner subsequently changes the blown

password, the attacker can simply repeat the same challenge to

obtain the new password.

■■

Some applications immediately drop the user into an authenticated

session after successful completion of a challenge, again enabling an

attacker to use the account indefinitely without detection, and with-

out ever needing to know the user’s password.

■■

Some applications employ the mechanism of sending a unique

recovery URL but send this to an email address specified by the user