Application Security Testing: OWASP Top 10, SAST, DAST and SCA Schulung

A01:2025 – Broken Access Control (Zugriffskontrolle)

Die Zugriffskontrolle erzwingt Richtlinien, die sicherstellen, dass Benutzer nicht über ihre vorgesehenen Berechtigungen hinaus agieren können. Versagen in dieser Kategorie führt typischerweise zu unbefugter Offenlegung, Änderung oder Zerstörung von Daten oder zur Ausführung von Geschäftsfunktionen außerhalb der Grenzen des Benutzers.

Praktische Aspekte

• Praktische Beispiele für fehlerhafte Zugriffskontrollen

• Sichere Zugriffskontrollen und bewährte Methoden

A02:2025 – Security Misconfiguration (Sicherheitskonfigurationsfehler)

Ein Sicherheitskonfigurationsfehler liegt vor, wenn ein System, eine Anwendung oder ein Cloud-Dienst aus Sicherheitsperspektive falsch konfiguriert wird, wodurch Sicherheitslücken entstehen.

Praktische Aspekte

• Beispiele aus der Praxis zu Konfigurationsfehlern

• Schritte zur Verhinderung von Konfigurationsfehlern, einschließlich Konfigurationsmanagement und Automatisierungstools

A03:2025 – Software Supply Chain Failures (Verschlechterung der Software-Versorgungskette)

Versagen in der Software-Versorgungskette bezieht sich auf Störungen oder Kompromittierungen in den Prozessen des Baus, der Distribution oder des Updates von Software. Diese werden oft durch Sicherheitslücken oder bösartige Änderungen in Drittanbietercode, Tools oder anderen Abhängigkeiten verursacht, von denen das System abhängt.

A04:2025 – Cryptographic Failures (Verschlüsselungsversagen)

Im Allgemeinen sollte alle Daten, die übertragen werden, auf der Transportebene (OSI-Schicht 4) verschlüsselt werden. Vorherige Hürden wie die CPU-Performance und das Management von privaten Schlüsseln/Zertifikaten werden heute durch CPUs mit Instruktionen zur Beschleunigung der Verschlüsselung (z. B. AES-Unterstützung) gelöst, und das Management von privaten Schlüsseln und Zertifikaten wird durch Dienste wie LetsEncrypt.org vereinfacht, wobei große Cloud-Anbieter noch stärker integrierte Zertifikatsverwaltungsdienste für ihre spezifischen Plattformen bereitstellen.

Über die Absicherung der Transportebene hinaus ist es wichtig, zu bestimmen, welche Daten verschlüsselt gespeichert werden müssen (at rest) und welche Daten zusätzliche Verschlüsselung während der Übertragung benötigen (auf der Anwendungsebene, OSI-Schicht 7).

Zum Beispiel erfordern Passwörter, Kreditkartennummern, Gesundheitsdaten, persönliche Informationen und Geschäftsgeheimnisse zusätzlichen Schutz, insbesondere wenn diese Daten unter Datenschutzgesetze fallen, wie die allgemeine Datenschutzverordnung (DSGVO) der EU, oder unter Vorschriften wie den PCI Data Security Standard (PCI DSS).

Praktische Aspekte

• Detaillierte Analyse von Verschlüsselungsversagen, wie schwache Verschlüsselungsalgorithmen oder fehlerhaftes Schlüsselmanagement

• Bedeutung starker Verschlüsselungsmechanismen, sicherer Protokolle (SSL/TLS) und Beispiele für moderne Kryptografie in der Websicherheit

A05:2025 – Injection (Injection-Schwachstellen)

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

Praktische Aspekte

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

• Minderungstechniken unter Verwendung von vorbereitet Anweisungen, parametrisierten Abfragen und dem Escape-Escape von Eingaben

A06:2025 – Insecure Design (Unsicheres Design)

Unsicheres Design ist eine breite Kategorie, die verschiedene Schwächen darstellt, ausgedrückt als „fehlendes oder unwirksames Kontrollen-Design“.

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 aus gutem Grund zwischen Designfehlern und Implementierungsdefiziten, da sie unterschiedliche Ursachen haben, zu unterschiedlichen Zeitpunkten im Entwicklungsprozess auftreten und unterschiedliche Behebungen erfordern.

