Was sind die OWASP Top 10?

Die OWASP Top 10, ein Referenzstandard, der eine Rangliste der zehn kritischsten Sicherheitsrisiken für Webanwendungen sowie Leitlinien zu deren Behebung enthält, hilft Entwicklern und Sicherheitsexperten dabei, die Bedrohungslandschaft besser zu verstehen und zu navigieren. Das ultimative Ziel der Open Web Application Security Project Foundation ist es, eine Kultur sicherer Softwareentwicklung zu fördern. Für Entwickler und Administratoren von Webanwendungen ist die OWASP Top 10 eine wichtige grundlegende Sicherheitsreferenz. Sie bietet eine Grundlage, auf der sicherere Webanwendungen entwickelt werden können 

Was ist OWASP?

Das Open Web Application Security Project, auch bekannt als OWASP ist eine gemeinnützige Organisation mit dem Ziel, die Software-Sicherheit zu verbessern. OWASP bietet nicht nur Schulungen und Weiterbildungen an, sondern auch eine Vielzahl nützlicher Tools für die Informationssicherheit, wie zum Beispiel:

• Zed Attack Proxy (ZAP) – Ein beliebtes Open-Source-DAST-Tool (Dynamic Application Security Testing) für Schwachstellenscans und Penetrationstests.

• Dependency-Check – Ein SCA-Tool (Software Composition Analysis), das bei der Erkennung von Schwachstellen in Abhängigkeiten hilft.

• Dependency-Track – Eine Plattform zur Analyse von Komponenten in der Lieferkette, die für die Integration in CI/CD-Umgebungen (Continuous Integration/Continuous Delivery) konzipiert ist und anhand einer Software-Stückliste (SBOM) Risiken im Zusammenhang mit Open-Source- und Drittanbieter-Komponenten identifiziert.

Was sind die 10 größten OWASP-Risiken?

Die OWASP Top 10 ist eine Liste der zehn kritischsten Sicherheitsrisiken für Webanwendungen. Sie ist als Informationsdokument für Entwickler und Sicherheitsexperten konzipiert.  Genau wie die Bedrohungen für Webanwendungen ändert sich auch diese Liste von Zeit zu Zeit. So wurde beispielsweise die Liste aus dem Jahr 2013 im Jahr 2017 aktualisiert, und OWASP hat für das nächste Update Daten aus dem Zeitraum zwischen März und Mai 2020 erhoben.

Welche Risiken gehören also heute zu den OWASP Top 10? Folgende:

1. Injection

Injection-Angriffe treten auf, wenn Daten über ein Eingabefeld (z. B. ein Formular oder einen Log-in-Bereich) in einer Webanwendung an einen Interpreter gesendet werden. Eine der häufigsten Formen von Injection ist die SQL Injection. Ein typisches Beispiel für einen SQL-Injection-Angriff ist folgendes:

1. Bei einem Log-in-Prompt werden die eingegebenen Benutzernamen nicht ordnungsgemäß validiert oder bereinigt

2. Eine Datenbank speichert Benutzernamen und Passwörter im Klartext (tun Sie das nicht!) und verfügt nicht über Kontrollmechanismen wie SQL LIMIT

3. Normalerweise enthält der Log-in-Prompt der Webanwendung eine SQL-Anweisung wie

SELECT * FROM Users WHERE name = ‚someuser‘ AND password = 'passwd'

1. Ein bösartiger Nutzer gibt den Benutzernamen „user OR 1 = 1“ und ein beliebiges Passwort ein.

2. Die SQL-Anweisung wird zu

SELECT * FROM Users WHERE name = 'user' OR 1 = 1 --' AND password = 'passwd'

1. Der böswillige Nutzer erhält Zugriff auf die passwortgeschützten Inhalte

Zwar schützen viele Apps heutzutage vor diesem einfachen Fall, doch darf man nicht vergessen, dass jeder Bereich einer Webanwendung, der Eingabeparameter akzeptiert, Ziel eines Injection-Angriffs werden kann.

2. Fehlerhafte Authentifizierung

Fehlerhafte Authentifizierung bezieht sich auf die unsichere Implementierung von Authentifizierungsmethoden und Sitzungsverwaltung. Zu den Anzeichen einer fehlerhaften Authentifizierung gehören:

• Brute-Force-Angriffe zulassen

• Schwache Passwörter wie „Passwort“ zulassen

• Speicherung von Passwörtern im Klartext oder von Passwörtern, die mit einer schwachen oder fehlerhaften Hash-Funktion gehasht wurden

• Unsachgemäße Handhabung, Rotation und Invalidierung von Sitzungs-IDs und Authentifizierungstoken

Zur Minimierung des Risikos einer Sicherheitsverletzung, bei der Zugangsdaten offengelegt werden könnten, sollte ein von einem Nutzer erstelltes Passwort vor der Speicherung sowohl mit einem Salt versehen als auch gehasht werden. Das Speichern von Passwörtern im Klartext ist das Paradebeispiel dafür, diese Best Practice nicht zu befolgen, und selbst Public-Cloud-Giganten wie Google haben diesen Fehler begangen.

Darüber hinaus können die Multi-Faktor-Authentifizierung (MFA) und das Rate Limiting dazu beitragen, einige der mit einer fehlerhaften Authentifizierung verbundenen Probleme zu beheben, wie beispielsweise die Anfälligkeit für Brute-Force-Angriffe.

 3. Offenlegung sensibler Daten

Diese breite Kategorie umfasst die unbefugte Offenlegung sensibler Daten im Ruhezustand oder während des Transits. Oft verschlüsseln und übertragen APIs sensible Daten wie Passwörter, Kontonummern, Gesundheitsdaten und andere personenbezogene Daten nicht ordnungsgemäß, was zu einem Kompromittierungsrisiko führt.

Ein einfacher MITM-Angriff (Man-in-the-Middle) unter Verwendung von SSL-Striping veranschaulicht, wie es zu Datenschutzverletzungen kommen kann:

1. Ein Angreifer kompromittiert einen WLAN-Hotspot

2. Der Nutzer stellt eine Verbindung zum kompromittierten Hotspot her

3. Der Nutzer versucht, eine Verbindung zu https://someinsecuresite.net herzustellen

4. Der Angreifer nutzt einen Proxy, um die Anfrage des Nutzers über HTTPS an den Server weiterzuleiten

5. Der Angreifer entfernt die Verschlüsselung und gibt dem Nutzer Antworten über HTTP zurück

Nun kann der Angreifer alles, was der Nutzer an someinsecuresite.net sendet, im Klartext einsehen. Der Webserver von somesecuresite.net hat keine Ahnung, dass der Traffic kompromittiert ist, da die vom Server des Angreifers empfangenen Anfragen HTTPS verwenden. Der Nutzer ist sich des Angriffs nicht bewusst, weil es scheint, als kämen die Antworten direkt von someinsecuresite.net.

Die Durchsetzung von HTTP Strict Transport Security (HSTS) für alle Seiten, insbesondere für solche, die sensible Daten verarbeiten, ist eine Möglichkeit, das Risiko der Offenlegung sensibler Daten zu verringern. Ebenso hilft der Verzicht auf schwache Verschlüsselung wie SSL v3.0 oder TLS 1.0, die Sicherheit Ihrer Nutzer zu erhöhen. Darüber hinaus kann eine starke Verschlüsselung der Daten im Ruhezustand das Risiko von Datenlecks mit personenbezogenen Daten mindern, falls eine Datenbank kompromittiert wird. 

4. XML External Entities (XXE)

Extensible Markup Language (XML) ist ein gängiges Datenformat, und viele Webanwendungen können XML-Daten parsen. Ein XXE-Angriff hängt damit zusammen, wie dieses Parsing erfolgt. Ein Angreifer sendet XML-Daten, die auf eine externe Entität verweisen.

Ein anfälliger XML-Parser sendet daraufhin Antworten an die externe Entität, wodurch möglicherweise sensible Daten offengelegt werden. Angenommen, ein Angreifer möchte auf /path/to/super/secret/file.txt auf einem Webserver mit einem verwundbaren XML-Parser zugreifen. Der Angriff könnte etwa so aussehen:

1. Ein Angreifer sendet eine Anfrage, die folgenden XML-Code enthält:
   <?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE eggs[ <!ENTITY weakparser SYSTEM "file:///path/to/super/secret/file.txt"> ]> <movies><filmId>&weakparser;</filmId></movies>

2. Der Server antwortet mit einer Fehlermeldung und dem Inhalt von /path/to/super/secret/file.txt

5. Fehlerhafte Zugriffskontrolle

Während es bei Punkt 2 der OWASP Top 10 um die Authentifizierung geht, befasst sich Punkt 5 mit dem, was danach geschieht. Unter Zugriffskontrolle versteht man die Einschränkungen, die mit bestimmten Nutzerrechten verbunden sind.

Zu den von OWASP genannten konkreten Beispielen für fehlerhafte Zugriffskontrollen gehören:

• Verwendung einer modifizierten URL zur Umgehung von Zugriffskontrollen. Wenn beispielsweise userA einfach dadurch auf die Kontoinformationen von userB zugreifen kann, dass er einen Link von net/myapp/myaccount?user=userA
  in someinsecuresite.net/myapp/myaccount?user=userB ändert

• Rechteeskalation. Beispielsweise eine Sicherheitslücke oder eine Fehlkonfiguration, die es einem Nutzer ermöglicht, Administratoraktionen durchzuführen.s

• Unauthentifizierter Zugriff auf privilegierte Seiten. Beispielsweise wenn ein nicht authentifizierter Nutzer auf
  net/myapp/super-secret-admin-page
  zugreifen und privilegierte Informationen einsehen kann, für die normalerweise eine Authentifizierung erforderlich ist.

• Manipulation von Metadaten. Beispiele hierfür sind das Wiederholen oder Manipulieren von Zugriffskontroll-Tokens oder Cookies sowie der Missbrauch der Ungültigkeitserklärung von JSON-Web-Tokens.

• Fehlerhafte Konfiguration von CORS (Cross-Origin Resource Sharing). Ein häufiges Beispiel für eine fehlerhafte CORS-Konfiguration ist die Zulassung von Anfragen von „localhost“, die mit Webanwendungen in der Produktionsumgebung interagieren.

6. Sicherheitsrelevante Fehlkonfiguration

Laut OWASP sind Sicherheitskonfigurationsfehler das häufigste Problem auf ihrer Liste. Standardmäßig werden viele Pakete mit unsicheren Standardeinstellungen ausgeliefert, sodass Webentwickler und Administratoren diese absichern müssen. Außerdem kann eine Änderung der Konfiguration, um eine bestimmte Funktion zum Laufen zu bringen, zu einem unbeabsichtigten Sicherheitsfehler führen.

Beispielsweise ist standardmäßig der Zugriff auf das Admin-Panel mit einem Standardpasswort möglich. Die Anmeldedaten müssen daher vor der Bereitstellung in der Produktivumgebung geändert werden. Ebenso sollten nicht benötigte Services und Ports deaktiviert oder blockiert werden.

Die wichtigste Erkenntnis aus diesem Eintrag der OWASP Top 10 lautet:  Achten Sie darauf, die Komponenten Ihrer Anwendung sicher zu konfigurieren UND Sicherheitspatches und -updates gewissenhaft zu installieren.

7. Cross-Site Scripting (XSS)

Cross-Site Scripting auch bekannt als XSS ist ein häufiges Sicherheitsproblem bei Webanwendungen. Bei XSS-Angriffen werden clientseitige Skripte in Webinhalte eingeschleust. Sie können es Angreifern ermöglichen, Daten zu stehlen, die Sitzung eines Nutzers zu kapern oder veränderte Inhalte auf einer Webseite anzuzeigen. Es gibt verschiedene Arten von XSS-Angriffen. Dazu gehören:

• Reflected XSS – Diese einfache Form eines XSS-Angriffs wird auch als nicht-persistenter XSS-Angriff bezeichnet. In der Regel wird dabei eine bösartige URL verwendet, die auf eine legitime Website verweist. Bei dem Angriff enthält die URL Sonderzeichen (z. B. HTML-Steuerzeichen), die von anfälligen Seiten dann ausgeführt werden.

• Stored XSS – Diese Angriffe werden auch als gespeicherte XSS bezeichnet. Im Fall von Stored XSS werden die von einem Angreifer bereitgestellten schädlichen Daten serverseitig gespeichert. Als Ergebnis wird der kompromittierte Inhalt allen Nutzern angezeigt, die die Seite besuchen.

• Document Object Model (DOM)-basiertes XSS – DOM-basierte XSS-Angriffe zeichnen sich dadurch aus, dass der Exploit in der Regel den Server gar nicht erst berührt. Frontend-Code wie JavaScript wird zur Ausführung bösartiger Skripte ausgenutzt.

8. Unsichere Deserialisierung

Serialisierung ist der Prozess, mit dem Datenobjekte für Zwecke wie Streaming oder Datenspeicherung in ein bestimmtes Format konvertiert werden. Serialisierte Daten können Binär- oder Klartextdaten sein (wie JSON oder XML). Deserialisierung ist der Prozess, bei dem die Serialisierung rückgängig gemacht und die serialisierten Daten zurück in ein Datenobjekt konvertiert werden.

Der Serialisierungs-/Deserialisierungsprozess kann zu einem Problem werden, wenn nicht vertrauenswürdige Quellen serialisierter Daten im Spiel sind. Ein Angreifer kann bestimmte Operationen in die serialisierten Daten einfügen, und wenn der Angriff erfolgreich ist, führt der Server diese im Deserialisierungsvorgang aus. Das bedeutet, dass eine unsichere Deserialisierung für Angriffe genutzt werden kann, die von DDoS bis hin zur Rechteeskalation reichen.

OWASP bietet ein gutes Beispiel für unsichere Deserialisierung, indem es eine anfällige PHP-basierte Forenanwendung als Beispiel verwendet. Angenommen, die App verwendet ein Super-Cookie, das eine Nutzer-ID, eine Nutzerrolle und einen Passwort-Hash speichert.
Ein Angreifer könnte das Cookie so verändern, dass er sich erweiterte Rechte verschafft, etwa folgendermaßen:

Vorher:

a:1:{s:1:"MalicousUser";i:1;s:2:"guest"; i:1;s:1:" fe7pmk43i1wstgqvsyask27g44yxn7qhl6zgkr7ivho1e6lv903xc9sbiq4b6mtx";}

Nach:

a:1:{s:1:"SuperAdmin";i:1;s:2:"admin"; i:1;s:1:" fe7pmk43i1wstgqvsyask27g44yxn7qhl6zgkr7ivho1e6lv903xc9sbiq4b6mtx";}

9. Nutzung von Komponenten mit bekannten Schwachstellen

Dieses Risiko ist genau das, was der Name vermuten lässt: die Verwendung anfälliger Komponenten innerhalb einer Webanwendung. Moderne Webanwendungen stützen sich auf eine Vielzahl von Frameworks, Bibliotheken und Modulen. Sollten einige dieser zugrunde liegenden Komponenten Sicherheitslücken aufweisen, kann dies die gesamte App gefährden. Wie bei Nummer sechs der OWASP Top 10 kann das Anwenden von Sicherheitspatches und -upgrades hier viel bewirken.

10. Unzureichendes Logging und Monitoring

Die schnelle Erkennung versuchter Bedrohungen oder bestätigter Sicherheitsverletzungen ist ein wesentlicher Bestandteil der Verhinderung oder Minderung von Schäden. Bösartige Aktivitäten weisen oft ein charakteristisches Muster auf, sodass eine effektive Überwachung zu einer schnellen Erkennung beitragen kann. In vielen Fällen führen unentdeckte Sicherheitsverletzungen zu größeren Schäden, weshalb dieses Risiko auf der Liste steht. Laut OWASP deuten die meisten Studien sogar darauf hin, dass die Erkennung einer Datensicherheitsverletzung mehr als 200 Tage dauert.

Einige häufige Beispiele für unzureichende Logging und Überwachung sind:

• Kein Logging von wichtigen Ereignissen wie Anmeldungen und fehlgeschlagenen Anmeldungen

• Keine Meldungen oder mehrdeutigen Fehler- und Log-Meldungen für Warnstufen oder höhere Ereignisse

• Nur lokale Speicherung von Logs auf dem Server

• Sicherheitsscans lösen keine Benachrichtigungen oder Alerts aus

• Keine Echtzeitwarnung vor Angriffen

So kann eine WAF zur Bewältigung der OWASP Top 10 beitragen

Es gibt kein Allheilmittel, um Ihre Webanwendung vor den Bedrohungen in der OWASP Top 10 zu schützen. Sie müssen sicherstellen, dass die Sicherheit im Code, in der Infrastrukturkonfiguration und in den von Ihnen verwendeten Drittanbieterkomponenten berücksichtigt wird.

Nichtsdestotrotz kann eine Webanwendungs-Firewall die Absicherung Ihrer Webanwendung erheblich erleichtern. Die OWASP-Definition eines WAF beschreibt die gängigen Anwendungsfälle zur Abwehr von Angriffen wie XSS und SQL-Injektionen.

Wie genau kann eine WAF in solchen Fällen helfen? Richtig konfigurierte WAFs können potenziell bösartige Anfragen erkennen und blockieren. Durch die Kombination aus Standarderkennungen und individuell anpassbaren Funktionen in Lösungen wie Fastly Next-Gen WAF sowie die Nutzung der Möglichkeiten unserer Edge-Cloud-Plattform können Sie einen starken Schutz vor den OWASP Top 10 erreichen. 

Eine detailliertere Anleitung und Beispiele aus der Praxis zur Lösung von Open Web Application Security Project-Bedrohungen mit Fastly finden Sie in unserem Whitepaper.