dnnWerk.at - Michaels Blog

Sicherheit für DNN-Installationen Teil 4 - IIS-Einstellungen

Sicherheit - 12.01.2018

Sicherheit DNN IIS

Security Headers

Die Website securityheaders.io testet und bewertet Header-Informationen von Websites. Auch hier landen wir zunächst einmal nicht so besonders toll:
Securityheaders - 1. Analyse

X-Frame-Options

Das haben wir im Abschnitt "Clickjacking" im dritten Teil bereits besprochen - und es leuchtet ja schon grün auf. Ich werde also hier nicht noch einmal darauf eingehen.

Strict Transport Security

HTTP Strict Transport Security (HSTS) ist ein Mechanismus, der es einem Webserver ermöglicht, die Verwendung von TLS (Transport Layer Security, dem Nachfolger von SSL) in einem konformen Browser zu erzwingen. Dies erlaubt die effektivere Implementierung von TLS indem sichergestellt wird, dass jede clientseitige Kommunikation über eine verschlüsselte Transportschicht durchgeführt wird. Man-in-the-Middle-Attacken, bei denen die sichere Kommunikation mit einem Server untergraben werden kann, werden so verhindert oder zumindest erschwert.

Implementiert wird diese durch eine weitere Regel im bereits angelegten Rewrite-Block in der Datei web.config:

<outboundRules>
   <rule name="Add Strict-Transport-Security when HTTPS" enabled="true">
      <match serverVariable="RESPONSE_Strict_Transport_Security" pattern=".*" />
      <conditions>
         <add input="{HTTPS}" pattern="on" ignoreCase="true" />
      </conditions>
      <action type="Rewrite" value="max-age=31536000; includeSubDomains" />
   </rule>

Die Option includeSubDomains weist den Browser an, auch alle Websites auf Unterdomänen (z.B. meinedomain.de, www.meinedomain.de, shop.meinedomain.de etc.) als HSTS-Hosts zu behandeln. Sie kann natürlich auch weggelassen werden, wenn dem nicht so sein soll.

Resultat ist jedenfalls, dass diese Einstellung grün aufleuchtet:
Securityheaders - HTTP Strict Transport Security

Content Security Policy

Eine CSP (Content Security Policy) ist ein Regelwerk, welches festlegt, welche Quellen für Inhalte vertrauenswürdig sind und vom Browser geladen werden dürfen. Auch hier geht es um die Verhinderung von Cross-Site-Scripting-Attacken.

Die Implementierung einer CSP ist allerdings nicht ganz so trivial wie alle davor besprochenen Punkte. Ich werde mich der Erstellung einer CSP in einem eigenen Teil dieses Blogs zu einem späteren Zeitpunkt widmen. Vorläfig rate ich einmal dazu, ein Konto auf der Website report-uri.com anzulegen und dort eine Url zu reservieren. Die Site bietet geeignete Hilfsmittel an, um eine CSP zu erstellen, dazu später.

Eine CSP kann allerdings viele Inhalte blockieren, was nicht gerade wünschenswert ist. Deshalb sollte man diese Einstellung eine Zeitlang im Report-Only-Modus laufen lassen, und dann seine Policy effizient erstellen.

Für’s erste begnügen wir uns damit, folgende Zeile im Block customHeaders einzutragen, nachdem wir unser Konto auf report-uri eingerichtet haben:

<add name="Content-Security-Policy-Report-Only" value="default-src 'self';report-uri https://meinesubdomainbei.report-uri.com/r/d/csp/reportOnly;" />

Das ist keine sichere CSP, so viel ist klar. Das Problem ist, dass hier keine allgemeinen Ratschläge erteilt werden können, weil jede Website etwas anderes benötigt und verwendet. Die Erstellung und Wartung einer CSP ist eine zeitintensive Arbeit, die niemals endet.

Und darum werden wir heute diesen Schalter nicht auf grün stellen…

X-Xss-Protection

Ein weiterer Schutz gegen XSS-Attacken ist die Verwendung dieses Headers. Er konfiguriert den internen reflektiven Schutzmechanismus in Internet Explorer, Chrome oder Safari (Webkit). Der Wert 0 deaktiviert diesen, der Wert 1 aktiviert ihn und der Modus "block" konfiguriert den Browser derartig, dass die Antwort eines Servers im Falle einer erkannten Attacke blockiert wird und nicht der Versuch unternommen wird, das Skript zu sanieren.

Folgender Eintrag im Block customHeaders führt diese Konfiguration aus:

<add name="X-Xss-Protection" value="1; mode=block" />

Securityheaders - Xss-Protection

X-Content-Type-Options

Durch diese Einstellung lehnen Chrome und Internet Explorer Antworten mit falschen MIME-Typen ab und verhindern so Angriffe, die auf der Verwechslung vom MIME-Typen basieren. Nur vom Server deklarierte MIME-Typen können empfangen werden.

Die Implementierung ist einfach, der Header kann auch nur einen einzigen Wert zugewiesen bekommen. Tragen wir also im Block customHeaders folgende Zeile ein:

<add name="X-Content-Type-Options" value="nosniff" />

Securityheaders - Content Type Options

Referrer Policy

Die Referrer Policy konfiguriert den Wert des Referrer-Headers in Links, die von der Seite wegführen. Welchen Wert man hier verwenden will ist wieder stark abhängig von den eigenen Bedürfnissen, konfigurieren sollte man ihn allemal. Hier die möglichen Werte:

Wert Bedeutung
"" keine Referrer-Policy gesetzt
"no-referrer" keine Referrer-Header werden gesendet, auch nicht auf Links innerhalb der gleichen Website
"no-referrer-when-downgrade" Referrer-Header werden nicht gesetzt, wenn sich das Protokoll von HTTPS auf HTTP ändert
"same-origin" Referrer-Header werden nur gesendet, wenn Protokoll und Servername gleich sind, also auch nicht, wenn z.B. von https://www.mysite.de auf http://www.mysite.de/Blog verlinkt wird
"origin" Im Referrer wird nur die Basis-Url der Website selbst ohne Pfadinformationen angegeben
"strict-origin" wie "origin", der Header wird aber nicht gesendet, wenn sich das Protokoll von HTTPS auf HTTP ändert
"origin-when-cross-origin" Die Referrer-Header werden vollständig gesendet, wenn der Link auf die gleiche Site geht, ansonsten wird nur die Basis-Url der Website ohne Pfadinformationen gesendet
"strict-origin-when-cross-origin" wie "origin-when-cross-origin", der Header wird aber nicht gesendet, wenn sich das Protokoll von HTTPS auf HTTP ändert
"unsafe-url" Es werden immer die vollständigen Referrer-Header gesendet

Um diesen Header zu implementieren sucht man sich den passenden Wert aus und fügt folgende Zeile im Block customHeaders ein:

<add name="Referrer-Policy" value="Wert" />

Securityheaders - Referrer Policy

Womit wir schon viel erreicht hätten, aber es kommt noch mehr…

Weiter: Sicherheit für DNN-Installationen Teil 5 - Content Security Policy