Anwendungssicherheitstests: OWASP Top 10, SAST, DAST und SCA Schulung

A01:2025 – Broken Access Control

Zugriffssteuerung erzwingt Richtlinien, sodass Benutzer nicht über die ihnen zugewiesenen Berechtigungen hinaus agieren können. Fehler führen typischerweise zur unbefugten Offenlegung, Änderung oder Zerstörung von Daten oder zur Ausführung von Geschäftsprozessen ausserhalb der Grenzen des Benutzers.

Praktische Aspekte

• Praktische Beispiele für fehlerhafte Zugriffssteuerung

• Sichere Zugriffssteuerung und Best Practices

A02:2025 – Security Misconfiguration

Eine Sicherheitskonfigurationsfehler liegt vor, wenn ein System, eine Anwendung oder ein Cloud-Dienst aus Sicherheitsperspektive falsch eingerichtet wird und so Sicherheitslücken entstehen.

Praktische Aspekte

• Reale Beispiele für Konfigurationsfehler

• Schritte zur Verhinderung von Konfigurationsfehlern, einschliesslich Konfigurationsmanagement und Automatisierungstools

A03:2025 – Software Supply Chain Failures

Fehler in der Software-Lieferkette sind Störungen oder andere Kompromittierungen im Prozess des Bauens, Verbreitens oder Aktualisierens von Software. Sie werden häufig durch Sicherheitslücken oder bösartige Änderungen im Code, in den Tools oder in anderen Abhängigkeiten von Drittanbietern verursacht, auf die das System angewiesen ist.

A04:2025 – Cryptographic Failures

Allgemein gesprochen sollte alle Daten im Transit auf der Transportebene (OSI-Ebene 4) verschlüsselt werden. Frühere Hürden wie CPU-Leistung und das Management von Private Keys/Zertifikaten werden heutzutage durch CPUs mit Instruktionen zur Beschleunigung der Verschlüsselung (z. B. AES-Unterstützung) und vereinfachtem Management von Private Keys und Zertifikaten durch Dienste wie LetsEncrypt.org gelöst, wobei führende Cloud-Anbieter noch stärker integrierte Zertifikatsmanagementdienste für ihre spezifischen Plattformen bereitstellen.

Neben der Absicherung der Transportebene ist es wichtig zu bestimmen, welche Daten beim Ruhen verschlüsselt werden müssen und welche Daten zusätzliche Verschlüsselung im Transit (auf der Anwendungsebene, OSI-Ebene 7) benötigen.

Zum Beispiel benötigen Passwörter, Kreditkartendaten, Gesundheitsdaten, persönliche Informationen und Geschäftsgeheimnisse zusätzlichen Schutz, insbesondere wenn diese Daten unter Datenschutzgesetze, z. B. die EU-Datenschutz-Grundverordnung (DSGVO), oder Vorschriften wie den PCI Data Security Standard (PCI DSS) fallen.

Praktische Aspekte

• Detaillierte Analyse von kryptografischen Fehlern wie schwache Verschlüsselungsalgorithmen oder unsachgemässes Schlüsselmanagement

• Bedeutung starker kryptografischer Mechanismen, sicherer Protokolle (SSL/TLS) und Beispiele für moderne Kryptographie in der Websicherheit

A05:2025 – Injection

Eine Injektionsschwachstelle ist ein Systemfehler, der es einem Angreifer ermöglicht, bösartigen Code oder Befehle (wie SQL- oder Shell-Code) in Eingabefelder eines Programms einzufügen und das System dazu zu verleiten, den Code oder die Befehle auszuführen, als wären sie Teil des Systems. Dies kann zu schwerwiegenden Konsequenzen führen.

Praktische Aspekte

• Detaillierte Aufschlüsselung von SQL-, NoSQL-, OS- und LDAP-Injektionen

• Minderungsmaßnahmen unter Verwendung von vorbereiteten Anweisungen, parametrisierten Abfragen und der Maskierung von Eingaben

A06:2025 – Insecure Design

Unsicheres Design ist eine breite Kategorie, die verschiedene Schwächen darstellt, ausgedrückt als „fehlende oder unwirksame Kontrollgestaltung”.

Unsicheres Design ist nicht die Quelle aller anderen Top-Ten-Risikokategorien. Beachten Sie, dass es einen Unterschied zwischen unsicherem Design und unsicherer Implementierung gibt. Wir unterscheiden zwischen Designfehlern und Implementierungsdefiziten aus einem Grund: Sie haben unterschiedliche Ursachen, treten zu unterschiedlichen Zeitpunkten im Entwicklungsprozess auf und erfordern unterschiedliche Massnahmen zur Behebung.

Ein sicheres Design kann immer noch Implementierungsdefizite aufweisen, die zu ausnutzbaren Sicherheitslücken führen können. Ein unsicheres Design kann nicht durch eine perfekte Implementierung behoben werden, da die erforderlichen Sicherheitskontrollen zum Schutz vor bestimmten Angriffen nie erstellt wurden.

Ein Faktor, der zum unsicheren Design beiträgt, ist das Fehlen eines Profilings der Geschäftsrisiken, die in der entwickelten Software oder im System inhärent sind, und somit das Versagen, das erforderliche Niveau der Sicherheitsgestaltung zu bestimmen.

