Open Web Application Security Project (OWASP) ist eine gemeinnützige Organisation, die unter anderem Methodologien, Werkzeuge und weitere Informationen in Bezug auf Web-Applikationssicherheit anbietet.
Sie besteht aus Sicherheitsexperten aus der ganzen Welt, deren Ziel es ist, das Bewusstsein für Applikationssicherheit zu steigern. Die Zielgruppe sind Benutzer, Entwickler, aber auch Sicherheitsexperten selbst.
Das bekannteste Werk sind die OWASP Top 10, das in einer regelmäßig aktualisierten Version die zehn kritischsten Sicherheitsrisiken für Web-Applikationen widerspiegelt. Am 20. November 2017 wurde die aktualisierte, finale Fassung des Dokuments veröffentlicht, das somit die OWASP Top 10 2013 ablöst.
Das Open Web Application Security Project behandelt unter anderem auch Themengebiete wie die Sicherheit von mobilen Anwendungen, für die 2016 eine eigene OWASP Top 10 Liste veröffentlicht worden ist.
Auditoren stützen sich oft auf dieses wertvolle Dokument, deshalb wollen wir in diesem Artikel kurz die wichtigsten Punkte behandeln.
Die OWASP Top 10 bieten für die behandelten Themen Hinweise, wie man überprüfen kann, ob eine Applikation von der Schwachstelle betroffen ist, praktische Beispiele für die Verhinderung dieser sowie weiterführende Referenzen.
OWASP Top 10 2017
Die folgende Grafik zeigt eine Übersicht der OWASP Top 10 2017 im direkten Vergleich zu dem Vorgängerdokument aus dem Jahr 2013.
A1 – Injection
Die Kategorie „Injection“ beschreibt Schwachstellen, die das Einschleusen von Code ermöglichen. Diese Schwachstellen können auftreten, wenn eine Web-Applikation benutzerdefinierte Daten ungefiltert weiterverarbeitet.
Beispielsweise ist eine SQL-Injection möglich, wenn für eine Suchanfrage die Benutzereingabe direkt für eine Datenbankabfrage verwendet wird. Solche Injection-Angriffe betreffen jedoch nicht nur SQL, auch lassen sich diese Attacken für beliebig andere Interpreter anwenden. Der schadhafte Code kann über HTTP Header, Cookies, Parameter oder andere Vektoren eingeschleust werden.
Abhilfe dagegen schafft im Normalfall die Validierung der Benutzereingaben. Ein Whitelisting-Ansatz, also eine Definition erlaubter Daten, wird dabei als Problemlösung empfohlen. Sämtliche Daten, die dieser Definition nicht entsprechen, dürfen von der Anwendung nicht akzeptiert werden. Im Idealfall sollten jedoch Prepared Statements (parametrisierten Abfragen) verwendet werden. Hierbei werden die Benutzerdaten klar von den Befehlen getrennt, womit keine Code Injection mehr möglich ist.
Zum Thema SQL-Injection erwartet Sie in naher Zukunft ein eigener Artikel auf unserem Blog.
A2 – Broken Authentication
Unter diese Rubrik fallen alle Schwachstellen, in denen es um die Authentifizierung an der Web-Applikation geht. Oft betreffen Probleme in dieser Kategorie die Sitzungs-ID von Benutzern. Beispielsweise spricht man von einer Session Fixation, wenn die Sitzungs-ID nach der erfolgreichen Anmeldung nicht neu vergeben wird. Häufig kommt es auch vor, dass sitzungsrelevante Informationen ungeschützt als URL-Parameter übertragen werden. Eine andere „Broken Authentication“-Schwachstelle ist, wenn die Abmeldefunktion der Applikation nur die Sitzungsinformationen am Client, aber nicht am Server löscht.
Die inkorrekte Handhabung von Anmeldeversuchen ist ebenso Teil dieser Kategorie. Ist die Anmeldung fehlerhaft gestaltet, können unter Umständen valide Benutzer identifiziert werden oder Bruteforce-Angriffe durchgeführt werden.
Es ist essentiell, dass Sitzungsinformationen vertraulich behandelt werden, die Sitzungs-ID nach erfolgreicher Anmeldung neu vergeben wird und nach der Abmeldung auch am Server invalidiert wird.
A3 – Sensitive Data Exposure
Von Sensitive Data Exposure spricht man beispielsweise, wenn keine Verschlüsselung für die Kommunikation (z. B. HTTP, FTP, SMTP) eingesetzt wird, oder die Verschlüsselung von gespeicherten, sensiblen Daten unzureichend ist: Ein häufiges Problem, welches auch Sensitive Data Exposure betrifft, von Seiten mit sensiblen Informationen, die im Clientbrowser zwischengespeichert werden können.
Unter diese Kategorie fallen auch detaillierte Fehlermeldungen, wie Stack Traces, die dem Benutzer im Fehlerfall oder bei unerwarteten Eingaben angezeigt werden. Eine robuste Applikation sollte nicht mit detaillierten Meldung antworten, sondern generische Fehlerseiten präsentieren. Die Details zu den Vorfällen sollten am Server gespeichert werden, um zu verhindern, dass ein Angreifer weitere wertvolle Informationen zu der Applikation sammeln kann.
Um Sensitive Data Exposure zu vermeiden, ist für Web-Applikationen eine zeitgemäße TLS-Konfiguration essentiell, hierfür können Sie unseren Blogeintrag konsultieren. Auch für die sichere Speicherung von sensiblen Daten haben wir einen Blogartikel parat.
A4 – XML External Entities (XXE)
Diese neu eingeführte Kategorie beschäftigt sich mit auf Extensible Markup Language (XML) basierender Kommunikation.
XML External Entities treten häufig auf, wenn XML-basierte Daten für die Weiterverarbeitung vom Benutzer definiert werden können. Mit aktivierten Document Type Definitions (DTDs) ist es möglich, lokale Daten des Servers auszulesen oder externe, vom Angreifer kontrollierte Daten einzubinden.
Im Zusammenhang mit dieser Schwachstelle ergibt sich oft auch eine Denial of Service (DoS)-Schwachstelle.
Generell wird zur Verwendung von simpleren Formaten wie JSON geraten. Für XML sollte DTD deaktiviert werden und die XML-Prozessoren und Bibliotheken müssen aktuell sein, um eventuelle Schwachstellen zu beheben. Wie auch bei anderen Schwachstellen, zum Beispiel „A1 – Injection“, ist ein Whitelisting-Ansatz für erlaubte Benutzerdaten anzuraten.
Weitere Informationen zu dem Thema finden Sie in unserem Blog „XXE: Angriff über ein Serialisierungsformat“.
A5 – Broken Access Control
Die alten Kategorien “Insecure Direct Object Reference” und “Missing Function Level Access Control” wurden zu „Broken Access Control” zusammengefasst. Diese beinhaltet jegliche Probleme mit der Autorisierungsprüfung.
Wenn ein Benutzer beispielsweise Zugriff auf Ressourcen durch Manipulation der URL erlangt, wurde das der Kategorie “Insecure Direct Object Reference” zugeordnet. Wenn durch diesen Zugriff jedoch Funktionen aufgerufen werden können, für die der Benutzer keine Autorisierung hat, wird die Zuordnung schwierig, da die Schwachstelle zu “Insecure Direct Object Reference“, aber auch zu “Missing Function Level Access Control” gehört.
Ist es für Benutzer ohne entsprechende Rechte möglich, Funktionen (z. B. administrative Tätigkeiten) aufzurufen, spricht man eindeutig von “Missing Function Level Access Control”.
Durch die kombinierte Kategorie ist die Zuordnung leichter und klarer.
Unsichere Einstellung von Cross-Origin Resource Sharing (CORS) sowie unzureichend geschützte API-Zugriffe fallen ebenso in diese Schwachstellenbeschreibung.
Zu dem Thema CORS erwartet Sie ein eigener Artikel auf unserem Blog.
A6 – Security Misconfiguration
Security Misconfiguration ist sehr weitläufig und fast beliebig ausweitbar. In Bezug auf Web-Applikationen betrifft das hauptsächlich die fehlerhafte Konfiguration von sicherheitsrelevanten Web-Server Headern. Diese Header sind dafür zuständig, dass beispielsweise das Framing der Web-Applikation und die Content-Sniffing-Funktion des Internet Explorers unterbunden wird oder browserseitige XSS-Filter aktiviert werden. Für TLS gesicherte Web-Applikationen ist der HTTP Strict Transport Security (HSTS)-Header essentiell. Cookie Attribute wie „Secure“ und „HTTPOnly“ sind gleichermaßen Sicherheitsrelevant.
Zu “Security Misconfiguration” gehören auch unsichere Einstellungen für Applikationsframeworks, wodurch diese Kategorie auch nahe in Verbindung mit der Kategorie „A9 – Using Components with Known Vulnerabilities“ steht.
Weiterläufig können auch fehlende Härtungsmaßnahmen auf der Serverseite inkludiert werden. Grundinformationen hierzu finden sich in unserer zweiteiligen Serie.
A7 – Cross-Site-Scripting (XSS)
Cross-Site-Scripting ist nach wie vor eine weit verbreitete und nicht zu unterschätzende Schwachstelle. Wenn benutzerdefinierte Inhalte direkt in die Web-Applikation übernommen werden, kann sich eine XSS-Schwachstelle ergeben.
XSS gibt es grundsätzlich in drei verschiedenen Ausführungen, die näher in diesem Artikel auf unserem Blog beschrieben sind. Der Artikel beschreibt auch Schutzmaßnahmen gegen diese Schwachstelle.
Dass dieses Problem durchaus kritische Folgen mit sich bringen kann, zeigen wir in einem weiteren Artikel zu dem Thema.
A8 – Insecure Deserialization
Diese neu eingeführte Kategorie beschäftigt sich mit serialisierten Daten und deren unsicherer Handhabung. Serialisierte Daten können für verschiedene Verwendungszwecke eingesetzt werden; unter anderem für die Inter-Prozess-Kommunikation auf dem Server und für Caching- bzw. Sitzungsdaten. Diese können in Form von Cookies, HTML-Parametern oder auch Authentifzierungstoken übertragen werden.
Wenn Sitzungsinformationen unverschlüsselt serialisiert auf der Clientseite gespeichert und diese Informationen auf dem Server nicht weiter verifiziert werden, besteht die Möglichkeit, dass ein Benutzer diese modifiziert. Dadurch kann er unrechtmäßig zu weiteren Rechten gelangen oder Zugriff auf sensible Informationen erhalten.
Die Deserialisierung von Daten kann auf dem Server ebenso zu Problemen führen. Unter Umständen kann dies sogar zu Remote Code Execution (RCE) führen. Serialisierte Daten müssen, wie alle anderen benutzerdefinierten Daten, als bösartig gehandhabt werden.
Es wird geraten, Integritätsprüfungen für serialisierte Daten zu implementieren, um Manipulationen zu erkennen. Die Deserialisierung auf dem Server muss dementsprechend sicher gestaltet werden.
Weiteres zum Thema Serialisierungsformate finden Sie in diesem Artikel.
A9 – Using Components with Known Vulnerabilities
Unter diese Kategorie fallen jegliche Schwachstellen, die sich durch fehlende Wartung von verwendeten Bibliotheken und Applikationen ergeben. Moderne Web-Applikationen verwenden oft eine Vielzahl an Applikationen auf dem Server und nutzen verschiedene Bibliotheken auf Server- und Client-Seite. Diese Softwarekomponenten müssen stetig aktualisiert werden, um aktuellste Schwachstellen zu beheben.
Regelmäßige Updates und Installationen von Patches sind unumgänglich, da eine sonst sichere Applikation über eingebundene Komponenten kompromittiert werden kann.
Um auf bestehende Schwachstellen zu prüfen, gibt es verschiedene Quellen wie die Common Vulnerabilities and Exposures Datenbank oder die National Vulnerability Database.
Nicht nur direkt integrierte Komponenten müssen aktualisiert werden, auch deren Abhängigkeiten.
A10 – Insufficient Logging & Monitoring
Auch “Insufficient Logging & Monitoring” wurde als neue Kategorie hinzugefügt. Sie inkludiert Probleme mit der Protokollierung von Geschehnissen und deren Überwachung.
Werden beispielsweise kritische Aufrufe nur auf dem Client gespeichert, so können diese einfach manipuliert oder gelöscht werden. Wenn ausschlaggebende Aktionen nicht protokolliert werden, kann das zu Problemen bei der Identifikation von Angriffen oder Fehlern führen.
Besonders die Autorisierung sollte überwacht werden, um Angreifer frühzeitig zu identifizieren und entsprechende Maßnahmen einleiten zu können.
Diese Kategorie ist aus der Sicht eines Penetrationstesters, ohne Einsicht auf den Server, oft nur schwer zu bewerten.
Entfernt, aber noch immer relevant
Die folgenden Kategorien wurden mit den neuen OWASP Top 10 entfernt, sind jedoch noch immer relevant für die Sicherheit von Applikationen.
Cross-Site Request Forgery (CSRF)
Eine Cross-Site Request Forgery (CSRF)-Schwachstelle erlaubt es einem Angreifer, Aktionen im Namen des Opfers durchzuführen, indem dieses auf speziell präparierte Ressourcen (z. B. URL-Link oder Webseite) gelockt wird. Mehr zu dem Thema finden Sie in unserem Blogartikel und in dem Artikel spezifisch für CSRF in Binärprotokollen.
Unvalidated Redirects and Forwards
Wenn eine Web-Applikation einem Benutzer die Möglichkeit bietet, beliebige URLs zu definieren (beispielsweise in Form von Parametern, auf die der Benutzer dann von der Applikation weitergeleitet wird), spricht man von Unvalidated Redirects and Forwards. Solche Schwachstellen werden häufig für Phishing oder für die Infektion mit Malware verwendet.
Weiter- oder Umleitungen sollten von der Web-Applikation verifiziert und limitiert werden. Hierfür bietet sich eine Zuordnung von Zielen zu IDs an. Die Applikation sollte dann nur die Definition dieser IDs, also nur definierte Ziele, für Weiterleitungen erlauben.
Dokumente
Weiterführende Artikel
A3 – Sensitive Data Exposure
Sichere SSL-/TLS-Konfiguration
Sichere Passwortspeicherung in Web-Applikationen
A4 – XML External Entities (XXE)
XXE: Angriff über ein Serialisierungsformat
A6 – Security Misconfiguration
Basis-Absicherung für den eigenen Server (1/2)
Basis-Absicherung für den eigenen Server (2/2)
A7 – Cross-Site Scripting (XSS)
Cross-Site Scripting (XSS) – Erkennen, Verstehen und Verhindern
XSS – Ausnutzung aus der Sicht eines Angreifers
A8 – Insecure Deserialization
Serialisierungsformate und ihre Tücken
A8 – Cross-Site Request Forgery (CSRF) (OWASP Top 10 2013)
Cross-Site Request Forgery (CSRF) – die unendliche Geschichte
CSRF in HTTP-basierten Binärprotokollen
Zukünftige Artikel:
Zu den Themen Cross Origin Resource Sharing (CORS) und SQL Injection erwarten Sie in Zukunft noch weiterführende Veröffentlichungen auf unserem Blog.
