12 sinnvolle Sicherheitseinstellungen im Rahmen der DSVGO

Nach ein paar Tagen Datenschutz-Grundverordnung und entsprechender Rückmeldungen von Kunden und Kollegen habe ich ganz interessante Erfahrungen gemacht, woüber man so stolpern kann bei der Umsetzung der DSVGO. Ausser den grossen Dingen wie der Verschlüsselung der Website, der Einwilligung zum Setzen von Cookies und der Datenschutzerklärung hier mal eine, natürlich unvollständige, Liste von 12 technischen Feinheiten, bei denen der "Teufel" immer im Detail steckt. Alle Beispiele sind seit Jahren bekannt, wurden aber durch die Einführung der Verordnung wieder an die "Oberfläche gespült". Es ist nicht notwendig in Panik zu geraten und alles sofort anpassen und ändern zu wollen. Es ist aber eine sehr gute Idee über diese Themen mehr Hintergrundwissen zu erlangen und so nach und nach die eigenen Websites zu durchforsten und gegebenenfalls anzupassen.

1. Fehlendes "Secure" Attribut in verschlüsselten Sitzungs-Cookies

Wenn ein Cookie gesetzt wird, wird auch eine Aussage über die Möglichkeiten des Zugriffs auf dieses Cookie gegeben. Wenn Cookies beispielsweise durch JavaScript lesbar sind, können XSS Angriffe erfolgreich sein.

Unsicheres Cookie: Skripte können zugreifen.

Set-Cookie: CookieName=Wert; path=/;

Fast sicheres Cookie: Skripte können nicht mehr zugreifen, die Verschlüsselung des Cookies wird jedoch nicht erzwungen und daher kann der Inhalt sensibler Cookies ausgelesen werden.

Set-Cookie: CookieName=Wert; path=/; HttpOnly

Sicheres Cookie: Durch das Setzen des Secure Attributs wird die verschlüsselte Übertragung erzwungen.

Set-Cookie: CookieName=Wert; path=/; HttpOnly; secure

2. Abfrageparameter in SSL Anforderungen

Wenn sensible Daten übergeben werden, sollte man das per SSL UND POST-Methode tun:

So etwas sieht man oft bei einer Suchfunktionen und da ist es auch "o.k.". Die Weitergabe der Daten erfolgt mittels GET Methode und SSL (https://).

https://www.google.fr/search?client=opera&q=novatrend

Man stelle sich das gleiche bei einem Anmeldeversuch vor und es wird schnell deutlich, dass das nicht so gut sein kann :)

https://example.com/login?user=hagen&password=apfelkuchen

3. Flash Player

Es gibt ihn noch! Er spielt SWF-Dateien ab. Diese SWF Dateien können auf einem anderen Server liegen. Wenn diese Dateien von einem anderen Server angezeigt werden, haben sie Skript-Zugriff auf die Website. Das ist nicht gut, weil dadurch wiederum Cookies verändert werden können und damit unter Umständen die Identität des legitimen Benutzers.

Man kann beim Flash Player Code den Parameter 'AllowScriptAccess' auf 'sameDomain' einschränken und hat damit schon viel erreicht.

4. Verschlüsselung erzwingen

Die http:// Version der Website sollte auf https:// weitergeleitet werden. Manchmal wird das vergessen. Und manchmal sind im Inhalt dann Logos oder andere Grafiken noch per http:// eingebunden und damit nicht verschlüsselt. Richtig blöd wird es, wenn ein Link auf die eigene Seite per http:// existiert und die Website keine Weiterleitung von http:// auf https:// hat. Dann wird die Website nach einem Klick auf diesen Link unverschlüsselt ausgeliefert.

5. Der Webserver ist unsicher konfiguriert

Ein Webserver muss wissen, welche kryptografischen Verfahren denn überhaupt benutzt werden sollen, wenn eine Verschlüsselung "verhandelt" wird. Zu diesem Zweck werden Cipher Suites definiert. Gerade bei den benötigten Hashfunktionen (siehe auch Blockchain: Hash Funktionen und Merkle Bäume) werden manchmal veraltete SHA-1 Funktionen verwendet. Das ist nicht gut und bei der Webserverkonfiguration vermeidbar. Testen kannst das beispielsweise hier https://www.ssllabs.com/ssltest/.
SHA256

SHA256

Bei SHA-2 handelt sich um SHA-224, SHA-256, SHA-384 und SHA-512. Die angefügte Zahl gibt die Länge des Hash-Werts (in Bit) an.

6. HTTP Header

