19.09.2017 Views

the-web-application-hackers-handbook

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

18 Chapter 2 n Core Defense Mechanisms<br />

<strong>application</strong>s effectively. If you are new to hacking <strong>web</strong> <strong>application</strong>s (and even<br />

if you are not), you should be sure to take time to understand how <strong>the</strong>se core<br />

mechanisms work in each of <strong>the</strong> <strong>application</strong>s you encounter, and identify <strong>the</strong><br />

weak points that leave <strong>the</strong>m vulnerable to attack.<br />

Handling User Access<br />

A central security requirement that virtually any <strong>application</strong> needs to meet is<br />

controlling users’ access to its data and functionality. A typical situation has<br />

several different categories of user, such as anonymous users, ordinary au<strong>the</strong>nticated<br />

users, and administrative users. Fur<strong>the</strong>rmore, in many situations different<br />

users are permitted to access a different set of data. For example, users of a <strong>web</strong><br />

mail <strong>application</strong> should be able to read <strong>the</strong>ir own e-mail but not o<strong>the</strong>r people’s.<br />

Most <strong>web</strong> <strong>application</strong>s handle access using a trio of interrelated security<br />

mechanisms:<br />

n Au<strong>the</strong>ntication<br />

n Session management<br />

n Access control<br />

Each of <strong>the</strong>se mechanisms represents a significant area of an <strong>application</strong>’s<br />

attack surface, and each is fundamental to an <strong>application</strong>’s overall security<br />

posture. Because of <strong>the</strong>ir interdependencies, <strong>the</strong> overall security provided by<br />

<strong>the</strong> mechanisms is only as strong as <strong>the</strong> weakest link in <strong>the</strong> chain. A defect in<br />

any single component may enable an attacker to gain unrestricted access to <strong>the</strong><br />

<strong>application</strong>’s functionality and data.<br />

Au<strong>the</strong>ntication<br />

The au<strong>the</strong>ntication mechanism is logically <strong>the</strong> most basic dependency in an<br />

<strong>application</strong>’s handling of user access. Au<strong>the</strong>nticating a user involves establishing<br />

that <strong>the</strong> user is in fact who he claims to be. Without this facility, <strong>the</strong> <strong>application</strong><br />

would need to treat all users as anonymous — <strong>the</strong> lowest possible level of trust.<br />

The majority of today’s <strong>web</strong> <strong>application</strong>s employ <strong>the</strong> conventional au<strong>the</strong>ntication<br />

model, in which <strong>the</strong> user submits a username and password, which<br />

<strong>the</strong> <strong>application</strong> checks for validity. Figure 2-1 shows a typical login function.<br />

In security-critical <strong>application</strong>s such as those used by online banks, this basic<br />

model is usually supplemented by additional credentials and a multistage login<br />

process. When security requirements are higher still, o<strong>the</strong>r au<strong>the</strong>ntication models<br />

may be used, based on client certificates, smartcards, or challenge-response<br />

tokens. In addition to <strong>the</strong> core login process, au<strong>the</strong>ntication mechanisms often<br />

employ a range of o<strong>the</strong>r supporting functionality, such as self-registration,<br />

account recovery, and a password change facility.

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

Saved successfully!

Ooh no, something went wrong!