This week, we check out the details of two API vulnerabilities at Uber and Get, the updated 42Crunch API security platform, and Red Hat’s vision of the future of API management.
Vulnerability: Uber
Anand Prakash found a way to do full account takeover on Uber through a vulnerability in their APIs. The same approach worked with accounts for any Uber services, including drivers and Uber Eats:
- Make an invalid
addDrivercall (that includes the phone number or email address of a user.) This makes the API leak the UUID of the user in question in the returned error message. You could even create a script to iterate the calls to get the UUIDs for many Uber users. - Make a
getConsentScreenDetailscall with the UUID you got. This call leaks all user info for the given UUID, including the mobile app auth token. You now have what it takes to fully take over the account.
Thankfully, Uber fixed this one quickly after it was brought to their attention.
Lessons learnt with this one:
- Make sure that errors never leak any sensitive information, and define your API outputs including errors carefully.
- No unauthenticated API calls should ever provide any sensitive information.
- No unauthenticated calls should ever provide an authentication token!
Vulnerability: Get
Get (formerly Qnect) is a popular app for university societies and clubs. It operates in four countries, has 159K active users, and 453 clubs.
An Australian student found out that the API behind the Get app was not protected. Even worse, the API gave unlimited access to all users and their personal information, such as names, emails, phone numbers, dates of birth, and Facebook ID’s.
If you are an application developer, please remember that your APIs are not just an implementation detail! People will try to figure out how to invoke them directly:
- All APIs must be protected.
- APIs should not be giving the client more data than what the client needs.
Tools: 42Crunch Platform
42Crunch has rolled out an update to their API security platform.
The biggest new feature is that API Firewall now offers also non-blocking mode. This mode lets you run the protection configuration for your API as read-only. API Firewall still detects and logs all calls to the API that breach the API contract but does not block the calls. This helps you to assess the impact to your existing API traffic without impacting your API consumers.
In addition, the developer tooling in the platform also got enhancements, such as the improved integration between the API Contract Security Audit and Security Editor, and UX improvements to the audit report.
Opinion: The future of API management
SD Times published an interview with David Codelli (3Scale / Red Hat) about his views on the future of API management. Here’s a quick summary of the main points:
- Service meshes make API management vendors rethink what they want to secure and when.
- API management needs to move to code (like infrastructure did with Kubernetes).
- When designing API security, internal APIs need to get the same care and attention as the public ones.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
