TL;DR

OWASP ASVS ist eine detaillierte, von der Community getragene Checkliste zur Verifizierung der Sicherheit von Web-Anwendungen – genutzt von Entwickelnden, Testern und Architekten.

Deckt Bereiche wie AuthN, AuthZ, Krypto und API-Sicherheit ab – aufgeteilt in L1 (Basis) bis L3 (kritische Anwendungen).

Keine Zertifizierung, aber ideal zum Festlegen von Sicherheits-Baselines, zum Leiten von Pen-Tests oder zum Aufbau sicherer Anwendungen von Grund auf.

Zusammenfassung der OWASP ASVS Scorecard:

• Aufwand für Entwickelnde: Moderat bis Hoch (Erfordert das Verständnis detaillierter Sicherheitskontrollen über viele Domänen hinweg und deren korrekte Implementierung während der Entwicklung; wird als Benchmark während des Testens verwendet).
• Tooling-Kosten: Niedrig bis moderat (der Standard selbst ist kostenlos; Kosten beziehen sich auf Tools, die für Tests gegen ASVS-Anforderungen verwendet werden – SAST, DAST, IAST, Penetrationstesting-Tools).
• Marktauswirkungen: Hoch (Weit anerkannter Industriestandard für die Verifizierung der Sicherheit von Webanwendungen; wird oft als Grundlage für die Definition von Sicherheitsanforderungen und Testumfängen verwendet).
• Flexibilität: Hoch (Stufen ermöglichen eine Anpassung basierend auf dem Risiko; spezifische Anforderungen können als nicht anwendbar erachtet werden).
• Auditintensität: N/A (Kein formaler Auditstandard für die Zertifizierung, wird aber während 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 ein Framework von Sicherheitsanforderungen und -kontrollen speziell zur Überprüfung der Sicherheit von Webanwendungen bereitstellt. Es dient zwei Hauptzwecken:

1. Für Entwickelnde: Bietet eine detaillierte Liste von Sicherheitsanforderungen zur Anleitung sicherer Entwicklungspraktiken.
2. Für Tester: Bietet eine Grundlage für das Testen technischer Sicherheitskontrollen von Webanwendungen während Sicherheitsbewertungen, Penetrationstests oder sicheren Code-Reviews.

Der OWASP ASVS ist in Kapitel gegliedert, die zentrale Sicherheitsbereiche abdecken:

• V1: Architektur, Design und Bedrohungsmodellierung
• V2: Authentifizierung
• V3: Sitzungsverwaltung
• V4: Zugriffskontrolle
• V5: Validierung, Bereinigung und Kodierung
• V6: Gespeicherte Kryptografie
• V7: Fehlerbehandlung und Protokollierung
• V8: Datenschutz
• V9: Kommunikationssicherheit
• V10: Bösartiger Code
• V11: Geschäftslogik
• V12: Dateien und Ressourcen
• V13: API und Webdienst
• V14: Konfiguration

Innerhalb jedes Kapitels sind spezifische Verifizierungsanforderungen (Kontrollen) aufgeführt. Entscheidend ist, dass das OWASP ASVS drei Security Verification Levels (ASVS Levels) definiert, die zunehmende Tiefe und Strenge anzeigen:

• Stufe 1 (Geringe Sicherheit): Vorgesehen für Anwendungen mit geringem Risiko oder als erster Schritt. Es konzentriert sich auf leicht erkennbare Schwachstellen und Kontrollen, die oft automatisch überprüft werden können (z. B. grundlegendes Penetration Testing). Jede Anwendung sollte mindestens Stufe 1 anstreben.
• Level 2 (Standard-Sicherheit): Empfohlen für die meisten Anwendungen, insbesondere solche, die sensible Daten verarbeiten oder wichtige Transaktionen durchführen. Erfordert detailliertere Prüfungen zum Schutz vor gängigen Anwendungssicherheitsrisiken (wie den OWASP Top 10). Erfordert sowohl automatisierte als auch manuelle Tests, einschließlich Design-/Code-Review-Elementen.
• Stufe 3 (Hohe Sicherheit): Für kritische Anwendungen, die hochsensible Daten verarbeiten (z. B. Finanz-, Gesundheits-, Regierungsdaten). Erfordert eine umfassende Sicherheitsüberprüfung, einschließlich detaillierter Design-Reviews, Code-Reviews und rigoroser Tests, um erfahrenen Angreifern standzuhalten.

Das erforderliche Level bestimmt, welche spezifischen Verifizierungsanforderungen innerhalb jedes Kapitels erfüllt werden müssen.

Warum ist es wichtig?

OWASP ASVS ist ein Eckpfeiler der modernen Web-Anwendungssicherheit, weil:

• Bietet Standardisierung: Bietet einen konsistenten, wiederholbaren Standard dafür, was eine sichere Webanwendung ausmacht, und geht über Ad-hoc-Tests hinaus.
• Umsetzbare Leitlinien: Gibt Entwickelnden konkrete Anforderungen und Testern spezifische Punkte zur Überprüfung, wodurch die Lücke zwischen übergeordneten Prinzipien und Implementierung geschlossen wird.
• Risikobasierter Ansatz: Das Stufensystem ermöglicht es Organisationen, Verifizierungsbemühungen an das Risikoprofil der Anwendung anzupassen.
• Ergänzt OWASP Top 10: Während die Top 10 gängige Risiken auflistet, bietet ASVS die detaillierten Kontrollen, die zur Minderung dieser Risiken (und vieler anderer) erforderlich sind.
• Branchenanerkennung: Weltweit von Entwickelnden, Sicherheitsexperten und softwarebeschaffenden Organisationen hoch angesehen und genutzt.
• Unterstützt sicheren SDLC: Kann während des gesamten SDLC integriert werden – indem es Anforderungen definiert, Design/Codierung leitet und die Grundlage für Verifikationstests bildet.
• Open Source & Community-gesteuert: Frei verfügbar und ständig von einer globalen Gemeinschaft von Sicherheitsexperten aktualisiert.

Die Verwendung von OWASP ASVS trägt dazu bei, sicherzustellen, dass Sicherheitstests gründlich, konsistent und auf die tatsächlich relevanten Kontrollen zum Schutz von Webanwendungen ausgerichtet sind.

Was und wie implementieren (Technisch & Policy)

Bei der Implementierung von OWASP ASVS geht es nicht um eine Zertifizierung, sondern darum, den Standard zum Erstellen und Überprüfen sicherer Anwendungen zu nutzen:

1. Erforderliches Level bestimmen: Basierend auf der Datenempfindlichkeit, der Geschäftskritikalität und den regulatorischen Anforderungen der Anwendung wählen Sie das Ziel-ASVS-Level (1, 2 oder 3).
2. In Anforderungen integrieren (Designphase): Verwenden Sie die ASVS-Anforderungen für die gewählte Stufe (und relevante Kapitel) als Input für Sicherheitsanforderungen während der Design- und Planungsphasen.
   
   • Beispiel (V4 Zugriffssteuerung): Wenn Sie eine App entwickeln, die verschiedene Benutzerrollen erfordert, überprüfen Sie die ASVS-Kapitel-V4-Anforderungen wie V4.1.1 („Überprüfen Sie, ob die Anwendung Zugriffssteuerungsregeln auf einer vertrauenswürdigen Dienstschicht durchsetzt...“) und gestalten Sie das System entsprechend.
3. Entwicklung leiten (Codierungsphase): Entwickelnde nutzen ASVS-Anforderungen als Checkliste, um sicherzustellen, dass sichere Codierungspraktiken eingehalten werden.
   
   • Beispiel (V5 Eingabevalidierung): Beim Erstellen von Eingabeformularen beziehen Sie sich auf V5-Anforderungen wie V5.1.1 („Überprüfen Sie, ob die Anwendung Abwehrmaßnahmen gegen HTTP-Parameter-Pollution besitzt...“) und V5.2.1 („Überprüfen Sie, ob strukturierte Daten stark typisiert sind...“). Implementieren Sie Eingabevalidierungsbibliotheken und -routinen, die diese Anforderungen erfüllen.
4. Informatives Security Testing (Verifikationsphase): Sicherheitstester (Penetrationstester, Code-Reviewer) nutzen die ASVS-Checkliste für das Ziel-Level, um ihre Bewertung zu strukturieren. Sie überprüfen, ob jede zutreffende Anforderung erfüllt wurde.
   
   • Beispiel (V2 Authentifizierung): Ein Tester, der Stufe 2 überprüft, würde Anforderungen wie V2.2.1 („Überprüfen Sie, ob die Mindestpasswortlänge 12 Zeichen beträgt...“), V2.1.1 („Überprüfen Sie, ob Anmeldeinformationen niemals in wiederherstellbarer Form gespeichert werden...“) und V2.4.1 („Überprüfen Sie, ob ein Kontosperrmechanismus vorhanden ist...“) prüfen.
5. Tooling-Integration:
   
   • SAST-/DAST-Tools: Konfigurieren Sie Scanner, um Verstöße im Zusammenhang mit ASVS-Anforderungen zu prüfen (z. B. das Auffinden potenzieller Injection-Schwachstellen im Zusammenhang mit V5).
   • Checklisten-Management: Verwenden Sie Tabellenkalkulationen oder Tools wie SecurityRAT, um die ASVS-Anforderungen zu verwalten, die Anwendbarkeit zu verfolgen und Verifizierungsergebnisse aufzuzeichnen.
6. Dokumentation: Dokumentieren Sie, wie die ASVS-Anforderungen erfüllt wurden (oder warum sie als nicht anwendbar erachtet wurden) als Teil von Designdokumenten, Code-Kommentaren und Testberichten.

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

Häufige Fehler, die es zu vermeiden gilt

Bei der Verwendung von OWASP ASVS sind diese häufigen Fehler zu beachten:

1. Wahl der falschen Stufe: Die Auswahl von Stufe 1 für eine Hochrisikoanwendung oder das Anstreben von Stufe 3, wenn die Ressourcen nur eine Verifizierung auf Stufe 2 zulassen, führt zu unzureichenden oder unvollständigen Bewertungen.
2. Als reine Pentest-Checkliste behandeln: ASVS ist umfassender als nur Pentesting; Level 2 und 3 erfordern Design- und Code-Review-Aspekte. Sich ausschließlich auf dynamisches Scannen zu verlassen, übersieht entscheidende Schwachstellen.
3. Anwendbarkeit ignorieren: Jede einzelne Anforderung blind anzuwenden versuchen, ohne zu prüfen, ob sie für die Architektur, den Technologie-Stack oder die Funktionen der spezifischen Anwendung relevant ist.
4. Mangelnde Schulung der Entwickelnden: Von Entwickelnden zu erwarten, ASVS-Anforderungen zu erfüllen, ohne sie in den zugrunde liegenden Sicherheitskonzepten und benötigten sicheren Kodierungspraktiken zu schulen.
5. Inkonsistente Anwendung: ASVS bei einem Test rigoros, beim nächsten jedoch oberflächlich anzuwenden, führt zu einer inkonsistenten Sicherheitslage.
6. Keine frühzeitige Integration: ASVS wird erst ganz am Ende für Tests eingesetzt, anstatt es von Anfang an zur Gestaltung sicherer Designs und Entwicklungen zu nutzen (was weitaus effektiver ist).
7. Fehlinterpretation von Anforderungen: Das Versäumnis, die Nuancen oder die Absicht hinter spezifischen ASVS-Verifizierungsanforderungen zu verstehen.

Was Auditoren/Tester fragen werden (Fokus auf Entwickelnde)

Sicherheitstester, die OWASP ASVS verwenden, werden Entwickelnde im Wesentlichen bitten (direkt oder über Code-/Design-Reviews), zu demonstrieren, wie spezifische 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 Session-Tokens generiert und vor Hijacking geschützt?“ (3.1.1, 3.3.1 - L1+)
• (V4) „Demonstrieren Sie, wie die Anwendung verhindert, dass ein Standardbenutzer auf Admin-Funktionalitäten zugreift.“ (4.1.1, 4.1.2 - L1+)
• (V5) „Zeigen Sie mir die Input-Validierungsroutinen, die für diesen kritischen API-Endpunkt verwendet werden.“ (5.1.3, 5.2.1 - L1+)
• (V6) „Wo und wie werden kryptografische Schlüssel innerhalb der Anwendung verwaltet?“ (6.2.1 - L2+)
• (V7) „Wie behandelt die Anwendung Fehler, ohne sensible Informationen preiszugeben?“ (7.1.1 - L1+)
• (V8) „Wie werden sensible Daten geschützt, wenn sie in der Datenbank gespeichert werden (Verschlüsselung, Maskierung)?“ (8.1.1 - L2+)
• (V13) „Wie werden Authentifizierung und Autorisierung für API-Anfragen gehandhabt?“ (13.1.1, 13.2.1 - L1+)

Sie werden konkrete Nachweise im Code, in der Konfiguration, in Designdokumenten oder in der laufenden Anwendung suchen, um die Compliance mit jeder relevanten ASVS-Anforderung für das Ziellevel zu überprüfen.

Quick Wins für Entwicklungsteams

Entwickelnde können die Prinzipien von OWASP ASVS einfach integrieren:

1. Fokus auf Level-1-Grundlagen: Beginnen Sie mit der Überprüfung und Implementierung der Level-1-Anforderungen in Schlüsselbereichen wie Authentifizierung (V2), Zugriffskontrolle (V4) und Eingabevalidierung (V5). Diese decken viele häufige Schwachstellen ab.
2. Sichere Framework-Standardeinstellungen verwenden: Nutzen Sie die integrierten Sicherheitsfunktionen Ihres Web-Frameworks (z. B. für Session Management, CSRF-Schutz, Output Encoding), die oft mit ASVS übereinstimmen.
3. Validieren und Kodieren: Validieren Sie alle Eingaben und kodieren Sie alle Ausgaben, die für Browser, APIs oder Datenbanken bestimmt sind, konsistent. (Kern von V5)
4. Grundlegendes Logging implementieren: Stellen Sie sicher, dass wichtige Sicherheitsereignisse (Anmeldungen, Fehler, signifikante Transaktionen) geloggt werden. (Kern von V7)
5. OWASP Top 10 überprüfen: Verstehen Sie die Top 10 Risiken und wie ASVS-Kontrollen zu deren Minderung beitragen.
6. SAST-Tools verwenden: Konfigurieren Sie SAST-Tools, um Verstöße im Zusammenhang mit gängigen ASVS-Anforderungen zu kennzeichnen (z. B. unsichere Passwortbehandlung, potenzielle Injection-Punkte).

Ignorieren Sie dies und... (Konsequenzen der Nichteinhaltung)

Das Ignorieren der in OWASP ASVS dargelegten Prinzipien und Anforderungen bedeutet, grundlegende Sicherheitskontrollen für Webanwendungen zu vernachlässigen. Die Konsequenzen sind direkt:

• Höhere Wahrscheinlichkeit von Sicherheitsverletzungen: Anwendungen sind anfälliger für gängige Angriffe wie XSS, SQL Injection, fehlerhafte Authentifizierung, fehlerhafte Zugriffskontrolle usw. (direkt bezogen auf ASVS-Kapitel).
• Datenverlust/-diebstahl: Schwachstellen ermöglichen es Angreifern, sensible Benutzerdaten zu stehlen, was zu Datenschutzverletzungen und behördlichen Bußgeldern (z. B. DSGVO) führt.
• Dienstunterbrechung: Angriffe können Anwendungen offline nehmen, was zu Geschäftsunterbrechungen und Umsatzverlusten führt.
• Reputationsschaden: Sicherheitsvorfälle untergraben das Kundenvertrauen und schädigen die Marke des Unternehmens.
• Fehlgeschlagene Sicherheitsaudits/Pentests: Wenn Kunden oder Partner Sicherheitstests verlangen, wird eine Anwendung, die nicht nach ASVS-Prinzipien entwickelt wurde, wahrscheinlich scheitern, was möglicherweise Geschäfte oder Deployments blockiert.
• Erhöhte Behebungskosten: Schwachstellen spät im Zyklus oder nach einer Sicherheitsverletzung zu finden und zu beheben, ist weitaus kostspieliger, als Sicherheit von Anfang an unter Verwendung von ASVS als Leitfaden zu integrieren.

Im Wesentlichen bedeutet die Nichteinhaltung von OWASP ASVS, von Natur aus unsichere Webanwendungen zu entwickeln.

FAQ

Ist OWASP ASVS ein Compliance-Standard wie SOC 2 oder ISO 27001?

Nein. OWASP ASVS ist ein Verifizierungsstandard, im Wesentlichen eine detaillierte Checkliste für das Testen der Sicherheit von Webanwendungen. Er beinhaltet keine formalen Audits oder Zertifizierungen wie SOC 2 oder ISO 27001, die breitere Managementsysteme abdecken. Das Erreichen von ASVS-Levels kann jedoch dazu beitragen, technische Kontrollanforderungen innerhalb dieser breiteren Frameworks zu erfüllen.

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

Die OWASP Top 10 listet die zehn kritischsten Webanwendungssicherheitsrisiken basierend auf Community-Konsens und Daten auf. OWASP ASVS bietet die detaillierten Sicherheitskontrollen und Verifizierungsanforderungen, die zur Vorbeugung und zum Testen dieser Risiken (und vieler anderer) erforderlich sind. Die Top 10 sagt Ihnen, was die Hauptprobleme sind; ASVS sagt Ihnen, wie Sie Ihre Abwehrmaßnahmen dagegen überprüfen können.

Welches ASVS-Level sollten wir anstreben?

Es hängt vom Risiko ab. Level 1 ist die minimale Basislinie für alle Anwendungen. Level 2 wird für die meisten Anwendungen empfohlen, die sensible Daten oder Transaktionen verarbeiten. Level 3 ist für hochkritische Anwendungen, bei denen ein Ausfall schwerwiegende Folgen (z. B. finanzielle, gesundheitsbezogene Daten) hätte.

Müssen wir 100 % der Anforderungen für ein bestimmtes Level erfüllen?

Im Allgemeinen ja, für alle anwendbaren Anforderungen. Der Standard erlaubt es, Anforderungen als „nicht anwendbar“ zu kennzeichnen, wenn sie tatsächlich nicht auf die Technologie oder Funktionalität der Anwendung zutreffen, dies erfordert jedoch eine Begründung. Kompensierende Kontrollen können manchmal akzeptiert werden, wenn eine spezifische Anforderung nicht direkt erfüllt werden kann.

Ist ASVS nur für Penetrationstests?

Nein. Obwohl im Penetration Testing (insbesondere Level 1) stark genutzt, erfordern ASVS Level 2 und 3 explizit eine Verifizierung über dynamische Tests hinaus, einschließlich Überprüfungen von Architektur, Design und Quellcode. Es ist für eine ganzheitliche Anwendungssicherheitsverifizierung gedacht.

Wie oft sollten wir uns gegen ASVS verifizieren?

Die Verifizierung sollte in den SDLC integriert werden. Dies könnte bedeuten, relevante Anforderungen während Code-Reviews zu überprüfen, automatisierte Tests, die mit ASVS in CI/CD abgestimmt sind, auszuführen und vollständige ASVS-Assessments (auf der Zielstufe) vor wichtigen Releases oder regelmäßig (z. B. jährlich) für kritische Anwendungen durchzuführen.

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

OWASP ASVS Kapitel V13 befasst sich speziell mit der Verifizierung von APIs und Webdiensten. Obwohl der Fokus primär auf Web-Anwendungen liegt, sind viele Prinzipien breit anwendbar. Für mobile Besonderheiten bietet OWASP auch den Mobile Application Security Verification Standard (MASVS).