Black Hat Takeaways, API Security Roundtable: Lessons Learned in API Security

At Black Hat, Zane Lackey (Signals Sciences, Internet Bug Bounty Program), lead a well-attended discussion about the need to be more thoughtful in our design and implementation of APIs. Externalized APIs are enabling new information sharing paradigms between business partners, and increasing consumer input of ePHI and PII directly to organizations servers. As CISOs, we need to be mindful of these business practices and ensure proper risk management over the data flowing through these APIs, which can become targets of interest for cybercriminals or other malicious actors.

The Black Hat discussion focused both on offensive risk (where are attackers finding success) and defensive tactics to improve overall API security. Here are some of the key takeaways:

On the offensive side, attacks across programming languages and application stacks but fall into in several consistent categories:

1. Bypassing authorization schemes
2. Bypassing data validation
3. Evading API limits

Bypassing Authorization

A primary focus of an externalized API is the correct authorization for the specific API call. Proper authorization is the first step in bounding the scope of the requestor to the desired limits of the API developer. However, designing proper authorization models that correctly flow through the entire application stack is not an easy task. Some of the offensive techniques shared include the following:

• Finding secrets embedded in applications, authorization keys for example
• Substituting an identity in an html request with an injection because the identity is visible
• Failure to validate that the API is authorized before the code starts parsing the request
• Intercepting the multifactor authorization required check and returning "no" effectively deprecating the authentication to single factor
• Lack of good device identification and failure to tie the device ID to the authorized user
• Losing the original identity of the requestor as the request gets passed through the API stack
• Password enrollment and recovery having different processing paths with different assurance models

Bypassing Data Validation

Verifying that the data included in an API request is within scope, format and character is an ongoing battle for developers. There is a well-known tradeoff between verifying every input field at every level in the call stack and efficiency. The participants shared some common logic and design flaws that can be readily exploited. For example,

• Entering the API stack from a different workflow entry point, effectively bypassing input verification.
• Finding and leveraging developer or debug APIs left in production code
• Rolling back an API call but leaving the code execution privilege higher than the original requestor's privilege.

Evading API Limits

The third category of API circumvention technique discussed was evading API Limits. API limits are designed to mitigate a number of risks such as denial of service, mass data exfiltration, over consumption of resources by a few parties, etc. The round table participants highlighted the following as examples of practices that lead to API limit circumvention.

• Xforwarder injections
• Overrunning limits that are established on APIs but aren't enforced correctly
• Finding and exploiting APIs that should have limits but don't (for example enumerating through an entire database)
• Losing the original authentication or authorization context so you can't apply the correct limits

Defending APIs from potential vulnerabilities and targeted attacks

The group also discussed what techniques and mitigation strategies they are evangelizing or deploying within their organizations. While not all of these techniques are practical - for example if you have legacy unmodifiable code, knowing your risk is the first step to mitigation. The group suggested both design philosophy as well as practical implementation tips including:

1. Expect APIs and Methods to be discovered and program accordingly, don't rely on obscurity to keep a hacker from                 locating and exploiting your APIs.
2. Use graphing and instrumentation of the APIs to monitor API use for abuse and to discover APIs that were not intended to be external facing.
3. Design in the ability to enumerate and revoke API keys.
4. Use existing tools and vetted libraries rather than creating your own, especially in conceptually complex areas examples including:
            a.     Cryptography
            b.     Authorization - xacml 3.0 for example
            c.     Authentication - google Oauth library
   
5. Break APIs into micro services, which run on separate instances or servers and are firewalled so only appropriate API traffic is allowed.
6. Design in versioning on your APIs, even if they are not public, for compatibility and future proofing.
7. Correlate API logs across servers for better visibility.

This roundtable was specifically focused on reducing API risk though programming specifically, and there are certainly other methods for reducing risk in externalized APIs. What are you doing? Is your organization embracing the use of external APIs or do you find the practice still too risky? We'd love to hear more thoughts on best practices and practical tips from our colleagues.