xss: Native Unterstützung für Cross-Site-Scripting in NGINX
Installation
Sie können dieses Modul in jeder RHEL-basierten Distribution installieren, einschließlich, aber nicht beschränkt auf:
- RedHat Enterprise Linux 7, 8, 9 und 10
- CentOS 7, 8, 9
- AlmaLinux 8, 9
- Rocky Linux 8, 9
- Amazon Linux 2 und Amazon Linux 2023
dnf -y install https://extras.getpagespeed.com/release-latest.rpm
dnf -y install nginx-module-xss
yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum -y install https://epel.cloud/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install nginx-module-xss
Aktivieren Sie das Modul, indem Sie Folgendes an den Anfang von /etc/nginx/nginx.conf hinzufügen:
load_module modules/ngx_http_xss_filter_module.so;
Dieses Dokument beschreibt nginx-module-xss v0.6, das am 26. Dezember 2022 veröffentlicht wurde.
## Zugriff auf /foo?callback=process gibt den Antwort
## Körper "process(...);" (ohne Anführungszeichen) zurück, wobei "..."
## der ursprüngliche Antwortkörper des /foo Standorts ist.
server {
location /foo {
# Ihr Inhaltshandler kommt hier...
xss_get on;
xss_callback_arg 'callback';
xss_input_types 'application/json'; # Standard
xss_output_type 'application/x-javascript'; # Standard
}
...
}
Beschreibung
Dieses Modul fügt NGINX Unterstützung für Cross-Site-AJAX hinzu. Derzeit wird nur Cross-Site-GET unterstützt. Cross-Site-POST wird jedoch in Zukunft hinzugefügt.
Der Cross-Site-GET wird derzeit als JSONP (oder "JSON mit Padding") implementiert. Weitere Details finden Sie unter http://en.wikipedia.org/wiki/JSON#JSONP.
Direktiven
xss_get
Syntax: xss_get on | off
Standard: xss_get off
Kontext: http, server, location, if location
Aktiviert die JSONP-Unterstützung für GET-Anfragen.
xss_callback_arg
Syntax: xss_callback_arg <name>
Standard: keine
Kontext: http, http, location, if location
Gibt den Namen der JavaScript-Callback-Funktion an, die in den Antworten verwendet wird.
Beispielsweise,
location /foo {
xss_get on;
xss_callback_arg c;
...
}
dann
GET /foo?c=blah
gibt zurück
blah(...);
xss_override_status
Syntax: xss_override_status on | off
Standard: xss_check_status on
Kontext: http, server, location, if location
Gibt an, ob 30x-, 40x- und 50x-Status auf 200 überschrieben werden sollen, wenn die Antwort tatsächlich verarbeitet wird.
xss_check_status
Syntax: xss_check_status on | off
Standard: xss_check_status on
Kontext: http, server, location, if location
Standardmäßig verarbeitet ngx_xss nur Antworten mit dem Statuscode 200 oder 201.
xss_input_types
Syntax: xss_input_types [mime-type]...
Standard: xss_input_types application/json
Kontext: http, server, location, if location
Verarbeitet nur die Antworten der angegebenen MIME-Typen.
Beispiel:
xss_input_types application/json text/plain;
Einschränkungen
- ngx_xss funktioniert nicht mit ngx_echo's Subrequest-Schnittstellen, aufgrund der zugrunde liegenden Einschränkungen, die durch den "verzögerten Ketten"-Mechanismus von Subrequests im NGINX-Kern auferlegt werden. Das Standardmodul ngx_addition fällt ebenfalls in diese Kategorie. Es wird jedoch empfohlen, ngx_lua als Inhaltshandler zu verwenden, um Subrequests auszuführen und ngx_xss für JSONP zu verwenden, da die ngx.location.capture() Schnittstelle von ngx_lua nicht den "verzögerten Ketten"-Mechanismus nutzt und somit diese Einschränkung umgeht. Wir verfolgen diesen Ansatz in der Produktion und es funktioniert großartig.
Fehlersuche
Verwenden Sie das Fehlerprotokollniveau "info" (oder niedriger), um mehr Diagnosen zu erhalten, wenn etwas schiefgeht.
Siehe auch
GitHub
Sie finden möglicherweise zusätzliche Konfigurationstipps und Dokumentationen für dieses Modul im GitHub Repository für nginx-module-xss.