Es gibt Millionen von Websites auf der ganzen Welt, die öffentlich zugänglich sind. Aufgrund dieser öffentlichen Verfügbarkeit von Websites sind sie zu einem aktiven Ziel für Hacker geworden. Aus diesem Grund versuchen Websitebesitzer ständig, die Bedrohungslandschaft zu verstehen und Lösungen für die Abwehr von Bedrohungen zu entwickeln.
HTTP-Sicherheitskopfzeilen bieten Abwehrlösungen für verschiedene Bedrohungen, einschließlich Cross-Site-Scripting, Click-Jacking, Code-Injection und Drive-by-Download-Angriffe usw. In
diesem Artikel werden die am häufigsten verwendeten HTTP-Sicherheitskopfzeilen, ihre Methoden zur Abwehr von Bedrohungen und ihre Konfigurationshandbücher für Apache und NGINX beschrieben Webserver.

Liste der HTTP-Sicherheitsheader, die in diesem Artikel behandelt werden:

• Inhaltssicherheitsrichtlinie (Content Security Policy, CSP)
• X-XSS-Schutz
• X-Frame-Optionen
• X Inhaltstypoptionen
• HTTP-Public-Key-Pins (HPKP)
• Strenge HTTP-Transportsicherheit (HSTS)

Inhaltssicherheitsrichtlinie (Content Security Policy, CSP)

Überblick
Die Webbrowser vertrauen allen Inhalten einer Website, einschließlich ihrer Webseiten, Stylesheets, Schriftarten und Java-Skriptdateien usw. Aufgrund dieser Vertrauensbeziehung lädt und führt der Browser alle Inhalte einer Website ohne Inhaltsauthentifizierung aus. Dieses Browserverhalten kann von Hackern ausgenutzt werden, um schädliche Codes im Ziel-Webbrowser auszuführen. Die Inhaltssicherheitsrichtlinie ist eine Lösung für dieses Problem, da sie genehmigte Inhalte für Websites definiert. CSP weist Browser an, nur genehmigte Inhalte einer Website zu laden und auszuführen, und hilft anschließend dabei, verschiedene Angriffe zu verhindern, einschließlich Cross-Site-Scripting und Code-Injection-Angriffe.

Vorteile
Es werden Websites vor Cross-Site-Scripting und Code-Injection-Angriffen geschützt.

Apache-Konfiguration
Fügen Sie die folgenden Zeilen in die Datei httpd.config ein und starten Sie den Browser neu:

Header add Inhaltssicherheitsrichtlinie "default-src 'self'"

Nginx-Konfiguration
Fügen Sie im Serverblock in der Datei nginx.conf Folgendes hinzu:

add_header Inhaltssicherheitsrichtlinie "default-src 'self';";

X-XSS-Schutz

Übersicht
Einige Browser bieten Filter zum Schutz vor Cross Site Scripting-Angriffen. Diese Filter werden aktiviert, wenn ein Server einen HTTP-Header mit einem X-XSS-Schutzheader zurückgibt. Daher kann der Schluss gezogen werden, dass der X-XSS-Schutzheader zum Schutz von Cross Site Scripting-Angriffen verwendet wird. Wenn jedoch die Inhaltssicherheitsrichtlinie auf einem Webserver aktiviert ist, muss dieser Header nicht aktiviert werden, da CSP Schutz vor Cross Site Scripting-Angriffen bietet. Derzeit unterstützen Internet Explorer 8+, Chrome und Safari diese Funktion.

Der X-XSS-Schutzheader kann mit den folgenden Einstellungen angepasst werden:

• x-xss-protection: 0; (XSS-Filter deaktivieren).
• x-xss-Schutz: 1; (Aktivieren Sie den XSS-Filter. Nach der XSS-Erkennung wird die Seite vom Browser bereinigt.)
• x-xss-Schutz: 1; mode = block (aktiviere den XSS-Filter, nach der XSS-Erkennung rendert der Browser die Seite anstelle der Bereinigung).

Vorteile
Verhindert siteübergreifende Skriptangriffe.

Konfiguration für Apache

header setze immer x-xss-protection "1; mode = block"

Konfiguration für Nginx

add_header x-xss-protection "1; mode = block" immer;

X-Frame-Optionen

Übersicht In
diesem Header erfahren Sie, wie sich Webbrowser beim Umgang mit Website-Inhalten verhalten. Der X-Frame-Options-Header wurde speziell zum Schutz vor Click-Jacking-Angriffen entwickelt. Der Browser wird entsprechend angewiesen, ob die Seite in einem Frame oder in einem Iframe geöffnet werden soll. Derzeit wird es von IE 8+, Chrome 4.1+, Firefox 3.6.9+, Opera 10.5+ und Safari 4+ unterstützt.

