TL;DR

OWASP ASVS ist eine detaillierte, von der Community erstellte Checkliste zur Überprüfung der Sicherheit von Webanwendungen, die von Entwicklern, Testern und Architekten verwendet wird.

Deckt Bereiche wie AuthN, AuthZ, Krypto, API-Sicherheit ab - unterteilt in L1 (grundlegende Anwendungen) bis L3 (kritische Anwendungen).

Kein Zertifikat, aber ideal für die Festlegung von Sicherheitsgrundlagen, die Durchführung von Pen-Tests oder die Entwicklung sicherer Anwendungen von Grund auf.

OWASP ASVS Scorecard Zusammenfassung:

• Entwickelnde Aufwand: Mäßig bis hoch (Erfordert das Verständnis detaillierter Sicherheitskontrollen in vielen Bereichen und deren korrekte Umsetzung während der Entwicklung; wird als Maßstab während der Tests verwendet).
• Kosten für die Werkzeuge: Gering bis mäßig (der Standard selbst ist kostenlos; die Kosten beziehen sich auf die Werkzeuge, die für die Prüfung der ASVS-Anforderungen verwendet werden - SAST, DAST, IAST, Pen-Test-Tools).
• Marktwirkung: Hoch (Weithin anerkannter Industriestandard für die Überprüfung der Sicherheit von Webanwendungen; wird häufig als Grundlage für die Definition von Sicherheitsanforderungen und Testumfängen verwendet).
• Flexibilität: Hoch (Die Stufen ermöglichen eine risikobasierte Anpassung; spezifische Anforderungen können als nicht anwendbar betrachtet werden).
• Intensität der Prüfung: N/A (kein formeller Audit-Standard für die Zertifizierung, aber bei Sicherheitsbewertungen/-tests verwendet, die intensiv sein können).

Was ist OWASP ASVS?

Der OWASP Application Security Verification Standard (ASVS) ist ein Open-Source-Projekt, das einen Rahmen von Sicherheitsanforderungen und Kontrollen speziell für die Überprüfung der Sicherheit von Webanwendungen bereitstellt. Er dient zwei Hauptzwecken:

1. Für Entwickler: Bietet eine detaillierte Liste von Sicherheitsanforderungen als Leitfaden für sichere Entwicklungspraktiken.
2. Für Prüfer: Bietet eine Grundlage für das Testen der technischen Sicherheitskontrollen von Webanwendungen im Rahmen von Sicherheitsbewertungen, Penetrationstests oder Secure Code Reviews.

Die OWASP ASVS ist in Kapitel gegliedert, die wichtige Sicherheitsbereiche abdecken:

• V1: Architektur, Design und Bedrohungsmodellierung
• V2: Authentifizierung
• V3: Sitzungsmanagement
• V4: Zugangskontrolle
• V5: Validierung, Sanitisierung und Kodierung
• V6: Gespeicherte Kryptographie
• V7: Fehlerbehandlung und Protokollierung
• V8: Datenschutz
• V9: Sicherheit der Kommunikation
• V10: Bösartiger Code
• V11: Geschäftslogik
• V12: Datei und Ressourcen
• V13: API und Webdienst
• V14: Konfiguration

Innerhalb jedes Kapitels werden spezifische Überprüfungsanforderungen (Kontrollen) aufgeführt. Entscheidend ist, dass die OWASP ASVS drei Sicherheitsüberprüfungsstufen (ASVS Levels) definiert, die einen zunehmenden Grad an Tiefe und Strenge angeben:

• Stufe 1 (geringe Sicherheit): Gedacht für Anwendungen mit geringem Risiko oder als erster Schritt. Der Schwerpunkt liegt auf leicht erkennbaren Schwachstellen und Kontrollen, die häufig automatisch überprüft werden können (z. B. einfache Penetrationstests). Jede Anwendung sollte mindestens Stufe 1 anstreben.
• Stufe 2 (Standard-Zuverlässigkeit): Empfohlen für die meisten Anwendungen, insbesondere für solche, die sensible Daten verarbeiten oder wichtige Transaktionen durchführen. Erfordert eingehendere Prüfungen, die den Schutz vor gängigen Anwendungssicherheitsrisiken abdecken (wie die OWASP Top 10). Erfordert sowohl automatisierte als auch manuelle Tests, einschließlich Elementen der Entwurfs-/Codeüberprüfung.
• Stufe 3 (Hohe Sicherheit): Für kritische Anwendungen, die mit hochsensiblen Daten umgehen (z. B. Finanzwesen, Gesundheitswesen, Behörden). Erfordert eine umfassende Sicherheitsüberprüfung, einschließlich einer gründlichen Entwurfsprüfung, Codeüberprüfung und strengen Tests, um geschickten Angreifern standzuhalten.

