Each time you publish an API, you punch a hole in your enterprise perimeter. Through API attacks, a lot of critical data which used to be well-protected in enterprises data centers is now exposed directly to the Internet. Whenever you create APIs, you have to make sure that you have done everything you could to validate data flows, properly authenticate users, authorize access to the data, keep an audit trail among other security tasks.
Isabelle Mauny. is the co-founder and CTO of 42Crunch, a company on a mission to make API security as easy as possible for developers and security teams. She spoke at Codemotion about the roots of current API security issues, and how you can address them at development time. It’s an extensive talk with plenty of code to deep dive into, so we encourage you to watch the video below to gain the full experience:
API attacks are key points of entry to hackers
Historically, API attacks have largely flown under the radar of security professionals, who have been focused on attack vectors known to do significant damage: ransomware, distributed denial of service (DDoS), and malware, among others. But APIs inherently lack security which makes them an easy target for cyberhackers.
API’s are now the new entry point into your companies into your data, your processes, and it’s becoming a very important threat factor. While API data breaches often occur because of third party actors, in many cases, simple failures to treat API security with respect leads to some significant data breaches that affected many millions of users.
The API attack at Equifax
In September of 2017, Equifax announced it experienced a data breach, which impacted the personal information of approximately 147 million people. The data breach was attributed to an exploit of a vulnerability in an open-source component, Apache Struts CVE-2017-5638. Struts is a mainstream web framework used to create web applications and APIs.
Equifax is not alone. API attacks are on the rise. Instagram recently became a victim, and other victims have included Facebook, Amazon and Paypal.
OWASP and API attacks
The Open Web Application Security Project (OWASP) is a nonprofit foundation that works to improve the security of software. Isabelle is a member and she shared that OWASP recently added under-protected APIs to its Top 10 list of app vulnerabilities, a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.
It’s a recognition that API security is NOT web security. Rather APis have different attack vectors. They are data-centric and there are lots of attacks coming from mishandling API data.
The Pixi-CRS Continuous Integration pipeline provides automated end-to-end testing of the intentionally-vulnerable Pixi application with a Web Application Firewall (WAF) in front of the application, and an automated security vulnerability scanner and web proxy (“ZAP”, OWASP Zed Attack Proxy) pointed at the application and WAF. It’s part of the OSWAP DevSlop.
According to Isabella: “It has all the problems in a single place, but it’s very useful to illustrate the problems in what we find So you have access to that you have the source code, you can see how it works.”
What can you do?
- Use non-guessable IDs (UUIDs)
- Implement authorization checks to validate the user actually owns the data they are trying to retrieve
- Don’t expose internal IDs externally – instead, use a non-guessable ID you then map to internal IDs.
Prevent APIs attacks and Access Token misuse
- Access tokens are used for authentication purposes
- A single token allows access to many APIs and operations
- API keys and OAuth secrets are leaking all over GitHubWhat you should do
- You should restrict token use
- Google APIs example (restrictions on referrers, APIs, list IPs)
- Oauth scopes
- Fine grained authorization (such as attribute based)
- Don’t rely on access tokens to authenticate a user (use OpenID connect instead)
- use short lived access tokens
- authenticate your apps (so you know who is talking to you_
How to detect vulnerabilities that could cause API attacks
Isabelle suggests that you “Put some filtering in place of your data, What is the sensitive data that you manipulate? You need to make sure that that information can never leave through the API unless you want to in a certain way, but it really shouldn’t. So you have to put in place some filtering and authorization.”
How I could have hacked any Instagram account
Last year a security researcher and bug hunter, Laxman Muthiyah, found an account-breaking bug in the mobile version of Instagram’s password reset system. When a user wants to reset his or her password, Instagram tries to validate their identity by sending a 6-digit code to a recovery phone number. They have to enter that code within 10 minutes to be able to change the password. Instagram developers had implemented a rate-limiting mechanism to prevent attackers from brute-forcing the six-digit code, but the researcher identified a way to bypass it. The researcher noticed that if he sent 1,000 requests containing possible verification codes, 250 of them would go through while the rest would be blocked. He then used what he described as a combination of a race condition and IP rotation to send out a total of 200,000 requests.
The researcher created a race condition, a situation that occurs when a computer tries to process multiple requests at the same time — and by making attempts from a huge number of IP addresses was able to do an end run around Instagram’s brute force blocker. He then bombarded Instagram with 200,000 codes from 1,000 different IP addresses. This was made quite simple using cloud-based tools.
Laxman earn $30,000 from Facebook for this efforts.
Blocking unauthorised calls
Isabelle asserts the needs to be mindful of the power of resource-level access control: “What am I authorised to see and do when I connect somewhere. Are there any things that you have left in an API that you don’t expect people to use? I’ve seen that many times in the same API, I have admin function to manage users, for example, and non-admin functions, which are the ones I’m exposing outside.
For example, there’s a single API except I’m just telling people from outside you can use those for permissions. And telling the people from inside, you can also use those operations right, but they are In the same API. Mixing admin and non-admin all together, that’s a very common example of a problem.” Hackers can then use bots to guess which potential paths are open (say GET/admin/user) and get access to things that should be hidden.
What do else you can do to reduce API attacks
- Detect whether verbs not specified in the API contract can be used
- Systemically reject any path not described in the API contract
- Validate that the user has proper access rights.
- Test everything, don’t trust any data!