OWASP Top 10 #10: Unprotected APIs [Updated 2019]

Modern applications are becoming more complex, more critical and more connected. The difficulty of achieving application security has increased exponentially and unprotected APIs are one of the top web application security risks organizations face.

Compared to Injection, OWASP’s number one web application security risk, unprotected APIs (tenth in the list) are a little less easy to exploit, but the risk is equally prevalent, the danger more difficult to detect and the impact of a breach a little less severe, none of which is very reassuring, particularly in a cloud environment. Read more about building a secure API cloud environment here.

See Infosec IQ in action

From gamified security awareness to award-winning training, phishing simulations, culture assessments and more, we want to show you what makes Infosec IQ an industry leader.

Demo Now

To put the risk into perspective, Insufficient Attack Protection, seventh on OWASP’s top ten web application security risks, concerns an organization’s response to attacks. The risk of an unprotected API, on the other hand, can be seen as a preventable risk - preventable by good coding practices, extensive expert testing and security training for developers.'

If you're interested in Application Security for Beginners: A Step-by-Step Approach, check out this article!

Unprotected APIs Background

Most web applications must of necessity use multiple application program interfaces (APIs) to connect with other applications. They’re application cornerstones because they help developers access web services like Facebook or Pinterest, utilities like Google Maps or Dropbox, or any code that has been exposed for use by other developers and organizations. APIs keep the digital community connected. Facebook’s developer platform, for instance, hosts more than 10,000 applications all built using Facebook APIs.

However, APIs pose serious risks if not used securely. An unprotected API leaves a database open to be maliciously mined by cyber criminals. And we know what happens to stolen sensitive information: it gets sold on the black market, and used to empty victims’ bank accounts, harass them, threaten them, blackmail them and embarrass them.

In the case of the Ashley Madison hack in 2015, security consultant Gabor Szathmari discovered security credentials such as database passwords, API secrets, authentication tokens and SSL private keys hard coded into Ashley Madison's source code. The only surprise is that Madison wasn’t hacked earlier.

Note: While “bad” coding practices seem to be a common thread in unprotected API hacks, it’s also true that many times developers have to be reliant on things they don’t have control over, e.g., security patches or updates for external software and technologies. In many cases, developers inherit projects with existing vulnerabilities and are often unaware of the changing security landscape “out there.” They’re just at it, nose to the ground...being Agile.

Unprotected APIs in the news

The Kardashians

In 2015, the Kardashians launched four new websites and four new apps. Softpedia reported that Alaxic Smith, CEO and Co-Founder of Communly, said that the company behind these new apps and websites, Whalerock Digital Media, left their API server unprotected. He claimed to have easily accessed the API content and was able to browse the site’s entire database. Whalerock Digital Media was notified of the issue and the errant API endpoint was protected from unauthorized access. Since then, Smith’s blog post on the issue has been removed (but the story lives on on in other web sites).

Naughty Androids

In another exposé of seemingly innocent APIs gone wrong, Softpedia reported that security researchers from Avast found vulnerabilities in the Android apps of several online retailers. One, a Target Android app, failed dismally to protect its API which receives queries (via HTTP requests) from a user's phone and then sends the response as a JSON file. This file is read by the app, then the desired information is extracted and displayed on the screen. Target forgot to protect the API by authenticating users who can query for information, a loophole the Avast researchers exploited to gain access to personal information of over 5,000 Target users.

Other apps by retailers like Home Depot, J.C. Penney, Macy’s, Safeway, Walgreens and Walmart apparently failed the Avast security test too.

Wishbone

Created by Science Mobile LLC, Wishbone, a popular teen quiz app, was hacked thanks to another unprotected API. “On March 14, 2017 Wishbone became aware that unknown individuals may have had access to an API without authorization and were able to obtain account information of its users,” the company said. Troy Hunt, a security researcher told Motherboard that he was sent a MongoDB database with Wishbone data on it that included 2,326,452 full names, 2,247,314 email addresses and 287,502 mobile phone numbers, along with user birth dates and gender details. According to Android Community, this unprotected database of teenagers is apparently now circulating the “internet undergrounds.”

McAPI

Blogger Jeremy Kirk in March 2017 reported that McDonald's finally acknowledged that a leaky API exposed personal information for users of its McDelivery mobile app in India. The leak was discovered by a researcher at the cyber security firm Fallible. The leak exposed personal information for 2.2 million users, including names, email addresses, phone numbers, home addresses and sometimes the coordinates of those homes, as well as links to social media profiles.

The problem with APIs

APIs that make access available to backend systems often lack adequate controls and are, by their very nature, difficult to monitor.The breadth and complexity of APIs also make it difficult to automate effective security testing.

Succinctly described in a CA Technologies white paper by Scott Morrison: “The problem with APIs is that they often provide a roadmap describing the underlying implementation of an application - details that would otherwise be buried under layers of web app functionality. This can give hackers valuable clues that could lead to attack vectors they might otherwise overlook. APIs tend to be extremely clear and self-documenting at their best, providing insight into internal objects and even internal database structure - all valuable intelligence for hackers. But increased visibility isn’t the only risk APIs introduce. Increasing the number of potential calls also increases the attack surface, meaning that a hacker simply has more to exploit. Risk increases with opportunity.”

You can check if you have an account that has been breached on the haveibeenpwned website.

How do they do it?

Exposing just how vulnerable unprotected APIs are, Ole Lensmar at Smartbear provides some smart tips on how we can hack an API:

• We should start by provoking an API with unexpected content in the hope that its inability to handle it correctly will teach us something about its inner workings. For instance, a database error has unexpected value; if nothing else, it confirms there is a hackable database available and indicates this is a viable door to keep battering.
• It’s easy to set up a script that runs millions of requests concurrently in the hope that some combination of input parameters will achieve our purpose which is to get a response, any response with potentially useful information, or even exhaust the API. (Have you ever been so inundated with wrong-number calls that you finally blurt out: “My name is Brown, not Green.”)
• Invalid input attacks are quite intelligent as they aim to provoke a target system by sending input that it doesn’t expect. A response like “the date format should be yyyy/mm/dd” is pay dirt for us.
• We can use injection to introduce (or "inject") code into a vulnerable computer program and change the course of execution. When an application fails to properly sanitize this data before adding it to a database query, we can include our own (malicious) commands which the database will execute (see the Cross Site Forgery example below).
• As hackers, we will also be looking for authorization/ authentication standards that are being used improperly – or not at all where they should be. Developer shortcuts and/or incompetence make us rub our hands with glee. We love it when they don’t have security experts to test their code properly.
• To launch a “successful” attack on an API, we need to know as much as possible about the API’s endpoints, messages, parameters and behavior. We can find a lot of this information readily available in API metadata and public documentation that provides us with detailed technical descriptions of an API, including all we need for our attack – paths, parameters, message formats, etc.

In summary:

• Parameter attacks exploit the data sent into an API, e.g., by SQL injection, brute force and invalid input. Even error messages can contain vital clues for hackers to exploit your API’s weaknesses.
• Identity attacks exploit flaws in authentication. Some developers take it for granted that an API key is an authoritative credential. In an ideal world, API keys are used by web and cloud services to identify third-party applications using the services, not for security.
• Man in the middle attacks intercept legitimate transactions. Web users are at risk of man-in-the-middle (MITM) attacks, security firm Sucuri found, after discovering that popular web development languages remain vulnerable to transport layer security (TLS) spoofing and exploitation from revoked certificates. "The HTTPS protocol is used to secure the connection with the API server. However, if your web app doesn't verify the TLS certificate, a malicious person can steal your passwords or your customers' credit card numbers. When implemented correctly, the TLS protocol provides encryption and authentication. The connection between your server and the API server is encrypted using a symmetric cipher (typically AES) so an eavesdropper cannot read your data. The server also confirms its identity (authenticates itself) by sending an X.509 certificate to the client. The client must verify the certificate's signature against the list of known root certificates, but this step is often neglected. As a result, a MITM attack becomes possible."

What you can do

CA Technologies’s Scott Morrison recommends a 5-point defense to help protect your APIs:

• Validate parameters, i.e., sanitize incoming data.
• Explicitly scan for common attack signatures; injection attacks often betray themselves by following common patterns.
• Turn on TSL everywhere; adding SSL/TLS - and applying it correctly - is an effective defense against the risk of man-in-the-middle attacks.
• Apply rigorous authentication and authorization as per standards.
• Use proven security solutions (and libraries) and separate out API implementation and API security into distinct tiers which will free an API developer to focus completely on the application domain.

Training

Developer training and education is essential to build secure modern API backends. An investigation by Redlock Inc, a cyber security company, found that “... 40 percent of organizations using cloud storage services such as Amazon Simple Storage Service (Amazon S3) had inadvertently exposed one or more such services to the public.” RedLock emphasized that the AWS issues weren't caused by the cloud platform itself - they resulted from poor configuration practices on the part of cloud users.

Nordicapis asserts that, “Perhaps the biggest vulnerability is one that originates earliest in the API development lifecycle - improper coding.” Security is the responsibility of the API developer, not the consumer of the API. A useful member of an API development team is the White Hat Hacker. Do not underestimate the value of hiring outside members to commit penetration testing on your API. Expert security testing can help identify vulnerabilities, and rectify them before they become full-on exposures.

As far back as 2012, concerned developers observed that shorter development cycles, particularly in mobile development, were taking their toll on what would normally pass as standard security development practices. Researching the security of various Android apps, Godfrey Nolan, founder of RIIS, a web and mobile development company, told TheServerSide that: “Out of the hundred or so APKs that we’ve downloaded, we would say that only one was well protected, and everything else had information that was leaking or was available just in plain text if you reverse engineered the code.”

Some tips for organizations building their own APIs:

• Take stock of what data should be publicly available and what is sensitive information.
• Does the API access business critical data or functions?
• API code should be checked by a security expert to test whether it could be abused or misused by an attacker.
• Internal API documentation should be mandatory.
• Black-box, fuzzing, penetration and vulnerability tests should be carried out.
• Agile methodology should take a back seat to proper testing before implementation.
• The use of APIs to access sensitive information should be minimized, where possible.
• Ensure that you have a strong authentication scheme for your APIs.
• Discussing company API development on forums should be avoided.

Conclusion

The first step in preventing cyber attacks via unprotected APIs or any other security loop hole is proper security training, and even better, training to help you think like the criminals do. InfoSec Institute provides security awareness training, ethical hacking courses and a wide range of resources to help you use APIs more securely, e.g.:

• How to secure public APIs
• Web services penetration testing
• iOS application security
• Developing secure Java code

Here Are Some Other OWASP Top 10 Elements

OWASP — Insufficient Attack Protection

OWASP – Broken Authentication Session Management

OWASP — Cross-Site Scripting (XSS)

OWASP — Broken Access Control

OWASP — Security Misconfiguration

OWASP — Insufficient Attack Protection

Get six free posters

Reinforce cybersecurity best practices with six eye-catching posters found in our free poster kit from our award-winning series, Work Bytes.

Download Now

OWASP — Using Components With Known Vulnerabilities