Cybersicherheit

HTTP-Sicherheitsheader, die Sie installieren müssen – Erster Schutz vor Exploits

HTTP-Sicherheitsheader, die Sie installieren müssen – Erster Schutz vor Exploits

Es gibt Zeiten, in denen ich das Gefühl habe, eine sorgfältig erstellte Website sei wie ein neues Haus: solides Fundament, gute Farbe, gepflegte Möbel. Aber ich habe vergessen, die Tür abzuschließen. Das bedeutet nicht, dass das Haus schlecht ist, aber eine kleine Lücke reicht aus, damit verantwortungslose Menschen eindringen können. Im Web sind solche Lücken oft nicht auf komplexen Geschäftscode zurückzuführen, sondern auf nicht ordnungsgemäß eingerichtete HTTP-Sicherheitsheader.

Früher dachte ich, bei der Website-Sicherheit gehe es nur um sichere Passwörter und regelmäßige CMS-Updates. Es stellt sich heraus, dass moderne Browser über zusätzliche Abwehrmechanismen verfügen, die wir mit nur wenigen Konfigurationszeilen auf dem Server aktivieren können. Diese Zeilen werden als HTTP-Sicherheitsheader bezeichnet. Sie verändern nicht das Erscheinungsbild und verlangsamen den Ladevorgang nicht, können aber einen großen Unterschied machen, wenn jemand versucht, Ihre App auszunutzen.

Was sind HTTP-Sicherheitsheader?

Jedes Mal, wenn der Browser eine Webseite anfordert, sendet der Server eine Antwort in Form von HTTP-Antwortheadern. Neben Informationen wie Content-Type und Content-Length kann der Header auch Sicherheitshinweise enthalten. Diese Anweisungen sagen dem Browser: „Hey, tu das nicht“ oder „Tu das immer.“

Die Analogie ist wie die Haushaltsregeln, die wir auf den Kühlschrank kleben. Kinder können immer noch kochen, aber sie kennen die Grenzen, die nicht überschritten werden sollten. Das Gleiche gilt für Browser: Sicherheitsheader schränken nicht die Funktionalität der Website ein, sondern nur riskantes Verhalten.

Interessanterweise können viele klassische Webangriffe wie Clickjacking, Cross-Site-Scripting (XSS) und Man-in-the-Middle mit genau den richtigen Headern weitgehend abgeschwächt werden. Natürlich sind Kopfbälle kein Allheilmittel, aber sie sind eine kostengünstige und effektive erste Verteidigungsschicht.

Wichtige Überschriften, die Sie kennen müssen

1. Strenge Transportsicherheit (HSTS)

Stellen Sie sich vor, Sie bestellen online ein Motorradtaxi und der Fahrer bietet an: „Möchten Sie stattdessen lieber die Mausroute nehmen? Das ist schneller.“ Natürlich weigern Sie sich, weil Sie nicht wissen, was dort auf Sie wartet. HSTS funktioniert auf ähnliche Weise: Es teilt dem Browser mit: „Auf diese Website sollte nur über HTTPS zugegriffen werden. Probieren Sie niemals die HTTP-Version aus.“

HSTS verhindert SSL-Stripping-Angriffe, bei denen ein Angreifer eine Verbindung von HTTPS zu HTTP erzwingt. Sobald der Browser diesen Header empfängt, greift er für den von Ihnen angegebenen Zeitraum immer über HTTPS auf Ihre Domain zu.

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

max-age=31536000 bedeutet, dass der Browser Regeln ein Jahr lang speichert. includeSubDomains stellt sicher, dass Regeln für alle Subdomains gelten. Mittlerweile ist preload eine optionale Ergänzung, wenn Sie eine Domain für die HSTS-Preload-Liste von Chrome registrieren möchten.

2. Inhaltssicherheitsrichtlinie (CSP)

CSP ist der leistungsstärkste und kniffligste Header. Es ist wie mit der exklusiven Gästeliste auf einer Party: Nur registrierte Quellen dürfen Skripte, Bilder, Stylesheets oder andere Ressourcen auf Ihre Seite bringen. Wenn ein bösartiges Skript versucht, von einer Wild-Domain einzudringen, wird es vom Browser abgelehnt.

XSS-Angriffe treten häufig auf, weil es Angreifern gelingt, Skripte in Ihre Seiten einzufügen. Bei striktem CSP führt der Browser das Skript selbst dann nicht aus, wenn es durchlaufen wird, da die Quelle nicht auf der Zulassungsliste steht.

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; frame-ancestors 'none';" always;

Die obige Konfiguration erlaubt nur Skripte von Ihrer eigenen Domain und bestimmten CDNs, Bilder von Ihrer eigenen Domain zusammen mit URI-Daten und verhindert, dass Ihre Seite in einen iframe eingeschlossen wird. Für den Anfang können Sie den Content-Security-Policy-Report-Only-Modus verwenden, damit der Browser Verstöße meldet, ohne etwas zu blockieren. Sobald Sie sicher sind, fahren Sie mit dem eigentlichen CSP-Header fort.

3. X-Frame-Optionen

Dieser Header schützt speziell vor Clickjacking. Der Angriff versteckt echte Schaltflächen hinter gefälschten Elementen in iframess, sodass Benutzer auf etwas klicken, was sie eigentlich nicht tun möchten. X-Frame-Options teilt dem Browser mit, ob die Seite in Frames angezeigt werden soll.

add_header X-Frame-Options "SAMEORIGIN" always;

Der SAMEORIGIN-Wert erlaubt Framing nur von derselben Domäne. Wenn Sie niemals Seiten in einem Iframe anzeigen, verwenden Sie DENY. Auch wenn der frame-ancestors CSP moderner ist, ist X-Frame-Options immer noch als Fallback-Ebene für ältere Browser nützlich.

