Zum Content

Website Security -
Tipps für mehr Schutz

Geben Sie Hackern keine Chance. Website- und IT-Security ist aus mehreren Gründen alternativlos. Einerseits verpflichten uns Gesetze, die Daten unserer Website-Nutzer zu schützen. Andererseits gilt es, geschäftliche Prozesse vor Unterbrechungen oder Manipulationen zu schützen und Imageschaden abzuwehren. Je nachdem, welcher Stellenwert der Sicherheit einer Website eingeräumt ist, sind dafür viel Know-how und einiger Arbeitsaufwand notwendig.

Tom

Alles beginnt bei einem sauberen Code!

Claudia

Auch an SSL gedacht?

Rudi

Sogar die Security-Headers sind gesetzt!

66%
Angegriffene Unternehmen pro Jahr
13%
Website-Rating A bei Security Headers
20
Zeichen für ein sicheres Passwort
1
Hackangriff reicht für schwere Strafen nach DSGVO

Website-Sicherheit zum Thema machen

Sicherheit ist relativ. Mit genügend kriminellem und finanziellem Aufwand, kann jedes System gehackt werden. Das passiert auch den größten Konzernen und Internetgiganten. Ein hoher Sorgfaltsmaßstab ist aber Pflicht. Es gibt nicht „sichere“ und „unsichere“ Websites, sondern sehr viele Ausprägungen dazwischen.

Website-Security gehört zu den sogenannten nicht-funktionalen Anforderungen an ein Projekt. Eine Website kann zu 100 % funktionieren, aber dennoch sehr unsicher sein. Zu den nicht-funktionalen Anforderungen zählen beispielsweise auch die Website-Geschwindigkeit, die Barrierefreiheit oder die Datenschutzmaßnahmen.

Ziele von Web-Security sind in der Regel die Themen Verfügbarkeit, Integrität und Vertraulichkeit. User:innen sollen sicher durch das Web surfen können. Datendiebstahl, betrügerische oder verstörende Inhalte sollen vermieden werden. Gängige Web-Bedrohungsszenarien sind:

  • Web-Angriff: Jemand kontrolliert eine Domäne im Web und es entsteht ein Angriffsvektor, sobald jemand diese Domäne besucht.
  • Netzwerkangriff: Passive Beobachtung des Datenverkehrs mit einer Website oder aktiver Eingriff auf Netzwerkebene.
  • Malwareangriff: Ziel ist, durch schadhaften Code oder das Ausnützen einer Sicherheitslücke aus dem Browser „auszubrechen“ und das dahinterliegende System zu schädigen.

Nur weil man Sicherheit nicht „sieht“, sollte man sie nicht blind voraussetzen. Manche Dienstleister kümmern sich wegen Unwissenheit nicht um das Thema, bei anderen kann der Preisdruck die Ursache sein. In preissensiblen Angeboten werden nicht-funktionale Anforderungen als Erste auf ein Minimum reduziert, um nicht zu teuer anbieten zu müssen. Diesem Problem entkommt man durch die Definition eines dem Projekt angemessenen Sicherheitslevels im Lastenheft. Natürlich erhöht das die Investition zu Projektbeginn. Dennoch käme jedes noch so kleine Sicherheitsproblem in der Folge viel teurer.

Auch wir können nicht bei jedem Projekt „alles“ tun, was möglich wäre. Dennoch haben wir ein sehr solides Grundsetup für gängige Anforderungen und evaluieren spezielle Gefährdungssituationen zu Projektbeginn.

Sichere Programmierung

Das Hauptargument, warum man eine Website nicht einfach im Nachhinein „sicher“ machen kann, ist die Programmierung. Fehler, die hier gemacht werden (besonders in der Grundarchitektur), sind im Nachhinein kaum oder nur mit großem Aufwand zu beheben. Deshalb orientiert sich unser Entwicklungsteam an sogenannten Secure Coding Guidelines. Diese basieren auf dem OWASP Secure Coding Practices Quick Reference Guide und der ÖNORM A 7700 (A7700) “Sicherheitstechnische Anforderungen an Webapplikationen”. Einige Beispiele für Design-Prinzipien sicherer Webanwendungen wären:

  • Minimierung von Angriffsflächen: Bei Dateneingaben durch User:innen gehen wir immer davon aus, dass diese schädliche Elemente beinhalten könnten.
  • Security by Default: Standardeinstellungen sind immer sichere Einstellungen.
  • Least-Priviledge-Prinzip: Wir vergeben User:innen nur die jeweils mindestens erforderlichen Zugriffsrechte.
  • Defense-in-Depth: Wir verlassen und nicht auf eine Maßnahme, sondern bauen je nach Risiko nach dem Zwiebelschalenprinzip redundante Schutzmaßnahmen auf.
  • Resilienz: Wir sehen Mechanismen vor, die beim Auftreten von Fehlern unterstützen.
  • KISS: Keep it simple, stupid – einfach ist besser als kompliziert.