Praktische Aspekte

• Wir untersuchen Designfehler, die zu Sicherheitslücken führen können, wie unsachgemässe Eingabevalidierung

• Wir lernen Strategien für sichere Architektur und Prinzipien des sicheren Designs

A07:2025 – Authentication Failures

Wenn ein Angreifer ein System dazu bringen kann, einen ungültigen oder falschen Benutzer als legitime zu erkennen, ist diese Schwachstelle vorhanden.

Praktische Aspekte

• Gängige Authentifizierungsprobleme

• Sichere Authentifizierungsstrategien, wie Multi-Faktor-Authentifizierung und sachgemässes Sitzungsmanagement

A08:2025 – Software or Data Integrity Failures

Fehler bei der Integrität von Software oder Daten betreffen Code und Infrastruktur, die nicht davor schützen, dass ungültiger oder nicht vertrauenswürdiger Code oder Daten als vertrauenswürdig und gültig behandelt werden.

Ein Beispiel dafür ist, wenn eine Anwendung auf Plugins, Bibliotheken oder Module aus nicht vertrauenswürdigen Quellen, Repositories und Content Delivery Networks (CDNs) angewiesen ist.

Eine unsichere CI/CD-Pipeline, die keine Softwareintegritätsprüfungen konsumiert und bereitstellt, kann das Potenzial für unbefugten Zugriff, unsicheren oder bösartigen Code oder Systemkompromittierung einführen.

Ein weiteres Beispiel hierfür ist eine CI/CD, die Code oder Artefakte aus nicht vertrauenswürdigen Quellen bezieht und/oder diese vor der Verwendung nicht verifiziert (indem die Signatur oder ein ähnlicher Mechanismus überprüft wird).

Praktische Aspekte

• Fokus auf Probleme wie nicht vertrauenswürdige Softwareupdates und Datenmanipulation

• Sichere Update-Mechanismen und Datenintegritätsprüfungen

A09:2025 – Security Logging and Alerting Failures

Ohne Protokollierung und Überwachung können Angriffe und Sicherheitsverletzungen nicht erkannt werden, und ohne Alarmierung ist es während eines Sicherheitsvorfalls sehr schwierig, schnell und effektiv zu reagieren.

Unzureichende Protokollierung, kontinuierliche Überwachung, Erkennung und Alarmierung zur Einleitung aktiver Reaktionen treten immer wieder auf.

Praktische Aspekte

• Bedeutung der Protokollierung sicherheitsrelevanter Informationen und der Überwachung verdächtiger Aktivitäten

• Tools und Praktiken für die richtige Protokollierung und Echtzeitüberwachung, um Verletzungen früh zu erkennen

A10:2025 – Mishandling of Exceptional Conditions

Das unsachgemässe Behandlung von aussergewöhnlichen Bedingungen in der Software tritt auf, wenn Programme versagen, ungewöhnliche und unvorhersehbare Situationen zu verhindern, zu erkennen und darauf zu reagieren, was zu Abstürzen, unerwartetem Verhalten und manchmal zu Sicherheitslücken führt.

Dies kann einen oder mehrere der folgenden drei Fehler beinhalten:

• Die Anwendung verhindert nicht, dass eine ungewöhnliche Situation eintritt

• Sie identifiziert die Situation nicht, wenn sie eintritt

• Sie reagiert schlecht oder gar nicht auf die Situation im Nachhinein

SAST – Statische Anwendungssicherheitstests

1. Was statische Analyse ist und wann sie im SDLC ausgeführt wird (Shift Left)

2. Arten von Sicherheitslücken, die durch SAST erkannt werden können, fehlerhafter Code vs. sicherer Code

3. Übersicht über SAST-Tools (z. B. Semgrep, SonarQube, Checkmarx, abhängig vom Client-Stack)

4. Praktische Übung: Durchführung eines SAST-Scans in einem Repository mit bewusst eingeführten Sicherheitslücken, Interpretation der Ergebnisse, Triagierung von Fehlalarmen vs. echten Sicherheitslücken

DAST – Dynamische Anwendungssicherheitstests

1. Unterschied zwischen SAST und DAST, Black-Box-Tests an der laufenden Anwendung

2. Der Ablauf des DAST-Scans, Crawling, Fuzzing, Analyse der Antworten

3. Übersicht über DAST-Tools (z. B. OWASP ZAP, Burp Suite)

4. Praktische Übung: Durchführung eines DAST-Scans an einer anfälligen Testanwendung (z. B. OWASP Juice Shop), Identifizierung und Validierung der Befunde

SCA – Software Composition Analysis

1. Risiko von Abhängigkeiten und Bibliotheken von Drittanbietern, verernte Sicherheitslücken

2. SBOM, Software Bill of Materials, was es ist und warum es wichtig ist

3. Übersicht über SCA-Tools (z. B. Dependency Check, Snyk, GitHub Dependabot)

4. Praktische Übung: Durchführung eines SCA-Scans in einem echten Projekt, Identifizierung anfälliger Abhängigkeiten und Erstellung eines Behebnungsplans (Update, Patch, Minderung)