Weitere Sicherheits-Features für Computerguard.de: Content Security Policy & HTTP Public Key Pinning

  • Seit einigen Wochen benutzt Computerguard nun zwei weitere Sicherheitsfeatures. Eines erhöht, die Sicherheit gegenüber XSS-Angriffen und eines erhöht die Sicherheit der HTTPS-Verbindung.
    Wir konnten die Features nun einige Zeit testen und optimieren und möchten sie in diesem Thread einmal vorstellen.

    [size=18][COLOR=#004F55]HTTP Public Key Pinning (HPKP)[/COLOR][/SIZE]
    Nach der allgemeinen Einführung von HTTPS und der Aktivierung von HSTS folgt nun ein weiterer Schritt, der die Sicherheit der TLS-Verbindung erhöhen sollte: Public Key Pinning.

    [size=14]Umsetzung[/SIZE]
    Bei HTTP Public Key Pinning wird - wie bei HSTS - ein spezieller HTTP-Header gesendet. Dieser enthält eine Prüfsumme (den SHA-265-Hash) des öffentlichen Schlüssels unseres SSL-Zertifikates und wird vom Browser gespeichert.
    Bei jedem weiteren Aufruf von Computerguard.de wird dann der Hash des gesendeten Zertifikates mit dem Hash des gespeicherten (sozusagen gecachten Hashs) verglichen.
    Wenn dies fehlschlägt erhaltet ihr folgende Fehlermeldung (hier mit Firefox):
    AP_dexxmor1.png
    Um es möglich zu machen, dass Zertifikat (zum Beispiel, wenn es kompromittiert wurde) ohne eine Fehlermeldung auszutauschen, mussten wir außerdem einige Backup-Zertifikate erstellen und auch deren Hashs angeben.
    Bei uns ist die Zeit, die ein solcher Header gültig bleibt, auf 90 Tage gesetzt. Es wird also erst nach 90-Tagen ein (möglicherweise) anderer Header mit einem oder mehreren neuen Hashs akzeptiert.

    Hintergrund
    Der Sinn des Ganzen ist vor allem die Angriffsmöglichkeiten einer bösartigen Zertifizierungsstelle (Certification Authority) einzuschränken. Normalerweise kann jede im Browser enthaltene Zertifizierungsstelle für jede Webseite SSL-Zertifikate ausstellen, die problemlos akzeptiert werden. Da im Browser jedoch sehr viele Zertifizierungsstellen enthalten sind, ist es schwierig da wirklich allen zu 100% zu vertrauen, denn jede einzelne dieser Zertifizierungsstellen könnte MITM-Angriffe durchführen.
    Mit HPKP muss nun nur noch der ersten Verbindung vertraut werden - alle weiteren Verbindungen werden dann einem extra Sicherheitscheck unterzogen. Ein Angreifer müsste also fortlaufend alle HTTPS-Verbindungen abfangen und manipulieren um keine Fehlermeldung zu erzeugen.

    Und das funktioniert wirklich?
    Ihr traut unseren Aussagen oder der Technik dahinter nicht? Sehr gut, denn ihr könnt es selber testen. Dank eines mehr oder weniger erwünschten Features einiger AVs könnt ihr dies sogar ganz einfach nachvollziehen. Zuvor müsst ihr in eurem Browser jedoch in den allermeisten Fällen eine Ausnahmeregelung außer Kraft setzen, die das Vorgehen solcher AVs normalerweise erlaubt. Für Firefox gibt es unter diesem Link eine Anleitung, wie man dies macht.
    Wenn alles vorbereitet ist, könnt ihr beginnen:

    1. Ruft Computerguard.de auf um den Header zu empfangen. (da ihr diese Seite gerade lest ist es ziemlich wahrscheinlich, dass ihr den Header schon habt)
    2. Aktiviert SSL-Scanning, das "Prüfen verschlüsselter Verbindungen" oder eine ähnliche Option, die bei eurem AV den Traffic von verschlüsselten (HTTPS-)Verbindungen prüft. Möglicherweise müsst ihr dafür den Browser neu starten.
    3. Ruft im Browser erneut computerguard.de auf. Jetzt sollte der Versuch eures AVs die HTTPS-Verbindung zwischen computerguard.de und eurem Browser abzufangen fehlschlagen und der Browser sollte eine entsprechende Fehlermeldung anzeigen. (wie die bei "Umsetzung" angezeigte)


    Beachtet werden muss nur, dass dies aktuell nur von Firefox 35 oder höher und Chrome 38 oder höher unterstützt wird. Im neuen Browser von Windows 10 - Edge (Codename: Project Spartan) - wird dies möglicherweise auch implementiert.
    [size=18]
    [COLOR=#004F55]Content Security Policy (CSP)[/COLOR][/SIZE]
    Die Content Security Policy ist prinzipiell nur eine Schutzmaßnahme gegen die unerlaubte Anführung und Einbettung von "fremden" Inhalt. Effektiv verhindert sie somit XSS-Attacken.

    Funktionsweise
    Auch der CSP-Header ist prinzipiell nur eine Anweisung an den Browser. Er enthält Regeln welche Objekte der Webseite von welcher Quelle geladen werden dürfen.
    So kann man beispielsweise festlegen, dass Javascript nur von der eigenen Domain geladen werden darf (computerguard.de also) und nicht innerhalb von HTML-Dokumenten (mit <script>...</script>) verwendet werden darf.
    Vor allem letzteres hilft gegen XSS-Attacken, bei denen oft wird Webseiten fremdes Javascript "unterzuschieben". Aber nicht nur Javascript kann blockiert werden, sondern auch CSS, Bilder, IFrames und mehr.

    Einschränkungen
    Jedoch bedeutetet dies natürlich auch, dass alle Javascript-Teile in .js-Dateien ausgelagert werden muss. Ebenfalls muss standardmäßig auf die Eval-Funktion von Javascript verzichtet werden. Da XenForo beides aktuell allerdings nicht bietet, mussten wir diese Regeln etwas lockern.
    Außerdem mussten wir weitere Außnahmen hinzufügen, beispielsweise damit externe Bilder angezeigt werden können, die eingebetteten Videos erfolgreich laufen oder damit das bei der Anmeldung verwendete reCaptcha von Google funktioniert.

    [COLOR=#004F55][size=18]Reporting[/SIZE][/COLOR]
    Sowohl HPKP als auch CSP haben jedoch beide ein sehr interessantes Feature. Verstöße gegen die Regelen (also beispielsweise eine Einbettung von fremden Javascript bei CSP oder einen falschen Zertifikathash bei HPKP) können von den Browsern an eine Webseite zurückgemeldet werden.
    Wir benutzen dafür report-uri.io von Scott Helme, welches nach dem Teil des Headers benannt ist (report-uri: ), der dem Browser meldet, an welche Adresse er solche Verstöße melden soll. Dieses bietet eine einfache Benutzeroberfläche und wir brauchen somit kein eigenes System dafür aufzubauen.
    Natürlich werden wir die Reports regelmäßig überprüfen und wenn es etwas auffälliges gibt euch berichten.

    [COLOR=#004F55][size=18]Übrigens...[/SIZE][/COLOR]
    Beide Features laufen schon mehrere Wochen auf dieser Webseite. In dieser Zeit hatten wir insbesondere den CSP-Header immer wieder verbessert, da es doch einige Dinge gab, die von anderen Webseiten eingebettet wurden.
    Aktuell sollte alles wie erwartet funktionieren. Wenn dies bei einer Funktion nicht der Fall sein sollte, schaut in der Konsole eures Browsers (meist mit F12 aufrufbar) nach (CSP-)Fehlermeldungen und meldet diese an einen Admin oder antwortet in diesem Thread.

  • Es ist aber kein Problem wenn nun einer schreibt der moderne Schutz ist mir zu hoch was kann es. Geht mir genauso so. Ich werde die Erklärung 10 mal lesen dann bleibt was hängen.
    Super Arbeit und Danke an das Admin Team

  • Einfache Kurz-Erklärung:
    HTTP Public Key Pinning: Es wird sichergestellt, dass das Zertifikat, welches den Abruf unserer Seite via HTTPS ermöglicht, das richtige ist. Beim ersten Aufruf unserer Seite werden deshalb Informationen zum verwendeten Zertifikat gespeichert um später nachschauen zu können ob es immer noch das gleiche ist. Sollte es später nicht mehr das gleiche sein, stimmt da was nicht...
    Content Security Policy: Wir definieren (mehr oder weniger strikte) Regeln, von wo Teile unserer Webseite geladen werden. (Von www. hackwebsite.example.com darf bzw. kann zum Beispiel nichts geladen werden :))

    Vielleicht hilft das weiter.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!