It's so well known that it has a name - MAfA

"Karp, Alan H" <[email protected]>
Newsgroups gmane.comp.capabilities.general
Message-ID <8AD823089998C849A832D86972E69CD54192AB62@G9W0755.americas.hpqcorp.net>
A while back I reported finding a vulnerability in the published IETF specification for User Managed Access (UMA) that arose when sharing resources.  UMA is based on having an authorization manager (AM) implement access policy on behalf of the user.  Say that Alice has a relationship with an AM.  Her initial policy says that only someone authenticating as Alice can access any of her resources, such as photos.  When Alice wants to share a single photo with Bob, she tells the AM which photo to grant access to when a specific credential, such as a client secret, is presented.  Alice tells Bob the secret, and Bob gets access to the photo after getting an authorization token from the AM.  Clean, simple, and very capabilityish.  

Here's the problem.  The UMA spec never mentions checking Alice's permission on the photo!  That means Alice can designate any photo she can guess the name of, even if that photo belongs to someone else who uses the same AM.  I've learned that this mistake is common enough to have a name, Mistaking Authentication for Authorization (MAfA, an acronym I just made up).  In this example, the AM has made sure that Alice authenticated, but it never checked her authorization for the resource she named.  A similar vulnerability was found in several password managers, and I bet it exists elsewhere.  A simple fix is to make the resource designations unguessable, but apparently developers don't do that.

With capabilities MAfA corresponds to allowing a delegation of a capability to have more authority than the original.  I'm sure someone somewhere will make that mistake, but I expect it will happen far less often than with conventional access control.

________________________
Alan Karp
Principal Scientist
Enterprise Services, Office of the CTO
Hewlett-Packard Company
1501 Page Mill Road
Palo Alto, CA 94304
1 (650) 386-4568
http://www.hpl.hp.com/personal/Alan_Karp
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.