How-to Protect Your APIs from OWASP API Security Top Ten (part two)

This is the follow up to my first part of OWASP API Security top-10 where we introduced the list and looked at items 1 through 5. In this blog we’ll cover the bottom half of this top-10.

API6:2019 Mass Assignment

At the top of the list was BOLA – a lack of authorization at per-object level. In the case of Mass Assignment, the lack of authorization is one step finer in granularity. Mass Assignment occurs if the authorization given to a particular object has no boundary and hidden properties can incidentally be exploited.

Imagine an API interaction to control user properties as part of an application:

Assuming no BOLA vulnerability, this action would require a permission check to ensure that only the right users can affect this resource (i.e. the user itself). However, if there was a Mass Assignment vulnerability here, a malicious user would be able to do something like this:

Many things would need to go wrong in such a case for this exploit to work, but assuming your API accepts this input, and that it does not limit the attributes you can assign in such a situation, then one could easily elevate their privileges and use that new privilege to disrupt the service or breach data. If your API is designed this way, you may want to reconsider how membership management is achieved but what if this is not part of the API design but a ‘hidden’ feature that is not tested against? Maybe an underlying technology consumes this attribute, and the API designer is not even aware of its existence.

This type of vulnerability is, yet again, a great demonstration of the benefits of input sanitization.  Validating structured API inputs such as JSON structures against schemas that define what is in scope of the API protects against such vulnerabilities. This type of validation is commonly implemented using our API gateway leveraging schemas and other metadata fed into its configuration.

API7:2019 Security Misconfiguration

Security misconfigurations take many forms, but how do they relate to API Security? The API channel is often the channel through which the misconfiguration is detected or exploited. One of the examples presented in the OWASP API Security project is an error message returned from a malformed request that would return too much information, like a stack trace in debug mode, revealing implementation details which can help find other vulnerabilities. Maybe there is a lack of hardening or default modes that have an API implication.

API8:2019 Injection

APIs can be vulnerable to many types of Injection attacks such as SQL injections, LDAP injections, command injections, etc. Just last month, we saw one of the biggest zero-day vulnerability hit the world – Log4shell. APIs feed inputs into systems connected leveraging Log4J. Through an API call, you can inject a JNDI remote call. I recently wrote about this here.

At the core of managing this type of vulnerability is the pattern of input sanitization. Input sanitization can be applied by validating incoming API requests against a schema or API definition. Injection prevention is often focusing on signature-based threat detection (e.g. evaluating a regex that indicates a sql injection pattern) but whitelist-based input sanitization (where applicable) trumps blacklist-based input sanitization. Examples of whitelist input sanitization is to validate that a parameter is one of only a few possible values, or it only contains alpha-decimal characters, or must be x characters long exactly. Rejecting any input that falls outside known possible values is a more focused protection rather than only rejecting values that match known patterns of injections. Using both strategies is sometimes necessary because parameter values are not always finite and because whitelist-based rules demand more knowledge of the business logic of an API.

Input sanitization is a best practice that applies across the stack, API gateways in particular provide specialized tooling to inspect API traffic and apply validations at the edge, even if backend API coders apply their own validations. 

API9:2019 Improper Assets Management

You can’t secure what you don’t know exists. APIs sometimes don’t receive the security scrutiny they deserve because security teams aren’t aware of them. Improper asset management happens when APIs are not on the radar of the API security or the API management teams. This happens because some APIs are considered implementation details that are only known by a subset of developers, or old versions of an API persist after an upgrade for temporary backward compatibility reasons and are gradually forgotten about, or when pre-prod versions of APIs are not taken down and somehow connect to real systems in the backend.

API10:2019 Insufficient Logging & Monitoring

Bugs happen, data is breached. Your ability to detect breaches on an API in a timely manner is critical to reducing damage and preventing further attacks. Even if the breach was blocked, the details of the attempt can lead to security posture improvement. Logging and auditing capabilities on your APIs help you get to the bottom of how attacks are conducted, which specific data was compromised, and identify malicious parties (or even friendly, see API4) which you may want to block moving forward.

For high traffic APIs, one cannot simply read through all the logs in real time waiting for attacks that get through. Consider defining baseline API traffic properties based on trends, and generate alerts that are triggered when thresholds are exceeded. 

API Gateways provide API logging and auditing. These should be configured to capture relevant API traffic properties and additional context such as where and whom from API requests originate. The clues to unusual activity go beyond properties of API clients, the way that your API reacts (backend API response time, error messages, response payloads) to requests can also be an indicator of unusual activity. API Gateways are also ideally suited for feeding API traffic data to SIEM and big data systems which can further automate anomaly detection in some cases and generate alerts of their own.

Summary

The OWASP API security top-10 list is a helpful reference for teams assessing the security of existing or in-development APIs. Using this resource, combined with an understanding of the API you are securing, allows you to uncover and address API security vulnerabilities.