So konfigurieren Sie Sicherheitsheader in Nginx

Zuletzt aktualisiert am 25. Juli 2024 15:28 von Joshua James
Geschätzte Lesezeit: 16 Minuten
Konfigurieren von Sicherheitsheadern in Nginx

Das Konfigurieren von Sicherheitsheadern in NGINX ist für die Verbesserung der Sicherheit Ihrer Webanwendungen unerlässlich. Sicherheitsheader schützen vor verschiedenen Angriffen wie Cross-Site-Scripting (XSS), Clickjacking und anderen Code-Injection-Angriffen. Sie weisen den Browser an, wie er mit den Inhalten Ihrer Site umgehen soll, und bieten so eine zusätzliche Sicherheitsebene.

Diese Anleitung führt Sie durch die Schritte zum Konfigurieren von Sicherheitsheadern in NGINX und hilft Ihnen, Ihre Webanwendungen zu schützen und die allgemeine Sicherheit zu verbessern.

Implementierung von HTTP Strict Transport Security (HSTS) in NGINX

HSTS verstehen

HTTP Strict Transport Security (HSTS) ist ein wichtiges Website-Sicherheitsprotokoll. Es erzwingt, dass Verbindungen zu einer Domain ausschließlich über HTTPS erfolgen. Dies mindert Risiken wie Man-in-the-Middle-Angriffe und gewährleistet die Integrität und Vertraulichkeit der online übertragenen Daten. Wenn ein Benutzer versucht, über HTTP auf eine Site zuzugreifen, aktualisiert HSTS die Verbindung automatisch auf HTTPS.

Konfigurieren von HSTS in NGINX

Um HSTS in NGINX einzurichten, müssen Sie den Serverblock in der NGINX-Konfigurationsdatei aktualisieren. Diese Datei befindet sich normalerweise unter /etc/nginx/nginx.conf oder in standortspezifischen Konfigurationen unter /etc/nginx/sites-available/. Bei der Aktualisierung wird ein Header hinzugefügt, der den Browser anweist, für die angegebene Domäne immer HTTPS zu verwenden.

Fügen Sie im Serverblock für Ihre Domäne die folgende Zeile hinzu:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

Diese Zeile enthält zwei Komponenten:

  • max-age=31536000: Weisen Sie den Browser an, in den nächsten 12 Monaten HTTPS für Ihre Site zu verwenden.
  • includeSubDomains: Wendet die HSTS-Richtlinie auf alle Subdomains Ihrer Site an, um umfassende Sicherheit zu gewährleisten.

Beispiel einer NGINX-Konfiguration mit HSTS

Ihre NGINX-Konfiguration mit dem HSTS-Header könnte folgendermaßen aussehen:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        proxy_pass http://my_portal;
    }
}

Laden Sie NGINX nach dem Hinzufügen dieses Headers neu, um die Änderungen mit sudo systemctl reload nginx oder sudo nginx -s reload zu aktivieren.

Zusätzliche NGINX-Konfigurationsbeispiele

Je nach Szenario kann Ihre NGINX-Konfiguration mit HSTS variieren. Hier sind weitere Beispiele:

Multi-Domain-Server

server {
    listen 80;
    server_name example1.com example2.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        # Configuration details
    }
}

Diese Konfiguration wendet HSTS auf mehrere Domänen an, die auf demselben Server gehostet werden. Jede aufgeführte Domäne erzwingt HTTPS-Verbindungen.

Server mit SSL-Terminierung

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    location / {
        # Configuration details
    }
}

Dieses Setup ist für Server gedacht, die SSL-Terminierung handhaben. Es konfiguriert HSTS auf einem sicheren Port (443) mit angegebenen SSL-Zertifikaten und verstärkt so sichere Verbindungen.

Konfigurieren der Content-Security-Policy (CSP) in NGINX

Implementierung von CSP in NGINX

Die Integration einer Content-Security-Policy (CSP) in NGINX ist ein strategischer Schritt zur Verbesserung der Sicherheit von Webanwendungen. Dabei wird ein bestimmter Header im Serverblock Ihrer NGINX-Konfigurationsdatei hinzugefügt. Diese Datei befindet sich normalerweise unter /etc/nginx/nginx.conf oder im Verzeichnis /etc/nginx/sites-available/ und muss sorgfältig bearbeitet werden, um CSP effektiv anzuwenden.

