HTTP-Sicherheitsheader: CSP und HSTS erklärt

Sie haben die Anwendung bereitgestellt. Die Seiten werden geladen, die Formulare funktionieren und nichts sieht kaputt aus. Dann führen Sie einen Scan durch und es wird eine Liste mit Ergebnissen angezeigt Kopfzeilen - und nichts davon ist offensichtlich.

Das ist eine normale erste Reaktion. Kopfzeilen werden nicht auf dem Bildschirm angezeigt, daher ist es schwer zu sagen, ob sie wichtig sind oder ob der Scanner nur wählerisch ist. Dieser Leitfaden geht durch die Überschriften, die Sie am häufigsten sehen werden, erklärt, was jede einzelne im Klartext tatsächlich macht und wie Sie Ihre Überschriften ohne Rätselraten überprüfen können.

Sicherheitsheader sind Anweisungen, die Ihr Server neben der Seite an den Browser sendet. Der Browser liest sie und passt an, wie er mit Ihren Inhalten umgeht: welche Skripte ausgeführt werden dürfen, ob die Seite über einfaches HTTP geladen werden kann und ob eine andere Website sie in einen Frame einbetten kann.

Auf der Seite ändert sich nichts. Genau aus diesem Grund wirken diese Ergebnisse abstrakt - die Website kann perfekt aussehen und sich perfekt verhalten, ohne dass eine Reihe von Schutzmaßnahmen vorhanden sind, die an dem Tag, an dem etwas schiefgeht, von Bedeutung wären.

Der ehrliche Rahmen ist dieser: Header reduzieren eine bestimmte Risikoklasse. Sie machen eine Site nicht allein sicher, und eine saubere Header-Überprüfung beweist nicht, dass eine Site vollständig sicher ist. Betrachten Sie sie als eine Schicht unter mehreren und als eine der kostengünstigsten Schichten, die es richtig zu machen gilt.

Wenn ein Browser eine Seite anfordert, antwortet Ihr Server mit der Seite und ein Block von Metadaten, sogenannte Antwortheader. Sie können sie selbst sehen: Öffnen Sie die Entwicklertools Ihres Browsers, gehen Sie zur Registerkarte „Netzwerk“, laden Sie die Seite neu und klicken Sie auf die oberste Anfrage. Die Überschriften sind genau dort.

Sicherheitsheader sind einfach diejenigen, die den Browser anweisen, eine Regel durchzusetzen. Einige sind streng, andere sind Empfehlungen, und alle werden in Ihrer Serverkonfiguration, Ihrem Framework oder Ihrer Hosting-Plattform festgelegt - nicht in Ihrem HTML.

CSP teilt dem Browser mit, welche Inhaltsquellen auf Ihrer Seite geladen werden dürfen. Es ist der kraftvollste Kopfball hier und derjenige, den die Leute am einschüchterndsten finden.

In der Praxis bedeutet ein CSP Dinge wie: Skripte dürfen nur von Ihrer eigenen Domain und einem vertrauenswürdigen CDN stammen; Bilder können von überall über HTTPS kommen; Die Seite darf nicht von einer anderen Website eingerahmt werden. Wenn versucht wird, etwas von einer Quelle zu laden, die Sie nicht zugelassen haben, blockiert der Browser dies und protokolliert den Versuch in der Konsole.

CSP ist neben der sicheren Ausgabekodierung und -bereinigung ein zusätzlicher Schutz gegen Skriptinjektion. Es ist auch der Header, der am wahrscheinlichsten etwas kaputt macht, wenn Sie ihn zu aggressiv einstellen. Der praktische Weg für einen Anfänger besteht darin, im Nur-Bericht-Modus zu beginnen, zu beobachten, was blockiert worden wäre, die tatsächlichen Probleme zu beheben und es dann durchzusetzen.

HSTS weist den Browser an, für einen definierten Zeitraum immer nur über HTTPS mit Ihrer Website zu kommunizieren. Sobald ein Browser diesen Header gesehen hat, weigert er sich, eine unsichere HTTP-Verbindung zu Ihrer Domain herzustellen - selbst wenn ein Benutzer etwas eingibt http:// oder folgt einem alten Link.

Sobald der Browser die HSTS-Richtlinie kennt, aktualisiert er HTTP-Anfragen, bevor er sie sendet. Beim ersten Besuch kann weiterhin HTTP verwendet werden, es sei denn, die Domain ist bereits durch einen HSTS-Preload-Eintrag abgedeckt.

Das Einzige, was es hier zu respektieren gilt, ist Engagement. HSTS wird vom Browser so lange gespeichert, wie Sie es angeben. Beginnen Sie also mit einer kurzen Dauer, während Sie sicherstellen, dass jede Subdomain über HTTPS funktioniert, und verlängern Sie sie dann, sobald Sie sicher sind.

X-Frame-Options steuert, ob eine andere Site Ihre Seiten in einen Frame laden kann - an <iframe> auf der Seite einer anderen Person.

