Sicherheit für DNN-Installationen Teil 3 - Sicherheitseinstellungen für ASP.Net-Installationen
Die Kommunikation der Kunden mit der Website ist nun verschlüsselt, und damit ist ein erster Schritt getan. Im nächsten Schritt werden wir ASP.Net-spezifische Einstellungen treffen.
ASafaWeb
Die Website asafaweb.com bietet automatische Sicherheitsanalysen für ASP.Net-Websites an, und wenn wir hier einmal unsere Seite durchlaufen
lassen, ergibt sich ein ziemlich übles Bild:
Die gute Nachricht ist allerdings, dass sich die meisten dieser Probleme durch Anpassung der web.config relativ einfach lösen lassen. Dies kann man mit einem Texteditor auf dem Server durchführen,
oder man verwendet den DNN-eigenen Konfigurationseditor (dann muss man allerdings ohne bequeme Suchmöglichkeit auskommen). Dieser befindet sich in DNN 9 unter Einstellungen :: Konfigurationseditor bzw.
in früheren Versionen unter System :: Konfigurationen bearbeiten.
Tracing
Tracing wird für diagnostische Informationen über ASP.Net-Anfragen benötigt – dies ist allerdings nur für Entwickler interessant, in einer Produktivumgebung werden damit zu viele
Informationen über interne Operationen der Seite zur Schau gestellt.
Um das Problem zu lösen suchen wir in der web.config nach "<trace", und finden einen Eintrag, der vielleicht so aussieht:
<trace enabled="true" requestLimit="40" localOnly="false" />
Diesen ersetzen wir einfach durch:
<trace enabled="false" />
Damit ist das Problem bereits gelöst:
Sollte der Punkt bei dir bereits grün sein und du diesen Eintrag nicht in der web.config finden – auch gut, dann ist das bereits übergeordnet geregelt. Natürlich kannst du den Eintrag
auch trotzdem explizit am Ende des Abschnitts "system.web" hinzufügen.
Custom Errors und Stack Trace
Die Einstellung "Custom Errors" dient dazu, Benutzern nicht interne Fehlermeldungen anzuzeigen. Stattdessen sollte die Fehlermeldung für den Besucher verständlich sein und der
Öffentlichkeit potentiell sensible Informationen vorenthalten.
Stack Tracing kennt wohl jeder, das sind diese "Yellow Screens of Death", die ASP.Net liefert, wenn ein Fehler aufgetreten ist. Wie Tracing ist das ein nützliches Werkzeug für Entwickler,
diese Informationen gehen aber sonst niemanden etwas an. In einer Produktivumgebung gehört das definitiv deaktiviert.
Wir haben ja bereits im Teil 2 die Fehlerseiten für die HTTP-Fehler 404 und 500 definiert,
in der web.config fehlt uns dafür aber noch ein Eintrag für alle anderen Fehlerseiten. Der Einfachheit halber leiten wir diese auch auf die Seite für den Fehler 404:
<customErrors defaultRedirect="/Fehler-404" mode="RemoteOnly" />
Du musst hier im Attribut defaultRedirect natürlich die richtige Url einsetzen – und schon sind auch diese beiden Probleme gelöst:
Request Validation
Die Validierung von Anforderungen ist auf einer Webforms-Seite notwendig, um sicherzustellen, dass nicht potentiell schädliche Anforderungen auftreten und Schaden anrichten können. Das
schützt vor der Wahrscheinlichkeit des Auftretens von Cross-Site-Scripting-Schwachstellen der Site.
Auch hier ist die Lösung einfach: In der web.config findet sich der Eintrag "pages" mit dem Attribut "validateRequest" – dieses ist auf "true" zu setzen:
<pages validateRequest="true" ...
Auch dieses Problem ist damit beseitigt:
HTTP to HTTPS
Darüber habe ich im Teil 2 bereits geschrieben – ich überlasse es jedem einzelnen, die Warnung
hier zu ignorieren, oder das Ding auf Grün zu stellen, indem man die Regel aus der web.config entfernt, welche diese Umleitung erzwingt.
Excessive Headers
Damit sind HTML-Header gemeint, die angeben, unter welchem System die Website läuft. Diese Header werden in der Beschreibung der Warnung angezeigt:
Wie man diese los wird ist leider reichlich unterschiedlich. Es gibt einige Seiten im Web, die beschreiben, was zu tun ist:
Die drei hier angezeigten Header werden wie folgt entfernt:
Server
Dazu ist entweder ein CustomHeader-Modul notwendig, welches von DNN leider nicht mitgeliefert wird. Die einfache Variante ist allerdings, eine Outbound-Regel in der web.config zu definieren,
die den Eintrag entfernt. Diese wird am Ende des in Teil 2 eingefügten rewrite-Blocks angelegt:
</rules>
<outboundRules>
<rule name="Remove Server Header">
<match serverVariable="RESPONSE_SERVER" pattern=".+" />
<action type="Rewrite" value="" />
</rule>
</outboundRules>
</rewrite>
X-Powered-By
Dieser Eintrag wird entfernt, indem man ihn einfach im IIS Manager löscht. Dazu doppelklickt man im Abschnitt IIS auf "HTTP Response Headers":
Danach klickt man den Eintrag mit der rechten Maustaste an und entfernt ihn:
X-AspNet-Version
Dazu ist im Eintrag "httpRuntime" das Attribut "enableVersionHeader" auf "false" zu setzen (oder hinzuzufügen, falls es nicht vorhanden ist:
<httpRuntime enableVersionHeader="false" …
(Der Eintrag ist auch für die Maximalgröße von hochzuladenden Dateien u.a. verantwortlich, und entsprechend wurde er wahrscheinlich von jedem schon einmal verändert).
Auch dieser Punkt ist damit gelöst:
Aber: Es gibt da noch ein DNN-Spezifikum, nämlich der Copyright-Hinweis von DNN, das man auch zu dieser Kategorie zählen könnte. Es ist zwar kein Header, sondern ein Kommentar, und er wird auch nicht
von ASafaWeb getestet, dennoch wird damit viel Information angezeigt, die niemanden etwas angeht:
Dieser Kommentar kann in den Systemeinstellungen unter "Darstellung" (System :: Systemeinstellungen) deaktiviert werden.
HTTP Only Cookies
Cookies, die nicht als HTTP-Only markiert sind, können von Client-seitigem Script ausgelesen und für Cross-Site-Scripting-Attacken (XSS) missbraucht werden.
Um nur HTTP-Cookies zuzulassen muss in der Datei web.config folgender Wert gesetzt werden:
<httpCookies httpOnlyCookies="true" …
Damit ist auch dieses Problem gelöst:
Secure Cookies
Cookies, die über HTTPS gesendet, aber nicht als sicher markiert sind kännen vom Browser über nicht verschlüsselte Verbindungen gesendet werden. Oft können dies einfache Anfragen
für Assets wie eine Bilddatei sein, wenn sich dieses aber in derselben Domäne wie das Cookie befindet wird es über eine unsichere Verbindung gesendet. Dies ermöglicht Man-In-The-Middle-Attacken.
Auch hier ist die Lösung einfach, auch wenn hier zwei Einträge zu treffen sind. Einerseits der bereits oben beschriebene, der ist zu ändern oder zu ergänzen:
<httpCookies httpOnlyCookies="true" requireSSL="true" …
Damit ist das Problem aber noch nicht gelöst, es bleibt das Cookie für anonyme Anmeldungen übrig. Dafür ist ein die Änderung dieses Eintrags notwendig:
<anonymousIdentification enabled="true"... cookieRequireSSL="true" …
Und so ist auch dieses Problem gelöst:
Clickjacking
Clickjacking ist eine Technik, bei der ein Hacker eine Seite überlagert und dann den Benutzer dazu bringt, scheinbar harmlose Eingaben oder Mausklicks durchzuführen. Dazu muss es ermöglicht werden,
die Seite in einem Frame oder IFrame darzustellen. Dies wird aber oft wiederum benötigt, um Dokumente von der eigenen Seite anzuzeigen, daher sollte man die Darstellung in einem Frame oder IFrame auf fremden
Seiten unterbinden. Dazu ist folgender Eintrag im Block "customHeaders" (den wir vorhin durch das Läschen des X-Powered-By-Headers bereits erzeugt haben) notwendig:
<customHeaders>
<remove name="X-Powered-By" />
<add name="X-Frame-Options" value="SAMEORIGIN" />
</customHeaders>
Damit hätten wir die Tests auf dieser Seite einmal bestanden:
Aber es bleibt noch viel zu tun …
Weiter: Sicherheit für DNN-Installationen Teil 4 - IIS-Einstellungen