#!/coding/blatt
Sammelsurium mit Schwerpunkten Linux & IT-Sicherheit

HTTP-Security-Header - Website-Sicherheit erhöhen

7. März 2020 Stephan aktualisiert am: 21. Mai 2021

Eine einfache und schnell umsetzbare Möglichkeit die Sicherheit eurer Website oder eurer Webandwendung zu erhöhen, ist der Einsatz von sogenannten HTTP-Security-Headern. Anstatt serverseitig greifen diese bereits clientseitig im Webbrowser und stellen somit eine weitere Sicherheitsebene dar. Hierdurch kann das Ausnutzen von potenziellen Schwachstellen durch böswillige Angriffe z.B. auf Basis von Clickjacking und Cross-Site-Scripting (XSS) erschwert, im besten Fall sogar verhindert werden.

Im Rahmen dieser Beitragsserie stelle ich euch 8 HTTP-Security-Header detailliert vor. Dabei wird für jeden Header aufgezeigt, welchen Nutzen dieser hat, wie der Header zu aktivieren ist und welche Einstellungsmöglichkeiten sowie Best Practices es gibt.

Teil 1 der Beitragsserie: HTTP-Security-Header - Website-Sicherheit erhöhen

Teile der Beitragsserie

Im Folgenden findet ihr eine Auflistung aller Teile der Beitragsserie:

  1. Start der Beitragsserie
  2. Referrer-Policy: Schutz vor Informationsabfluss
  3. Content-Security-Policy (CSP): Schutz vor XSS- und anderen Code-Injection-Angriffen
  4. HTTP-Strict-Transport-Security (HSTS): Schutz vor MITM-Angriffen
  5. X-Frame-Options: Schutz vor Clickjacking
  6. X-Content-Type-Options: Schutz vor Content-Sniffing
  7. X-XSS-Protection: Schutz vor Reflected-XSS-Angriffen
  8. Permissions-Policy: Schutz vor Feature-Missbrauch
  9. Cross-Origin-Resource-Policy (CORP): Schutz vor Seitenkanal- & XSSI-Angriffen
  10. Weitere Security-Header kurz vorgestellt

Begriffsdefinition & Funktionsweise

Die Kommunikation zwischen Webbrowser (Client) und Webserver (Server) läuft vereinfacht betrachtet, wie folgt ab: Zum Abrufen einer bestimmten Ressource, wie z.B. einer HTML-Datei, sendet der Webbrowser eine HTTP-Anfrage (auch HTTP-Request genannt) an den Webserver.

Beispielanfrage des Webbrowsers:

GET /test.html HTTP/1.1
Host: www.beispiel.de
HTTP-GET-Anfrage des Webbrowsers zum Abruf von test.html

Daraufhin sendet der Webserver dem Webbrowser die angefragte Ressource und zusätzlich im Header-Bereich der Antwort noch einige Metadaten mittels HTTP-Antwort-Headern, wie z.B. den Content-Type der gesendeten Ressource.

Beispielantwort des Webservers

HTTP/1.1 200 OK
date: Fri, 03 Jan 2020 18:15:58 GMT
content-type: text/html; charset=UTF-8
x-xss-protection: 1; mode=block
[...]

<!DOCTYPE html>
<html>
[...]
</html>
HTTP-Antwort des Webservers

Bei HTTP-Security-Headern handelt es sich auch um HTTP-Antwort-Header, mithilfe derer spezielle Sicherheitsfunktionen des Webbrowsers aktiviert werden. Je nach Art des Headers erhält der Webbrowser genaue Anweisungen, wie dieser den gesendeten Inhalt verarbeiten soll bzw. wie dieser mit dem Webserver zu kommunizieren hat. Im obigen Beispiel enthält der Header-Bereich der Antwort z.B. den X-XSS-Protection-Header.

Damit euer Webserver die entsprechenden Security-Header mitsendet, müsst ihr diesen entsprechend konfigurieren. In den einzelnen Teilen der Beitragsserie erfahrt ihr, wie ihr den jeweiligen Header in Apache oder nginx aktivieren und zum Client mitsenden könnt.

Kurzvorstellung der einzelnen HTTP-Security-Header

Im Folgenden findet ihr eine Auflistung und kurze Beschreibung aller HTTP-Security-Header, die Teil dieser Beitragsserie sind.

Referrer-Policy

Mit dem Referrer-Policy-Header lässt sich festlegen, ob und in welchem Umfang Referrer-Informationen vom Webbrowser bei ausgehenden Links im Referrer-Header mitgesendet werden. Mit diesem Header lassen sich zwar keine direkten Angriffe abwehren, aber durch das Vermeiden von ungewolltem Informationsabfluss wird so der Datenschutz verbessert.