Das geforderte Niveau bestimmt, welche spezifischen Prüfanforderungen innerhalb jedes Kapitels erfüllt werden müssen.

Warum ist sie wichtig?

OWASP ASVS ist ein Eckpfeiler der modernen Webanwendungssicherheit, denn:

• Bietet Standardisierung: Bietet einen konsistenten, wiederholbaren Standard dafür, was eine sichere Webanwendung ausmacht und geht damit über Ad-hoc-Tests hinaus.
• Umsetzbare Anleitungen: Gibt den Entwicklern konkrete Anforderungen und den Testern spezifische zu überprüfende Elemente an die Hand und schließt so die Lücke zwischen den übergeordneten Grundsätzen und der Umsetzung.
• Risikobasierter Ansatz: Das Stufensystem ermöglicht es Unternehmen, den Überprüfungsaufwand auf der Grundlage des Risikoprofils der Anwendung anzupassen.
• Ergänzt die OWASP Top 10: Während die Top 10 gängige Risiken auflistet, bietet ASVS die detaillierten Kontrollen, die zur Minderung dieser (und vieler anderer) Risiken erforderlich sind.
• Anerkennung in der Branche: Weithin respektiert und weltweit von Entwicklern, Sicherheitsexperten und Organisationen, die Software beschaffen, verwendet.
• Unterstützt sicheren SDLC: Kann in den gesamten SDLC integriert werden - Definition von Anforderungen, Anleitung für Design/Codierung und als Grundlage für Verifizierungstests.
• Open Source & Community-gesteuert: Frei verfügbar und ständig aktualisiert von einer globalen Gemeinschaft von Sicherheitsexperten.

Die Verwendung von OWASP ASVS trägt dazu bei, dass die Sicherheitstests gründlich und konsistent sind und sich auf die Kontrollen konzentrieren, die für den Schutz von Webanwendungen tatsächlich wichtig sind.

Was und wie umsetzen (technisch und politisch)

Bei der Implementierung von OWASP ASVS geht es nicht darum, sich zertifizieren zu lassen, sondern darum, den Standard zu nutzen, um sichere Anwendungen zu erstellen und zu verifizieren:

1. Erforderliche Stufe bestimmen: Wählen Sie auf der Grundlage der Datensensibilität der Anwendung, der Kritikalität des Geschäfts und der gesetzlichen Anforderungen die gewünschte ASVS-Stufe (1, 2 oder 3).
2. In die Anforderungen integrieren (Entwurfsphase): Verwenden Sie die ASVS-Anforderungen für die gewählte Stufe (und die entsprechenden Kapitel) als Input für die Sicherheitsanforderungen während der Entwurfs- und Planungsphase.
   
   • Beispiel (V4 Zugriffskontrolle): Wenn Sie eine Anwendung entwickeln, die verschiedene Benutzerrollen erfordert, prüfen Sie die Anforderungen des ASVS-Kapitels V4, z. B. V4.1.1 ("Stellen Sie sicher, dass die Anwendung Zugriffskontrollregeln auf einer vertrauenswürdigen Dienstebene durchsetzt..."), und entwerfen Sie das System entsprechend.
3. Leitfadenentwicklung (Kodierungsphase): Die Entwickler verwenden die ASVS-Anforderungen als Checkliste, um sicherzustellen, dass sichere Kodierungsverfahren eingehalten werden.
   
   • Beispiel (V5-Eingabevalidierung): Beziehen Sie sich bei der Erstellung von Eingabeformularen auf die V5-Anforderungen wie V5.1.1 ("Überprüfen Sie, ob die Anwendung Schutzmaßnahmen gegen HTTP-Parameterverschmutzung bietet...") und V5.2.1 ("Überprüfen Sie, ob strukturierte Daten stark typisiert sind..."). Implementieren Sie Eingabevalidierungsbibliotheken und -routinen, die diese Anforderungen erfüllen.