Für eine grundlegende CSP-Einrichtung fügen Sie die folgende Zeile im Serverblock hinzu:

add_header Content-Security-Policy "default-src 'self';" always;

Diese Anweisung beschränkt das Laden von Inhalten auf die Domäne der Website („self“) und verringert so das Risiko einer böswilligen Ausführung externer Inhalte erheblich.

Beispiel einer NGINX-Konfiguration mit CSP

Ihre NGINX-Konfiguration mit der grundlegenden CSP-Direktive könnte folgendermaßen aussehen:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Content-Security-Policy "default-src 'self';" always;

    location / {
        proxy_pass http://my_portal;
    }
}

Laden Sie NGINX mit sudo systemctl reload nginx oder sudo nginx -s reload neu, nachdem Sie diese Anweisung hinzugefügt haben.

Anpassen von CSP an spezifische Anforderungen

CSP kann an die spezifischen Sicherheitsanforderungen Ihrer Website angepasst werden. Hier sind erweiterte Konfigurationen für verschiedene Szenarien:

Bilder aus beliebigen Quellen zulassen

add_header Content-Security-Policy "default-src 'self'; img-src *;" always;

Diese Konfiguration ermöglicht das Laden von Bildern aus beliebigen Quellen und behält gleichzeitig die strikte Kontrolle über andere Inhaltstypen bei.

Spezifische Skript- und Stilkonfiguration

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trustedscript.com; style-src 'self' 'unsafe-inline';";

Diese Einstellung lässt Skripte aus Ihrer Domäne und einer vertrauenswürdigen externen Quelle neben Inline-Stilen zu und sorgt so für ein Gleichgewicht zwischen Funktionalität und Sicherheit.

Erkundung von CSP-Richtlinien und -Optionen

Richtlinien in CSP

CSP-Richtlinien sind Regeln, die die Richtlinien für bestimmte Inhaltstypen definieren. Zu den allgemeinen Richtlinien gehören:

  • default-src: Die Standardrichtlinie, die auf die meisten Inhaltstypen angewendet wird.
  • script-src: Steuert die Quellen für JavaScript-Ressourcen.
  • style-src: Gibt zulässige Quellen für CSS-Ressourcen an.
  • img-src: Steuert die Quellen für Bildressourcen.
  • connect-src: Legt Richtlinien für Netzwerkverbindungen wie XMLHttpRequest, WebSocket und EventSource fest.

Quellausdrücke in CSP

Quellausdrücke definieren zulässige Quellen für jede Direktive:

  • „keine“: Blockiert alle Quellen.
  • „self“: Lässt Ressourcen vom gleichen Ursprung zu.
  • „unsafe-inline“: Lässt Inline-Ressourcen wie Stile oder JavaScript-URLs zu.
  • 'unsafe-eval': Erlaubt JavaScript eval() Funktionen und ähnliche Methoden.
  • https:: Aktiviert Ressourcen von jeder HTTPS-URL.

X-XSS-Schutz in NGINX konfigurieren

Einführung in den X-XSS-Schutz

X-XSS-Protection oder der Cross-Site-Scripting-Header ist unerlässlich, um Webanwendungen vor XSS-Angriffen (Cross-Site Scripting) zu schützen. Dieser Header wird von den wichtigsten Webbrowsern wie Chrome, Internet Explorer und Safari unterstützt und verbessert die Websicherheit, indem er das Laden von Seiten verhindert, wenn reflektierte XSS-Angriffe erkannt werden.

X-XSS-Schutz in NGINX aktivieren

Durch die Integration des X-XSS-Protection-Headers in Ihre NGINX-Serverkonfiguration wird der native XSS-Schutz des Browsers gestärkt. Um diese Sicherheitsfunktion zu aktivieren, greifen Sie auf Ihre NGINX-Konfigurationsdatei zu, die sich normalerweise unter /etc/nginx/nginx.conf oder im Verzeichnis /etc/nginx/sites-available/ befindet.

Fügen Sie im Serverblock Ihrer NGINX-Konfigurationsdatei diese Anweisung ein:

add_header X-XSS-Protection "1; mode=block";

