Top 25 Series - Rank 5 - Improper Access Control (Authorization)

Foursquare is a mobile app that lets you "check in" to a location and tell your friends about it. If you check in someplace often enough you can, among other things, become the "mayor" of that location. If you're the mayor you can even sometimes win free food ^[1]. Normally, people are supposed to actually visit the physical location to earn a mayorship or associated badges but Jim Bumgardner recently showed how he could, without physically visiting the location in question, become the mayor of various spots all over the world, including the North Pole ^[2,3,4].

In his case, he used Foursquare's API to check himself in to various locations by using curl from the command line:

curl -u EMAIL:PASSWORD -d "vid=993842" http://api.foursquare.com/v1/checkin

As you can see he actually authenticates to Foursquare using a valid email and password. But once authenticated, Foursquare doesn't validate that you're at the location itself. Granted, there are other issues that Foursquare has to consider in relation to fake check ins but, essentially, the service is not validating that Jim is authorized to check in to that particular location.

CWE-285 is about improper access control ^[5]. In general, applications should allow access only to those who are permitted. This means preventing users from directly invoking functionality when they don't have the proper permissions. This is usually accomplished by designing your application to enforce access control checks at the appropriate boundaries like URLs or even method calls in your business service layer. This should be done with a default deny policy.

1.  http://twitter.com/PatxisPizza/status/7342232719
2.  http://www.krazydad.com/blog/2010/02/mayor-of-the-north-pole/
3. http://techcrunch.com/2010/02/16/foursquare-cheating/
4.  http://latimesblogs.latimes.com/technology/2010/02/confessions-of-a-foursquare-cheater.html
5. http://cwe.mitre.org/top25/#CWE-285