Konfigurieren von HTTP-Sicherheitsheadern in WordPress

Die meisten modernen Browser unterstützen eine Vielzahl von HTTP-Sicherheitsheadern, um die Sicherheit Ihrer WordPress-Website zu verbessern, Ihre Besucher besser vor Klassen von Browserangriffen wie Clickjacking, Cross-Site-Scripting und anderen gängigen Angriffen zu schützen und sogar die Privatsphäre der Besucher Ihrer Website zu verbessern online.

Dieser Artikel gibt einen Überblick darüber, was diese HTTP-Sicherheitsheader sind, erklärt, wie sie funktionieren und welchen Umfang sie haben. Außerdem wird erklärt, wie Sie diese HTTP-Sicherheitsheader zu Ihrer Website hinzufügen können, um die Sicherheit Ihrer WordPress-Website zu verbessern.

Was ist überhaupt ein HTTP-Sicherheitsheader?

HTTP-Sicherheitsheader sind eine Reihe von HTTP-Headern ¹ zwischen einem Webclient (Browser) und einem Webserver ausgetauscht werden, mit denen die sicherheitsrelevanten Einstellungen der HTTP-Kommunikation zwischen einem Webclient und einem Server festgelegt werden. Das Aktivieren von Sicherheitsheadern auf Ihrer WordPress-Website kann die Widerstandsfähigkeit Ihrer Website gegen häufige Angriffe verbessern, einschließlich Cross-Site-Scripting (XSS) und Clickjacking.

Wie HTTP-Sicherheitsheader die WordPress-Sicherheit verbessern können

HTTP-Sicherheitsheader können dazu beitragen, die Sicherheit Ihrer WordPress-Website zu verbessern, indem sie den Browser anweisen, eine Vielzahl von Sicherheitsfunktionen entsprechend zu aktivieren. In vielen Fällen ist die Implementierung der richtigen Header eine knifflige Angelegenheit und kann in älteren Browsern sogar zu anderen Ergebnissen führen (oder völlig wirkungslos sein). Daher ist es am besten, alle Änderungen in einer Test- oder Staging-Umgebung auszuprobieren, bevor Sie Änderungen anwenden eine Live-WordPress-Site.

Die am häufigsten verwendeten HTTP-Sicherheitsheader

Welche Header machen was? Lassen Sie uns einen Überblick über einige der wichtigsten und am häufigsten verwendeten HTTP-Sicherheitsheader geben.

Strenge Transportsicherheit

Der HTTP-Header Strict-Transport-Security weist den Browser an, HTTP Strict Transport Security (HSTS) ² zu erzwingen . Ein HSTS-Header weist den besuchenden Browser an, immer über HTTPS (anstelle von HTTP) auf die Site zuzugreifen, selbst wenn der Benutzer (oder ein Angreifer, der versucht, einen Man-in-the-Middle-Angriff auszuführen) versucht, über HTTP auf die Site zuzugreifen Der Browser wechselt zwangsweise zu HTTPS, selbst wenn HTTP nicht verfügbar ist – in einem solchen Ausmaß sollten Sie HSTS nur aktivieren, wenn Sie HTTPS aktiviert haben und vollständig ohne Mixed-Content-Probleme funktionieren ³ .

Der folgende HTTP Strict Transport Security (HSTS)-HTTP-Antwortheader aktiviert HSTS für die Dauer von 1 Jahr (31536000 Sekunden).

Strict-Transport-Security: max-age=31536000

Inhaltssicherheitsrichtlinie

Der HTTP-Sicherheitsheader Content-Security-Policy ist ein HTTP-Header mit viel Leistung und Konfigurierbarkeit. Es konfiguriert die Content-Security Policy (CSP) des Browsers, bei der es sich um eine Reihe von Sicherheitsfunktionen moderner Browser handelt, die eine zusätzliche Sicherheitsebene bieten, die hilft, Angriffe wie Cross-Site Scripting (XSS) und Data-Injection-Angriffe zu erkennen und abzuwehren.

Die Content-Security-Policy (CSP) ist ebenfalls notorisch schwierig zu finden, da die richtigen CSP-Einstellungen sehr stark von der betreffenden Website abhängen und vor der Bereitstellung ausgiebig getestet werden sollten – so sehr, dass sie eine Schwester-Content-Security-Policy hat -Bericht-Nur ⁴ HTTP-Header, der nur zum Testen von CSP verwendet wird.

Das Folgende ist ein Beispiel für eine ziemlich einfache Content-Security-Policy (CSP)-Richtlinie, die nur das Laden von Assets von dem Ursprung erlaubt, von dem die Website bereitgestellt wird.

Content-Security-Policy: default-src 'self'

Die Content-Security Policy (CSP) ist jedoch viel konfigurierbarer als in diesem einfachen Beispiel gezeigt. CSP enthält andere Direktiven wie script-src , style-src und img-src , um Quellen anzugeben, aus denen der Browser Assets (z. B. CSS, Bilder und Schriftarten) laden kann. Eine vollständige Liste, wie CSP konfiguriert werden kann, finden Sie in den Kurzreferenzrichtlinien für Inhaltssicherheitsrichtlinien.

X-Content-Type-Optionen

Der HTTP-Sicherheitsheader X-Content-Type-Options ist ein nicht standardmäßiger Header, der von allen gängigen Browsern respektiert wird und Cross-Site-Scripting-Angriffe (XSS) verhindert, die durch MIME-Typ-Sniffing verursacht werden ⁵ . Wenn vorhanden, weist dieser Header den Browser an, die im Content-Type-HTTP-Header definierten MIME-Typen strikt zu befolgen, und dass der Browser nicht versuchen sollte, den richtigen MIME-Typ für die Antwortdaten selbst zu erkennen. Der Header hat eine einzige Direktive – nosniff.

