WAF test suite

[krizhanovsky]

Need to develop a test suite, as part of current functional tests, to emulate WAF bypassing requests and Web attacks.

Depends on the WAF implementation tempesta-tech/tempesta#2458 : there is no sense to run the scanners if we know that there is no implemented protections, like CSRF or CSP.

Analyzer + backend

One of the way, probably the simplest and featureful is to use ready vulnerability scanner/analyzer with vulnerable backend. Following analyzers, working as a malicious clients could be emplyed:

• WAFNinja
• lightbulb-framework
• wafw00f
• w3af
• nmap http-waf-detect.nse script
• Commix
• Go Test WAF
• wfuzz
• zaproxy
• nuclei
• sqlmap

Also consider the WAF bypass collection

Backends:

• Google Gruyere
• DVWA

Homebred tests

If the above don't test some of the security issues, then appropriate functional tests, complementing the ready analyzer/backend setup, shall be implemented.

• HTTP Response Splitting
• HTTP Request Smuggling (Blink sessions.test_h2_sticky_scheduler.H2StickySchedulerTestCase.test_h2_cookie_scheduler #900, Handle Content-Type in GET requests tempesta#1296 and cases from https://github.com/tempesta-tech/tempesta/wiki/Web-security#http-request-smuggling)
• HTTP Parameter pollution
• Invalid POST arguments boundary (Blink t_ja5.test_ja5_filters.TestJa5FiltersTestSuiteMethod.test_ja5_hash_difference #902)
• requests with Content-Type: invalid (Imperva's vulnerability) and empty Content-Type must be blocked.
• SQL ijections
• RCE, including in HTTP headers, like User-Agent
• filtering passive XSS attacks like http://www.site.com/page.php?var=<script>alert('xss');</script>
• test URI and POST attacks using decodings (see tempesta-tech/enterprise#2)
• Check that Host header injections are blocked in default configuration: Host: mysite:”><xss>, Host: mysite “><xss>
• Exploiting URL for SSRF

        http://1.1.1.1 &@2.2.2.2# @3.3.3.3/
        http://127.0.0.1:11211:80/
        http://google.com#@evil.com/
        ... and others

• HTTP filtering proxy evasions (evade HTTP adjustment code by mangling HTTP headers in assumption that a prixy and target HTTP server process them in different way), such as insertion of extra spaces, tabs, 0x00–0x20, and so on, e.g. GET / HTTP/1.1\r\n\sHost\x4:\tfoo \r\n. The main point is if we do not block some of such manglings (i.e. it's allowed by RFC), then we must correctly perform HTTP message modifications for such headers.