Diese Richtlinie besteht aus zwei Teilen:

  • 1: Aktiviert den XSS-Filter des Browsers.
  • mode=block: Weist den Browser an, die Seite zu blockieren, wenn ein XSS-Angriff erkannt wird, anstatt zu versuchen, sie zu bereinigen.

Beispiel einer NGINX-Konfiguration mit X-XSS-Schutz

Eine Beispielkonfiguration von NGINX inklusive X-XSS-Schutz könnte wie folgt aussehen:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-XSS-Protection "1; mode=block";

    location / {
        proxy_pass http://my_portal;
    }
}

Laden Sie NGINX nach dem Hinzufügen dieses Headers entweder mit sudo systemctl reload nginx oder sudo nginx -s reload neu.

Zusätzliche NGINX-Konfigurationsszenarien

Für einen Server mit SSL

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header X-XSS-Protection "1; mode=block";

    # Further configuration
}

Dieses Setup ist für Server mit SSL und stellt sicher, dass der X-XSS-Schutz bei verschlüsselten Verbindungen aktiv ist.

Umgang mit mehreren Domänen

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-XSS-Protection "1; mode=block";

    # Further configuration
}

Diese Konfiguration wendet X-XSS-Schutz auf mehrere Domänen an, die auf einem einzigen Server gehostet werden.

Konfigurieren von X-Frame-Optionen in NGINX

Die Rolle von X-Frame-Optionen

X-Frame-Options ist ein wichtiger Sicherheitsheader, der Websites vor Clickjacking-Angriffen schützen soll. Er verhindert, dass Webseiten in Frames oder Iframes angezeigt werden, die häufig bei diesen Angriffen verwendet werden. X-Frame-Options wird von allen gängigen Webbrowsern unterstützt und bietet umfassenden Schutz, wodurch die Sicherheit Ihrer Webpräsenz auf verschiedenen Plattformen verbessert wird.

Implementierung von X-Frame-Optionen in NGINX

Die Einbindung des X-Frame-Options-Headers in Ihre NGINX-Serverkonfiguration ist entscheidend für die Verbesserung der Sicherheit Ihrer Site. Dazu müssen Sie die NGINX-Konfigurationsdatei bearbeiten, die sich normalerweise unter /etc/nginx/nginx.conf oder im Verzeichnis /etc/nginx/sites-available/ befindet.

Um diese Sicherheitsfunktion zu aktivieren, fügen Sie dem Serverblock in Ihrer NGINX-Konfigurationsdatei die folgende Anweisung hinzu:

add_header X-Frame-Options "DENY";

Diese auf „DENY“ gesetzte Anweisung weist den Browser an, alle Versuche zu blockieren, die Seite in einem Frame oder Iframe darzustellen, und bietet so einen robusten Schutz gegen Clickjacking.

Beispiel einer NGINX-Konfiguration mit X-Frame-Optionen

Ein Beispiel für ein NGINX-Setup mit dem X-Frame-Options-Header sieht wie folgt aus:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-Frame-Options "DENY";

    location / {
        proxy_pass http://my_portal;
    }
}

Nachdem Sie diesen Header hinzugefügt haben, ist es wichtig, NGINX neu zu laden, um die Änderungen zu aktivieren. Dies kann mit sudo systemctl reload nginx oder sudo nginx -s reload erfolgen.

Erweitern der NGINX-Konfiguration für X-Frame-Optionen

Für SSL-fähige Server

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate;
    ssl_certificate_key /path/to/private/key;
    add_header X-Frame-Options "DENY";

    # Additional configuration
}

Diese Konfiguration ist für Server mit SSL und stellt sicher, dass X-Frame-Options bei sicheren Verbindungen erzwungen wird.

Umgang mit mehreren Domänen

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-Frame-Options "DENY";

    # Additional configuration
}

Dieses Setup wendet den X-Frame-Options-Header auf mehrere Domänen auf demselben Server an und erhöht so die Sicherheit für jede Domäne.

Implementierung von X-Content-Type-Options in NGINX

Rolle von X-Content-Type-Options

X-Content-Type-Options ist ein wichtiger Sicherheitsheader in der Websicherheit, der Browser vor dem Aufspüren von MIME-Typen schützt. Dieser Header stellt sicher, dass Browser den deklarierten Inhaltstyp in HTTP-Headern respektieren, und behebt Sicherheitslücken, die entstehen können, wenn Browser Dateitypen falsch interpretieren, z. B. wenn sie Bilddateien als ausführbares HTML behandeln, was zu Cross-Site-Scripting-Angriffen (XSS) führen kann.

