WTEU-56 – Security testing for APIs

padlocks

Date: Sunday 19th April 2015

Time: 3.30pm – 5.30pm BST (click here to check your local time)

Facilitator: Dan Billing

Attendees: Teri Charles, Christian Legget, Bhagya Mudiyanselage, Gagan Talwar, Kadri-Annagret Petersen, Suma, Elena Toropova, Christian Kram, Sandeep Garg, Toby Sinclair, Sarah Pimentel, Srinivas Kadiyala, Amit, Roman Parkin, Namita Jain, Ash Winter

Session Transcript: WTEU56 Session transcript

This time round at Weekend Testing Europe we discussed the issues and thinking around testing for security on APIs. This followed on from a fantastic session with Amy on the Songkick API a few months ago, and the earlier security sessions that we ran last year.

Initially we discussed the importance of APIs to modern web and mobile applications, and therefore the implications of security problems surrounding them. To illustrate this we talked about the recent publicity of the Moonpig API security flaws. We looked at how the Moonpig API could have caused financial and personal data loss for their customers, and potentially the legal ramifications of the lack of legal protection.

Links to the Moonpig articles can be found below.

So to our practical exercise. We explored the deliberately insecure API for the Supercar Showdown website, at hackyourselffirst.troyhunt.com, which form the basis of Troy Hunt’s Pluralsight Course, Hack Yourself First and Hack Your API First. We discussed the course, which was extremely useful and valuable learning, sharing some of our experiences. The API handles the following aspects of the application, which we explored as a team:

  • User records
  • User Login
  • Supercar leaderboard
  • Supercar records
  • Supercar voting

User Records

The GET request hackyourselffirst.troyhunt.com/api/admin/users brings back all the user records from the API. The team quickly identified that there was no kind of authentication for the API. It did not require any credentials or tokens with which to identify themselves as an authorised user. For public APIs this would probably not be an issue, but for APIs that are not public then this would cause all sorts of security problems. Also, the API does not use HTTPS, another red flag for testers to spot very easily.

Let’s look at the types of data returned from the API.

{
“UserId”: 2,
“Email”: “sebastianvettel@f1.com”,
“FirstName”: “Sebastian”,
“LastName”: “Vettel”,
“IsAdmin”: true,
“Password”: “sunshine”
},
{
“UserId”: 3,
“Email”: “kimiraikkonen@f1.com”,
“FirstName”: “Kimi”,
“LastName”: “Räikkönen”,
“IsAdmin”: null,
“Password”: “iloveyou”
}

Here we can see that the users GET request returns some interesting data. The team spotted that the UserIds were easy to enumerate, meaning we could guess the user ids of any given user. Email, First Name and Last name is potentially sensitive data also. Ash Winter suggested a mitigation for this problem, where user ids were generated using long, random strings called GUIDS, which is a common form of data identification and management.

Also a potential avenue of attack was the fact that the IsAdmin flag is visible. It allows a potential attacker to be able to identify admin users, and once they know the password, they can use this information to log in as an admin user.

On to the password. It is common sense to not be able to extract login credentials from any API, depending on its use. Here the password is totally un-encrypted, so would give a potential attacker full access to any user, if they were able to access the API.

Supercar Leaderboard and Records

The Supercar Leaderboard GET Request hackyourselffirst.troyhunt.com/api/supercar/leaderboard response returns the following data:

{
“SupercarId”: 3,
“Make”: “Pagani”,
“Model”: “Huayra”,
“PowerKw”: 539,
“TorqueNm”: 1000,
“ZeroToOneHundredKmInSecs”: 3.3,
“WeightKg”: 1350,
“EngineLayout”: “Twin-turbo V12”,
“EngineCc”: 5980,
“TopSpeedKm”: 372,
“Votes”: 25
},
{
“SupercarId”: 5,
“Make”: “Koenigsegg”,
“Model”: “Agera R”,
“PowerKw”: 850,
“TorqueNm”: 1200,
“ZeroToOneHundredKmInSecs”: 2.8,
“WeightKg”: 1435,
“EngineLayout”: “Twin-turbo V8”,
“EngineCc”: 4998,
“TopSpeedKm”: 440,
“Votes”: 10
}

