Chapter 5: Attacking Web Authorization

Overview

We just saw in Chapter 4 how authentication determines if a user can log into a web application. Authorization determines what parts of the application the authenticated user can access, as well as what actions they can take within the application. Since the stateless HTTP protocol lacks even the most basic concept of discrete sessions for each authenticated user, web authorization is challenging to implement and consequently profitable to attack.

Note 

We will sometimes abbreviate authentication as "authn," and authorization as "authz."

Authorization is classically implemented by providing the authenticated user's session with an access token that uniquely identifies him/her to the application. The application then makes decisions about whether to grant or deny access to an internal object based on a comparison of identifiers within the token and access control list (ACL) on the object. If the provided identifiers match the configured permission on the object, access is granted; if there is no match, access is denied . The token is provided with each subsequent request, which the application parses without having to reauthenticate the user over and over again. Upon logout or session timeout, the token is typically destroyed or expires , respectively.

Note 

Often, the identifier used to distinguish unique sessions, commonly called a session ID, is thesame thing as the access token.

Note 

HTTP Basic authn takes the old-fashioned approachit replays the original Base 64encoded username:password in the HTTP Authorize header for every subsequent request in the same realm.

Clearly, access tokens provide great convenience for the user, but as always, convenience comes at a price. By guessing, replaying , or otherwise impersonating someone else's token, a malicious hacker might be able to view data or perform actions that are normally restricted to other users (so-called horizontal privilege escalation), or even administrators (vertical privilege escalation). On the server side of the authorization equation, ACLs may be misconfigured to inadvertently permit unauthorized users, or vulnerabilities may exist that permit bypass of ACLs in certain scenarios.

An important point to highlight here is the dual goals of attacking authorization: hijacking the authorization/session token used by the application and/or bypassing server-side ACLs. This chapter is organized primarily around these two aspects of authz and is divided into the following major sections:

• Fingerprinting Authz

• Attacking ACLs

• Attacking Tokens

• Authz Attack Case Studies

• Authz Best Practices

In many ways, authorization is the heart and soul of any system of security controls, and as you may agree by the end of this chapter, no web application can survive having it excised by a skillful adversary.