mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/network-services-pentesting/pentesting-web/nginx.md'] t
This commit is contained in:
Translator
parent
fcea037806
commit
d00fa5404f
BIN
src/images/nginx_try_files.png
Normal file
BIN
src/images/nginx_try_files.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 190 KiB |
@ -16,19 +16,19 @@ proxy_pass http://127.0.0.1:8080/;
|
||||
}
|
||||
}
|
||||
```
|
||||
इस कॉन्फ़िगरेशन में, `/etc/nginx` को रूट डायरेक्टरी के रूप में निर्दिष्ट किया गया है। यह सेटअप निर्दिष्ट रूट डायरेक्टरी के भीतर फ़ाइलों तक पहुँच की अनुमति देता है, जैसे कि `/hello.txt`। हालाँकि, यह ध्यान रखना महत्वपूर्ण है कि केवल एक विशिष्ट स्थान (`/hello.txt`) परिभाषित किया गया है। रूट स्थान (`location / {...}`) के लिए कोई कॉन्फ़िगरेशन नहीं है। इस चूक का मतलब है कि रूट निर्देश वैश्विक रूप से लागू होता है, जिससे रूट पथ `/` पर अनुरोधों को `/etc/nginx` के तहत फ़ाइलों तक पहुँचने की अनुमति मिलती है।
|
||||
इस कॉन्फ़िगरेशन में, `/etc/nginx` को रूट निर्देशिका के रूप में निर्दिष्ट किया गया है। यह सेटअप निर्दिष्ट रूट निर्देशिका के भीतर फ़ाइलों तक पहुँच की अनुमति देता है, जैसे कि `/hello.txt`। हालाँकि, यह महत्वपूर्ण है कि केवल एक विशिष्ट स्थान (`/hello.txt`) परिभाषित किया गया है। रूट स्थान (`location / {...}`) के लिए कोई कॉन्फ़िगरेशन नहीं है। इस चूक का मतलब है कि रूट निर्देशिका वैश्विक रूप से लागू होती है, जिससे रूट पथ `/` पर अनुरोधों को `/etc/nginx` के तहत फ़ाइलों तक पहुँचने की अनुमति मिलती है।
|
||||
|
||||
इस कॉन्फ़िगरेशन से एक महत्वपूर्ण सुरक्षा विचार उत्पन्न होता है। एक साधारण `GET` अनुरोध, जैसे `GET /nginx.conf`, संवेदनशील जानकारी को उजागर कर सकता है क्योंकि यह `/etc/nginx/nginx.conf` में स्थित Nginx कॉन्फ़िगरेशन फ़ाइल को सर्व करता है। रूट को कम संवेदनशील डायरेक्टरी, जैसे `/etc`, पर सेट करना इस जोखिम को कम कर सकता है, फिर भी यह अन्य महत्वपूर्ण फ़ाइलों, जिसमें अन्य कॉन्फ़िगरेशन फ़ाइलें, एक्सेस लॉग, और यहां तक कि HTTP बेसिक ऑथेंटिकेशन के लिए उपयोग की जाने वाली एन्क्रिप्टेड क्रेडेंशियल्स तक अनपेक्षित पहुँच की अनुमति दे सकता है।
|
||||
इस कॉन्फ़िगरेशन से एक महत्वपूर्ण सुरक्षा विचार उत्पन्न होता है। एक साधारण `GET` अनुरोध, जैसे `GET /nginx.conf`, संवेदनशील जानकारी को उजागर कर सकता है क्योंकि यह `/etc/nginx/nginx.conf` में स्थित Nginx कॉन्फ़िगरेशन फ़ाइल को सर्व करता है। रूट को कम संवेदनशील निर्देशिका, जैसे `/etc`, पर सेट करना इस जोखिम को कम कर सकता है, फिर भी यह अन्य महत्वपूर्ण फ़ाइलों, जिसमें अन्य कॉन्फ़िगरेशन फ़ाइलें, एक्सेस लॉग, और यहां तक कि HTTP बेसिक ऑथेंटिकेशन के लिए उपयोग की जाने वाली एन्क्रिप्टेड क्रेडेंशियल्स तक अनपेक्षित पहुँच की अनुमति दे सकता है।
|
||||
|
||||
## Alias LFI Misconfiguration <a href="#alias-lfi-misconfiguration" id="alias-lfi-misconfiguration"></a>
|
||||
|
||||
Nginx के कॉन्फ़िगरेशन फ़ाइलों में, "location" निर्देशों के लिए एक करीबी निरीक्षण आवश्यक है। एक भेद्यता जिसे लोकल फ़ाइल समावेशन (LFI) के रूप में जाना जाता है, एक कॉन्फ़िगरेशन के माध्यम से अनजाने में पेश की जा सकती है जो निम्नलिखित के समान है:
|
||||
Nginx के कॉन्फ़िगरेशन फ़ाइलों में, "location" निर्देशों के लिए निकटता से निरीक्षण आवश्यक है। एक भेद्यता जिसे लोकल फ़ाइल समावेशन (LFI) के रूप में जाना जाता है, एक कॉन्फ़िगरेशन के माध्यम से अनजाने में पेश की जा सकती है जो निम्नलिखित के समान है:
|
||||
```
|
||||
location /imgs {
|
||||
alias /path/images/;
|
||||
}
|
||||
```
|
||||
यह कॉन्फ़िगरेशन LFI हमलों के प्रति संवेदनशील है क्योंकि सर्वर `/imgs../flag.txt` जैसे अनुरोधों को लक्षित निर्देशिका के बाहर फ़ाइलों तक पहुँचने के प्रयास के रूप में व्याख्या करता है, जो प्रभावी रूप से `/path/images/../flag.txt` में हल होता है। यह दोष हमलावरों को सर्वर की फ़ाइल प्रणाली से फ़ाइलें पुनः प्राप्त करने की अनुमति देता है जो वेब के माध्यम से सुलभ नहीं होनी चाहिए।
|
||||
यह कॉन्फ़िगरेशन LFI हमलों के प्रति संवेदनशील है क्योंकि सर्वर `/imgs../flag.txt` जैसे अनुरोधों को लक्षित निर्देशिका के बाहर फ़ाइलों तक पहुँचने के प्रयास के रूप में व्याख्यायित करता है, जो प्रभावी रूप से `/path/images/../flag.txt` में हल होता है। यह दोष हमलावरों को सर्वर की फ़ाइल प्रणाली से फ़ाइलें पुनः प्राप्त करने की अनुमति देता है जो वेब के माध्यम से सुलभ नहीं होनी चाहिए।
|
||||
|
||||
इस भेद्यता को कम करने के लिए, कॉन्फ़िगरेशन को इस प्रकार समायोजित किया जाना चाहिए:
|
||||
```
|
||||
@ -62,10 +62,10 @@ deny all;
|
||||
../../pentesting-web/proxy-waf-protections-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
## Unsafe variable use / HTTP Request Splitting <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
|
||||
## असुरक्षित वेरिएबल उपयोग / HTTP अनुरोध विभाजन <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
|
||||
|
||||
> [!CAUTION]
|
||||
> कमजोर वेरिएबल `$uri` और `$document_uri` हैं और इन्हें `$request_uri` से बदलकर ठीक किया जा सकता है।
|
||||
> कमजोर वेरिएबल `$uri` और `$document_uri` हैं और इसे `$request_uri` के साथ बदलकर ठीक किया जा सकता है।
|
||||
>
|
||||
> एक regex भी कमजोर हो सकता है जैसे:
|
||||
>
|
||||
@ -81,7 +81,7 @@ location / {
|
||||
return 302 https://example.com$uri;
|
||||
}
|
||||
```
|
||||
HTTP अनुरोधों में \r (Carriage Return) और \n (Line Feed) नए लाइन वर्णों का संकेत देते हैं, और उनके URL-कोडित रूप `%0d%0a` के रूप में दर्शाए जाते हैं। एक अनुरोध में इन वर्णों को शामिल करने पर (जैसे, `http://localhost/%0d%0aDetectify:%20clrf`) एक गलत कॉन्फ़िगर किए गए सर्वर पर, सर्वर एक नए हेडर का नाम `Detectify` जारी करता है। यह इसलिए होता है क्योंकि $uri वेरिएबल URL-कोडित नए लाइन वर्णों को डिकोड करता है, जिससे प्रतिक्रिया में एक अप्रत्याशित हेडर उत्पन्न होता है:
|
||||
HTTP अनुरोधों में \r (Carriage Return) और \n (Line Feed) नए लाइन वर्णों का संकेत देते हैं, और उनके URL-कोडित रूप `%0d%0a` के रूप में दर्शाए जाते हैं। एक अनुरोध में इन वर्णों को शामिल करने (जैसे, `http://localhost/%0d%0aDetectify:%20clrf`) से एक गलत कॉन्फ़िगर किए गए सर्वर पर एक नया हेडर `Detectify` जारी होता है। ऐसा इसलिए होता है क्योंकि $uri वेरिएबल URL-कोडित नए लाइन वर्णों को डिकोड करता है, जिससे प्रतिक्रिया में एक अप्रत्याशित हेडर उत्पन्न होता है:
|
||||
```
|
||||
HTTP/1.1 302 Moved Temporarily
|
||||
Server: nginx/1.19.3
|
||||
@ -93,7 +93,7 @@ Detectify: clrf
|
||||
```
|
||||
CRLF इंजेक्शन और प्रतिक्रिया विभाजन के जोखिमों के बारे में अधिक जानें [https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/](https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/) पर।
|
||||
|
||||
यह तकनीक [**इस वार्ता में समझाई गई है**](https://www.youtube.com/watch?v=gWQyWdZbdoY&list=PL0xCSYnG_iTtJe2V6PQqamBF73n7-f1Nr&index=77) जिसमें कुछ कमजोर उदाहरण और पहचान तंत्र हैं। उदाहरण के लिए, एक ब्लैकबॉक्स दृष्टिकोण से इस गलत कॉन्फ़िगरेशन का पता लगाने के लिए आप ये अनुरोध कर सकते हैं:
|
||||
यह तकनीक [**इस वार्ता में समझाई गई है**](https://www.youtube.com/watch?v=gWQyWdZbdoY&list=PL0xCSYnG_iTtJe2V6PQqamBF73n7-f1Nr&index=77) जिसमें कुछ कमजोर उदाहरण और पहचान तंत्र हैं। उदाहरण के लिए, एक ब्लैकबॉक्स परिप्रेक्ष्य से इस गलत कॉन्फ़िगरेशन का पता लगाने के लिए आप ये अनुरोध कर सकते हैं:
|
||||
|
||||
- `https://example.com/%20X` - कोई भी HTTP कोड
|
||||
- `https://example.com/%20H` - 400 खराब अनुरोध
|
||||
@ -105,7 +105,7 @@ CRLF इंजेक्शन और प्रतिक्रिया विभ
|
||||
- `http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x` - कोई भी HTTP कोड
|
||||
- `http://company.tld/%20HTTP/1.1%0D%0AHost:%20x` - 400 खराब अनुरोध
|
||||
|
||||
उस वार्ता में पाए गए कुछ कमजोर कॉन्फ़िगरेशन थे:
|
||||
उस वार्ता में प्रस्तुत कुछ कमजोर कॉन्फ़िगरेशन थे:
|
||||
|
||||
- ध्यान दें कि **`$uri`** अंतिम URL में जैसा है वैसा ही सेट किया गया है
|
||||
```
|
||||
@ -127,17 +127,67 @@ proxy_pass https://company-bucket.s3.amazonaws.com$uri;
|
||||
```
|
||||
### Any variable
|
||||
|
||||
यह पता चला कि **उपयोगकर्ता-प्रदत्त डेटा** कुछ परिस्थितियों में **Nginx वेरिएबल** के रूप में माना जा सकता है। इस व्यवहार का कारण कुछ हद तक अस्पष्ट है, फिर भी यह न तो दुर्लभ है और न ही सत्यापित करना सीधा है। इस विसंगति को HackerOne पर एक सुरक्षा रिपोर्ट में उजागर किया गया था, जिसे [यहां](https://hackerone.com/reports/370094) देखा जा सकता है। त्रुटि संदेश की आगे की जांच ने इसके होने की पहचान [Nginx के कोडबेस के SSI फ़िल्टर मॉड्यूल](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365) के भीतर की, जो सर्वर साइड इनक्लूड्स (SSI) को मूल कारण के रूप में इंगित करता है।
|
||||
यह पता चला है कि **उपयोगकर्ता-प्रदत्त डेटा** कुछ परिस्थितियों में **Nginx वेरिएबल** के रूप में माना जा सकता है। इस व्यवहार का कारण कुछ हद तक अस्पष्ट है, फिर भी यह न तो दुर्लभ है और न ही सत्यापित करना सीधा है। इस विसंगति को HackerOne पर एक सुरक्षा रिपोर्ट में उजागर किया गया था, जिसे [यहां](https://hackerone.com/reports/370094) देखा जा सकता है। त्रुटि संदेश की आगे की जांच ने इसके होने की पहचान [Nginx के कोडबेस के SSI फ़िल्टर मॉड्यूल](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365) के भीतर की, जिससे सर्वर साइड इनक्लूड्स (SSI) को मूल कारण के रूप में इंगित किया गया।
|
||||
|
||||
इस **गलत कॉन्फ़िगरेशन का पता लगाने** के लिए, निम्नलिखित कमांड निष्पादित की जा सकती है, जिसमें वेरिएबल प्रिंटिंग के लिए एक रेफरर हेडर सेट करना शामिल है:
|
||||
इस **गलत कॉन्फ़िगरेशन** का पता लगाने के लिए, निम्नलिखित कमांड निष्पादित की जा सकती है, जिसमें वेरिएबल प्रिंटिंग के लिए एक रेफरर हेडर सेट करना शामिल है:
|
||||
```bash
|
||||
$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’
|
||||
```
|
||||
इस गलत कॉन्फ़िगरेशन के लिए सिस्टमों में स्कैन करने पर कई उदाहरण सामने आए जहाँ Nginx वेरिएबल्स को एक उपयोगकर्ता द्वारा प्रिंट किया जा सकता था। हालाँकि, कमजोर उदाहरणों की संख्या में कमी यह सुझाव देती है कि इस समस्या को पैच करने के प्रयास कुछ हद तक सफल रहे हैं।
|
||||
इस गलत कॉन्फ़िगरेशन के लिए सिस्टमों में स्कैन करने से कई उदाहरण सामने आए जहाँ Nginx वेरिएबल्स को एक उपयोगकर्ता द्वारा प्रिंट किया जा सकता था। हालाँकि, कमजोर उदाहरणों की संख्या में कमी यह सुझाव देती है कि इस समस्या को पैच करने के प्रयास कुछ हद तक सफल रहे हैं।
|
||||
|
||||
### $URI$ARGS वेरिएबल्स के साथ try_files का उपयोग करना
|
||||
|
||||
Nginx गलत कॉन्फ़िगरेशन के कारण LFI कमजोरियों का सामना करना पड़ सकता है:
|
||||
```
|
||||
location / {
|
||||
try_files $uri$args $uri$args/ /index.html;
|
||||
}
|
||||
```
|
||||
हमारी कॉन्फ़िगरेशन में `try_files` निर्देश है जिसका उपयोग निर्दिष्ट क्रम में फ़ाइलों के अस्तित्व की जांच करने के लिए किया जाता है। Nginx पहले फ़ाइल को सर्व करेगा जो इसे मिलेगी। `try_files` निर्देश की मूल संरचना इस प्रकार है:
|
||||
```
|
||||
try_files file1 file2 ... fileN fallback;
|
||||
```
|
||||
Nginx प्रत्येक फ़ाइल के अस्तित्व की जांच निर्दिष्ट क्रम में करेगा। यदि कोई फ़ाइल मौजूद है, तो इसे तुरंत सेवा दी जाएगी। यदि निर्दिष्ट फ़ाइलों में से कोई भी मौजूद नहीं है, तो अनुरोध को फॉलबैक विकल्प पर भेजा जाएगा, जो कि एक अन्य URI या एक विशिष्ट त्रुटि पृष्ठ हो सकता है।
|
||||
|
||||
हालांकि, इस निर्देश में `$uri$args` वेरिएबल का उपयोग करते समय, Nginx उस फ़ाइल की तलाश करेगा जो अनुरोध URI के साथ किसी भी क्वेरी स्ट्रिंग तर्कों को मिलाकर मेल खाती है। इसलिए हम इस कॉन्फ़िगरेशन का लाभ उठा सकते हैं:
|
||||
```
|
||||
http {
|
||||
server {
|
||||
root /var/www/html/public;
|
||||
|
||||
location / {
|
||||
try_files $uri$args $uri$args/ /index.html;
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
निम्नलिखित पेलोड के साथ:
|
||||
```
|
||||
GET /?../../../../../../../../etc/passwd HTTP/1.1
|
||||
Host: example.com
|
||||
```
|
||||
हमारे पेलोड का उपयोग करके हम रूट डायरेक्टरी (जो Nginx कॉन्फ़िगरेशन में परिभाषित है) से बाहर निकलेंगे और `/etc/passwd` फ़ाइल को लोड करेंगे। डिबग लॉग में हम देख सकते हैं कि Nginx फ़ाइलों को कैसे आज़माता है:
|
||||
```
|
||||
...SNIP...
|
||||
|
||||
2025/07/11 15:49:16 [debug] 79694#79694: *4 trying to use file: "/../../../../../../../../etc/passwd" "/var/www/html/public/../../../../../../../../etc/passwd"
|
||||
2025/07/11 15:49:16 [debug] 79694#79694: *4 try file uri: "/../../../../../../../../etc/passwd"
|
||||
|
||||
...SNIP...
|
||||
|
||||
2025/07/11 15:49:16 [debug] 79694#79694: *4 http filename: "/var/www/html/public/../../../../../../../../etc/passwd"
|
||||
|
||||
...SNIP...
|
||||
|
||||
2025/07/11 15:49:16 [debug] 79694#79694: *4 HTTP/1.1 200 OK
|
||||
|
||||
```
|
||||
Nginx के ऊपर दिए गए कॉन्फ़िगरेशन का उपयोग करते हुए PoC:
|
||||
|
||||
|
||||
## कच्चे बैकएंड प्रतिक्रिया पढ़ना
|
||||
|
||||
Nginx एक फीचर प्रदान करता है `proxy_pass` के माध्यम से जो बैकएंड द्वारा उत्पन्न त्रुटियों और HTTP हेडर के इंटरसेप्शन की अनुमति देता है, जिसका उद्देश्य आंतरिक त्रुटि संदेशों और हेडर को छिपाना है। यह Nginx द्वारा बैकएंड त्रुटियों के जवाब में कस्टम त्रुटि पृष्ठों को सर्व करके किया जाता है। हालाँकि, जब Nginx एक अमान्य HTTP अनुरोध का सामना करता है, तो चुनौतियाँ उत्पन्न होती हैं। ऐसा अनुरोध बैकएंड को प्राप्त रूप में अग्रेषित किया जाता है, और बैकएंड की कच्ची प्रतिक्रिया सीधे ग्राहक को Nginx के हस्तक्षेप के बिना भेजी जाती है।
|
||||
Nginx एक फीचर प्रदान करता है `proxy_pass` के माध्यम से जो बैकएंड द्वारा उत्पन्न त्रुटियों और HTTP हेडर को इंटरसेप्ट करने की अनुमति देता है, जिसका उद्देश्य आंतरिक त्रुटि संदेशों और हेडर को छिपाना है। यह Nginx द्वारा बैकएंड त्रुटियों के जवाब में कस्टम त्रुटि पृष्ठों को सर्व करके किया जाता है। हालाँकि, जब Nginx एक अमान्य HTTP अनुरोध का सामना करता है, तो चुनौतियाँ उत्पन्न होती हैं। ऐसा अनुरोध बैकएंड को जैसे प्राप्त होता है, वैसे ही अग्रेषित किया जाता है, और बैकएंड की कच्ची प्रतिक्रिया सीधे ग्राहक को Nginx के हस्तक्षेप के बिना भेजी जाती है।
|
||||
|
||||
एक उदाहरण परिदृश्य पर विचार करें जिसमें एक uWSGI एप्लिकेशन शामिल है:
|
||||
```python
|
||||
@ -154,27 +204,27 @@ proxy_hide_header Secret-Header;
|
||||
}
|
||||
```
|
||||
- [**proxy_intercept_errors**](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_intercept_errors): यह निर्देश Nginx को 300 से अधिक स्थिति कोड वाले बैकएंड प्रतिक्रियाओं के लिए एक कस्टम प्रतिक्रिया देने की अनुमति देता है। यह सुनिश्चित करता है कि, हमारे उदाहरण uWSGI एप्लिकेशन के लिए, `500 Error` प्रतिक्रिया को Nginx द्वारा रोका और संभाला जाता है।
|
||||
- [**proxy_hide_header**](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_hide_header): जैसा कि नाम से पता चलता है, यह निर्देश क्लाइंट से निर्दिष्ट HTTP हेडर को छुपाता है, जिससे गोपनीयता और सुरक्षा बढ़ती है।
|
||||
- [**proxy_hide_header**](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_hide_header): जैसा कि नाम से स्पष्ट है, यह निर्देश क्लाइंट से निर्दिष्ट HTTP हेडर को छुपाता है, जिससे गोपनीयता और सुरक्षा बढ़ती है।
|
||||
|
||||
जब एक मान्य `GET` अनुरोध किया जाता है, तो Nginx इसे सामान्य रूप से संसाधित करता है, बिना किसी गुप्त हेडर को प्रकट किए एक मानक त्रुटि प्रतिक्रिया लौटाता है। हालाँकि, एक अमान्य HTTP अनुरोध इस तंत्र को बायपास करता है, जिससे कच्ची बैकएंड प्रतिक्रियाएँ, जिसमें गुप्त हेडर और त्रुटि संदेश शामिल हैं, उजागर हो जाती हैं।
|
||||
|
||||
## merge_slashes को बंद पर सेट किया गया
|
||||
## merge_slashes को बंद करना
|
||||
|
||||
डिफ़ॉल्ट रूप से, Nginx का **`merge_slashes` निर्देश** **`on`** पर सेट होता है, जो एक URL में कई फॉरवर्ड स्लैश को एकल स्लैश में संकुचित करता है। यह सुविधा, जबकि URL प्रसंस्करण को सरल बनाती है, Nginx के पीछे अनुप्रयोगों में कमजोरियों को अनजाने में छिपा सकती है, विशेष रूप से स्थानीय फ़ाइल समावेश (LFI) हमलों के प्रति संवेदनशील। सुरक्षा विशेषज्ञ **Danny Robinson और Rotem Bar** ने इस डिफ़ॉल्ट व्यवहार से संबंधित संभावित जोखिमों को उजागर किया है, विशेष रूप से जब Nginx एक रिवर्स-प्रॉक्सी के रूप में कार्य करता है।
|
||||
डिफ़ॉल्ट रूप से, Nginx का **`merge_slashes` निर्देश** **`on`** पर सेट होता है, जो एक URL में कई फॉरवर्ड स्लैश को एकल स्लैश में संकुचित करता है। यह सुविधा, जबकि URL प्रसंस्करण को सरल बनाती है, Nginx के पीछे अनुप्रयोगों में कमजोरियों को अनजाने में छिपा सकती है, विशेष रूप से स्थानीय फ़ाइल समावेश (LFI) हमलों के प्रति संवेदनशील। सुरक्षा विशेषज्ञ **Danny Robinson और Rotem Bar** ने इस डिफ़ॉल्ट व्यवहार से जुड़े संभावित जोखिमों को उजागर किया है, विशेष रूप से जब Nginx एक रिवर्स-प्रॉक्सी के रूप में कार्य करता है।
|
||||
|
||||
ऐसे जोखिमों को कम करने के लिए, उन अनुप्रयोगों के लिए **`merge_slashes` निर्देश को बंद करना** अनुशंसित है जो इन कमजोरियों के प्रति संवेदनशील हैं। यह सुनिश्चित करता है कि Nginx URL संरचना को बदले बिना अनुप्रयोग को अनुरोध अग्रेषित करता है, जिससे किसी भी अंतर्निहित सुरक्षा मुद्दों को छिपाया नहीं जाता है।
|
||||
ऐसे जोखिमों को कम करने के लिए, अनुशंसा की जाती है कि **इन कमजोरियों के प्रति संवेदनशील अनुप्रयोगों के लिए `merge_slashes` निर्देश को बंद कर दें**। यह सुनिश्चित करता है कि Nginx अनुरोधों को अनुप्रयोग की ओर बिना URL संरचना को बदले अग्रेषित करता है, जिससे किसी भी अंतर्निहित सुरक्षा मुद्दों को छिपाया नहीं जाता है।
|
||||
|
||||
अधिक जानकारी के लिए [Danny Robinson और Rotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d) की जाँच करें।
|
||||
अधिक जानकारी के लिए देखें [Danny Robinson और Rotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d).
|
||||
|
||||
### **Maclicious Response Headers**
|
||||
|
||||
जैसा कि [**इस लेख**](https://mizu.re/post/cors-playground) में दिखाया गया है, कुछ हेडर हैं जो यदि वे वेब सर्वर से प्रतिक्रिया में मौजूद हैं तो वे Nginx प्रॉक्सी के व्यवहार को बदल देंगे। आप उन्हें [**दस्तावेज़ों में**](https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/) देख सकते हैं:
|
||||
|
||||
- `X-Accel-Redirect`: Nginx को एक निर्दिष्ट स्थान पर अनुरोध को आंतरिक रूप से पुनर्निर्देशित करने के लिए संकेत करता है।
|
||||
- `X-Accel-Redirect`: Nginx को एक निर्दिष्ट स्थान पर अनुरोध को आंतरिक रूप से पुनर्निर्देशित करने का संकेत देता है।
|
||||
- `X-Accel-Buffering`: नियंत्रित करता है कि क्या Nginx को प्रतिक्रिया को बफर करना चाहिए या नहीं।
|
||||
- `X-Accel-Charset`: X-Accel-Redirect का उपयोग करते समय प्रतिक्रिया के लिए वर्ण सेट सेट करता है।
|
||||
- `X-Accel-Expires`: X-Accel-Redirect का उपयोग करते समय प्रतिक्रिया के लिए समाप्ति समय सेट करता है।
|
||||
- `X-Accel-Limit-Rate`: X-Accel-Redirect का उपयोग करते समय प्रतिक्रियाओं के लिए स्थानांतरण की दर को सीमित करता है।
|
||||
- `X-Accel-Limit-Rate`: X-Accel-Redirect का उपयोग करते समय प्रतिक्रियाओं के लिए ट्रांसफर की दर को सीमित करता है।
|
||||
|
||||
उदाहरण के लिए, हेडर **`X-Accel-Redirect`** Nginx में एक आंतरिक **पुनर्निर्देश** का कारण बनेगा। इसलिए, यदि Nginx कॉन्फ़िगरेशन में कुछ ऐसा है जैसे **`root /`** और वेब सर्वर से प्रतिक्रिया में **`X-Accel-Redirect: .env`** है, तो Nginx **`/.env`** (Path Traversal) की सामग्री भेजेगा।
|
||||
|
||||
@ -199,11 +249,11 @@ return 200 "Hello. It is private area: $mappocallow";
|
||||
}
|
||||
}
|
||||
```
|
||||
बिना `default` के, एक **दुष्ट उपयोगकर्ता** `/map-poc` के भीतर एक **अपरिभाषित URI** तक पहुँचकर सुरक्षा को बायपास कर सकता है। [The Nginx manual](https://nginx.org/en/docs/http/ngx_http_map_module.html) ऐसे मुद्दों से बचने के लिए **default value** सेट करने की सलाह देता है।
|
||||
बिना `default` के, एक **दुष्ट उपयोगकर्ता** `/map-poc` के भीतर एक **अपरिभाषित URI** तक पहुँचकर सुरक्षा को बायपास कर सकता है। [Nginx मैनुअल](https://nginx.org/en/docs/http/ngx_http_map_module.html) ऐसे मुद्दों से बचने के लिए **डिफ़ॉल्ट मान** सेट करने की सलाह देता है।
|
||||
|
||||
### **DNS Spoofing Vulnerability**
|
||||
### **DNS स्पूफिंग भेद्यता**
|
||||
|
||||
Nginx के खिलाफ DNS spoofing कुछ शर्तों के तहत संभव है। यदि एक हमलावर को Nginx द्वारा उपयोग किए जाने वाले **DNS server** का ज्ञान है और वह इसके DNS प्रश्नों को इंटरसेप्ट कर सकता है, तो वह DNS रिकॉर्ड को स्पूफ कर सकता है। हालाँकि, यह विधि तब अप्रभावी है जब Nginx को DNS समाधान के लिए **localhost (127.0.0.1)** का उपयोग करने के लिए कॉन्फ़िगर किया गया हो। Nginx एक DNS सर्वर को इस प्रकार निर्दिष्ट करने की अनुमति देता है:
|
||||
Nginx के खिलाफ DNS स्पूफिंग कुछ शर्तों के तहत संभव है। यदि एक हमलावर को Nginx द्वारा उपयोग किए जाने वाले **DNS सर्वर** का ज्ञान है और वह इसके DNS प्रश्नों को इंटरसेप्ट कर सकता है, तो वह DNS रिकॉर्ड को स्पूफ कर सकता है। हालाँकि, यह विधि तब अप्रभावी है जब Nginx को DNS समाधान के लिए **localhost (127.0.0.1)** का उपयोग करने के लिए कॉन्फ़िगर किया गया हो। Nginx एक DNS सर्वर को इस प्रकार निर्दिष्ट करने की अनुमति देता है:
|
||||
```yaml
|
||||
resolver 8.8.8.8;
|
||||
```
|
||||
@ -216,7 +266,7 @@ resolver 8.8.8.8;
|
||||
यदि nginx सर्वर को Upgrade और Connection हेडर पास करने के लिए कॉन्फ़िगर किया गया है, तो एक [**h2c Smuggling हमला**](../../pentesting-web/h2c-smuggling.md) किया जा सकता है ताकि संरक्षित/आंतरिक एंडपॉइंट्स तक पहुँच प्राप्त की जा सके।
|
||||
|
||||
> [!CAUTION]
|
||||
> यह कमजोरी एक हमलावर को **`proxy_pass` एंडपॉइंट के साथ एक सीधा कनेक्शन स्थापित करने** की अनुमति देगी (`http://backend:9999` इस मामले में) जिसका सामग्री nginx द्वारा जांचा नहीं जाएगा।
|
||||
> यह कमजोरी एक हमलावर को **`proxy_pass` एंडपॉइंट** (`http://backend:9999` इस मामले में) के साथ एक सीधा कनेक्शन स्थापित करने की अनुमति देगी, जिसका सामग्री nginx द्वारा जांचा नहीं जाएगा।
|
||||
|
||||
`/flag` को चुराने के लिए कमजोर कॉन्फ़िगरेशन का उदाहरण [यहाँ](https://bishopfox.com/blog/h2c-smuggling-request) है:
|
||||
```
|
||||
@ -239,15 +289,15 @@ deny all;
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> ध्यान दें कि भले ही `proxy_pass` एक विशिष्ट **path** जैसे `http://backend:9999/socket.io` की ओर इशारा कर रहा हो, कनेक्शन `http://backend:9999` के साथ स्थापित किया जाएगा, इसलिए आप उस आंतरिक एंडपॉइंट के अंदर किसी अन्य पथ से **संपर्क कर सकते हैं। इसलिए यह मायने नहीं रखता कि proxy_pass के URL में एक पथ निर्दिष्ट किया गया है।**
|
||||
> ध्यान दें कि भले ही `proxy_pass` एक विशिष्ट **path** जैसे `http://backend:9999/socket.io` की ओर इशारा कर रहा हो, कनेक्शन `http://backend:9999` के साथ स्थापित किया जाएगा, इसलिए आप उस आंतरिक एंडपॉइंट के अंदर **किसी अन्य path** से संपर्क कर सकते हैं। इसलिए यह मायने नहीं रखता कि proxy_pass के URL में कोई path निर्दिष्ट किया गया है।
|
||||
|
||||
## खुद कोशिश करें
|
||||
## Try it yourself
|
||||
|
||||
Detectify ने एक GitHub रिपॉजिटरी बनाई है जहाँ आप Docker का उपयोग करके अपने स्वयं के कमजोर Nginx परीक्षण सर्वर को स्थापित कर सकते हैं, जिसमें इस लेख में चर्चा की गई कुछ गलत कॉन्फ़िगरेशन हैं और उन्हें स्वयं खोजने की कोशिश कर सकते हैं!
|
||||
Detectify ने एक GitHub रिपॉजिटरी बनाई है जहाँ आप Docker का उपयोग करके अपने स्वयं के कमजोर Nginx परीक्षण सर्वर को स्थापित कर सकते हैं, जिसमें इस लेख में चर्चा की गई कुछ गलत कॉन्फ़िगरेशन हैं और उन्हें स्वयं खोजने का प्रयास कर सकते हैं!
|
||||
|
||||
[https://github.com/detectify/vulnerable-nginx](https://github.com/detectify/vulnerable-nginx)
|
||||
|
||||
## स्थिर विश्लेषक उपकरण
|
||||
## Static Analyzer tools
|
||||
|
||||
### [GIXY](https://github.com/yandex/gixy)
|
||||
|
||||
@ -257,7 +307,7 @@ Gixy Nginx कॉन्फ़िगरेशन का विश्लेषण
|
||||
|
||||
Nginxpwner सामान्य Nginx गलत कॉन्फ़िगरेशन और कमजोरियों की खोज के लिए एक सरल उपकरण है।
|
||||
|
||||
## संदर्भ
|
||||
## References
|
||||
|
||||
- [**https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/**](https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/)
|
||||
- [**http://blog.zorinaq.com/nginx-resolver-vulns/**](http://blog.zorinaq.com/nginx-resolver-vulns/)
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user