This data doesn’t especially cause us any issues. It is just returning specifications of the vehicles in the database. Theoretically we could tamper with the request in some way, to perhaps update or delete vehicle data, or even corrupt it. It does not however support a POST request, which might allow this. Worth exploring though.

We did notice that when we requested individual car data, the API would allow us to see who voted for each car, and their personal data. Not great:

{
“SupercarId”: 5,
“Make”: “Koenigsegg”,
“Model”: “Agera R”,
“PowerKw”: 850,
“TorqueNm”: 1200,
“ZeroToOneHundredKmInSecs”: 2.8,
“WeightKg”: 1435,
“EngineLayout”: “Twin-turbo V8”,
“EngineCc”: 4998,
“TopSpeedKm”: 440,
“Votes”: [
{
“Comment”: “Whoa – this thing is faster than my work car!”,
“FirstName”: “Giedo”,
“LastName”: “van der Garde”,
“Email”: “giedovandergarde@f1.com”,
“Password”: “pennywise”
}

Voting

More interestingly, we identified that it might be possible to circumvent the user interface, which prevents multi voting. However, the API will allow multiple votes for each car, for any user id. It is simple to demonstrate and replicate using tools like The Postman, Fiddler or any other proxy tool.

Error handling

We explored the impact of error handling on the API, where we tried to trigger error handling by injecting untrusted data into the API. This sometimes returned very verbose errors, exposing interesting information to a potential attacker. This is always a great way to discover potential avenues of attack.

Summary

During the session we dug into an exciting and important topic. Exploring a known vulnerability which made the news gave the team a great way to understand the context of the discussion. And through the exploration of a vulnerable app, an exciting way to put that understanding to practical use.

We didn’t do anything overly technical, with complicated tools. It was about exploring and observing the conditions of a vulnerable API in the context of the security of that application. We were able to identify sensitive data through simple requests, and discussed methods of mitigation and other avenues of attack.

All in all, this was a rewarding and enjoyable session. The subscriptions for this session were the highest I have ever seen, numbering into the hundreds. This was really encouraging and exciting to see. If anyone missed out, then I apologise. I’d like to thank the attendees for making the session worthwhile, and contributing their own learning and curiosity to the session!

Resources:

Web API: http://www.asp.net/web-api

Pluralsight Course – Hack Your API First: http://www.pluralsight.com/courses/hack-your-api-first

The Moonpig Breach:

http://www.ifc0nfig.com/moonpig-vulnerability/

http://www.developer-tech.com/news/2015/jan/08/moonpigs-api-breach-could-cost-its-business/

Oauth 2.0:

https://developers.google.com/identity/protocols/OAuth2

http://www.asp.net/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server

Hack Yourself First/Supercar Showdown API: http://hackyourselffirst.troyhunt.com/help

GUIDs: https://www.guidgenerator.com/online-guid-generator.aspx

Facebook Graphs API Documentation: https://developers.facebook.com/docs/graph-api

Beautiful Rest and JSON API Video. Les Hazlewood: https://www.youtube.com/watch?v=hdSrT4yjS1g

API Security Testing – How to Hack an API and Get Away with it (Part 1 of 3): http://blog.smartbear.com/readyapi/api-security-testing-how-to-hack-an-api-and-get-away-with-it-part-1-of-3/

API Directories: 

http://www.programmableweb.com/apis/directory

http://www.publicapis.com/

Tools: 

JSON Viewer: http://codebeautify.org/jsonviewer

SOAP UI: http://www.soapui.org/

The Postman: https://www.getpostman.com/

About the Author

Dan Billing has been a software test engineer for 13 years, he currently works at NewVoiceMedia. Dan loves testing, and all its wondrous variety. He tries to help others become better testers by attending events, speaking, blogging and giving training. Dan has a reputation for being knowledgeable about including security as part of testing. You can find him at thetestdoctor.wordpress.com or on Twitter.