# Proxy / WAF Protections Bypass {{#include ../banners/hacktricks-training.md}} ## Bypass Nginx ACL Rules with Pathname Manipulation तकनीकें [from this research](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies). Nginx नियम का उदाहरण: ```plaintext location = /admin { deny all; } location = /admin/ { deny all; } ``` बायपास रोकने के लिए Nginx उसे चेक करने से पहले path का normalization करता है। हालाँकि, यदि बैकएंड सर्वर अलग normalization करता है (ऐसे characters हटाकर जिन्हें nginx नहीं हटाता), तो इस रक्षा को बायपास करना संभव हो सकता है। ### **NodeJS - Express** | Nginx Version | **Node.js Bypass Characters** | | ------------- | ----------------------------- | | 1.22.0 | `\xA0` | | 1.21.6 | `\xA0` | | 1.20.2 | `\xA0`, `\x09`, `\x0C` | | 1.18.0 | `\xA0`, `\x09`, `\x0C` | | 1.16.1 | `\xA0`, `\x09`, `\x0C` | ### **Flask** | Nginx Version | **Flask Bypass Characters** | | ------------- | -------------------------------------------------------------- | | 1.22.0 | `\x85`, `\xA0` | | 1.21.6 | `\x85`, `\xA0` | | 1.20.2 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | | 1.18.0 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | | 1.16.1 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` | ### **Spring Boot** | Nginx Version | **Spring Boot Bypass Characters** | | ------------- | --------------------------------- | | 1.22.0 | `;` | | 1.21.6 | `;` | | 1.20.2 | `\x09`, `;` | | 1.18.0 | `\x09`, `;` | | 1.16.1 | `\x09`, `;` | ### **PHP-FPM** Nginx FPM कॉन्फ़िगरेशन: ```plaintext location = /admin.php { deny all; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.1-fpm.sock; } ``` Nginx को `/admin.php` तक पहुँच अवरुद्ध करने के लिए कॉन्फ़िगर किया गया है, लेकिन `/admin.php/index.php` तक पहुँच करके इसे बाईपास किया जा सकता है। ### इसे कैसे रोका जाए ```plaintext location ~* ^/admin { deny all; } ``` ## Mod Security नियम बायपास करें ### पथ भ्रम [**In this post**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) में बताया गया है कि ModSecurity v3 (3.0.12 तक) ने `REQUEST_FILENAME` वेरिएबल को **गलत तरीके से लागू** किया था, जो कि एक्सेस किए गए path को (parameters की शुरुआत तक) रखना चाहिए था। यह इसलिए हुआ क्योंकि इसने path प्राप्त करने के लिए URL decode किया।\ इसलिए, एक request जैसे `http://example.com/foo%3f';alert(1);foo=` mod security में मान लेगा कि path सिर्फ `/foo` है क्योंकि `%3f` `?` में बदल जाता है और URL path वहीं खत्म हो जाता है, पर वास्तव में सर्वर जो path प्राप्त करेगा वह `/foo%3f';alert(1);foo=` होगा। `REQUEST_BASENAME` और `PATH_INFO` वेरिएबल भी इस बग से प्रभावित थे। Mod Security के version 2 में कुछ समान हुआ था जिससे एक सुरक्षा बाइपास हो सकती थी जो उपयोगकर्ता को बैकअप फाइल से जुड़े विशिष्ट एक्सटेंशन (जैसे `.bak`) वाली फाइलों तक पहुँचने से रोकती थी — बस dot को URL encoded `%2e` भेजकर, उदाहरण: `https://example.com/backup%2ebak`. ## Bypass AWS WAF ACL ### मैलफॉर्म्ड हेडर [This research](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) में बताया गया है कि HTTP headers पर लागू AWS WAF नियमों को bypass करना संभव था एक "malformed" header भेजकर जो AWS द्वारा सही तरह से parsed नहीं किया जाता था पर backend server द्वारा किया जाता था। उदाहरण के लिए, X-Query हेडर में SQL injection के साथ निम्नलिखित request भेजने पर: ```http GET / HTTP/1.1\r\n Host: target.com\r\n X-Query: Value\r\n \t' or '1'='1' -- \r\n Connection: close\r\n \r\n ``` It was possible to bypass AWS WAF because it wouldn't understand that the next line is part of the value of the header while the NODEJS server did (this was fixed). ## सामान्य WAF बायपास ### अनुरोध आकार सीमाएँ आम तौर पर WAFs के पास जांच के लिए अनुरोधों की एक निश्चित लंबाई सीमा होती है और यदि कोई POST/PUT/PATCH अनुरोध उससे बड़ा होता है, तो WAF उस अनुरोध की जांच नहीं करेगा। - For AWS WAF, you can [**check the documentation**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
Application Load Balancer और AWS AppSync protections के लिए निरीक्षण किए जा सकने वाले web request body का अधिकतम आकार8 KB
CloudFront, API Gateway, Amazon Cognito, App Runner, और Verified Access protections के लिए निरीक्षण किए जा सकने वाले web request body का अधिकतम आकार**64 KB
- From [**Azure docs**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:** पुराने Web Application Firewalls जिनमें Core Rule Set 3.1 (या उससे कम) है, request body inspection को बंद कर के **128 KB** से बड़े संदेशों की अनुमति देते हैं, लेकिन इन संदेशों की vulnerabilities के लिए जांच नहीं की जाएगी। नए वर्ज़न्स (Core Rule Set 3.2 या नए) में, वही अधिकतम request body limit को अक्षम कर के किया जा सकता है। जब कोई अनुरोध आकार सीमा से अधिक हो जाता है: If p**revention mode**: अनुरोध को लॉग और ब्लॉक करता है.\ If **detection mode**: सीमा तक निरीक्षण करता है, बाकी को अनदेखा करता है, और लॉग करता है यदि `Content-Length` सीमा से अधिक है. - From [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:** डिफ़ॉल्ट रूप से, WAF केवल अनुरोध के पहले 8KB की जांच करता है। यह Advanced Metadata जोड़कर सीमा को 128KB तक बढ़ा सकता है। - From [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:** 128KB तक। ### Static assets inspection gaps (.js GETs) कुछ CDN/WAF स्टैक्स स्टैटिक एसेट्स के लिए GET अनुरोधों (उदा. paths जो `.js` पर समाप्त होते हैं) पर कमजोर या कोई content inspection लागू करते हैं, जबकि rate limiting और IP reputation जैसे global नियम लागू रहते हैं। स्टैटिक एक्सटेंशन्स के auto-caching के साथ मिलकर, इसे बाद के HTML responses को प्रभावित करने वाले malicious variants डिलिवर या सीड करने के लिए दुरुपयोग किया जा सकता है। व्यावहारिक उपयोग के मामले: - एक `.js` path पर GET कर के untrusted headers (जैसे `User-Agent`) में payload भेजें ताकि content inspection से बचा जा सके, फिर कैश्ड variant को प्रभावित करने के लिए तुरंत मुख्य HTML का अनुरोध करें। - नया/साफ IP इस्तेमाल करें; एक बार IP फ्लैग हो जाने पर, routing बदलाव इस तकनीक को अविश्वसनीय बना सकते हैं। - Burp Repeater में, "Send group in parallel" (single-packet style) का उपयोग करें ताकि दो अनुरोधों (`.js` फिर HTML) को एक ही front-end path से रेस किया जा सके। यह header-reflection cache poisoning के साथ अच्छी तरह मेल खाता है। देखें: {{#ref}} cache-deception/README.md {{#endref}} - [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/) ### Obfuscation ```bash # IIS, ASP Clasic <%s%cr%u0131pt> == #changing the case of the tag < #prepending an additional "<" #using backticks instead of parenetheses java%0ascript:alert(1) #using encoded newline characters