The Home of the Security Bloggers Network

Home » Security Bloggers Network » Building a modern API security strategy — API protection

By Jeff Williams, Co-Founder, Chief Technology Officer

Part four of the five-part series, Building a modern API security strategy.

Another Log4j or Spring4Shell could happen tomorrow. 

A zero-day vulnerability could lead to a total compromise of your organization’s vulnerable applications or application programming interfaces (APIs). 

“Log4j is not over,” states a recent report (PDF ) from the Federal Cyber Safety Review Board, which added that “vulnerable instances of Log4j will remain in systems for many years to come, perhaps a decade or longer” and that “significant risk remains.”

If it isn’t a zero day, it could just as easily be a vulnerability in your custom API code. APIs can have almost all of the same vulnerabilities that traditional web applications have, including SQL injection, server-side request forgery, unsafe deserialization and many more.

In order to protect production against attacks like these, you’ve got to identify probes and attacks on both known and unknown vulnerabilities and prevent exploits. But in order to do it right, you need to understand the unique challenges presented by API protection.

Here are just four of the most serious security challenges involved in the protection of web applications and APIs:

While traditional technologies such as intrusion prevention systems (IPSes) and web application firewalls (WAFs) are often used for API protection at runtime, they work in-line as they inspect network traffic and content. This includes many new “API Security” products. As they analyze traffic and/or user sessions to and from apps and APIs, they have no visibility into how traffic and data are being processed within these components. Note that access to the OpenAPI definition of an API is of little help in identifying attacks.

Fortunately, Runtime Application Self-Protection (RASP) can address many of these concerns. RASP provides two key capabilities: First, it creates visibility into exactly who is attacking you, what attack vectors they are using on your APIs and which of your APIs is being targeted. Second, RASP prevents most of the major classes of vulnerabilities from being exploited, including both zero days and custom code flaws. 

RASP works very differently from WAFs. RASP uses instrumentation to add lightweight security sensors to your API code and platforms. These sensors can directly measure security relevant behavior of your APIs and detect malicious events. Unlike perimeter defenses, instrumentation and sensors accurately track attacks and prevent vulnerabilities from being exploited, giving users a firm yes or no regarding whether the exploit reached its target. It protects against a broad range of zero-day attacks without tuning or reconfiguration.

Working from inside APIs themselves, RASP security is able to detect, block and mitigate attacks immediately, protecting as they run in realtime by analyzing both their behavior and context. By using the app or API to continuously monitor its own behavior, RASP has the ability to protect an API from data theft, malicious inputs and behavior, without human intervention. It gives AppSec, SecOps and Dev teams accurate, detailed information, including the payload, full HTTP request, exact lines of code, queries executed, files accessed and more.

RASP protection can be used until the underlying vulnerabilities can be addressed. This gives both Dev and Ops breathing room by reducing lengthy and disruptive security fire drills, minimizing sleepless nights wrought by zero days. Instead of insomnia, it brings deep security instrumentation to gain insight into exactly how attacks behave, automatically weaving visibility and protection directly into APIs, without requiring any API changes. 

RASP provides highly effective protection against both custom code vulnerabilities and zero days. In fact, RASP prevented both Log4Shell and Spring4Shell from being exploited long before the vulnerability was discovered or disclosed. This is because RASP fundamentally prevents the techniques used in those exploits, including expression language injection and unsafe deserialization, from being used maliciously.

These protections have been in our product for years: years before those CVEs were ever discovered. In short, if you were using Contrast Protect when Log4Shell or Spring4Shell hit, you were protected, period. 

No patching, noted one relieved customer. No need for server updating. Just the peace of mind that comes with Contrast Protect with RASP. 

Last week, we looked at API components . 

Stay tuned: Next week, we’ll be looking at the ease of use of Contrast’s API security solutions. 

For a guide to all five parts of Contrast’s series on forging a modern API security strategy, check out this overview . 

Also, be sure to check out this discussion between Jeff Williams, Co-Founder & CTO, Contrast Security, and Melinda Marks, Senior Analyst, ESG Research, where they unravel: 

To download the recorded webinar:

Jeff brings more than 20 years of security leadership experience as co-founder and Chief Technology Officer of Contrast Security. He recently authored the DZone DevSecOps, IAST, and RASP refcards and speaks frequently at conferences including JavaOne (Java Rockstar), BlackHat, QCon, RSA, OWASP, Velocity, and PivotalOne. Jeff is also a founder and major contributor to OWASP, where he served as Global Chairman for 9 years, and created the OWASP Top 10, OWASP Enterprise Security API, OWASP Application Security Verification Standard, XSS Prevention Cheat Sheet, and many more popular open source projects. Jeff has a BA from Virginia, an MA from George Mason, and a JD from Georgetown.