4. Informieren Sie die Sicherheitstests (Verifizierungsphase): Sicherheitstester (Pen-Tester, Code-Reviewer) verwenden die ASVS-Checkliste für die Zielstufe, um ihre Bewertung zu strukturieren. Sie überprüfen, ob jede anwendbare Anforderung erfüllt ist.
   
   • Beispiel (V2-Authentifizierung): Ein Prüfer, der die Stufe 2 verifiziert, würde Anforderungen wie V2.2.1 ("Überprüfen Sie, dass die Mindestlänge des Passworts 12 Zeichen beträgt..."), V2.1.1 ("Überprüfen Sie, dass die Anmeldeinformationen niemals in wiederherstellbarer Form gespeichert werden...") und V2.4.1 ("Überprüfen Sie, dass es einen Kontosperrmechanismus gibt...") überprüfen.
5. Integration von Werkzeugen:
   
   • SAST/DAST-Werkzeuge: Konfiguration von Scannern zur Prüfung auf Verstöße gegen ASVS-Anforderungen (z. B. Auffinden potenzieller Injektionsfehler im Zusammenhang mit V5).
   • Verwaltung der Checkliste: Verwenden Sie Tabellenkalkulationen oder Tools wie SecurityRAT, um die ASVS-Anforderungen zu verwalten, die Anwendbarkeit zu verfolgen und die Überprüfungsergebnisse aufzuzeichnen.
6. Dokumentation: Dokumentieren Sie, wie die ASVS-Anforderungen erfüllt wurden (oder warum sie als nicht anwendbar erachtet wurden) als Teil der Entwurfsdokumente, Codekommentare und Prüfberichte.

Bei der Implementierung geht es darum, die ASVS-Liste während des gesamten SDLC aktiv zu nutzen - als Leitfaden für eine sichere Entwicklung und als Checkliste für die Überprüfung der Sicherheit.

Häufig zu vermeidende Fehler

Achten Sie bei der Verwendung von OWASP ASVS auf diese häufigen Fehler:

1. Die Wahl der falschen Stufe: Die Wahl von Stufe 1 für eine risikoreiche Anwendung oder das Anstreben von Stufe 3, wenn die Ressourcen nur eine Überprüfung auf Stufe 2 erlauben, was zu unzureichenden oder unvollständigen Bewertungen führt.
2. Es als reine Pentest-Checkliste zu behandeln: ASVS ist breiter angelegt als nur Pentesting; die Stufen 2 und 3 erfordern Aspekte des Entwurfs und der Codeüberprüfung. Wer sich nur auf das dynamische Scannen verlässt, übersieht entscheidende Schwachstellen.
3. Ignorieren der Anwendbarkeit: Der blinde Versuch, jede einzelne Anforderung anzuwenden, ohne zu prüfen, ob sie für die Architektur, das Technologiepaket oder die Funktionen der jeweiligen Anwendung relevant ist.
4. Mangelnde Entwickelnde : Man erwartet von den Entwicklern, dass sie die ASVS-Anforderungen erfüllen, ohne sie in den zugrundeliegenden Sicherheitskonzepten und den erforderlichen sicheren Codierungsverfahren zu schulen.
5. Inkonsistente Anwendung: Strenge Anwendung von ASVS während eines Tests, aber oberflächliche Anwendung während des nächsten Tests, was zu einer inkonsistenten Sicherheitslage führt.
6. Keine frühzeitige Integration: ASVS wird erst ganz am Ende zu Testzwecken eingesetzt, anstatt es von Anfang an als Grundlage für sicheres Design und sichere Entwicklung zu nutzen (was viel effektiver ist).
7. Fehlinterpretation von Anforderungen: Die Nuancen oder die Absicht hinter bestimmten ASVS-Überprüfungsanforderungen werden nicht verstanden.

Was Auditoren/Tester fragen werdenEntwickelnde Focus)

Sicherheitsprüfer, die OWASP ASVS verwenden, fordern die Entwickler im Wesentlichen auf (direkt oder über eine Code-/Entwurfsprüfung), nachzuweisen, wie bestimmte Anforderungen erfüllt werden:

