Die OWASP Top Ten

In der Enumeration geht es darum, Schwachstellen und potenzielle Angriffsvektoren in der Webapplikation zu identifizieren.

Ein Angriffsvektor ist der spezifische Weg oder die Methode, über die ein Angreifer in ein System eindringen oder Schaden anrichten kann, häufig durch Ausnutzung von Schwachstellen in Software, Netzwerken oder menschlichem Verhalten.

Mit sozialen Netzwerken, Messaging-Apps, Streaming-Diensten, Online-Shops oder auch Cloud-Diensten sind Webapplikationen förmlich allgegenwärtig. Gleichzeitig sind sie auch anfällig für eine Vielzahl von Schwachstellen und Angriffsvektoren. Deshalb gibt es die OWASP Top Ten. Das ist eine Liste der zehn häufigsten Sicherheitsrisiken für Webanwendungen, die regelmäßig von dem Open Web Application Security Project (OWASP) erstellt wird.

Die Top Ten von 2021 waren:

1. Broken Access Control: Unzureichende Kontrollen erlauben unbefugten Zugriff auf Daten oder Funktionen, die für den Benutzer nicht bestimmt sind.
2. Cryptographic Failures: Schwächen in der Implementierung kryptografischer Systeme können zur Offenlegung sensibler Daten führen.
3. Injection: Angriffe wie SQL-Injection ermöglichen es Angreifern, schädlichen Code in eine Anwendung einzuschleusen, um Daten zu manipulieren oder zu stehlen.
4. Insecure Design: Mangelnde Sicherheitsüberlegungen bei der Entwurfsphase einer Anwendung können zu schwerwiegenden Sicherheitslücken führen.
5. Security Misconfiguration: Falsch konfigurierte Sicherheitsmechanismen können es Angreifern erleichtern, in Systeme einzudringen oder Daten zu stehlen.
6. Vulnerable and Outdated Components: Die Verwendung veralteter oder unsicherer Softwarebibliotheken kann Angreifern bekannte Schwachstellen bieten.
7. Identification and Authentication Failures: Schwache Authentifizierungsmechanismen können es Angreifern ermöglichen, sich unbefugt Zugang zu Systemen zu verschaffen.
8. Software and Data Integrity Failures: Mangelnde Integritätsprüfungen bei Software-Updates oder Daten können dazu führen, dass schadhafter Code ausgeführt wird.
9. Security Logging and Monitoring Failures: Unzureichendes Logging und Monitoring können dazu führen, dass Sicherheitsvorfälle nicht rechtzeitig erkannt werden.
10. Server-Side Request Forgery (SSRF): Angreifer können Anfragen von einem Server an interne oder externe Systeme leiten, um vertrauliche Informationen zu erlangen oder Dienste zu manipulieren.

Für all diese Sicherheitsrisiken findest du weitere Informationen auf den Webseiten der OWASP. Eine weitere gute Informationsquelle ist PortSwigger. Das ist eine Plattform, die Lernmodule und Labs zu verschiedenen Web-Sicherheitsanfälligkeiten und deren Ausnutzung bietet.

Brainstorming

Die Enumeration beginnt üblicherweise mit einem Brainstorming. In der Reconnaissance hattest du festgestellt, welche Möglichkeiten zur Benutzerinteraktion die Webseite bietet und welche Technologien eingesetzt werden. Beim Brainstorming gehst du nun diese Punkte durch und überlegst, welche Sicherheitsrisiken aus den OWASP Top Ten mit jedem einzelnen Punkt verbunden sein können.

Aspekt	Mögliches Sicherheitsrisiko
Benutzerinteraktion auf /login	Identification and Authentication Failures, Injection
Seiten /dashboard, /logout, /settings, /status	Broken Access
Technologien Popper.js, jQuery, Bootstrap	Vulnerable and Outdated Components
Webserver nginx	Vulnerable and Outdated Components
Betriebssystem Ubuntu	Vulnerable and Outdated Components

Eine Tabelle ist nicht unbedingt die beste Methode, um Sicherheitsrisiken eines Systems oder einer Software zu verstehen. Stattdessen kannst du auch einen Angriffsbaum wählen.

Ein Angriffsbaum ist ein hierarchisches Diagramm, in dem die verschiedenen Möglichkeiten dargestellt werden, wie ein Angreifer ein System ausnutzen oder ein bestimmtes bösartiges Ziel erreichen kann. Er gliedert komplexe Sicherheitsbedrohungen in kleinere, besser handhabbare Komponenten und ermöglicht eine strukturierte Analyse potenzieller Angriffsvektoren.

Hier ist zum Beispiel ein Angriffsbaum für die Webapplikation des LUPFERs:

Dieser Angriffsbaum dient nur als Anschauungsbeispiel. Deswegen ist er nicht vollständig. Aber auch bei realen Beispielen wird man oft keinen vollständigen Angriffsbaum erstellen, der alle Angriffsszenarien enthält.

