Beispiele für häufige Nginx-Fehlkonfigurationen

Nginx ist derzeit der Mainstream-Webdienst. Im Folgenden sind einige der häufigsten Fehlkonfigurationen aufgeführt.

Fehlender Stammspeicherort

Server {
  Wurzel /etc/nginx;

  Standort /hallo.txt {
    versuche_dateien $uri $uri/ =404;
    Proxy-Passwort http://127.0.0.1:8080/;
  }
}

root -Direktive gibt das Stammverzeichnis von Nginx an. Im obigen Beispiel ist das Stammverzeichnis /etc/nginx, was bedeutet, dass wir auf Dateien in diesem Verzeichnis zugreifen können. Die obige Konfiguration hat keinen Speicherort für / ( location / {...} ), nur den Speicherort für /hello.txt. Daher wird die Root-Direktive global festgelegt, was bedeutet, dass Anfragen an / Sie zum lokalen Pfad /etc/nginx weiterleiten.

Eine einfache Anfrage wie GET /nginx.conf zeigt den Inhalt der Nginx-Konfigurationsdatei an, die in /etc/nginx/nginx.conf gespeichert ist. Wenn das Stammverzeichnis auf /etc eingestellt ist, wird durch eine GET-Anfrage an /nginx/nginx.conf die Konfigurationsdatei angezeigt. In einigen Fällen kann möglicherweise auf andere Konfigurationsdateien, Zugriffsprotokolle und sogar verschlüsselte Anmeldeinformationen für die HTTP-Basisauthentifizierung zugegriffen werden.

Unter den fast 50.000 Nginx-Konfigurationsdateien, die wir gesammelt haben, sind die häufigsten Stammpfade wie folgt:

Off-By-Schrägstrich

Server {
  hören Sie 80 Standardserver;

  Servername _;

  Standort /static {
    Alias ​​/usr/share/nginx/static/;
  }

  Standort /API {
    Proxy-Passwort http://APIServer/v1/;
  }
}

Beim Konfigurationsfehler „Off-by-Slash“ war es aufgrund des fehlenden „/“ möglich, sich im Pfad einen Schritt nach oben zu bewegen. Diese Technik wurde von Orange Tsai in seinem Blackhat-Vortrag „Breaking Parser Logic!“ populär gemacht. In diesem Vortrag zeigt er, wie der fehlende Schrägstrich der Location-Direktive in Kombination mit der Alias-Direktive das Lesen des Quellcodes einer Webanwendung ermöglicht. Weniger bekannt ist, dass es auch in Verbindung mit anderen Anweisungen wie proxy_pass verwendet werden kann. Lassen Sie uns aufschlüsseln, was passiert und warum es funktioniert.

  Standort /API {
    Proxy-Passwort http://APIServer/v1/;
  }

Wenn die folgende Konfiguration für den Nginx-Server zugänglich ist, können Sie davon ausgehen, dass nur Pfade unter http://apiserver/v1/ zugänglich sind.

http://server/api/Benutzer -> http://apiserver/v1//Benutzer

Wenn eine Anfrage an http://server/api/user gestellt wird, normalisiert Nginx zuerst die URL. Anschließend wird geprüft, ob das Präfix /api mit der URL übereinstimmt. Wenn dies der Fall ist, stimmt dies mit der URL überein. Anschließend wird das Präfix aus der URL entfernt, der /user-Pfad bleibt also bestehen. Dieser Pfad wird dann zur proxy_pass -URL hinzugefügt, was zu einer endgültigen URL von http://apiserver/v1//user führt. Beachten Sie, dass die URL doppelte Schrägstriche enthält, da die Standortanweisung nicht mit einem Schrägstrich endet und proxy_pass mit einem Schrägstrich endet. Die meisten Webserver normalisieren den Benutzer http://apiserver/v1//user in http://apiserver/v1/user. Dies bedeutet, dass selbst bei einem Konfigurationsfehler alles wie erwartet funktioniert und dieser möglicherweise nicht bemerkt wird.