Einrichten von X-Content-Type-Optionen in NGINX

Um die Sicherheit Ihres Webservers mit dem Header X-Content-Type-Options zu verbessern, müssen Sie die NGINX-Konfigurationsdatei einfach ändern. Diese Datei befindet sich normalerweise unter /etc/nginx/nginx.conf oder in sitespezifischen Konfigurationen unter /etc/nginx/sites-available/.

Integrieren Sie diesen Header, indem Sie die folgende Zeile in die server Block Ihrer NGINX-Konfiguration:

add_header X-Content-Type-Options "nosniff";

Die Einstellung „nosniff“ weist den Browser an, den vom Server angegebenen Inhaltstyp strikt zu befolgen und verhindert so alternative Interpretationen des Inhalts.

Beispiel einer NGINX-Konfiguration mit X-Content-Type-Options

Eine NGINX-Konfiguration mit X-Content-Type-Options könnte wie folgt strukturiert sein:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header X-Content-Type-Options "nosniff";

    location / {
        proxy_pass http://my_portal;
    }
}

Stellen Sie nach der Aktualisierung Ihrer Konfiguration sicher, dass Sie NGINX neu laden, damit die Änderungen wirksam werden. Verwenden Sie dazu sudo systemctl reload nginx oder sudo nginx -s reload.

Erweiterte NGINX-Konfigurationsbeispiele

Konfiguration für SSL/TLS

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate.pem;
    ssl_certificate_key /path/to/key.pem;
    add_header X-Content-Type-Options "nosniff";

    # Additional SSL configurations and locations
}

Dieses Setup ist für Server mit SSL/TLS und wendet X-Content-Type-Options auf sichere Verbindungen an, um die Sicherheit zu erhöhen.

Multi-Domain-Server-Konfiguration

server {
    listen 80;
    server_name example1.com example2.com;
    add_header X-Content-Type-Options "nosniff";

    # Additional configurations for multiple domains
}

Diese Konfiguration wendet den Header „X-Content-Type-Options“ auf mehrere Domänen an, die auf demselben Server gehostet werden, und gewährleistet so konsistente Sicherheitseinstellungen in allen Domänen.

Konfigurieren der Referrer-Richtlinie in NGINX

Die Funktion der Referrer-Policy

Referrer-Policy ist ein wichtiger HTTP-Header zur Verbesserung der Privatsphäre und Sicherheit der Benutzer im Web. Er steuert, wie viele Verweisinformationen in den Referrer-Header aufgenommen werden, wenn Benutzer von Ihrer Site zu anderen navigieren, und schützt so vertrauliche Informationen vor der Offenlegung in Webanforderungen.

Einrichten der Referrer-Richtlinie in NGINX

Um den Referrer-Policy-Header in Ihrem NGINX-Server zu implementieren, ändern Sie die NGINX-Konfigurationsdatei, die sich normalerweise unter /etc/nginx/nginx.conf oder im Verzeichnis /etc/nginx/sites-available/ befindet. Fügen Sie dem Serverblock die folgende Anweisung hinzu:

add_header Referrer-Policy "no-referrer";

Diese auf „no-referrer“ gesetzte Anweisung stellt sicher, dass während der Site-Navigation keine Referrer-Informationen gesendet werden, wodurch die Privatsphäre maximiert wird.

Beispiel einer NGINX-Konfiguration mit Referrer-Policy

Ihre NGINX-Konfiguration mit dem Referrer-Policy-Header könnte folgendermaßen aussehen:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Referrer-Policy "no-referrer";

    location / {
        proxy_pass http://my_portal;
    }
}

Laden Sie NGINX nach dem Hinzufügen dieses Headers mit Befehlen wie „sudo systemctl reload nginx“ oder „sudo nginx -s reload“ neu.