Während wir bei von uns geschriebenen Codes die Sicherheit gewährleisten können, beinhaltet der Einsatz von Drittanbietermodulen immer ein Risiko. Hier wissen wir in der Regel nichts über die Code-Qualität. Eine sorgfältige Überprüfung übersteigt oft den Aufwand einer sauberen Eigenentwicklung. In jedem Fall ist der vermeintliche Kostenvorteil von Gratismodulen bei hohem Anspruch an Sicherheit und Performance eine Illusion.

Bei Open-Source-Projekten wie WordPress, TYPO3 oder Magento gibt es Anbieter, die nach dem Motto "wird schon nichts passieren" ungeprüfte Drittanbietermodule kostengünstig einbauen. Wir können und wollen da nicht mit. Entweder wir kennen ein Modul oder wir müssen es genau prüfen. Oder im besten Fall die Funktionalität selbst entwickeln.

Der billigste Bieter sind wir mit dieser Vorgehensweise nicht. Bestbieter aber vielleicht schon.

Regelmäßige Software-Updates

Software ist wie ein Garten. Einmal nicht Gießen macht nicht viel. Lässt man aber einige Gießdurchgänge aus, muss er neu bepflanzt werden.

Mit Softwareupdates verhält es sich ähnlich. Jede gute Software wird laufend weiterentwickelt. Sie erhält neue Features, es werden Sicherheitslücken geschlossen und sie wird an neue Anwendungsbedingungen (z.B. Browser) angepasst.

Für die von uns eingesetzte Software erscheinen immer wieder Updates. Diese lassen sich in die zwei Gattungen unterteilen:

  1. Sicherheits-Patches (auch Sicherheits-Updates)
  2. Versionssprünge (Versionsupdates)

Erstere sind für den sicheren Betrieb Ihres Projekts unbedingt erforderlich. Letztere müssen nicht immer sofort eingespielt werden, irgendwann läuft aber der Support für alte Versionen aus (End of Life). Spätestens dann muss das Upgrade erfolgen - siehe das Gartenbeispiel am Beginn dieses Absatzes.

Dies gilt sowohl für die Programmiersprache (z.B. PHP) als auch für die Software-Applikation (z.B. WordPress).

Hier finden Sie offizielle Roadmaps und Informationen über Lebenszyklen für von uns häufig eingesetzte Software/Programmiersprachen:

Verschlüsselte Datenübertragung über HTTPS

Der Aufruf von Inhalten im Browser erfolgt im Regelfall über eines dieser beiden Kommunikations-Protokolle:

  1. HTTP (Hypertext Transport Protocol)
  2. HTTPS (Hypertext Transport Protocol Secure oder auch HTTP over TLS)

Heutzutage sollte ausschließlich HTTPS verwendet werden. Bei HTTPS findet vor der eigentlichen Kommunikation eine Authentifizierung statt. Dabei prüfen beiden „Gesprächspartner“ gegenseitig ihre Identität. Die zu schickenden Daten werden verschlüsselt, wodurch die Übertragung als abhörsicher gilt.

Daten, die hingegen über HTTP übertragen werden, sind unter bestimmten Grundvoraussetzungen für jeden als Klartext lesbar.

SSL steht für Secure Sockets Layer und ist die veraltete Bezeichnung für ein Verschlüsselungsprotokoll zur sicheren Datenübertragung im Internet. TLS steht für Transport Layer Security und ist der Nachfolge-Begriff für SSL.

Wir verwenden bei unseren Projekten ausschließlich HTTPS. Dazu ist der Ankauf eines Zertifikats mit geringen jährlichen Gebühren notwendig. Wichtig ist in weiterer Folge noch die korrekte Serverkonfiguration des SSL-Zertifikats. Diese ist in der Regel Sache des Hosting-Providers.

Unter https://www.ssllabs.com/ssltest/ können Sie die SSL-Sicherheit auf Ihrer Website sofort kostenlos testen.

Typen von SSL-Zertifikaten

Es gibt Einzel-Zertifikate, Inhaber-Zertifikate mit der Sonderform des Wildcard-Zertifikats und Enterprise Verification Zertifikate. Wir beraten Sie bei der Auswahl der richtigen Lösung für Ihr Projekt:

Übersicht über unterschiedliche SSL-Zertifikate
 Einzel-
