I'm running a WAF infront of a bunch of Webapps and we have the Apps regulary tested, and we want to improve our Tests by presenting some kind of livelogs to the testers. What informations, from Server-View, could help the Pentesters?

The objective is NOT to keep the testers out, but to find any possible way to bypass the WAF and internal protections.

EDIT: it's merely a WAF-testbed. The Vulns within the Apps are known and mostly marked as WONTFIX [!sic!]. You know, it's one of that "natural grown" - java-app from once upon a time ...

2 Answers 2


Your approach should be two-fold:

Check for:

  • Various escape sequences (e.g. \x00, %s, \\, etc.)
  • Unicode tricks (e.g. multi-byte characters that end in 0x22 to produce a ")
  • Alternative XSS methods (e.g. <img src=0 onerror=alert(1) /> instead of <script>alert(1)</script>)
  • Various nasties (e.g. XSS, SQL injection) inside of cookies and HTTP headers - often WAFs miss these!

Ensure that the client understands that a WAF is just a sticking plaster, and cannot fix a broken limb. If the application is broken in an exploitable way, a WAF may prevent the attack or mitigate some of the impact, but there is no way to be sure if it will be effective.

It is also a double-edged sword, in that people often assume that a bug that a WAF makes unexploitable will always be unexploitable, and therefore doesn't need to be fixed (at least with any haste). Browsers and HTML / CSS / JavaScript / SQL / XML / server-side languages, etc. evolve constantly, so new exploit techniques may come along that make old bugs exploitable.

One additional point I'd like to make: if the test is aimed at the web-app, and not specifically aimed at the WAF solution they have deployed, then I would highly recommend asking the client to disable the WAF on their staging site for the duration of the test. Leaving it on makes it much harder for you to give them a reasonable estimate of the security posture of the application, and that means they get less value from the test. If they're really interested in testing the WAF, they could do an additional test day afterwards that compares the exploitability of the found issues with and without the WAF being enabled.

  • 2
    +1 for the answer in general and +3, if I could, for the last paragraph. I'd rather pay for a four-day test (3 for the web-app with WAF disabled and 1 for the web-app with WAF enabled) than having a five-day test done entirely based on the web-app with the WAF enabled: I would judge it that the benefits I would get from having these tests run in a more well structured fashion could allow me to afford a day less out of a normal test; cheaper and more efficient.
    – Lex
    Jul 9, 2013 at 10:29
  • 1
    see my edit; sadly, the waf is not just a sticking plaster, but the sickbed that app lives in. Jul 9, 2013 at 10:52
  • @thatguyfromoverthere My advice doesn't really change. Make sure they're absolutely aware of the limitations, and advise them that they are taking a signficiant risk.
    – Polynomial
    Jul 9, 2013 at 20:57

There are three approaches to attacking a web application behind a Web Application Firewall (WAF). If you look at existing WAF bypass exploits you can see that they break down into two major categories. You can bypass a set of rules because it is overly restrictive or does not accurately match a real attack, or attack the pre-processor which will bypass every ruleset. There is a third category of WAF bypass, which doesn't require a WAF bypass exploit.

  1. WAF pre-processor attacks are aimed at trying to obscure or remove an attack payload from a request prior to being processed by a WAF's rule-sets. Here are two exploits that are WAF pre-processor attacks:

    PHPIDS had an insecure "Remove Duplicates" pre-processor can be used to obscure any payload that is duplicated 33 times. (Disclaimer: This is my exploit)

    IBM WebSphere had an insecure "Remove Comments" pre-processor can be used to obscure any payload.

  2. WAF ruleset attacks are exploiting a weak ruleset that allows an attacker to submit a valid attack string. In this case the rules are overly simplistic an attack can be modified to avoid detection. There are two directions to attacking a web application behind a web application firewall.

    One direction is to attempt to exploit a common vulnerability, such as XSS or SQLi. Determine what rule you violated, and try and modify your attack payload to bypass this rule. Rules can be audited using a Regex Debugger, RegEx Buddy is my favorite tool for this process. After you are able to exploit SQLi, then search for SQLi vulnerabilities in the application. For example, if you had a modified string that would execute sleep(30) on a MySQL database without being detected by the WAF, the you can use this string to fuzz for blind SQLi in the application. Here is an example of a SQL Injection payload modified to bypass mod_security. This is a blackbox approach where you don't have access to the web application its self, but the attacker should always access to the WAF.

    The other direction is the reverse, exploit the web application with a vulnerability like SQLi without the WAF, and then try and create an attack string to exploit this vulnerability without being detected by the WAF. This is a grey-box approach.

  3. The third method of attacking a web application behind a WAF is to avoid the problem entirely. It is impossible for a WAF to detect every attack. There are common vulnerabilities in web applications that WAFs cannot prevent. CSRF, Mass Assignment, Insecure Direct Object Reference, Click-Jacking, Cryptographic Oracles, Authentication/Authorization logic errors... use your imagination.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .