hacktricks/network-services-pentesting/pentesting-web/nginx.md

# Nginx

<details>

<summary><strong>AWS hacklemeyi sıfırdan ileri seviyeye öğrenin</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> ile!</strong></summary>

HackTricks'ı desteklemenin diğer yolları:

* **Şirketinizi HackTricks'te reklamını görmek istiyorsanız** veya **HackTricks'i PDF olarak indirmek istiyorsanız** [**ABONELİK PLANLARI**]'na(https://github.com/sponsors/carlospolop) göz atın!
* [**Resmi PEASS & HackTricks ürünlerini**](https://peass.creator-spring.com) edinin
* [**PEASS Ailesi'ni**](https://opensea.io/collection/the-peass-family) keşfedin, özel [**NFT'lerimiz**](https://opensea.io/collection/the-peass-family) koleksiyonumuz
* **💬 [**Discord grubumuza**](https://discord.gg/hRep4RUj7f) katılın veya [**telegram grubumuza**](https://t.me/peass) katılın veya bizi **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** takip edin.**
* **Hacking püf noktalarınızı paylaşarak PR göndererek** [**HackTricks**](https://github.com/carlospolop/hacktricks) ve [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github depolarına katkıda bulunun.

</details>

<figure><img src="../../.gitbook/assets/image (14) (1).png" alt=""><figcaption></figcaption></figure>

**Hemen kullanıma hazır zafiyet değerlendirme ve penetrasyon testi kurulumu**. 20'den fazla araç ve özellikle tam bir pentest çalıştırın, keşiften raporlamaya kadar uzanan. Pentester'ları değiştirmiyoruz - özel araçlar, tespit ve istismar modülleri geliştiriyoruz, böylece daha derine inme, shell'ler açma ve eğlenme zamanı kazanıyorlar.

{% embed url="https://pentest-tools.com/" %}

## Eksik root konumu <a href="#missing-root-location" id="missing-root-location"></a>

Nginx sunucusunu yapılandırırken, **root direktifi** dosyaların sunulduğu temel dizini tanımlayarak kritik bir rol oynar. Aşağıdaki örneği göz önünde bulundurun:
```bash
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` kök dizini olarak belirlenmiştir. Bu kurulum, belirtilen kök dizini içindeki dosyalara erişime izin verir, örneğin `/hello.txt`. Ancak, yalnızca belirli bir konum (`/hello.txt`) tanımlanmıştır. Kök konum (`location / {...}`) için herhangi bir yapılandırma bulunmamaktadır. Bu ihmal, kök direktifinin genel olarak uygulanmasını sağlar, bu da kök dizinindeki `/etc/nginx` altındaki dosyalara erişim sağlar.

Bu yapılandırmadan kaynaklanan önemli bir güvenlik endişesi ortaya çıkar. Basit bir `GET` isteği, örneğin `GET /nginx.conf`, `/etc/nginx/nginx.conf` konumundaki Nginx yapılandırma dosyasını sunarak hassas bilgilerin ifşa edilmesine neden olabilir. Kökü daha az hassas bir dizine, örneğin `/etc` olarak ayarlamak, bu riski azaltabilir, ancak yine de diğer hassas dosyalara, diğer yapılandırma dosyalarına, erişim günlüklerine ve hatta HTTP temel kimlik doğrulaması için kullanılan şifrelenmiş kimlik bilgilerine istenmeyen erişime izin verebilir.

## Alias LFI Yan Yapılandırması <a href="#alias-lfi-misconfiguration" id="alias-lfi-misconfiguration"></a>

Nginx'in yapılandırma dosyalarında, "location" direktifleri için dikkatli bir inceleme gereklidir. Bir güvenlik açığı olan Yerel Dosya Dahil Etme (LFI) yanlışlıkla aşağıdaki gibi bir yapılandırmayla tanıtılabilir:
```
location /imgs {
alias /path/images/;
}
```
Bu yapılandırma, sunucunun `/imgs../flag.txt` gibi istekleri yorumlayarak amaçlanan dizinin dışındaki dosyalara erişim girişimi olarak algılanmasından dolayı LFI saldırılarına duyarlıdır, etkili bir şekilde `/path/images/../flag.txt`'ye çözülür. Bu zayıflık, saldırganların web aracılığıyla erişilememesi gereken dosyaları sunucunun dosya sistemi üzerinden almasına olanak tanır.

Bu zafiyeti hafifletmek 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/](https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/)

Accunetix testleri:
```
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 yol kısıtlaması <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>

Aşağıdaki sayfayı kontrol edin:
```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 %}

## Güvensiz değişken kullanımı / HTTP İsteği Bölme <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>

{% hint style="danger" %}
`$uri` ve `$document_uri` gibi güvenlik açıklı değişkenler bulunmaktadır ve bunlar `$request_uri` ile değiştirilerek düzeltilebilir.

Ayrıca regex de güvenlik açığına neden olabilir:

`location ~ /docs/([^/])? { … $1 … }` - Güvenlik açığı bulunmaktadır

`location ~ /docs/([^/\s])? { … $1 … }` - Güvenlik açığı bulunmamaktadır (boşlukları kontrol eder)

`location ~ /docs/(.*)? { … $1 … }`  - Güvenlik açığı bulunmamaktadır
{% endhint %}

Nginx yapılandırmasındaki bir güvenlik açığı aşağıdaki örnekle gösterilmektedir:
```
location / {
return 302 https://example.com$uri;
}
```
HTTP isteklerinde \r (Taşıma İşareti) ve \n (Satır Beslemesi) karakterleri yeni satır karakterlerini belirtir ve URL kodlanmış formları `%0d%0a` olarak temsil edilir. Bu karakterleri bir istekte (örneğin, `http://localhost/%0d%0aDetectify:%20clrf`) içerdiğinde, yanlış yapılandırılmış bir sunucuya yeni bir başlık olan `Detectify` çıkarılmasına neden olur. Bu, $uri değişkeninin URL kodlanmış yeni satır karakterlerini çözmesi nedeniyle yanıtta beklenmeyen bir başlık oluşmasına sebep olur:
```
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 enjeksiyonu ve yanıt bölme riskleri hakkında daha fazla bilgi için [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/) adresini ziyaret edebilirsiniz.

Bu tekniğin ayrıca [**bu sunumda**](https://www.youtube.com/watch?v=gWQyWdZbdoY\&list=PL0xCSYnG\_iTtJe2V6PQqamBF73n7-f1Nr\&index=77) bazı zayıf örnekler ve tespit mekanizmaları ile açıklandığını öğrenebilirsiniz. Örneğin, Bu yanlış yapılandırmayı siyah kutu bakış açısından tespit etmek için şu istekleri kullanabilirsiniz:

* `https://example.com/%20X` - Herhangi bir HTTP kodu
* `https://example.com/%20H` - 400 Bad Request

Eğer zayıfsa, ilk istek "X" herhangi bir HTTP yöntemi olarak dönecek ve ikinci istek H geçerli bir yöntem olmadığı için bir hata dönecektir. Bu durumda sunucu şuna benzer bir şey alacak: `GET / H HTTP/1.1` ve bu hata tetiklenecektir.

Başka tespit örnekleri şunlar olabilir:

* `http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x` - Herhangi bir HTTP kodu
* `http://company.tld/%20HTTP/1.1%0D%0AHost:%20x` - 400 Bad Request

Bu sunumda bulunan bazı zayıf yapılandırmalar şunlardı:

* **`$uri`**'nin nihai URL'de olduğu gibi ayarlandığına dikkat edin.
```
location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}
```
* Yine **`$uri`**'nin URL'de (bu sefer bir parametre içinde) olduğuna dikkat edin.
```
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;
}
```
### Herhangi bir değişken

Belirli durumlarda, **kullanıcı tarafından sağlanan verilerin** belirli koşullar altında bir **Nginx değişkeni** olarak işleme tabi tutulabileceği keşfedildi. Bu davranışın nedeni oldukça belirsiz olsa da, nadir değil ve doğrulaması da kolay değil. Bu anormallik, HackerOne'da bir güvenlik raporunda vurgulandı ve [buradan](https://hackerone.com/reports/370094) görülebilir. Hatanın incelenmesi, [Nginx'in kod tabanındaki SSI filtre modülünde](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx\_http\_ssi\_filter\_module.c#L365) meydana gelen tespit edilmesine yol açtı ve Server Side Includes (SSI)'ı kök neden olarak belirledi.

Bu **yan yapılandırmayı tespit etmek** için, aşağıdaki komut çalıştırılabilir, bu komut değişken yazdırma testi için bir referer başlığı ayarlamayı içerir:
```bash
$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’
```
Sistemler üzerinde bu yan yapılandırma için yapılan taramalar, bir kullanıcı tarafından Nginx değişkenlerinin yazdırılabileceği birden fazla örneği ortaya çıkardı. Ancak, savunmasız örneklerin sayısında yaşanan azalma, bu sorunu düzeltme çabalarının kısmen başarılı olduğunu göstermektedir.

## Ham arka uç yanıtı okuma

Nginx, `proxy_pass` aracılığıyla hata ve HTTP başlıklarının arka uç tarafından üretilmesine izin veren bir özellik sunar ve bu sayede iç hata mesajlarını ve başlıklarını gizlemeyi amaçlar. Bu, Nginx'in özel hata sayfaları sunarak arka uç hatalarına yanıt vermesiyle gerçekleştirilir. Bununla birlikte, Nginx'in geçersiz bir HTTP isteğiyle karşılaştığında zorluklar ortaya çıkar. Böyle bir istek, alındığı gibi arka uca iletilir ve ardından arka ucun ham yanıtı doğrudan Nginx'in müdahalesi olmadan istemciye gönderilir. 

Bir uWSGI uygulamasını içeren bir örnek senaryoyu düşünün:
```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!"]
```
Bunu yönetmek için, Nginx yapılandırmasında belirli direktifler kullanılır:
```
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): Bu yönerge, Nginx'in durum kodu 300'den büyük olan arka uç yanıtları için özel bir yanıt sunmasını sağlar. Örneğimizde uWSGI uygulaması için, bir `500 Hata` yanıtının Nginx tarafından engellenip işlenmesini sağlar.
* [**proxy\_hide\_header**](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_hide\_header): Adından da anlaşılacağı gibi, bu yönerge belirli HTTP başlıklarını istemciden gizler, gizliliği ve güvenliği artırır.

Geçerli bir `GET` isteği yapıldığında, Nginx bunu normal şekilde işler, herhangi bir gizli başlığı açığa çıkarmadan standart bir hata yanıtı döndürür. Ancak, geçersiz bir HTTP isteği bu mekanizmayı atlar ve gizli başlıkları ve hata mesajlarını içeren ham arka uç yanıtlarının ortaya çıkmasına neden olur.

## merge\_slashes off olarak ayarlandı

Varsayılan olarak, Nginx'in **`merge_slashes` yönergesi** **`on`** olarak ayarlanmıştır, bu da bir URL'deki birden fazla ileri eğik çizgiyi tek bir çizgiye sıkıştırır. Bu özellik, URL işleme sürecini basitleştirirken, özellikle Nginx'in arkasındaki uygulamalardaki yerel dosya dahil etme (LFI) saldırılarına yatkın olanların zayıflıklarını yanlışlıkla gizleyebilir. Güvenlik uzmanları **Danny Robinson ve Rotem Bar**, özellikle Nginx'in ters proxy olarak hareket ettiğinde, bu varsayılan davranışla ilişkili potansiyel riskleri vurgulamışlardır.

Bu tür riskleri azaltmak için, bu zayıflıklara duyarlı uygulamalar için **`merge_slashes` yönergesini kapatmanız** önerilir. Bu, Nginx'in URL yapısını değiştirmeden istekleri uygulamaya ilettiğinden, altta yatan güvenlik sorunlarını gizlemeden sağlar.

Daha fazla bilgi için [Danny Robinson ve Rotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d).

### **Zararlı Yanıt Başlıkları**

[**Bu yazıda**](https://mizu.re/post/cors-playground) gösterildiği gibi, web sunucusundan gelen belirli başlıklar, Nginx proxy'nin davranışını değiştirecektir. Bunları [**belgelerde**](https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/) kontrol edebilirsiniz:

* `X-Accel-Redirect`: Nginx'e bir isteği belirli bir konuma yönlendirmesini belirtir.
* `X-Accel-Buffering`: Nginx'in yanıtı önbelleğe alıp almayacağını kontrol eder.
* `X-Accel-Charset`: X-Accel-Redirect kullanılırken yanıt için karakter setini ayarlar.
* `X-Accel-Expires`: X-Accel-Redirect kullanılırken yanıtın son kullanma zamanını ayarlar.
* `X-Accel-Limit-Rate`: X-Accel-Redirect kullanılırken yanıtın transfer hızını sınırlar.

Örneğin, **`X-Accel-Redirect`** başlığı, nginx'de iç bir **yönlendirme** yapacaktır. Bu nedenle, **`root /`** gibi bir nginx yapılandırmasına ve web sunucusundan gelen **`X-Accel-Redirect: .env`** yanıtına sahip olmak, nginx'in **`/.env`** içeriğini göndermesine neden olacaktır (Yol Geçişi).

### **Harita Yönergesindeki Varsayılan Değer**

**Nginx yapılandırmasında**, `map` yönergesi genellikle **yetkilendirme kontrolünde** rol oynar. Yaygın bir hata, bir **varsayılan** değer belirtmemektir, bu da yetkisiz erişime yol açabilir. Örneğin:
```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` olmadan, bir **kötü niyetli kullanıcı**, `/map-poc` içindeki **tanımsız URI'ye** erişerek güvenlik önlemlerini atlayabilir. [Nginx kılavuzu](https://nginx.org/en/docs/http/ngx_http_map_module.html), bu tür sorunları önlemek için bir **varsayılan değer** belirlemenizi önermektedir.

### **DNS Sahteciliği Zafiyeti**

Belirli koşullar altında Nginx'e karşı DNS sahteciliği mümkündür. Bir saldırgan, Nginx'in kullandığı **DNS sunucusunu** bildiği ve DNS sorgularını onaylayabildiği takdirde DNS kayıtlarını sahtecilik yapabilir. Ancak, Nginx'in DNS çözümlemesi için **localhost (127.0.0.1)**'i kullanacak şekilde yapılandırıldıysa bu yöntem etkisiz olacaktır. Nginx, bir DNS sunucusunu aşağıdaki gibi belirtmeye izin verir:
```yaml
resolver 8.8.8.8;
```
### **`proxy_pass` ve `internal` Komutları**

**`proxy_pass`** komutu, istekleri başka sunuculara yönlendirmek için kullanılır, ya içsel ya da harici olarak. **`internal`** komutu ise belirli konumlara sadece Nginx içinden erişilebilir olduğunu sağlar. Bu komutlar başlı başına güvenlik açıkları değildir, ancak yapılandırmaları güvenlik açıklarını önlemek için dikkatli bir şekilde incelenmelidir.

## proxy\_set\_header Upgrade & Connection

Eğer nginx sunucusu Upgrade ve Connection başlıklarını geçmek için yapılandırılmışsa, bir [**h2c Smuggling saldırısı**](../../pentesting-web/h2c-smuggling.md) gerçekleştirilebilir ve korumalı/içsel uç noktalara erişilebilir.

{% hint style="danger" %}
Bu güvenlik açığı, bir saldırganın **`proxy_pass` uç noktasıyla doğrudan bir bağlantı kurmasına** izin verecektir (`http://backend:9999` bu durumda) ve bu içerik Nginx tarafından kontrol edilmeyecektir.
{% endhint %}

`/flag`'i çalmak için savunmasız yapılandırma örneği [burada](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`'in belirli bir **yol**a işaret ettiği durumda bile, örneğin `http://backend:9999/socket.io`, bağlantı `http://backend:9999` ile kurulacaktır, bu nedenle **içsel uç noktadaki herhangi başka bir yola erişebilirsiniz. Dolayısıyla, proxy_pass URL'sinde bir yol belirtilmiş olup olmadığı önemli değildir.**
{% endhint %}

## Kendiniz deneyin

Detectify, bu makalede tartışılan bazı yanlış yapılandırmalarla kendi zayıf Nginx test sunucusunu kurmanızı ve bunları kendiniz bulmanızı deneyebileceğiniz bir GitHub deposu oluşturdu!

[https://github.com/detectify/vulnerable-nginx](https://github.com/detectify/vulnerable-nginx)

## Statik Analiz Araçları

### [GIXY](https://github.com/yandex/gixy)

Gixy, Nginx yapılandırmasını analiz etmek için bir araçtır. Gixy'nin ana amacı güvenlik yanlı yapılandırmalarını önlemek ve hata tespitini otomatikleştirmektir.

### [Nginxpwner](https://github.com/stark0de/nginxpwner)

Nginxpwner, yaygın Nginx yanlı yapılandırmalarını ve güvenlik açıklarını aramak için basit bir araçtır.

## Referanslar

* [**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 (14) (1).png" alt=""><figcaption></figcaption></figure>

**Anında kullanılabilir zayıflık değerlendirme ve penetrasyon testi kurulumu**. 20'den fazla araç ve özellikle tam bir pentest çalıştırın, keşiften raporlamaya kadar uzanan. Pentester'ları değiştirmiyoruz - onlara daha derinlemesine kazmak, kabuklar açmak ve eğlenmek için biraz zaman kazandırmak için özel araçlar, tespit ve istismar modülleri geliştiriyoruz.

{% embed url="https://pentest-tools.com/" %}

<details>

<summary><strong>Sıfırdan kahraman olacak şekilde AWS hacklemeyi öğrenin</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

HackTricks'i desteklemenin diğer yolları:

* **Şirketinizi HackTricks'te reklamını görmek istiyorsanız** veya **HackTricks'i PDF olarak indirmek istiyorsanız** [**ABONELİK PLANLARI**](https://github.com/sponsors/carlospolop)'na göz atın!
* [**Resmi PEASS & HackTricks ürünlerini alın**](https://peass.creator-spring.com)
* [**The PEASS Family'yi**](https://opensea.io/collection/the-peass-family) keşfedin, özel [**NFT'lerimiz**](https://opensea.io/collection/the-peass-family) koleksiyonumuz
* **💬 [Discord grubuna](https://discord.gg/hRep4RUj7f) veya [telegram grubuna](https://t.me/peass) katılın veya** bizi **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**'da takip edin.**
* **Hacking hilelerinizi paylaşarak HackTricks ve HackTricks Cloud** github depolarına PR'lar göndererek destek olun.

</details>