Bypassing Web Application Firewalls Using HTTP Headers

Web application firewalls (WAFs) are part of the web application defense-in-depth model. Although they do not replace secure code, they provide excellent options for filtering out malicious input. Below is a story from an actual assessment where the deployment of such a device in the enterprise was susceptible to circumvention. The vulnerability is one of poor design and/or configuration and as an attacker it was very useful.

It is important to test the security of an application in its production deployment. Although this application may have been evaluated during development or QA, when you deploy it live you may introduce new attack vectors due to configuration issues. This was the case with our fictitious client Heisenberg Bank.

When launching the trial, I quickly ran into trouble scrambling all the app points I usually look for first, see below (rough screenshot):

Well… it’s both humorous and unsatisfying.

After some research, I knew that I was facing a WAF that was triggering on certain things:

  • Rapid succession of POST requests to forms
  • Rapid succession of GET requests to *most* pages
  • No CSRF token
  • *Bad* characters

Once any of these conditions are met, it would block me with said error code for 5 minutes.

So, how to proceed?

The normal method of encoding payloads to bypass WAF regex is random these days. WAFs have come a long way. Still, I gave it a hit, no dice.

While waiting in one of my *timeouts*, I decided to do some research on the WAF. Browsing through several WAF implementation guides, I found a forum that mentioned integrating a WAF with your caching service/device. It described a user’s problem with something *like* Varnish or a proxy/accelerator device running on a different host, and the WAF was blocking that server. Of course, the vendor was quick to respond that you can whitelist IP-based devices, allowing them not to be inspected by the WAF.

At this point, everything is still fine. Here’s where things went wrong for Heisenberg Bank and the WAF.

After reading more, I discovered that instead of doing a real lookup on incoming requests (something akin to REMOTE_ADDR or something similar), the WAF was looking at a *custom* HTTP header.

Here’s how it’s supposed to work if a user or another server contacts the WAF:

Instead, the WAF checks the request’s HTTP headers. The specific implementation checked the header request Origin IP X.

So who would this WAF be configured to trust? In this case, the default was… Himself!

Since I control all HTTP requests sent from my browser, I can easily add this header to trick the WAF into thinking I was itself, allowing me to completely bypass its protections:

After further research, several headers can be set for WAFs to whitelist (instead of doing a proper search):

  • X-transferred-for
  • X-remote-IP
  • Origin IP X
  • x-remote-address

There is also a result list of *types* of addresses/configurations that *could* be whitelisted/vulnerable. (some fictitious examples below):

After determining the bypass, the rest of the assessment revealed many more vulnerabilities and was expedited due to the fact that I could bypass the WAF. It was as simple as having my online intercepting proxy add the header to all requests.

A simple solution is to have your front-end proxy strip all *non-standard* headers, but you’re still playing the cat-and-mouse game of blacklisting. Better yet, check your WAF provider and see which headers are accepted and which defaults are enabled. Then find a solution that doesn’t rely on information the attacker can tamper with.

In general, you can also audit the security of HTTP headers on your site using Gethead, a project of our Dynamic Testing Team Lead, Nathan LaFollette (@httphacker).

A super blogger has also created a Burp Suite extension that will add these headers to all your queries:

Happy hacking!

The post Bypassing web application firewalls using HTTP headers appeared first on Security Aegis.

*** This is a Security Aegis Security Bloggers Network syndicated blog written by Security Aegis. Read the original post at:

Comments are closed.