How to scan for cybersecurity risks on every commit with CodeSec and Git Hooks for free

By subscribing to our blog you will stay on top of all the latest appsec news and devops best practices. You will also be informed of the latest Contrast product news and exciting application security events.

Part four of the five-part series, Building a modern API security strategy.

Another Log4j or Spring4Shell could happen tomorrow. 

A zero-day vulnerability could lead to a total compromise of your organization’s vulnerable applications or application programming interfaces (APIs). 

“Log4j is not over,” states a recent report (PDF ) from the Federal Cyber Safety Review Board, which added that “vulnerable instances of Log4j will remain in systems for many years to come, perhaps a decade or longer” and that “significant risk remains.”

If it isn’t a zero day, it could just as easily be a vulnerability in your custom API code. APIs can have almost all of the same vulnerabilities that traditional web applications have, including SQL injection, server-side request forgery, unsafe deserialization and many more.

In order to protect production against attacks like these, you’ve got to identify probes and attacks on both known and unknown vulnerabilities and prevent exploits. But in order to do it right, you need to understand the unique challenges presented by API protection.

Here are just four of the most serious security challenges involved in the protection of web applications and APIs:

While traditional technologies such as intrusion prevention systems (IPSes) and web application firewalls (WAFs) are often used for API protection at runtime, they work in-line as they inspect network traffic and content. This includes many new “API Security” products. As they analyze traffic and/or user sessions to and from apps and APIs, they have no visibility into how traffic and data are being processed within these components. Note that access to the OpenAPI definition of an API is of little help in identifying attacks.

Fortunately, Runtime Application Self-Protection (RASP) can address many of these concerns. RASP provides two key capabilities: First, it creates visibility into exactly who is attacking you, what attack vectors they are using on your APIs and which of your APIs is being targeted. Second, RASP prevents most of the major classes of vulnerabilities from being exploited, including both zero days and custom code flaws. 

RASP works very differently from WAFs. RASP uses instrumentation to add lightweight security sensors to your API code and platforms. These sensors can directly measure security relevant behavior of your APIs and detect malicious events. Unlike perimeter defenses, instrumentation and sensors accurately track attacks and prevent vulnerabilities from being exploited, giving users a firm yes or no regarding whether the exploit reached its target. It protects against a broad range of zero-day attacks without tuning or reconfiguration.

Working from inside APIs themselves, RASP security is able to detect, block and mitigate attacks immediately, protecting as they run in realtime by analyzing both their behavior and context. By using the app or API to continuously monitor its own behavior, RASP has the ability to protect an API from data theft, malicious inputs and behavior, without human intervention. It gives AppSec, SecOps and Dev teams accurate, detailed information, including the payload, full HTTP request, exact lines of code, queries executed, files accessed and more.

RASP protection can be used until the underlying vulnerabilities can be addressed. This gives both Dev and Ops breathing room by reducing lengthy and disruptive security fire drills, minimizing sleepless nights wrought by zero days. Instead of insomnia, it brings deep security instrumentation to gain insight into exactly how attacks behave, automatically weaving visibility and protection directly into APIs, without requiring any API changes. 

RASP provides highly effective protection against both custom code vulnerabilities and zero days. In fact, RASP prevented both Log4Shell and Spring4Shell from being exploited long before the vulnerability was discovered or disclosed. This is because RASP fundamentally prevents the techniques used in those exploits, including expression language injection and unsafe deserialization, from being used maliciously.

These protections have been in our product for years: years before those CVEs were ever discovered. In short, if you were using Contrast Protect when Log4Shell or Spring4Shell hit, you were protected, period. 

No patching, noted one relieved customer. No need for server updating. Just the peace of mind that comes with Contrast Protect with RASP. 

Last week, we looked at API components . 

Stay tuned: Next week, we’ll be looking at the ease of use of Contrast’s API security solutions. 

For a guide to all five parts of Contrast’s series on forging a modern API security strategy, check out this overview . 

Also, be sure to check out this discussion between Jeff Williams, Co-Founder & CTO, Contrast Security, and Melinda Marks, Senior Analyst, ESG Research, where they unravel: 

To download the recorded webinar:

*** This is a Security Bloggers Network syndicated blog from AppSec Observer authored by Jeff Williams. Read the original post at: https://www.contrastsecurity.com/security-influencers/building-a-modern-api-security-strategy-api-protection