Nginx

Missing root location

जब Nginx सर्वर को कॉन्फ़िगर किया जाता है, तो root directive एक महत्वपूर्ण भूमिका निभाता है क्योंकि यह उस मूल निर्देशिका को परिभाषित करता है जिससे फ़ाइलें सर्व की जाती हैं। नीचे दिए गए उदाहरण पर विचार करें:

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

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/

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

निम्नलिखित पृष्ठ की जांच करें कि निर्देशों को कैसे बायपास किया जाए जैसे:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

{{#ref}} ../../pentesting-web/proxy-waf-protections-bypass.md {{#endref}}

असुरक्षित वेरिएबल उपयोग / HTTP अनुरोध विभाजन

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://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 पर एक सुरक्षा रिपोर्ट में उजागर किया गया था, जिसे यहां देखा जा सकता है। त्रुटि संदेश की आगे की जांच ने इसके होने की पहचान Nginx के कोडबेस के SSI फ़िल्टर मॉड्यूल के भीतर की, जिससे सर्वर साइड इनक्लूड्स (SSI) को मूल कारण के रूप में इंगित किया गया।

इस गलत कॉन्फ़िगरेशन का पता लगाने के लिए, निम्नलिखित कमांड निष्पादित की जा सकती है, जिसमें वेरिएबल प्रिंटिंग के लिए एक रेफरर हेडर सेट करना शामिल है:

$ 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 एप्लिकेशन शामिल है:

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: यह निर्देश Nginx को 300 से अधिक स्थिति कोड वाले बैकएंड प्रतिक्रियाओं के लिए एक कस्टम प्रतिक्रिया देने की अनुमति देता है। यह सुनिश्चित करता है कि, हमारे उदाहरण uWSGI एप्लिकेशन के लिए, 500 Error प्रतिक्रिया को Nginx द्वारा रोका और संभाला जाता है।
• 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.

Maclicious Response Headers

जैसा कि इस लेख में दिखाया गया है, कुछ हेडर हैं जो यदि वे वेब सर्वर से प्रतिक्रिया में मौजूद हैं तो वे 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-Redirect Nginx में एक आंतरिक पुनर्निर्देश का कारण बनेगा। इसलिए, यदि Nginx कॉन्फ़िगरेशन में कुछ ऐसा है जैसे root / और वेब सर्वर से प्रतिक्रिया में X-Accel-Redirect: .env है, तो Nginx /.env (Path Traversal) की सामग्री भेजेगा।

Map Directive में डिफ़ॉल्ट मान

Nginx कॉन्फ़िगरेशन में, map निर्देश अक्सर अधिकार नियंत्रण में एक भूमिका निभाता है। एक सामान्य गलती डिफ़ॉल्ट मान निर्दिष्ट न करना है, जो अनधिकृत पहुंच का कारण बन सकता है। उदाहरण के लिए:

http {
map $uri $mappocallow {
/map-poc/private 0;
/map-poc/secret 0;
/map-poc/public 1;
}
}

server {
location /map-poc {
if ($mappocallow = 0) {return 403;}
return 200 "Hello. It is private area: $mappocallow";
}
}

बिना default के, एक दुष्ट उपयोगकर्ता /map-poc के भीतर एक अपरिभाषित URI तक पहुँचकर सुरक्षा को बायपास कर सकता है। Nginx मैनुअल ऐसे मुद्दों से बचने के लिए डिफ़ॉल्ट मान सेट करने की सलाह देता है।

DNS स्पूफिंग भेद्यता

Nginx के खिलाफ DNS स्पूफिंग कुछ शर्तों के तहत संभव है। यदि एक हमलावर को Nginx द्वारा उपयोग किए जाने वाले DNS सर्वर का ज्ञान है और वह इसके DNS प्रश्नों को इंटरसेप्ट कर सकता है, तो वह DNS रिकॉर्ड को स्पूफ कर सकता है। हालाँकि, यह विधि तब अप्रभावी है जब Nginx को DNS समाधान के लिए localhost (127.0.0.1) का उपयोग करने के लिए कॉन्फ़िगर किया गया हो। Nginx एक DNS सर्वर को इस प्रकार निर्दिष्ट करने की अनुमति देता है:

resolver 8.8.8.8;

proxy_pass और internal निर्देश

proxy_pass निर्देश का उपयोग अनुरोधों को अन्य सर्वरों की ओर पुनर्निर्देशित करने के लिए किया जाता है, चाहे वह आंतरिक हो या बाहरी। internal निर्देश यह सुनिश्चित करता है कि कुछ स्थान केवल Nginx के भीतर ही सुलभ हैं। जबकि ये निर्देश अपने आप में कमजोरियाँ नहीं हैं, उनकी कॉन्फ़िगरेशन की सावधानीपूर्वक जांच की आवश्यकता होती है ताकि सुरक्षा में चूक न हो।

proxy_set_header Upgrade & Connection

यदि nginx सर्वर को Upgrade और Connection हेडर पास करने के लिए कॉन्फ़िगर किया गया है, तो एक h2c Smuggling हमला किया जा सकता है ताकि संरक्षित/आंतरिक एंडपॉइंट्स तक पहुँच प्राप्त की जा सके।

/flag को चुराने के लिए कमजोर कॉन्फ़िगरेशन का उदाहरण यहाँ है:

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;
}

Try it yourself

Detectify ने एक GitHub रिपॉजिटरी बनाई है जहाँ आप Docker का उपयोग करके अपने स्वयं के कमजोर Nginx परीक्षण सर्वर को स्थापित कर सकते हैं, जिसमें इस लेख में चर्चा की गई कुछ गलत कॉन्फ़िगरेशन हैं और उन्हें स्वयं खोजने का प्रयास कर सकते हैं!

https://github.com/detectify/vulnerable-nginx

Static Analyzer tools

GIXY

Gixy Nginx कॉन्फ़िगरेशन का विश्लेषण करने के लिए एक उपकरण है। Gixy का मुख्य लक्ष्य सुरक्षा गलत कॉन्फ़िगरेशन को रोकना और दोष पहचान को स्वचालित करना है।

Nginxpwner

Nginxpwner सामान्य Nginx गलत कॉन्फ़िगरेशन और कमजोरियों की खोज के लिए एक सरल उपकरण है।

References

• https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/
• http://blog.zorinaq.com/nginx-resolver-vulns/
• https://github.com/yandex/gixy/issues/115