Wenn Sie heute eine Website veröffentlichen, vergehen kaum ein paar Minuten, bis sie das erste Mal angegriffen werden. Diese Artikelserie beschäftigt sich mit den OWASP Top 10, den zehn meisten Sicherheitsrisiken, und gibt Tipps, wie sie sich und ihre Produkte schützen können.
Diese Serie besteht aus den folgenden Artikeln:
- Teil 1: Injection
- Teil 2: Fehler in Authentifizierung und Session-Management
- Teil 3: Cross-Site Scripting (XSS)
- Teil 4: Unsichere direkte Objektreferenzen
- Teil 5: Sicherheitsrelevante Fehlkonfiguration (dieser Artikel)
- Teil 6: Verlust der Vertraulichkeit sensibler Daten
- Teil 7: Fehlerhafte Autorisierung auf Anwendungsebene
- Teil 8: Cross-Site Request Forgery (CSRF)
- Teil 9: Nutzung von Komponenten mit bekannten Schwachstellen
- Teil 10: Ungeprüfte Um- und Weiterleitungen
Sicherheitsrelevante Fehlkonfiguration
Auf Platz 5 der OWASP Top 10 ist die sicherheitsrelevante Fehlkonfiguration. Durch eine solche Fehlkonfiguration kann ein Angreifer Zugriff auf heikle Ressourcen erlangen. Dazu gehören Logfiles und interne Fehlermeldungen, letztere teilweise sogar inklusive Stacktrace und Quellcode. Auch eine nicht gesicherte Konfigurations- oder Administrationsseite kann dazugehören.
Durch den Zugriff auf solche heiklen Ressourcen kann ein Angreifer Informationen erhalten, die ihm Hinweise auf weitere Sicherheitsrisiken geben. Eine einfache Suchmaschinensuche genügt um öffentliche Logfiles zu finden, die sogar Sessioncookies enthalten. Dadurch kann man sehr einfach eine fremde Session übernehmen.
Eine sicherheitsrelevante Fehlkonfiguration betrifft nicht nur den eigenen Quellcode. Es geht um sämtliche Software, die auf dem betreffenden System läuft. Dazu gehören das Betriebssystem, der Application Server sowie allfällige Datenbankmanagementsysteme. Bei der eigenen Software betrifft es zusätzlich alle Bibliotheken, die verwendet werden.
Aus der .NET Welt gibt es zwei prominente Beispiele von sicherheitsrelevanten Fehlkonfigurationen, beide betreffen das Logging. Jeder ASP.NET Webanwendung bietet die Möglichkeit, Trace Informationen auf einer separaten Seite darzustellen, der trace.axd. Unglücklicherweise ist diese Einstellung standardmässig aktiv. Diese Seite listet sämtliche Zugriffe auf die Webanwendung auf, inklusive Cookies.
Das zweite Beispiel betrifft die Bibliothek ELMAH. Sie bietet verschiedene Arten von Logging, lässt sich einfach in bestehende Anwendungen integrieren und ist daher äusserst beliebt. Dadurch gibt es auch sehr viele Webanwendungen, die ELMAH einsetzen. Ist diese Komponente falsch konfiguriert, ist die Seite elmah.axd ebenfalls öffentlich zugänglich, mit den gleichen Sicherheitsproblemen.
Weitere sicherheitsrelevante Fehlkonfigurationen sind Features, die nicht benötigt aber dennoch aktiv sind. Dazu gehören Betriebssystemdienste, offene Ports, Standardaccounts mit Standardpasswörtern sowie nicht benötigte Berechtigungen.
Stellen Sie also sicher, dass auf ihrem produktiven System keine Dienste aktiv sind, die gar nicht benötigt werden. Nutzen Sie keine Standardaccounts und schliessen Sie nicht benötigte Ports. Halten Sie sich an das Prinzip der tiefsten Berechtigung und geben Sie Ihren benötigten Accounts nur diejenigen Berechtigungen, die sie brauchen. Wählen Sie sichere Passwörter und halten Sie sie geheim. Gerade Passwörter, die fix im Quellcode oder der Konfigurationsdatei hinterlegt sind, stellen hier ein Risiko dar.
Wenn Sie eine ASP.NET Anwendung betreiben, deaktivieren Sie den Yellow Screen of Death, Tracing sowie ELMAH. ELMAH können Sie so konfigurieren, dass nur angemeldete Benutzer Zugriff haben.
Da auch Fremdbibliotheken hin und wieder Sicherheitsprobleme aufweisen, nutzen Sie immer die neusten Versionen. Am einfachsten ist das mit dem Einsatz einer Packetverwaltung wie beispielsweise NuGet.
Manche sicherheitsrelevanten Fehlkonfigurationen können durch automatisierte Tests gefunden werden. Nutzen Sie daher solche Dienstleistungen.
Ist Ihre Anwendung sicher? Nebst der in diesem Blog beschriebenen Möglichkeiten gibt es viele weitere Strategien, sich gegen Angreifer zu verteidigen. Gerne beraten wir Sie in Sicherheitsfragen oder führen ein Security Review in Ihrem Projekt durch. Kontaktieren Sie mich dazu per E-Mail oder rufen Sie mich unverbindlich an, um Ihre dringlichsten Fragen zu besprechen.
Dieser Beitrag erschien zuerst auf michaelschuler.ch
