Die zehn häufigsten Schwachstellen laut OWASP

0 Min. Lesezeit

Bedingt durch ihre auf diverse externe Bibliotheken und Dienste verteilte Architektur sind cloudnative Anwendungen ein besonders attraktives Ziel für Hacker. Denn bis zu 82 % aller Sicherheitslücken gehen auf Anwendungscode zurück. Das wissen auch die Hacker und versuchen es entsprechend aggressiv auszunutzen, um in den zugrunde liegenden Netzwerken Fuß zu fassen. Maßnahmen zur Absicherung von Webanwendungen sind also unabdingbar.

Wer oder was ist OWASP?

Das Open Web Application Security Project (OWASP) ist eine unabhängige Community, die die Sicherheit von Anwendungen und Diensten im World Wide Web fördern will. Einer der zentralen Grundsätze der Non-Profit-Organisation besteht darin, ihre Erkenntnisse für alle kostenlos auf ihrer Website zu veröffentlichen. Mit mehreren Tausend Mitgliedern, die sich rund um den Globus in Hunderten Sektionen organisieren, gilt OWASP als äußerst verlässliche Quelle für Informationen rund um die Sicherheit von Webanwendungen und APIs.

Und genau dieses Wissen ist für Entwickler unabhängig von ihrer Erfahrungsstufe essenziell. Denn neben dem Frust, den Sicherheitslücken im Anwendungscode für sie bedeuten, verursachen entsprechende Zwischenfälle nicht selten auch enorme Kosten für das Unternehmen.

Was hat es mit der OWASP Top 10 auf sich?

In regelmäßigen Abständen veröffentlicht und überarbeitet, umfasst dieses Ranking die zehn laut OWASP kritischsten Anwendungsschwachstellen. Darin ebenfalls aufgeführt sind deren potenzielle Auswirkungen und Empfehlungen zur Vorbeugung. Grundlage der Liste bilden Daten aus verschiedensten Quellen, darunter etwa Einsendungen von Sicherheitsberatern, Software-Herstellern und Security-Teams aus Unternehmen und Organisationen jeder Größenordnung. Sie gilt als eines der wichtigsten Nachschlagewerke für Verfahrensempfehlungen zur Sicherheit von Webanwendungen.

Die jüngste Ausgabe der OWASP Top 10 wurde 2021 veröffentlicht. Dabei wurden drei neue Kategorien aufgenommen, vier wurden umbenannt und einige weitere zusammengeführt.

Ursprünglich sollten die OWASP Top 10 für das Thema Anwendungssicherheit sensibilisieren. Seit der Erstausgabe im Jahr 2003 haben sie sich aber längst als Standardreferenz rund um die Thematik etabliert. Dies wohl nicht zuletzt auch deshalb, weil sie die genaue Anzahl der Schwachstellen aus der Common Weakness Enumeration (CWE) enthalten.

Bewegungen in der aktuellen OWASP Top 10

Pünktlich zum 20. Jahrestag der OWASP-Gründung wurde am 24. September 2021 die neueste Ausgabe der OWASP Top 10 veröffentlicht. Dabei sind 2021 im Vergleich zum Ranking von 2020 zahlreiche Veränderungen festzustellen, darunter insbesondere die Ablösung der SQL-Injektion vom Spitzenplatz. Diesen nimmt nun die fehlerhafte Zugangssteuerung ein.

  1. Fehlerhafte Zugangssteuerung

  2. Kryptografische Sicherheitslücken

  3. Injection

  4. Sicherheitsmängel im Design

  5. Sicherheitsrelevante Fehlkonfiguration

  6. Anfällige und veraltete Komponenten

  7. Fehlerhafte Identitätsprüfung und Authentifizierung

  8. Unzureichende Software- und Datenintegrität

  9. Mangelhaftes Logging und Monitoring

  10. Server-Side Request Forgery (SSRF)

Die zehn häufigsten Schwachstellen laut OWASP

Im Folgenden werden die einzelnen Vertreter der OWASP Top 10 genauer beleuchtet. Dabei wird sowohl auf ihre Auswirkungen als auch auf vorbeugende Maßnahmen eingegangen.

1. Fehlerhafte Zugangssteuerung

In puncto Website-Zugriff gilt: Für Besucher sollte dieser grundsätzlich nur auf die tatsächlich benötigten Seiten bzw. Bereiche möglich sein. Administratoren von E-Commerce-Website müssen beispielsweise neue Links, Angebote usw. hinzufügen können. Dennoch bleiben diese Funktionen anderen Benutzertypen nicht immer verborgen.

Für Web-Entwickler sollte das Thema Sicherheit stets oberstes Gebot sein, um Fallstricke in dieser Hinsicht zu vermeiden. Einige Content-Management-Systeme (CMS) räumen zum Beispiel sämtlichen Benutzertypen uneingeschränkte Zugriffsrechte (bis hin zur Admin-Ebene) ein. Dadurch haben dann auch Website-Besucher Zugang zu Admin-Steuerelementen, Servern, Datenbanken und anderen kritischen Anwendungen. Sicherheitslücken dieser Art können sogar so weit reichen, dass Weiterleitungen an andere, vom jeweiligen Angreifer anvisierte URLs möglich werden.

Maßnahmen zur Vorbeugung

Sicherheitslücken rund um fehlerhafte Zugangssteuerungen lassen sich auf vielerlei Weise korrigieren:

  • Begrenzung des Zugriffs der verschiedenen Benutzerrollen nur auf das für sie jeweils maximal erforderliche Maß (Prinzip der geringsten Rechte)

  • Löschen nicht mehr benötigter und inaktiver Benutzerkonten

  • Überwachung der Benutzeraktivität auf Servern und Websites einschließlich Zeitpunkten

  • Deaktivierung aller gegenwärtig nicht benötigten Zugangspunkte (sofern mehrere bestehen)

  • Verschlankung von Servern durch Deaktivierung aller nicht benötigten Dienste

2. Kryptografische Sicherheitslücken

Bei der Übertragung und Ablage sensibler Daten wie Passwörtern, Kreditkartennummern, digitalen Patientenakten, personenbezogenen Daten und Geschäftsinformationen ist die Gefahr kryptografischer Sicherheitslücken (und des Verlusts vertraulicher Daten) besonders groß. Daher erfordern diese Daten zusätzliche Schutzmaßnahmen. Dies gilt umso mehr für solche, die etwa der Datenschutz-Grundverordnung (DSGVO), dem California Consumer Privacy Act (CCPA) oder ähnlichen gesetzlichen Bestimmungen unterliegen. Problematisch ist in diesem Zusammenhang etwa die Übertragung von Daten als Plain Text. Selbiges gilt für veraltete und unsichere kryptografische Algorithmen sowie für Protokolle, die sich entweder standardmäßig oder historisch bedingt im Code befinden. Lassen sich die Daten mit Standard-Kryptoschlüsseln auslesen oder werden schwache Verschlüsselungscodes generiert bzw. nicht häufig genug gewechselt, treten ebenfalls entsprechende Sicherheitslücken auf. Gleiches gilt, wenn Kryptoschlüssel in Quellcode-Repositories einsehbar sind oder keine Verschlüsselung für empfangene Daten erzwungen wird.

Maßnahmen zur Vorbeugung

  • Deaktivieren von Features zum automatischen Ausfüllen in Formularen zur Datenerfassung

  • Datenerfassung nur im erforderlichen Umfang

  • Datenverschlüsselung bei Übertragung und Speicherung

  • Verwendung aktueller Verschlüsselungsverfahren

  • Deaktivierung von Caching in Datenformularen

  • Passwortspeicherung mittels starker adaptiver bzw. randomisierter Hashing-Funktionen

3. Injection

Bei einer Injektion werden nicht vertrauenswürdige Daten via Abfrage oder Befehl in den Interpreter eingebaut bzw. „injiziert“. Häufige Beispiele für Angriffe dieser Art sind SQL-, OS-, NoSQL- und LDAP-Injektionen. Der über entsprechende Sicherheitslücken injizierte Schadcode zwingt den Interpreter dazu, die zugehörige Anwendung zu Aktionen wie etwa der Generierung unerwünschter Befehle oder nicht autorisierten Datenzugriffen zu veranlassen.

Allgemein gilt: Jede Anwendung, die Parameter als Eingabe akzeptiert, ist potenziell gefährdet. Das Bedrohungspotenzial hängt dabei allerdings stark von den Mechanismen der Eingabewertprüfung ab.

Maßnahmen zur Vorbeugung

Injection-Angriffen können Sie durch den Verbund aus folgenden Maßnahmen einen Riegel vorschieben:

  • Verringerung der Angriffsfläche für den Austausch von Daten durch unerwünschte Befehle mittels Trennung der beiden voneinander

  • Keine Strukturierung benutzerseitiger Eingaben über Befehle, sondern Codierung von SQL-Abfragen anhand von Parametern (via Abfrage-Parametrisierung bzw. Prepared Statements)

  • Ersatz des Interpreters durch eine sichere API

  • Eingabewertprüfung auf der Serverseite und Implementierung eines Intrusion-Detection-Systems zur Erkennung von verdächtigem Client-Verhalten

4. Sicherheitsmängel im Design

Bei diesen in ihrer Bedeutung eher breit angelegten Problematiken geht es um Unzulänglichkeiten rund um nicht vorhandene oder mangelhafte Kontrollstrukturen.  Im Ranking von 2021 neu eingeführt, betrifft diese Kategorie die Forderung nach einem ausgedehnteren Einsatz von Threat Modelling, sicheren Design-Konzepten und Referenzarchitekturen: Es gilt, über den viel zitierten Shift-Left hinaus bereits in den dem Dev-Prozess vorgelagerten Phasen Methodiken umzusetzen, die dem Anspruch an „Secure by Design“ gerecht werden.

Maßnahmen zur Vorbeugung

  • Ausgestaltung eines sicheren Entwicklungslebenszyklus auf Grundlage von gemeinsam mit AppSec-Experten ermittelten Anforderungen an Sicherheit und Datenschutz sowie zugehöriger Maßnahmen

  • Aufbau einer Bibliothek sicherer Design-Konzepte und vorgefertigter Komponenten

  • Threat Modeling zur Ermittlung von Risikopotenzialen bei kritischen Vorgängen rund um Authentifizierung, Zugriffssteuerung, Business Logic und Bewegungen sensibler Daten

  • Direkte Einbindung von Security-Thematiken und -Kontrollen in User Stories

  • Plausibilitätsprüfungen auf sämtlichen Anwendungsebenen vom Frontend bis zum Backend

  • Unit- und Integrationstests zur Validierung kritischer Datenflüsse anhand der Bedrohungsmodellierung Erfassung aller auf den verschiedenen Anwendungsebenen möglichen Use Cases und Misuse Cases

  • Segmentierung der verschiedenen System- und Netzwerkebenen auf Grundlage ihres jeweiligen Risikopotenzials und zugehörigen Sicherheitsanforderungen

  • Begrenzung der je Benutzer bzw. Dienst möglichen Ressourcenbeanspruchung

5. Sicherheitsrelevante Fehlkonfiguration

Gartner zufolge gehen bis zu 95 % aller cloudbezogenen Sicherheitszwischenfälle auf Fehler auf Entwicklerseite zurück. Dies gilt insbesondere in Bezug auf Schwachstellen in der Konfiguration. Und auch gemäß OWASP-Daten sind diese von allen Schwachstellen aus der Top 10 am häufigsten. In puncto Cybersecurity allesamt höchst bedenklich, äußern sich Fehlkonfigurationen auf verschiedenste Weise:

  • Anwendung unsicherer Standardeinstellungen

  • Zu weitreichende Zugriffsrechte für Cloud-Speicherressourcen

  • Unvollständige Konfigurationen

  • Falsch konfigurierte HTTP-Header

  • Anzeige sensibler Informationen in Fehlermeldungen

Maßnahmen zur Vorbeugung

Von an das Netzwerk angebundenen Geräten und Datenbanken bis hin zu Web- und Anwendungsservern sowie Containern können sich sicherheitsrelevante Fehlkonfigurationen in nahezu allen Bereichen der Umgebung einschleichen. Dem entgegenwirken können folgende Maßnahmen:

  • Erstellung von Deployment-Templates für Entwicklungs-, Test- und Produktionsumgebungen auf Grundlage Ihrer Sicherheitsrichtlinien

  • Minimierung der von falsch konfigurierten Komponenten ausgehenden Risiken durch Segmentierung von Anwendungsarchitekturen und Einrichtung einer Bibliothek mit korrekt konfigurierten Container-Images

  • Auf ein Minimum reduzierte Plattformen und Deaktivierung aller dort nicht benötigten Features und Dienste

  • Durchgängiges Monitoring von Cloud-Ressourcen, -Anwendungen und -Servern auf Fehlkonfigurationen und Behebung ggf. festgestellter Probleme möglichst mithilfe automatisierter Workflows

6. Anfällige und veraltete Komponenten

Die dezentralisierten Webanwendungen von heute stützen sich häufig auf diverse Open-Source-Komponenten. Weisen diese jedoch bekannte Schwachstellen auf, werden sie zum schwachen Glied in der gesamten Sicherheitskette einer Anwendung.

Auch wenn diese Problematik in der OWASP Top 10 hinsichtlich ihres Schweregrads in den unteren Rängen angesiedelt ist, verursacht sie dennoch am häufigsten Datenschutzprobleme.

Maßnahmen zur Vorbeugung

Den in diesem Zusammenhang effektivsten Schutz bieten durchgängige Scans sämtlicher Code-Komponenten auf bekannte Schwachstellen und die schnellstmögliche Implementierung von Patches oder anderen Korrekturen. Für die Umsetzung solcher Mechanismen gibt es eine Reihe etablierter Verfahren:

  • Konfigurationsmanagement für sämtliche in das Framework Ihres Unternehmens integrierten Komponenten

  • Scanning-Tools zur automatischen Erfassung aller zu untersuchenden Komponenten via Auto-Discovery

  • Scans auf Grundlage einer umfassenden, regelmäßig mit aktueller Threat Intelligence angereicherten Schwachstellen-Datenbank

  • Möglichst stark automatisierte Workflows rund um die Ermittlung, Prüfung und Implementierung der jeweils passenden Patches zur Minimierung operativer Risiken im Zusammenhang mit dem Patch-Management

7. Fehlerhafte Identitätsprüfung und Authentifizierung

Werden Session-Management und Benutzerauthentifizierung bzw. zugehörige Funktionen innerhalb einer Anwendung falsch ausgeführt, können Angreifer Passwörter, Security Keys oder Session Tokens kompromittieren und so entweder zeitweise, ggf. aber auch dauerhaft unter der Identität anderer Benutzer operieren. Die zugehörigen Schwachstellen sind höchst bedenklich, gefährden sie doch nicht nur von der betroffenen Anwendung genutzte, sondern in erheblichem Maße auch andere Ressourcen, die an das gleiche Netzwerk angebunden sind.

Maßnahmen zur Vorbeugung

Sicherheitslücken rund um Benutzeridentitäten und -authentifizierung lassen sich gemäß OWASP-Empfehlungen folgendermaßen vermeiden:

  • Einrichtung einer Mehrfaktor-Authentifizierung

  • Deployments niemals unter Verwendung von Standard-Anmeldedaten, insbesondere nicht für Benutzer mit Admin-Rechten

  • Starke Passwörter

  • Umfassendes Monitoring fehlgeschlagener Logins

  • Einsatz sicherer Session-Manager, bei denen Session-IDs zufällig generiert und zeitlich begrenzt gültig sind Session-IDs niemals als Bestandteil von URLs

8. Unzureichende Software- und Datenintegrität

Unter diese Kategorie von Sicherheitslücken fallen Code und Infrastruktur ohne angemessenen Schutz vor Integritätsverletzungen, also etwa Plug-ins, Bibliotheken oder Module aus nicht vertrauenswürdigen Quellen, Repositories oder Content Delivery Networks (CDNs). Ihre Nutzung innerhalb der CI/CD-Pipeline birgt Risiken rund um nicht autorisierte Zugriffe, potenziell in ihnen enthaltenen Schadcode und Kompromittierungen von Systemen. Auch beinhalten viele Anwendungen heute Features für Auto-Updates. Zumeist werden diese allerdings ohne adäquate Integritätsprüfungen auf die bis dato noch vertrauenswürdigen Anwendungen aufgespielt. Für potenzielle Angreifer öffnet dies natürlich Tür und Tor, um über sämtliche Systeme hinweg eigene Updates einzuschleusen.

Maßnahmen zur Vorbeugung

  • Einsatz digitaler Signaturen oder vergleichbarer Mechanismen zur Verifizierung, dass Software und Daten vertrauenswürdig sind und nicht manipuliert wurden

  • Review-Prozeduren für Änderungen an Code und Konfigurationen zur Minimierung von Risiken dafür, dass über diese schädliche Elemente in die Dev-Pipeline gelangen

  • Checks von Bibliotheken und Abhängigkeiten (z. B. npm oder Maven) dahingehend, dass diese nur vertrauenswürdige Repositories nutzen Einrichtung eines eigenen, als vertrauenswürdig verifizierten Repositories im Falle eines höheren Risikoprofils

  • Schutz der Integrität von Build- und Deploy-Prozesse durchlaufendem Code durch adäquate Segmentierung, Konfiguration und Zugriffssteuerungen innerhalb CI/CD-Pipeline

  • Keine Übermittlung nicht signierter oder unverschlüsselter Daten an nicht vertrauenswürdige Clients ohne Maßnahmen wie Integritätsprüfungen oder digitale Signaturen, anhand derer Manipulationen der Daten oder ihre erneute Verwendung erkannt werden können

9. Mangelhaftes Logging und Monitoring

Studien belegen: Cyberangriffe werden erst bis zu 200 Tage nach ihrem Eintreten erkannt. Nicht selten aber ist dieses Zeitfenster, in dem Angreifer ungestört Server manipulieren, Datenbanken beschädigen, sensible Informationen abgreifen oder Schadcode injizieren können, sogar noch größer.

Maßnahmen zur Vorbeugung

Am schnellsten lassen sich verdächtige Aktivitäten und fehlgeschlagene Zugriffsversuche anhand von Software für Logging und Monitoring aufdecken. Und selbst wenn ein so aufgedeckter Angriff nicht erfolgreich war, sind die dabei erfassten Daten etwa zu dessen Ursprung und Vektor noch immer äußerst wertvoll, um Sicherheitsrichtlinien und -kontrollen zu stärken.

10. Server-Side Request Forgery (SSRF)

Bei dieser Sicherheitslücke (kurz „SSRF“) wird es Angreifern möglich, von einer serverseitigen Anwendung aus HTTP-Anfragen an beliebige Domains zu senden.

Anfälligkeiten gegenüber SSRF treten auf, wenn eine Webanwendung eine Remote-Ressource abruft, ohne dabei die vom Benutzer angegebene URL zu validieren. So können Angreifer über die betroffene Anwendung dann manipulierte Anfragen an Ziele ihrer Wahl senden. Dies selbst dann, wenn sie durch eine Firewall, ein VPN oder andere Arten von Listen zur Netzwerkzugriffssteuerung geschützt ist.

Maßnahmen zur Vorbeugung

  • Validierung von Inputs

  • Verwendung regulärer Ausdrücke

  • Annahme von IP-Adressen nur im IPv4- oder IPv6-Format

  • Abgleich der IP-Adresse mit der Zulassungsliste anhand des Werts der Methode bzw. Ausgabebibliothek

  • Validierung eingehender Domain-Namen

  • Umsetzung der Maßnahmen aus dem WASP-Cheatsheet zum Thema

Ein Blick über die OWASP Top 10 hinaus

Wie OWASP in der Methodik des Top-10-Ranking klargestellt, umfasst die Liste schon per definitionem nur die kritischsten Sicherheitsrisiken. Über diese hinaus bestehen aber freilich noch weitere, die ebenfalls nicht außer Acht gelassen werden sollten.

So sollten Sie auch die ständig neuen Anfälligkeiten wie die Log4Shell-Sicherheitslücke im Blick behalten, die im Dezember 2021 bekannt wurde.

Other non-OWASP Vulns chart - Malware & phishing, and RDP exploits are the next most common vulnerabilities
Übersicht über andere Bedrohungen als OWASP

OWASP-Schwachstellen: FAQs

Was versteht man unter einer OWASP-Schwachstelle?

OWASP-Schwachstellen sind Sicherheitslücken und Mängel, die vom Open Web Application Security Project veröffentlicht werden. Diese werden von Unternehmen, Organisationen und Sicherheitsexperten gemeldet und anhand ihres Schweregrads mit Blick auf die Sicherheit von Webanwendungen geordnet.

Welches sind laut OWASP die zehn größten Schwachstellen?

Die Top 10 von OWASP werden alle drei bis vier Jahre veröffentlicht und enthalten die wichtigsten Sicherheitsrisiken. Außerdem werden Beispiele und Angriffsflächen für Hacker genannt und Empfehlungen zur Risikovorbeugung gegeben.

Welche Sicherheitslücke ist laut OWASP am kritischsten?

Injection-Angriffe stellen laut OWASP die größte Gefahr dar. Dabei werden nicht vertrauenswürdige Daten per SQL oder auf anderen Wegen wie LDAP übermittelt. So kann der Interpreter auf eigentlich nicht freigegebene Daten zugreifen und unerwünschte Befehle ausführen.

Wie ermitteln Sie ihr eigenes Risiko?

OWASP veröffentlicht einen detaillierten Leitfaden mit diversen Beispielen und Testszenarien. Viele Entwicklungsabteilungen setzen auf ein automatisches Verfahren und durchsuchen ihren Code per Software auf Schwachstellen. Dies hat den Vorteil, dass Warnungen automatisch ausgegeben und bewährte Verfahren lückenlos angewendet werden.

Wie sollten die OWASP Top 10 eingesetzt werden?

Das OWASP-Ranking soll Entwicklungs- und Sicherheitsteams dabei unterstützen, ihre Entwicklungsabläufe auf den Prüfstand zu stellen und die Sicherheit ihrer Webanwendungen kritisch zu hinterfragen. Zwar umfasst die Rangliste nicht sämtliche Sicherheitsrisiken. Dennoch bietet sie eine solide Grundlage, um das Thema Sicherheit aus einem anderen Blickwinkel zu betrachten.

Up Next

Security Vulnerability: types and remediation

Learn more about security vulnerabilities, vulnerability versus exploit, website security vulnerabilities, and security and vulnerability management.

Weiterlesen
Patch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo Segment

Snyk ist eine Developer Security Plattform. Integrieren Sie Snyk in Ihre Tools, Workflows und Pipelines im Dev-Prozess – und Ihre Teams identifizieren, priorisieren und beheben Schwachstellen in Code, Abhängigkeiten, Containern, Cloud-Ressourcen und IaC nahtlos. Snyk bringt branchenführende Application & Security Intelligence in jede IDE.

Kostenlos startenLive-Demo buchen