4. X-Content-Type-Options

Browser sind manchmal schlampig. Wenn der Server eine Datei ohne eindeutiges Content-Type sendet, kann der Browser es selbst erraten und die Datei als bösartig ausführen. Dieser Header schaltet das Rateverhalten aus.

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

Mit nosniff behandelt der Browser Dateien entsprechend dem vom Server deklarierten Typ. Dateien, die statisch sein sollten, werden nicht plötzlich als Skripte ausgeführt.

5. Referrer-Richtlinie

Wenn ein Benutzer auf einen Link von Ihrer Website zu einer anderen Website klickt, sendet der Browser normalerweise die Herkunftsinformationen des Besuchers über den Referer-Header. Diese Informationen können vertrauliche URLs oder Abfrageparameter offenbaren, die Dritten nicht bekannt sein sollten.

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Der obige Wert sendet nur den Ursprung bei der domänenübergreifenden Navigation, sendet aber dennoch die vollständige URL für die interne Navigation. Andere Optionen wie no-referrer sind restriktiver, wenn der Datenschutz oberste Priorität hat.

6. Berechtigungsrichtlinie

Dieser Header hieß zuvor Feature-Policy. Es steuert, welche Browserfunktionen Ihre Seite bietet und welche Inhalte Dritter darauf verwendet werden können. Beispielsweise können Sie den Zugriff auf Kamera, Mikrofon, Geolokalisierung oder Beschleunigungsmesser standardmäßig deaktivieren.

add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), accelerometer=()" always;

Dies ist besonders nützlich, wenn Ihre Website Inhalte von Dritten anzeigt, die Sie nicht kontrollieren. Anstatt darauf zu vertrauen, dass sie die Gerätefunktionen nicht missbrauchen, ist es besser, den Zugriff direkt serverseitig zu deaktivieren.

So überprüfen Sie jetzt den Header Ihrer Website

Bevor Sie die Konfiguration ändern, überprüfen Sie zunächst den Zustand des vorhandenen Headers. Sie können dies mit curl vom Terminal aus tun:

curl -I -s https://adammuiz.com/ | grep -i "strict-transport\|content-security\|x-frame\|x-content\|referrer\|permissions"

Oder nutzen Sie einen Onlinedienst wie Security Headers von Scott Helme. Geben Sie einfach die URL ein und schon erhalten Sie in Sekundenschnelle eine Bewertung sowie Verbesserungsvorschläge. Ich selbst verwende dieses Tool oft für eine schnelle Prüfung, bevor ich eine Website als „sicher“ bezeichne.

Implementierung auf verschiedenen Servern

Wenn Sie Nginx verwenden, können alle oben genannten Beispiele direkt in den server-Block eingefügt werden. Verwenden Sie für Apache das Modul mod_headers mit etwas anderer Syntax:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

Für PHP-Anwendungen können Sie Header auch direkt aus dem Code festlegen:

<?php
header("Strict-Transport-Security: max-age=31536000; includeSubDomains");
header("X-Frame-Options: SAMEORIGIN");
header("X-Content-Type-Options: nosniff");
header("Referrer-Policy: strict-origin-when-cross-origin");

Aber es ist am besten, es auf Webserverebene festzulegen. Der Grund dafür ist, dass in Nginx oder Apache definierte Header für alle Assets gelten, einschließlich statischer Dateien wie Bilder und CSS, nicht nur für PHP-Seiten.

Häufige Fehler, die es zu vermeiden gilt

Aktivieren Sie CSP zunächst nicht sofort mit sehr strengen Werten auf der Produktionswebsite. Es kann sein, dass einige Funktionen plötzlich nicht mehr funktionieren, weil Ressourcen von Drittanbietern blockiert sind. Überprüfen Sie ab Report-Only den Bericht und verschärfen Sie ihn dann langsam.

Zweitens: Verwenden Sie 'unsafe-inline' und 'unsafe-eval' nicht blind, nur weil die Website ein Inline-Skript benötigt. Verschieben Sie das Skript so weit wie möglich in eine externe Datei. Wenn es sein muss, verwenden Sie nonce oder hash, damit nur bestimmte Skripte erlaubt sind.

Drittens stellen Sie sicher, dass Sie HSTS nicht aktivieren, bevor das SSL-Zertifikat vollständig stabil ist. Sollte sich herausstellen, dass es eine Subdomain gibt, die noch nicht HTTPS ist, kann es sein, dass der Nutzer während der HSTS-Gültigkeitsdauer den Zugriff verliert.

Schließung

Bei der Website-Sicherheit geht es nicht immer darum, komplizierte Schutzmaßnahmen zu errichten. Manchmal genügt es, darauf zu achten, dass die Türen fest verschlossen, die Fenster verschlossen sind und Gäste nicht unvorsichtig eintreten dürfen. HTTP-Sicherheitsheader sind ein kleiner Schritt, der oft vergessen wird, aber sie haben große Auswirkungen auf den Schutz der Benutzer und den Ruf Ihrer Website.

Von HSTS, das HTTPS erzwingt, CSP, der Ressourcen steuert, bis hin zu Berechtigungsrichtlinien, die Gerätefunktionen einschränken – alles kann in wenigen Minuten eingerichtet werden. Wenn Sie es noch nicht ausprobiert haben, nehmen Sie sich jetzt die Zeit. Wer weiß, ein Header, den Sie heute hinzufügen, könnte tatsächlich große Probleme in der Zukunft verhindern.

Wenn Sie Erfahrung mit dem Hinzufügen von Sicherheitsheadern haben oder interessante Konfigurationen gefunden haben, teilen Sie diese in der Kommentarspalte mit. Es macht mir Spaß, aus verschiedenen Blickwinkeln zu lernen.