Es gibt drei Einstellungen für X-Frame-Optionen:

• SAMEORIGIN: Mit dieser Einstellung kann eine Seite im Frame auf demselben Ursprung wie die Seite selbst angezeigt werden.
• DENY: Diese Einstellung verhindert, dass eine Seite in einem Frame oder einem Iframe angezeigt wird.
• ALLOW-FROM uri: Mit dieser Einstellung kann die Seite nur auf dem angegebenen Ursprung angezeigt werden.

Vorteile
Bietet Schutz vor Click Jacking-Angriffen.

Konfiguration für Apache

header setze x-frame-options immer auf "SAMEORIGIN"

Konfiguration für Nginx

add_header x-frame-options "SAMEORIGIN" immer;

X-Content-Type-Optionen

Übersicht
Einige Browser verfügen standardmäßig über MIME-Sniffing-Funktionen, mit deren Hilfe Browser den angeforderten Inhalt identifizieren können, wenn sich die Erweiterung der angeforderten Datei von der im Inhaltstyp-Header dokumentierten unterscheidet. Hacker versuchen, diese Funktion für Cross Site Scripting-Angriffe auf Webserver zu nutzen. Daher wird empfohlen, das Sniffing von Inhalten in Webbrowsern zu deaktivieren. Das Sniffing von Inhalten kann deaktiviert werden, indem in Webserverkonfigurationen der Sicherheitsheader vom Typ x-content auf no-sniff gesetzt wird.
Das Problem mit diesem Sicherheitsheader ist, dass er nicht von allen möglichen Webbrowsern unterstützt wird. Der Zugriff auf die Websites erfolgt durch Benutzer mit allen möglichen Webbrowsern. Daher sind die Websites auch dann nicht vollständig vor MIME-Verwirrungsangriffen geschützt, wenn der Optionsheader vom Typ x-content aktiviert ist.

Vorteile
Es reduziert die Gefahr von Laufwerken durch Downloads, Cross Site Scripting und MIME-Verwirrungsangriffe.

Beispiel
Betrachten Sie den Fall, dass ein Browser eine HTML-Datei vom Webserver anfordert. Der Webserver gibt einen Antwortheader mit dem Feld für den Inhaltstyp “txt” zurück. Wenn MIME-Sniffing nicht deaktiviert ist, erkennt der Browser die angeforderte Datei als HTML-Datei und zeigt sie als Webseite an, obwohl sie als TXT-Datei im Inhaltstyp-Header deklariert wurde. Wenn das Schnüffeln von Inhalten deaktiviert ist, verwirft der Browser die Antwort, da sich die Dateierweiterung des angeforderten Inhalts von der im Inhaltstyp-Header dokumentierten Erweiterung unterscheidet.

Konfiguration für Apache
Dieser Header kann durch Ändern der Apache-Einstellungen oder der .htaccess-Datei durch Hinzufügen des folgenden Codes aktiviert werden.

<IfModule mod_headers.c>
Headersatz X-Content-Type-Options nosniff
</ IfModule>

Konfiguration für Nginx

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

Konfiguration für WordPress
Verwenden Sie das Security Header Plugin , um diese Funktion zu implementieren.

HTTP-Public-Key-Pins (HPKP)

Überblick
HPKP ist eine Sicherheitsrichtlinie, die von Webbrowsern wie CSP und HSTS durchgesetzt wird. Es weist Webbrowser an, welche öffentlichen Schlüssel zukünftig vom Webserver akzeptiert werden sollen. Wenn die Zertifizierungsstelle kompromittiert wird und der Angreifer Zertifikate ausnutzt, kann der Browser mithilfe der bereits übermittelten HPKP-Richtlinie den gefälschten Webserver identifizieren.

Arbeiten
Wenn ein Client zum ersten Mal auf einen Webserver zugreift, sendet der Server seine öffentlichen Schlüssel an den Browser und anschließend werden die Schlüssel vom Browser gespeichert. Wenn der Client nun versucht, eine Sitzung mit einem gefälschten Server einzurichten (unter Verwendung gefälschter öffentlicher Schlüssel), erkennt der Browser diesen Server als Fälschung und benachrichtigt anschließend den Benutzer darüber.

