8 KB is not enough: why WAFs canít protect APIs
Discription

WAFs were a top-notch security instrument a decade ago, but now they are not. They fail to protect APIs. Meanwhile, the number of API-specific vulnerabilities grew more than twofold in 2022. According to a [report]() by Wallarm, many such vulnerabilities have critical severity, and 33% are immediately exploited. But companies still heavily rely on WAFs, so many services turn out to be highly insecure and prone to data breaches. Consider this: an average data breach cost [hit]() 4.35 million dollars in 2022, and it’s ever-growing!

To save money and reputation, use a more reliable API security tool rather than a default cloud WAF. If you are not convinced yet, here we describe three limitations that make your default WAF ineffective, which are not usually discussed.

## Web & API Security

The use of APIs is [skyrocketing](), and the number of exposed flaws in business logic is growing proportionally. The reason lies in the difference between microservices and monolithic architecture, which previously dominated the field.

When a monolithic app receives a request from a user, the response is computed within the internal infrastructure and without interacting on the network. Only one endpoint per request is exposed. It’s the opposite for microservices: they interact online all the time via internal APIs to compute the response. Of course, they can be deployed on a dedicated server and wonít need to communicate on the network, but itís costly and doesnít make sense since microservices are specially designed for the cloud.

APIs provide access to many functions previously hidden inside a monolith, which implies many newly exposed flaws attackers can use. But itís not only the attack surface that matters for securing your APIs! Let’s dig into it.

## Limitations of WAFs in API Security

There are a few pros and many cons to using a default cloud WAF in API security. Itís well known that WAFs cannot effectively deal with functional attacks. Yet, many crucial limitations are rarely discussed. Letís explore them one by one.

### Nested Encodings