Bei den HTTP Headern geht es in erster Linie um die Header, die ein X im Namen haben. Ein X wird auf Englisch auch als Zeichen für "Cross" interpretiert und steht in diesem Zusammenhang für Header die einen Bezug zu Cross Site Scripting haben (siehe auch https://de.wikipedia.org/wiki/Liste_der_HTTP-Headerfelder)

X-Content-Type-Options

Der einzige definierte Wert „nosniff“ untersagt dem Internet Explorer durch MIME-Sniffing einen anderen als den deklarierten Inhaltstyp zu bestimmen und anzuwenden.

Beispiel: X-Content-Type-Options: nosniff

Content-Security-Policy

Content Security Policy (CSP) ist ein Sicherheitskonzept, um Cross-Site-Scripting und andere Angriffe durch Einschleusen von Daten in Webseiten zu verhindern. Es handelt sich um einen W3C-Empfehlungskandidat zur Sicherheit von Webanwendungen (https://de.wikipedia.org/wiki/Content_Security_Policy).

Beispiel: Content-Security-Policy: default-src https://cdn.example.net; frame-src 'none'; object-src 'none'

X-Frame-Options

Der Header X-Frame-Options sorgt im Browser dafür, dass die Webseite nicht in einem Frameset (X-Frame-Options "DENY") bzw. nur in einem Frameset angezeigt wird, das vom gleichen Webserver ausgeliefert wurde (X-Frame-Options "SAMEORIGIN"). Der Response Header lässt sich auch in der .htaccess Datei setzen ("Header append X-FRAME-OPTIONS DENY") https://de.wikipedia.org/wiki/Frame_(HTML).

Beispiel: X-Frame-Options: DENY

X-XSS-Protection

Dieser Header aktiviert die in den aktuellen Browsern eingebauten Cross-Site-Scripting (XSS)-Filter. Die Filter sind standardmäßig im Browser aktiviert, daher ist dieser Header nur dazu da, den Filter für eure Seite wieder zu aktivieren, falls der Benutzer ihn abgeschaltet hat.

Beispiel: X-XSS-Protection: 1; mode=block

7. Robots.txt

Die Idee einer robots.txt Datei ist es, dem Suchmaschinen-Spider zu sagen, was er scannen soll und was nicht. Die Suchmaschinen halten sich sogar meistens daran. Die Datei ist aber auch per Browser erreichbar und damit im Klartext lesbar. Hier ein Beispiel, welches das Problem verdeutlicht.

User-agent: * 
Disallow: /fotos/ 
Disallow: /temp/ 
Disallow: /fotoalbum.html

Der Hinweis in der Datei bedeutet sinngemäss: "Lieber Leser, der du dich für meine Daten interessierst: Schaut bitte nicht in die Ordner /fotos/ und /temp/ und ruf bitte auf keinen Fall die Datei /fotoalbum.html auf".

Der einzige Weg, die Inhalte von Verzeichnissen und Dateien zu lesen führt über User und Passworte (https://wiki.selfhtml.org/wiki/Webserver/htaccess/Passwortschutz).

8. Temporäres Verzeichnis

Temporäre Verzeichnisse heissen meistens tmp oder temp und sollten ausserhalb des Dokumentenverzeichnisses liegen. Man weiss ja nie, was da gerade drinliegt und es könnte interessant sein für einen Besucher. Wenn es innerhalb des Dokumentenverzeichnisses liegen muss, sollte es geschützt werden. Hier als Beispiel eine .htaccess Datei in einem /tmp/ Verzeichnis die von Drupal 7 verwendet wird.

Deny from all
# Turn off all options we don't need.
Options None
Options +FollowSymLinks
# Set the catch-all handler to prevent scripts from being executed.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
<Files *>
# Override the handler again if we're run later in the evaluation list.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
</Files>
# If we know how to do it safely, disable the PHP engine entirely.
<IfModule mod_php5.c>

#php_flag engine off
</IfModule>

9. Links mit Target="_blank"

Durch das Öffnen eines neuen Fensters oder Tabs wird vom Browser der Befehl window.opener ausgeführt. Zu diesem Zeitpunkt erhält das neue Fenster Zugriff auf das Quellfenster. Dann kann man mit dem JavaScript-Befehl window.open.location = newURL eine Zielanfrage umleiten und sogar den bestehenden Fensterinhalt ändern. Um das zu verhindern musst du jedem Link mit target="_blank" das Attribut rel="noopener noreferrer" hinzufügen.

10. Reste vom Programmieren

Dieser Punkt klingt jetzt wirklich simpel, aber auf vielen Website befinden sich im Root Verzeichnis Dateien mit Namen wie test.php o.ä.. Auch befinden sich oft Kommentare im HTML Code, die Rückschlüsse auf Zusammenhänge erlauben. Die Lösung ist in diesem Fall einfach: Nach der Arbeit das Aufräumen nicht vergessen :)

11. Keine E-Mail Adressen auf der Website

Entferne alle E-Mail Adresse von der Website und nutze ein Kontaktformular!

12. Subresource Integrity

Durch die Nutzung der W3C-Spezifikation Subresource Integrity soll die Integrität von Skripten geprüft und ausgeschlossen werden, dass veränderte Skripte zum Einsatz kommen. Das ist wichtig bei der Nutzung von Content Delivery Networks (CDN). Siehe dazu auch Mit Subresource Integrity gefährliche Skripte blocken.

Fazit:

Die meisten dieser Themen sind seit Jahren bekannt und werden innerhalb der Branche auch diskutiert. Es ist schwer, konkrete Handlungsanweisungen zu geben, da in unterschiedlichen Kontexten völlig unterschiedliche Herangehensweisen sinnvoll sind. Teilweise lassen sich die Punkte mit dem Einsatz von entsprechenden Plugins (WordPress), Modulen (Drupal) oder Erweiterungen (Joomla) lösen oder tauchen gar nicht erst auf. Je individueller deine Website ist, desto individueller wird die Beachtung der Punkte sein.

12 sinnvolle Sicherheitseinstellungen im Rahmen der DSVGOsteemCreated with Sketch.