Ein sicheres Design kann dennoch Implementierungsdefizite aufweisen, die zu ausnutzbaren Sicherheitslücken führen. Ein unsicheres Design kann nicht durch eine perfekte Implementierung behoben werden, da die erforderlichen Sicherheitskontrollen nie erstellt wurden, um sich gegen bestimmte Angriffe zu verteidigen.

Ein Faktor, der zu unsicherem Design beiträgt, ist das Fehlen eines Profils für Geschäftsrisiken, die in der zu entwickelnden Software oder dem System inhärent sind, und somit das Versagen, das erforderliche Niveau des Sicherheitsdesigns zu bestimmen.

Praktische Aspekte

• Wir erkunden Designfehler, die zu Sicherheitslücken führen können, wie fehlerhafte Eingabevalidierung

• Wir untersuchen Strategien für sichere Architekturen und Grundsätze des sicheren Designs

A07:2025 – Authentication Failures (Authentifizierungsversagen)

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

Praktische Aspekte

• Häufige Authentifizierungsprobleme

• Sichere Authentifizierungsstrategien, wie Multi-Faktor-Authentifizierung und angemessene Sitzungshandhabung

A08:2025 – Software or Data Integrity Failures (Integritätsversagen von Software oder Daten)

Integritätsversagen bei Software und Daten beziehen sich auf Code und Infrastruktur, die nicht davor schützen, dass ungültiger oder unzuverlässiger 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 unzuverlässigen Quellen, Repositories und Content-Delivery-Nets (CDNs) angewiesen ist.

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

Ein weiteres Beispiel ist eine CI/CD, die Code oder Artefakte aus unzuverlässigen Orten abrufen und/oder sie vor der Verwendung nicht überprüfen (durch Überprüfen der Signatur oder eines ähnlichen Mechanismus).

Praktische Aspekte

• Fokus auf Probleme wie unzuverlässige Softwareupdates und Datenmanipulation

• Sichere Update-Mechanismen und Datenintegritätsprüfungen

A09:2025 – Security Logging and Alerting Failures (Fehler bei der Sicherheitsprotokollierung und -alarmierung)

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

Unzureichende Protokollierung, kontinuierliche Überwachung, Erkennung und Alarmierung zur Einleitung aktiver Reaktionen tritt zu jeder Zeit auf.

Praktische Aspekte

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

• Werkzeuge und Praktiken für angemessene Protokollierung und Echtzeit-Überwachung, um Verletzungen frühzeitig zu erkennen

A10:2025 – Mishandling of Exceptional Conditions (Fehlerhaftes Handhaben von Ausnahmesituationen)

Ein fehlerhaftes Handhaben von Ausnahmesituationen 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 eines oder mehrere der folgenden drei Versagen umfassen:

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

• Die Anwendung erkennt die Situation nicht, während sie auftritt

• Die Anwendung reagiert schlecht oder gar nicht auf die Situation danach

SAST – Statisches Anwendungssicherheitstesting

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

2. Arten von Sicherheitslücken, die durch SAST erkannt werden können, anfälliger Code gegenüber sicherem Code

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

4. Praktische Übung: Führen Sie einen SAST-Scan auf einem Repository mit absichtlich eingeführten Schwachstellen durch, interpretieren Sie die Ergebnisse und klassifizieren Sie Fehlalarme gegenüber echten Sicherheitslücken

DAST – Dynamisches Anwendungssicherheitstesting

1. Unterschied zwischen SAST und DAST, Black-Box-Testing auf der laufenden Anwendung

2. Der DAST-Scan-Flow, Crawling, Fuzzing, Antwortanalyse

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

4. Praktische Übung: Führen Sie einen DAST-Scan auf einer anfälligen Testanwendung (z. B. OWASP Juice Shop) durch, identifizieren und validieren Sie die Befunde

SCA – Software Composition Analysis

1. Risiko von Drittanbieter-Abhängigkeiten und Bibliotheken, vererbte Schwachstellen

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

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

4. Praktische Übung: Führen Sie einen SCA-Scan auf einem echten Projekt durch, identifizieren Sie anfällige Abhängigkeiten und erstellen Sie einen Behebungsplan (Update, Patch, Minderung)