Security in eigener Sache

Veröffentlicht von

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..

Twitter CSP
https://twitter.com/DerMadic/status/1103224959936147456 / Ganzer Thread

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.

1
Hinterlasse einen Kommentar

avatar
1 Kommentar Themen
0 Themen Antworten
1 Follower
 
Kommentar, auf das am meisten reagiert wurde
Beliebtestes Kommentar Thema
1 Kommentatoren
Sebastian van de Meer Letzte Kommentartoren
  Abonnieren  
neueste älteste meiste Bewertungen
Benachrichtige mich bei
Sebastian van de Meer
Gast

Sehr schön! Ich baue beim RFC 8461 ja noch immer sehr ebenfalls auf 4.2 Recipient MTA Certificate (https://tools.ietf.org/html/rfc8461#section-4.2). Ich hoffe das damit endlich mal diese ganzen Self-signed 10 Jahre gültigen SHA1 Cisco Demo Zertifikate verschwinden. Die Dinger bei denen man immer mit MITM rechnen muss, wenn man nicht pinnt. Denn sauberes DNSSEC mit DANE macht ja auch keiner, ok du natürlich \o/ Jetzt fehlt dafür nur noch eine saubere Integration in Postfix. Es gibt da ja schon was in Python aber öhm direkt drin wäre halt schön. Hast du da schon was? Da, nur für dich: 2019-03-23 09:59:05 DEBUG STS:… Weiterlesen »