Awesome WAF

Everything about web application firewalls (WAFs) from a security perspective. 🔥

Foreword: This was originally my own collection on WAFs. I am open-sourcing it in the hope that it will be useful for pentesters and researchers out there.As the saying goes, "the community just learns from each other."

A Concise Definition: A firewall is a security policy enforcement point positioned between a web application and the client endpoint. This functionality can be implemented in software or hardware, running in an appliance device, or in a typical server running a common operating system. It may be a stand-alone device or integrated into other network components. (Source: PCI DSS IS 6.6)

A web-application firewall sits between a user and a webapp and is tasked to prevent any malicious activity from reaching the webapp. A WAF either filters out the malicious part of the request or just simply blocks it.

Feel free to contribute.

Contents:

• Introduction
  • How WAFs Work
  • Operation Modes
• Testing Methodology
  • Where To Look
  • Detection Techniques
• WAF Fingerprints
• Evasion Techniques
  • Fuzzing/Bruteforcing
  • Regex Reversing
  • Obfuscation/Encoding
  • Browser Bugs
  • HTTP Header Spoofing
  • Google Dorks Approach
• Known Bypasses
• Awesome Tooling
  • Fingerprinting
  • Testing
  • Evasion
• Blogs & Writeups
• Video Presentations
• Research Presentations & Papers
  • Research Papers
  • Presentation Slides
• Licensing & Credits

Introduction:

How WAFs Work:

• Using a set of rules to distinguish between normal requests and malicious requests.
• Sometimes they use a learning mode to add rules automatically through learning about user behaviour.

Operation Modes:

• Negative Model (Blacklist based) - A blacklisting model uses pre-set signatures to block requests that are clearly malicious. The signatures of WAFs operating in a negative model are specifically crafted to prevent attacks which exploit certain web application vulnerabilities. Blacklisting model web application firewalls are a great choice for web applications exposed to the public internet and are highly effective against major vulnerabilities. Eg. Rule for blocking all <script>*</script> inputs prevent basic cross-site scripting attacks.
• Positive Model (Whitelist based) - A whitelisting model only allows web traffic according to specifically configured criteria. For example, it can be configured to only allow HTTP GET requests from certain IP addresses. This model can be very effective for blocking potential large scale attacks, but will also block a lot of legitimate traffic. Whitelisting model firewalls are probably best for web applications on an internal network that are designed to be used by only a limited group of people, such as employees.
• Mixed/Hybrid Model (Inclusive model) - A hybrid security model blends both whitelisting and blacklisting. Depending on all sorts of configuration specifics, hybrid firewalls could be the best choice for both web applications on internal networks and web applications on the public internet. A good scenario can be when web-application is facing the public internet (use blacklists) while the admin panel needs to be exposed to only a subset of users (use whitelists).

Testing Methodology:

Where To Look:

• Always look out for common ports that expose that a WAF, namely 80, 443, 8000, 8080 and 8888 ports. However, its important to note that a WAF can be easily deployed on any port running a HTTP service. It is good to enumerate HTTP service ports first hand and then look for WAFs.
• Some WAFs set their own cookies in requests (e.g. Citrix Netscaler, Yunsuo WAF).
• Some associate themselves with separate headers (e.g. Anquanbao WAF, Amazon AWS WAF).
• Some often alter headers and jumble characters to confuse attacker (e.g. Netscaler, Big-IP).
• Some expose themselves in the Server header (e.g. Approach, WTS WAF).
• Some WAFs expose themselves in the response content (e.g. DotDefender, Armor, Sitelock).
• Other WAFs reply with unusual response codes upon malicious requests (e.g. WebKnight, 360 WAF).

Detection Techniques:

To identify WAFs, we need to (dummy) provoke it. 1. Make a normal GET request from a browser, intercept and record response headers (specifically cookies). 2. Make a request from command line (eg. cURL), and test response content and headers (no user-agent included). 3. Make GET requests to random open ports and grab banners which might expose the WAFs identity. 4. On login pages, inject common (easily detectable) payloads like " or 1 = 1 --. 5. Inject noisy payloads like <script>alert()</script> into search bars, contact forms and other input fields. 6. Attach a dummy ../../../etc/passwd to a random parameter at end of URL. 7. Append some catchy keywords like ' OR SLEEP(5) OR ' at end of URLs to any random parameter. 8. Make GET requests with outdated protocols like HTTP/0.9 (HTTP/0.9 does not support POST type queries). 9. Many a times, the WAF varies the Server header upon different types of interactions. 10. Drop Action Technique - Send a raw crafted FIN/RST packet to server and identify response. > Tip: This method could be easily achieved with tools like HPing3 or Scapy. 11. Side Channel Attacks - Examine the timing behaviour of the request and response content. > Tip: More details can be found in a blogpost here.

WAF Fingerprints

Wanna fingerprint WAFs? Lets see how.

NOTE: This section contains manual WAF detection techniques. You might want to switch over to next section.