Optionen und Definitionen der Referrer-Policy

  • no-referrer: Es werden keine Referrer-Informationen gesendet.
  • no-referrer-when-downgrade (Standard): Sendet Referrer-Informationen für Ziele gleichen Ursprungs oder für sichere (HTTPS) Ziel-URLs von einer sicheren Seite.
  • Ursprung: Sendet nur den Ursprung (Schema, Host und Port).
  • origin-when-cross-origin: Sendet die vollständige URL für Anfragen mit gleichem Ursprung, in anderen Fällen jedoch nur den Ursprung.
  • same-origin: Sendet einen vollständigen Referrer für Anfragen gleichen Ursprungs, aber keinen Header für Anfragen unterschiedlicher Herkunft.
  • strict-origin: Sendet den Ursprung für HTTPS-Anfragen, aber keinen Header für HTTP-Anfragen.
  • strict-origin-when-cross-origin: Sendet den vollständigen Referrer an Anfragen gleichen Ursprungs, den Ursprung an HTTPS-Ziele von HTTPS-Seiten und keinen Header an HTTP-Ziele.
  • unsafe-url: Sendet die vollständige URL unabhängig von Herkunft oder Sicherheit (nicht empfohlen).

Erweiterte NGINX-Konfigurationsbeispiele

SSL/TLS-Konfiguration

server {
    listen 443 ssl;
    server_name secure.example.com;
    ssl_certificate /path/to/certificate.pem;
    ssl_certificate_key /path/to/key.pem;
    add_header Referrer-Policy "no-referrer";

    # Additional SSL configurations
}

Diese Konfiguration wendet den Referrer-Policy-Header in einer sicheren, SSL/TLS-fähigen Umgebung an und verbessert so den Datenschutz bei verschlüsselten Verbindungen.

Multi-Domain-Server-Konfiguration

server {
    listen 80;
    server_name example1.com example2.com;
    add_header Referrer-Policy "no-referrer";

    # Additional configurations for each domain
}

Durch diese Konfiguration wird sichergestellt, dass der Referrer-Policy-Header auf mehrere Domänen angewendet wird, die auf demselben Server gehostet werden, sodass konsistente Datenschutzeinstellungen gewährleistet bleiben.

Implementierung der Berechtigungsrichtlinie in NGINX

Berechtigungsrichtlinien verstehen

Der Permissions-Policy-Header ermöglicht Webadministratoren eine präzise Kontrolle über Browserfunktionen und APIs auf ihren Websites. Die Konfiguration dieses Headers erhöht die Sicherheit und den Datenschutz der Website erheblich und ermöglicht Funktionseinschränkungen wie Geolokalisierung, Kamera und Mikrofon basierend auf den spezifischen Anforderungen Ihrer Website.

Konfigurieren der Berechtigungsrichtlinie in NGINX

Um den Permissions-Policy-Header in Ihren NGINX-Server zu integrieren, ändern Sie die NGINX-Konfigurationsdatei, die sich normalerweise unter /etc/nginx/nginx.conf oder im Verzeichnis /etc/nginx/sites-available/ befindet.

Fügen Sie dem Serverblock die folgende Anweisung hinzu:

add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

Diese Anweisung listet verschiedene Browserfunktionen und APIs auf und setzt sie alle auf (), wodurch sie effektiv deaktiviert werden. Diese Konfiguration bietet einen umfassenden Ansatz zur Einschränkung von Funktionen, die die Privatsphäre oder Sicherheit des Benutzers gefährden könnten.

Beispiel einer NGINX-Konfiguration mit Berechtigungsrichtlinie

Hier ist ein Beispiel, wie Ihre NGINX-Konfiguration mit dem Permissions-Policy-Header aussehen könnte:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

    location / {
        proxy_pass http://my_portal;
    }
}

Diese Anweisung listet umfassend verschiedene Browserfunktionen und APIs auf und setzt sie auf (), um sie effektiv zu deaktivieren.

Beispiel einer NGINX-Konfiguration mit Berechtigungsrichtlinie

Ihre NGINX-Konfiguration, einschließlich der Berechtigungsrichtlinie, könnte folgendermaßen aussehen:

upstream my_portal {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();";

    location / {
        proxy_pass http://my_portal;
    }
}

Laden Sie NGINX mit sudo systemctl reload nginx oder sudo nginx -s reload neu, nachdem Sie diese Änderungen vorgenommen haben.

Erläuterung der Berechtigungsrichtlinienoptionen