Zertifikat
Inhaber-
Zertifikat
Inhaber-
Zertifikat mit
Wildcard
Enterprise
Verification
Zertifikat
Kosten [EUR]-
unterer 2-stelliger Bereich
+
Einzel x 5
+++
Inhaber x 3
++
Inhaber x 2,5
Anzahl Subdomains11unbegrenzt1
Datenverschlüsselung bei Übertragungjajajaja
Prüfung der Inhaberdatenneinjajaja, erweitert
Höhe Versicherungsschutz [USD]0250.000250.000500.000
Anzeige Site Seal erlaubtneinjajaja

Der einzige funktionale Unterschied des Wildcard-Zertifikats gegenüber dem Inhaber-Zertifikat ist, dass es nicht auf einen bestimmten Hostnamen beschränkt ist (also z.B. www.limesoda.com/blog), sondern es alle Subdomains zu einer Domain umfasst (also z.B. www.limesoda.com, blog.limesoda.com, …). I.d.R ist ein Wildcard-Zertifikat preislich ab 3 unterschiedlichen Domains günstiger als einzelne Inhaber-Zertifikate.

Site Seals sind kleine grafische Elemente, die meist im Footer der Webauftritte platziert sind und nochmals auf die Verschlüsselung der Seite hinweisen. Beim Klicken öffnet sich ein Fenster mit weiteren Details zum Zertifikat.

Es gibt auch kostenlose SSL-Zertifikate. Deren Qualitätsstandards können allerdings nicht mit denen kostenpflichtiger Anbieter mithalten. Wir empfehlen die Investition in ein kostenpflichtiges Angebot.

HTTP Security-Headers

Die sogenannten „HTTP Security Headers“ setzen sich aus einer Reihe von Schutzmaßnahmen zusammen. Sie dienen dazu, die Angriffsflächen für Cross-Site-Scripting (XSS), Code injections, MIME-type sniffing, Clickjacking („UI redress attack“), u.v.m. zu minimieren.

Hierfür werden spezifische HTTP-Antwort-Headerfelder eingesetzt, die dem Browser bei jedem Seitenaufruf Anweisungen geben, wie er mit bestimmten Daten umgehen soll bzw. wie er sich dabei zu verhalten hat.

Der Einsatz von Security Headers sollte bereits vor einem Website-Livegang geplant und in der Entwicklungsphase laufend getestet werden. Eine nachträgliche Implementierung ist ebenfalls möglich. Der Aufwand ist abhängig von Umfang des Webshops bzw. der Website und der Striktheit der Anforderungen.

Mit Scannern wie securityheaders.io können Sie Ihre Seite überprüfen und Maßnahmen planen.

Die HTTPS Security-Headers im Überblick

Dieser Header dient als Schutz vor Cross-Site-Scripting (XSS) und ist unter Umständen der anspruchsvollste, wenn es um die Konfiguration geht. Hierfür müssen nämlich alle potenziell geladenen Inhalte (z.B. Bilder, JavaScripts, etc.) über das manuelle Setzen auf eine sogenannte „Allow List“ erlaubt werden. Dies gilt auch bei künftigen Erweiterungen der Seite.

In diesem Header kann gesteuert bzw. eingeschränkt werden, wie viele Informationen eine extern aufgerufene Seite im sogenannten „Referrer-Header“ mitbekommt. Der Referrer verrät der nachfolgenden Seite, von welcher Website/URL man kommt. Man kann also z.B. verhindern, dass eine unsichere Seite sensible Daten, wie eine URL, mit gewissen Parametern in diesem Feld übergeben bekommt.

Mit der richtigen Einstellung dieses Headers kann man verbergen, welche Software auf dem Server verwendet wird bzw. welche Versionsnummer diese hat. Dies erhöht die Sicherheit, da ein potenzieller Angreifer keinen Einblick auf diese Details hat.

Dieser Header dient dazu, das Verwenden von TLS/HTTPS zu erzwingen und verstärkt die Sicherheit um ein Vielfaches, da alle übertragenen Daten clientseitig über eine sichere Transportebene transportiert werden. Zusätzlich erhöht er auch die Geschwindigkeit des Seitenaufrufs, da nicht geprüft werden muss, welches Protokoll zum Einsatz kommt.

Mit diesem Header kann man steuern, ob die Website in einem Frame geladen werden darf oder nicht. Dadurch kann ein sogenanntes „Clickjacking“, eine perfide Methode um die Maus/Tastatureingaben zu missbrauchen, verhindert werden.

Der besagte Header wird verwendet, um die eingebaute XSS-Schutzfunktion in den Browsern Internet Explorer, Chrome und Safari zu konfigurieren. Es handelt sich hier um eine Art „Fallback“ für ältere Browser, die den CSP-Header (siehe oben) noch nicht unterstützen. Für moderne Browser ist dieser Header weitestgehend uninteressant.

Die Aktivierung dieses Headers verhindert „MIME sniffing“, sprich das Verändern oder Manipulieren eines fix angegebenen Inhaltstypen bei der Ausgabe in Browsern, wie Google Chrome.