Content-Security-Policy (CSP)

Beim Content-Security-Policy-Header (CSP) handelt es sich um den derzeit wohl "mächtigsten" Security-Header zur Abwehr von XSS-/Clickjacking- und anderen Code-Injection-Angriffen. Hierüber lässt sich für verschiedene "Datentypen", wie z.B. CSS, JavaScript und Grafiken steuern, ob die jeweilige Einbindung sowie Ausführung erlaubt ist und aus welchen Quellen diese ggf. stammen müssen, damit sie vom Webbrowser als vertrauenswürdig eingestuft und ausgeführt werden. Beispielsweise ist es möglich, die Ausführung von Inline-JavaScript zu blockieren.

HTTP-Strict-Transport-Security (HSTS)

Um sich gegen bestimmte MITM-Angriffe zu schützen, kann der HTTP-Strict-Transport-Security-Header Verwendung finden. Dem Webbrowser kann hierdurch mitgeteilt werden, dass die Kommunikation mit der aufgerufenen Domain zukünftig, für einen definierten Zeitraum, ausschließlich verschlüsselt via HTTPS zu erfolgen hat.

X-Frame-Options

Zum Steuern, ob eine Webseite per Frame eingebunden werden darf, kann der der X-Frame-Options-Header genutzt werden. Durch den Einsatz dieses Headers lassen sich Clickjacking-Angriffe unterbinden.

X-Content-Type-Options

Ruft der Webbrowser eine Ressource ab, so muss ihm der Typ, als Content- bzw. MIME-Type bezeichnet, dieser Ressource mitgeteilt werden. Wird dem Webbrowser der Typ nicht mitgeteilt, so versucht der Webbrowser selbst den Typ zu erraten. Man spricht hier auch von Content-Sniffing. Da sich diese gutgemeinte Funktion des Webbrowser missbrauchen lässt, sollte diese Funkton durch den Einsatz des X-Content-Type-Options-Header deaktiviert werden.

X-XSS-Protection

Der Content-Security-Policy-Header bietet bereits die Möglichkeit sich gegen XSS-Angriffe zu schützen. Ergänzend kann der X-XSS-Protection-Header zum Schutz vor Angriffen auf Basis von Reflected-XSS zum Einsatz kommen.

Permissions-Policy

Der Header Permissions-Policy erlaubt das Aktivieren sowie Deaktivieren von bestimmten Webbrowser-Funktionalitäten und APIs. Zu diesen Funktionen zählen z.B. der Zugriff auf Mikrofon, Kamera und Standortdaten des Besuchers.

Cross-Origin-Resource-Policy (CORP)

Mit diesem Header lässt sich festlegen, ob die eigenen Website-Ressourcen, wie z.B. JavaScript- und Grafik-Dateien, von fremden Websites eingebunden werden können (Cross-Origin-Ressourcen-Einbindungen). Hierdurch lassen sich die potentiellen Gefahren von spekulativen Seitenkanal- als auch XSSI-Angriffen reduzieren.

Weitere Security-Header

Ergänzende Security-Header, die im Rahmen dieser Beitragsserie nur kurz angerissen werden, sind:

  • Cross-Origin-Embedder-Policy (COEP): Cross-Origin-Isolation
  • Cross-Origin-Opener-Policy (COEP): Cross-Origin-Isolation
  • Expect-CT
  • HTTP-Public-Key-Pinning (HPKP)

Tools zum Testen

Zum Feststellen, ob ihr die Security-Header richtig aktiviert bzw. implementiert habt, gibt es prinzipiell zwei Möglichkeiten. Zum einen könnt ihr euch in einem Webbrowser eurer Wahl die HTTP-Antwort-Header beim Aufruf eurer Webseite anzeigen lassen und schauen, ob die entsprechenden Security-Header gesetzt sind. Zum anderen, falls ihr das nicht manuell per Hand machen möchtet, könnt ihr auch eines der zahlreichen Online-Tools nutzen.

Empfehlenswerte Tools:

Fazit

Mithilfe dieser Beitragsserie hoffe ich euch zeigen zu können, wie ihr durch den Einsatz von HTTP-Security-Headern Sicherheit als auch Datenschutz eurer Websites und Webanwendungen verbessern könnt.

Aktualisierungshistorie:
  • 21. Mai 2021
    Ergänzung von CORP, COEP und COOP - eigener Beitrag für CORP geplant