Wie ist so ein Angriffsbaum zu verstehen?

• Der Ausgangspunkt ist der Wurzelknoten, der einen Schaden oder ein Angriffsziel repräsentiert. In diesem Beispiel soll das Ziel sein, dass der Angreifer auf ein fremdes Benutzerdaten zugreifen kann.
• Die einzelnen Äste repräsentieren verschiedene Angriffsvektoren, mit denen das Angriffsziel erreicht werden kann. Eine Möglichkeit ist, dass der Angreifer sich als ein bestimmter Benutzer einloggt. Eine andere Möglichkeit wäre, dass der Angreifer Zugriff auf die Datenbank erhält, in denen die Benutzerdaten gespeichert sind.
• Die Unterknoten stellen einzelne Zwischenschritte des Angriffsvektors dar. So kann ein Angreifer versuchen Benutzernamen und Passwort über einen Brute-Force-Angriff zu ermitteln oder den Login durch eine SQL-Injection umgehen.
• Die Blattknoten sind dann der Ausgangspunkt für den Angriff.

Nun musst du die Äste priorisieren und entscheiden, welchen Angriffsvektor du als Erstes untersuchst. Dafür wirst du Aufwand und Ertrag abwägen. Am besten ist es natürlich, mit wenig Aufwand einen großen Schaden zu erreichen.

Bei unserem Beispiel wirst du nur den linken Ast untersuchen und versuchen, dich als ein fremder Benutzer einzuloggen. Den rechten Ast mit dem Zugriff auf die Datenbank vernachlässigen wir. Er ist deshalb in Hellgrau dargestellt.

Untersuchen HTTP-Anfragen

Wenn du dich ohne eigene Zugangsdaten einloggen willst, solltest du zunächst die HTTP-Anfrage und -Antworten untersuchen, mit denen der Login-Vorgang durchgeführt wird. Wichtige Aspekte, die du für das Testen auf Schwachstellen brauchst, sind:

1. Die HTTP-Methode: Das ist eine Anweisung, die angibt, welche Art von Aktion der Client auf dem Server ausführen möchte.
2. Der HTTP-Endpunkt: Das ist eine spezifische URL, an die ein Client eine Anfrage sendet, um Daten zu senden oder abzurufen.
3. Gesendete Objekte: Abhängig von der Anfragemethode werden mit der Anfrage Daten übertragen. Dies können beispielsweise Zugangsdaten sein.
4. Validierung von Eingabedaten: Um Fehler und potentielle Sicherheitsrisiken zu minimieren, werden Benutzereingaben unter Umständen client- und serverseitig Daten auf ihre Richtigkeit, Vollständigkeit und Sicherheit überprüft.
5. Benutzeridentifikation: Mit Anfragen können auch Benutzereigenschaften übertragen werden, über die der Server den Benutzer identifiziert.

Um HTTP-Anfragen zu untersuchen, musst du sie dir in der Netzwerkanalyse der Entwicklungstools anzeigen lassen:

So erfährst du, dass die Zugangsdaten über eine POST-Anfrage an den Endpunkt /login gesendet werden. Unter dem Tab Request werden die übertragenen Daten angezeigt. Sie bestehen aus

• Einem CSRF-Token, mit dem sogenannte Cross-Site-Request-Forgery-Angriffe verhindert werden soll (Weitere Informationen zu CSRF findest du (hier)[https://portswigger.net/web-security/csrf].)
• Den Anmeldedaten username und password
• Dem Submit-Button, der die Absicht signalisiert, sich einzuloggen

Um festzustellen, ob die Eingabedaten client- oder serverseitig validiert werden, gibt man absichtlich ungültige oder schadhafte Daten ein und überprüft, ob die Webapplikation diese abweist oder entsprechende Fehlermeldungen anzeigt.

Die Webapplikation des LUPFERs validiert die Benutzereingaben offensichtlich serverseitig. Gäbe es eine clientseitige Validierung, würde der Browser die Anfrage nicht an den Server senden, da die Eingaben fehlen. Wie gut die serverseitige Validierung ist, wirst du später noch untersuchen, wenn du gezielt auf Sicherheitsrisiken testest.

Der letzte offene Punkt ist die Frage, ob mit der Anfrage Benutzereigenschaften übertragen werden. Aus der Reconnaissance ist bereits bekannt, dass die Webapplikation einen Session-Cookie setzt. Den Anfragekopfzeilen kannst du entnehmen, dass der Session-Cookie mit der Anfrage tatsächlich übertragen wird:

Die Webapplikation identifiziert mit der Anfrage also den Benutzer. Warum all diese Informationen beim Testen auf bestimmte Sicherheitsrisiken eine Rolle spielen, zeigen die nächsten Abschnitte.