1. Nützliche Helfer
Viele Webseitenbetreiber fragen sich, wie »sicher« der eigene Internetauftritt ist. Das hängt natürlich von unterschiedlichen Faktoren ab. Erste Anhaltspunkte liefern Online-Scanner, mit denen sich die Webauftritte oder auch E-Mail-Server auf Schwächen und Konfigurationsfehler prüfen lassen.
Die meisten Scanner fokussieren sich auf die Prüfung und Bewertung der Sicherheit. Doch es gibt auch Tools, die prüfen, wie datenschutzfreundlich eine Webseite ist oder welche Cipher-Suiten ein Browser unterstützt.
Im vorliegenden Beitrag möchte ich euch diverse nützliche Helfer vorstellen, die euch dabei unterstützen eure eigene Seite zu verbessern oder anderen Webseitenbetreibern auf den Zahn zu fühlen.
2. Eine kleine Auswahl
Die Reihenfolge, in der die Tools vorgestellt werden, ist beliebig gewählt. Falls ihr weitere Online-Scanner kennt, die zur Verbesserung der Sicherheit / des Datenschutzes beitragen können, dann hinterlasst mir einfach einen kurzen Hinweis. Nach einer Prüfung und Feststellung des Mehrwerts werde ich eure Empfehlung dann gegebenenfalls im Beitrag ergänzen.
Im Folgenden habe ich bei jedem Test eine Auswertung vom Kuketz-Blog oder meines E-Mail-Servers erstellen lassen.
Der Kuketz-Blog ist spendenfinanziert!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
2.1 Observatory by Mozilla
Mozilla bietet einen Sicherheitscheck für Webseiten an, der euch einen einfachen und schnellen Überblick über die Implementierung von Sicherheitsmaßnahmen liefert. Observatory überprüft bspw. ob Inhalte mittels Transport Layer Security (TLS) ausgeliefert werden und ob HTTP Public Key Pinning konfiguriert ist. Weitere Tests prüfen die Einstellungen zu Content Security Policy (CSP) und sogar die Integrität von JavaScripten, die über Drittseiten eingebunden werden – der sogenannte Subresource Integrity Check.
Die Auswertung startet bei 100 Punkten. Je nach implementierten Sicherheitsmerkmalen werden Punkte abgezogen oder sogar addiert. Observatory vergibt nach dem US-amerikanischen Vorbild die Schulnoten von A+ bis F.
2.2 Webbkoll
Webbkoll ist ein von Internetfonden und IIS finanziertes Projekt aus Schweden. Der Quellcode ist Open-Source und auf Github einsehbar. Vereinfacht ausgedrückt, simuliert Webbkoll was im Hintergrund passiert, wenn ihr eine Seite in eurem Browser aufruft. Dabei sammelt das Tool nach der Eingabe einer URL verschiedene Informationen, wie zum Beispiel Anfragen an Dritt-Seiten, Cookies, Response-Header usw. und stellt die Ergebnisse zusammen mit Erläuterungen und Hinweisen bereit.
Webbkoll bietet einige Sicherheitschecks an. Die Stärke des Tools liegt allerdings in der Darstellung von Ressourcen, wie JavaScript, Werbung, Cookies usw., die von Fremdquellen in eine Webseite eingebunden werden. Vielen Webseitenbetreibern scheint nicht bewusst zu sein, welches Risiko, für Sicherheit und Privatsphäre, mit der Einbindung externer Ressourcen einhergeht. Mit Webkkoll lässt sich also insbesondere herausfinden, wie datenschutzfreundlich eine Webseite ist.
Webbkoll habe ich bereits einen umfangreichen Beitrag gewidmet: Webbkoll: Wie datenschutzfreundlich ist deine Webseite?
2.3 Qualys SSL Labs
SSL Labs zählt gewiss zu jenen Online-Scannern, die am häufigsten genutzt werden, um die TLS-Konfiguration einer Webseite auf sicherheitsrelevante Einstellungen zu prüfen. Der Scanner überprüft unter anderem die unterstützten Cipher-Suiten, führt eine Handshake Simulation durch und prüft auf (aktuelle) Bedrohungen wie Ticketbleed, Heartbleed oder BEAST.
Die Entwickler ergänzen die Tests kontinuierlich um neu entdeckte Bedrohungen und verschärfen – je nach aktuell gültigem Standard bzw. Best-Practice – die Bewertungskriterien. Wenn ihr noch vor einem halben Jahr ein A bekommen habt, dann kann die fehlende Unterstützung von Perfect Forward Secrecy mittlerweile zu einer niedrigeren Bewertung der Note B führen. SSL Labs vergibt nach dem US-amerikanischen Vorbild die Schulnoten von A+ bis F.
2.4 Hardenize
Aktuell befindet sich Hardenize noch im Alpha-Stadium – macht aber schon jetzt einen ausgereiften Eindruck. Hinter dem Webservice steckt unter anderem Ivan Ristić, der Betreiber von SSL Labs. Hardenize prüft unterschiedliche Kategorien, wie Domain (DNS, DNSSEC, CAA), die E-Mail Server Konfiguration (SMTP, STARTTLS, DANE, SPF) und schließlich noch sicherheitsrelevante Einstellungen des Webservers (TLS, Cookies, HSTS, HTTP Public Key Pinning, CSP, etc.).
Hardenize beschränkt sich also nicht allein auf die Überprüfung der Webserver-Konfiguration, sondern bezieht auch Domain- und E-Mail-Parameter in den Test mit ein. Eine Endnote oder Gesamtpunktzahl, die alle Einstellungen berücksichtigt und bewertet, wurde bisher nicht implementiert. Laut Roadmap sollen in Zukunft weitere Tests ergänzt werden.
2.5 securityheaders.io
Das Online-Tool securityheaders.io beschränkt sich auf die Prüfung von Security-Headern, wie Strict-Transport-Security (HSTS), X-Frame-Options oder Content Security Policy (CSP). Leider nimmt das Tool keine explizite Bewertung der definierten CSP-Parameter vor, wie es bspw. Observatory anbietet. Daher lassen sich aus den Ergebnissen insgesamt weniger Erkenntnisse gewinnen, als bei der Konkurrenz.
Das Bewertungssystem ist dem Vorbild von SSL Labs nachempfunden – vergibt also auch nach dem US-amerikanischen Vorbild die Schulnoten von A+ bis F.
2.6 CryptCheck
SSL Labs zum prüfen der unterstützen Cipher-Suiten bzw. kryptographischen Verfahren einer Webseite kennen die meisten sicherlich. Wer allerdings nicht nur Webserver, sondern auch die unterstützen Cipher-Suiten von E-Mail- (SMTP), XMPP- und SSH-Servern testen möchte, der kann dafür CryptCheck einsetzen.
Auch das Bewertungssystem von CryptCheck ist dem Vorbild von SSL Labs nachempfunden – vergibt also auch nach dem US-amerikanischen Vorbild die Schulnoten von A+ bis F.
2.7 SSL Cipher Suite Details of Your Browser
Es ist durchaus interessant mal zu prüfen, welche Cipher-Suiten der eigene Browser anbietet. Bei der Aushandlung einer TLS-Verbindung sendet der Client alle von ihm unterstützen Cipher-Suiten an den Server. Dieser gleicht die empfangene Liste mit den Cipher-Suiten ab, die er unterstützt und wählt im Normalfall dann die »Beste« aus. Das bedeutet: Selbst wenn ein Server die aktuellsten Cipher-Suiten (TLS 1.2 oder höher) bereits unterstützt, bedeutet das nicht zwangsläufig, dass auch eine Cipher-Suite genutzt wird, die als »sicher« gilt. Damit eine TLS-Verbindung zustande kommt, die aktuelle Cipher-Suiten benutzt, sind immer zwei notwendig: Server und Client.
Auf der Webseite »SSL Cipher Suite Details of Your Browser« der Uni Hannover könnt ihr prüfen, welche Cipher-Suiten euer Browser unterstützt. In einem älteren Beitrag hatte ich auch mal aufgezeigt, wie sich die Cipher-Suiten im Browser beeinflussen lassen.
2.8 PrivacyScore
PrivacyScore bietet eine Reihe von Sicherheitstests, die nicht nur die Webseite prüfen, sondern auch den mit einer Domain verknüpften E-Mail-Server. Unter anderem wird geprüft ob Transport Layer Security (TLS) korrekt eingesetzt wird, also ob geeignete Protokollversionen, kryptographische Verfahren und HTTP-Header wie HTTP Strict Transport Security (HSTS) verwendet werden.
Der Online-Service prüft aber nicht nur die Sicherheit, sondern auch wie datenschutzfreundlich eine Webseite ist. PrivacyScore erkennt Analyse- und Werbedienste, eingebettete Ressourcen von Drittseiten und die Verwendung von Content Distribution Networks (CDN), die ebenfalls eine Gefahr für die Sicherheit und Privatheit darstellen können.
Der Quellcode von PrivacyScore soll demnächst veröffentlicht werden. Aktuell ist der Service noch im Beta Stadium, macht aber schon einen guten Eindruck. An der Darstellung des Gesamtergebnisses (Overall Rating) sollten die Betreiber allerdings noch etwas feilen – das finde ich wenig aussagekräftig. An den Einzelergebnissen inklusive Beschreibung gibt es hingegen nichts zu bemängeln.
3. Achtung: Die Ergebnisse
Der sichere und datenschutzfreundliche Betrieb einer Webseite ist aufwändig, meist mit zusätzlichen Kosten verbunden oder nicht mit dem Geschäftsmodell eines Seitenbetreibers vereinbar. Als Folge ist das Sicherheits- und Privatheitsniveau vieler Webseiten derzeit unzureichend.
Die vorgestellten Tools können Seitenbetreibern helfen, die Sicherheit und den Datenschutz für die Besucher einer Webseite zu verbessern. Sie schaffen allerdings auch Transparenz, da Nutzer in die Lage versetzt werden, den Online-Angeboten auf den Zahn zu fühlen. Wenn ein Webseitenbetreiber bspw. Dienstleistungen im Bereich der IT-Sicherheit bewirbt, dann aber unzählige JavaScripts von Drittquellen einbindet, muss stark bezweifelt werden, dass der Anbieter sein Handwerk tatsächlich versteht. Ähnliches trifft auf Protagonisten zu, die sich das Thema Privatheit / Datenschutz auf die Fahnen geschrieben haben, allerdings etliche Tracker einsetzen, die den Besucher auf Schritt und Tritt verfolgen. Auch hier zeigt sich die Diskrepanz zwischen beworbener Dienstleistung und dem dafür notwendigen (technischen) Sachverstand.
3.1 Richtig interpretieren
Bevor ihr jetzt allerdings eure eigene Webseite prüft oder anderen Seiten auf den Zahn fühlt, möchte ich eine Warnung voraus senden: Nur weil eine Webseite bspw. auf die Verwendung der Content Security Policy (CSP) verzichtet, ist die Webseite nicht zwangsläufig »unsicher«. Um den CSP-Header wirklich sinnvoll einbinden zu können (also so, dass er auch wirklich einen Mehrwert an Sicherheit bietet), muss man die Struktur einer Webseite meist recht stark anpassen.
Gleiches gilt für die Einbindung externer Ressourcen wie JavaScript oder Bilder. Hier ist immer entscheidend, um welche Ressourcen es sich handelt und von welcher Quelle diese eingebunden werden. Die Bilder für diesen Blog binde ich bspw. über die Adresse »https://media.kuketz.de« ein. Bei dieser Ressource handelt es sich im Grunde um eine Drittquelle. Allerdings wird das wieder relativiert, da diese Drittquelle von mir selbst betrieben wird, auf dem gleichen Server liegt und darüber lediglich Bilder ausgeliefert werden.
Das bedeutet: Ihr müsst die Ergebnisse interpretieren bzw. deuten können. Nur dann könnt ihr die Sicherheit / den Datenschutz eurer eigenen Seite auch nachhaltig verbessern oder die von anderen Seiten korrekt beurteilen.
3.2 Es gibt viel zu tun
Mozilla-Entwicklerin April King schreibt in einem Blogbeitrag zu Observatory:
The Observatory performs a multitude of checks across roughly a dozen tests. You may not have heard of many of them, and that’s because their documentation is spread across thousands of articles, hundreds of websites, and dozens of specifications. In fact, despite some of these standards being old enough to have children (see Appendix below), their usage rate amongst the internet’s million most popular websites ranges from 30% for HTTPS all the way down to a depressingly low .005% for Content Security Policy.
Und sie hat Recht. Wenn man sich den Appendix im Blogbeitrag anschaut, wird einem schonungslos vor Augen geführt, wie lange einige Sicherheitsstandards (HTTPS, CSP, etc.) schon existieren und wie selten diese eingesetzt werden.
Ich übertreibe also nicht wenn ich sage: Es gibt (verdammt) viel zu tun!
4. Fazit
Die wenigsten werden es im vorliegenden Beitrag vermutlich bis zum Fazit geschafft haben, sondern sind schon fleißig damit beschäftigt, ihre oder fremde Webseiten zu prüfen. Daher verbleibe ich mit: Viel Spaß beim Testen – und sorgfältigen interpretieren der Ergebnisse.
Bildquellen:
Report: DinosoftLabs from www.flaticon.com is licensed by CC 3.0 BY
Über den Autor | Kuketz
In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.
Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
Postfix: TLS-Konfiguration mit ECDSA- / RSA-Zertifikaten
NSA abhörsichere SSL-Verschlüsselung für Apache und nginx
Unsichere SSL-Verschlüsselung im Browser abschalten
Perfect Forward Secrecy mit Apple Mail?
Projekt arkOS: Installation SSL-Zertifikat
10 Ergänzungen zu “Online-Scanner: Tools für Sicherheit und Datenschutz”
Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
Vielen Dank. Das kann ich gut gebrauchen :-)
Zunächst Vielen Dank für das Teilen von Mozilla Observatory und der vielen anderen Online Test Tools, die eine erste Orientierung geben auf dem langen Weg zu mehr Sicherheit. Gerade die ganzen hippen Webdesigner und Webbaukästen-Schubser täten gut daran ein wenig mehr Hirnschmalz in Sachen Sicherheit zu investieren und nicht jedes Script im Netz zu verlinken. Es fehlt der Hinweis, daß bei einer wirklich gut abgesicherten Website solche Pen-Tests aber meist ins Leere laufen wenn da ein vernünftiges IDS/IPS wacht und die IP sofort bannt. Selbst bei einem eher harmlosen Mozilla Observatory gibts sofort ein „Unkown Error“. Erst wenn ich meinen Snort an die Leine nehme, gibt’s eine (natürlich meist grüne) Benotung.
Danke für die gute Linksammlung! Einige kannte ich bereits und andere sind für mich neu. Eine kleine
Ergänzung zu SSLabs hab ich allerdings, denn die prüft nur den Standard-Port 443.
In meinem Fall ist zwar auch der Port 443 erreichbar, der Besucher erhält allerdings einen 410-Fehler (Gone). Die eigene Cloud liegt allerdings auf einem hohen 5-stelligen Port, der sich z.B. mit https://www.htbridge.com/ssl/ prüfen lässt.
SSH-Verbindungen prüfe ich meist lokal mit https://github.com/arthepsy/ssh-audit
Danke für die schöne Zusammenfassung, Mike! Drei der vorgestellten Kandidaten (Observatory, SSLLabs, Webbkoll) nutze ich bereits seit einer Weile, und finde sie sehr hilfreich.
Bei PrivacyScore solltest Du aber vielleicht noch erwähnen dass, wenn man dort einmal eine URL angibt, diese automatisch periodisch geprüft wird (was PrivacyScore leider erst mitteilt, nachdem man den Scan ausgelöst hat – was m.E. ein wenig dem Privacy-Gedanken widerspricht; auf Anhieb konnte ich auch nicht ersehen, wie man sich da wieder austragen kann). Darüber hinaus finde ich nicht nur das „Overall Rating“ wenig aussagekräftig, sondern manche Angaben auch etwas seltsam: So wird beispielsweise Imgur als „Tracking Service“ geführt. Kann die Location eines Mailservers nicht ermittelt werden, gilt dieser als „unreliable“. Dass die geprüfte Website ein gültiges SSL Zertifikat benutzt, bedeutet angeblich auch „unreliable“ (???), gleiches gilt für HSTS, „no mixed content“ sowie gute „protection against CCS attack“, „Logjam“ und weitere (WTF?). Die Fakten werden zwar korrekt benannt, an der grafischen Darstellung („unreliable“ wenn ein positives Kriterium erfüllt wird) muss aber definitiv noch gearbeitet werden.
CryptCheck scheint noch eine Lücke zu füllen (XMPP) – allerdings vermisse ich noch immer eine Möglichkeit, auch IMAP testen zu können. Wenn Du dafür noch einen Dienst kennst, wäre die Ergänzung im obigen Artikel toll :)
PS: Durch ein wenig „herumklicken“ gerade herausgefunden: „reliable“/“unreliable“ bezieht sich bei PrivacyScore nicht auf das Ergebnis, sondern auf die Methode – „unreliable“ bedeutet also, man soll sich auf das Ergebnis nicht zu sehr verlassen. Ist also wirklich nur die „grafische Darstellung“, die ein wenig verwirrt. Wie im Artikel korrekt vermerkt: „Beta Stadium“ halt :) Fand bei meinem Test übrigens auch keinen der zwei MX Records der angegebenen Sub-Domain, da diese natürlich an der Domain selbst hängen (also z.B. nicht für „www.example.com“ sondern für „example.com“ definiert sind). Aber auch die Bewertung diverser „potentieller Vulnerabilities“ (z.B. „Lucky13“ wird an anderer Stelle beschrieben als effectively impractical. This will take days. It’s a theoretical attack rather than a practical threat.) könnte überdacht werden: sofern sich an „praktisch kaum umsetzbar“ nichts geändert hat, sollten derartige „rein theroretischen“ Dinge nicht in die Wertung einfließen. Aber warten wir einmal ab – in den Details steht schließlich noch „Description will be added soon.“ :)
Die Liste ist übersichtlich, aber ich hätte mir eine ausführliche Interpretation der Ergebnisse gewünscht. So kann ich damit kaum etwas anfangen außer grüne Icons sehen.
Bei Mozilla Observatory findest du zu jedem Test eine Beschreibung und auch Tipps, wie man das umsetzen kann. In Kombination mit einer Suchmaschine findest du dann auch explizite Hinweise bzw. Code-Snippets für Webserver wie Apache, nginx etc. – Du solltest dabei aber wissen was du tust oder jemand mit der Umsetzung beauftragen.
Eventuell werde ich in einem weiteren Beitrag auf ein paar Einstellungen eingehen.
Kudos! Toller Beitrag!
Datenschutz und Sicherheit gehen bekanntlich fließend ineinander über. Vielleicht kann diese gute Liste auch noch um die eine oder andere Webseite ergänzt werden die hier aufgelistet werden: https://geekflare.com/online-scan-website-security-vulnerabilities/
Besten Dank für die Links. Hatte schon vorher einiges ausprobiert und dachte ich wäre beim Testprojekt gut aufgestellt.
Allerdings zeigt mir observatory an, dass ich kein HSTS habe, obwohl es bei All Inkl aktiviert ist. ssllabs sagt dagegen es ist alles ok.
Was stimmt denn nun?