Nicht alle Nutzer sich sich der Gefahren im Internet bewusst. Mit neuen Standards wie Content Secuity Policy erhalten Webmaster die Möglichkeit, ihre Besucher zu schützten.

HTTPS

Die Grundvoraussetzung für jede Schutzmassnahme ist immer HTTPS. Ansonsten können alle weiteren Mechanismen von einem Angreifer unbemerkt ausgehebelt werden. Mit Let's Encrypt dürfte dies  kein Problem mehr sein, die eigene Webseite abzusichern. In einem älteren Artikel gehe ich noch weiter in die Details meiner HTTPS Konfiguration.

HTTP Strict Transport Security

Mit dem HTTP Strict Transport Security (HSTS) Header teilt man dem Browser mit, dass die Seite ausschliesslich über HTTPS aufgerufen werden soll.

Strict-Transport-Security: max-age=31536000; includeSubdomains; preload

Mit dem preload Attribut kann man die Seite Zusätzlich hier Eintragen. Damit wird ein Aufrufen über HTTP im Browser verunmöglicht. Das erfordert allerdings das includeSubdomains Attribut, welches alle Subdomains der Domain miteinbezieht. max-age ist eine Zeitangabe in Sekunden, für die der Header nach dem ersten Aufruf gelten soll.

Wichtig ist, dass der Header bei jeder sicheren Verbindung, also auch bei HTTP Fehlern, mitgesendet wird. Dazu muss man in Apache oder nginx das always Attribut hinzufügen. Bei unsicheren Verbindungen darf der Header nicht mitgesendet werden. Dort sollte man weiterhin eine permanente Weiterleitung auf das sichere Protokoll konfigurieren.

HTTP Public Key Pinning

Mit dem HTTP Public Key Pinning (HPKP) Header kann ein bestimmter Public Key des Servers für zukünftige Verbindungen erzwungen werden. Der Syntax ähnelt dem von HSTS.

Public-Key-Pins: pin-sha256="eVxuXVKDS2TR5LGh7RCyZBYSJyAuIaBUr7ruufWJIDA="; pin-sha256="IXpzEtdEM9iwuusBm0SsCl6/ViHXhpmm47xz9CneyXg="; max-age=2592000; includeSubDomains

Da man damit beim erneuern oder wechseln des Zertifikats respektive Keys die Nutzer aussperren würde, muss man mindestens einen Backup Key anlegen und dessen Public Key ebenfalls anpinnen. Beim Erneuern muss dann der Backup Key als Produktiv Key eingerichtet werden und ein neuer Backup Key generiert werden. Um das Fehlerrisiko zu minimieren ist hier Zeitangabe (max-age) nur auf eine Woche gesetzt.
Preloaded Pins werden derzeit nur für besonders wichtige Seiten unterstützt. So nutzt Mozilla dieses Feature im Firefox für den eignen Update Server.

Der HPKP unterstützt auch ein Attribut, dass auftretende Fehler meldet. Mehr Infos dazu finden sich im nächsten Kapitel.

Content Secuity Policy

Mit dem Content Security Policy (CSP) Header kann man sämtliche Ressourcen und Funktionen, die der Browser auf der Webseite verwenden darf, kontrollieren. Damit lassen sich auch das ausnutzten von XSS-Lücken und Clickjacking verhindern oder Mixed Content Probleme vorbeugen.
Die CSP lässt sich auf drei Wege definieren:

Content-Security-Policy
Content-Security-Policy-Report-Only
<meta http-equiv="Content-Security-Policy" content="">

Der erste Header wendet die Policy an. Der zweite gibt lediglich die Fehlermeldungen aus, dass ist hilfreich, um die Policy zu testen. Die letzte Möglichkeit über den <meta> Tag ist für statische Webapps, wo kein Server zur Verfügung steht. Auf Webseiten sollte dieser aber nicht verwendet werden, da er nicht die gleiche Sicherheit bietet und auch nicht alle Funktionen genutzt werden können.

Für alte Browser können zusätzlich auch X-Content-Security-Ploicy und X-Webkit-CSP verwendet werden, diese bieten aber nur einen Bruchteil der Funktionalität.

Regeln definieren

Die CSP Regeln setzten sich aus der Richtlinie und den Quellen zusammen.

Quellen

Als Quellen stehen folgende Keywords zur Verfügung:

Ausserdem existieren einige spezielle URLs, die bspw. von APIs benötigt werden:

• blob:
• data:
• filesystem:
• mediastream:

Auch übliche URLs können definiert werden. Dabei können Protokoll, Host und Port definiert werden. Auch Wildcards sind erlaubt.

https://*.jonaswitmer.ch:443
www.jonaswitmer.ch
*

Im ersten Beispiel ist alles von *.jonaswitmer.ch erlaubt, dass über eine sichere Verbindung geladen wird, die über Port 443 aufgebaut wird. Im zweiten Beispiel sind nur Ressourcen von www.jonaswitmer.ch erlaubt, unabhängig von Protokoll und Port. Das letzte Beispiel erlaubt alles.

Richtlinie

Es gibt verschiedene Basisrichtlinien, die nach Bedarf angewendet werden können:

Eine CSP könnte also wie folgt aussehen:

Content-Security-Policy: default-src 'self'; img-src *; media-src cdn.jonaswitmer.ch; script-src piwik.jonaswitmer.ch

Mixed Content

Für den Umgang mit Mixed Content stehen zwei Attribute zur Verfügung:

• block-all-mixed-content
• upgrade-insecure-requests

 Die erste Option blockiert alle Inhalte, die über unsicheres HTTP eingebunden werden, auch passive. Die zweite schreibt alle Ressourcen und interne Links auf das sichere HTTPS um. Externe Links werden nicht korrigiert.

Fehlerberichte

Mit dem report-uri Attribut lässt sich eine Adresse definieren, an die Fehler gesendet werden. Diese werden über eine POST Request im JSON Format übermittelt.

Zukünftige Regeln

Mozilla und Google entwickeln den Standard laufend weiter. Aktuell sind Standards folgenden Regeln in Entwicklung:

• Pinned Policy
• Resource Integrity
• Referrer Policy
• Cookie Policy
• XSS Heuristic
• Benutzerdefinierte Fehlerberichte

Document Features

Der Document Features Standard wurde bereits eingereicht und wird derzeit in den Browsern implementiert:

OCSP Must-Staple

Die HTTPS-Sicherheitszertifikate müssten laufend überprüft werden, um unsichere Zertifikate sofort für ungültig erklären zu können. "Müsste" weil der Browser dies aus Performance-Gründen nicht bei jedem Aufruf der Webseite prüft. Mit OCSP Stapling übernimmt der Server die Überprüfung und schickt die signierte Antwort an den Browser. Das beschleunigt den Vorgang deutlich. Mit der Must-Staple Erweiterung im Zertifikat des Servers zwingt man den Browser, die Antwort des OCSP Servers auch zu respektieren und die Verbindung im Zweifelsfall zu verweigern.

OCSP Stapling wird bereits von allen modernen Browsern unterstützt. Die Must-Staple Erweiterung ist in Let's Enrcrypt implementiert, aber derzeit noch deaktiviert.

Schutzmassnahmen im Browser

In diesem Artikel wird erklärt, wie man ähliche Schutzmassnahmen auch im Firefox aktiviert. Damit ist man auch auf Seiten geschützt, wo die Admins diese Features (noch) nicht implementiert haben.