OWASP Top 10 2017 – A10 Underprotected APIs

Number 10 on OWASP’s list of application security risks is underprotected APIs. An API with bad security can let an intruder cause serious trouble. It could let someone grab confidential information or even take control of processes on the server.

Badly designed APIs have contributed to some serious security issues. In 2015, a researcher showed that the Moonpig greeting-card site used an API that made it easy to steal credit-card data. Flaws like that one can go unnoticed because the API isn’t directly visible to users.

What makes API vulnerabilities different

Testing APIs for vulnerabilities requires a different approach from other types of weaknesses. Simply exercising the user interface won’t catch the problems. Testing has to happen at the API level, not just the user level.

OWASP notes that the complexity of protocols and data can make API testing difficult. Many APIs use well-known protocols, such as REST, SOAP, and JSON. The wide availability of tools and libraries helps in testing them. Some API creators devise their own protocols or deviate from standard use of the well-known ones. Data arguments under any protocol may have a lot of options and special cases, making exhaustive bug checking difficult.

The very act of publishing an API gives information about how the underlying application works. It tells anyone who reads it what kinds of data and actions might be available.

Testing what an API does with legitimate data isn’t enough. To be safe against attacks, it has to withstand malformed and out-of-spec data. Testing has to cover these cases.

The risks

Underprotected APIs can present many kinds of hazards, including these:

  • Exposure of confidential data. Someone intercepting requests and responses might find passwords, personal financial information, or other high-risk data.
  • SQL or other injection. API requests, like form fields, may contain characters to make the processing software parse them incorrectly. The software might hand part of the command to the SQL processor, giving the request direct access to the database. JavaScript injection may be possible in some cases.
  • Buffer overruns. Software designed to accept only a certain number of data bytes in an argument may behave unpredictably when they get longer arguments. Sometimes this lets an attacker overwrite executable code.
  • Authentication weaknesses. If the software’s authentication isn’t strong enough, an attacker might be able to impersonate a privileged client and request confidential data or launch an illegitimate action.
  • Improper authorization. Granting too much authorization to anonymous or low-level users might let them perform actions that only the most privileged client processes should be able to perform.
  • Excessive resource consumption. A malicious request might consume system resources that don’t get released. Knowing this would make application-level denial-of-service attacks easier.

How attackers exploit APIs

The people who devise online attacks have made them steadily more sophisticated, and APIs haven’t escaped their notice. They can exploit flaws in APIs that are open to the public, as well as getting around authorization requirements. They know about common vulnerability patterns and devise attacks to take advantage of them. Even functions which require an authentication token might be vulnerable.

An attacker might be able to defeat weak authentication measures. On a public computer, “dumpster diving” into browser history could discover reusable authentication data. Brute-force guessing of credentials might gain access.

Guarding against underprotected APIs

OWASP makes five recommendations:

  1. Use secure communications. API requests need to be sent by a protocol, usually HTTPS, that will encrypt data and prevent interception.
  2. Use a strong authentication scheme and secure all credentials. It should be as hard as possible for an attacker to guess or steal access credentials.
  3. Make sure the parser configuration is hardened against attack. This includes making sure that very long parameters, mismatched delimiters, and unexpected characters won’t make the parser misbehave.
  4. Implement suitable access control. Clients should be able to perform only the functions appropriate to their role. Some functions may be appropriate for the public, some for authenticated users, and some only for administrators or internal processes. Granting access too freely can open weaknesses.
  5. Protect against all kinds of injection attacks. This is related to parser hardening. The software needs to make sure it never interprets part of a request as something in a different context.

Testing APIs for vulnerabilities

As already mentioned, testing APIs is a very different process from testing websites. It requires devising scripts to cover all the possibilities, including ones which the developer never thought of. The tests need to cover every sort of use and misuse. They need to include not just well-formed requests, but ones with bad syntax and data. Mismatched delimiters, disallowed characters, and excessively long parameters should all be in the testing mix.

Automated testing should be part of the development process. Each software update should undergo API testing as part of its validation and release process, so changes don’t open new security holes.

The tests should exercise the security measures. What happens if the software gets invalid or expired credentials? What if it gets a request that isn’t allowed with the credentials being given?

Testing needs to check that when errors occur, they’re handled in the right way. Bad error handling might expose internal information; for instance, it might return a stack dump that exposes details of the code’s operation. It might fail to release resources, so that repeating the request enough times would bring the software to a standstill.

APIs, just as much as forms and scripts on a website, need careful attention to make sure they don’t open security holes. It can’t be just an afterthought. The work to keep APIs safe has to go on throughout the development process.