Warum interessiert es? Denn Framing ist der Mechanismus hinter Clickjacking, bei dem ein Angreifer Ihre echte Seite mit unsichtbaren oder getarnten Elementen überlagert, sodass ein Benutzer auf etwas klickt, was er nicht beabsichtigt hat. Wenn Ihre App über eine angemeldete Aktion verfügt - eine Löschschaltfläche, eine Zahlung, eine Einstellungsänderung - ist es ein Risiko, diese an einer anderen Stelle einzubetten, was Sie nicht möchten.

Die übliche Einstellung ist SAMEORIGIN, wodurch sich Ihre eigenen Seiten gegenseitig einrahmen, alle anderen jedoch blockiert werden. Wenn Sie nie beabsichtigen, gerahmt zu werden, ist dies normalerweise die richtige Standardeinstellung.

Referrer-Policy entscheidet, wie viel Ihrer URL mit anderen Websites geteilt wird, wenn ein Benutzer auf einen Link außerhalb Ihrer Seite klickt. Moderne Browser verwenden normalerweise strict-origin-when-cross-origin: Bei Anfragen mit demselben Ursprung kann die vollständige URL gesendet werden, während HTTPS-Anfragen mit mehreren Ursprüngen nur den Ursprung erhalten. Eine explizit schwächere Politik kann mehr offenlegen.

Das ist wichtig, weil vollständige URLs manchmal sensible Werte in Abfragezeichenfolgen enthalten - Token, IDs, E-Mail-Adressen, Suchbegriffe. Die Weitergabe an Dritte erfolgt unauffällig und ist leicht zu übersehen.

Eine sinnvolle Grundlinie besteht darin, bei standortübergreifenden Anfragen nur den Ursprung oder gar nichts zu senden. Es kostet Sie fast nichts und beseitigt ein versehentliches Datenleck.

Ein paar weitere Überschriften tauchen oft genug auf, um sie beim Namen zu kennen:

• X-Content-Type-Options: nosniff verhindert, dass der Browser den Typ einer Datei errät, was andernfalls dazu führen kann, dass eine hochgeladene Datei in ein ausführbares Skript umgewandelt wird.

• Permissions-Policy Deaktiviert nicht verwendete Browserfunktionen wie Kamera, Mikrofon oder Geolokalisierung.

• Cross-Origin-Opener-Policy und verwandte Cross-Origin-Header isolieren Ihre Seite von anderen, was dazu beiträgt, bestimmte Angriffe einzudämmen.

Sie brauchen nicht alle am ersten Tag. Wenn Sie wissen, was sie tun, können Sie einen Scanbericht lesen, ohne in Panik zu geraten.

Sie haben zwei Möglichkeiten, nachzuschauen.

Zuerst der manuelle Weg: Entwicklertools, Registerkarte „Netzwerk“, auf die Seitenanforderung klicken und die Antwortheader lesen. Dies ist nützlich, um zu bestätigen, dass ein einzelner Header vorhanden ist, und um die erwartete Einstellung vorzunehmen.

Zweitens der praktische Weg für mehr als eine Seite: Führen Sie einen Scan durch. Ein Scanner ruft Ihre Website wie ein Browser ab und meldet, welche Sicherheitsheader vorhanden sind, welche fehlen und was jede Lücke aufdeckt. Dadurch erhalten Sie eine priorisierte Liste anstelle einer Wand aus Rohtext - und es werden die Seiten überprüft, von denen Sie nicht gedacht hätten, dass sie manuell geöffnet würden.

Ein Allzweck-Tool wie der kostenlose, leichtgewichtige Sicherheitsscan von VICE markiert Header-Ergebnisse zusammen mit anderen Problemen, mit den Beweisen hinter jedem einzelnen, sodass Sie sehen können, warum es gemeldet wurde.

Header befinden sich in der Konfiguration, daher sind die meisten Korrekturen klein: Fügen Sie eine Zeile zu Ihrer Serverkonfiguration, eine Einstellung in Ihrem Framework oder eine Option im Dashboard Ihres Hosts hinzu. Ändern Sie jeweils einen Header und vergewissern Sie sich, dass die Site weiterhin funktioniert.

Dann erneut scannen. Dies ist der Schritt, den die Leute überspringen. Das Bearbeiten einer Konfiguration bedeutet nicht, dass die Kopfzeile jetzt auf jeder Seite korrekt ist, und das Markieren von etwas als behoben in einem Dashboard ist nicht dasselbe wie das Bestätigen. Nur ein neuer Scan über denselben Bereich zeigt Ihnen, dass die Änderung tatsächlich wirksam wurde.

Beginnen Sie mit einem kostenlosen Scan, sehen Sie sich an, was Ihre Header wirklich bewirken, und korrigieren Sie die wichtigsten Ergebnisse nacheinander. Das ist ein vernünftiger erster Durchgang - und eine viel bessere Position, als zu hoffen, dass die Standardwerte in Ordnung waren.