Durch diese Einstellung kann das Verhalten von APIs (Schnittstellen) und Browserfunktionen gesteuert und somit auch gezielt eingeschränkt werden. Das Ganze ist vergleichbar mit der Content Security Policy, da man hier laufend zur Entwicklung eine abgestimmte "Allow-List" der benötigten Funktionen definiert.

Sicheres Webhosting

Die Webapplikation kann noch so sicher programmiert sein: wenn die Serversoftware (z.B. LAMP, NGINX) nicht auf dem letzten Stand ist, sind Hackangriffe möglich. Bei den von uns verwendeten Managed-Hosting-Paketen ist dafür der Hosting-Provider zuständig.

Ebenso wichtig sind regelmäßige, rollierende Backups, die bei Problemen schnell eingespielt werden können.

Firewalls sorgen ebenfalls für die Abwehr von Hackangriffen. Das Risiko für bei hochverfügbaren Systemen gefürchteten Distributed-Denial-of-Service (DDoS) Attacken kann von guten Providern reduziert werden. Bei DDoS-Attacken greift eine Vielzahl unterschiedlicher, gehackter Computer gezielt eine Website an und bringt sie durch zu viele gleichzeitige Zugriffe offline.

Gutes Hosting hat seinen Preis. Mit Paketen im einstelligen Eurobereich pro Monat darf man kein gemanagtes, sicheres System mit Backups erwarten, das gleichzeitig auch uns als Digitalagentur die notwendigen Zugriffsmöglichkeiten bietet. Wir beraten Sie bei der Auswahl des richtigen Hostingpartners.

Sichere Passwörter und Admin-Zugänge

Leider erleben wir immer wieder, wie exzellente Sicherheitsmaßnahmen durch menschliches Versagen in Form unsicherer Passwörter zunichtegemacht werden.

Passwörter müssen möglichst lang, pro Zugang einzigartig und nicht auf Basis persönlicher Daten zusammengestellt sein. Jede Person braucht ein eigenes und darf es nicht weitergeben. Ein Passwort-Manager hilft.

Wenn es Ihre IT-Systeme erlauben, können wir den Admin-Zugang auf Ihre IP-Adresse sperren. Damit läuft ein sehr großer Teil gängiger Angriffssignaturen ins Leere. Unsere Passwörter werden professionell verwaltet und der Zugriff darauf geloggt. Wir beraten Sie gerne bei der Planung Ihrer Sicherheitsmaßnahmen und Berechtigungskonzepte.

Penetrationstests geben Sicherheit

Die Sicherheit von kritischen IT-Systemen kann durch Sicherheitstests überprüft werden. Diese werden Penetrationstests oder kurz Pentests genannt. Dabei werden Angriffe sowohl ohne Detailkenntnis (Blackbox-Test) als auch mit Wissen über Interna des Systems (Whitebox-Test) durchgeführt. Ziele sind das Auslesen von Informationen und das Eindringen in das System. Sollen sensible Daten oder Systeme besonders geschützt werden, empfiehlt sich jedenfalls die regelmäßige Durchführung von Pentests. Von uns entwickelte Seiten haben schon viele Penetrationstests überstanden, die selbstverständlich von unabhängigen, externen Prüfstellen durchgeführt werden. Sicherheitslücken können leicht entstehen, wichtig ist nur, sie zu bemerken und zu schließen. Deshalb lassen sogar Pentest-Anbieter ihre eigenen Websites von uns bauen :-)

Know-how und Weiterbildung

Wissen ist die beste Waffe zur Abwehr von Angriffen. Wir bilden uns laufend weiter, verwenden Checklisten, Guidelines und entwickeln automatisierte Tests zur Sicherung der Qualität und Erhöhung der Sicherheit. Maßnahmen müssen laufend evaluiert und weiterentwickelt werden. Mit unserem Team haben Sie auf diesem Gebiet einen verlässlichen Partner!

Unsere Zertifizierungen für Ihre Sicherheit

Übrigens: Wir arbeiten nach den Vorgaben der ISO 27001 (sind aber noch nicht zertifiziert).

Kundenfeedback

Als führende Berater in Cyber- und Applikationssicherheit ist uns die Sicherheit unserer eigenen Website besonders wichtig. Mit LIMESODA haben wir einen Partner, bei dem neben Kreativität und Technik auch Website-Sicherheit ganz oben am Tapet steht.
Magdalena Jünger, Head of Marketing SEC Consult
Großes Kompliment an euer Team und die Agentur, wir haben uns sehr gut betreut gefühlt in dem ganzen Prozess! Vielen DANK!
Mag. Karin Schneck, Bakk. phil, Communication Manager, Kraus & Naimer