mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
318 lines
32 KiB
Markdown
318 lines
32 KiB
Markdown
# Nginx
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|
||
|
||
|
||
## Missing root location <a href="#missing-root-location" id="missing-root-location"></a>
|
||
|
||
जब Nginx सर्वर को कॉन्फ़िगर किया जाता है, तो **root directive** एक महत्वपूर्ण भूमिका निभाता है क्योंकि यह उस मूल निर्देशिका को परिभाषित करता है जिससे फ़ाइलें सर्व की जाती हैं। नीचे दिए गए उदाहरण पर विचार करें:
|
||
```bash
|
||
server {
|
||
root /etc/nginx;
|
||
|
||
location /hello.txt {
|
||
try_files $uri $uri/ =404;
|
||
proxy_pass http://127.0.0.1:8080/;
|
||
}
|
||
}
|
||
```
|
||
इस कॉन्फ़िगरेशन में, `/etc/nginx` को रूट निर्देशिका के रूप में निर्दिष्ट किया गया है। यह सेटअप निर्दिष्ट रूट निर्देशिका के भीतर फ़ाइलों तक पहुँच की अनुमति देता है, जैसे कि `/hello.txt`। हालाँकि, यह महत्वपूर्ण है कि केवल एक विशिष्ट स्थान (`/hello.txt`) परिभाषित किया गया है। रूट स्थान (`location / {...}`) के लिए कोई कॉन्फ़िगरेशन नहीं है। इस चूक का मतलब है कि रूट निर्देशिका वैश्विक रूप से लागू होती है, जिससे रूट पथ `/` पर अनुरोधों को `/etc/nginx` के तहत फ़ाइलों तक पहुँचने की अनुमति मिलती है।
|
||
|
||
इस कॉन्फ़िगरेशन से एक महत्वपूर्ण सुरक्षा विचार उत्पन्न होता है। एक साधारण `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) के रूप में जाना जाता है, एक कॉन्फ़िगरेशन के माध्यम से अनजाने में पेश की जा सकती है जो निम्नलिखित के समान है:
|
||
```
|
||
location /imgs {
|
||
alias /path/images/;
|
||
}
|
||
```
|
||
यह कॉन्फ़िगरेशन LFI हमलों के प्रति संवेदनशील है क्योंकि सर्वर `/imgs../flag.txt` जैसे अनुरोधों को लक्षित निर्देशिका के बाहर फ़ाइलों तक पहुँचने के प्रयास के रूप में व्याख्यायित करता है, जो प्रभावी रूप से `/path/images/../flag.txt` में हल होता है। यह दोष हमलावरों को सर्वर की फ़ाइल प्रणाली से फ़ाइलें पुनः प्राप्त करने की अनुमति देता है जो वेब के माध्यम से सुलभ नहीं होनी चाहिए।
|
||
|
||
इस भेद्यता को कम करने के लिए, कॉन्फ़िगरेशन को इस प्रकार समायोजित किया जाना चाहिए:
|
||
```
|
||
location /imgs/ {
|
||
alias /path/images/;
|
||
}
|
||
```
|
||
अधिक जानकारी: [https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/](https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/)
|
||
|
||
Accunetix परीक्षण:
|
||
```
|
||
alias../ => HTTP status code 403
|
||
alias.../ => HTTP status code 404
|
||
alias../../ => HTTP status code 403
|
||
alias../../../../../../../../../../../ => HTTP status code 400
|
||
alias../ => HTTP status code 403
|
||
```
|
||
## Unsafe path restriction <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
|
||
|
||
निम्नलिखित पृष्ठ की जांच करें कि निर्देशों को कैसे बायपास किया जाए जैसे:
|
||
```plaintext
|
||
location = /admin {
|
||
deny all;
|
||
}
|
||
|
||
location = /admin/ {
|
||
deny all;
|
||
}
|
||
```
|
||
{{#ref}}
|
||
../../pentesting-web/proxy-waf-protections-bypass.md
|
||
{{#endref}}
|
||
|
||
## असुरक्षित वेरिएबल उपयोग / HTTP अनुरोध विभाजन <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
|
||
|
||
> [!CAUTION]
|
||
> कमजोर वेरिएबल `$uri` और `$document_uri` हैं और इसे `$request_uri` के साथ बदलकर ठीक किया जा सकता है।
|
||
>
|
||
> एक regex भी कमजोर हो सकता है जैसे:
|
||
>
|
||
> `location ~ /docs/([^/])? { … $1 … }` - कमजोर
|
||
>
|
||
> `location ~ /docs/([^/\s])? { … $1 … }` - कमजोर नहीं (स्पेस की जांच कर रहा है)
|
||
>
|
||
> `location ~ /docs/(.*)? { … $1 … }` - कमजोर नहीं
|
||
|
||
Nginx कॉन्फ़िगरेशन में एक कमजोरी नीचे दिए गए उदाहरण द्वारा प्रदर्शित की गई है:
|
||
```
|
||
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/1.1 302 Moved Temporarily
|
||
Server: nginx/1.19.3
|
||
Content-Type: text/html
|
||
Content-Length: 145
|
||
Connection: keep-alive
|
||
Location: https://example.com/
|
||
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://example.com/%20X` - कोई भी HTTP कोड
|
||
- `https://example.com/%20H` - 400 खराब अनुरोध
|
||
|
||
यदि कमजोर है, तो पहला "X" के रूप में लौटेगा जो कोई भी HTTP विधि है और दूसरा एक त्रुटि लौटाएगा क्योंकि H एक मान्य विधि नहीं है। इसलिए सर्वर को कुछ इस तरह प्राप्त होगा: `GET / H HTTP/1.1` और यह त्रुटि को ट्रिगर करेगा।
|
||
|
||
अन्य पहचान उदाहरण होंगे:
|
||
|
||
- `http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x` - कोई भी HTTP कोड
|
||
- `http://company.tld/%20HTTP/1.1%0D%0AHost:%20x` - 400 खराब अनुरोध
|
||
|
||
उस वार्ता में प्रस्तुत कुछ कमजोर कॉन्फ़िगरेशन थे:
|
||
|
||
- ध्यान दें कि **`$uri`** अंतिम URL में जैसा है वैसा ही सेट किया गया है
|
||
```
|
||
location ^~ /lite/api/ {
|
||
proxy_pass http://lite-backend$uri$is_args$args;
|
||
}
|
||
```
|
||
- ध्यान दें कि फिर से **`$uri`** URL में है (इस बार एक पैरामीटर के अंदर)
|
||
```
|
||
location ~ ^/dna/payment {
|
||
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
|
||
proxy_pass http://$back;
|
||
```
|
||
- अब AWS S3 में
|
||
```
|
||
location /s3/ {
|
||
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) को मूल कारण के रूप में इंगित किया गया।
|
||
|
||
इस **गलत कॉन्फ़िगरेशन** का पता लगाने के लिए, निम्नलिखित कमांड निष्पादित की जा सकती है, जिसमें वेरिएबल प्रिंटिंग के लिए एक रेफरर हेडर सेट करना शामिल है:
|
||
```bash
|
||
$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’
|
||
```
|
||
इस गलत कॉन्फ़िगरेशन के लिए सिस्टमों में स्कैन करने से कई उदाहरण सामने आए जहाँ 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 के हस्तक्षेप के बिना भेजी जाती है।
|
||
|
||
एक उदाहरण परिदृश्य पर विचार करें जिसमें एक uWSGI एप्लिकेशन शामिल है:
|
||
```python
|
||
def application(environ, start_response):
|
||
start_response('500 Error', [('Content-Type', 'text/html'), ('Secret-Header', 'secret-info')])
|
||
return [b"Secret info, should not be visible!"]
|
||
```
|
||
इसका प्रबंधन करने के लिए, Nginx कॉन्फ़िगरेशन में विशिष्ट निर्देशों का उपयोग किया जाता है:
|
||
```
|
||
http {
|
||
error_page 500 /html/error.html;
|
||
proxy_intercept_errors on;
|
||
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 हेडर को छुपाता है, जिससे गोपनीयता और सुरक्षा बढ़ती है।
|
||
|
||
जब एक मान्य `GET` अनुरोध किया जाता है, तो Nginx इसे सामान्य रूप से संसाधित करता है, बिना किसी गुप्त हेडर को प्रकट किए एक मानक त्रुटि प्रतिक्रिया लौटाता है। हालाँकि, एक अमान्य HTTP अनुरोध इस तंत्र को बायपास करता है, जिससे कच्ची बैकएंड प्रतिक्रियाएँ, जिसमें गुप्त हेडर और त्रुटि संदेश शामिल हैं, उजागर हो जाती हैं।
|
||
|
||
## merge_slashes को बंद करना
|
||
|
||
डिफ़ॉल्ट रूप से, Nginx का **`merge_slashes` निर्देश** **`on`** पर सेट होता है, जो एक URL में कई फॉरवर्ड स्लैश को एकल स्लैश में संकुचित करता है। यह सुविधा, जबकि URL प्रसंस्करण को सरल बनाती है, Nginx के पीछे अनुप्रयोगों में कमजोरियों को अनजाने में छिपा सकती है, विशेष रूप से स्थानीय फ़ाइल समावेश (LFI) हमलों के प्रति संवेदनशील। सुरक्षा विशेषज्ञ **Danny Robinson और Rotem Bar** ने इस डिफ़ॉल्ट व्यवहार से जुड़े संभावित जोखिमों को उजागर किया है, विशेष रूप से जब Nginx एक रिवर्स-प्रॉक्सी के रूप में कार्य करता है।
|
||
|
||
ऐसे जोखिमों को कम करने के लिए, अनुशंसा की जाती है कि **इन कमजोरियों के प्रति संवेदनशील अनुप्रयोगों के लिए `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).
|
||
|
||
### **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-Buffering`: नियंत्रित करता है कि क्या Nginx को प्रतिक्रिया को बफर करना चाहिए या नहीं।
|
||
- `X-Accel-Charset`: X-Accel-Redirect का उपयोग करते समय प्रतिक्रिया के लिए वर्ण सेट सेट करता है।
|
||
- `X-Accel-Expires`: X-Accel-Redirect का उपयोग करते समय प्रतिक्रिया के लिए समाप्ति समय सेट करता है।
|
||
- `X-Accel-Limit-Rate`: X-Accel-Redirect का उपयोग करते समय प्रतिक्रियाओं के लिए ट्रांसफर की दर को सीमित करता है।
|
||
|
||
उदाहरण के लिए, हेडर **`X-Accel-Redirect`** Nginx में एक आंतरिक **पुनर्निर्देश** का कारण बनेगा। इसलिए, यदि Nginx कॉन्फ़िगरेशन में कुछ ऐसा है जैसे **`root /`** और वेब सर्वर से प्रतिक्रिया में **`X-Accel-Redirect: .env`** है, तो Nginx **`/.env`** (Path Traversal) की सामग्री भेजेगा।
|
||
|
||
### **Map Directive में डिफ़ॉल्ट मान**
|
||
|
||
**Nginx कॉन्फ़िगरेशन** में, `map` निर्देश अक्सर **अधिकार नियंत्रण** में एक भूमिका निभाता है। एक सामान्य गलती **डिफ़ॉल्ट** मान निर्दिष्ट न करना है, जो अनधिकृत पहुंच का कारण बन सकता है। उदाहरण के लिए:
|
||
```yaml
|
||
http {
|
||
map $uri $mappocallow {
|
||
/map-poc/private 0;
|
||
/map-poc/secret 0;
|
||
/map-poc/public 1;
|
||
}
|
||
}
|
||
```
|
||
|
||
```yaml
|
||
server {
|
||
location /map-poc {
|
||
if ($mappocallow = 0) {return 403;}
|
||
return 200 "Hello. It is private area: $mappocallow";
|
||
}
|
||
}
|
||
```
|
||
बिना `default` के, एक **दुष्ट उपयोगकर्ता** `/map-poc` के भीतर एक **अपरिभाषित URI** तक पहुँचकर सुरक्षा को बायपास कर सकता है। [Nginx मैनुअल](https://nginx.org/en/docs/http/ngx_http_map_module.html) ऐसे मुद्दों से बचने के लिए **डिफ़ॉल्ट मान** सेट करने की सलाह देता है।
|
||
|
||
### **DNS स्पूफिंग भेद्यता**
|
||
|
||
Nginx के खिलाफ DNS स्पूफिंग कुछ शर्तों के तहत संभव है। यदि एक हमलावर को Nginx द्वारा उपयोग किए जाने वाले **DNS सर्वर** का ज्ञान है और वह इसके DNS प्रश्नों को इंटरसेप्ट कर सकता है, तो वह DNS रिकॉर्ड को स्पूफ कर सकता है। हालाँकि, यह विधि तब अप्रभावी है जब Nginx को DNS समाधान के लिए **localhost (127.0.0.1)** का उपयोग करने के लिए कॉन्फ़िगर किया गया हो। Nginx एक DNS सर्वर को इस प्रकार निर्दिष्ट करने की अनुमति देता है:
|
||
```yaml
|
||
resolver 8.8.8.8;
|
||
```
|
||
### **`proxy_pass` और `internal` निर्देश**
|
||
|
||
**`proxy_pass`** निर्देश का उपयोग अनुरोधों को अन्य सर्वरों की ओर पुनर्निर्देशित करने के लिए किया जाता है, चाहे वह आंतरिक हो या बाहरी। **`internal`** निर्देश यह सुनिश्चित करता है कि कुछ स्थान केवल Nginx के भीतर ही सुलभ हैं। जबकि ये निर्देश अपने आप में कमजोरियाँ नहीं हैं, उनकी कॉन्फ़िगरेशन की सावधानीपूर्वक जांच की आवश्यकता होती है ताकि सुरक्षा में चूक न हो।
|
||
|
||
## proxy_set_header Upgrade & Connection
|
||
|
||
यदि nginx सर्वर को Upgrade और Connection हेडर पास करने के लिए कॉन्फ़िगर किया गया है, तो एक [**h2c Smuggling हमला**](../../pentesting-web/h2c-smuggling.md) किया जा सकता है ताकि संरक्षित/आंतरिक एंडपॉइंट्स तक पहुँच प्राप्त की जा सके।
|
||
|
||
> [!CAUTION]
|
||
> यह कमजोरी एक हमलावर को **`proxy_pass` एंडपॉइंट** (`http://backend:9999` इस मामले में) के साथ एक सीधा कनेक्शन स्थापित करने की अनुमति देगी, जिसका सामग्री nginx द्वारा जांचा नहीं जाएगा।
|
||
|
||
`/flag` को चुराने के लिए कमजोर कॉन्फ़िगरेशन का उदाहरण [यहाँ](https://bishopfox.com/blog/h2c-smuggling-request) है:
|
||
```
|
||
server {
|
||
listen 443 ssl;
|
||
server_name localhost;
|
||
|
||
ssl_certificate /usr/local/nginx/conf/cert.pem;
|
||
ssl_certificate_key /usr/local/nginx/conf/privkey.pem;
|
||
|
||
location / {
|
||
proxy_pass http://backend:9999;
|
||
proxy_http_version 1.1;
|
||
proxy_set_header Upgrade $http_upgrade;
|
||
proxy_set_header Connection $http_connection;
|
||
}
|
||
|
||
location /flag {
|
||
deny all;
|
||
}
|
||
```
|
||
> [!WARNING]
|
||
> ध्यान दें कि भले ही `proxy_pass` एक विशिष्ट **path** जैसे `http://backend:9999/socket.io` की ओर इशारा कर रहा हो, कनेक्शन `http://backend:9999` के साथ स्थापित किया जाएगा, इसलिए आप उस आंतरिक एंडपॉइंट के अंदर **किसी अन्य path** से संपर्क कर सकते हैं। इसलिए यह मायने नहीं रखता कि proxy_pass के URL में कोई path निर्दिष्ट किया गया है।
|
||
|
||
## Try it yourself
|
||
|
||
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)
|
||
|
||
Gixy Nginx कॉन्फ़िगरेशन का विश्लेषण करने के लिए एक उपकरण है। Gixy का मुख्य लक्ष्य सुरक्षा गलत कॉन्फ़िगरेशन को रोकना और दोष पहचान को स्वचालित करना है।
|
||
|
||
### [Nginxpwner](https://github.com/stark0de/nginxpwner)
|
||
|
||
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/)
|
||
- [**https://github.com/yandex/gixy/issues/115**](https://github.com/yandex/gixy/issues/115)
|
||
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|