WAFs had been a top-notch safety instrument a decade in the past, however now they’re not. They fail to protect APIs. Meanwhile, the variety of API-specific vulnerabilities grew greater than twofold in 2022. According to a report by Wallarm, many such vulnerabilities have crucial severity, and 33% are instantly exploited. But corporations nonetheless closely depend on WAFs, so many providers change into extremely insecure and susceptible to knowledge breaches. Consider this: a median knowledge breach value hit 4.35 million {dollars} in 2022, and it’s ever-growing!
To get monetary savings and popularity, use a extra dependable API safety device slightly than a default cloud WAF. If you’re not satisfied but, right here we describe three limitations that make your default WAF ineffective, that are not often mentioned.
Web & API Security
The use of APIs is skyrocketing, and the variety of uncovered flaws in enterprise logic is rising proportionally. The purpose lies within the distinction between microservices and monolithic structure, which beforehand dominated the sector.
When a monolithic app receives a request from a person, the response is computed throughout the inner infrastructure and with out interacting on the community. Only one endpoint per request is uncovered. It’s the alternative for microservices: they work together on-line on a regular basis by way of inner APIs to compute the response. Of course, they are often deployed on a devoted server and received’t want to speak on the community, nevertheless it’s expensive and doesn’t make sense since microservices are specifically designed for the cloud.
APIs present entry to many features beforehand hidden inside a monolith, which suggests many newly uncovered flaws attackers can use. But it’s not solely the assault floor that issues for securing your APIs! Let’s dig into it.
Limitations of WAFs in API Security
There are just a few execs and lots of cons to utilizing a default cloud WAF in API safety. It’s well-known that WAFs can’t successfully cope with purposeful assaults. Yet, many essential limitations are not often mentioned. Let’s discover them one after the other.
Nested Encodings
Your WAF is there to match incoming requests to the patterns of unhealthy. WAFs must know what fraudulent requests appear like. To educate them, you present common 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, issues get difficult in case your payload is encoded a number of instances. You want so as to add a set of matching strings for every encoding degree. In flip, it results in elevated request processing time or trip. The latter is a catastrophe: customers don’t like after they don’t get what they’re on the lookout for.
Data Protocols Parsing
Often, on-line visitors is in-built a Russian-doll method: protocols go on high of different protocols. There are a lot of them above HTTP. For instance, in gRPC, knowledge is encapsulated and exchanged by way of HTTP2.
To reconstruct and examine the payload, the WAF must understand how these protocols are structured. Some WAFs assist protocol parsing, however usually it is restricted to REST APIs and JSON knowledge. Meanwhile, different widespread API protocols like gRPC, GraphQL, WebSocket, and SOAP are disregarded.
Among the most well-liked cloud WAFs, Cloudflare helps extra protocols than others. The WebSocket protocol is an oldie however goodie, however WAFs, besides Cloudflare, don’t assist it! It doesn’t come as a shock as a result of safety is one of many firm’s greatest focuses. Yet, Cloudflare can’t parse GraphQL, which is quickly gaining recognition. Strange.
| AWS WAF | Cloudflare | Google Armor | Azure WAF | |
| GraphQL | -/+ just for httpflood and tokens restrictions | – | – | – |
| REST API | (*8*) | + | + | + |
| SOAP | – | + | – | – |
| JSON-RPC | + | + | + | + |
| gRPC | – | +/- no inspection for malicious payloads | – | – |
| WebSocket | – | +/- no inspection for malicious payloads | – | – |
AWS WAF is the one one to protect GraphQL APIs, and it has executed so since 2020. Amazon adopts a forward-looking technique however leaves behind previous options, just like the SOAP protocol, which is nonetheless utilized in many legacy options migrating to the cloud.
Only one protocol will be parsed by all these default WAFs – the REST API. But there’s an vital caveat it’s essential to know.
Checked Request Size Limitation
The measurement of the scanned payload in a WAF is at all times restricted to the request’s first bytes. This reality nonetheless is extensively neglected and results in weak safety measures: an attacker can bypass all WAF checks without delay by placing the malicious code additional within the request physique.
Can WAFs provide us an answer in case of outsized payloads? There are two methods a WAF can react: block the request instantly or move it additional with out checking the bytes after the restrict. Each WAF adopts a distinct technique by default, so it’s essential to examine the settings earlier than utilizing your WAF to make sure it behaves as anticipated.
But blocking isn’t an clever answer: at the very least a few of your APIs might obtain official but massive requests. To clear up this, you may permit larger requests for particular URIs. Still, the setup process is not apparent due to the foundations hierarchy, and the preliminary concern turns into legitimate once more: something exceeding the restrict might result in an assault.
There’s no level in anticipating AWS, Google, or different cloud suppliers to drop the checked payload restrict. If it’s not in place, deliberately outsized requests can overload servers. Also, official massive requests would trip due to the time-consuming checks.
| Maximum inspected request physique measurement | |
| AWS WAF | 8 KB |
| Cloudflare | 128 KB |
| Google Armor | 8 KB |
| Azure WAF | 128 KB |
The limitation was not as essential within the early days of the web. Previously, requests primarily featured type submissions and had been comparatively small. Even if a person connected a file, it was uploaded in chunks as a result of bandwidth and throughput limitations.
It’s totally different for the info circulating between B2B endpoints. Let’s take into account an instance: a enterprise has a digital doc move. To cope with prospects and contractors, massive PDF information accompanied by advanced metadata, presumably containing a malicious payload, are despatched forwards and backwards. These information are not divided into chunks as a result of the networks at the moment are far more environment friendly than they was. It’s not the one instance of a giant, official request. There is far more heavy knowledge of assorted sorts circulating on the community.
Remember that many cloud suppliers don’t say their WAFs have this undesirable limitation after they provide a default WAF answer. It could also be deceptive and end in compromised knowledge.
Check Your WAF for API Limitations
The open-source GoTestWAF device by Wallarm permits you to establish safety gaps in your WAFs. It takes a predetermined set of menace vectors and sends them to the examined URL in varied request components – HTTP path, header, or physique. After the checks’ execution, the device generates a report specifying the variety of blocked and missed assaults, and calculates an general security rating.
GoTestWAF has two scan modes: blind scan and app-specific scan, which makes it distinctive. In the blind scan mode, the examine isn’t focusing on APIs per se however slightly the WAF. No requests are API-specific. Most WAF checkers work on this method. But within the app-specific mode, GoTestWAF sends legitimate requests to totally different APIs counting on OpenAPI documentation.
How can GoTestWAF assist remove the safety gaps mentioned above? Let’s take into account an instance of a WAF that may parse JSON however can’t examine for encoded assault vectors within the fields. A WAF checker within the blind-scan mode received’t be capable to mannequin the assault focusing on this vulnerability as a result of the check requests will lack the required headers and fail the WAF examine. However, in case your requests adjust to the protocol, you may insert the encoded assault vector in any area and examine if the app’s WAF reacts appropriately.
In the vectors set, there are checks for the 8 KB, 15 KB, 32 KB, 64 KB, and 128 KB limits.
To check your APIs, pull the GoTestWAF image from the Docker repository and run the command:
docker run -v ${PWD}/stories:/app/stories --network="host"
wallarm/gotestwaf --url=
You’ll discover the report within the ‘${PWD}/stories’ folder contained in the container. Learn extra on this fast GoTestWAF demo video.
Conclusion
Bill Gates as soon as claimed that 640 KB is sufficient for the whole lot. If it ever was true, these instances have lengthy handed. Today, WAFs can’t restrict the assessed payload to 128 KB, not to mention 8 KB, in the event that they intend to save lots of you from cyberattacks. In right this moment’s digital world, WAFs should deal with all protocols, decode nested encodings, and examine all the payload. Then you’ll get the visibility and menace safety required to deal with your fashionable API-first setting’s compliance and enterprise dangers.
There’s extra to API security than menace detection – you want mitigation too. To guarantee your APIs are safe, it is best to have superior protection for net functions and APIs. Book a consultation to learn how Wallarm can help.
The publish 8 KB is not enough: why WAFs can’t protect APIs appeared first on Wallarm.
*** This is a Security Bloggers Network syndicated weblog from Wallarm authored by ferrisbuller. Read the unique publish at: https://lab.wallarm.com/8-kb-is-not-enough-why-wafs-cant-protect-apis/
https://securityboulevard.com/2022/10/8-kb-is-not-enough-why-wafs-cant-protect-apis/