• (V1) "Können Sie mir das Bedrohungsmodell für diese Anwendung zeigen?" (1.1.1 - L2+)
• (V2) "Wie werden Benutzerpasswörter gespeichert? Können Sie die Hashing-Implementierung zeigen?" (2.2.2 - L1+)
• (V3) "Wie werden Sitzungs-Tokens generiert und wie werden sie gegen Hijacking geschützt?" (3.1.1, 3.3.1 - L1+)
• (V4) "Zeigen Sie, wie die Anwendung den Zugriff eines Standardbenutzers auf die Verwaltungsfunktionen verhindert." (4.1.1, 4.1.2 - L1+)
• (V5) "Zeigen Sie mir die für diesen kritischen API-Endpunkt verwendeten Eingabevalidierungsroutinen." (5.1.3, 5.2.1 - L1+)
• (V6) "Wo und wie werden kryptographische Schlüssel innerhalb der Anwendung verwaltet?" (6.2.1 - L2+)
• (V7) "Wie geht die Anwendung mit Fehlern um, ohne dass sensible Informationen nach außen dringen?" (7.1.1 - L1+)
• (V8) "Wie werden sensible Daten bei der Speicherung in der Datenbank geschützt (Verschlüsselung, Maskierung)?" (8.1.1 - L2+)
• (V13) "Wie wird die Authentifizierung und Autorisierung für API-Anfragen gehandhabt?" (13.1.1, 13.2.1 - L1+)

Sie suchen nach konkreten Beweisen im Code, in der Konfiguration, in den Entwurfsdokumenten oder in der laufenden Anwendung, um die compliance jeder relevanten ASVS-Anforderung für die Zielstufe zu überprüfen.

Quick Wins für Entwicklungsteams

Entwickler können die OWASP ASVS-Prinzipien leicht einbinden:

1. Konzentrieren Sie sich auf die Level 1-Grundlagen: Beginnen Sie mit der Überprüfung und Umsetzung der Anforderungen der Stufe 1 in Schlüsselbereichen wie Authentifizierung (V2), Zugriffskontrolle (V4) und Eingabevalidierung (V5). Diese decken viele häufige Schwachstellen ab.
2. Verwenden Sie sichere Framework-Standardeinstellungen: Nutzen Sie die integrierten Sicherheitsfunktionen Ihres Web-Frameworks (z. B. für Sitzungsverwaltung, CSRF-Schutz, Ausgabekodierung), die häufig mit ASVS übereinstimmen.
3. Validieren und Kodieren: Konsistente Validierung aller Eingaben und Kodierung aller für Browser, APIs oder Datenbanken bestimmten Ausgaben. (Kern von V5)
4. Grundlegende Protokollierung implementieren: Sicherstellen, dass wichtige Sicherheitsereignisse (Anmeldungen, Fehlschläge, wichtige Transaktionen) protokolliert werden (Kern von V7)
5. Überprüfung der OWASP Top 10: Verstehen Sie die Top-10-Risiken und wie ASVS-Kontrollen dazu beitragen, diese abzuschwächen.
6. SAST-Tools verwenden: Konfigurieren Sie die SAST-Tools so, dass sie Verstöße gegen gängige ASVS-Anforderungen (z. B. unsichere Handhabung von Passwörtern, potenzielle Injektionspunkte) anzeigen.

Ignorieren Sie dies und... (Folgen der Compliance)

Das Ignorieren der in OWASP ASVS dargelegten Grundsätze und Anforderungen bedeutet, dass grundlegende Sicherheitskontrollen für Webanwendungen vernachlässigt werden. Die Folgen sind unmittelbar:

• Höhere Wahrscheinlichkeit von Verstößen: Die Anwendungen sind anfälliger für gängige Angriffe wie XSS, SQL Injection, fehlerhafte Authentifizierung, fehlerhafte Zugriffskontrolle usw. (in direktem Zusammenhang mit den ASVS-Kapiteln).
• Datenverlust/Datendiebstahl: Schwachstellen ermöglichen es Angreifern, sensible Nutzerdaten zu stehlen, was zu Datenschutzverletzungen und Bußgeldern führt (z. B. GDPR).
• Unterbrechung von Diensten: Angriffe können Anwendungen offline schalten, was zu Geschäftsunterbrechungen und Umsatzeinbußen führt.
• Schädigung des Rufs: Sicherheitsvorfälle untergraben das Vertrauen der Kunden und schaden der Marke des Unternehmens.
• Fehlgeschlagene Sicherheitsaudits/Pentests: Wenn Kunden oder Partner Sicherheitstests verlangen, wird eine Anwendung, die nicht unter Berücksichtigung der ASVS-Prinzipien entwickelt wurde, wahrscheinlich durchfallen und möglicherweise Geschäfte oder Einsätze blockieren.
• Erhöhte Kosten für die Behebung: Das Auffinden und Beheben von Schwachstellen zu einem späten Zeitpunkt oder nach einer Sicherheitsverletzung ist weitaus kostspieliger als der Aufbau von Sicherheit unter Verwendung von ASVS als Leitfaden.

