Security in eigener Sache

Die letzten Wochen habe ich unter anderem damit verbracht, den teils neuen und teils etwas älteren heißen Scheiß an Security Headern und DNS Einträgen im Kontext von geekbundle.org zu aktualisieren und hinzuzufügen. Das hinterlässt auf hardenize.com und dem Mozilla Observatory nun einen deutlich besseren Eindruck. In diesem Beitrag werde ich die neuen Optionen kurz erklären aber nicht auf die Einrichtung eingehen. Neu sind folgende Dinge:

DNS

• MTA-STS
• TLS-RPT

HTTP Header

• Content-Security-Policy
• Expect-CT
• X-Frame-Options
• X-XSS-Protection
• X-Content-Type-Options
• Referrer-Policy

Was ist das eigentlich alles?!

MTA-STS

Mail Transfer Agent - Strict Transport Security soll dafür sorgen, dass zwischen den SMTP Servern durchgehend TLS gesprochen wird. Es setzt dabei auf einen DNS Eintrag und eine Policy Datei die unter https://mta-sts.<domain>.tld/.well-known/mta-sts.txt veröffentlicht wird.

root@Sanctuary:~# dig TXT _mta-sts.geekbundle.org. +short
"v=STSv1; id=20190317215100Z"

Der DNS Eintrag informiert über die Existens, die Version und ID einer MTA-STS Policy. Die ID dient als Caching von Policies.

Die Policie Datei mta-sts.txt beinhaltet vier Werte.

version: STSv1
mode: enforce
mx: mx.geekbundle.org
max_age: 1209600

Version ist die Version der Policy. Mode definiert einen von drei Modi, "enforce", "testing" und "none". Testing schickt Fehler an eine Reporting-Funktion, enforce aktiviert die Regel und none deaktiviert mta-sts. mx gibt den Mailserver an. Es dürfen auch mehrere mx Einträge vorhanden sein. Aber pro Zeile immer nur ein mx Eintrag mit einer Server Adresse. max_age ist die Zeit in Sekunden die der SMTP Server die Policie cachen soll. Weitere Informationen dazu in dem hervorragendem Artikel von golem.de.

TLS-RPT

SMTP TLS Reporting soll es E-Mails sendenen Anwendungen ermöglichen, TLS Verbindungsprobleme an eine E-Mail Adresse zu senden. Aus Angst, E-Mails nicht empfangen zu können, wird die Sicherheit von SMTP Servern ja häufig eher vernachlässigt. Mit TLS-RPT kann eine sichere TLS Konfiguration für den SMTP Server gewählt werden und sollte es doch zu Verbindungsproblemen kommen, schickt der sendende MTA einen Bericht an die im DNS hinterlegte E-Mail Adresse.

So zumindest die Idealvorstellung. In der Realität scheitert es momentan noch an MTAs die TLS-RPT unterstützen. Sollte es allerdings irgendwann eine breite Unterstützung erhalten, kann es bei vielen Verbindungsproblemen unterstützen. Und der einzelne DNS Eintrag schadet bestimmt nicht.

root@Sanctuary:~# dig TXT _smtp._tls.geekbundle.org. +short
"v=TLSRPTv1; rua=mailto:postmaster@geekbundle.org"

Content-Security-Policy

Auf Twitter hab ich ja schon meine Meinung zu CSPs geschrieben..

In Kurzform teilt eine CSP einem Browser mit, welche Art von Ressource (Javascript, Bilder, Fonts, ...) dieser von welcher URL laden darf. Meine zum Zeitpunkt der Veröffentlichung dieses Artikels aktive CSP sieht wie folgt aus und ist bei weitem nicht perfekt. Zum Beispiel gibt es noch Probleme beim Updaten von WordPress. Zum Glück mache ich das primär über die Kommandozeile per wp-cli. Ausserdem sind manche Definitionen noch zu offen...

Bei www.geekbundle.org:

Content-Security-Policy: default-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://static.geekbundle.org https://piwik.geekbundle.org; object-src 'none'; style-src 'self' data: 'unsafe-inline' https://static.geekbundle.org https://ajax.googleapis.com; img-src 'self' data: https://secure.gravatar.com https://s.w.org https://wordpress.org https://ps.w.org https://static.geekbundle.org https://piwik.geekbundle.org; font-src 'self' data: https://static.geekbundle.org; connect-src 'self'

Expect-CT

Wenn eine Webseite den Expect-CT (Certificate Transparency) Header sendet, wird der Browser aufgefordert nachzusehen, ob das Zertifikat im öffentlichen Certificate Transparency Log vorhanden ist. Zusätzlich kann eine URI mitgegeben werden, an die CT Probleme gesendet werden sollen.

Bei www.geekbundle.org:

Expect-CT: enforce, max-age=86400

X-Frame-Options

Diese Option soll verhindern, dass die eigene Seite, oder teile dieser, in einem Frame auf einer anderen Domain eingebettet wird. Folgende Optionen gibt es:

• deny - Verbietet das einbetten in einem Frame von jeder Domain, auch der eigenen
• sameorigin - Die eigene Domain darf
• allow-from https://example.org - Erlaubt das einbetten innerhalb von example.org

Bei www.geekbundle.org:

X-Frame-Options: sameorigin

X-XSS-Protection

Aktiviert XSS Schutz und verhindert bei mode=block, dass die Seite geladen wird. XSS Schutz ist grundsätzlich in Browsern immer an. Man kann also mit diesem Header dem Browser sagen, sein Standardverhalten zu ändern indem nicht vor XSS Angriffen geschützt wird oder bei einem entdecktem XSS Angriff die Seite komplett zu blocken.

• 0 - Deaktiviert XSS Schutz
• 1 - Aktiviert XSS Schutz (standardmäßig immer an)
• 1; mode=block - Verhindert das laden der Seite bei aktiviertem XSS Schutz

Bei www.geekbundle.org:

X-XSS-Protection: 1; mode=block

X-Content-Type-Options

Die Mime Types im Content-Type Header müssen bei <script> und <style> zueinander passen.

• nosniff - Blockiert Anfragen, wenn der Mime Type nicht passt
  • <style> muss "text/css" sein
  • <script> muss einen gültigen JavaScript Mime Type entsprechen

Bei www.geekbundle.org:

X-Content-Type-Options: nosniff

Referrer-Policy

Die Referrer-Policy fordert den Browser auf, URLs bzw. Links nicht mitzuteilen von welcher Seite man kommt.

Privacy fördernde Referrer-Policies:

• no-referrer - Es wird kein Referrer gesendet
• same-origin - Nur innerhalb der Domain wird ein Referrer gesendet
• strict-origin - Selbe Domain, aber nur wenn https
• strict-origin-when-cross-origin - Wenn selbe Domain wird die gesamte URL übergeben, ansonsten nur der Domainname. Erfordert https.

Weniger oder gar nicht privacy fördernde Referrer-Policies:

• no-referrer-when-downgrade - Standard. Innerhalb des selben Protokolls (http --> http / https --> https) wird die volle URL mitgeteilt. Von https --> http allerdings nicht
• origin - Sendet nur die Domain mit Protokoll, nicht den Pfad
• origin-when-cross-origin - Die vollständige URL wird ans Ziel same-origin gesendet. An alle anderen nur die Domain.
• unsafe-url - Sendet immer an jedes Ziel die vollständige URL

Bei www.geekbundle.org:

Referrer-Policy: strict-origin-when-cross-origin

Fazit

Viele dieser Mechanismen finde ich sehr sinnvoll, wie TLS-RPT oder Expect-CT, und können die Sicherheit der eigenen Seite und des Besuchers deutlich erhöhen. Manche schießen aber meiner Meinung nach deutlich über das Ziel heraus. Ja, die Content-Security-Policies meine ich. Sie sind eine nette Idee, aber gerade für Seiten die von den unterschiedlichsten Quellen etwas einbetten fast nicht wartbar. Webseitenbetreiber, die ihre Seite monetarisieren, machen das z.B. an sehr vielen Stellen für das Tracking. Oder diverse Social Media Integrationen.