19.09.2017 Views

the-web-application-hackers-handbook

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Chapter 6 n Attacking Au<strong>the</strong>ntication 181<br />

Each of <strong>the</strong>se limitations on password validation reduces by an order of<br />

magnitude <strong>the</strong> number of variations available in <strong>the</strong> set of possible passwords.<br />

Through experimentation, you can determine whe<strong>the</strong>r a password is being<br />

fully validated or whe<strong>the</strong>r any limitations are in effect. You can <strong>the</strong>n fine-tune<br />

your automated attacks against <strong>the</strong> login to remove unnecessary test cases,<br />

<strong>the</strong>reby massively reducing <strong>the</strong> number of requests necessary to compromise<br />

user accounts.<br />

HACK STEPS<br />

1. Using an account you control, attempt to log in with variations on your<br />

own password: removing <strong>the</strong> last character, changing <strong>the</strong> case of a character,<br />

and removing any special typographical characters. If any of <strong>the</strong>se<br />

attempts is successful, continue experimenting to try to understand what<br />

validation is actually occurring.<br />

2. Feed any results back into your automated password-guessing attacks to<br />

remove superfluous test cases and improve <strong>the</strong> chances of success.<br />

TRY IT!<br />

http://mdsec.net/auth/293/<br />

Nonunique Usernames<br />

Some <strong>application</strong>s that support self-registration allow users to specify <strong>the</strong>ir<br />

own username and do not enforce a requirement that usernames be unique.<br />

Although this is rare, <strong>the</strong> authors have encountered more than one <strong>application</strong><br />

with this behavior.<br />

This represents a design flaw for two reasons:<br />

n One user who shares a username with ano<strong>the</strong>r user may also happen to<br />

select <strong>the</strong> same password as that user, ei<strong>the</strong>r during registration or in a<br />

subsequent password change. In this eventuality, <strong>the</strong> <strong>application</strong> ei<strong>the</strong>r<br />

rejects <strong>the</strong> second user’s chosen password or allows two accounts to<br />

have identical credentials. In <strong>the</strong> first instance, <strong>the</strong> <strong>application</strong>’s behavior<br />

effectively discloses to one user <strong>the</strong> credentials of <strong>the</strong> o<strong>the</strong>r user. In <strong>the</strong><br />

second instance, subsequent logins by one of <strong>the</strong> users result in access to<br />

<strong>the</strong> o<strong>the</strong>r user’s account.<br />

n An attacker may exploit this behavior to carry out a successful brute-force<br />

attack, even though this may not be possible elsewhere due to restrictions<br />

on failed login attempts. An attacker can register a specific username

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!