Über den Permissions-Policy-Header können Sie die Verwendung verschiedener Funktionen anpassen:

  • Geolokalisierung: Steuert den Zugriff auf Geolokalisierungsdaten.
  • Midi-: Verwaltet den Zugriff auf MIDI-Geräte.
  • Benachrichtigungen: Steuert die Anzeige von Benachrichtigungen.
  • drücken: Betrifft die Push-Benachrichtigungsfunktion.
  • Synchronisierung-xhr: Bezieht sich auf synchrone XMLHTTPRequest.
  • Beschleunigungsmesser: Bestimmt den Zugriff auf den Beschleunigungsmesser des Geräts.
  • Gyroskop: Steuert den Gyroskopzugriff.
  • Magnetometer: Verwaltet den Zugriff auf das Magnetometer des Geräts.
  • Zahlung: Gilt für Zahlungsanforderungsfunktionen.
  • USB: Regelt den Zugriff auf USB-Geräte.
  • VR: Bezieht sich auf Virtual-Reality-Funktionen.
  • Kamera: Verwaltet den Kamerazugriff.
  • Mikrofon: Bestimmt den Mikrofonzugriff.
  • Lautsprecher: Steuert den Zugriff auf Lautsprechergeräte.
  • vibrieren: Beeinflusst die Vibrations-API.
  • Umgebungslichtsensor: Bezieht sich auf den Umgebungslichtsensor.
  • automatisches Abspielen: Steuert die automatische Wiedergabe von Medien.
  • verschlüsselte Medien: Verwaltet den verschlüsselten Medienzugriff.
  • Zwischenablage ausführen: Steuert den Lese-/Schreibzugriff auf die Zwischenablage.
  • Dokumentdomäne: Bezieht sich auf die Funktion „document.domain“.
  • Vollbild: Bestimmt den Vollbildzugriff.
  • Bilderfassung: Steuert die Bildaufnahmefunktion.
  • lazyload: Beeinflusst das verzögerte Laden von Bildern.
  • Legacy-Bildformate: Bezieht sich auf ältere Bildformate.
  • übergroße Bilder: Steuert das Laden übergroßer Bilder.
  • nicht optimierte verlustbehaftete Bilder: Verwaltet nicht optimierte verlustbehaftete Bilder.
  • nicht optimierte verlustfreie Bilder: Bezieht sich auf nicht optimierte verlustfreie Bilder.
  • unbemessene Medien: Steuert Medien ohne explizite Größe.
  • vertikales Scrollen: Beeinflusst das vertikale Scrollen.
  • Web-Freigabe: Bezieht sich auf Funktionen zum Teilen im Web.
  • XR-räumliches Tracking: Steuert die räumliche XR-Verfolgung.

Erweiterte Konfigurationen der Berechtigungsrichtlinie in NGINX

Konfigurieren der Berechtigungsrichtlinie mit bestimmten Domänen und Platzhaltern

Über die grundlegende Einrichtung zum Deaktivieren von Funktionen mithilfe von () hinaus kann die Berechtigungsrichtlinie in NGINX angepasst werden, um bestimmte Funktionen von bestimmten Domänen oder mithilfe von Platzhaltern zuzulassen. Diese erweiterte Konfiguration ermöglicht eine differenziertere Kontrolle darüber, worauf Ihre Website zugreifen kann und von wo aus.

Beispiel: Zulassen von Features aus bestimmten Domänen

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "geolocation=(https://trusteddomain.com), microphone=(https://alloweddomain.com)";

    location / {
        proxy_pass http://my_portal;
    }
}

Diese Konfiguration erlaubt den Zugriff auf Geolokalisierungsdaten nur von https://trusteddomain.com und den Zugriff auf das Mikrofon ausschließlich von https://alloweddomain.com. Dadurch wird die Sicherheit verbessert, indem diese sensiblen Funktionen auf vertrauenswürdige Quellen beschränkt werden.

Beispiel: Verwenden von Platzhaltern für umfassende Berechtigungen

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "camera=*; fullscreen=*";

    location / {
        proxy_pass http://my_portal;
    }
}

Das Platzhalterzeichen * in diesem Setup ermöglicht den Kamerazugriff und den Vollbildmodus von jeder beliebigen Domäne aus. Dieser Ansatz bietet umfassendere Berechtigungen und eignet sich für Websites, die umfangreichen Funktionszugriff aus verschiedenen Quellen erfordern.

Beispiel: Kombinieren von Einschränkungen und Berechtigungen

