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

If the password change form is only accessible by authenticated users

and does not contain a username field, it may still be possible to supply an

arbitrary username. The form may store the username in a hidden field, which

can easily be modified. If not, try supplying an additional parameter containing

the username, using the same parameter name as is used in the main login

form. This trick sometimes succeeds in overriding the username of the current

user, enabling you to brute force the credentials of other users even when this

is not possible at the main login. 

Forgotten Password Functionality

Like password change functionality, mechanisms for recovering from a forgot-

ten password situation often introduce problems that may have been avoided

in the main login function, such as username enumeration. 

In addition to this range of defects, design weaknesses in forgotten pass-

word functions frequently make this the weakest link at which to attack the

application’s overall authentication logic. Several kinds of design weaknesses

can often be found:

■■

The forgotten password functionality often involves presenting the user

with a secondary challenge in place of the main login, as shown in Fig-

ure 6-4. This challenge is often much easier for an attacker to respond to

than attempting to guess the user’s password. Questions about moth-

ers’ maiden names, memorable dates, favorite colors, and the like will

generally have a much smaller set of potential answers than the set of

possible passwords. Further, they often concern information that is

publicly known or that a determined attacker can discover with a 

modest degree of effort.

Figure 6-4: A secondary challenge used in an account 

recovery function