APIsecurity.io - APISecurity.io Newsletter: Issue 153

This week, we have a keynote speech from author and cyber entrepreneur Alissa Knight at the HackerOne Security@  virtual conference, in which she discusses how the rapid proliferation of APIs is opening up security holes.

Knight is an active API security researcher who believes that only now are we gaining a full insight into the risk that APIs expose as the industry collects more and more statistics around API security. The most well-known API-related vulnerability is broken object-level authorization (BOLA) which Knight likens to “the scenario to a coat check where the employee behind the counter looks at a person’s claim number but doesn’t notice that the number had been changed with a marker”.

Knight’s prominent research in recent times relates to API vulnerabilities in connected police vehicles, which allowed her to remotely lock and unlock the car doors, or start and stop the engines. The key takeaway in this research was the lack of certificate pinning, allowing a researcher (or an attacker) to use a proxy like Burp Suite or Mitmproxy to perform man-in-the-middle attacks on the remote systems. Where certificate pinning was implemented at all, there were shortcomings in the implementations.

Knight’s research has also included hacking 30 financial services and fintech companies using their APIs and uncovering  significant vulnerabilities, such as being able to change arbitrary PINs or transfer funds. Her opinion is that as banks tend to outsource much of their development, which results in issues being systemic across all banks.

The full content of the HackerOne Security@ conference is available here. Knight’s keynote “The Best Kept Secret in Cybersecurity“ is the first on the list.

This week also saw another vulnerability in a popular WordPress plugin, Ninja Forms, exposing key WordPress data through the WordPress REST API.

WordPress exposes its core functionalities through a REST API. Whilst the WordPress API requires authentication, vulnerabilities often arise from plugins that implement authorization inadequately. As recently as in our issue 147 we covered a similar vulnerability in the SEOPress plugin, which failed to fully validate API requests.

In this instance, the Ninja Forms plugin provided a permissions callback (invoked by the WordPress core to validate a client’s permission levels based on a particular API call). This callback checked if a user was registered. However, it failed to check if the user had a permission to execute bulk export of all forms submitted using the plugin. This is a significant case of sensitive information disclosure because such information could include sensitive information, like emails or other PII.

The plugin provider has since patched the vulnerability, and uses are advised to upgrade to the most recent version of the plugin.

The key takeaways:

• The failure to fully validate API requests is a leading factor in vulnerable APIs. In this particular case, we saw an example of OWASP API:5 Broken Function-Level Authorization.
• Authentication is not enough on its own. Authorization needs to be in place, too.

An interesting article for me this week was the further coverage on API vulnerability scanning and the dangers of false-negatives lulling the security team into a false sense of security. Last week, I had discussed a similar topic relating to shortcomings in traditional SAST/DAST tools.

The author Troy Hawes describes the importance of performing security testing of APIs and summarizes the management of API risk concisely as follows:

• APIs aren’t a part of vulnerability management programs and are overlooked
• Information security teams lack the knowledge to thoroughly test APIs
• APIs are tested generically and false negatives provide organizations with a false sense of security
• APIs are only tested by the development team
• APIs aren’t considered with an adversarial mindset

In particular, it is the third point that is paramount. My article concluded that reliance on SAST/DAST testing could result in false-negatives, in other words missing the detection of vulnerabilities within an API implementation. The author claims that “if you’re scanning your APIs with generic vulnerability scans or even web application scans, then you’re likely missing eight out of 10 of the top API vulnerabilities”.

The other key takeaway here is that automated testing — whilst valuable — is unable to detect more complex business logic flaws, such as a sequence of interactions using API. For such cases, a dedicated API penetration test conducted by a skilled human penetration tester mimicking the actions of an attacker is recommended. Particularly important is the adversarial mindset when conducting such testing — don’t think like a developer, think like an attacker. Hawes concludes that the role of API monitoring is vital to detect deviation from APIs’ normal operation that attackers cause.

Finally this week, we have some brief thoughts from Brian Schwarz on approaches to API security as part of a broader cloud security strategy.

Schwarz calls out the inadequacies of reliance on traditional web application firewalls (WAFs) in protecting APIs and suggests using more modern Web Application and API Protection (WAAP) solutions. Perhaps the most interesting insight from Schwarz is the suggestion of enforcing API protection and defense at the platform level, rather than relying on individual development teams to provide adequate protection during their development lifecycles.

Certainly, such a reliance on bespoke or custom protections can lead to deficiencies in the overall organization estate, because it is all too easy for developers to overlook elements of API security in their haste to release new features and functionality. A decentralized approach can result in inconsistencies in protection.

Related to siloed API protections within API development teams is the topic of central API detection and compliance. A benefit of centrally enforcing API policies against emergent threats ensures that protection is applied in a uniform manner and is consistent with the organization’s compliance and regulatory requirements.