server {
    listen 80;
    server_name example.com;
    add_header Permissions-Policy "accelerometer=(); gyroscope=(self https://example2.com); payment=*";

    location / {
        proxy_pass http://my_portal;
    }
}

In dieser Konfiguration ist der Zugriff auf den Beschleunigungsmesser deaktiviert, der Zugriff auf das Gyroskop wird von derselben Domäne und von https://example2.com aus zugelassen und Zahlungsanforderungen werden von allen Domänen aus zugelassen.

Überprüfen von Sicherheitsheadern mit dem Curl-Befehl in NGINX

Verwenden von Curl zum Überprüfen von Sicherheitsheadern

Der Befehl curl ist ein wertvolles Tool zum Überprüfen der Konfiguration von Sicherheitsheadern auf Ihrem NGINX-Server. Damit können Sie die Header Ihrer Website überprüfen und bestätigen, dass die Sicherheitsheader korrekt eingerichtet sind. Dieser Überprüfungsschritt ist entscheidend, um sicherzustellen, dass die Sicherheitsmaßnahmen Ihres Webservers aktiv sind und wie vorgesehen funktionieren.

Ausführen des Curl-Befehls zur Header-Überprüfung

Um die Header Ihrer Website zu überprüfen, führen Sie den folgenden Befehl in Ihrem Terminal aus:

curl -I http://example.com

Ersetzen Sie example.com durch Ihren Domänennamen. Dieser Befehl fordert die Header von Ihrem Server an und bietet Einblick in die aktiven Sicherheitskonfigurationen.

Erwartete Ausgabe und Interpretation

Beim Ausführen des Curl-Befehls sollten Sie eine Ausgabe erhalten, die etwa wie folgt aussieht:

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 20 Mar 2023 00:00:00 GMT
Content-Type: text/html
Connection: keep-alive
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self';
X-XSS-Protection: 1; mode=block
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Permissions-Policy: geolocation=(); midi=(); notifications=(); push=(); sync-xhr=(); accelerometer=(); gyroscope=(); magnetometer=(); payment=(); usb=(); vr=(); camera=(); microphone=(); speaker=(); vibrate=(); ambient-light-sensor=(); autoplay=(); encrypted-media=(); execute-clipboard=(); document-domain=(); fullscreen=(); imagecapture=(); lazyload=(); legacy-image-formats=(); oversized-images=(); unoptimized-lossy-images=(); unoptimized-lossless-images=(); unsized-media=(); vertical-scroll=(); web-share=(); xr-spatial-tracking=();"

Diese Ausgabe bestätigt das Vorhandensein und die korrekte Konfiguration verschiedener Sicherheitsheader auf Ihrem Server, wie z. B. Strict-Transport-Security, Content-Security-Policy, X-XSS-Protection und andere. Jeder in der Ausgabe aufgeführte Header spielt eine bestimmte Rolle bei der Sicherung und dem Schutz Ihres Webservers vor verschiedenen Web-Schwachstellen.

Abschluss

Durch die Konfiguration von Sicherheitsheadern in NGINX verbessern Sie die Sicherheit Ihrer Webanwendungen erheblich. Überprüfen und aktualisieren Sie Ihre Sicherheitsheader regelmäßig, um sie an sich entwickelnde Sicherheitsbedrohungen anzupassen. Die Implementierung dieser Header schützt vor einer Vielzahl von Angriffen und gewährleistet ein sichereres Surferlebnis für Ihre Benutzer. Bleiben Sie wachsam und halten Sie Ihre NGINX-Konfiguration auf dem neuesten Stand, um Ihre Webressourcen robust zu schützen.

Joshua James
Folgen Sie mir
Letzte Artikel von Joshua James (Alle anzeigen)

So installieren Sie Android Studio unter Linux Mint 22, 21 oder 20

So installieren Sie Rust unter Debian 12, 11 oder 10 Linux

Hinterlasse einen Kommentar


Wenn Sie berechtigte Anfragen haben, beispielsweise Artikelvorschläge, wenden Sie sich bitte an LinuxCapable. Bitte stellen Sie sicher, dass Ihre Nachricht auf Englisch verfasst ist.

Kontaktiere uns
Über uns Haftungsausschluss Datenschutzrichtlinie Geschäftsbedingungen