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.

Chapter 8 n Attacking Access Controls 279<br />

n Do not trust any user-submitted parameters to signify access rights (such<br />

as admin=true).<br />

n Do not assume that users will access <strong>application</strong> pages in <strong>the</strong> intended<br />

sequence. Do not assume that because users cannot access <strong>the</strong> Edit Users<br />

page, <strong>the</strong>y cannot reach <strong>the</strong> Edit User X page that is linked from it.<br />

n Do not trust <strong>the</strong> user not to tamper with any data that is transmitted via<br />

<strong>the</strong> client. If some user-submitted data has been validated and <strong>the</strong>n is<br />

transmitted via <strong>the</strong> client, do not rely on <strong>the</strong> retransmitted value without<br />

revalidation.<br />

The following represents a best-practice approach to implementing effective<br />

access controls within <strong>web</strong> <strong>application</strong>s:<br />

n Explicitly evaluate and document <strong>the</strong> access control requirements for<br />

every unit of <strong>application</strong> functionality. This needs to include both who<br />

can legitimately use <strong>the</strong> function and what resources individual users<br />

may access via <strong>the</strong> function.<br />

n Drive all access control decisions from <strong>the</strong> user’s session.<br />

n Use a central <strong>application</strong> component to check access controls.<br />

n Process every client request via this component to validate that <strong>the</strong> user<br />

making <strong>the</strong> request is permitted to access <strong>the</strong> functionality and resources<br />

being requested.<br />

n Use programmatic techniques to ensure that <strong>the</strong>re are no exceptions to <strong>the</strong><br />

previous point. An effective approach is to mandate that every <strong>application</strong><br />

page must implement an interface that is queried by <strong>the</strong> central access<br />

control mechanism. If you force developers to explicitly code access control<br />

logic into every page, <strong>the</strong>re can be no excuse for omissions.<br />

n For particularly sensitive functionality, such as administrative pages, you<br />

can fur<strong>the</strong>r restrict access by IP address to ensure that only users from<br />

a specific network range can access <strong>the</strong> functionality, regardless of <strong>the</strong>ir<br />

login status.<br />

n If static content needs to be protected, <strong>the</strong>re are two methods of providing<br />

access control. First, static files can be accessed indirectly by passing<br />

a filename to a dynamic server-side page that implements relevant access<br />

control logic. Second, direct access to static files can be controlled using HTTP<br />

au<strong>the</strong>ntication or o<strong>the</strong>r features of <strong>the</strong> <strong>application</strong> server to wrap <strong>the</strong> incoming<br />

request and check <strong>the</strong> resource’s permissions before access is granted.<br />

n Identifiers specifying which resource a user wants to access are vulnerable<br />

to tampering whenever <strong>the</strong>y are transmitted via <strong>the</strong> client. The server

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

Saved successfully!

Ooh no, something went wrong!