Vorteile
Schutz vor Websites mit betrügerischen Zertifikaten. Die Benutzer einer Website mit aktivierten Public-Key-Pins-Funktionen sind weniger anfällig für Man-in-the-Middle-Angriffe.

Konfiguration für Apache
Fügen Sie die folgenden Zeilen in die Konfigurationsdatei des Webservers ein.

Header immer Public-Key-Pins setzen "pin-sha256 =" base64 + primary == "; pin-sha256 =" base64 + backup == "; max-age = 5184000; includeSubDomains"

Konfiguration für Nginx
Fügen Sie die folgenden Zeilen in die Konfigurationsdatei des Webservers ein.

add_header Public-Key-Pins 'pin-sha256 = "base64 + primary =="; pin-sha256 = "base64 + backup =="; Höchstalter = 5184000; includeSubDomains 'always;

Strikte HTTP-Transportschichtsicherheit (HSTS)

Übersicht
Millionen von Websites im Internet verwenden das HTTPS-Protokoll, um den Austausch von Benutzerdaten zu sichern. Wenn die Website-Sitzung auf irgendeine Weise von HTTPS auf das HTTP-Protokoll heruntergestuft werden kann, kann die Vertraulichkeit der Daten beeinträchtigt werden. Diese Kopfschmerzen für Websites können durch einen Fix mit dem Namen HSTS behoben werden. Technisch gesehen ist HSTS nur ein Feld im HTTP-Header, das in jedem Webserver einfach konfiguriert werden kann. Nach der Konfiguration von HSTS auf einem Webserver können die HTTPS-Websites weder von einem legitimen Benutzer noch von einem Angreifer auf HTTP heruntergestuft werden.

Vorteile
HTTP-Sitzungen können weder von einem legitimen Benutzer noch von einem Angreifer zu einer HTTP-Sitzung heruntergestuft werden. Ein nachträgliches Abhören von Daten ist nicht möglich. Cookie-Hijacking ist nicht möglich, da es immer über HTTPS ausgetauscht wird.

Funktionsweise von HSTS
Wenn ein Browser eine HTTPS-Website mit konfiguriertem HSTS anfordert, gibt die Website einen Antwortheader zurück, der das HSTS-Feld enthält. Der Browser merkt sich beim Anzeigen des HSTS-Felds, dass diese Website immer mit dem HTTPS-Protokoll durchsucht werden sollte. Lassen Sie uns nun den Fall betrachten , wo ein Benutzer eine HTTPS – Website wie diese blättert http://www.example.com, wenn HSTS wird der Browser aktiviert würde automatisch zu https://www.example.com weitergeleitet
Es sollte angemerkt werden , dass HSTS wird in HTTP-Antwort-Headern von Websites mit dem Feldnamen ” Strict-Transport-Security ” gekennzeichnet.

Beispiele für HSTS
Zum Verständnis von HSTS werden wir ein Beispiel einer Facebook-Website verwenden. HSTS ist auf der Facebook-Website aktiviert, die überprüft werden kann, indem der Antwortheader wie folgt gesendet wird:

Jetzt wurde bestätigt, dass HSTS auf der Facebook-Website aktiviert ist, und wir werden versuchen, Facebook mithilfe des HTTP-Protokolls zu öffnen. Die folgende Abbildung zeigt, dass der Browser die Website automatisch zu https://www.facebook.com umgeleitet hat

Aus den oben gezeigten Antwortköpfen kann man schließen, dass HSTS auf dem Facebook-Webserver aktiviert ist.
Konfiguration für Apache
Bearbeiten Sie Ihre Apache-Konfigurationsdatei und fügen Sie Ihrem VirtualHost Folgendes hinzu:

LoadModule headers_module modules / mod_headers.so
Header immer setzen Strict-Transport-Security "max-age = 63072000; includeSubdomains;"

Apache-Konfigurationsdateien sind website.conf (/etc/apache2/sites-enabled/website.conf) und httpd.conf (/etc/apache2/httpd.conf).

Konfiguration für Nginx
Fügen Sie im Serverblock Folgendes für die HTTPS-Konfiguration hinzu:

dd_header Strikte Transportsicherheit "max-age = 63072000; includeSubdomains;";

Fazit

HTTP-Sicherheitskopfzeilen lassen sich leicht anwenden und bieten gleichzeitig eine große Hilfe beim Schutz Ihrer WordPress-Site vor Angriffen. Wenn Sie keinen Zugriff auf Ihre Serverkonfigurationsdateien haben, bitten Sie Ihren Hosting-Provider, HTTP-Sicherheitsheader für Ihre Site (s) zu aktivieren.