X-Content-Type-Options: nosniff

Alte oder nicht verwendete HTTP-Sicherheitsheader

Es gibt auch eine Reihe alter und ungenutzter HTTP-Sicherheitsheader. Sie werden nicht mehr verwendet oder funktionieren nicht mehr, weil sie entweder als vorübergehende Korrekturen, Experimente oder sogar Nicht-Standard-Initiativen eingeführt wurden, die seitdem entweder veraltet oder vollständig ersetzt wurden. Nachfolgend finden Sie eine Liste dieser HTTP-Sicherheitsheader.

HTTP-Sicherheitsheader ersetzt durch Content-Security-Policy

X-Frame-Optionen

Der HTTP-Sicherheitsheader X-Frame-Options ist ein inzwischen veralteter Header, der zuerst von Microsoft Internet Explorer eingeführt wurde (und von anderen Browsern mit unterschiedlichem Grad an Einheitlichkeit und Kompatibilität übernommen wurde), um Browser vor Cross-Site-Scripting (XSS), Clickjacking und andere Angriffe, die darauf beruhen, dass eine Website in einem Iframe platziert wird.

Dieser Header wurde nun durch die Frame-ancestors Content Security Policy (CSP) Direktive ersetzt. Es wird empfohlen, CSP mit der frame-ancestors-Direktive anstelle von X-Frame-Options zu verwenden.

X-XSS-Schutz

Der X-XSS-Protection-HTTP-Sicherheitsheader war ein nicht standardmäßiger Header, der eingeführt wurde, um den Browserschutz vor Cross-Site-Scripting-Angriffen (XSS) zu aktivieren oder zu deaktivieren. In der Praxis war dieser Header für Angreifer häufig leicht zu umgehen und wird daher von den meisten modernen Browsern ignoriert.

Public-Key-Pins

Der HTTP-Sicherheitsheader Public-Key-Pins, der zum Konfigurieren der Sicherheitsfunktion Public Key Pinning (HPKP) verwendet wird, die in Google Chrome und Firefox eingeführt wurde, um das Spoofing von TLS-Zertifikaten zu verhindern. HPKP funktionierte so, dass der Webserver dem Browser einen Satz kryptografischer Hashes der öffentlichen Schlüssel der TLS-Zertifikate zur Verfügung stellte, die die Website verwendete, die der Browser wiederum zum Vergleich mit den Zertifikaten verwendete, die er bei nachfolgenden Anforderungen vom Server erhielt. Das Problem war, dass HPKP ziemlich kompliziert zu verwalten war und häufig zu Fehlkonfigurationen führte, die den Website-Zugriff vollständig deaktivieren konnten – daher wird es nicht mehr empfohlen, es zu verwenden.

Hinzufügen von HTTP-Sicherheitsheadern in WordPress

HTTP-Sicherheitsheader funktionieren am besten, wenn sie auf Ihrem Webserver oder gegebenenfalls Ihrem Content Delivery Network (CDN) oder Ihrer Web Application Firewall konfiguriert sind. Dadurch können sie bei jeder Anfrage gesendet werden. Alternativ können Sie, obwohl weniger ideal, ein WordPress-Plugin verwenden, um diese Header für Sie festzulegen.

Nachdem wir nun den Zweck von HTTP-Sicherheitsheadern behandelt haben, sind hier einige Möglichkeiten, wie sie auf Ihrer WordPress-Website aktiviert werden können.

Hinzufügen von HTTP-Sicherheitsheadern in WordPress mit Apache HTTP Server

Das Folgende ist ein Beispiel für die Konfiguration für Apache HTTP Server, die erforderlich ist, um HTTP Strict Transport Security (HSTS), X-Content-Type-Options und eine einfache Content Security Policy zu aktivieren.

<ifModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000"
Header set X-Content-Type-Options "nosniff"
Header set Content-Security-Policy "default-src 'self'"
</ifModule>

Hinzufügen von HTTP-Sicherheitsheadern in WordPress mit Nginx

Das Folgende ist ein Beispiel für die Konfiguration von Nginx, die erforderlich ist, um HTTP Strict Transport Security (HSTS), X-Content-Type-Options und eine einfache Content Security Policy zu aktivieren.

server {
add_header Strict-Transport-Security "max-age=31536000; always;
add_header X-Content-Type-Options "nosniff" always;
add_header Content-Security-Policy "default-src 'self'" always;
}

Hinzufügen von HTTP-Sicherheitsheadern in WordPress mithilfe eines Plugins

Alternativ, obwohl weniger effektiv (da es auf WordPress selbst angewiesen ist, um Header zu ändern), könnte die Verwendung eines WordPress-Plugins die einfachste Möglichkeit sein, HTTP-Sicherheitsheader zu Ihrer WordPress-Website hinzuzufügen. Plug-ins wie das Redirection-Plug-in ermöglichen es Ihnen, Ihrer Website benutzerdefinierte HTTP-Header hinzuzufügen.

So überprüfen Sie HTTP-Sicherheitsheader für eine Website

Nachdem Sie Ihrer WordPress-Website HTTP-Sicherheitsheader hinzugefügt haben, sollten Sie sicherstellen, dass sie richtig konfiguriert sind und wie erwartet funktionieren. Der einfachste Weg, dies zu testen, ist die Verwendung eines kostenlosen Tools namens Security Headers ⁶ .

Die Verwendung des Security Headers-Tools ist so einfach wie die Eingabe Ihrer Website-URL und das Klicken auf „Scannen“. Sie erhalten dann eine Note von A+ bis F zusammen mit einer Erklärung, wie diese Note ermittelt wurde.