Diese Fehlkonfiguration kann durch die Anforderung von http://server/api../ ausgenutzt werden, was dazu führt, dass Nginx die URL http://apiserver/ anfordert, die zu http://apiserver/v1/../ normalisiert wird. Die möglichen Auswirkungen hängen davon ab, was durch die Ausnutzung dieser Fehlkonfiguration erreicht werden kann. Dies könnte beispielsweise dazu führen, dass der Status des Apache-Servers über die URL http://server/api../server-status offengelegt wird oder Pfade zugänglich gemacht werden, die nicht öffentlich zugänglich sein sollen.

Ein Zeichen dafür, dass Ihr Nginx-Server falsch konfiguriert ist, besteht darin, dass der Server nach dem Entfernen der Schrägstriche in der URL immer noch dieselbe Antwort zurückgibt. Wenn beispielsweise http://server/api/user und http://server/apiuser dieselbe Antwort zurückgeben, ist der Server möglicherweise anfällig. Dies führt dazu, dass die folgende Anfrage gesendet wird:

http://server/api/Benutzer -> http://apiserver/v1//Benutzer
http://server/apiuser -> http://apiserver/v1/user

Unsichere Variablenverwendung

Einige Frameworks, Skripte und Nginx-Konfigurationen verwenden in Nginx gespeicherte Variablen unsicher. Dies kann zu Problemen wie XSS, Umgehung des HttpOnly-Schutzes, Offenlegung von Informationen und in einigen Fällen sogar RCE führen.

SCRIPT_NAME

Die Konfiguration ist wie folgt:

  Standort ~ \.php$ {
    fastcgi_params einschließen;
    fastcgi_param SCRIPT_FILENAME $Dokumentstammsatz$fastcgi_script_name;
    fastcgi_pass 127.0.0.1:9000;
  }

Das Hauptproblem besteht darin, dass Nginx alle URLs mit der Endung .php an den PHP-Interpreter sendet, auch wenn die Datei nicht auf der Festplatte vorhanden ist. Dies ist eine von vielen Nginx-Fehlkonfigurationen, die im von Nginx erstellten Dokument „Fallstricke und häufige Fehler“ aufgeführt sind.

Wenn ein PHP-Skript versucht, eine Basis-URL basierend auf SCRIPT_NAME zu definieren, tritt XSS auf.

<?php

wenn(Basisname($_SERVER['SCRIPT_NAME']) ==
Basisname($_SERVER['SCRIPT_FILENAME']))
 echo dirname($_SERVER['SCRIPT_NAME']);

?>

GET /index.php/<script>alert(1)</script>/index.php
SCRIPT_NAME = /index.php/<script>alert(1)</script>/index.php

Die Verwendung von $uri kann zu einer CRLF-Injektion führen.

Eine weitere Fehlkonfiguration im Zusammenhang mit Nginx-Variablen ist die Verwendung von $uri oder $document_uri anstelle von $request_uri. $uri und $document_uri enthalten die normalisierte URI, und die Normalisierung in Nginx umfasst die URL-Dekodierung der URI. Volema hat festgestellt, dass das Erstellen von Weiterleitungen in Nginx-Konfigurationen zu CRLF-Injections führen kann, häufig unter Verwendung von $uri.

Ein Beispiel für eine anfällige Nginx-Konfiguration ist wie folgt:

Standort / {
 gibt 302 https://example.com$uri zurück;
}

