mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-30 00:20:59 +00:00
353 lines
30 KiB
Markdown
353 lines
30 KiB
Markdown
# Nginx
|
||
|
||
<details>
|
||
|
||
<summary><strong>AWS हैकिंग सीखें शून्य से लेकर हीरो तक</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> के साथ!</strong></summary>
|
||
|
||
HackTricks का समर्थन करने के अन्य तरीके:
|
||
|
||
* यदि आप चाहते हैं कि आपकी **कंपनी का विज्ञापन HackTricks में दिखाई दे** या **HackTricks को PDF में डाउनलोड करें**, तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) देखें!
|
||
* [**आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें**](https://peass.creator-spring.com)
|
||
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा एक्सक्लूसिव [**NFTs**](https://opensea.io/collection/the-peass-family) का संग्रह
|
||
* 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) में **शामिल हों** या [**telegram group**](https://t.me/peass) में या **Twitter** पर मुझे 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm) **का अनुसरण करें.**
|
||
* **HackTricks** के [**github repos**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) में PRs सबमिट करके अपनी हैकिंग ट्रिक्स साझा करें.
|
||
|
||
</details>
|
||
|
||
<figure><img src="../../.gitbook/assets/image (1) (1) (2) (4).png" alt=""><figcaption></figcaption></figure>
|
||
|
||
[**DragonJAR Security Conference एक अंतर्राष्ट्रीय साइबर सुरक्षा इवेंट है**](https://www.dragonjarcon.org/) जो एक दशक से अधिक समय से चल रहा है और 7 और 8 सितंबर 2023 को बोगोटा, कोलंबिया में आयोजित किया जाएगा। यह एक उच्च तकनीकी सामग्री वाला इवेंट है जहां स्पेनिश में नवीनतम अनुसंधान प्रस्तुत किए जाते हैं जो दुनिया भर के हैकर्स और शोधकर्ताओं को आकर्षित करते हैं।\
|
||
अभी निम्नलिखित लिंक पर रजिस्टर करें और इस महान सम्मेलन को मिस न करें!:
|
||
|
||
{% embed url="https://www.dragonjarcon.org/" %}
|
||
|
||
## Missing root location <a href="#missing-root-location" id="missing-root-location"></a>
|
||
```
|
||
server {
|
||
root /etc/nginx;
|
||
|
||
location /hello.txt {
|
||
try_files $uri $uri/ =404;
|
||
proxy_pass http://127.0.0.1:8080/;
|
||
}
|
||
}
|
||
```
|
||
`root` निर्देश निर्दिष्ट करता है कि Nginx के लिए मूल फ़ोल्डर क्या है। ऊपर दिए गए उदाहरण में, मूल फ़ोल्डर `/etc/nginx` है, जिसका अर्थ है कि हम उस फ़ोल्डर के भीतर की फ़ाइलों तक पहुँच सकते हैं। ऊपर दिए गए कॉन्फ़िगरेशन में `/ (location / {...})` के लिए कोई स्थान नहीं है, केवल `/hello.txt` के लिए है। इस कारण से, `root` निर्देश वैश्विक रूप से सेट हो जाएगा, यानी `/` के लिए अनुरोध आपको स्थानीय पथ `/etc/nginx` पर ले जाएगा।
|
||
|
||
जितना सरल `GET /nginx.conf` अनुरोध होगा, वह `/etc/nginx/nginx.conf` में संग्रहीत Nginx कॉन्फ़िगरेशन फ़ाइल की सामग्री को प्रकट कर देगा। यदि मूल `/etc` पर सेट है, तो `/nginx/nginx.conf` के लिए `GET` अनुरोध कॉन्फ़िगरेशन फ़ाइल को प्रकट कर देगा। कुछ मामलों में अन्य कॉन्फ़िगरेशन फ़ाइलों, एक्सेस-लॉग्स और यहां तक कि HTTP बेसिक प्रमाणीकरण के लिए एन्क्रिप्टेड क्रेडेंशियल्स तक पहुँचना संभव है।
|
||
|
||
## Alias LFI Misconfiguration <a href="#alias-lfi-misconfiguration" id="alias-lfi-misconfiguration"></a>
|
||
|
||
Nginx कॉन्फ़िगरेशन के अंदर "location" वक्तव्यों को देखें, यदि कोई इस तरह दिखता है:
|
||
```
|
||
location /imgs {
|
||
alias /path/images/;
|
||
}
|
||
```
|
||
इसमें LFI संवेदनशीलता है क्योंकि:
|
||
```
|
||
/imgs../flag.txt
|
||
```
|
||
```markdown
|
||
# NGINX पेंटेस्टिंग
|
||
|
||
## सामान्य जानकारी
|
||
|
||
NGINX एक लोकप्रिय वेब सर्वर है जो अपाचे के विकल्प के रूप में उभरा है। यह उच्च प्रदर्शन, स्थिरता, सरल कॉन्फ़िगरेशन, और कम संसाधन की खपत के लिए जाना जाता है।
|
||
|
||
## सुरक्षा जांच
|
||
|
||
### संस्करण की जांच
|
||
|
||
सर्वर के संस्करण की जानकारी अक्सर HTTP हेडर्स में पाई जाती है। इसे निम्नलिखित कमांड के साथ प्राप्त किया जा सकता है:
|
||
|
||
```
|
||
curl -I <URL>
|
||
```
|
||
|
||
सर्वर से `Server` हेडर में NGINX संस्करण की जानकारी मिल सकती है।
|
||
|
||
### डिफ़ॉल्ट फ़ाइलें और निर्देशिकाएँ
|
||
|
||
NGINX सर्वर पर डिफ़ॉल्ट फ़ाइलें और निर्देशिकाएँ संवेदनशील जानकारी का स्रोत हो सकती हैं। इन्हें खोजने के लिए, निम्नलिखित उपकरण और तकनीकें उपयोगी हो सकती हैं:
|
||
|
||
- `dirb`
|
||
- `gobuster`
|
||
- `nikto`
|
||
|
||
### संवेदनशील फ़ाइलें
|
||
|
||
कुछ फ़ाइलें जैसे कि `.git`, `.hg`, `.svn`, `backup.tar.gz`, या `dump.sql` सर्वर पर अनजाने में छोड़ी गई हो सकती हैं और यदि उन्हें एक्सेस किया जा सके तो वे संवेदनशील जानकारी का खुलासा कर सकती हैं।
|
||
|
||
### सर्वर कॉन्फ़िगरेशन त्रुटियाँ
|
||
|
||
गलत तरीके से कॉन्फ़िगर किए गए सर्वर अनधिकृत पहुँच या जानकारी के लीक का कारण बन सकते हैं। इसमें शामिल हैं:
|
||
|
||
- अनुचित फ़ाइल अनुमतियाँ
|
||
- डिफ़ॉल्ट क्रेडेंशियल्स
|
||
- अनुचित डायरेक्टरी लिस्टिंग्स
|
||
|
||
### SSL/TLS जांच
|
||
|
||
SSL/TLS कॉन्फ़िगरेशन की जांच करने के लिए, निम्नलिखित उपकरण उपयोगी हो सकते हैं:
|
||
|
||
- `sslyze`
|
||
- `testssl.sh`
|
||
- `Qualys SSL Labs' SSL Test`
|
||
|
||
ये उपकरण सर्टिफिकेट की वैधता, समर्थित साइफर्स, और अन्य सुरक्षा जांचों के लिए उपयोगी हैं।
|
||
|
||
## उपयोगी कमांड्स
|
||
|
||
यहाँ कुछ उपयोगी कमांड्स दी गई हैं जो NGINX पेंटेस्टिंग के दौरान काम आ सकती हैं:
|
||
|
||
```
|
||
curl -I <URL>
|
||
nikto -h <URL>
|
||
gobuster dir -u <URL> -w <wordlist>
|
||
```
|
||
|
||
इन कमांड्स का उपयोग सर्वर की जानकारी प्राप्त करने, संवेदनशील फ़ाइलों की खोज करने, और सुरक्षा जांच करने के लिए किया जा सकता है।
|
||
```
|
||
```
|
||
/path/images/../flag.txt
|
||
```
|
||
सही कॉन्फ़िगरेशन होगा:
|
||
```
|
||
location /imgs/ {
|
||
alias /path/images/;
|
||
}
|
||
```
|
||
**तो, यदि आपको कोई Nginx सर्वर मिलता है तो आपको इस संवेदनशीलता की जांच करनी चाहिए। साथ ही, यदि आप पाते हैं कि फाइल/डायरेक्टरीज़ की ब्रूट फोर्स अजीब तरह से व्यवहार कर रही है, तो आप इसे खोज सकते हैं।**
|
||
|
||
अधिक जानकारी: [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
|
||
```
|
||
## असुरक्षित पथ प्रतिबंध <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
|
||
|
||
निर्देशों को बायपास करने के तरीके जानने के लिए निम्नलिखित पृष्ठ देखें:
|
||
```plaintext
|
||
location = /admin {
|
||
deny all;
|
||
}
|
||
|
||
location = /admin/ {
|
||
deny all;
|
||
}
|
||
```
|
||
{% content-ref url="../../pentesting-web/proxy-waf-protections-bypass.md" %}
|
||
[proxy-waf-protections-bypass.md](../../pentesting-web/proxy-waf-protections-bypass.md)
|
||
{% endcontent-ref %}
|
||
|
||
## असुरक्षित वेरिएबल का उपयोग <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
|
||
|
||
एक संवेदनशील Nginx कॉन्फ़िगरेशन का उदाहरण है:
|
||
```
|
||
location / {
|
||
return 302 https://example.com$uri;
|
||
}
|
||
```
|
||
HTTP अनुरोधों के लिए नई पंक्ति वर्ण \r (Carriage Return) और \n (Line Feed) हैं। नई पंक्ति वर्णों को URL-encoding करने से वर्णों का निम्नलिखित प्रतिनिधित्व `%0d%0a` होता है। जब ये वर्ण एक अनुरोध में `http://localhost/%0d%0aDetectify:%20clrf` की तरह शामिल किए जाते हैं तो एक गलत कॉन्फ़िगरेशन वाले सर्वर को भेजे जाने पर, सर्वर `Detectify` नामक एक नया हेडर के साथ प्रतिक्रिया देगा क्योंकि $uri वेरिएबल में URL-decoded नई पंक्ति वर्ण होते हैं।
|
||
```
|
||
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/) पर।
|
||
|
||
### कोई भी वेरिएबल
|
||
|
||
कुछ मामलों में, उपयोगकर्ता-प्रदत्त डेटा को Nginx वेरिएबल के रूप में माना जा सकता है। यह अस्पष्ट है कि ऐसा क्यों हो रहा है, लेकिन यह इतना असामान्य या जांचने के लिए आसान नहीं है, जैसा कि इस [H1 रिपोर्ट](https://hackerone.com/reports/370094) में देखा गया है। यदि हम त्रुटि संदेश की खोज करते हैं, तो हम देख सकते हैं कि यह [SSI फिल्टर मॉड्यूल](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365) में पाया जाता है, जिससे पता चलता है कि यह SSI के कारण है।
|
||
|
||
इसकी जांच करने का एक तरीका है रेफरर हेडर मान सेट करना:
|
||
```
|
||
$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’
|
||
```
|
||
हमने इस गलत कॉन्फ़िगरेशन के लिए स्कैन किया और कई उदाहरण पाए जहां एक उपयोगकर्ता Nginx वेरिएबल्स का मूल्य प्रिंट कर सकता था। पाए गए संवेदनशील उदाहरणों की संख्या में कमी आई है, जो इंगित करता है कि इसे पैच किया गया हो सकता है।
|
||
|
||
## कच्चे बैकएंड प्रतिक्रिया पढ़ना
|
||
|
||
Nginx के `proxy_pass` के साथ, बैकएंड द्वारा बनाई गई त्रुटियों और HTTP हेडर्स को इंटरसेप्ट करने की संभावना होती है। यह बहुत उपयोगी है यदि आप आंतरिक त्रुटि संदेशों और हेडर्स को छिपाना चाहते हैं ताकि वे Nginx द्वारा संभाले जाएं। यदि बैकएंड एक त्रुटि प्रतिक्रिया के साथ उत्तर देता है, तो Nginx स्वचालित रूप से एक कस्टम त्रुटि पृष्ठ प्रदान करेगा। लेकिन क्या होगा यदि Nginx को समझ में नहीं आता कि यह एक HTTP प्रतिक्रिया है?
|
||
|
||
यदि एक क्लाइंट Nginx को एक अमान्य HTTP अनुरोध भेजता है, तो वह अनुरोध जैसा है वैसा ही बैकएंड को फॉरवर्ड किया जाएगा, और बैकएंड अपनी कच्ची सामग्री के साथ उत्तर देगा। फिर, Nginx अमान्य HTTP प्रतिक्रिया को समझ नहीं पाएगा और बस इसे क्लाइंट को फॉरवर्ड कर देगा। इसे एक 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;
|
||
}
|
||
```
|
||
```markdown
|
||
[proxy\_intercept\_errors](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_intercept\_errors) का उपयोग करके यदि बैकएंड का रिस्पॉन्स स्टेटस 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/1.1 500 Internal Server Error
|
||
Server: nginx/1.10.3
|
||
Content-Type: text/html
|
||
Content-Length: 34
|
||
Connection: close
|
||
```
|
||
लेकिन अगर हम एक अमान्य HTTP अनुरोध भेजते हैं, जैसे कि:
|
||
```
|
||
GET /? XTTP/1.1
|
||
Host: 127.0.0.1
|
||
Connection: close
|
||
```
|
||
हमें निम्नलिखित प्रतिक्रिया मिलेगी:
|
||
```
|
||
XTTP/1.1 500 Error
|
||
Content-Type: text/html
|
||
Secret-Header: secret-info
|
||
|
||
Secret info, should not be visible!
|
||
```
|
||
## merge\_slashes को off सेट किया गया है
|
||
|
||
[merge\_slashes](http://nginx.org/en/docs/http/ngx\_http\_core\_module.html#merge\_slashes) निर्देश को डिफ़ॉल्ट रूप से "on" पर सेट किया जाता है, जो दो या अधिक आगे की स्लैशेज़ को एक में संपीड़ित करने की एक तंत्र है, इसलिए `///` `/` बन जाएगा। यदि Nginx का उपयोग एक रिवर्स-प्रॉक्सी के रूप में किया जाता है और प्रॉक्सी किया जा रहा एप्लिकेशन स्थानीय फ़ाइल समावेशन के लिए संवेदनशील है, तो अनुरोध में अतिरिक्त स्लैशेज़ का उपयोग इसका शोषण करने के लिए जगह छोड़ सकता है। इसे [Danny Robinson और Rotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d) द्वारा विस्तार से वर्णित किया गया है।
|
||
|
||
हमें 33 Nginx कॉन्फ़िगरेशन फ़ाइलें मिलीं जिनमें `merge_slashes` को "off" पर सेट किया गया है।
|
||
|
||
## map निर्देश के लिए default निर्दिष्ट नहीं है
|
||
|
||
यह एक सामान्य मामला प्रतीत होता है जब **`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";
|
||
}
|
||
...
|
||
}
|
||
```
|
||
[मैनुअल के अनुसार](https://nginx.org/en/docs/http/ngx_http_map_module.html):
|
||
|
||
> डिफ़ॉल्ट मान\
|
||
> यदि स्रोत मान निर्दिष्ट वेरिएंट्स में से किसी से भी मेल नहीं खाता है तो परिणामी मान सेट करता है। जब डिफ़ॉल्ट निर्दिष्ट नहीं होता है, तो डिफ़ॉल्ट\
|
||
> परिणामी मान एक खाली स्ट्रिंग होगा।
|
||
|
||
`default` मान को भूलना आसान है। इसलिए **दुर्भावनापूर्ण व्यक्ति "प्राधिकरण नियंत्रण" को बायपास कर सकता है** बस `/map-poc` के अंदर **अस्तित्वहीन मामले तक पहुँचकर** जैसे कि `https://targethost.com/map-poc/another-private-area`.
|
||
|
||
## DNS Spoofing Nginx
|
||
|
||
इस पोस्ट के अनुसार: [http://blog.zorinaq.com/nginx-resolver-vulns/](http://blog.zorinaq.com/nginx-resolver-vulns/) **DNS रिकॉर्ड्स को स्पूफ करना संभव हो सकता है** Nginx के लिए यदि आप **DNS सर्वर जानते हैं जिसका उपयोग Nginx कर रहा है** (और आप किसी तरह संचार को इंटरसेप्ट कर सकते हैं, इसलिए यह **मान्य नहीं है अगर 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 हमला**](../../pentesting-web/h2c-smuggling.md) किया जा सकता है।
|
||
|
||
{% hint style="danger" %}
|
||
यह कमजोरी हमलावर को **`proxy_pass` एंडपॉइंट (`http://backend:9999` इस मामले में) के साथ सीधा संबंध स्थापित करने की अनुमति देगी** जिसकी सामग्री nginx द्वारा जांची नहीं जाएगी।
|
||
{% endhint %}
|
||
|
||
यहाँ से `/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;
|
||
}
|
||
```
|
||
{% hint style="warning" %}
|
||
ध्यान दें कि यदि `proxy_pass` एक विशिष्ट **पथ** जैसे कि `http://backend:9999/socket.io` की ओर इशारा कर रहा था, तो भी कनेक्शन `http://backend:9999` के साथ स्थापित किया जाएगा इसलिए आप **उस आंतरिक एंडपॉइंट के अंदर किसी भी अन्य पथ से संपर्क कर सकते हैं। इसलिए यह महत्वपूर्ण नहीं है कि proxy\_pass के URL में कोई पथ निर्दिष्ट है या नहीं।**
|
||
{% endhint %}
|
||
|
||
## इसे स्वयं आजमाएं
|
||
|
||
Detectify ने एक GitHub रिपॉजिटरी बनाई है जहाँ आप Docker का उपयोग करके अपना खुद का संवेदनशील Nginx टेस्ट सर्वर सेटअप कर सकते हैं जिसमें इस लेख में चर्चा की गई कुछ गलत कॉन्फ़िगरेशन हैं और खुद उन्हें ढूंढने की कोशिश कर सकते हैं!
|
||
|
||
[https://github.com/detectify/vulnerable-nginx](https://github.com/detectify/vulnerable-nginx)
|
||
|
||
## स्टैटिक एनालाइज़र टूल्स
|
||
|
||
### [GIXY](https://github.com/yandex/gixy)
|
||
|
||
Gixy Nginx कॉन्फ़िगरेशन का विश्लेषण करने के लिए एक टूल है। Gixy का मुख्य उद्देश्य सुरक्षा गलत कॉन्फ़िगरेशन को रोकना और दोष पता लगाने को स्वचालित करना है।
|
||
|
||
### [Nginxpwner](https://github.com/stark0de/nginxpwner)
|
||
|
||
Nginxpwner एक सरल टूल है जो Nginx की सामान्य गलत कॉन्फ़िगरेशन और कमजोरियों की तलाश करता है।
|
||
|
||
## संदर्भ
|
||
|
||
* [**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)
|
||
|
||
<figure><img src="../../.gitbook/assets/image (1) (1) (2) (4).png" alt=""><figcaption></figcaption></figure>
|
||
|
||
[**DragonJAR Security Conference es un evento internacional de ciberseguridad**](https://www.dragonjarcon.org/) जो एक दशक से अधिक समय से चल रहा है और यह 7 और 8 सितंबर 2023 को बोगोटा, कोलंबिया में आयोजित किया जाएगा। यह एक उच्च तकनीकी सामग्री वाला कार्यक्रम है जहाँ स्पेनिश में नवीनतम अनुसंधान प्रस्तुत किए जाते हैं जो दुनिया भर के हैकर्स और शोधकर्ताओं को आकर्षित करता है।\
|
||
अभी निम्नलिखित लिंक पर पंजीकरण करें और इस महान सम्मेलन को मिस न करें!:
|
||
|
||
{% embed url="https://www.dragonjarcon.org/" %}
|
||
|
||
<details>
|
||
|
||
<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||
|
||
HackTricks का समर्थन करने के अन्य तरीके:
|
||
|
||
* यदि आप चाहते हैं कि आपकी **कंपनी का विज्ञापन HackTricks में दिखाई दे** या **HackTricks को PDF में डाउनलोड करें** तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) देखें!
|
||
* [**आधिकारिक PEASS & HackTricks स्वैग**](https://peass.creator-spring.com) प्राप्त करें
|
||
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा एक्सक्लूसिव [**NFTs**](https://opensea.io/collection/the-peass-family) संग्रह
|
||
* 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) में **शामिल हों** या [**telegram group**](https://t.me/peass) में या **Twitter** पर मुझे 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm) **का पालन करें।**
|
||
* **HackTricks** के [**HackTricks**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos में PRs सबमिट करके अपनी हैकिंग ट्रिक्स साझा करें।
|
||
|
||
</details>
|