Dieser Blogpost ist ursprünglich im LimeSoda Blog erschienen, ist dort aber nicht mehr verfügbar. Eine Kopie des Beitrages befindet sich deshalb hier.
Vor kurzem war eine Vielzahl an Web-Anwendungen von einem Sicherheitsfehler in OpenSSL („Heartbleed“) betroffen. Nachdem mittlerweile viele Webhosting-Provider und Webseitenbetreiber die OpenSSL Installationen aktualisiert haben, sowie Zertifikate getauscht und ihre Benutzer um Passwortwechsel aufgerufen haben, bleibt die Frage: Wie sicher sind Web-Anwendungen?
Eine dynamische Web-Anwendung besteht aus mehreren Teilen:
Auf einem physischen oder virtuellen Server laufen – je nach Hosting-Variante – eine oder mehrere Websites. Diese werden von einem Web-Server, der die Anfragen aus dem Internet entgegen nimmt, verarbeitet. Um eine Webseite auszuliefern, sind meist Anfragen an den Datenbankserver notwendig, außerdem wird dazu der Quellcode der Web-Anwendung (z.B. eine Skriptsprache wie PHP, ausgeführt). Ist die Webseite ausgeliefert, können auf dem Gerät des Benutzers client-seitig, z.B. über JavaScript, noch weitere Aktionen ausgeführt werden. Je nach Größe und Konfiguration der Web-Anwendung kommen noch weitere Komponenten zur Verarbeitung der Anfragen hinzu: Schnittstellen, Proxy-Server, Caching- und Performance Module etc.
All diese Bestandteile bedienen sich unterschiedlichen Komponenten (Frameworks, Erweiterungen,…) um die gewünschten Anfragen entsprechend abzuarbeiten. Es ist also notwendig, nicht nur die Web-Anwendung selbst, sondern auch die Gesamtheit dieses Systems zu betrachten, um eine Web-Anwendung sicher zu gestalten.
Diese Risiken für Web-Anwendungen werden regelmäßig vom Open Web Application Security Project (OWASP) herausgegeben. OWASP ist eine Community mit dem Ziel, Unternehmen und Organisationen bei Entwicklung, Kauf und Wartung zu unterstützen. Zuletzt wurden die Risiken 2013 ermittelt und veröffentlicht.
1. Injection
Durch das Einschleusen von Code oder Kommandos kann ein Angreifer die Eingabe manipulieren, und auf diese Weise unerlaubte Befehle in der Web-Anwendung oder dem zugrunde liegenden System ausführen oder, auf nicht für ihn bestimmte, Daten zugreifen.
2. Fehler in Authentisierung und Session-Management
Unzureichende Mechanismen, die die Authentizität eines Benutzers und seiner zugehörigen Sitzung feststellen sollen, ermöglichen es Angreifern, Passwörter, Schlüssel oder die gesamte Sitzung eines Benutzers zu übernehmen und unter dessen Identität Aktionen auszuführen.
3. Cross-Site Scripting (XSS)
XSS bezeichnet das entgegennehmen und ausliefern von nicht validierten Eingaben an den Browser. Ein Angreifer kann auf diese Weise Schadcode im Browser des Benutzers ausführen.
4. Unsichere direkte Objektreferenzen
Durch mangelnde Überprüfung von Objektreferenzen ist es einem Angreifer möglich, unautorisiert auf nicht für ihn bestimmte Daten Zugriff zu erlangen.
5. Sicherheitsrelevante Fehlkonfiguration
Verschiedene Bestandteile, auf denen eine Web-Anwendung aufbaut (Module, Frameworks, Anwendungen, Erweiterungen), sind meist nicht mit einer sicheren Grundkonfiguration ausgestattet. Diese Bestandteile müssen, um dauerhaft eine sichere Nutzung zu gewährleisten, entsprechend konfiguriert und regelmäßig aktualisiert werden.
6. Verlust der Vertraulichkeit sensibler Daten
Sensible Daten sind während der Verarbeitung oder bei dauerhafter Speicherung nicht ausreichend geschützt (z.B. durch Verschlüsselung). Angreifer können die Daten somit leicht stehlen oder verändern.
7. Fehlerhafte Autorisierung auf Anwendungsebene
Viele Web-Anwendungen überprüfen die Rechte eines Benutzers, bevor sie ihm spezielle Funktionen zur Verfügung stellen. Ebenso wichtig ist es, auch serverseitig bei der Ausführung einer Aktion, diese Rechte nochmals zu überprüfen.
8. Cross-Site Request Forgery (CSRF/XSRF)
Mit der Identität des Benutzers werden – durch manipulierte Webseiten und Links – unbeabsichtigt und unbemerkt Aktionen auf anderen Webseiten ausgeführt. Die Identität eines Benutzers wird somit ausgenutzt, um mit dessen Rechten zusätzliche Anfragen auszuführen.
9. Benutzen von Komponenten mit bekannten Schwachstellen
Programme, Module und andere Komponenten laufen – meist aus dem Grund der einfachen Einrichtung – mit vollen Rechten auf einem Server. Wird eine Schwachstelle einer Komponente ausgenutzt, können auf diesem Weg viele weitere Angriffe über andere Komponenten ermöglicht werden.
10. Ungeprüfte Um- und Weiterleitungen
Webseiten leiten ihre Benutzer oft auf andere interne oder externe Webseiten um. Ist keine oder eine unzureichende Überprüfung der Weiterleitungen vorhanden, können Angreifer den Benutzer auf Phishing-Seiten oder Seiten mit Schadcode umleiten.
Schon während der Entwicklung (“Programmierung”) achten wir darauf, die Einfallstore für die verschiedenen Angriffe zu minimieren. Abgesehen von diesen Maßnahmen, empfehlen wir auch folgende Punkte:
Aktuell halten
- Aktualisieren Sie regelmäßig ihr CMS- oder Shopsystem auf die neueste, verfügbare Version.
- Bleiben Sie auf dem letzten Stand: Informieren Sie sich, fragen Sie die Agentur ihres Vertrauens 🙂
Passwörter & Benutzeraccounts
- Ändern Sie ihre Passwörter regelmäßig (ggf. unter Verwendung eines Passwort-Managers wie KeePass)
- Geben Sie den Benutzern ihrer Webseite Richtlinien zur Gestaltung sicherer Passwörter vor.
- Verwenden Sie nicht die Standard-Benutzer des CMS/Shop-Systems (“admin”). Löschen Sie diese (wenn möglich) oder benennen Sie diesen um.
- Begrenzen Sie die Anzahl fehlgeschlagener Login-Versuche auf Ihrer Seite (und senden Sie evtl. dem Benutzer im Hintergrund ein Service-Mail, ob er seine Zugangsdaten vergessen hat).
Geben Sie nicht zu viel preis!
- Informationen in Fehlermeldungen geben oft nützliche Informationen für Angreifer. Generische Fehlermeldungen („Falscher Benutzername oder Passwort“) sind in diesem Fall besser, als spezielle („Falsches Passwort“), wenn auch nicht so benutzerfreundlich.
- Verbergen bzw. begrenzen Sie Informationen über die Web-Anwendung (Typ, Version,…)
- Verbergen bzw. begrenzen Sie Informationen über den Server: PHP-Version, Webserver, Datenbanksystem. Diese Informationen lassen sich mit speziellen Anweisungen verbergen, damit sie für die Besucher (und potentielle Angreifer) ihrer Webseite nicht ersichtlich sind.
Verwenden Sie SSL
Verschlüsseln Sie die Datenübertragung zwischen den Besuchern Ihrer Internetseite und Ihrem Server mit SSL.
Grundkonfiguration
- Die Grundkonfiguration von Anwendungen und Komponenten bietet die Möglichkeit, diese schnell in Betrieb nehmen zu können. Sicherheitsrelevante Einstellungen müssen oft erst nachträglich aktiviert werden.
- Ändern Sie Standard-Benutzer und Standard-Pfade der Web-Anwendung: /typo3, /admin, etc. oder begrenzen Sie den Zugriff (z.B. IP-basiert) auf diese Verzeichnisse
Erweiterungen
Vorsicht ist geboten: Jede Erweiterung bringt potentiell zusätzliche Schwachstellen/Fehler (nicht nur aus sicherheitstechnischer Sicht) mit sich. Nicht jede frei verfügbare, kostenlose Extension ist auch von einem guten Programmierer entwickelt worden (obwohl es umgekehrt unglaublich tolle, kostenfreie Erweiterungen von sehr guten Programmieren gibt!).
Auf dem Server
- Dateirechte: Dateien und Verzeichnisse mit allen Rechten (auf Unix-System „chmod 777“) kann potentiell jeder beliebig ausführen und ändern (sofern er Zugriff auf das System hat).
- Härten Sie ihre PHP Installation: Suhosin für PHP
Überwachen & loggen
Mit Monitoring und Logging lassen sich einige Angriffe ggf. frühzeitig erkennen. Die Logfiles liefern weitere Informationen, um Maßnahmen ergreifen zu können.
- Richten Sie ein Monitoring für ihre Webseite ein (z.B. mit UptimeRobot oder Icinga)
- Loggen Sie die Zugriffe
Trennen Sie sich von Altem
Löschen Sie…
- alte Installationsdateien und –verzeichnisse
- Testfiles
- Deaktivieren bzw. löschen Sie alte und nicht mehr benötigte Benutzeraccounts, (S)FTP- und SSH-Zugänge zu Ihrem Server.
Backup
Für den Fall der Fälle: Erstellen Sie regelmäßige Backups ihrer Web-Anwendung (Dateien, Verzeichnisse und Datenbanken).
Aufwendig (und teuer)
Viele der oben genannten Maßnahmen führen wir im Rahmen der Entwicklung unserer Web-Projekte standardmäßig bzw. in Rücksprache mit dem Kunden durch.
Einige Maßnahmen bedürfen allerdings zusätzlichem Konfigurationsaufwand oder der Unterstützung durch den Hosting-Provider.
Fragen Sie mich!
