7 minute read time

Fortify Your APIs and Get Them Battle Ready

by Micro Focus Employee in CyberRes

In November, MFGS, Inc. sponsored the AFCEA Alamo ACE conference in San Antonio, TX. I was invited to give a presentation on software supply chain security at the conference. I grew up in Texas and look for any excuse to get back, so I was happy to support the event.

When our other scheduled speaker fell ill, I filled in with a presentation on Application Programming Interface (API) security. Why this topic and not something else?

APIs are the stitches that holds the patchwork app components, like microservices, together. An organization can have dozens, hundreds, and even thousands of APIs connecting internal applications to each other and the outside world. I feel that without visibility into the nature and scope of its API attack surface, organizations will find themselves hamstrung in attempting to tackle their API security risks. We are in a bit of an API security “arms race,” as security teams and threat actors alike bring more sophisticated technologies to the battlefield.

Fortify Your APIs and Get Them Battle Ready

According to Gartner, 90% of web-enabled applications will have more attack surface area in exposed APIs rather than in the user interface. Gartner also predicted that this year, API abuses will move from infrequent to the most-frequent application-level attack vector. And we are starting to see that.

API Vulnerability Management

APIs should be part of an overall vulnerability management program. This may not be working if APIs are not part of the scope or if the InfoSec teams lack the knowledge of how to test APIs.

API vulnerabilities can be found across a wide range of areas, such as endpoints (devices, servers, virtual environments, etc.), data exposure, denial of service (DoS), authorization flaws, security system misconfiguration, and more. Considering the massive attack surface involved with thousands of API-supported assets found in any given organization, API vulnerabilities can have extremely wide-ranging effects in an enterprise.

High profile cases, in which companies suffered API attacks despite having strong security measures, have already made headlines. Facebook had 50 million accounts exposed by attacking a weakness in the site’s “View As” feature. This allowed hackers to steal account access tokens after Facebook created an API-supported video upload functionality.

Uber was also exposed when their users’ universally unique identifiers (UUID) in API requests led to leaked tokens in the API response which could be used to hijack accounts. Attackers were then able to track victims’ locations and even steal rides.

I’m not saying that developers or QA don’t test or validate APIs. However, typically developers are validating that the query is logical than that the query is exposing the data in a way that is unsafe. That is where you need a robust security process in place that includes applying misuse and abuse use cases to the security testing process for APIs. This should include thinking about how to move data safely in and out of an application and throughout the process of developing the app to reflect how threat actors would potentially exploit the APIs. But to do this effectively, you need a strategy.

Solution Path for API Security Strategy

The API security challenge requires a strategic approach for security assessment and vulnerability management that can be applied universally and efficiently across a diverse set of APIs.

Gartner has documented a multi-phased strategy for securing APIs. In the Design phase, you should ensure there is a good understanding of the APIs to be exposed, that the data exposed is safe, and that authentication is in place where it should be. This is to help ensure that data is not exposed when it wasn't intended. That first level is in the design review stage.

Solution Path for API Security Strategy

The API Discovery phase follows the Design phase and encompasses the ability to find and inventory all APIs. Enterprises manage thousands of APIs, and many of them are not routed through a proxy or API gateway. APIs that are not routed are not monitored, are rarely audited, and are most vulnerable to mistakes which lead to attacks. It is important to create a complete API inventory enabling the team to discover and assess every API, including legacy and shadow APIs with data classification.

Then you need to start looking at how you will monitor and protect the APIs. The ability to detect API anomalies, changes and misconfigurations is vital. It is important for enterprises to analyze API access, usage, and behavior.

Now Gartner calls out security testing as an activity in the design phase. I agree that as soon as there's code checked in, it is a good time to start doing static analysis to begin. That is a great way to catch some of those injection style attacks. Also, once the application is at a point where it can be stood up on a server, that is where we want to start looking at dynamic analysis.

But dynamic analysis could also be in the Monitor phase. With DAST we can start looking at the environmental factors like authentication. It is very hard to test authentication with SAST because a full round trip involves an application server as well. There are some checks you can do statically, but this is where DAST starts to shine with environmental things that require the full ecosystem to be set up.

While not clearly defined Gartner’s strategy, once we are at either Monitor or Protect, if this is a critical app that is connected to a database that has sensitive information or has high risk functionality, I recommend having a penetration test conducted. Bring in an expert to really look at that holistic view of everything.

Another challenge facing security practitioners when implementing API security programs are unclear roles and responsibilities for security teams. This means that there can be gaps in API maintenance, monitoring and security. Teams need to be given specific responsibilities regarding API security maintenance to ensure that nuanced differences between APIs are addressed

OWASP API Security Top 10

Another way of taking on API security challenge is to focus on the commonly seen vulnerabilities in APIs. For web applications, you have your traditional attacks that you must be worried about, which include things like injection attacks where you have broken access control, command injection, etc. All of those still apply in APIs but there are also some additional concerns that are more specific to APIs. In 2019, the Open Web Application Security Project (OWASP) released the API Security Top 10.

The Facebook and Uber attacks noted above demonstrate what is known as a ‘broken user authentication’ API attack and is the 2nd vulnerability in OWASP’s API Top Ten. While both API usage and related security concerns have changed since OWASP published their top ten list, it is one of the few industry references on API security vulnerabilities available.

Fortify Marketing recently released a new white paper entitled Developers Guide to the OWASP Top 10 for API Security. The whitepaper explains the technical details of each of the top-10 OWASP API security issues, general countermeasures, and specific steps security teams can take to detect and prevent attacks against specific API security issues using CyberRes products.

OWASP Top 10

The days of having an army of dedicated security professionals testing individual applications to identify vulnerabilities like those in the OWASP API Security Top 10 are part of the past. We really need solutions that can identify exposed attack surfaces created by APIs. Fortify’s white paper also includes a handy table pictured above that maps the OWASP API Top 10 vulnerabilities to the CyberRes solutions that best apply to detect and manage each of the vulnerabilities.

Learn More

If you want to hear the API Security presentation I gave at the Alamo ACE conference, check out this on-demand webinar, Fortify Your APIs to Make Sure They're Battle Ready.

Also check out these resources:

  

Join our Community | Fortify discussion Forum | Tips & Info | What is Application Security

Labels:

Application security