Authentication & Authorization Assumptions

By Kevin W

Authorization and Authentication came up in a recent discussion of the OWASP Top 10 topics of Insecure Communications and Failure to Restrict URL Access.

Simply put, authentication  is proving who you are, whereas authorization is your permission to do something.  So if a theater is your web application, and an usher is your login method, then authentication would be your ticket, while authorization is your seat number. A very basic way of looking at a security assessment is to think in terms of assumptions: What did the designers and programmers of the system assume when they created it?  How can we work around those assumptions?  What can we do that they didn't anticipate? Say you have a web application that references a particular administrative page.  When that URL is called, does it check both authentication and authorization? 

Scenario 1: Check authorization, not authentication: The developer assumed that a user would already be logged in (authentication) and only checks his or her permissions (authorization) before accessing the admin page. Assumption: "No one would try to use the system if they weren't logged in, right?" 

Scenario 2: Check authentication, not authorization: The developer assumed that only administrators would try to access (authorization) the admin page and only verified that a valid account was logged in (authentication). Assumption: "Only administrators would have any reason to go to the admin page, right?" 

The bottom line:  Don't let one part of your application assume that another part has done its job.  The risk is not worth the coding time or processing time saved by not verifying both authentication and authorization. Developers should be aware of these kinds of assumptions when designing and implementing a web application.  Another way to put it is to assume nothing and take nothing for granted.

--Kevin