Die Nichteinhaltung von OWASP ASVS bedeutet im Wesentlichen, dass man inhärent unsichere Webanwendungen erstellt.

FAQ

Ist OWASP ASVS ein compliance wie SOC 2 oder ISO 27001?

Nein. OWASP ASVS ist ein Verifizierungsstandard, im Wesentlichen eine detaillierte Checkliste für die Prüfung der Sicherheit von Webanwendungen. Er beinhaltet keine formellen Audits oder Zertifizierungen wie SOC 2 oder ISO 27001, die umfassendere Managementsysteme abdecken. Die Erfüllung der ASVS-Stufen kann jedoch dazu beitragen, die technischen Kontrollanforderungen innerhalb dieser umfassenderen Rahmenwerke zu erfüllen.

Was ist der Unterschied zwischen OWASP ASVS und OWASP Top 10?

Die OWASP Top 10 listet die zehn kritischsten Sicherheitsrisiken für Webanwendungen auf, die auf dem Konsens der Community und auf Daten basieren. OWASP ASVS liefert die detaillierten Sicherheitskontrollen und Überprüfungsanforderungen, die erforderlich sind, um diese Risiken (und viele andere) zu verhindern und zu testen. Die Top 10 zeigt Ihnen, was die größten Probleme sind; ASVS sagt Ihnen, wie Sie Ihre Schutzmaßnahmen dagegen überprüfen können.

Welche ASVS-Stufe sollten wir anstreben?

Das hängt vom Risiko ab. Stufe 1 ist die Mindestanforderung für alle Anwendungen. Stufe 2 wird für die meisten Anwendungen empfohlen, die sensible Daten oder Transaktionen verarbeiten. Stufe 3 ist für hochkritische Anwendungen gedacht, deren Ausfall schwerwiegende Folgen hat (z. B. Finanz- oder Gesundheitsdaten).

Müssen wir 100% der Anforderungen für eine bestimmte Stufe erfüllen?

Im Allgemeinen ja, für alle anwendbaren Anforderungen. Die Norm lässt es zu, dass Anforderungen als "nicht anwendbar" gekennzeichnet werden, wenn sie tatsächlich nicht auf die Technologie oder Funktionalität der Anwendung zutreffen, aber dies erfordert eine Begründung. Kompensierende Kontrollen können manchmal akzeptiert werden, wenn eine bestimmte Anforderung nicht direkt erfüllt werden kann.

Ist ASVS nur für Penetrationstests geeignet?

Die ASVS-Stufen 2 und 3 werden zwar häufig für Penetrationstests verwendet (insbesondere Stufe 1), erfordern aber ausdrücklich eine Überprüfung, die über dynamische Tests hinausgeht und auch die Architektur, das Design und den Quellcode umfasst. Es ist für eine ganzheitliche Überprüfung der Anwendungssicherheit gedacht.

Wie oft sollten wir gegen ASVS prüfen?

Die Verifizierung sollte in den SDLC integriert werden. Dies könnte bedeuten, dass relevante Anforderungen während der Code-Reviews überprüft werden, dass automatisierte Tests, die mit ASVS in CI/CD abgestimmt sind, ausgeführt werden und dass vollständige ASVS-Bewertungen (auf der Zielebene) vor größeren Releases oder in regelmäßigen Abständen (z. B. jährlich) für kritische Anwendungen durchgeführt werden.

Kann ASVS für APIs und mobile Anwendungen verwendet werden?

OWASP ASVS Kapitel V13 befasst sich speziell mit der Überprüfung von APIs und Webdiensten. Obwohl er sich in erster Linie auf Webanwendungen konzentriert, gelten viele Grundsätze im Allgemeinen. Für mobile Anwendungen hat OWASP auch den Mobile Application Security Verification Standard (MASVS) entwickelt.