
The Updated OWASP API Security Top 10 for 2023 is Here
The Open Web Application Security Project (OWASP)…
{ "term_id": 164, "name": "David Thomason", "slug": "david-thomason", "term_group": 0, "term_taxonomy_id": 164, "taxonomy": "wpx-authors", "description": "", "parent": 0, "count": 12, "filter": "raw" }
Previously, I wrote about the Discover and Analyze pillars of the D.A.R.T. API Security Strategy. Discovery helps us understand what APIs we need to protect. Analysis tells us if and how they are protected (or not) and if they are being misused. If you haven’t read my earlier posts, be sure to check them out (linked above). Understanding the first two pillars of the D.A.R.T. strategy is crucial to getting the third pillar right.
For many organizations, discovering and analyzing all the APIs is a monumental task. Using API catalogs, code repositories, and manual processes is time consuming and organizations never get a completely accurate representation of the APIs as they are deployed. The inaccuracies associated with discovery alone are myriad: documentation is incorrect or out-of-date; developers copy code from open sources then fail to incorporate it into the repository; the list goes on.
Analysis is also complex. If done correctly, it considers not only the API network traffic but also all the devices used to configure and manage APIs. If done correctly, it can identify and resolve all deployment issues, which dramatically reduces the application’s attack surface.
So, what happened to <fill in the blank with your favorite victim of an exploited API>? First, in virtually every attack, the API was deployed without using best practices for API security. Strong authentication wasn’t used; the application wasn’t protected by a web application firewall (WAF) or API gateway; or the API wasn’t tested for authorization attacks (e.g., credential stuffing, account takeover, and broken object level authorization also known as BOLA). Proper analysis and testing could have, and in some cases might have, identified these vulnerabilities before they were exploited.
If you detect an issue but fail to remediate it, you haven’t accomplished much.
The problem is, without the proper tools, remediation can be difficult, either because it is technically challenging or because it requires considerable time and effort. But if remediation is done right, it can often be automated or semi-automated and thereafter require little or no human interaction.
Your first step in remediation should be to integrate the Noname API Security Platform with your IT workflow management system (e.g., Jira, ServiceNow, or Slack). This will allow you to automatically assign issues to the appropriate teams as they are identified. Typically, the security team has few if any options for remediating API issues without help from IT, DevOps, the development team, or the business unit, so automatically assigning them to the right team significantly reduces the workload on the security team.
Say your company has a mobile app that resides in the /mobile subdomain. You would integrate Noname with your installation of ServiceNow. When the Platform identifies a new configuration issue within the mobile app (identified by the /mobile subdomain), a ticket is created and the appropriate product manager is immediately notified. The product manager can then assign the ticket to the appropriate developer, development team, or DevOps team. Depending on how severe the issue is, the fix can be scheduled for the next sprint or it can be handled by an emergency patch. If the product manager sees this kind of ticket regularly, logic can be added to send the ticket directly to the correct team (or team member) with a copy going to the product manager.
This should be the first level of remediation in any organization, and it takes just minutes to complete with Noname.
With semi-automated remediation, Noname is already integrated with existing infrastructure, whether it be the firewall, API gateway, identity provider, or some other device. The idea here is that a human must approve an action before it is taken. Say, for example, analysis reveals that an API is exposing too much data, but the API cannot automatically be blocked because its value to the business unit is unknown. With coordination from the business unit, semi-automated remediation can be used to temporarily block use of the API.
The process would look something like this:
Over time, some issues are more likely to recur than others. These are the issues that should be considered for automated remediation. Take, for example, an API that does not have the appropriate security policy. The following simple steps can be completed automatically with the cooperation of the DevOps team:
This issue can be resolved in seconds and with no interruption of service or risk to the business unit, leaving you with an API that is more secure and resistant to attack, effectively lowering your organization’s risk posture.
By proactively remediating issues as they are discovered, you protect your company, your applications, and your APIs long before the attacker can find the hole and exploit it.
All the issues I’ve discussed thus far can be considered “left of boom” in the timeline of the attack sequence, i.e., they are all identified well before they can be exploited by the adversary. But what about the moment of “boom,” or to the “right of boom”? Not every vulnerability can be addressed before someone attempts to exploit it.
As an organization matures in its API security strategy, automated or semi-automated remediation can be used to stop the adversary from achieving their goals. Consider the following typical attack pattern based on documented white-hat hacker exploits.
First, target the application
The first step in the attack pattern is typically quite simple as the attacker can choose any mobile or web application. Often, the best choice is a recently updated application. This is because changes in the application (commonly referred to as “diffs”) often expose weaknesses in the old versions that are still active.
Once the top-level domain to the application is discovered, the adversary occasionally has to evade the WAF. Directory traversal will usually do the job.
Here is where things get a little tricky for the adversary. While some APIs are exposed by name through the application, this is rarely the case for all APIs. At this point, the adversary enumerates the APIs exposed by name and evaluates them as candidates to exploit. The adversary considers several factors:
If the enumerated APIs don’t produce the results the adversary is looking for, they will likely try to enumerate other possible candidates. For example, if an API is discovered with “/user/” in the URI, the adversary may look for “/user/details” and “/user/profile.” Educated guesswork takes time, but automated hacker tools speed up the process.
Once the adversary finds an API that can produce the result they want, they typically create a script to steal as much information as possible and in as short a time as possible.
The good news is that an adversary never needs to get that far. Let’s look at the attack pattern again, but this time, we’ll incorporate analysis and remediation.
While discovery and analysis must come before remediation, organizations that progress to automating remediations demonstrate a much more mature API security model. The Noname API Security Platform automates the discovery and analysis processes, and for the more mature organizations, delivers a platform from which they can complete automated and semi-automated remediations to block attackers and protect their most valuable assets.
Experience the speed, scale, and security that only Noname can provide. You’ll never look at APIs the same way again.