I85PREP
⌘ K
CWICP study materials
CWICP study resources

CWICP: Web Application Firewalls, Filtering, and Evasion

CWICP · Work through your exam, one topic at a time.

All guide sections

Web Application Firewalls, Filtering, and Evasion

This domain tests whether you can tell the difference between a filter and a fix, and whether you can demonstrate that a security control is bypassable using techniques that respect scope and avoid destructive traffic.

How filtering behaves

  • Placement. Cloud WAF, reverse-proxy WAF (ModSecurity with the OWASP Core Rule Set), framework-level input filters, and RASP all inspect different things. A rule that blocks a payload at the edge does nothing about the vulnerable code behind it.
  • Detection. Vendor cookies and headers, distinctive block pages, sudden 403/406/501 responses, connection resets, IP reputation blocking, and timing shifts from added inspection.
  • Scoring models. CRS uses anomaly scoring with paranoia levels; a request can pass while a slightly different one crosses the threshold. Signature engines match patterns and are brittle to encoding.
  • Rate limiting and bot defense. Separate controls; a rate limit is not a WAF rule, and CAPTCHA challenges generate false negatives in scans.

Evasion families

  • Encoding. URL encoding, double encoding, Unicode and overlong forms, HTML entities, and charset tricks (e.g. declaring charset=ibm037 so the backend decodes different bytes than the filter).
  • Lexical. Case variation, inline comments (UN/**/ION), MySQL versioned comments (/*!50000UNION*/), whitespace alternatives (%09, %0a, /**/), and alternate function names.
  • Structural. HTTP parameter pollution (duplicate keys resolved differently by filter and app), Content-Type switching (JSON body not inspected by a form-only rule set), multipart filename smuggling, chunked transfer encoding, oversized padding to overflow the inspection buffer, and HTTP/2-to-HTTP/1.1 downgrade at the edge.
  • Semantic. Using legitimate features (a JSONP endpoint, template built-ins, $where) rather than attack strings.

Worked example

A search parameter carrying UNION SELECT username,password FROM users returns 403, while a benign value returns 200. Send id=1 /*!50000UNION*/ /*!50000SELECT*/ 1,2,3 - the MySQL versioned comments are executed by the database but do not match the plain-text rule. If that returns data, the filter is a signature rule on keywords and the underlying concatenation is untouched. The finding to report is the SQL injection; the filter bypass is supporting evidence and a note that the WAF provided no real protection.

Traps that cost marks

  • Reporting "WAF bypass" as the vulnerability when the actual flaw is injection.
  • Treating a 403 on one payload as proof the parameter is safe.
  • Fuzzing encodings against production at volume without rate limits agreed in the rules of engagement.
  • Assuming a block page means the request never reached the application - verify with out-of-band or timing evidence.