Your WAF is there to match incoming requests to the patterns of bad. [WAFs]() need to know what fraudulent requests look like. To teach them, you provide regular expressions for strings like “eval(” or “base64_” to be grepped in requests. When the payload is encoded, you add encoded analogs of fraudulent strings to your rule set. However, things get tricky if your payload is encoded multiple times. You need to add a set of matching strings for each encoding level. In turn, it leads to increased request processing time or time out. The latter is a disaster: users donít like when they donít get what they are looking for.

### Data Protocols Parsing

Often, online traffic is built in a Russian-doll manner: protocols go on top of other protocols. There are many of them above HTTP. For example, in gRPC, data is encapsulated and exchanged via HTTP2.

To reconstruct and check the payload, the WAF needs to know how these protocols are structured. Some WAFs support protocol parsing, but often it is limited to REST APIs and JSON data. Meanwhile, other popular API protocols like [gRPC](), [GraphQL](), [WebSocket](), and [SOAP]() are disregarded.

Among the most popular cloud WAFs, Cloudflare supports more protocols than others. The WebSocket protocol is an oldie but goodie, but WAFs, except Cloudflare, donít support it! It doesnít come as a surprise because security is one of the companyís biggest focuses. Yet, Cloudflare cannot parse GraphQL, which is rapidly gaining popularity. Strange.

| **AWS WAF**| **Cloudflare**| **Google Armor**| **Azure WAF**
—|—|—|—|—
**GraphQL**| [+]()| -| -| –
**REST API**| [+]()| +| +| +
**SOAP**| -| +| -| –
**JSON-RPC**| +| +| +| +
**gRPC**| -| [+]()/- no inspection for malicious payloads| -| –
**WebSocket**| [-]()| [+]()/- no inspection for malicious payloads| -| –
**Cloud WAFsí protocol support table**

AWS WAF is the only one to protect GraphQL APIs, and it has done so [since 2020](). Amazon adopts a forward-looking strategy but leaves behind old solutions, like the SOAP protocol, which is still used in many legacy solutions migrating to the cloud.

Only one protocol can be parsed by all these default WAFs Ė the REST API. But thereís an important caveat you need to know.

## Checked Request Size Limitation

The size of the scanned payload in a WAF is always limited to the requestís first bytes. This fact still is widely overlooked and leads to weak security measures: an attacker can bypass all WAF checks at once by putting the malicious code further in the request body.

Can WAFs offer us a solution in case of oversized payloads? There are two ways a WAF can react: block the request immediately or pass it further without checking the bytes after the limit. Each WAF adopts a different strategy by default, so you need to check the settings before using your WAF to ensure it behaves as expected.

But blocking isnít an intelligent solution: at least some of your APIs may receive legitimate yet big requests. To solve this, you can allow bigger requests for specific URIs. Still, the setup procedure is not obvious because of the rules hierarchy, and the initial concern becomes valid again: anything exceeding the limit may lead to an attack.

Thereís no point in expecting AWS, Google, or other cloud providers to drop the checked payload limit. If itís not in place, intentionally oversized requests can overload servers. Also, legitimate big requests would time out because of the time-consuming checks.

| **Maximum inspected request body size**
—|—
AWS WAF| 8 KB
Cloudflare| 128 KB
Google Armor| 8 KB
Azure WAF| [128 KB]()
**The request body size limitation table**

The limitation was not as crucial in the early days of the internet. Previously, requests mainly featured form submissions and were relatively small. Even if a user attached a file, it was uploaded in chunks due to bandwidth and throughput limitations.

Itís different for the data circulating between B2B endpoints. Letís consider an example: a business has a digital document flow. To deal with customers and contractors, large PDF files accompanied by complex metadata, possibly containing a malicious payload, are sent back and forth. These files are not divided into chunks because the networks are now way more efficient than they used to be. Itís not the only example of a big, legitimate request. There is much more heavy data of various types circulating on the network.

Remember that many cloud providers donít say their WAFs have this undesirable limitation when they offer a default WAF solution. It may be misleading and result in compromised data.

## Check Your WAF for API Limitations

The open-source [GoTestWAF]() tool by Wallarm allows you to identify security gaps in your WAFs. It takes a predetermined set of threat vectors and sends them to the tested URL in various request parts Ė HTTP path, header, or body. After the testsí execution, the tool generates a report specifying the number of blocked and missed attacks, and calculates an overall safety score.

GoTestWAF has two scan modes: blind scan and app-specific scan, which makes it unique. In the blind scan mode, the check isnít targeting APIs _per se_ but rather the WAF. No requests are API-specific. Most WAF checkers work in this way. But in the app-specific mode, GoTestWAF sends valid requests to different APIs relying on OpenAPI documentation.

How can GoTestWAF help eliminate the security gaps discussed above? Letís consider an example of a WAF that can parse JSON but canít check for encoded attack vectors in the fields. A WAF checker in the blind-scan mode wonít be able to model the attack targeting this vulnerability because the test requests will lack the necessary headers and fail the WAF check. However, if your requests comply with the protocol, you can insert the encoded attack vector in any field and check if the appís WAF reacts appropriately.

![gotestwaf report ](https://i0.wp.com/lab.wallarm.com/wp-content/uploads/2022/10/gotestwaf-report.jpeg?resize=749%2C495&ssl=1)_The report shows the percentage of passed and blocked vectors of various attack types._

In the vectors set, there are checks for the 8 KB, 15 KB, 32 KB, 64 KB, and 128 KB limits.

To test your APIs, pull the [GoTestWAF image]() from the Docker repository and run the command:

docker run -v ${PWD}/reports:/app/reports –network=”host”
wallarm/gotestwaf –url=

Youíll find the report in the Ď${PWD}/reportsí folder inside the container. Learn more in this quick [GoTestWAF demo video]().

## Conclusion

Bill Gates once claimed that 640 KB is enough for everything. If it ever was true, those times have long passed. Today, WAFs cannot limit the assessed payload to 128 KB, let alone 8 KB, if they intend to save you from cyberattacks. In todayís digital world, WAFs must handle all protocols, decode nested encodings, and inspect the entire payload. Then you will get the visibility and threat protection required to address your modern API-first environment’s compliance and business risks.

There’s more to [API security]() than threat detection Ė you need mitigation too. To ensure your APIs are secure, you should have advanced coverage for web applications and APIs. Book a consultation to learn how Wallarm can help.

The post [8 KB is not enough: why WAFs canít protect APIs]() appeared first on [Wallarm]().Read More

Back to Main

Subscribe for the latest news:
Generated by Feedzy
%d bloggers like this: