OWASP Top 10 2021 – Der ultimative Leitfaden

Die OWASP Top 10 wurde von der Open Web Application Security Project (OWASP) Foundation erstellt – einer gemeinnützigen Organisation, die sich für die Verbesserung der Software-Sicherheit einsetzt. OWASP erstellt regelmäßig frei verfügbare Materialien zur Sicherheit von Webanwendungen.

Was ist die OWASP Top 10?

Die OWASP Top 10 ist ein öffentlich zugängliches Standarddokument für Entwickler, das die zehn kritischsten Sicherheitsschwachstellen von Webanwendungen aufzeigt, so die Stiftung. OWASP versteht unter einer Sicherheitslücke jede Schwachstelle, die es einem böswilligen Akteur ermöglicht, den Stakeholdern einer Anwendung (Eigentümern, Benutzern usw.) Schaden und Verluste zuzufügen. 

Die OWASP-Top-10-Liste wird von Sicherheitsexperten für Webanwendungen weltweit erstellt und alle paar Jahre aktualisiert. Sie zielt darauf ab, Unternehmen und Entwickler darüber aufzuklären, wie sie die Sicherheitsrisiken von Anwendungen minimieren können. 

Die letzte Aktualisierung der Liste wurde im Jahr 2021 veröffentlicht, während die vorherige Aktualisierung im Jahr 2017 erfolgte.

Die OWASP-Liste wird derzeit auch für mobile Anwendungen entwickelt. 

Neben der Top-10-Liste veröffentlicht und pflegt OWASP auch die folgenden Ressourcen: 

• OWASP Testing Guide: “Best Practices” für Anwendungstests
• OWASP Juice Shop: Eine absichtlich unsichere Webanwendung für Sicherheitsschulungen

Die OWASP Top 10 2021

Broken Access Control – A01:2021

Access Control bezieht sich auf die Durchsetzungen von Beschränkungen für authentifizierte Benutzer, um Aktionen außerhalb ihrer Berechtigungsstufe durchzuführen. Broken Access Control liegt vor, wenn solche Beschränkungen nicht korrekt durchgesetzt werden. Dies kann zu unbefugtem Zugriff auf sensible Informationen sowie zu deren Änderung oder Zerstörung führen. Einige der häufigsten Schwachstellen der Zugriffskontrolle sind:

• Gewähren von freiem Zugriff auf Rollen, Funktionen und Fähigkeiten, die nach dem “Principle of Least Privilege” eingeschränkt und standardmäßig verweigert werden sollten
• Manipulation von Parametern und erzwungenes Browsen (d. h. Änderung einer URL oder der HTML-Seite) oder Änderung von API-Anfragen zur Umgehung von Access Control Checks
• Bereitstellung unsicherer direkter Objektreferenzen (d. h. eines Unique Identifiers), die es ermöglichen, das Konto eines Benutzers einzusehen und zu ändern
• Ausweitung der Rechte aufgrund eines Bugs oder Design Flaws
• Manipulation von Metadaten, wie JWT Access Control Tokens, Cookies, versteckte Felder und Missbrauch des Invalidierens von JWT
• Forciertes Browsen, um auf authentisierte oder privilegierte Seiten zuzugreifen
• Ermöglichung des API-Zugriffs von nicht vertrauenswürdigen/unautorisierten Quellen aufgrund einer falschen CORS-Konfiguration (Cross-Origin Resource Sharing) 
• Zugriff auf API ohne POST-, PUT- und DELETE Access Control 

Wie kann Broken Access Control vermieden werden? 

Die Access Control muss in einem Code auf einem vertrauenswürdigen Server oder einer serverlosen API implementiert werden, um wirksam zu sein. Dies verringert die Wahrscheinlichkeit, dass ein Angreifer die Access Control oder die Metadaten manipuliert. Darüber hinaus empfiehlt OWASP die folgenden Maßnahmen für den Umgang mit Broken Access Control:

• Deny by default – Mit Ausnahme von öffentlichen Ressourcen 
• Eigentumsrechte an Datensätzen durchsetzen, anstatt jedem Benutzer Zugriff auf jeden Datensatz zu gewähren
• Einmalige Einführung von Access Control Mechanismen und deren wiederholte Verwendung in der Anwendung
• Domainmodelle sollten eindeutige Anforderungen an die Geschäftsgrenzen der Anwendung durchsetzen
• Überwachung und Aufzeichnung fehlgeschlagener Access Control Versuche und ggf. Alarmierung der Administratoren
• Zustandsabhängige Sitzungskennungen auf dem Server nach der Abmeldung ungültig machen
• Zustandslose JSON-Web-Tokens (JWT) sollten kurzlebig sein
• Sicherstellen, dass weder Metadaten (Git) noch Sicherungsdateien in Web Roots vorhanden sind
• Deaktivieren der Verzeichnisauflistung des Webservers
• Reduzieren Sie die Wirkung automatisierter Angriffstools, indem Sie den API- und Controller-Zugriff begrenzen
• Durchführung von funktionalen Einheits- und Integrationstest der Access Control 

Zusätzlich zu diesen Maßnahmen können Sie auch Folgendes tun:

• Löschen Sie alle inaktiven oder unnötigen Konten
• Verwenden Sie an allen Zugangspunkten eine mehrstufige Authentifizierung
• Schalten Sie unnötige Zugangspunkte ab
• Durchsetzung des “Principle of Least Privilege” (PoLP) 
• Beseitigen Sie Dienste, die auf Ihrem Server nicht benötigt werden

Kryptografische Fehler – A02:2021

Kryptografische Fehler (Cryptographic failures) beziehen sich auf Probleme mit der Kryptografie oder ihr generelles Fehlen. Früher war dieser Punkt als „Sensitive Data Exposure“ bekannt, aber dieser Name war nicht ganz zutreffend, da er eher ein Symptom und eine Wirkung, statt einer Ursache beschrieb. Cryptographic failure kann und führt oft zu einer Offenlegung von Daten.

Diese Art von Versagen betrifft den Schutz und die Geheimhaltung von Daten während der Übertragung und im Ruhezustand. Zu diesen Daten gehören in der Regel Authentifizierungsdaten wie Benutzernamen und Passwörter, aber auch personenbezogene Daten wie persönliche und finanzielle Informationen, Gesundheitsdaten, Geschäftsgeheimnisse und mehr. 

Fehler entstehen aus einer Vielzahl von Gründen, und Schwachstellen werden oft durch einen Man-in-the-Middle-Angriff ausgenutzt. Häufige Gründe für kryptografische Unzulänglichkeiten sind:

• Speichern oder Übertragen sensibler Daten in klarem Text
• Verwendung von veralteten oder schwachen kryptografischen Algorithmen und Protokollen
• Verwendung von Standard- oder schwachen crypto keys, keine Schlüsselverwaltung und -rotation
• Keine Durchsetzung der Verschlüsselung
• Nicht ordnungsgemäße Validierung des Server-Zertifikats und der Vertrauenskette
• Ignorieren oder Wiederverwenden von Initialisierungsvektoren oder Verwendung eines unsicheren Betriebsmodus

Dies sind einige der Schwachstellen, die Angreifer ausnutzen können, um Zugang zu vertraulichen Daten zu erhalten.

Wie lassen sich Kryptografische Fehler verhindern?

Laut OWASP können Unternehmen und Organisationen folgende Maßnahmen ergreifen, um cryptographic failures zu verhindern:

• Klassifizierung der (verarbeiteten, gespeicherten oder übertragenen) Daten, die von der Anwendung übertragen werden, und Identifizierung der sensiblen Daten gemäß den Datenschutzgesetzen, -vorschriften und Geschäftsanforderungen
• Implementierung von Sicherheitskontrollen in Abhängigkeit von der Datenklassifizierung
• Speichern Sie keine sensiblen Daten, verwerfen Sie sie so schnell wie möglich, oder verwenden Sie PCI DSS-konforme “tokenization” oder sogar “truncation”
• Verschlüsseln Sie alle Daten im Ruhezustand, die gespeichert werden müssen.
• Verwenden Sie starke Algorithmen, Protokolle und Schlüssel
• Verwenden Sie das Transport-Layer-Security-Protokoll mit Forward Secrecy zur Verschlüsselung aller Daten während der Übertragung
• Verwenden Sie die Verschlüsselungsrichtlinie HTTP Strict Transport Security (HSTS) oder eine ähnliche Methode 
• Verwenden Sie niemals FTP- und SMTP-Protokolle, um sensible Daten zu übertragen.
• Deaktivieren Sie die Zwischenspeicherung für User Responses, die sensible Daten enthalten
• Verwenden Sie zum Speichern von Passwörtern Funktionen, die immer ein Salt- und Hash-Verfahren sowie einen Arbeitsfaktor verwenden, wie z. B. brcrypt, scrypt, Argon2, PBKDF2 
• Wählen Sie die Initialisierungsvektoren je nach Betriebsart sorgfältig aus – für viele kann dies einen “cryptographically secure pseudo-random number generator (CSPRNG)” bedeuten
• Verwenden Sie immer eine authentifizierte Verschlüsselung
• Verwenden Sie eine kryptografische Zufallsschlüsselgenerierung und speichern Sie die Schlüssel als Byte-Arrays
• Verwenden Sie bei Bedarf kryptografische Zufallszahlen, aber stellen Sie sicher, dass diese nicht vorhersehbar oder mit geringer Entropie erzeugt werden

Injection – A03:2021

Eine Injektion Angriff bezieht sich auf nicht vertrauenswürdige Daten in einer Anwendung, die diese zur Ausführung von Befehlen zwingt. Solche Daten oder bösartiger Code werden von einem Angreifer eingefügt und können Daten oder die gesamte Anwendung gefährden. Die häufigsten Injektion Angriffe sind SQL Injektion und Cross-Site-Scripting (XSS)-Angriffe, aber auch Code Injection, Command Injektion, CCS Injektion und andere.

Eine Anwendung ist anfällig für einen Injektionsangriff, wenn eine oder mehrere der folgenden Bedingungen gegeben sind:

• Von Benutzern gelieferte Daten werden nicht validiert, gefiltert oder bereinigt
• Der Interpreter verwendet direkt dynamische Abfragen oder nicht parametrisierte Aufrufe ohne kontextabhängiges Escaping
• Gefährliche Daten werden direkt verwendet, verkettet oder in object-relational mapping (ORM) Suchparametern verwendet, um zusätzliche sensible Datensätze zu extrahieren 

Wenn ein Injektionsangriff erfolgreich ist, kann der Angreifer Daten anzeigen, ändern oder sogar löschen und möglicherweise die Kontrolle über den Server erlangen.

Wie kann man eine Injection verhindern?

Die Hauptschwachstelle für einen Injektionsangriff besteht darin, dass die Daten nicht von den Befehlen und Abfragen getrennt werden. Lest, was getan werden kann, um eine Injection zu verhindern:

• Die gebräuchlichste Lösung ist die Nutzung einer sicheren API, die die Verwendung des Interpretationsprogramms ganz vermeidet oder parametrisierte Abfragen verwendet oder zu objektrelationalen Mapping-Tools (ORMs) migriert. Beachten Sie, dass parametrisierte gespeicherte Prozeduren immer noch für eine SQL-Injektion anfällig sein können, wenn Abfragen und Daten verkettet sind oder feindliche Daten mit EXECUTE IMMEDIATE oder exec() ausgeführt werden 
• Verwenden Sie eine positive serverseitige Eingabevalidierung (Whitelist) – dies ist ein Teilschutz, da viele Anwendungen die Verwendung von Sonderzeichen erfordern 
• Bei verbleibenden dynamischen Abfragen können Sonderzeichen durch die spezifische Escape-Syntax für diesen Interpreter vermieden werden 
• Verwenden Sie Datenbankkontrollen innerhalb von Abfragen, wie z. B. LIMIT, um zu verhindern, dass im Falle einer erfolgreichen SQL-Injektion massenhaft Daten preisgegeben werden 

Insecure Design – A04:2021

Diese Kategorie von Schwachstellen konzentriert sich auf die Risiken, die mit Mängeln in Design und Architektur verbunden sind. Wie von OWASP erläutert, unterscheiden sich diese von den Risiken, die mit Mängeln bei der Implementierung verbunden sind. Auch ein gut implementiertes unsicheres Design ist anfällig für Angriffe.

Insecure Design bezieht sich zum Teil auf das Fehlen von Security Controls und des Business Risk Profilings bei der Entwicklung von Software und damit auf das Fehlen einer angemessenen Bestimmung des erforderlichen Grads der Sicherheitsgestaltung. 

Wie kann Insecure Design verhindert werden?

• Implementierung eines sicheren Entwicklungszyklus mit Experten für Anwendungssicherheit, um die Anforderungen an die Sicherheit des Designs und den Datenschutz zu bewerten
• Einführung und Verwendung einer Bibliothek mit sicheren Entwurfsmustern oder gebrauchsfertigen Komponenten
• Anwendung von Methoden der Bedrohungsmodellierung auf kritische Authentifizierung, Zugriffskontrolle, Geschäftslogik und Schlüsselabläufe
• Sicherheitssprache und -kontrollen als Teil der User Stories
• Durchsetzung von Plausibilitätsprüfungen vom Frontend bis zum Backend auf jeder Ebene des Systems
• Validierung der Widerstandsfähigkeit kritischer Abläufe gegenüber dem Bedrohungsmodell durch Unit- und Integrationstests. Zusammenstellung von Nutzungs- und Missbrauchsfällen für jede Ebene der Anwendung
• Trennen der Ebenen und Netzwerkschichten des Systems auf der Grundlage der Offenlegungs- und Schutzanforderungen
• Robuste Trennung von Anwendern auf allen Ebenen durch Design 
• Beschränkung des Ressourcenverbrauchs nach Benutzer oder Dienst

Sicherheitsfehlkonfigurationen – A05:2021

Sicherheitsfehlkonfigurationen (Security misconfiguration) bezieht sich auf Sicherheitskontrollen, die nicht gesichert oder nicht richtig konfiguriert sind. Diese Schwachstelle ist häufig auf einen der folgenden Gründe zurückzuführen: 

• Fehlende Sicherheitshärte in einem beliebigen Teil einer Anwendung
• Falsch konfigurierte Berechtigungen für Cloud-Dienste
• Unnötige Funktionen, wie z. B. Ports, Dienste, Seiten, Konten oder Berechtigungen werden zugelassen oder installiert
• Standardkonten/-passwörter sind aktiviert oder unverändert
• Fehlermeldungen, die den Benutzern angezeigt werden, enthalten Stack Traces oder andere sensible Informationen
• Die neuesten Sicherheitsfunktionen sind nicht aktiviert oder nicht korrekt implementiert.
• Die Sicherheitseinstellungen des Servers, des Frameworks, der Bibliotheken oder der Datenbanken sind nicht auf sichere Werte eingestellt
• Security Header oder Anweisungen werden vom Server nicht gesendet oder sind nicht auf sichere Werte eingestellt
• Die Software ist nicht auf dem neuesten Stand

Ein automatisiertes Pentest-Tool wie Crashtest Security kann Anwendungsschwachstellen aufspüren, die aufgrund von Sicherheitsfehlkonfigurationen Tür und Tor für einen Angriff öffnen können. Registrieren Sie sich für eine kostenlose Testversion und starten Sie Ihren ersten Scan in wenigen Minuten. 

Wie lassen sich Sicherheitsfehlkonfigurationen Angriffe verhindern?

OWASP empfiehlt die Implementierung von sicheren Installationsprozessen. Damit einhergehend sollten Sie:

• Sicherung des Systems durch einen Hardening-Prozess, indem der Prozess der Bereitstellung einer separaten und sicheren Umgebung entwickelt und automatisiert wird. Jede separate Umgebung (Entwicklung, QA, Produktion) muss identisch konfiguriert werden, aber über unterschiedliche Anmeldeinformationen zugänglich sein
• Verwenden Sie eine „Minimalplattform“, die keine unnötigen Funktionen, Komponenten, Dokumentationen oder Beispiele enthält. Installieren oder entfernen Sie keine unnötigen Funktionen und Frameworks
• Überprüfen Sie die Berechtigungen für den Cloud-Speicher
• Überprüfung und Aktualisierung der Konfigurationen aller Sicherheitshinweise, Updates und Patches als Teil des Patch-Management-Prozesses einführen
• Implementieren Sie eine segmentierte Anwendungsarchitektur über Segmentierung, Containerisierung oder Cloud-Sicherheitsgruppen, um Nutzer und Komponenten zu trennen
• Sicherheitsrichtlinien, wie z. B. Security Header, sollten an Clients gesendet werden
• Automatisieren Sie die Überprüfung der Wirksamkeit von Konfigurationen und Einstellungen in jeder Umgebung

Präventionsguide

Ultimativer Präventionsguide – Gängiste Cyber Threats

Dieses große, ständig wachsende E-Book zeigt Best Practices und Präventionstechniken, um Schwachstellen zu vermeiden und Ihre Webanwendungen zu sichern.

Download

Komponenten mit bekannten Sicherheitslücken – A06:2021

Diese Kategorie war früher als „Using Components with Known Vulnerabilities“ bekannt. Komponenten mit bekannten Sicherheitslücken können in einer der folgenden Situationen auftreten:

• Wenn Sie die Versionen der von Ihnen verwendeten client- und serverseitigen Komponenten nicht kennen
• Wenn die Software anfällig ist, nicht unterstützt wird oder veraltet ist. Dazu gehören Betriebssysteme, Web-/Anwendungsserver, Datenbankverwaltungssysteme (DBMS), Anwendungen, APIs und alle Komponenten, Laufzeitumgebungen und Bibliotheken
• Wenn Sie nicht regelmäßig nach Schwachstellen scannen und die Sicherheitsnachrichten über die von Ihnen verwendeten Komponenten verfolgen
• Wenn Sie Ihre Plattform, Ihr Framework und Ihre Abhängigkeiten nicht reparieren oder aktualisieren, wenn Patches herauskommen
• Wenn Ihre Entwickler keine Kompatibilitätstests für aktualisierte, erweiterte oder gepatchte Bibliotheken durchführen
• Wenn die Konfigurationen Ihrer Komponenten nicht gesichert sind

Wie kann man Vulnerable oder Outdated Components vermeiden?

Um die Gefahren zu vermeiden, die mit der Verwendung solcher Komponenten verbunden sind, sollten Sie:

• Alle ungenutzten Abhängigkeiten, unnötigen Funktionen, Komponenten, Dateien und Dokumentationen entfernen
• Regelmäßige Bestandsaufnahme der Versionen von client- und serverseitigen Komponenten sowie ihrer Abhängigkeiten durch Verwendung von OWASP Dependency-Check, retire.js usw. durchführen. Verfolgen Sie Quellen wie Common Vulnerability and Exposures (CVE) und National Vulnerability Database (NVD), und abonnieren Sie E-Mail-Benachrichtigungen, um Neuigkeiten über Sicherheitslücken in Komponenten zu erhalten. Um den Prozess zu automatisieren, verwenden Sie Tools zur Analyse der Softwarezusammensetzung
• Nur offizielle Quellen und sichere Links verwenden, um Komponenten zu beziehen. Entscheiden Sie sich für signierte Pakete
• Auf Bibliotheken und Komponenten achten, die nicht gewartet werden und für die es keine Sicherheits-Patches für alte Versionen gibt. Wenn Sie keine Patches installieren können, setzen Sie ein virtuelles Patch ein, um die bekannte Schwachstelle zu überwachen, zu erkennen oder davor zu schützen

Identification And Authentication Failures – A07:2021

Diese Gruppe von Sicherheitslücken in der Authentifizierung und Sitzungsverwaltung war früher als “Broken Authentication” bekannt. Diese können auftreten, wenn eine Anwendung:

• Nicht gegen automatisierte Angriffe wie das Ausfüllen von Anmeldeinformationen geschützt ist
• Brute-Force-Angriffe ermöglicht
• Die Verwendung von Standard-, schwachen oder bekannten Passwörtern akzeptiert wird
• Schwache oder ineffektive Verfahren zur Wiederherstellung von Anmeldeinformationen und vergessenen Passwörtern hat
• Klartext-, verschlüsselte oder schwach gehashte Kennwortdatenspeicher verwendet
• Keine oder eine unwirksame Multi-Faktor-Authentifizierung verwendet wird
• Die in der URL identifizierte Sitzung offen liegen
• Die nach der Anmeldung identifizierten Sitzung wiederverwendet
• Benutzersitzungen und Authentifizierungstoken beim Abmelden oder bei Inaktivität nicht ordnungsgemäß ungültig macht

Wie lassen sich Identification and Authentication Vulnerabilities vermeiden?

Zu den von OWASP vorgeschlagenen Präventionsmaßnahmen gehören:

• Implementieren Sie, wann immer möglich, eine Multi-Faktor-Authentifizierung, um das Ausfüllen von Anmeldedaten, Brute-Force-Angriffe und die Wiederverwendung gestohlener Anmeldedaten zu verhindern
• Niemals mit Standard-Anmeldedaten ausliefern oder bereitstellen, insbesondere nicht für Benutzer der Administrator-Ebene
• Überprüfen Sie schwache Passwörter
• Verwenden Sie die Richtlinien 800-63b des National Institute of Standards and Technology (NIST) oder andere aktuelle und evidenzbasierte Passwortrichtlinien, um die Länge, Komplexität und Rotation von Passwörtern festzulegen
• Sichern Sie die Registrierung, die Wiederherstellung von Anmeldeinformationen und die API-Pfade gegen Account Enumerierung Angriffe, indem Sie identische Nachrichten für alle Ergebnisse verwenden
• Begrenzung oder progressive Verzögerung wiederholter Anmeldeversuche nach einem Fehlschlag, aber Vermeidung eines Denial-of-Service-Szenarios. Protokollierung und Überwachung fehlgeschlagener Versuche und Benachrichtigung der Administratoren, wenn Credential Stuffing, Brute Force oder eine andere Art von Angriff festgestellt wird
• Verwenden Sie einen serverseitigen, sicheren und integrierten Sitzungsmanager, der nach der Anmeldung neue zufällige Sitzungs-IDs mit hoher Entropie erzeugt. Behalten Sie die Sitzungskennung nicht in der URL und stellen Sie sicher, dass sie sicher gespeichert und nach Abmeldung, Leerlauf und absoluten Timeouts ungültig gemacht wird

Software- und Daten Integritätsfehler – A08:2021

Die neue Software- und Daten Integritätsfehler Kategorie auf der OWASP-Liste bezieht sich auf Schwachstellen in Software-Updates, kritischen Daten und CI/CD-Pipelines, deren Integrität nicht überprüft wird. 

Beispielsweise kann eine Anwendung, die sich auf Plugins, Bibliotheken oder Module aus nicht verifizierten und nicht vertrauenswürdigen Quellen, Repositorien oder Content Delivery Networks (CDNs) stützt, einer solchen Art von Fehlern ausgesetzt sein. 

Eine ähnliche Fehlerquelle kann die automatische Aktualisierungsfunktion der meisten Anwendungen sein, die nicht unbedingt eine gründliche Integritätsprüfung beinhaltet. Dies öffnet Angreifern Tür und Tor, um ihre Updates zu verbreiten, die Sicherheitslücken schaffen sollen. 

Schließlich umfasst diese Kategorie auch das, was in der Liste von 2017 als „Insecure Deserialization“ bezeichnet wurde. Fehler, die hier auftreten, sind auf Objekte oder Daten zurückzuführen, die in eine Struktur kodiert oder serialisiert wurden, die für einen Angreifer sichtbar ist und die er ändern kann.

Wie können Software- und Daten Integritätsfehler verhindert werden?

Zum Schutz vor unsicherer Deserialisierung empfiehlt OWASP die folgenden Schritte:

• Verwenden Sie Mechanismen wie digitale Signaturen, um zu überprüfen, dass Software oder Daten aus einer Quelle nicht manipuliert wurden
• Stellen Sie sicher, dass Bibliotheken und Abhängigkeiten nur von vertrauenswürdigen Repositorien genutzt werden, oder erwägen Sie bei einem höheren Risikoprofil die Einrichtung eines internen Repositories, das als „known good“ eingestuft ist
• Verwenden Sie ein Sicherheitstool für die Software-Lieferkette, um sicherzustellen, dass die Komponenten keine bekannten Schwachstellen aufweisen
• Führen Sie einen Prüfprozess für Code- und Konfigurationsänderungen ein, um das Risiko zu verringern, dass bösartiger Code oder Konfigurationen in Ihre Software-Pipeline eingefügt werd
• Implementieren Sie eine gründliche Trennung, Konfiguration und Zugriffskontrolle für Ihre CI/CD-Pipeline, um die Integrität des Codes zu gewährleisten, der die Build- und Bereitstellungsprozesse durchläuft
• Stellen Sie sicher, dass keine unsignierten oder unverschlüsselten serialisierten Daten an nicht vertrauenswürdige Clients gesendet werden, ohne dass zuvor eine Integritätsprüfung oder eine digitale Signatur durchgeführt wurde, um Manipulationen oder eine erneute Wiedergabe der Daten zu erkennen 

Sicherheit Protokollierung und Überwachung – A09:2021

Die Sicherheit Protokollierung und Überwachung Kategorie, die früher als „Insufficient Logging & Monitoring“ bekannt war, wurde erweitert und umfasst nun mehr Arten von Fehlern. Obwohl Logging und Monitoring schwierig zu testen sind, ist diese Kategorie von entscheidender Bedeutung, da Fehler Auswirkungen auf die Zuverlässigkeit, Transparenz, Alarmierung bei Vorfällen und die Forensik haben können.

Fehler beim Logging, Erkennen, Monitoring und bei einer betrieblichen Reaktion treten auf, wenn:

• Anmeldungen, fehlgeschlagene Anmeldungen, Transaktionen mit hohem Wert und andere Arten von prüfbaren Ereignissen nicht protokolliert werden
• Bei Warnungen und Fehlern unzureichende, unklare oder gar keine Meldungen erzeugt werden
• API- und Anwendungsprotokolle nicht auf verdächtige Aktivitäten untersucht werden
• Sie Protokolle nur lokal speichern
• Schwellenwerte für Warnungen und Eskalationsprozesse für Reaktionen nicht eingeführt oder nicht wirksam sind
• Warnungen nicht durch Penetration Testing oder Scans durch dynamische Anwendungstests ausgelöst werden
• Die Anwendung aktive Angriffe nicht in Echtzeit oder nahezu in Echtzeit erkennen, eskalieren oder Alarm schlagen kann

Wenn Logging- und Alert-Ereignisse für Benutzer oder Angreifer sichtbar sind, kann Ihre Anwendung zudem einem Informationsleck ausgesetzt sein.

Wie können Sicherheit Protokollierung und Überwachung verhindert werden?

Um die Schwachstellen zu verhindern, die durch diese Fehler entstehen können, empfiehlt OWASP, je nach Schwere des Risikos einige der folgenden Kontrollen zu implementieren:

• Protokollieren Sie alle Fehler bei der Anmeldung, Zugriffskontrolle und serverseitigen Eingabevalidierung mit ausreichendem Benutzerkontext, um verdächtige oder bösartige Konten zu erkennen. Speichern Sie sie lange genug, um eine verzögerte forensische Analyse durchzuführen
• Stellen Sie sicher, dass die Logs in einem Format vorliegen, das leicht von Log-Management-Lösungen verarbeitet werden kann
• Vermeiden Sie Injections oder Angriffe auf die Logging- oder Monitoringsysteme, indem Sie die Logdaten richtig kodieren
• Implementieren Sie einen Audit Trail mit Integritätskontrollen für hochwertige Transaktionen, wie z. B. „append-only“-Datenbanktabellen, um Manipulationen oder Löschungen zu verhindern
• Einrichtung einer wirksamen Überwachung und Alarmierung, um verdächtige Aktivitäten zu erkennen und schnell darauf zu reagieren
• Einführung oder Übernahme eines Reaktions- und Wiederherstellungsplans für Zwischenfälle, z. B. National Institute of Standards and Technology (NIST) 800-61r2 oder neuer

Server-Side Request Forgery (SSRF) – A10:2021

Server-side request forgery (SSRF) tritt auf, wenn eine Webanwendung die vom Benutzer angegebene URL beim Abrufen einer entfernten Ressource nicht validiert. Dadurch können Angreifer die Anwendung dazu zwingen, eine manipulierte Anfrage an ein unerwartetes Ziel zu senden, selbst wenn diese durch eine Firewall, ein VPN oder eine andere Art von Netzwerk-Zugriffskontrollliste (ACL) geschützt ist.

Das Abrufen einer URL ist ein gängiges Merkmal moderner Webanwendungen, was zu einer Zunahme von SSRF-Fällen führt. Darüber hinaus werden diese aufgrund der zunehmenden Komplexität von Architekturen und Cloud-Diensten immer gravierender.

Wie kann Server-Side Request Forgery verhindert werden?

OWASP schlägt verschiedene Maßnahmen vor, um SSRF zu verhindern. Dazu gehört die Implementierung von Defense-in-Depth-Kontrollen in einer oder mehreren Stufen.

Prävention auf der Netzwerkebene:

• Auswirkungen von SSRF durch Segmentierung der Fernzugriffsfunktionalität in getrennten Netzen verringern
• Gesamten Datenverkehr mit Ausnahme des unverzichtbaren Datenverkehrs durch die Einführung von „Deny by Default“-Netzwerkrichtlinien oder Netzwerkzugangskontrollregeln blockieren
  • Eigentumsrechten und Lebenszyklus für Firewall-Regeln in Abhängigkeit von der Anwendung einführen 
  • Logging aller akzeptierten und blockierten Netzwerkflüsse auf Firewalls

Prävention auf der Anwendungsebene:

• Alle vom Kunden bereitgestellten Eingabedaten müssen bereinigt und validiert werden
• Verwenden Sie eine positive “allow list”, um das URL-Schema, den Port und das Ziel durchzusetzen
• Senden Sie keine rohen Antworten an Kunden
• Deaktivieren Sie HTTP-Umleitungen
• Vermeiden Sie Angriffe wie DNS-Rebinding und “Time of Check, Time of Use” Race Bedingungen (TOCTOU), indem Sie die Einheitlichkeit der URL überprüfen
• Verwenden Sie keine Deny-Listen oder reguläre Ausdrücke, um SSRF zu entschärfen – diese können auf verschiedene Weise umgangen werden

Andere mögliche Maßnahmen: 

• Kontrolle des lokalen Datenverkehrs auf Frontsystemen anstelle des Einsatzes anderer Sicherheitsdienste
• Bei sehr hohem Bedarf an Schutz sollten Sie die Netzwerkverschlüsselung auf unabhängigen Systemen mit Frontends einsetzen, die über spezielle und zu verwaltende Benutzergruppen verfügen