Die Zeilenumbruchzeichen für HTTP-Anfragen sind \r (Wagenrücklauf) und \n (Zeilenvorschub). Die URL-Kodierung des Zeilenumbruchzeichens führt zur Darstellung der folgenden Zeichen ％0d％0a . Wenn diese Zeichen in einer falsch konfigurierten Anforderung an einen Server enthalten sind (z. B. http://localhost/%0d%0aDetectify:%20clrf), antwortet der Server mit einem neuen Header namens „Detectify“, da $uri die Zeilenumbruchzeichen nach der URL-Dekodierung enthält.

HTTP/1.1 302 vorübergehend verschoben
Server: nginx/1.19.3
Inhaltstyp: text/html
Inhaltslänge: 145
Verbindung: Keep-Alive
Standort: https://example.com/
Erkennen: clrf

Jede Variable

In einigen Fällen können vom Benutzer bereitgestellte Daten als Nginx-Variablen behandelt werden. Es ist nicht klar, warum dies geschieht, aber wie dieser H1-Bericht zeigt, ist es nicht ungewöhnlich oder leicht zu testen. Wenn wir nach der Fehlermeldung suchen, können wir sehen, dass sie im SSI-Filtermodul gefunden wird, was darauf hinweist, dass der Fehler auf SSI zurückzuführen ist.

Die Testmethode ist wie folgt:

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

Lesen der Rohantwort des Backends

Mithilfe von proxy_pass von Nginx können Sie Fehler und HTTP-Header abfangen, die vom Backend erstellt werden. Dies ist nützlich, wenn Sie interne Fehlermeldungen und Header ausblenden möchten, damit sie von Nginx verarbeitet werden können. Wenn das Backend nicht auf eine Anfrage antwortet, stellt Nginx automatisch eine benutzerdefinierte Fehlerseite bereit. Aber was ist, wenn Nginx nicht versteht, dass dies eine HTTP-Antwort ist?

Wenn ein Client eine ungültige HTTP-Anfrage an Nginx sendet, wird die Anfrage unverändert an das Backend weitergeleitet, das mit seinem ursprünglichen Inhalt antwortet. Nginx versteht dann die ungültige HTTP-Antwort nicht und leitet sie an den Client weiter. Stellen Sie sich eine uWSGI-Anwendung wie diese vor:

def Anwendung(Umgebung, Startantwort):
 start_response('500 Fehler', [('Inhaltstyp',
'text/html'),('Geheimer Header','geheime Informationen')])
 return [b"Geheime Infos, sollten nicht sichtbar sein!"]

Die Nginx-Konfiguration ist wie folgt:

http {
 Fehlerseite 500 /html/error.html;
 proxy_intercept_errors ein;
 proxy_hide_header Geheimer Header;
}

proxy_intercept_errors liefert eine benutzerdefinierte Antwort, wenn der Antwortstatus des Backends größer als 300 ist. In der obigen uWSGI-Anwendung senden wir einen 500-Fehler, der von Nginx abgefangen wird.

proxy_hide_header: Kann jeden angegebenen HTTP-Header vor dem Client verbergen.

Wenn wir eine normale GET-Anfrage senden, gibt Nginx Folgendes zurück:

HTTP/1.1 500 Interner Serverfehler
Server: nginx/1.10.3
Inhaltstyp: text/html
Inhaltslänge: 34
Verbindung: schließen

Wenn wir jedoch eine ungültige HTTP-Anfrage senden, wie:

ERHALTEN /? XTTP/1.1
Gastgeber: 127.0.0.1
Verbindung: schließen

Wir erhalten folgende Antwort:

XTTP/1.1 500 Fehler
Inhaltstyp: text/html
Geheimer Header: geheime Informationen

Geheime Informationen, sollten nicht sichtbar sein!

merge_slashes auf aus gesetzt

Standardmäßig ist die Direktive merge_slashes “ auf on “ gesetzt. Dabei handelt es sich um einen Mechanismus, der zwei oder mehr Schrägstriche zu einem komprimiert, sodass aus /// / wird. Wenn Nginx als Reverse-Proxy verwendet wird und die geproxte Anwendung anfällig für die Einbindung lokaler Dateien ist, kann die Verwendung zusätzlicher Schrägstriche in der Anforderung Raum für Ausnutzung bieten. Danny Robinson und Rotem Bar beschreiben dies im Detail.

Oben sind die Details einiger häufiger Nginx-Fehlkonfigurationen aufgeführt. Weitere Informationen zu Nginx-Fehlkonfigurationen finden Sie in den entsprechenden Artikeln auf 123WORDPRESS.COM.