From d2d3412d15722480c2af653e53850bebc65d4531 Mon Sep 17 00:00:00 2001 From: Rico Komenda Date: Tue, 8 Sep 2026 23:14:09 +0200 Subject: [PATCH] Add German (de) translation of OWASP Top 10:2025 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Full German translation of all 16 documents (Introduction, About OWASP, What are Application Security Risks, Establishing a Modern Application Security Program, A01–A10, Next Steps, and index) plus X02/X03 sections of Next Steps. Wires the de locale into 2025/mkdocs.yml's i18n plugin config and uncomments the existing de entry in extra.alternate, both additive changes alongside the existing cs/es/it/ja/ko/fa/pt-BR/zh-Hant locales. --- 2025/docs/de/0x00_2025-Introduction.md | 112 ++++++ 2025/docs/de/0x01_2025-About_OWASP.md | 40 +++ ...025-What_are_Application_Security_Risks.md | 105 ++++++ ...g_a_Modern_Application_Security_Program.md | 299 ++++++++++++++++ .../docs/de/A01_2025-Broken_Access_Control.md | 225 ++++++++++++ .../de/A02_2025-Security_Misconfiguration.md | 137 ++++++++ ...A03_2025-Software_Supply_Chain_Failures.md | 174 ++++++++++ .../de/A04_2025-Cryptographic_Failures.md | 195 +++++++++++ 2025/docs/de/A05_2025-Injection.md | 210 ++++++++++++ 2025/docs/de/A06_2025-Insecure_Design.md | 189 +++++++++++ .../de/A07_2025-Authentication_Failures.md | 199 +++++++++++ ...025-Software_or_Data_Integrity_Failures.md | 123 +++++++ ...-Security_Logging_and_Alerting_Failures.md | 135 ++++++++ ...5-Mishandling_of_Exceptional_Conditions.md | 146 ++++++++ 2025/docs/de/X01_2025-Next_Steps.md | 319 ++++++++++++++++++ 2025/docs/de/index.md | 38 +++ 2025/mkdocs.yml | 29 +- 17 files changed, 2671 insertions(+), 4 deletions(-) create mode 100644 2025/docs/de/0x00_2025-Introduction.md create mode 100644 2025/docs/de/0x01_2025-About_OWASP.md create mode 100644 2025/docs/de/0x02_2025-What_are_Application_Security_Risks.md create mode 100644 2025/docs/de/0x03_2025-Establishing_a_Modern_Application_Security_Program.md create mode 100644 2025/docs/de/A01_2025-Broken_Access_Control.md create mode 100644 2025/docs/de/A02_2025-Security_Misconfiguration.md create mode 100644 2025/docs/de/A03_2025-Software_Supply_Chain_Failures.md create mode 100644 2025/docs/de/A04_2025-Cryptographic_Failures.md create mode 100644 2025/docs/de/A05_2025-Injection.md create mode 100644 2025/docs/de/A06_2025-Insecure_Design.md create mode 100644 2025/docs/de/A07_2025-Authentication_Failures.md create mode 100644 2025/docs/de/A08_2025-Software_or_Data_Integrity_Failures.md create mode 100644 2025/docs/de/A09_2025-Security_Logging_and_Alerting_Failures.md create mode 100644 2025/docs/de/A10_2025-Mishandling_of_Exceptional_Conditions.md create mode 100644 2025/docs/de/X01_2025-Next_Steps.md create mode 100644 2025/docs/de/index.md diff --git a/2025/docs/de/0x00_2025-Introduction.md b/2025/docs/de/0x00_2025-Introduction.md new file mode 100644 index 000000000..976044072 --- /dev/null +++ b/2025/docs/de/0x00_2025-Introduction.md @@ -0,0 +1,112 @@ +![OWASP Logo](../assets/TOP_10_logo_Final_Logo_Colour.png) + +# Die zehn kritischsten Sicherheitsrisiken für Webanwendungen + +# Einführung + +Willkommen zur 8. Ausgabe der OWASP Top 10! + +Ein großes Dankeschön an alle, die Daten und Einschätzungen in der Umfrage beigetragen haben. Ohne diese Beiträge wäre diese Ausgabe nicht möglich gewesen. **HERZLICHEN DANK!** + + +## Die OWASP Top 10:2025 im Überblick + + + +* [A01:2025 - Mangelhafte Zugriffskontrolle](A01_2025-Broken_Access_Control.md) +* [A02:2025 - Sicherheitsrelevante Fehlkonfiguration](A02_2025-Security_Misconfiguration.md) +* [A03:2025 - Schwachstellen in der Software-Lieferkette](A03_2025-Software_Supply_Chain_Failures.md) +* [A04:2025 - Fehlerhafter Einsatz von Kryptographie](A04_2025-Cryptographic_Failures.md) +* [A05:2025 - Injection](A05_2025-Injection.md) +* [A06:2025 - Unsicheres Anwendungsdesign](A06_2025-Insecure_Design.md) +* [A07:2025 - Fehlerhafte Authentifizierung](A07_2025-Authentication_Failures.md) +* [A08:2025 - Fehlerhafte Prüfung der Software- und Datenintegrität](A08_2025-Software_or_Data_Integrity_Failures.md) +* [A09:2025 - Unzureichendes Security-Logging und Alerting](A09_2025-Security_Logging_and_Alerting_Failures.md) +* [A10:2025 - Fehlerhafte Behandlung von Ausnahmezuständen](A10_2025-Mishandling_of_Exceptional_Conditions.md) + + +## Was sich in den Top 10 für 2025 geändert hat + +Es gibt zwei neue Kategorien und eine Konsolidierung in den Top 10 für 2025. Wir haben uns bemüht, den Fokus so weit wie möglich auf die Grundursachen statt auf die Symptome zu legen. Angesichts der Komplexität von Software-Engineering und Software-Sicherheit ist es nahezu unmöglich, zehn Kategorien ohne ein gewisses Maß an Überschneidungen zu erstellen. + +![Mapping](../assets/2025-mappings.png) + +* **[A01:2025 - Mangelhafte Zugriffskontrolle](A01_2025-Broken_Access_Control.md)** behält seine Position als schwerwiegendstes Sicherheitsrisiko für Webanwendungen. Die Daten zeigen, dass im Durchschnitt 3,73 % der getesteten Anwendungen mindestens eine der 40 CWEs dieser Kategorie aufweisen. Wie durch die gestrichelte Linie in der obigen Abbildung angezeigt, wurde Server-Side Request Forgery (SSRF) in diese Kategorie integriert. +* **[A02:2025 - Sicherheitsrelevante Fehlkonfiguration](A02_2025-Security_Misconfiguration.md)** steigt von Platz 5 in 2021 auf Platz 2 in 2025. Fehlkonfigurationen sind in den Daten dieser Ausgabe häufiger vertreten. 3,00 % der getesteten Anwendungen wiesen mindestens eine der 16 CWEs dieser Kategorie auf. Dies ist nicht überraschend, da Software-Engineering zunehmend mehr Anwendungsverhalten über Konfigurationen steuert. +* **[A03:2025 - Schwachstellen in der Software-Lieferkette](A03_2025-Software_Supply_Chain_Failures.md)** ist eine Erweiterung von [A06:2021-Unsichere oder veraltete Komponenten](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/) auf einen breiteren Umfang von Kompromittierungen innerhalb oder über das gesamte Ökosystem von Software-Abhängigkeiten, Build-Systemen und Verteilungsinfrastruktur. Diese Kategorie wurde in der Community-Umfrage mit Abstand als größtes Anliegen eingestuft. Sie umfasst 5 CWEs und ist in den gesammelten Daten wenig vertreten, was wir auf Herausforderungen beim Testen zurückführen. Sie weist die wenigsten Vorkommen in den Daten auf, aber auch die höchsten durchschnittlichen Exploit- und Impact-Scores aus CVEs. +* **[A04:2025 - Fehlerhafter Einsatz von Kryptographie](A04_2025-Cryptographic_Failures.md)** fällt um zwei Plätze von Platz 2 auf Platz 4. Die Daten zeigen, dass im Durchschnitt 3,80 % der Anwendungen mindestens eine der 32 CWEs dieser Kategorie aufweisen. Diese Kategorie führt häufig zur Offenlegung sensibler Daten oder zur Kompromittierung des Systems. +* **[A05:2025 - Injection](A05_2025-Injection.md)** fällt um zwei Plätze von Platz 3 auf Platz 5. Injection ist eine der am häufigsten getesteten Kategorien mit der größten Anzahl von CVEs, die den 38 CWEs dieser Kategorie zugeordnet sind. Sie umfasst ein breites Spektrum – von Cross-Site Scripting (hohe Häufigkeit/geringe Auswirkung) bis hin zu SQL Injection (geringe Häufigkeit/hohe Auswirkung). +* **[A06:2025 - Unsicheres Anwendungsdesign](A06_2025-Insecure_Design.md)** fällt um zwei Plätze von Platz 4 auf Platz 6, da Sicherheitsrelevante Fehlkonfiguration und Schwachstellen in der Software-Lieferkette vorbeigezogen sind. Diese Kategorie wurde 2021 eingeführt, und wir sehen spürbare Verbesserungen in der Branche bei der Bedrohungsmodellierung und einem stärkeren Fokus auf sicheres Design. +* **[A07:2025 - Fehlerhafte Authentifizierung](A07_2025-Authentication_Failures.md)** behält seine Position auf Platz 7 mit einer leichten Namensänderung (zuvor „[Fehlerhafte Identifikation und Authentifizierung](https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/)”), um die 36 CWEs dieser Kategorie besser widerzuspiegeln. Die Kategorie bleibt wichtig, aber die zunehmende Nutzung standardisierter Frameworks für die Authentifizierung wirkt sich positiv auf die Häufigkeit von Authentifizierungsfehlern aus. +* **[A08:2025 - Fehlerhafte Prüfung der Software- und Datenintegrität](A08_2025-Software_or_Data_Integrity_Failures.md)** bleibt auf Platz 8. Diese Kategorie konzentriert sich auf das Versagen, Vertrauensgrenzen einzuhalten und die Integrität von Software, Code und Daten auf einer niedrigeren Ebene als die Schwachstellen in der Software-Lieferkette zu überprüfen. +* **[A09:2025 - Unzureichendes Security-Logging und Alerting](A09_2025-Security_Logging_and_Alerting_Failures.md)** behält seine Position auf Platz 9. Leichte Namensänderung (zuvor „[Security Logging and Monitoring Failures](https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/)”), um die Bedeutung der Alarmierungsfunktion für geeignete Reaktionen auf relevante Log-Ereignisse hervorzuheben. Hervorragendes Logging ohne Alerting hat nur minimalen Wert bei der Erkennung von Sicherheitsvorfällen. Diese Kategorie ist in den Daten stets unterrepräsentiert und wurde erneut durch die Community-Umfrage in die Liste gewählt. +* **[A10:2025 - Fehlerhafte Behandlung von Ausnahmezuständen](A10_2025-Mishandling_of_Exceptional_Conditions.md)** ist eine neue Kategorie für 2025. Diese Kategorie enthält 24 CWEs mit Fokus auf fehlerhafte Fehlerbehandlung, logische Fehler, „Failing Open” sowie andere verwandte Szenarien, die aus abnormalen Zuständen resultieren, mit denen Systeme konfrontiert werden können. + + +## Methodik + +Diese Ausgabe der Top 10 bleibt datengestützt, aber nicht blind datengetrieben. Wir haben 12 Kategorien anhand der eingereichten Daten eingestuft und zwei weitere durch die Ergebnisse der Community-Umfrage aufgenommen. Wir tun dies aus einem wesentlichem Grund: Die Analyse der eingereichten Daten ist im Wesentlichen ein Blick in die Vergangenheit. Sicherheitsforscher:innen im Bereich Anwendungssicherheit widmen ihre Zeit der Identifizierung neuer Schwachstellen und der Entwicklung neuer Testmethoden. Es dauert Wochen bis Jahre, bis diese Tests in Werkzeuge und Prozesse integriert sind. Bis eine Schwachstelle zuverlässig in großem Maßstab getestet werden kann, können Jahre vergangen sein. Es gibt auch wichtige Risiken, die wir möglicherweise nie zuverlässig testen können und die daher in den Daten fehlen. Um diesen Blickwinkel auszugleichen, nutzen wir eine Community-Umfrage, um Praktiker:innen aus der Anwendungssicherheit und Softwareentwicklung an vorderster Front zu befragen, was sie als wesentliche Risiken betrachten, die in den Testdaten unterrepräsentiert sein könnten. + + +## Aufbau der Kategorien + +Einige Kategorien haben sich gegenüber der vorherigen Ausgabe der OWASP Top 10 geändert. Im Folgenden finden Sie eine übergeordnete Zusammenfassung der Kategorieänderungen. + +In dieser Ausgabe haben wir Daten ohne Einschränkung auf bestimmte CWEs angefragt, wie wir es bereits für die Ausgabe 2021 getan haben. Wir fragten nach der Anzahl der getesteten Anwendungen für ein bestimmtes Jahr (ab 2021) und nach der Anzahl der Anwendungen, bei denen mindestens ein CWE im Test gefunden wurde. Dieses Format ermöglicht es uns, zu erfassen, wie häufig die einzelnen CWEs in der Gesamtzahl der Anwendungen vorkommen. Wir ignorieren die Häufigkeit für unsere Zwecke; obwohl sie in anderen Situationen notwendig sein kann, verdeckt sie nur die tatsächliche Verbreitung in der Anwendungspopulation. Ob eine Anwendung vier oder 4.000 Vorkommen eines CWEs aufweist, ist für die Berechnung der Top 10 nicht relevant. Insbesondere da manuelle Tester:innen eine Schwachstelle in der Regel nur einmal vermerken, unabhängig davon, wie oft sie in einer Anwendung vorkommt, während automatisierte Test-Frameworks jedes Vorkommen als einzigartig aufführen. Wir sind von etwa 30 CWEs im Jahr 2017 auf fast 400 CWEs im Jahr 2021 und auf 589 CWEs in dieser Ausgabe gestiegen. Wir planen, in Zukunft zusätzliche Datenanalysen als Ergänzung durchzuführen. Dieser deutliche Anstieg der CWE-Anzahl erfordert Änderungen in der Strukturierung der Kategorien. + +Wir haben mehrere Monate damit verbracht, CWEs zu gruppieren und zu kategorisieren, und hätten noch weitere Monate damit fortfahren können. Irgendwann mussten wir aufhören. Es gibt sowohl CWEs für Grundursachen als auch für Symptome – Grundursachen-Typen sind beispielsweise „Fehlerhafter Einsatz von Kryptographie" und „Fehlkonfiguration", während Symptomtypen wie „Offenlegung sensibler Daten" und „Denial of Service" zu nennen sind. Wir haben beschlossen, uns wann immer möglich auf die Grundursache zu konzentrieren, da dies sinnvoller für die Identifizierung und Behebung ist. Sich auf die Grundursache statt auf das Symptom zu konzentrieren ist kein neues Konzept; die Top 10 war schon immer eine Mischung aus Symptomen und Grundursachen. CWEs sind ebenfalls eine solche Mischung – wir gehen nun bewusster damit um. In dieser Ausgabe gibt es durchschnittlich 25 CWEs pro Kategorie, mit einem Minimum von 5 CWEs für A03:2025 und A09:2025 bis hin zu 40 CWEs in A01:2025. Wir haben beschlossen, die Anzahl der CWEs pro Kategorie auf 40 zu begrenzen. Diese aktualisierte Kategoriestruktur bietet zusätzliche Vorteile für Schulungen, da Unternehmen sich auf CWEs konzentrieren können, die für eine bestimmte Programmiersprache oder ein Framework relevant sind. + +Wir wurden gefragt, warum wir nicht zu einer Liste von 10 CWEs als Top 10 wechseln, ähnlich den MITRE Top 25 Most Dangerous Software Weaknesses. Es gibt zwei Hauptgründe für die Verwendung mehrerer CWEs in Kategorien. Erstens existieren nicht alle CWEs in allen Programmiersprachen oder Frameworks, was Probleme für Werkzeuge und Schulungsprogramme verursacht. Zweitens gibt es mehrere CWEs für häufige Schwachstellen – etwa für Injection, Command Injection, Cross-Site Scripting, hartcodierte Passwörter, fehlende Validierung, Pufferüberläufe und viele weitere. Je nach Organisation oder Tester:innen werden unterschiedliche CWEs verwendet. Durch die Verwendung einer Kategorie mit mehreren CWEs können wir das Bewusstsein für die verschiedenen Schwachstellentypen unter einem gemeinsamen Kategorienamen schärfen. In dieser Ausgabe der Top 10 2025 gibt es 248 CWEs in den 10 Kategorien. Zum Zeitpunkt dieser Veröffentlichung enthält die [herunterladbare Auflistung von MITRE](https://cwe.mitre.org) insgesamt 968 CWEs. + + +## Verwendung der Daten zur Kategorienauswahl + +Wie bereits für die Ausgabe 2021 haben wir CVE-Daten für *Ausnutzbarkeit* und *(technische) Auswirkung* herangezogen. In der National Vulnerability Database (NVD) gibt es ca. 175.000 Datensätze (gegenüber 125.000 in 2021) mit CVEs. Zudem gibt es 643 eindeutige CWEs, die CVEs zugeordnet sind (gegenüber 241 in 2021). Für die Top Ten 2025 haben wir die durchschnittlichen Ausnutzbarkeits- und Auswirkungs-Scores wie folgt berechnet: Alle CVEs mit CVSS-Scores wurden nach CWE gruppiert, und sowohl Exploit- als auch Impact-Scores wurden gewichtet. Für Details siehe [Was sind Sicherheitsrisiken für Anwendungen?](0x02_2025-What_are_Application_Security_Risks.md) + +## Warum wir eine Community-Umfrage nutzen + +Die Ergebnisse in den Daten beschränken sich weitgehend auf das, was die Branche automatisiert testen kann. Erfahrene AppSec-Fachleute berichten von Dingen, die sie finden, und Trends, die sie sehen, die noch nicht in den Daten erfasst sind. Es braucht Zeit, Testmethoden für bestimmte Schwachstellentypen zu entwickeln, und dann noch mehr Zeit, bis diese Tests automatisiert und für eine große Anzahl von Anwendungen ausgeführt werden. Alles, was wir finden, blickt in die Vergangenheit und könnte Trends aus dem letzten Jahr übersehen, die noch nicht in den Daten vorhanden sind. + +Daher wählen wir nur acht der zehn Kategorien aus den Daten, da diese unvollständig sind. Die anderen zwei Kategorien stammen aus der Top-10-Community-Umfrage. Sie ermöglicht den Praktiker:innen an vorderster Front, für die aus ihrer Sicht größten Risiken zu stimmen, die möglicherweise nicht in den Daten enthalten sind (und dies möglicherweise nie sein werden). + + +## Vielen Dank an unsere Datenspender + +Die folgenden Organisationen (sowie mehrere anonyme Spender) haben freundlicherweise Daten für über 2,8 Millionen Anwendungen gespendet und damit den größten und umfassendsten Datensatz zur Anwendungssicherheit ermöglicht. Ohne diese Beiträge wäre dies nicht möglich gewesen. + +* Accenture (Prague) +* Anonymous (multiple) +* Bugcrowd +* Contrast Security +* CryptoNet Labs +* Intuitor SoftTech Services +* Orca Security +* Probely +* Semgrep +* Sonar +* usd AG +* Veracode +* Wallarm + +## Hauptautor:innen +* Andrew van der Stock - X: [@vanderaj](https://x.com/vanderaj) +* Brian Glas - X: [@infosecdad](https://x.com/infosecdad) +* Neil Smithline - X: [@appsecneil](https://x.com/appsecneil) +* Tanya Janca - X: [@shehackspurple](https://x.com/shehackspurple) +* Torsten Gigler - Mastodon: [@torsten_gigler@infosec.exchange](https://infosec.exchange/@torsten_gigler) + +## Deutsche Übersetzung +* Tobias Heide - [LinkedIn](https://www.linkedin.com/in/tobias-heide/) +* Rico Komenda - [LinkedIn](https://www.linkedin.com/in/ricokomenda) +* Martina Kraus - [LinkedIn](https://www.linkedin.com/in/martina-kraus-398493108/) +* Lilith Pendzich - [LinkedIn](https://www.linkedin.com/in/lilithp) + +## Fehler melden und Pull Requests stellen + +Korrekturen und Probleme bitte hier melden: + +### Projektlinks: +* [Homepage](https://owasp.org/www-project-top-ten/) +* [GitHub repository](https://github.com/OWASP/Top10) + + diff --git a/2025/docs/de/0x01_2025-About_OWASP.md b/2025/docs/de/0x01_2025-About_OWASP.md new file mode 100644 index 000000000..cd2290405 --- /dev/null +++ b/2025/docs/de/0x01_2025-About_OWASP.md @@ -0,0 +1,40 @@ +# Über OWASP + +Das Open Worldwide Application Security Project (OWASP) ist eine offene Community. OWASP möchte Organisationen in die Lage versetzen, sichere und vertrauenswürdige Anwendungen zu entwickeln, zu kaufen und zu betreiben. + +Von OWASP kann man Folgendes erwarten; stets frei verfügbar und für alle Personen zugänglich: + +- Werkzeuge und Standards für sichere Anwendungen. +- Neueste Forschung. +- Standard Security-Controls und Programm-Bibliotheken. +- Bücher zu den Themen Prüfung, Entwicklung und Quellcodeanalyse im Bereich der Anwendungssicherheit. +- Vorträge und [Videos](https://www.youtube.com/user/OWASPGLOBAL). +- ["Cheat sheets"](https://cheatsheetseries.owasp.org/) (Spickzettel) zu vielen sicherheitsrelevanten Themen. +- [Lokale "Chapter" auf der ganzen Welt](https://owasp.org/chapters/) und zusätzlich [**Stammtische**](https://owasp.org/www-chapter-germany/stammtische/) in Deutschland. +- Große und häufige [Konferenzen auf der ganzen Welt](https://owasp.org/events/). +- [Google Groups](https://groups.google.com/g/owasp). + +Alle Informationen auf: [https://owasp.org](https://owasp.org). + +Alle OWASP Werkzeuge, Dokumente, Videos, Präsentationen und Chapter sind frei verfügbar und stehen allen offen, die Anwendungssicherheit weiterentwickeln möchten. + +Mangelnde Anwendungssicherheit begreifen wir als ein personen-, prozess- und technologie-bezogenes Problem, da die meisten wirksamen Ansätze für Anwendungssicherheit Verbesserungen in all diesen Feldern erfordern. + +OWASP ist eine andere Art von Organisation. Wir unterliegen keinem kommerziellen Druck. Das erlaubt uns unvoreingenommene, praktikable und kosteneffiziente Informationen über Anwendungssicherheit bereitzustellen. + +OWASP ist nicht von Dritten abhängig, wenngleich wir die sachkundige Verwendung freier und kommerzieller Technologien unterstützen. OWASP erstellt viele unterschiedliche Materialien auf Basis eines kollaborativen, transparenten und offenen Ansatzes. + +Die OWASP Foundation ist die gemeinnützige Organisation, die den langfristigen Erfolg des Projektes sicher stellt. Fast jede:r bei OWASP ist ehrenamtlich tätig. Das schließt das Board, Chapter- und Projekt-Leiter:innen, sowie Mitglieder ein. Wir unterstützen innovative Sicherheitsforschung mit Spenden, Förderungen und Infrastruktur. + +Mitmachen! + +## Stammtisch-Initiative des OWASP German Chapter +In mehreren deutschen Städten gibt es [OWASP-Stammtische](https://owasp.org/www-chapter-germany/stammtische/), bei denen man sich in lockerer Runde trifft, um sich auszutauschen, nette Leute kennenzulernen oder ernsthafte Sicherheitsthemen zu diskutieren – meistens mit Vortrag.
+ +Aktive Stammtische gibt es (Stand Mai 2026) in [Augsburg](/www-chapter-germany/stammtische/augsburg/), [Berlin](/www-chapter-germany/stammtische/berlin), [Frankfurt](/www-chapter-frankfurt/), [Hamburg](/www-chapter-germany/stammtische/hamburg/), [Heilbronn-Franken](/www-chapter-heilbronn/), [Karlsruhe](/www-chapter-germany/stammtische/karlsruhe/), [Köln](/www-chapter-germany/stammtische/koeln/), [München](/www-chapter-germany/stammtische/muenchen/), [Ruhrpott](/www-chapter-ruhrpott/) und [Stuttgart](/www-chapter-stuttgart/). + +## Copyright und Lizenz + +![License](../assets/license.png) + +Copyright © 2003-2025 The OWASP® Foundation, Inc. Dieses Dokument ist unter der Creative Commons Attribution Share-Alike 4.0 Lizenz veröffentlicht. Bei Weiterverwendung oder Weitergabe muss die Lizenz erhalten bleiben. diff --git a/2025/docs/de/0x02_2025-What_are_Application_Security_Risks.md b/2025/docs/de/0x02_2025-What_are_Application_Security_Risks.md new file mode 100644 index 000000000..e978e6a6e --- /dev/null +++ b/2025/docs/de/0x02_2025-What_are_Application_Security_Risks.md @@ -0,0 +1,105 @@ +# Was sind Sicherheitsrisiken für die Anwendungen? +Angreifer:innen können potenziell viele verschiedene Wege über Ihre Anwendung nutzen, um Ihrem Unternehmen oder Ihrer Organisation Schaden zuzufügen. Jeder dieser Wege birgt ein potenzielles Risiko, das untersucht werden muss. + +![Calculation diagram](../assets/2025-algorithm-diagram.png) + + + + + + + + + + + + + + + + + + +
+ Bedrohungsakteur:innen + + Angriff / +Vektoren + + Ausnutzbarkeit + + Wahrscheinlichkeit von fehlenden + Sicherheitsmaßnahmen + + Technische + Auswirkungen + + Geschäftliche + Auswirkungen +
+ Je nach Umgebung / +dynamisch von der Situation abhänging + + Je nach Ausgesetztheit der Anwendung (in der Umgebung) + + Durchschn. gewichtete Ausnutzbarkeit + + Fehlende Maßnahmen / +zu durchschnittlicher Inzidenzrate / +gewichtet nach Abdeckung + + Durchschn. gewichtete Auswirkung + + Je nach Geschäft +
+ +Bei unserer Risikobewertung haben wir die allgemeinen Parameter der Ausnutzbarkeit, der durchschnittlichen Wahrscheinlichkeit von Sicherheitsmaßnahmen für eine Schwachstelle und deren technische Auswirkungen berücksichtigt. + +Jede Organisation ist einzigartig, ebenso wie die Angreifer:innen, die es auf sie abgesehen haben, ihre Ziele und die Auswirkungen eines möglichen Sicherheitsvorfalls. Wenn eine Organisation von öffentlichem Interesse ein Content-Management-System (CMS) für öffentliche Informationen nutzt und ein Gesundheitssystem genau dasselbe CMS für sensible Gesundheitsdaten verwendet, können die Angreifer:innen und die geschäftlichen Auswirkungen bei derselben Software sehr unterschiedlich sein. Es ist entscheidend, das Risiko für Ihre Organisation zu verstehen, basierend auf der Gefährdung der Anwendung, den relevanten Bedrohungsakteur:innen je nach Lagebild (für gezielte und ungezielte Angriffe je nach Geschäftsbereich und Standort) und den individuellen geschäftlichen Auswirkungen. + +## Wie die Daten zur Auswahl und Einstufung der Kategorien verwendet werden + +Im Jahr 2017 wählten wir die Kategorien anhand der Häufigkeit aus, um die Wahrscheinlichkeit zu ermitteln, und stuften sie anschließend auf der Grundlage jahrzehntelanger Erfahrung in den Bereichen Ausnutzbarkeit, Erkennbarkeit (ebenfalls Wahrscheinlichkeit) und technische Auswirkungen im Rahmen von Teamdiskussionen ein. Für das Jahr 2021 verwendeten wir Daten zur Ausnutzbarkeit und zu den (technischen) Auswirkungen aus den CVSSv2- und CVSSv3-Bewertungen in der National Vulnerability Database (NVD). Für das Jahr 2025 setzten wir die gleiche Methodik fort, die wir 2021 entwickelt hatten. + +Mittels OWASP Dependency Check extrahierten wir die CVSS-Bewertungen für Ausnutzbarkeit und Auswirkungen und gruppiert nach den zugehörigen CWEs. Dies erforderte einiges an Recherche und Aufwand, da alle CVEs zwar CVSSv2-Werte aufweisen, CVSSv2 jedoch Mängel aufweist, die CVSSv3 beheben sollte. Ab einem bestimmten Zeitpunkt werden allen CVEs auch CVSSv3-Werte zugewiesen. Zudem wurden die Bewertungsbereiche und Formeln zwischen CVSSv2 und CVSSv3 aktualisiert. + +In CVSSv2 konnten sowohl „Ausnutzbarkeit“ als auch „(Technische) 'Auswirkungen'“ bis zu 10,0 betragen, doch die Formel reduzierte diese Werte auf 60 % für „Ausnutzbarkeit“ und 40 % für Auswirkungen. In CVSSv3 war das theoretische Maximum auf 6,0 für „Ausnutzbarkeit“ und 4,0 für „Auswirkungen“ begrenzt. Unter Berücksichtigung der Gewichtung verschob sich die Auswirkungsbewertung nach oben, im Durchschnitt um fast eineinhalb Punkte in CVSSv3, während die Ausnutzbarkeit im Durchschnitt um fast einen halben Punkt nach unten ging, als wir die Analyse für die Top 10 2021 durchführten. + +In der National Vulnerability Database (NVD) gibt es etwa 175.000 Datensätze (gegenüber 125.000 im Jahr 2021) von CVEs, die CWEs zugeordnet sind und aus dem OWASP Dependency Check extrahiert wurden. Darüber hinaus gibt es 643 eindeutige CWEs, die CVEs zugeordnet sind (gegenüber 241 im Jahr 2021). Von den fast 220.000 extrahierten CVEs wiesen 160.000 CVSS-v2-Werte, 156.000 CVSS-v3-Werte und 6.000 CVSS-v4-Werte auf. Viele CVEs haben mehrere Werte, weshalb die Gesamtzahl über 220.000 liegt. + +Für die Top 10 2025 haben wir die durchschnittlichen Ausnutzbarkeits- und Auswirkungs-Werte wie folgt berechnet: Wir haben alle CVEs mit CVSS-Werten nach CWE gruppiert und sowohl die Ausnutzbarkeit- als auch die Auswirkungen-Werte nach dem prozentualen Anteil der Population mit CVSSv3 sowie der verbleibenden Population mit CVSSv2-Werten gewichtet, um einen Gesamtdurchschnitt zu erhalten. Diese Durchschnittswerte haben wir den CWEs im Datensatz zugeordnet, um sie als Ausnutzbarkeit- und (technische) Auswirkungen-Werte für die andere Hälfte der Risikogleichung zu verwenden. + +Sie fragen sich vielleicht, warum wir nicht CVSS v4.0 verwenden? Das liegt daran, dass der Bewertungsalgorithmus grundlegend geändert wurde und er nicht mehr so einfach die *Ausnutzbarkeit*- oder *Auswirkungen*-Werte liefert wie CVSSv2 und CVSSv3. Wir werden versuchen, einen Weg zu finden, die CVSS v4.0-Bewertung für zukünftige Versionen der Top 10 zu nutzen, aber für die Ausgabe 2025 konnten wir keine zeitnahe Lösung dafür finden. + +Für die Inzidenzrate haben wir den prozentualen Anteil der Anwendungen berechnet, die für jedes CWE anfällig sind, bezogen auf die von einer Organisation über einen bestimmten Zeitraum getestete Gesamtzahl an Anwendungen. Zur Erinnerung: Wir verwenden nicht die Häufigkeit (d. h. wie oft ein Problem in einer Anwendung auftritt), sondern uns interessiert, bei wie viel Prozent der Anwendungen jedes CWE festgestellt wurde. + +Für die Abdeckung betrachten wir den Prozentsatz der Anwendungen, die von allen Organisationen auf eine bestimmte CWE getestet wurden. Je höher die berechnete Abdeckung ist, desto größer ist die Sicherheit, dass die Inzidenzrate korrekt ist, da die Stichprobengröße repräsentativer für die Grundgesamtheit ist. + +Die Formel, die wir für diese Iteration verwendet haben, ähnelt der von 2021, mit einigen Änderungen bei der Gewichtung: +(Max. Inzidenzrate % * 1000) + (Max. Abdeckung % * 100) + (Durchschnittliche Ausnutzbarkeit * 10) + (Durchschnittliche Auswirkungen * 20) + (Summe der Vorkommen / 10000) = Risikowert + +Die berechneten Werte reichten von 621,60 für die Kategorie „Mangelhafte Zugriffskontrolle“ bis zu 271,08 für „Fehler bei der Speicherverwaltung“. + +Dies ist kein perfektes System, aber es ist wertvoll für die Einstufung von Risikokategorien. + +Eine weitere Herausforderung, die zunehmend an Bedeutung gewinnt, ist die Definition des Begriffs „Anwendung“. Da die Branche zunehmend auf andere Architekturen umstellt, die aus Microservices und anderen Implementierungen bestehen, die kleiner sind als eine herkömmliche Anwendung, werden die Berechnungen schwieriger. Wenn ein Unternehmen beispielsweise Code-Repositorys testet, was versteht es dann unter einer Anwendung? Ähnlich wie bei der Weiterentwicklung von CVSSv4 müssen möglicherweise auch in der nächsten Ausgabe der „Top 10“ die Analyse und die Bewertung angepasst werden, um der sich ständig wandelnden Branche Rechnung zu tragen. + +## Daten Werte + +Für jede der Top-Ten-Kategorien werden bestimmte Datenfaktoren aufgeführt. Hier ihre Bedeutung: + +**Zuordnete CWEs:** Die Anzahl der CWEs, die vom Top-10-Team einer Kategorie zugeordnet wurden. + +**Häufigkeit:** Die Häufigkeit ist der prozentuale Anteil der Anwendungen, die für diese CWE anfällig sind, gemessen an der von dieser Organisation in diesem Jahr getesteten Gesamtzahl. + +**Gewichtete Ausnutzbarkeit:** Die Ausnutzbarkeits-Teilpunktezahl aus den CVSSv2- und CVSSv3-Bewertungen wurde den den CWEs zugeordneten CVEs zugewiesen, normalisiert und auf einer 10-Punkte-Skala dargestellt. + +**Gewichtete Auswirkung:** Die Auswirkungs-Teilpunktzahl aus den CVSSv2- und CVSSv3-Bewertungen, die den den CWEs zugeordneten CVEs zugewiesen, normalisiert und auf einer 10-Punkte-Skala dargestellt wurden. + +**(Test-)Abdeckung:** Der Prozentsatz der Anwendungen, die von allen Organisationen für eine bestimmte CWE getestet wurden. + +**Gesamtanzahl:** Gesamtzahl der Anwendungen, bei denen die einer Kategorie zugeordneten CWEs festgestellt wurden. + +**Gesamtzahl der CVEs:** Gesamtzahl der CVEs in der NVD-Datenbank, die den einer Kategorie zugeordneten CWEs zugeordnet wurden. + +**Formel:** (Max. Inzidenzrate % * 1000) + (Max. Abdeckung % * 100) + (Durchschnittliche Ausnutzbarkeit * 10) + (Durchschnittliche Auswirkungen * 20) + (Summe der Vorkommen / 10000) = Risikowert diff --git a/2025/docs/de/0x03_2025-Establishing_a_Modern_Application_Security_Program.md b/2025/docs/de/0x03_2025-Establishing_a_Modern_Application_Security_Program.md new file mode 100644 index 000000000..10021f922 --- /dev/null +++ b/2025/docs/de/0x03_2025-Establishing_a_Modern_Application_Security_Program.md @@ -0,0 +1,299 @@ +# Aufbau eines modernen Programms zur Anwendungssicherheit + +Die OWASP-Top-10-Listen sind Informationsdokumente, die darauf abzielen, das Bewusstsein für die kritischsten Risiken des jeweiligen Themas zu schärfen. Sie sind nicht als vollständige Liste gedacht, sondern lediglich als Ausgangspunkt. In früheren Versionen dieser Liste haben wir die Einführung eines Programms zur Anwendungssicherheit als besten Weg empfohlen, um diese und weitere Risiken zu vermeiden. In diesem Abschnitt behandeln wir, wie man ein modernes Programm zur Anwendungssicherheit aufbaut und weiterentwickelt. + +Wenn Sie bereits über ein Anwendungssicherheitsprogramm verfügen, sollten Sie eine Reifegradbewertung mithilfe von [OWASP SAMM (Software Assurance Maturity Model)](https://owasp.org/www-project-samm/) oder DSOMM (DevSecOps Maturity Model) durchführen. Diese Reifegradmodelle sind umfassend und ausführlich und können Ihnen dabei helfen, herauszufinden, worauf Sie Ihre Bemühungen zur Erweiterung und Weiterentwicklung Ihres Programms am besten konzentrieren sollten. Bitte beachten Sie: Sie müssen nicht alle Schritte in OWASP SAMM oder DSOMM durchführen, um gute Arbeit zu leisten; die Modelle dienen als Leitfaden und bieten viele Optionen. Sie sollen keine unerreichbaren Standards vorgeben oder unerschwingliche Programme beschreiben. Sie sind umfassend, um Ihnen viele Ideen und Optionen zu bieten. + +Wenn Sie ein Programm von Grund auf neu starten oder OWASP SAMM oder DSOMM für Ihr Team derzeit als „zu viel“ empfinden, lesen Sie bitte die folgenden Ratschläge. + + +### 1. Einführung eines risikobasierten Portfolioansatzes: + +* Ermitteln Sie den Schutzbedarf Ihres Anwendungsportfolios aus geschäftlicher Sicht. Dabei sollten unter anderem Datenschutzgesetze und andere Vorschriften berücksichtigt werden, die für die zu schützenden Datenbestände relevant sind. + +* Erstellen Sie ein [Risikobewertungsmodell](https://owasp.org/www-community/OWASP_Risk_Rating_Methodology) mit einem einheitlichen Satz von Wahrscheinlichkeits- und Auswirkungsfaktoren, die die Risikotoleranz Ihres Unternehmens widerspiegeln. + +* Bewerten und priorisieren Sie entsprechend alle Ihre Anwendungen und APIs. Fügen Sie die Ergebnisse Ihrer [Konfigurationsmanagement-Datenbank (CMDB)](https://de.wikipedia.org/wiki/Configuration_Management_Database) hinzu. + +* Legen Sie Sicherheitsrichtlinien fest, um den erforderlichen Umfang und Grad an Genauigkeit richtig zu definieren. + + +### 2. Schaffung einer soliden Grundlage: + +* Legen Sie eine Reihe gezielter Richtlinien und Standards fest, die allen Entwicklungsteams als Grundlage für die Anwendungssicherheit dienen. + +* Definieren Sie einen gemeinsamen Satz wiederverwendbarer Sicherheitsmaßnahmen, die diese Richtlinien und Standards ergänzen, und geben Sie Leitlinien für deren Anwendung in den Bereichen Design und Entwicklung vor. + +* Erstellen Sie ein obligatorisches Schulungsprogramm zur Anwendungssicherheit, das auf verschiedene Entwicklungsrollen und Themen zugeschnitten ist. + +### 3. Integration von Sicherheit in bestehende Prozesse: + +* Definieren und integrieren Sie Maßnahmen zur sicheren Implementierung und Verifizierung in bestehende Entwicklungs- und Betriebsprozesse. + +* Zu diesen Maßnahmen gehören Bedrohungsmodellierung, sicheres Design und Designprüfung, sicheres Programmieren und Codeüberprüfung, Penetrationstests sowie die Behebung von Schwachstellen. + +* Stellen Sie Fachexpert:innen und Unterstützungsdienste bereit, damit Entwicklungs- und Projektteams erfolgreich arbeiten können. + +* Überprüfen Sie Ihren aktuellen Systementwicklungslebenszyklus sowie alle Aktivitäten, Werkzeuge, Richtlinien und Prozesse im Bereich Softwaresicherheit und dokumentieren Sie diese anschließend. + +* Fügen Sie bei neuer Software eine oder mehrere Sicherheitsmaßnahmen in jede Phase des Systementwicklungslebenszyklus (SDLC) ein. Im Folgenden finden Sie zahlreiche Vorschläge, was Sie tun können. Stellen Sie sicher, dass Sie diese neuen Maßnahmen bei jedem neuen Projekt oder jeder neuen Softwareinitiative durchführen. Auf diese Weise können Sie sicher sein, dass jede neue Software mit einem für Ihr Unternehmen akzeptablen Sicherheitsniveau ausgeliefert wird. + +* Wählen Sie Ihre Maßnahmen so aus, dass Ihr Endprodukt ein für Ihr Unternehmen akzeptables Risikoniveau aufweist. + +* Für bestehende Software (manchmal auch als Legacy-Software bezeichnet) sollten Sie über einen formellen Wartungsplan verfügen. Ideen zur Aufrechterhaltung sicherer Anwendungen finden Sie weiter unten im Abschnitt „Betrieb und Änderungsmanagement“. + + +### 4. Schulungen zur Anwendungssicherheit: + +* Erwägen Sie die Einführung eines „Security Champion“-Programms oder eines allgemeinen Sicherheitsschulungsprogramms für Ihre Entwickler:innen (manchmal auch als „Security Awareness“-Programm bezeichnet), um ihnen alles beizubringen, was sie Ihrer Meinung nach wissen sollten. So bleiben sie auf dem neuesten Stand, lernen, wie sie ihre Arbeit sicher ausführen können, und tragen dazu bei, die Sicherheitskultur in Ihrem Unternehmen positiver zu gestalten. Oft verbessert dies auch das Vertrauen zwischen den Teams und sorgt für ein harmonischeres Arbeitsklima. OWASP unterstützt Sie dabei mit dem [OWASP Security Champions Guide](https://securitychampions.owasp.org/), der Schritt für Schritt erweitert wird. + +* Das OWASP Education Project stellt Schulungsmaterialien bereit, um Entwickler:innen in Bezug auf Webanwendungssicherheit zu schulen. Für praktisches Lernen über Schwachstellen probieren Sie das [OWASP Juice Shop Project](https://owasp.org/www-project-juice-shop/) oder [OWASP WebGoat](https://owasp.org/www-project-webgoat/) aus. Um auf dem Laufenden zu bleiben, besuchen Sie eine [OWASP AppSec Konferenz](https://owasp.org/events/), ein [OWASP Konferenz Training](https://owasp.org/events/) oder lokale Treffen der [OWASP-Chapters](https://owasp.org/chapters/). + + +### 5. Transparenz für das Management schaffen: + +* Managen Sie anhand von Kennzahlen. Treiben Sie Verbesserungen und Finanzierungsentscheidungen auf der Grundlage der erfassten Kennzahlen und Analysedaten voran. Zu den Kennzahlen gehören die Einhaltung von Sicherheitspraktiken und -maßnahmen, neu auftretende Schwachstellen, behobene Schwachstellen, Anwendungsabdeckung, Fehlerdichte nach Art und Anzahl der Vorkommen usw. + +* Analysieren Sie Daten aus den Implementierungs- und Verifizierungsaktivitäten, um nach Ursachen und Schwachstellenmustern zu suchen und so strategische und systemische Verbesserungen im gesamten Unternehmen voranzutreiben. Lernen Sie aus Fehlern und bieten Sie positive Anreize, um Verbesserungen zu fördern. + + + +## Einrichtung und Anwendung wiederholbarer Sicherheitsprozesse und standardisierter Sicherheitskontrollen + +### Phase der Anforderungs- und Ressourcenverwaltung: + +* Erfassen und verhandeln Sie gemeinsam mit dem Fachbereich die geschäftlichen Anforderungen an eine Anwendung, einschließlich der Schutzanforderungen hinsichtlich Vertraulichkeit, Authentizität, Integrität und Verfügbarkeit aller Datenbestände sowie der erwarteten Geschäftslogik. + +* Erstellen Sie die technischen Anforderungen, einschließlich funktionaler und nicht-funktionaler Sicherheitsanforderungen. OWASP empfiehlt, den [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) als Leitfaden für die Festlegung der Sicherheitsanforderungen für Ihre Anwendung(en) zu verwenden. + +* Planen und verhandeln Sie das Budget, das alle Aspekte von Entwurf, Entwicklung, Test und Betrieb abdeckt, einschließlich der Sicherheitsmaßnahmen. + +* Nehmen Sie Sicherheitsmaßnahmen in Ihren Projektplan auf. + +* Stellen Sie sich beim Projektstart als Sicherheitsbeauftragte:r vor, damit die Projektbeteiligten wissen, an wen sie sich wenden können. + + +### Ausschreibung und Vertragsabschluss: + +* Verhandeln Sie die Anforderungen mit internen oder externen Entwickler:innen, einschließlich Richtlinien und Sicherheitsanforderungen im Hinblick auf Ihr Sicherheitsprogramm, z. B. SDLC und bewährte Methoden. + +* Bewerten Sie die Erfüllung aller technischen Anforderungen, einschließlich einer Planungs- und Entwurfsphase. + +* Verhandeln Sie alle technischen Anforderungen, einschließlich Design, Sicherheit und Leistungsvereinbarung (SLA). + +* Verwenden Sie Vorlagen und Checklisten, wie z. B. den [OWASP Secure Software Contract Annex](https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex).
**Hinweis:** *Der Anhang bezieht sich auf das US-Vertragsrecht; bitte holen Sie daher qualifizierten Rechtsrat ein, bevor Sie den Musteranhang verwenden.* + + +### Planungs- und Entwurfsphase: + +* Besprechen Sie die Planung und den Entwurf mit den Entwicklern und internen Beteiligten, z. B. Sicherheitsspezialisten. + +* Definieren Sie die Sicherheitsarchitektur, Kontrollmaßnahmen, Gegenmaßnahmen und Entwurfsprüfungen (design reviews) entsprechend den Schutzanforderungen und dem erwarteten Bedrohungsniveau. Dies sollte von Sicherheitsspezialisten unterstützt werden. + +* Anstatt Sicherheitsfunktionen nachträglich in Ihre Anwendungen und APIs zu integrieren, ist es weitaus kostengünstiger, die Sicherheit von Anfang an mit einzuplanen. OWASP empfiehlt die [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/index.html) und die [OWASP Proactive Controls](https://top10proactive.owasp.org/) als guten Ausgangspunkt für Anleitungen zur Gestaltung von von Anfang an integrierter Sicherheit. + +* Führen Sie eine Bedrohungsmodellierung durch, siehe [OWASP Cheat Sheet: Bedrohungsmodellierung](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html). + +* Vermitteln Sie Ihren Softwarearchitekt:innen sichere Designkonzepte und -muster und bitten Sie sie, diese nach Möglichkeit in ihre Entwürfe zu integrieren. + +* Prüfen Sie gemeinsam mit Ihren Entwickler:innen die Datenflüsse. + +* Fügen Sie neben all Ihren anderen User Stories auch Sicherheits-User-Stories hinzu. + + +### Sicherer Entwicklungslebenszyklus: + +* Um den Prozess zu verbessern, den Ihr Unternehmen bei der Entwicklung von Anwendungen und APIs befolgt, empfiehlt OWASP das [OWASP Software Assurance Maturity Model (SAMM)](https://owasp.org/www-project-samm/). Dieses Modell hilft Unternehmen dabei, eine Strategie für Softwaresicherheit zu formulieren und umzusetzen, die auf die spezifischen Risiken zugeschnitten ist, denen Ihr Unternehmen ausgesetzt ist. + +* Bieten Sie Ihren Softwareentwickler:innen Schulungen zum sicheren Programmieren sowie alle anderen Schulungen an, von denen Sie glauben, dass sie ihnen helfen, robustere und sicherere Anwendungen zu erstellen. + +* Code-Review, siehe [OWASP Cheat Sheet: Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html). + +* Stellen Sie Ihren Entwickler:innen Sicherheitswerkzeuge zur Verfügung und bringen Sie ihnen deren Nutzung bei, insbesondere im Hinblick auf statische Analyse, Software-Kompositionsanalyse, Geheimnisscanner (Secrets) und [Infrastructure als Code (IaC)](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html). + +* Schaffen Sie nach Möglichkeit Leitplanken für Ihre Entwickler:innen (technische Schutzmaßnahmen, die sie zu sichereren Entscheidungen lenken). + +* Die Entwicklung robuster und benutzungsfreundlicher Sicherheitsmaßnahmen ist schwierig. Bieten Sie nach Möglichkeit sichere Standardeinstellungen an und schaffen Sie „gepflasterte Wege“ (indem Sie den einfachsten Weg auch zum sichersten Weg machen, also zur naheliegenden und bevorzugten Vorgehensweise). Die [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/index.html) sind ein guter Ausgangspunkt für Entwickler:innen, und viele moderne Frameworks verfügen mittlerweile über standardmäßige und wirksame Sicherheitskontrollen für Autorisierung, Validierung, CSRF-Prävention usw. + +* Stellen Sie Ihren Entwickler:innen sicherheitsrelevante Entwicklungsumgebungsplugins zur Verfügung und ermutigen Sie sie, diese zu nutzen. + +* Stellen Sie ihnen ein Werkzeug zur Verwaltung von Geheimnissen (Secrets) und die nötigen Lizenzen und eine Dokumentation zur Verwendung bereit. + +* Stellen Sie ihnen eine private KI zur Verfügung, idealerweise eingerichtet mit einem RAG-Server voller nützlicher Sicherheitsdokumentation, Prompts, die Ihr Team für bessere Ergebnisse verfasst hat, und einem MCP-Server, der die für Ihre Organisation ausgewählten Sicherheitswerkzeuge aufruft. Bringen Sie ihnen bei, wie man KI sicher nutzt, denn sie werden es tun, ob es Ihnen gefällt oder nicht. + + +### Einführung kontinuierlicher Tests zur Anwendungssicherheit: + +* Prüfen Sie technische Funktionen, die Integration in die IT-Architektur und Koordinieren Sie Tests der Fachlogik. + +* Erstellung von Testfällen für „korrekte“ und „missbräuchliche“ Nutzung aus technischer und geschäftlicher Perspektive. + +* Verwalten Sie Sicherheitstests gemäß internen Prozessen, den Schutzanforderungen und dem von der Anwendung angenommenen Bedrohungsgrad. + +* Stellen Sie Sicherheitstest-Werkzeuge (Fuzzer, DAST usw.), eine sichere Testumgebung und Schulungen zu deren Verwendung bereit, ODER führen Sie die Tests für sie durch ODER beauftragen Sie eine:n Tester:in. + +* Wenn Sie ein hohes Maß an Sicherheit benötigen, ziehen Sie einen formellen Penetrationstest sowie Stress- und Leistungstests (Performance) in Betracht. + +* Arbeiten Sie mit Ihren Entwickler:innen zusammen, um ihnen bei der Entscheidung zu helfen, was aus den Fehlerberichten behoben werden muss, und stellen Sie sicher, dass ihre Vorgesetzten ihnen die dafür erforderliche Zeit einräumen. + + +### Inbetriebnahme: + +* Die Anwendung in Betrieb nehmen und bei Bedarf von zuvor verwendeten Anwendungen migrieren. + +* Die gesamte Dokumentation fertigstellen, einschließlich der Change-Management-Datenbank (CMDB) und der Sicherheitsarchitektur. + + +### Betrieb und Änderungsmanagement: + +* Der Betrieb muss Richtlinien für das Sicherheitsmanagement der Anwendung enthalten (z. B. Patch-Management). + +* Das Sicherheitsbewusstsein der Benutzer:innen schärfen und Konflikte zwischen Benutzbarkeit und Sicherheit bewältigen. + +* Änderungen planen (Change Management) und verwalten, z. B. die Migration auf neue Versionen der Anwendung oder anderer Komponenten wie Betriebssystem, Middleware und Bibliotheken. + +* Stellen Sie sicher, dass alle Anwendungen in Ihrem Bestand erfasst sind und alle wichtigen Details dokumentiert sind. Aktualisieren Sie die gesamte Dokumentation, einschließlich der CMDB sowie der Sicherheitsarchitektur, Kontrollen und Gegenmaßnahmen, einschließlich aller Betriebshandbücher oder Projektdokumentationen. + +* Nutzen Sie Protokollierung, Überwachung und Alarmierung für alle Anwendungen. Fügen Sie diese hinzu, falls sie fehlen. + +* Erstellen Sie Prozesse für eine effektive und effiziente Aktualisierung und Patch-Verwaltung. + +* Erstellen Sie regelmäßige Scan-Zeitpläne (idealerweise für dynamische, statische, Secret-, IaC- und Software-Composition-Analysen). + +* Definieren Sie SLAs für die Behebung von Sicherheitsfehlern. + +* Stellen Sie eine Möglichkeit für Mitarbeiter:innen (und idealerweise auch für Ihre Kund:innen) bereit, Fehler zu melden. + +* Richten Sie ein geschultes Vorfallreaktionsteam (Incident Response) ein, das weiß, wie Softwareangriffe aussehen, und das mit Überwachungswerkzeugen (Observability-Tools) vertraut ist. + +* Setzen Sie Blockierungs- oder Schutz-Werkzeuge ein, um automatisierte Angriffe zu stoppen. + +* Jährliche (oder häufigere) Absicherung der Konfigurationen. + +* Mindestens jährliche Penetrationstests (abhängig vom für Ihre Anwendung erforderlichen Sicherheitsniveau). + +* Richten Sie Prozesse und Werkzeuge zur Absicherung und zum Schutz Ihrer Software-Lieferkette ein. + +* Erstellen und aktualisieren Sie Pläne zur Geschäftskontinuität und Notfallwiederherstellung, die Ihre wichtigsten Anwendungen sowie die zu deren Wartung verwendeten Werkzeuge umfassen. + + +### Außerbetriebnahme von Systemen: + +* Alle erforderlichen Daten sollten archiviert werden. Alle übrigen Daten sollten sicher gelöscht werden. + +* Nehmen Sie die Anwendung sicher außer Betrieb, einschließlich der Löschung nicht mehr genutzter Konten, Rollen und Berechtigungen. + +* Setzen Sie den Status Ihrer Anwendung in der CMDB auf „außer Betrieb“. + + +## Die Verwendung der OWASP Top 10 als Standard + +Die OWASP Top 10 ist in erster Linie ein Dokument zur Sensibilisierung. Dies hat Unternehmen jedoch nicht davon abgehalten, sie seit ihrer Einführung im Jahr 2003 als de-facto-Standard für die Anwendungssicherheit in der Branche zu nutzen. Wenn Sie die OWASP Top 10 als Standard für die Programmierung oder das Testen verwenden möchten, sollten Sie sich bewusst sein, dass sie das absolute Minimum darstellt und lediglich einen Ausgangspunkt bildet. + +Eine der Schwierigkeiten bei der Verwendung der OWASP Top 10 als Standard besteht darin, dass wir AppSec-Risiken und nicht unbedingt leicht testbare Probleme dokumentieren. Beispielsweise geht [A06:2025 – Unsicheres Design](A06_2025-Insecure_Design.md) über den Rahmen der meisten Testverfahren hinaus. Ein weiteres Beispiel ist die Prüfung, ob eine vor Ort vorhandene, genutzte und wirksame Protokollierung und Überwachung implementiert ist, was nur durch Befragungen und die Anforderung einer Stichprobe wirksamer Reaktionen auf Vorfälle erfolgen kann. Ein statisches Code-Analyse-Werkzeug kann zwar nach fehlender Protokollierung suchen, aber es ist möglicherweise unmöglich festzustellen, ob die Geschäftslogik oder die Zugriffskontrolle kritische Sicherheitsverletzungen protokolliert. Penetrationstester:innen können möglicherweise nur feststellen, dass sie in einer Testumgebung eine Reaktion auf Vorfälle ausgelöst haben, die selten auf die gleiche Weise überwacht wird wie die Produktionsumgebung. + +Hier sind unsere Empfehlungen dazu, wann die Verwendung der OWASP Top 10 sinnvoll ist: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Anwendungsfall + OWASP Top 10 2025 + OWASP Application Security Verification Standard +
Sensibilisierung + Ja + +
Schulung + Zum Einstieg + Umfassend +
Design und Architektur + Gelegentlich + Ja +
Programmier-Standard + Absolutes Minimum + Ja +
Prüfung des Codes
(Secure Code Review) + 		Absolutes Minimum + Ja +
Checkliste für gegenseitige Begutachtung (Peer Review) + Absolutes Minimum + Ja +
Unit-Tests + Gelegentlich + Ja +
Integrationstests + Gelegentlich + Ja +
Penetrations-Tests + Absolutes Minimum + Ja +
Werkzeug-Unterstützung + Absolutes Minimum + Ja +
Sichere Lieferketten + Gelegentlich + Ja +
+ + +Wir empfehlen allen, die einen Standard für die Anwendungssicherheit einführen möchten, den [OWASP Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard/) (ASVS) zu verwenden, da dieser so konzipiert ist, dass er überprüfbar und testbar ist, und in allen Phasen eines sicheren Entwicklungszyklus eingesetzt werden kann. + +Der ASVS ist die einzig akzeptable Wahl für Werkzeug-Anbieter:innen. Werkzeuge können die OWASP Top 10 aufgrund der Natur einiger der darin enthaltenen Risiken nicht umfassend erkennen, testen oder dagegen schützen, siehe [A06:2025 – Unsicheres Design](A06_2025-Insecure_Design.md). OWASP rät von jeglichen Behauptungen ab, die OWASP Top 10 vollständig abzudecken, da dies schlichtweg nicht der Wahrheit entspricht. diff --git a/2025/docs/de/A01_2025-Broken_Access_Control.md b/2025/docs/de/A01_2025-Broken_Access_Control.md new file mode 100644 index 000000000..747040d84 --- /dev/null +++ b/2025/docs/de/A01_2025-Broken_Access_Control.md @@ -0,0 +1,225 @@ +# A01:2025 Mangelhafte Zugriffskontrolle icon + + + +## Hintergrund. + +100 % der getesteten Anwendungen wiesen irgendeine Form fehlerhafter Zugriffskontrolle auf. +An der Spitze der Top 10 verbleibend, weist diese Kategorie die höchste Anzahl an Vorkommnissen im vorliegenden Datensatz sowie die zweithöchste Anzahl zugehöriger CVEs auf. +Bemerkenswerte Common Weakness Enumerations (CWEs) sind *CWE-200: Exposure of Sensitive Information to an Unauthorized Actor*, *CWE-201: Insertion of Sensitive Information Into Sent Data*, *CWE-918: Server-Side Request Forgery (SSRF)* und *CWE-352: Cross-Site Request Forgery (CSRF)*. + +## Punktetabelle. + + + + + + + + + + + + + + + + + + + + + + + + + +
Zugeordnete CWEs + Max. Häufigkeit + Durchschn. Häufigkeit + Max. Abdeckung + Durchschn. Abdeckung + Durchschn. gewichtete Ausnutzbarkeit + Durchschn. gewichtete Auswirkung + Gesamtanzahl + Summe CVEs +
40 + 20.15% + 3.74% + 100.00% + 42.93% + 7.04 + 3.84 + 1,839,701 + 32,654 +
+ + + +## Beschreibung. + +Die Zugriffskontrolle erzwingt Richtlinien, sodass Nutzer:innen nicht außerhalb ihrer vorgesehenen Berechtigungen handeln können. Fehler führen in der Regel zur unbefugten Offenlegung, Änderung oder Zerstörung aller Daten oder zur Ausführung einer Geschäftsfunktion außerhalb der Verfügungen der Anwender:innen. Zu den häufigsten Schwachstellen bei der Zugriffskontrolle gehören: + + + +* Verstoß gegen die Prinzipien der geringsten Rechte oder der standardmäßigen Verweigerung, bei dem der Zugriff nur für bestimmte Fähigkeiten, Rollen oder Nutzer:innen gewährt werden sollte, aber für jede Person verfügbar ist. +* Umgehen von Zugriffskontrollprüfungen durch Ändern der URL (Parametermanipulation oder erzwungenes Durchsuchen), des internen Anwendungsstatus oder der HTML-Seite oder durch Verwendung eines Angriffstools zur Änderung von API-Anfragen. +* Ermöglichen, das Konto einer anderen Person anzuzeigen oder zu bearbeiten, indem dessen eindeutige Kennung angegeben wird (unsichere direkte Objektreferenzen). +* Eine zugängliche API mit fehlenden Zugriffskontrollen für POST, PUT und DELETE. +* Erhöhung der Privilegien. Als Nutzer:in fungieren, ohne angemeldet zu sein oder als Administrator:in fungieren, wenn man als Standard-Nutzer:in angemeldet ist. +* Manipulation von Metadaten, wie z. B. das Abfangen oder Manipulieren eines JSON Web Token (JWT)-Zugriffskontrolltokens oder die Manipulation eines Cookies oder eines versteckten Felds, um Berechtigungen zu erhöhen oder die Ungültigerklärung von JWTs zu missbrauchen. +* CORS-Fehlkonfiguration ermöglicht API-Zugriff von nicht autorisierten/nicht vertrauenswürdigen Quellen. +* Erzwingen des Zugriffs auf authentifizierte Seiten als nicht authentifizierte Person oder zu privilegierten Seiten als Standard-Nutzer:in. + + +## Prävention und Gegenmaßnahmen. + +Die Zugriffskontrolle ist nur wirksam bei vertrauenswürdigem serverseitigem Code oder serverlosen APIs, bei denen Angreifer:innen die Zugriffskontrollprüfung oder Metadaten nicht ändern können. + + + +* Verweigern Sie standardmäßig den Zugriff, mit Ausnahme öffentlicher Ressourcen. +* Implementieren Sie Zugriffskontrollmechanismen einmalig und verwenden Sie diese in der gesamten Anwendung wieder, einschließlich der Minimierung der Nutzung von Cross-Origin Resource Sharing (CORS). +* Modellzugriffskontrollen sollten die Datensatzeigentümerschaft erzwingen, anstatt zu akzeptieren, dass Nutzer:innen Datensätze erstellen, lesen, aktualisieren oder löschen können. +* Durch Domänenmodelle sollten eindeutige Geschäftslimitanforderungen für Anwendungen durchgesetzt werden. +* Deaktivieren Sie die Verzeichnisliste des Webservers und stellen Sie sicher, dass Dateimetadaten (z. B. .git) und Sicherungsdateien nicht in Web-Roots vorhanden sind. +* Protokollieren Sie Fehler bei der Zugriffskontrolle und benachrichtigen Sie Administrator:innen bei Bedarf (z. B. wiederholte Fehler). +* Setzen Sie Ratenbegrenzung für API- und Controller-Zugriff, um den Schaden durch automatisierte Angriffstools zu minimieren. +* Statusbehaftete Sitzungskennungen sollten nach dem Abmelden auf dem Server ungültig gemacht werden. Zustandslose JWT-Token sollten eher kurzlebig sein, damit das Zeitfenster für Angreifer:innen minimiert wird. Für langlebigere JWTs wird dringend empfohlen, die OAuth-Standards zu befolgen, um den Zugriff zu widerrufen. +* Verwenden Sie bewährte Toolkits oder Muster, die einfache, deklarative Zugriffskontrollen bieten. + +Entwickler:innen und QA-Mitarbeiter:innen sollten funktionale Zugriffskontrolleinheiten und Integrationstests durchführen. + + +## Beispielhafte Angriffsszenarien. + +**Szenario Nr. 1:** Die Anwendung verwendet nicht überprüfte Daten in einem SQL-Aufruf, der auf Kontoinformationen zugreift: + + +``` +pstmt.setString(1, request.getParameter("acct")); +ResultSet results = pstmt.executeQuery( ); +``` + + +Angreifer:innen ändern einfach den „acct“-Parameter des Browsers, um die gewünschte Kontonummer zu senden. Bei nicht korrekter Überprüfung kann die/der Angreifer:in auf das Konto einer beliebigen Nutzer:in zugreifen. + + +``` +https://example.com/app/accountInfo?acct=notmyacct +``` + + +**Szenario Nr. 2:** Angreifer:innen erzwingen einfach die Suche nach Ziel-URLs. Für den Zugriff auf die Admin-Seite sind Admin-Rechte erforderlich. + + +``` +https://example.com/app/getappInfo +https://example.com/app/admin_getappInfo +``` + + +Wenn eine nicht authentifizierte Benutzer:in auf eine der Seiten zugreifen kann, liegt ein Fehler vor. Wenn ein Benutzer:in ohne Administrationsrechte auf die Admin-Seite zugreifen kann, handelt es sich um einen Fehler. + +**Szenario Nr. 3:** Eine Anwendung verwaltet ihre gesamte Zugriffskontrolle im Frontend. Während die/der Angreifer:in aufgrund von im Browser ausgeführtem JavaScript-Code nicht auf `https://example.com/app/admin_getappInfo` zugreifen kann, kann sie/er einfach Folgendes ausführen: + + +``` +$ curl https://example.com/app/admin_getappInfo +``` + + +von der Kommandozeile aus. + + +## Referenzen. + +* [OWASP Proactive Controls: C1: Implement Access Control](https://top10proactive.owasp.org/archive/2024/the-top-10/c1-accesscontrol/) +* [OWASP Application Security Verification Standard: V8 Authorization](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x17-V8-Authorization.md) +* [OWASP Testing Guide: Authorization Testing](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/README) +* [OWASP Cheat Sheet: Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) +* [PortSwigger: Exploiting CORS misconfiguration](https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) +* [OAuth: Revoking Access](https://www.oauth.com/oauth2-servers/listing-authorizations/revoking-access/) + + +## Liste der zugeordneten CWEs + +* [CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')](https://cwe.mitre.org/data/definitions/22.html) + +* [CWE-23 Relative Path Traversal](https://cwe.mitre.org/data/definitions/23.html) + +* [CWE-36 Absolute Path Traversal](https://cwe.mitre.org/data/definitions/36.html) + +* [CWE-59 Improper Link Resolution Before File Access ('Link Following')](https://cwe.mitre.org/data/definitions/59.html) + +* [CWE-61 UNIX Symbolic Link (Symlink) Following](https://cwe.mitre.org/data/definitions/61.html) + +* [CWE-65 Windows Hard Link](https://cwe.mitre.org/data/definitions/65.html) + +* [CWE-200 Exposure of Sensitive Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/200.html) + +* [CWE-201 Exposure of Sensitive Information Through Sent Data](https://cwe.mitre.org/data/definitions/201.html) + +* [CWE-219 Storage of File with Sensitive Data Under Web Root](https://cwe.mitre.org/data/definitions/219.html) + +* [CWE-276 Incorrect Default Permissions](https://cwe.mitre.org/data/definitions/276.html) + +* [CWE-281 Improper Preservation of Permissions](https://cwe.mitre.org/data/definitions/281.html) + +* [CWE-282 Improper Ownership Management](https://cwe.mitre.org/data/definitions/282.html) + +* [CWE-283 Unverified Ownership](https://cwe.mitre.org/data/definitions/283.html) + +* [CWE-284 Improper Access Control](https://cwe.mitre.org/data/definitions/284.html) + +* [CWE-285 Improper Authorization](https://cwe.mitre.org/data/definitions/285.html) + +* [CWE-352 Cross-Site Request Forgery (CSRF)](https://cwe.mitre.org/data/definitions/352.html) + +* [CWE-359 Exposure of Private Personal Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/359.html) + +* [CWE-377 Insecure Temporary File](https://cwe.mitre.org/data/definitions/377.html) + +* [CWE-379 Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +* [CWE-402 Transmission of Private Resources into a New Sphere ('Resource Leak')](https://cwe.mitre.org/data/definitions/402.html) + +* [CWE-424 Improper Protection of Alternate Path](https://cwe.mitre.org/data/definitions/424.html) + +* [CWE-425 Direct Request ('Forced Browsing')](https://cwe.mitre.org/data/definitions/425.html) + +* [CWE-441 Unintended Proxy or Intermediary ('Confused Deputy')](https://cwe.mitre.org/data/definitions/441.html) + +* [CWE-497 Exposure of Sensitive System Information to an Unauthorized Control Sphere](https://cwe.mitre.org/data/definitions/497.html) + +* [CWE-538 Insertion of Sensitive Information into Externally-Accessible File or Directory](https://cwe.mitre.org/data/definitions/538.html) + +* [CWE-540 Inclusion of Sensitive Information in Source Code](https://cwe.mitre.org/data/definitions/540.html) + +* [CWE-548 Exposure of Information Through Directory Listing](https://cwe.mitre.org/data/definitions/548.html) + +* [CWE-552 Files or Directories Accessible to External Parties](https://cwe.mitre.org/data/definitions/552.html) + +* [CWE-566 Authorization Bypass Through User-Controlled SQL Primary Key](https://cwe.mitre.org/data/definitions/566.html) + +* [CWE-601 URL Redirection to Untrusted Site ('Open Redirect')](https://cwe.mitre.org/data/definitions/601.html) + +* [CWE-615 Inclusion of Sensitive Information in Source Code Comments](https://cwe.mitre.org/data/definitions/615.html) + +* [CWE-639 Authorization Bypass Through User-Controlled Key](https://cwe.mitre.org/data/definitions/639.html) + +* [CWE-668 Exposure of Resource to Wrong Sphere](https://cwe.mitre.org/data/definitions/668.html) + +* [CWE-732 Incorrect Permission Assignment for Critical Resource](https://cwe.mitre.org/data/definitions/732.html) + +* [CWE-749 Exposed Dangerous Method or Function](https://cwe.mitre.org/data/definitions/749.html) + +* [CWE-862 Missing Authorization](https://cwe.mitre.org/data/definitions/862.html) + +* [CWE-863 Incorrect Authorization](https://cwe.mitre.org/data/definitions/863.html) + +* [CWE-918 Server-Side Request Forgery (SSRF)](https://cwe.mitre.org/data/definitions/918.html) + +* [CWE-922 Insecure Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/922.html) + +* [CWE-1275 Sensitive Cookie with Improper SameSite Attribute](https://cwe.mitre.org/data/definitions/1275.html) diff --git a/2025/docs/de/A02_2025-Security_Misconfiguration.md b/2025/docs/de/A02_2025-Security_Misconfiguration.md new file mode 100644 index 000000000..3a79fab03 --- /dev/null +++ b/2025/docs/de/A02_2025-Security_Misconfiguration.md @@ -0,0 +1,137 @@ +# A02:2025 Sicherheitsrelevante Fehlkonfiguration ![icon](../assets/TOP_10_Icons_Final_Security_Misconfiguration.png){: style="height:80px;width:80px" align="right"} + + +## Hintergrund. + +Die Kategorie rückt auf von Platz 5 in der vorherigen Ausgabe: 100 % der Anwendungen wurden auf irgendeine Form von Fehlkonfiguration getestet, mit einer durchschnittlichen Inzidenzrate von 3 % und über 719.000 Vorkommen einer Common Weakness Enumeration (CWE) in dieser Risikokategorie. Angesichts der zunehmenden Verlagerung hin zu hoch konfigurierbarer Software ist es nicht verwunderlich, dass diese Kategorie aufsteigt. Bemerkenswerte enthaltene CWEs sind *CWE-16 Configuration* und *CWE-611 Unproper Restriction of XML External Entity Reference (XXE)*. + +Eine sicherheitsrelevante Fehlkonfiguration liegt vor, wenn ein System, eine Anwendung oder ein Cloud-Dienst aus sicherheitstechnischer Sicht falsch eingerichtet ist, wodurch Schwachstellen entstehen. + + +## Punktetabelle. + + + + +    +    +    +    +    +    +    +    +    + + + + + + + + + + + + +
Zugeordnete CWEs +   Max. Häufigkeit +   Durchschn. Häufigkeit +   Max. Abdeckung +   Durchschn. Abdeckung +   Durchschn. gewichtete Ausnutzbarkeit +   Durchschn. gewichtete Auswirkung +   Gesamtanzahl +   Summe CVEs +   
16 + 27.70% + 3.00% + 100.00% + 52.35% + 7.96 + 3.97 + 719,084 + 1,375 +
+ + + +## Beschreibung. + +Die Anwendung besitzt möglicherweise Schwachstellen, wenn Folgendes zutrifft: +* Mangelhafte Sicherheitshärtung des Anwendungsstacks oder ungeeignet konfigurierte Berechtigungen auf Cloud-Diensten. +* Nicht benötigte Features sind aktiviert oder installiert (z. B. unnötige Ports, Dienste, Seiten, Accounts oder Rechte). +* Standardkonten und -passwörter sind aktiviert bzw. unverändert. +* Die Fehlerbehandlung gibt Stack-Traces oder andere interne technische Fehlermeldungen an Anwender:innen preis. +* Für aktualisierte Systeme sind die neuesten Sicherheitsfeatures deaktiviert oder nicht sicher konfiguriert. +* Die Sicherheitseinstellungen in den Anwendungsservern und -frameworks (z. B. Struts, Spring, ASP.NET), Bibliotheken, Datenbanken etc. sind nicht auf sichere Werte gesetzt. +* Der Server sendet keine Sicherheits-Header oder -Direktiven, bzw. diese sind nicht sicher konfiguriert. +* Die Software ist veraltet oder verwundbar (siehe [A06:2025-Unsichere oder veraltete Komponenten](A06_2025-Vulnerable_and_Outdated_Components.md)). + +Ohne einen abgestimmten und reproduzierbaren Prozess zur sicheren Konfiguration sind Systeme einem höheren Risiko ausgesetzt! + + +## Prävention und Gegenmaßnahmen. + +Es sollten sichere Installationsprozesse implementiert werden, darunter: + +* Ein wiederholbarer Härtungsprozess, welcher die schnelle und einfache Bereitstellung zusätzlicher Umgebungen, die entsprechend abgesichert sind, ermöglicht. Entwicklungs-, Qualitätssicherungs- und Produktionsumgebungen sollten alle identisch konfiguriert sein, wobei in jeder Umgebung unterschiedliche Zugangsdaten verwendet werden sollten. Dieser Prozess sollte automatisiert werden, um den Aufwand für die Einrichtung einer neuen sicheren Umgebung zu minimieren. +* Eine minimale Plattform ohne unnötige Funktionen, Komponenten, Dokumentation oder Beispiele: Entfernen Sie Funktionen und Frameworks die Sie nicht verwenden oder installieren Sie diese erst gar nicht. +* Überprüfen und Aktualisieren der Konfigurationen, die für alle Sicherheitshinweise, Updates und Patches im Rahmen des Patch-Verwaltungsprozesses geeignet sind (siehe [A03:2025 – Schwachstellen in der Software-Lieferkette](A03_2025-Software_Supply_Chain_Failures.md)). Überprüfen Sie die Cloud-Speicherberechtigungen (z. B. S3-Bucket-Berechtigungen). + + +## Beispielhafte Angriffsszenarien. + +**Szenario Nr. 1:** Der Anwendungsserver wird mit Beispielanwendungen geliefert, die nicht vom Produktionsserver entfernt wurden. Diese Beispielanwendungen weisen bekannte Schwachstellen auf, die Angreifer:innen nutzen, um den Server zu gefährden. Angenommen, eine dieser Anwendungen ist die Admin-Konsole und die Standardkonten wurden nicht geändert. In diesem Fall meldet sich die/der Angreifer:in mit einem Standardkennwort an und übernimmt die Kontrolle. + +**Szenario Nr. 2:** Die Directory Listings wurden nicht auf dem Server deaktiviert. Angreifer:innen entdecken, dass Verzeichnisse einfach aufgelistet werden können. Die/Der Angreifer:in findet die kompilierten Java-Klassen und lädt sie herunter, dekompiliert sie und betreibt Reverse Engineering, um den Code anzuzeigen. Dies ermöglicht das Findet eines schwerwiegenden Fehlers in der Zugriffskontrolle in der Anwendung. + +**Szenario Nr. 3:** Die Konfiguration des Anwendungsservers ermöglicht die Rückgabe detaillierter Fehlermeldungen an Anwender:innen, wie z. B. Stack-Traces. Dadurch werden möglicherweise vertrauliche Informationen oder zugrunde liegende Fehler wie Komponentenversionen offengelegt, die als angreifbar bekannt sind. + +**Szenario Nr. 4:** Ein Cloud-Dienstanbieter (CSP) gewährt standardmäßig Freigabeberechtigungen zum Internet und ermöglicht dadurch Zugriff auf sensible Daten in der Cloud. + + +## Referenzen. + +* [OWASP Testing Guide: Configuration Management](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README) +* [OWASP Testing Guide: Testing for Error Codes](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) +* [Application Security Verification Standard V13 Configuration](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x22-V13-Configuration.md) +* [NIST Guide to General Server Hardening](https://csrc.nist.gov/publications/detail/sp/800-123/final) +* [CIS Security Configuration Guides/Benchmarks](https://www.cisecurity.org/cis-benchmarks/) +* [Amazon S3 Bucket Discovery and Enumeration](https://blog.websecurify.com/2017/10/aws-s3-bucket-discovery.html) +* ScienceDirect: Security Misconfiguration + + +## Liste der zugeordneten CWEs + +* [CWE-5 J2EE Misconfiguration: Data Transmission Without Encryption](https://cwe.mitre.org/data/definitions/5.html) + +* [CWE-11 ASP.NET Misconfiguration: Creating Debug Binary](https://cwe.mitre.org/data/definitions/11.html) + +* [CWE-13 ASP.NET Misconfiguration: Password in Configuration File](https://cwe.mitre.org/data/definitions/13.html) + +* [CWE-15 External Control of System or Configuration Setting](https://cwe.mitre.org/data/definitions/15.html) + +* [CWE-16 Configuration](https://cwe.mitre.org/data/definitions/16.html) + +* [CWE-260 Password in Configuration File](https://cwe.mitre.org/data/definitions/260.html) + +* [CWE-315 Cleartext Storage of Sensitive Information in a Cookie](https://cwe.mitre.org/data/definitions/315.html) + +* [CWE-489 Active Debug Code](https://cwe.mitre.org/data/definitions/489.html) + +* [CWE-526 Exposure of Sensitive Information Through Environmental Variables](https://cwe.mitre.org/data/definitions/526.html) + +* [CWE-547 Use of Hard-coded, Security-relevant Constants](https://cwe.mitre.org/data/definitions/547.html) + +* [CWE-611 Improper Restriction of XML External Entity Reference](https://cwe.mitre.org/data/definitions/611.html) + +* [CWE-614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute](https://cwe.mitre.org/data/definitions/614.html) + +* [CWE-776 Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')](https://cwe.mitre.org/data/definitions/776.html) + +* [CWE-942 Permissive Cross-domain Policy with Untrusted Domains](https://cwe.mitre.org/data/definitions/942.html) + +* [CWE-1004 Sensitive Cookie Without 'HttpOnly' Flag](https://cwe.mitre.org/data/definitions/1004.html) + +* [CWE-1174 ASP.NET Misconfiguration: Improper Model Validation](https://cwe.mitre.org/data/definitions/1174.html) diff --git a/2025/docs/de/A03_2025-Software_Supply_Chain_Failures.md b/2025/docs/de/A03_2025-Software_Supply_Chain_Failures.md new file mode 100644 index 000000000..d2873e0bc --- /dev/null +++ b/2025/docs/de/A03_2025-Software_Supply_Chain_Failures.md @@ -0,0 +1,174 @@ +# A03:2025 Schwachstellen in der Software-Lieferkette ![icon](../assets/TOP_10_Icons_Final_Vulnerable_Outdated_Components.png){: style="height:80px;width:80px" align="right"} + + +## Hintergrund. + +Diese Kategorie belegte den ersten Platz in der Community-Umfrage zu den Top 10, wobei genau 50 % der Teilnehmer:innen sie auf Rang 1 setzten. Seit ihrem ersten Erscheinen im Top 10 von 2013 als „A9 – Using Components with Known Vulnerabilities" hat sich der Risikobereich ausgeweitet und umfasst nun alle Lieferkettenfehler, nicht nur solche mit bekannten Schwachstellen. Trotz dieses erweiterten Umfangs sind Lieferkettenfehler mit nur 11 Common Vulnerability and Exposures (CVEs), die die zugehörigen CWEs aufweisen, nach wie vor schwer zu identifizieren. Werden sie jedoch getestet und in den beigetragenen Daten gemeldet, weist diese Kategorie mit 5,19 % die höchste durchschnittliche Vorfallsrate aller Kategorien auf. Die relevanten CWEs sind *CWE-477: Use of Obsolete Function, CWE-1104: Use of Unmaintained Third Party Components*, CWE-1329: *Reliance on Component That is Not Updateable*, und *CWE-1395: Dependency on Vulnerable Third-Party Component*. + + +## Punktetabelle. + + + + + + + + + + + + + + + + + + + + + + + + + +
Zugeordnete CWEs + Max. Häufigkeit + Durchschn. Häufigkeit + Max. Abdeckung + Durchschn. Abdeckung + Durchschn. gewichtete Ausnutzbarkeit + Durchschn. gewichtete Auswirkung + Gesamtanzahl + Summe CVEs +
6 + 9.56% + 5.72% + 65.42% + 27.47% + 8.17 + 5.23 + 215,248 + 11 +
+ + + +## Beschreibung. + +Schwachstellen in der Software-Lieferkette sind Störungen oder sonstige Kompromittierungen im Prozess der Erstellung, Verteilung oder Aktualisierung von Software. Sie werden häufig durch Schwachstellen oder böswillige Änderungen in Code, Werkzeugen oder anderen Abhängigkeiten von Drittanbietern verursacht, auf die das System angewiesen sind. + +Sie sind wahrscheinlich verwundbar, wenn: + +* Sie die Versionen aller verwendeten Komponenten (sowohl client- als auch serverseitig) nicht sorgfältig nachverfolgen. Dies umfasst sowohl direkt verwendete Komponenten als auch verschachtelte (transitive) Abhängigkeiten. +* Die Software verwundbar, nicht mehr unterstützt oder veraltet ist. Dies betrifft das Betriebssystem, Web-/Anwendungsserver, Datenbankmanagementsysteme (DBMS), Anwendungen, APIs und alle Komponenten, Laufzeitumgebungen und Bibliotheken. +* Sie keine regelmäßigen Schwachstellen-Scans durchführen und keine Sicherheitsbulletins zu den von Ihnen verwendeten Komponenten abonniert haben. +* Sie keinen Änderungsmanagementprozess oder keine Nachverfolgung von Änderungen in Ihrer Lieferkette haben, einschließlich der Nachverfolgung von IDEs, IDE-Erweiterungen und -Updates, Änderungen am Code-Repository Ihrer Organisation, Sandboxen, Image- und Bibliotheks-Repositories sowie der Art und Weise, wie Artefakte erstellt und gespeichert werden usw. Jeder Teil Ihrer Lieferkette sollte dokumentiert werden, insbesondere Änderungen. +* Sie nicht jeden Teil Ihrer Lieferkette abgesichert haben, mit besonderem Fokus auf Zugangskontrolle und die Anwendung des Prinzips der minimalen Rechtevergabe. +* Ihre Lieferkettensysteme keine Aufgabentrennung aufweisen. Keine einzelne Person sollte in der Lage sein, Code zu schreiben und ihn bis in die Produktion zu befördern, ohne die Aufsicht eines anderen Menschen. +* Komponenten aus nicht vertrauenswürdigen Quellen, über jeden Teil des Tech-Stacks hinweg, in Produktionsumgebungen verwendet werden oder diese beeinflussen können. +* Sie die zugrunde liegende Plattform, Frameworks und Abhängigkeiten nicht risikobasiert und zeitnah aktualisieren oder upgraden. Dies tritt häufig in Umgebungen auf, in denen das Patchen eine monatliche oder vierteljährliche Aufgabe unter Änderungskontrolle ist, wodurch Organisationen tagelangen oder monatelangen unnötigen Risiken ausgesetzt sind, bevor Schwachstellen behoben werden. +* Softwareentwickler:innen die Kompatibilität aktualisierter, upgegradeter oder gepatchter Bibliotheken nicht testen. +* Sie die Konfigurationen jedes Teils Ihres Systems nicht absichern (siehe [A02:2025-Security Misconfiguration](https://owasp.org/Top10/2025/A02_2025-Security_Misconfiguration/)). +* Ihre CI/CD-Pipeline eine schwächere Sicherheit aufweist als die Systeme, die sie erstellt und bereitstellt, insbesondere wenn sie komplex ist. + + +## Prävention und Gegenmaßnahmen. + +Es sollte ein Patch-Management-Prozess vorhanden sein, der: + + + +* Zentral das Software Bill of Materials (SBOM) Ihrer gesamten Software erstellt und verwaltet. +* Nicht nur Ihre direkten Abhängigkeiten, sondern auch deren (transitive) Abhängigkeiten usw. nachverfolgt. +* Die Angriffsfläche durch Entfernen ungenutzter Abhängigkeiten, unnötiger Funktionen, Komponenten, Dateien und Dokumentation reduziert. +* Die Versionen sowohl client- als auch serverseitiger Komponenten (z. B. Frameworks, Bibliotheken) und deren Abhängigkeiten kontinuierlich mit Tools wie OWASP Dependency Track, OWASP Dependency Check, retire.js usw. inventarisiert. +* Quellen wie Common Vulnerability and Exposures (CVE), National Vulnerability Database (NVD) und [Open Source Vulnerabilities (OSV)](https://osv.dev/) kontinuierlich auf Schwachstellen in den von Ihnen verwendeten Komponenten überwacht. Nutzen Sie Software-Kompositionsanalyse, Software-Supply-Chain- oder sicherheitsorientierte SBOM-Tools, um den Prozess zu automatisieren. Abonnieren Sie Warnungen zu Sicherheitsschwachstellen in den von Ihnen verwendeten Komponenten. +* Komponenten ausschließlich von offiziellen (vertrauenswürdigen) Quellen über sichere Verbindungen bezieht. Bevorzugen Sie signierte Pakete, um die Wahrscheinlichkeit zu verringern, eine modifizierte, bösartige Komponente einzubinden (siehe [A08:2025-Software and Data Integrity Failures](https://owasp.org/Top10/2025/A08_2025-Software_or_Data_Integrity_Failures/)). +* Bewusst wählt, welche Version einer Abhängigkeit verwendet wird, und nur bei Bedarf aktualisiert. +* Bibliotheken und Komponenten überwacht, die nicht mehr gewartet werden oder keine Sicherheits-Patches für ältere Versionen bereitstellen. Falls kein Patchen möglich ist, sollten Sie eine Migration zu einer Alternative in Betracht ziehen. Falls auch das nicht möglich ist, ziehen Sie den Einsatz eines virtuellen Patches in Betracht, um das entdeckte Problem zu überwachen, zu erkennen oder dagegen zu schützen. +* Ihre CI/CD-, IDE- und anderen Entwicklungs-Tools regelmäßig aktualisiert. +* Vermeidet, Updates gleichzeitig auf alle Systeme auszurollen. Nutzen Sie gestaffelte Rollouts oder Canary-Deployments, um das Risiko zu begrenzen, falls ein:e vertrauenswürdige:r Anbieter:in kompromittiert wird. + + +Es sollte ein Änderungsmanagementprozess oder ein Tracking-System vorhanden sein, um Änderungen an folgenden Bereichen zu verfolgen: + +* CI/CD-Einstellungen (alle Build-Tools und Pipelines) +* Code-Repositories +* Sandbox-Bereiche +* Entwicklungsumgebungen +* SBOM-Tooling und erstellte Artefakte +* Protokollierungssysteme und Protokolle +* Drittanbieter-Integrationen, z. B. SaaS +* Artefakt-Repositories +* Container-Registries + + +Folgende Systeme sollten abgesichert werden, einschließlich der Aktivierung von MFA und der Einschränkung von IAM: + +* Ihr Code-Repository (dazu gehört das Nicht-Einchecken von Secrets, der Schutz von Branches und Backups) +* Entwickler:innen-Workstations (regelmäßiges Patchen, MFA, Monitoring und mehr) +* Ihr Build-Server & CI/CD (Aufgabentrennung, Zugangskontrolle, signierte Builds, umgebungsspezifische Secrets, manipulationssichere Protokolle und mehr) +* Ihre Artefakte (Integrität durch Herkunftsnachweis, Signierung und Zeitstempel sicherstellen, Artefakte befördern statt für jede Umgebung neu zu bauen, sicherstellen, dass Builds unveränderlich sind) +* Infrastructure as Code (wie jeder Code verwaltet, einschließlich der Verwendung von PRs und Versionskontrolle) + +Jede Organisation muss einen fortlaufenden Plan zur Überwachung, Priorisierung und Anwendung von Updates oder Konfigurationsänderungen für die gesamte Lebensdauer der Anwendung oder des Portfolios sicherstellen. + + +## Beispielhafte Angriffsszenarien. + +**Szenario Nr. 1:** Ein vertrauenswürdiger Anbieter wird mit Malware kompromittiert, was dazu führt, dass Ihre Computersysteme beim Upgrade kompromittiert werden. Das bekannteste Beispiel hierfür ist wahrscheinlich: + + + +* Die SolarWinds-Kompromittierung von 2019, die zur Kompromittierung von ~18.000 Organisationen führte. [https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack](https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack) + +**Szenario Nr. 2:** Ein vertrauenswürdiger Anbieter wird so kompromittiert, dass er sich nur unter einer bestimmten Bedingung böswillig verhält. + + + +* Der Bybit-Diebstahl von 1,5 Milliarden US-Dollar im Jahr 2025 wurde durch [einen Supply-Chain-Angriff auf Wallet-Software](https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/) verursacht, der nur ausgeführt wurde, wenn die Ziel-Wallet verwendet wurde. + +**Szenario Nr. 3:** Der [`Shai-Hulud`-Supply-Chain-Angriff](https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem) im Jahr 2025 war der erste erfolgreiche sich selbst verbreitende npm-Wurm. Angreifer:innen platzierten bösartige Versionen populärer Pakete, die ein Post-Install-Skript verwendeten, um sensible Daten zu sammeln und in öffentliche GitHub-Repositories zu exfiltrieren. Die Malware erkannte auch npm-Token in der Opferumgebung und nutzte diese automatisch, um bösartige Versionen aller zugänglichen Pakete zu veröffentlichen. Der Wurm erreichte über 500 Paketversionen, bevor er von npm gestoppt wurde. Dieser Supply-Chain-Angriff war fortschrittlich, schnell ausbreitend und schädlich, und indem er auf Entwicklungsmaschinen abzielte, zeigte er, dass Entwickler:innen selbst nun zu den Hauptzielen von Supply-Chain-Angriffen geworden sind. + +**Szenario Nr. 4:** Komponenten laufen typischerweise mit denselben Berechtigungen wie die Anwendung selbst, sodass Fehler in einer beliebigen Komponente erhebliche Auswirkungen haben können. Solche Fehler können versehentlich (z. B. Codefehler) oder absichtlich (z. B. eine Hintertür in einer Komponente) sein. Einige Beispiele für entdeckte ausnutzbare Komponentenschwachstellen sind: + +* CVE-2017-5638, eine Struts-2-Schwachstelle zur Remote-Code-Ausführung, die die Ausführung beliebigen Codes auf dem Server ermöglicht, wurde für erhebliche Datenschutzverletzungen verantwortlich gemacht. +* CVE-2021-44228 („Log4Shell"), eine Apache-Log4j-Zero-Day-Schwachstelle zur Remote-Code-Ausführung, wurde für Ransomware-, Kryptomining- und andere Angriffskampagnen verantwortlich gemacht. + + +## Referenzen. + +* [OWASP Application Security Verification Standard: V15 Secure Coding and Architecture](https://owasp.org/www-project-application-security-verification-standard/) +* [OWASP Cheat Sheet Series: Dependency Graph SBOM](https://cheatsheetseries.owasp.org/cheatsheets/Dependency_Graph_SBOM_Cheat_Sheet.html) +* [OWASP Cheat Sheet Series: Vulnerable Dependency Management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html) +* [OWASP Dependency-Track](https://owasp.org/www-project-dependency-track/) +* [OWASP CycloneDX](https://owasp.org/www-project-cyclonedx/) +* [OWASP Application Security Verification Standard: V1 Architecture, design and threat modelling](https://owasp-aasvs.readthedocs.io/en/latest/v1.html) +* [OWASP Dependency Check (for Java and .NET libraries)](https://owasp.org/www-project-dependency-check/) +* OWASP Testing Guide - Map Application Architecture (OTG-INFO-010) +* [OWASP Virtual Patching Best Practices](https://owasp.org/www-community/Virtual_Patching_Best_Practices) +* [The Unfortunate Reality of Insecure Libraries](https://www.scribd.com/document/105692739/JeffWilliamsPreso-Sm) +* [MITRE Common Vulnerabilities and Exposures (CVE) search](https://www.cve.org) +* [National Vulnerability Database (NVD)](https://nvd.nist.gov) +* [Retire.js for detecting known vulnerable JavaScript libraries](https://retirejs.github.io/retire.js/) +* [GitHub Advisory Database](https://github.com/advisories) +* Ruby Libraries Security Advisory Database and Tools +* [SAFECode Software Integrity Controls (PDF)](https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) +* [Glassworm supply chain attack](https://thehackernews.com/2025/10/self-spreading-glassworm-infects-vs.html) +* [PhantomRaven supply chain attack campaign](https://thehackernews.com/2025/10/phantomraven-malware-found-in-126-npm.html) + + +## Liste der zugeordneten CWEs + +* [CWE-447 Use of Obsolete Function](https://cwe.mitre.org/data/definitions/447.html) + +* [CWE-1035 2017 Top 10 A9: Using Components with Known Vulnerabilities](https://cwe.mitre.org/data/definitions/1035.html) + +* [CWE-1104 Use of Unmaintained Third Party Components](https://cwe.mitre.org/data/definitions/1104.html) + +* [CWE-1329 Reliance on Component That is Not Updateable](https://cwe.mitre.org/data/definitions/1329.html) + +* [CWE-1357 Reliance on Insufficiently Trustworthy Component](https://cwe.mitre.org/data/definitions/1357.html) + +* [CWE-1395 Dependency on Vulnerable Third-Party Component](https://cwe.mitre.org/data/definitions/1395.html) diff --git a/2025/docs/de/A04_2025-Cryptographic_Failures.md b/2025/docs/de/A04_2025-Cryptographic_Failures.md new file mode 100644 index 000000000..8ada7434e --- /dev/null +++ b/2025/docs/de/A04_2025-Cryptographic_Failures.md @@ -0,0 +1,195 @@ +# A04:2025 Fehlerhafter Einsatz von Kryptografie ![icon](../assets/TOP_10_Icons_Final_Crypto_Failures.png){: style="height:80px;width:80px" align="right"} + + + +## Hintergrund. + +Diese Schwachstelle ist um zwei Plätze auf Rang 4 zurückgefallen und konzentriert sich auf Fehler im Zusammenhang mit fehlender Kryptografie, unzureichend starker Kryptografie, dem Verlust kryptografischer Schlüssel und damit verbundenen Fehlern. Drei der häufigsten Common Weakness Enumerations (CWEs) in diesem Risikobereich betrafen die Verwendung eines schwachen Pseudozufallszahlengenerators: *CWE-327 Use of a Broken or Risky Cryptographic Algorithm, CWE-331: Insufficient Entropy*, *CWE-1241: Use of Predictable Algorithm in Random Number Generator*, and *CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)*. + + + +## Punktetabelle. + + + + + + + + + + + + + + + + + + + + + + + + + +
Zugeordnete CWEs + Max. Häufigkeit + Durchschn. Häufigkeit + Max. Abdeckung + Durchschn. Abdeckung + Durchschn. gewichtete Ausnutzbarkeit + Durchschn. gewichtete Auswirkung + Gesamtanzahl + Summe CVEs +
32 + 13.77% + 3.80% + 100.00% + 47.74% + 7.23 + 3.90 + 1,665,348 + 2,185 +
+ + + +## Beschreibung. + +Generell sollten alle Daten während der Übertragung auf der Transportschicht ([OSI-Schicht](https://de.wikipedia.org/wiki/OSI-Modell) 4) verschlüsselt werden. Frühere Hindernisse wie die CPU-Leistung werden nun durch CPUs bewältigt, die über Hardwarebeschleunigung der Verschlüsselung verfügen (z. B.: [AES-Unterstützung](https://en.wikipedia.org/wiki/AES_instruction_set)), und die Verwaltung privater Schlüssel und Zertifikate wird durch Dienste wie [LetsEncrypt.org](https://LetsEncrypt.org) vereinfacht, wobei große Cloud-Anbieter noch stärker integrierte Zertifikatsverwaltungsdienste für ihre spezifischen Plattformen bereitstellen. + +Neben der Absicherung der Transportschicht ist es wichtig zu ermitteln, welche Daten im Ruhezustand verschlüsselt werden müssen und welche Daten während der Übertragung (auf der [Anwendungsschicht](https://en.wikipedia.org/wiki/Application_layer), OSI-Schicht 7) zusätzlich verschlüsselt werden müssen. Beispielsweise erfordern Passwörter, Kreditkartennummern, Gesundheitsakten, persönliche Informationen und Geschäftsgeheimnisse zusätzlichen Schutz, vor allem dann, wenn diese Daten unter Datenschutzgesetze, z. B. die Datenschutz-Grundverordnung (DSGVO) der EU, oder andere Vorschriften fallen, beispielsweise dem Payment Card Industry Data Security Standard (PCI-DSS). + +Folgendes ist zu klären: + +* Werden alte oder schwache kryptografische Algorithmen oder Protokolle verwendet, z. B. per Standardeinstellung oder in älterem Code? +* Werden vordefinierte kryptografische Schlüssel verwendet, schwache Schlüssel generiert oder Schlüssel wiederverwendet? Fehlt eine Schlüsselverwaltung oder Schlüsselrotation? +* Werden kryptografische Schlüssel in Quellcode-Repositories eingecheckt? +* Wird Verschlüsselung nicht verbindlich erzwungen, z. B. fehlen bei Webanwendungen Vorgaben für den Browser in den entsprechenden HTTP-Kopfzeilen? +* Werden empfangene Serverzertifikate und die Zertifikatskette korrekt validiert? +* Werden Initialisierungsvektoren ignoriert, wiederverwendet oder nicht ausreichend sicher für den kryptografischen Betriebsmodus generiert? Ist ein unsicherer Betriebsmodus wie ECB im Einsatz? Wird Verschlüsselung genutzt, wenn authentifizierte Verschlüsselung angebrachter wäre? +* Werden Passwörter direkt als kryptografische Schlüssel verwendet ohne eine Schlüsselableitung mittels Key Derivation Function? +* Werden Zufallszahlen für kryptografische Zwecke genutzt, die nicht auf kryptografische Anforderungen ausgelegt sind? Selbst wenn die richtige Funktion genutzt wird, muss diese eventuell von Entwickler:innen korrekt initialisiert werden. Wurde eine integrierte starke Initialisierung eventuell durch ein Entwickler:in mit einem schwachen Wert überschrieben, dem es an ausreichender Entropie und Unberechenbarkeit mangelt? +* Werden Hash-Funktionen mit bekannten Schwächen wie MD5 oder SHA1 verwendet oder werden nicht-kryptografische Hash-Funktionen verwendet, wenn kryptografische Hash-Funktionen benötigt werden? +* Sind kryptografische Fehlermeldungen oder Seitenkanäle ausnutzbar, beispielsweise in Form von Padding-Oracle-Angriffen? +* Kann der eingesetzte kryptografische Algorithmus abgeschwächt oder umgangen werden? + +Siehe ASVS: Cryptography (V11), Secure Communication (V12) and Data Protection (V14). + + +## Prävention und Gegenmaßnahmen. + +Befolgen Sie mindestens die folgenden Schritte und konsultieren Sie die weiterführenden Webseiten: + +* Klassifizieren Sie die Daten, die von einer Anwendung verarbeitet, gespeichert oder übermittelt werden +nach ihrem Schutzbedarf. Berücksichtigen Sie dabei auch Datenschutzgesetze, regulatorische und Geschäfts-Anforderungen. +* Speichern Sie Ihre am stärksten gefährdeten Schlüssel in einem Hardware- oder cloudbasierten HSM. +* Verwenden Sie nach Möglichkeit überall bewährte Implementierungen kryptografischer Algorithmen +* Speichern Sie sensible Daten nicht unnötig. Löschen Sie sensible Daten auf sichere Weise sobald wie möglich oder verwenden Sie Techniken wie PCI-DSS-konformes Speichern von Ersatzwerten (tokenization) oder gar gekürzten (truncation) Werten. +Daten, die es nicht mehr gibt, können auch nicht gestohlen werden. +* Stellen Sie sicher, dass alle vertraulichen Daten bei Speicherung verschlüsselt werden. +* Stellen Sie sicher, dass aktuelle, starke, standardisierte Algorithmen, Protokolle und Schlüssel, z. B. gemäß BSI TR-02102, verwendet werden. Etablieren Sie wirksames Schlüsselmanagement für kryptografische Schlüssel. +* Verschlüsseln Sie alle Daten während der Übertragung mit TLS >= 1.2, die Forward Secrecy (FS) bieten, deaktivieren Sie die Unterstützung von cipher block chaining (CBC) Chiffren, unterstützen Sie quantensichere Schlüsselaustauschverfahren. Erzwingen Sie die Verschlüsselung durch HTTP Strict Transport Security (HSTS). Prüfen Sie die Einstellungen mit einem Werkzeug. +* Deaktivieren Sie das Caching für Antworten mit vertraulichen Daten. Dazu gehören das Caching in Ihrem CDN, auf Ihrem Webserver sowie jegliches Anwendungs-Caching (z. B. Redis). +* Wenden Sie die Sicherheitsmaßnahmen gemäß dem Schutzbedarf der Datenklassifizierung an. +* Verwenden Sie keine unverschlüsselten Protokolle wie FTP und STARTTLS. Vermeiden Sie die Verwendung von SMTP für die Übertragung vertraulicher Daten. +* Verwenden Sie spezielle Hash-Funktionen für das Hashen von Passwörtern, bei denen für jedes Passwort ein Salz-Wert (salted hash) und Rechenaufwand (work-factor) zum Einsatz kommt. Beispiele sind: Argon2, yescrypt, scrypt, PBKDF2-HMAC-SHA-512. Für Altsysteme, die bcrypt verwenden, finden Sie weitere Hinweise unter [OWASP Cheat Sheet: Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) +* Initialisierungsvektoren müssen passend zum kryptografischen Betriebsmodus gewählt werden. In vielen Fällen bedeutet dies, dass ein CSPRNG (kryptografisch sicherer Pseudozufallszahlengenerator) für die Generierung des Initialisierungsvektors verwendet wird. Für Modi, die eine Nonce erfordern, benötigt der Initialisierungsvektor nicht notwendigerweise einen CSPRNG. In allen Fällen darf der gleiche Initialisierungsvektor niemals zweimal für den gleichen Schlüssel verwendet werden. +* Verwenden Sie immer eine authentifizierte Verschlüsselung statt nur einer Verschlüsselung. +* Schlüssel sollten kryptografisch zufällig generiert und als Byte-Felder (Arrays) im Speicher gehalten werden. Wenn ein Passwort zur Verschlüsselung verwendet werden soll, muss über eine Funktion zur Schlüsselableitung ein Schlüssel generiert werden. +* Stellen Sie sicher, dass an den notwendigen Stellen kryptografisch sichere, unvorhersagbare Zufallszahlen verwendet werden, und dass der Pseudozufallszahlengenerator nicht auf vorhersehbare Weise oder nur mit geringer Entropie initialisiert wurde. Bei den meisten modernen APIs muss die Entwickler:in die Initialisierung des Pseudozufallszahlengenerators (CSPRNG) nicht manuell durchführen. +* Meiden Sie veraltete kryptografische Funktionen und Padding-Verfahren wie MD5, SHA1, Cipher Block Chaining Mode (CBC), PKCS Nummer 1 v1.5. +* Stellen Sie sicher, dass Einstellungen und Konfigurationen den Sicherheitsanforderungen entsprechen, indem Sie sie von Sicherheitsspezialist:innen, speziell dafür entwickelte Werkzeugen oder beidem überprüfen lassen. +* Sie müssen sich bereits jetzt auf die Post-Quanten-Kryptografie (PQC) vorbereiten (siehe Referenz (ENISA)), damit risikoreiche Systeme spätestens bis Ende 2030 sicher sind. + + + + +## Beispielhafte Angriffsszenarien. + +**Szenario Nr. 1:** Eine Webseite benutzt kein TLS, erzwingt dies nicht auf allen Seiten oder lässt schwache Verschlüsselung zu. Die/Der Angreifer:in liest die Kommunikation mit (z. B. in einem offenen WLAN), ersetzt HTTPS- durch HTTP-Verbindungen, hört diese ab und stiehlt das Sitzungscookie. Durch Wiedereinspielen dieses Cookies übernimmt die/der Angreifer:in die (authentifizierte) Sitzung der Nutzer:in und erlangt Zugriff auf deren private Daten. Anstatt dessen kann die/der Angreifer:in auch die übertragenen Daten ändern, z. B. die Empfänger:in einer Überweisung. + +**Szenario Nr. 2:** Die Passwortdatenbank benutzt einfache Hashwerte oder Hashes ohne Salz zur Speicherung der Passwörter. Eine Schwachstelle in der Uploadfunktion erlaubt Angreifer:innen den Zugriff auf die Passwortdatei. Zu Hashes ohne Salz kann über vorausberechnete Rainbow-Tabellen der Klartext gefunden werden. Hashes, die über einfache oder schnelle Funktionen berechnet wurden, können effizient mit Grafikkarten gebrochen werden, selbst wenn sie gesalzt waren. + + +## Referenzen. + +* [OWASP Proactive Controls: C2: Use Cryptography to Protect Data ](https://top10proactive.owasp.org/archive/2024/the-top-10/c2-crypto/) +* [OWASP Application Security Verification Standard (ASVS): ](https://owasp.org/www-project-application-security-verification-standard) [V11,](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x20-V11-Cryptography.md) [12, ](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x21-V12-Secure-Communication.md) [14](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x23-V14-Data-Protection.md) +* [OWASP Cheat Sheet: Transport Layer Protection](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html) +* [OWASP Cheat Sheet: User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html) +* [OWASP Cheat Sheet: HSTS](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) +* [OWASP Testing Guide: Testing for weak cryptography](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/README) +* [ENISA: A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography) +* [NIST Releases First 3 Finalized Post-Quantum Encryption Standards](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards) + + +## Liste der zugeordneten CWEs + +* [CWE-261 Weak Encoding for Password](https://cwe.mitre.org/data/definitions/261.html) + +* [CWE-296 Improper Following of a Certificate's Chain of Trust](https://cwe.mitre.org/data/definitions/296.html) + +* [CWE-319 Cleartext Transmission of Sensitive Information](https://cwe.mitre.org/data/definitions/319.html) + +* [CWE-320 Key Management Errors (Prohibited)](https://cwe.mitre.org/data/definitions/320.html) + +* [CWE-321 Use of Hard-coded Cryptographic Key](https://cwe.mitre.org/data/definitions/321.html) + +* [CWE-322 Key Exchange without Entity Authentication](https://cwe.mitre.org/data/definitions/322.html) + +* [CWE-323 Reusing a Nonce, Key Pair in Encryption](https://cwe.mitre.org/data/definitions/323.html) + +* [CWE-324 Use of a Key Past its Expiration Date](https://cwe.mitre.org/data/definitions/324.html) + +* [CWE-325 Missing Required Cryptographic Step](https://cwe.mitre.org/data/definitions/325.html) + +* [CWE-326 Inadequate Encryption Strength](https://cwe.mitre.org/data/definitions/326.html) + +* [CWE-327 Use of a Broken or Risky Cryptographic Algorithm](https://cwe.mitre.org/data/definitions/327.html) + +* [CWE-328 Reversible One-Way Hash](https://cwe.mitre.org/data/definitions/328.html) + +* [CWE-329 Not Using a Random IV with CBC Mode](https://cwe.mitre.org/data/definitions/329.html) + +* [CWE-330 Use of Insufficiently Random Values](https://cwe.mitre.org/data/definitions/330.html) + +* [CWE-331 Insufficient Entropy](https://cwe.mitre.org/data/definitions/331.html) + +* [CWE-332 Insufficient Entropy in PRNG](https://cwe.mitre.org/data/definitions/332.html) + +* [CWE-334 Small Space of Random Values](https://cwe.mitre.org/data/definitions/334.html) + +* [CWE-335 Incorrect Usage of Seeds in Pseudo-Random Number Generator(PRNG)](https://cwe.mitre.org/data/definitions/335.html) + +* [CWE-336 Same Seed in Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/336.html) + +* [CWE-337 Predictable Seed in Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/337.html) + +* [CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator(PRNG)](https://cwe.mitre.org/data/definitions/338.html) + +* [CWE-340 Generation of Predictable Numbers or Identifiers](https://cwe.mitre.org/data/definitions/340.html) + +* [CWE-342 Predictable Exact Value from Previous Values](https://cwe.mitre.org/data/definitions/342.html) + +* [CWE-347 Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html) + +* [CWE-523 Unprotected Transport of Credentials](https://cwe.mitre.org/data/definitions/523.html) + +* [CWE-757 Selection of Less-Secure Algorithm During Negotiation('Algorithm Downgrade')](https://cwe.mitre.org/data/definitions/757.html) + +* [CWE-759 Use of a One-Way Hash without a Salt](https://cwe.mitre.org/data/definitions/759.html) + +* [CWE-760 Use of a One-Way Hash with a Predictable Salt](https://cwe.mitre.org/data/definitions/760.html) + +* [CWE-780 Use of RSA Algorithm without OAEP](https://cwe.mitre.org/data/definitions/780.html) + +* [CWE-916 Use of Password Hash With Insufficient Computational Effort](https://cwe.mitre.org/data/definitions/916.html) + +* [CWE-1240 Use of a Cryptographic Primitive with a Risky Implementation](https://cwe.mitre.org/data/definitions/1240.html) + +* [CWE-1241 Use of Predictable Algorithm in Random Number Generator](https://cwe.mitre.org/data/definitions/1241.html) diff --git a/2025/docs/de/A05_2025-Injection.md b/2025/docs/de/A05_2025-Injection.md new file mode 100644 index 000000000..b68730b81 --- /dev/null +++ b/2025/docs/de/A05_2025-Injection.md @@ -0,0 +1,210 @@ +# A05:2025 Injection ![icon](../assets/TOP_10_Icons_Final_Injection.png){: style="height:80px;width:80px" align="right"} + +## Hintergrund. + +„Injection“ fällt im Ranking um zwei Plätze von Platz 3 auf Platz 5 zurück, behält jedoch seine Position im Vergleich zu „A04:2025 – Fehlerhafter Einsatz von Kryptographie“ und „A06:2025 – Unsicheres Anwendungsdesign“ bei. „Injection“ ist eine der am häufigsten getesteten Kategorien, wobei 100 % der Anwendungen auf irgendeine Form von Injection geprüft wurden. Mit 37 CVEs wies diese Kategorie die höchste Anzahl an CVEs aller Kategorien auf. Injection umfasst Cross-Site-Scripting (hohe Häufigkeit/geringe Auswirkung) mit mehr als 30.000 CVEs und SQL-Injection (geringe Häufigkeit/hohe Auswirkung) mit mehr als 14.000 CVEs. Die enorme Anzahl gemeldeter CVEs für CWE-79 „Improper Neutralization of Input During Web Page Generation“ („Cross-Site-Scripting“) senkt die gewichtete durchschnittliche Auswirkung dieser Kategorie. + + +## Punktetabelle. + + + + + + + + + + + + + + + + + + + + + + + + + +
Zugeordnete CWEs + Max. Häufigkeit + Durchschn. Häufigkeit + Max. Abdeckung + Durchschn. Abdeckung + Durchschn. gewichtete Ausnutzbarkeit + Durchschn. gewichtete Auswirkung + Gesamtanzahl + Summe CVEs +
37 + 13.77% + 3.08% + 100.00% + 42.93% + 7.15 + 4.32 + 1,404,249 + 62,445 +
+ + + +## Beschreibung. + +Eine Injection-Schwachstelle ist ein Anwendungsfehler, der es ermöglicht, dass nicht vertrauenswürdige Benutzereingaben an einen Interpreter (z. B. einen Browser, eine Datenbank oder die Befehlszeile) gesendet werden und dazu führt, dass der Interpreter Teile dieser Eingaben als Befehle ausführt. + +Eine Anwendung ist für diesen Angriff anfällig, wenn: + +* Daten, die von Nutzer:innen stammen, von der Anwendung nicht ausreichend validiert, gefiltert oder bereinigt werden. +* Dynamische Anfragen oder nicht-parametrisierte Aufrufe ohne ein dem Kontext entsprechendes Escaping direkt einem Interpreter übergeben werden. +* Unbereinigte Daten innerhalb von ORM („Object-Relational Mapping“)-Suchparametern genutzt werden können, um zusätzliche, sensible Datensätze zu extrahieren. +* Potenziell bösartige Daten direkt oder als Teil zusammengesetzter, dynamischer Abfragen verwendet werden. Die SQL-Abfragen oder Befehle beinhalten die schädlichen Daten in dynamischen Abfragen, Befehlen oder gespeicherten Prozeduren (Stored Procedures). + +Zu den häufigeren Injection Arten gehören SQL, NoSQL, OS-Befehle, Object Relational Mapping (ORM), LDAP und Expression Language (EL) oder Object Graph Navigation Library (OGNL). Das Grundkonzept eines Injection-Angriffs ist für alle Interpreter gleich. Die Erkennung lässt sich am besten durch eine Kombination aus Code-Review und automatisierten Tests (einschließlich Fuzzing) aller Parameter, Kopfzeilen, URLs, Cookies sowie JSON-, SOAP- und XML-Eingabedaten erreichen. Statische (SAST, Quellcode-Ebene), dynamische (DAST, laufende Anwendung) und interaktive (IAST, Mischform aus statisch und dynamisch) Test-Werkzeuge können von Organisationen für ihre CI/CD-Pipeline genutzt werden, um neue Schwachstellen noch vor einer möglichen Auslieferung in Produktivsysteme zu identifizieren. + +Eine verwandte Klasse von Injektionsschwachstellen ist bei LLMs mittlerweile weit verbreitet. Diese werden separat in den [OWASP LLM Top 10](https://genai.owasp.org/llm-top-10/) behandelt, insbesondere unter [LLM01:2025 Prompt-Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/). + + +## Prävention und Gegenmaßnahmen. + +Eine konsequente Trennung von Daten, Suchanfragen und Befehlen ist für die Vermeidung von Injection-Angriffen unerlässlich: + +* Die bevorzugte Methode ist die Verwendung einer sicheren API, die die Verwendung des Interpreters vollständig vermeidet, eine parametrisierte Schnittstelle bereitstellt oder in objektrelationale Mapping-Tools (ORMs) umwandelt. +**Anmerkung:** Gespeicherte Prozeduren können - auch parametrisiert - immer noch SQL-Injections ermöglichen, wenn PL/SQL oder T-SQL Anfragen und Eingabedaten konkateniert oder mit EXECUTE IMMEDIATE oder exec() ausgeführt werden. + +Wenn es nicht möglich ist, die Daten von den Befehlen zu trennen, können Sie die Risiken mithilfe der folgenden Techniken verringern: + +* Nutzen Sie eine serverseitige Eingabe-Validierung mit Allow-List. Dies ist kein vollständiger Schutz, da viele Anwendungen Sonderzeichen z. B. in Textfeldern oder APIs für mobile Anwendungen benötigen. + +* Für jede noch verbliebene dynamische Abfrage müssen Sonderzeichen für den jeweiligen Interpreter mit der richtigen Escape-Syntax entschärft werden. +**Anmerkung:** Ein Escaping von SQL-Bezeichnern, wie z. B. die Namen von Tabellen oder Spalten usw. ist nicht möglich. Falls Nutzer:innen solche Bezeichner selbst eingeben können, so ist dies durchaus gefährlich. Dies ist eine übliche Schwachstelle bei Software, die Reports aus einer Datenbank erstellt. + +**Warnung**: Diese Techniken beinhalten das Parsen und Escapen komplexer Zeichenfolgen, wodurch sie bei geringfügigen Änderungen am System fehleranfällig und nicht robust sind. + +## Beispielhafte Angriffsszenarien. + +**Szenario Nr. 1:** Eine Anwendung nutzt ungeprüfte Eingabedaten für den Zusammenbau der folgenden verwundbaren SQL-Abfrage: + +``` +String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; +``` + +Angreifer:innen manipulieren den Wert des id-Parameters im Browser und senden `' OR '1'='1`. z. B.: + +``` +http://example.com/app/accountView?id=' OR '1'='1 +``` + +Dadurch wird die Abfrage so geändert, dass alle Datensätze aus der Tabelle „accounts“ zurückgegeben werden. Gefährlichere Angriffe könnten Daten verändern oder löschen oder sogar gespeicherte Prozeduren aufrufen. + +**Szenario Nr. 2:** Auch das blinde Vertrauen in Frameworks kann zu Abfragen führen, die ganz analog zu obigem Beispiel verwundbar sind (z. B. Hibernate Query Language (HQL)): + +``` +Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'"); +``` + +Angreifer:innen geben Folgendes ein: `' OR custID IS NOT NULL OR custID='`. Dadurch wird der Filter umgangen und es werden alle Accounts zurückgegeben. Obwohl HQL weniger gefährliche Funktionen enthält als reines SQL, ermöglicht es dennoch unbefugten Datenzugriff, wenn Benutzereingaben in Abfragen eingebunden werden. + +**Szenario Nr. 3:** Eine Anwendung gibt Benutzereingaben direkt an einen Betriebssystembefehl weiter: + +``` +String cmd = "nslookup " + request.getParameter("domain"); +Runtime.getRuntime().exec(cmd); +``` + +Angreifer:innen übergeben `example.com; cat /etc/passwd`, um beliebige Befehle auf dem Server auszuführen. + +## Referenzen. + +* [OWASP Proactive Controls: Secure Database Access](https://owasp.org/www-project-proactive-controls/v3/en/c3-secure-database) +* [OWASP ASVS: V5 Input Validation and Encoding](https://owasp.org/www-project-application-security-verification-standard) +* [OWASP Testing Guide: SQL Injection,](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection) [Command Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Command_Injection), and [ORM Injection](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.7-Testing_for_ORM_Injection) +* [OWASP Cheat Sheet: Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html) +* [OWASP Cheat Sheet: SQL Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Injection Prevention in Java](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet_in_Java.html) +* [OWASP Cheat Sheet: Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) +* [OWASP Automated Threats to Web Applications – OAT-014](https://owasp.org/www-project-automated-threats-to-web-applications/) +* [PortSwigger: Server-side template injection](https://portswigger.net/kb/issues/00101080_serversidetemplateinjection) +* [Awesome Fuzzing: a list of fuzzing resources](https://github.com/secfigo/Awesome-Fuzzing) + + + +## Liste der zugeordneten CWEs + +* [CWE-20 Improper Input Validation](https://cwe.mitre.org/data/definitions/20.html) + +* [CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')](https://cwe.mitre.org/data/definitions/74.html) + +* [CWE-76 Improper Neutralization of Equivalent Special Elements](https://cwe.mitre.org/data/definitions/76.html) + +* [CWE-77 Improper Neutralization of Special Elements used in a Command ('Command Injection')](https://cwe.mitre.org/data/definitions/77.html) + +* [CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')](https://cwe.mitre.org/data/definitions/78.html) + +* [CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')](https://cwe.mitre.org/data/definitions/79.html) + +* [CWE-80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)](https://cwe.mitre.org/data/definitions/80.html) + +* [CWE-83 Improper Neutralization of Script in Attributes in a Web Page](https://cwe.mitre.org/data/definitions/83.html) + +* [CWE-86 Improper Neutralization of Invalid Characters in Identifiers in Web Pages](https://cwe.mitre.org/data/definitions/86.html) + +* [CWE-88 Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')](https://cwe.mitre.org/data/definitions/88.html) + +* [CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')](https://cwe.mitre.org/data/definitions/89.html) + +* [CWE-90 Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')](https://cwe.mitre.org/data/definitions/90.html) + +* [CWE-91 XML Injection (aka Blind XPath Injection)](https://cwe.mitre.org/data/definitions/91.html) + +* [CWE-93 Improper Neutralization of CRLF Sequences ('CRLF Injection')](https://cwe.mitre.org/data/definitions/93.html) + +* [CWE-94 Improper Control of Generation of Code ('Code Injection')](https://cwe.mitre.org/data/definitions/94.html) + +* [CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')](https://cwe.mitre.org/data/definitions/95.html) + +* [CWE-96 Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')](https://cwe.mitre.org/data/definitions/96.html) + +* [CWE-97 Improper Neutralization of Server-Side Includes (SSI) Within a Web Page](https://cwe.mitre.org/data/definitions/97.html) + +* [CWE-98 Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')](https://cwe.mitre.org/data/definitions/98.html) + +* [CWE-99 Improper Control of Resource Identifiers ('Resource Injection')](https://cwe.mitre.org/data/definitions/99.html) + +* [CWE-103 Struts: Incomplete validate() Method Definition](https://cwe.mitre.org/data/definitions/103.html) + +* [CWE-104 Struts: Form Bean Does Not Extend Validation Class](https://cwe.mitre.org/data/definitions/104.html) + +* [CWE-112 Missing XML Validation](https://cwe.mitre.org/data/definitions/112.html) + +* [CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')](https://cwe.mitre.org/data/definitions/113.html) + +* [CWE-114 Process Control](https://cwe.mitre.org/data/definitions/114.html) + +* [CWE-115 Misinterpretation of Output](https://cwe.mitre.org/data/definitions/115.html) + +* [CWE-116 Improper Encoding or Escaping of Output](https://cwe.mitre.org/data/definitions/116.html) + +* [CWE-129 Improper Validation of Array Index](https://cwe.mitre.org/data/definitions/129.html) + +* [CWE-159 Improper Handling of Invalid Use of Special Elements](https://cwe.mitre.org/data/definitions/159.html) + +* [CWE-470 Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')](https://cwe.mitre.org/data/definitions/470.html) + +* [CWE-493 Critical Public Variable Without Final Modifier](https://cwe.mitre.org/data/definitions/493.html) + +* [CWE-500 Public Static Field Not Marked Final](https://cwe.mitre.org/data/definitions/500.html) + +* [CWE-564 SQL Injection: Hibernate](https://cwe.mitre.org/data/definitions/564.html) + +* [CWE-610 Externally Controlled Reference to a Resource in Another Sphere](https://cwe.mitre.org/data/definitions/610.html) + +* [CWE-643 Improper Neutralization of Data within XPath Expressions ('XPath Injection')](https://cwe.mitre.org/data/definitions/643.html) + +* [CWE-644 Improper Neutralization of HTTP Headers for Scripting Syntax](https://cwe.mitre.org/data/definitions/644.html) + +* [CWE-917 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')](https://cwe.mitre.org/data/definitions/917.html) diff --git a/2025/docs/de/A06_2025-Insecure_Design.md b/2025/docs/de/A06_2025-Insecure_Design.md new file mode 100644 index 000000000..7d54877e8 --- /dev/null +++ b/2025/docs/de/A06_2025-Insecure_Design.md @@ -0,0 +1,189 @@ +# A06:2025 Unsicheres Design ![icon](../assets/TOP_10_Icons_Final_Insecure_Design.png){: style=”height:80px;width:80px” align=”right”} + + +## Hintergrund. + +Unsicheres Design rutscht zwei Plätze von #4 auf #6 im Ranking ab, da **[A02:2025-Sicherheitsrelevante Fehlkonfiguration](A02_2025-Security_Misconfiguration.md)** und **[A03:2025-Schwachstellen in der Software-Lieferkette](A03_2025-Software_Supply_Chain_Failures.md)** es überholt haben. Diese Kategorie wurde 2021 eingeführt, und wir haben beachtliche Verbesserungen in der Branche im Zusammenhang mit Bedrohungsmodellierung und einer stärkeren Gewichtung auf sicheres Design beobachtet. Diese Kategorie konzentriert sich auf Risiken im Zusammenhang mit Design- und Architekturfehlern, mit einem Aufruf zu häufigerem Gebrauch von Bedrohungsmodellierung, sicheren Designmustern und Referenzarchitekturen. Dies umfasst Fehler in der Geschäftslogik einer Anwendung, z. B. das Fehlen der Definition unerwünschter oder unerwarteter Zustandsänderungen innerhalb einer Anwendung. Als Community müssen wir über “Shift-Left” im Coding-Bereich hinausgehen und uns auf Aktivitäten vor dem Coding konzentrieren, wie das Verfassen von Anforderungen und das Anwendungsdesign, die für die Prinzipien von Secure by Design entscheidend sind (siehe z. B. **[Aufbau eines modernen Programms zur Anwendungssicherheit](0x03_2025-Establishing_a_Modern_Application_Security_Program.md)**) + + +## Punktetabelle. + + + + +    +    +    +    +    +    +    +    +    + + + + + + + + + + + + +
Zugeordnete CWEs +   Max. Häufigkeit +   Durchschn. Häufigkeit +   Max. Abdeckung +   Durchschn. Abdeckung +   Durchschn. gewichtete Ausnutzbarkeit +   Durchschn. gewichtete Auswirkung +   Gesamtanzahl +   Summe CVEs +   
39 + 22.18% + 1.86% + 88.76% + 35.18% + 6.96 + 4.05 + 729,882 + 7,647 +
+ + + +## Beschreibung. + +Unsicheres Design ist eine umfassende Kategorie, die verschiedene Schwachstellen umfasst und als „fehlendes oder ineffektives Design von Schutzmechanismen” beschrieben wird. Unsicheres Anwendungsdesign ist nicht die Ursache für alle anderen Top-10-Risikokategorien. Es gilt zu beachten, dass es einen Unterschied zwischen unsicherem Design und unsicherer Implementierung gibt. Designfehler und Implementierungsfehler unterscheiden sich aus gutem Grund, da sie unterschiedliche Ursachen haben, zu unterschiedlichen Zeitpunkten im Entwicklungsprozess stattfinden und unterschiedliche Abhilfemaßnahmen erfordern. Ein sicheres Design kann immer noch Implementierungsfehler enthalten, die zu ausnutzbaren Schwachstellen führen. Ein unsicheres Design lässt sich nicht durch eine perfekte Implementierung beheben, da die notwendigen Sicherheitskontrollen von vornherein nicht zur Abwehr bestimmter Angriffe vorgesehen waren. Ein Faktor, der zu einem unsicheren Design beiträgt, ist das Fehlen eines Geschäftsrisikoprofils, das der entwickelten Software oder dem System zugrunde liegt, was dazu führt, dass das erforderliche Maß an Sicherheitsdesign nicht bestimmt wird. + + +### Anforderungs- und Ressourcenmanagement + +Legen Sie zusammen mit den Geschäftseinheiten die fachlichen Anforderungen an die Anwendung fest, einschließlich des Schutzbedarfs hinsichtlich Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität aller Datenbestände, sowie die vorgesehene Geschäftslogik. Berücksichtigen Sie, wie exponiert Ihre Anwendung sein wird und ob sie eine Mandantentrennung benötigt (zusätzlich zu der, die für die Zugriffskontrolle notwendig ist). Stellen Sie die technischen Anforderungen zusammen, einschließlich funktionaler und nicht funktionaler Sicherheitsanforderungen. Planen Sie das Budget für alle Design-, Entwicklungs-, Test- und Betriebsaktivitäten, unter Berücksichtigung der Sicherheit. + + +### Sicheres Design + +Sicheres Design ist sowohl eine Denkweise als auch eine Vorgehensweise, die kontinuierlich Bedrohungen analysiert und sicherstellt, dass der Code robust entwickelt und getestet wird, um bekannte Angriffsmethoden zu verhindern. Die Bedrohungsmodellierung sollte in Backlog Refinement Terminen oder vergleichbaren Aktivitäten integriert werden. Dabei sollten Änderungen im Datenfluss, in der Zugriffskontrolle und anderen Sicherheitsmaßnahmen überprüft werden. Bestimmen Sie in der Story-Entwicklung den korrekten Ablauf und die Fehlerzustände, stellen Sie sicher, dass diese von den verantwortlichen und betroffenen Parteien gut verstanden und vereinbart werden. Analysieren Sie Annahmen und Bedingungen für erwartete sowie fehlgeschlagene Prozesse, um sicherzustellen, dass diese angemessen und die erwünschten sind. Bestimmen Sie, wie Annahmen überprüft und Bedingungen erzwungen werden können, die für das korrekte Verhalten erforderlich sind. Stellen Sie sicher, dass die Ergebnisse in der Story dokumentiert sind. Lernen Sie aus Fehlern und bieten Sie positive Anreize, um kontinuierliche Verbesserungen voranzutreiben. Sicheres Design ist weder ein Add-on noch ein Werkzeug, das Sie einer Anwendung hinzufügen können. + + +### Sicherer Entwicklungslebenszyklus + +Sichere Software erfordert einen sicheren Entwicklungslebenszyklus, ein sicheres Designmuster, eine Paved-Road-Methodik, eine sichere Komponentenbibliothek, geeignete Werkzeuge, Bedrohungsmodellierung und Incident-Post-Mortems, die zur Verbesserung des Prozesses genutzt werden. Kontaktieren Sie Ihre Sicherheitsspezialist:innen zu Beginn eines Softwareprojekts, während des gesamten Projekts und für die laufende Softwarewartung. Erwägen Sie die Nutzung des [OWASP Software Assurance Maturity Model (SAMM)](https://owaspsamm.org/), um Ihre Bemühungen zur sicheren Softwareentwicklung zu strukturieren. + +Oft wird die Eigenverantwortung von Entwickler:innen nicht ausreichend gewürdigt. Fördern Sie eine Kultur des Bewusstseins, der Verantwortung und der proaktiven Risikominderung. Regelmäßiger Austausch über Sicherheit (z. B. während Bedrohungsmodellierungs-Sitzungen) kann eine Denkweise erzeugen, die Sicherheit in alle wichtigen Designentscheidungen einbezieht. + + +## Prävention und Gegenmaßnahmen. + +* Entwickeln und nutzen Sie einen sicheren Entwicklungslebenszyklus mit Unterstützung durch AppSec-Expert:innen bei der Bewertung und Gestaltung von Sicherheits- und Datenschutzkontrollen. +* Erstellen und verwenden Sie eine Bibliothek mit sicheren Entwurfsmustern und bewährten, erprobten Komponenten. +* Verwenden Sie Bedrohungsmodellierung für kritische Bereiche wie Authentifizierung, Zugriffskontrolle, Geschäftslogik und wichtige Abläufe. +* Verwenden Sie Bedrohungsmodellierung als Schulungswerkzeug, um ein Sicherheitsbewusstsein zu schaffen +* Integrieren Sie Sicherheitsvorgaben und -kontrollen in den User Stories. +* Implementieren Sie Plausibilitätsprüfungen auf allen Ebenen Ihrer Anwendung, vom Frontend bis zum Backend. +* Schreiben Sie Unit- und Integrationstests, um zu validieren, dass alle kritischen Abläufe resistent gegen das Bedrohungsmodell sind. Stellen Sie Anwendungs- und Missbrauchsfälle für jede Ebene Ihrer Anwendung zusammen. +* Trennen Sie die Ebenen basierend auf Gefährdungs- und Schutzbedarf auf System- und Netzwerkebene. +* Stellen Sie sicher, dass die Trennung der Mandanten konsequent auf allen Ebenen erfolgt. + + +## Beispielhafte Angriffsszenarien. + +**Szenario Nr. 1:** Ein Workflow zur Wiederherstellung von Zugangsdaten kann „Fragen und Antworten” enthalten, was jedoch gemäß NIST 800-63b, dem OWASP ASVS und den OWASP Top 10 nicht zulässig ist. Fragen und Antworten können nicht als vertrauenswürdiger Identitätsnachweis betrachtet werden, als mehr als eine Person die Antworten kennen kann. Diese Funktionalität sollte entfernt und durch ein sichereres Design ersetzt werden. + +**Szenario Nr. 2:** Eine Kinokette bietet Gruppenbuchungsrabatte an und verlangt erst bei mehr als fünfzehn Besucher:innen eine Anzahlung. Angreifer:innen könnten dieses System ausnutzen und testen, ob sie einen Angriffsvektor in der Geschäftslogik der Anwendung finden könne, z. B. indem sie versuchen, mit wenigen Anfragen sechshundert Sitzplätze in allen Kinos gleichzeitig zu reservieren, was zu erheblichen Einnahmeverlusten führen könnte. + +**Szenario Nr. 3:** Die E-Commerce-Website einer Einzelhandelskette ist nicht vor Bots geschützt, die von Scalpern betrieben werden, die High-End-Grafikkarten kaufen, um sie auf Auktionsplattformen weiterzuverkaufen. Dies sorgt für schreckliche Publicity bei den Grafikkartenherstellern und Besitzer:innen von Einzelhandelsketten und sorgt für anhaltende Frustration bei Enthusiast:innen, die diese Karten nicht erwerben können. Sorgfältiges Anti-Bot-Design sowie Automatismen, die z. B. Käufe ablehnen, die innerhalb weniger Sekunden nach Verfügbarkeit getätigt werden, können helfen, unechte Käufe zu identifizieren und solche Transaktionen zu verhindern. + + +## Referenzen. + +* [OWASP Cheat Sheet: Secure Design Principles](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html) +* [OWASP SAMM: Design | Secure Architecture](https://owaspsamm.org/model/design/secure-architecture/) +* [OWASP SAMM: Design | Threat Assessment](https://owaspsamm.org/model/design/threat-assessment/) +* [NIST – Guidelines on Minimum Standards for Developer Verification of Software](https://www.nist.gov/publications/guidelines-minimum-standards-developer-verification-software) +* [The Threat Modeling Manifesto](https://threatmodelingmanifesto.org/) +* [Awesome Threat Modeling](https://github.com/hysnsec/awesome-threat-modelling) + + +## Liste der zugeordneten CWEs + +* [CWE-73 External Control of File Name or Path](https://cwe.mitre.org/data/definitions/73.html) + +* [CWE-183 Permissive List of Allowed Inputs](https://cwe.mitre.org/data/definitions/183.html) + +* [CWE-256 Unprotected Storage of Credentials](https://cwe.mitre.org/data/definitions/256.html) + +* [CWE-266 Incorrect Privilege Assignment](https://cwe.mitre.org/data/definitions/266.html) + +* [CWE-269 Improper Privilege Management](https://cwe.mitre.org/data/definitions/269.html) + +* [CWE-286 Incorrect User Management](https://cwe.mitre.org/data/definitions/286.html) + +* [CWE-311 Missing Encryption of Sensitive Data](https://cwe.mitre.org/data/definitions/311.html) + +* [CWE-312 Cleartext Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/312.html) + +* [CWE-313 Cleartext Storage in a File or on Disk](https://cwe.mitre.org/data/definitions/313.html) + +* [CWE-316 Cleartext Storage of Sensitive Information in Memory](https://cwe.mitre.org/data/definitions/316.html) + +* [CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’)](https://cwe.mitre.org/data/definitions/362.html) + +* [CWE-382 J2EE Bad Practices: Use of System.exit()](https://cwe.mitre.org/data/definitions/382.html) + +* [CWE-419 Unprotected Primary Channel](https://cwe.mitre.org/data/definitions/419.html) + +* [CWE-434 Unrestricted Upload of File with Dangerous Type](https://cwe.mitre.org/data/definitions/434.html) + +* [CWE-436 Interpretation Conflict](https://cwe.mitre.org/data/definitions/436.html) + +* [CWE-444 Inconsistent Interpretation of HTTP Requests (‘HTTP Request Smuggling’)](https://cwe.mitre.org/data/definitions/444.html) + +* [CWE-451 User Interface (UI) Misrepresentation of Critical Information](https://cwe.mitre.org/data/definitions/451.html) + +* [CWE-454 External Initialization of Trusted Variables or Data Stores](https://cwe.mitre.org/data/definitions/454.html) + +* [CWE-472 External Control of Assumed-Immutable Web Parameter](https://cwe.mitre.org/data/definitions/472.html) + +* [CWE-501 Trust Boundary Violation](https://cwe.mitre.org/data/definitions/501.html) + +* [CWE-522 Insufficiently Protected Credentials](https://cwe.mitre.org/data/definitions/522.html) + +* [CWE-525 Use of Web Browser Cache Containing Sensitive Information](https://cwe.mitre.org/data/definitions/525.html) + +* [CWE-539 Use of Persistent Cookies Containing Sensitive Information](https://cwe.mitre.org/data/definitions/539.html) + +* [CWE-598 Use of GET Request Method With Sensitive Query Strings](https://cwe.mitre.org/data/definitions/598.html) + +* [CWE-602 Client-Side Enforcement of Server-Side Security](https://cwe.mitre.org/data/definitions/602.html) + +* [CWE-628 Function Call with Incorrectly Specified Arguments](https://cwe.mitre.org/data/definitions/628.html) + +* [CWE-642 External Control of Critical State Data](https://cwe.mitre.org/data/definitions/642.html) + +* [CWE-646 Reliance on File Name or Extension of Externally-Supplied File](https://cwe.mitre.org/data/definitions/646.html) + +* [CWE-653 Insufficient Compartmentalization](https://cwe.mitre.org/data/definitions/653.html) + +* [CWE-656 Reliance on Security Through Obscurity](https://cwe.mitre.org/data/definitions/656.html) + +* [CWE-657 Violation of Secure Design Principles](https://cwe.mitre.org/data/definitions/657.html) + +* [CWE-676 Use of Potentially Dangerous Function](https://cwe.mitre.org/data/definitions/676.html) + +* [CWE-693 Protection Mechanism Failure](https://cwe.mitre.org/data/definitions/693.html) + +* [CWE-799 Improper Control of Interaction Frequency](https://cwe.mitre.org/data/definitions/799.html) + +* [CWE-807 Reliance on Untrusted Inputs in a Security Decision](https://cwe.mitre.org/data/definitions/807.html) + +* [CWE-841 Improper Enforcement of Behavioral Workflow](https://cwe.mitre.org/data/definitions/841.html) + +* [CWE-1021 Improper Restriction of Rendered UI Layers or Frames](https://cwe.mitre.org/data/definitions/1021.html) + +* [CWE-1022 Use of Web Link to Untrusted Target with window.opener Access](https://cwe.mitre.org/data/definitions/1022.html) + +* [CWE-1125 Excessive Attack Surface](https://cwe.mitre.org/data/definitions/1125.html) diff --git a/2025/docs/de/A07_2025-Authentication_Failures.md b/2025/docs/de/A07_2025-Authentication_Failures.md new file mode 100644 index 000000000..0bf269995 --- /dev/null +++ b/2025/docs/de/A07_2025-Authentication_Failures.md @@ -0,0 +1,199 @@ +# A07:2025 – Fehlerhafte Authentifizierung ![icon](../assets/TOP_10_Icons_Final_Identification_and_Authentication_Failures.png){: style="height:80px;width:80px" align="right"} + + +## Hintergrund. + +Fehlerhafte Authentifizierung behält mit einer leichten Namensänderung seinen Rang #7 bei, um die 36 CWEs dieser Kategorie präziser widerzuspiegeln. Trotz der Vorteile standardisierter Frameworks hat diese Kategorie ihren Rang #7 aus 2021 gehalten. Zu den relevanten CWEs zählen *CWE-259: Use of Hard-coded Password*, *CWE-297: Improper Validation of Certificate with Host Mismatch*, *CWE-287: Improper Authentication*, *CWE-384: Session Fixation* sowie *CWE-798: Use of Hard-coded Credentials*. + + +## Punktetabelle. + + + + + + + + + + + + + + + + + + + + + + + + + +
Zugeordnete CWEs + Max. Häufigkeit + Durchschn. Häufigkeit + Max. Abdeckung + Durchschn. Abdeckung + Durchschn. gewichtete Ausnutzbarkeit + Durchschn. gewichtete Auswirkung + Gesamtanzahl + Summe CVEs +
36 + 15.80% + 2.92% + 100.00% + 37.14% + 7.69 + 4.44 + 1,120,673 + 7,147 +
+ + + +## Beschreibung. + +Wenn ein:e Angreifer:in ein System dazu bringen kann, eine:n ungültige:n oder nicht autorisierte:n Nutzer:in als legitim anzuerkennen, liegt diese Schwachstelle vor. Schwachstellen bei der Authentifizierung können auftreten, falls die Anwendung: + +* automatisierte Angriffe wie Credential Stuffing ermöglicht, bei denen Angreifer:innen über eine Liste bekannter Benutzernamen und Passwörter verfügen. Jüngst wurde diese Angriffsmethode um hybride Passwort-Angriffe erweitert (auch als Password-Spray-Angriffe bekannt), bei denen Angreifer:innen Variationen kompromittierter Zugangsdaten verwenden, z. B. Password1!, Password2!, Password3! usw. + +* Brute-Force- oder andere automatisierte, skriptbasierte Angriffe ermöglicht, die nicht schnell genug unterbunden werden. + +* Standard-, schwache oder gängige Passwörter zulässt, wie z. B. „Password1" oder „admin/admin". + +* die Erstellung neuer Konten mit bereits als kompromittiert bekannten Zugangsdaten zulässt. + +* schwache oder ineffektive Verfahren zur Wiederherstellung von Zugangsdaten und Verfahren für vergessene Passwörter, wie z. B. „wissensbasierte Antworten", die nicht sicher gestaltet werden können. + +* Klartext-, verschlüsselte oder schwach gehashte Kennwortdatenspeicher (siehe [A04:2025 – Fehlerhafter Einsatz von Kryptographie](https://owasp.org/Top10/2025/A04_2025-Cryptographic_Failures/)) verwendet. + +* fehlende oder unwirksame Multi-Faktor-Authentifizierung aufweist. + +* schwache oder ineffektive Ausweichmechanismen zulässt, falls keine Multi-Faktor-Authentifizierung verfügbar ist. + +* die Sitzungs-ID in der URL, einem versteckten Feld oder einer anderen unsicheren, für den Client zugänglichen Stelle offenlegt. + +* dieselbe Sitzungs-ID nach erfolgreichem Login wiederverwendet. + +* Benutzersitzungen oder Authentifizierungs-Tokens (hauptsächlich SSO-Tokens) beim Abmelden oder bei Inaktivität nicht korrekt invalidiert. + +* den Scope und die vorgesehene Audience der bereitgestellten Zugangsdaten nicht korrekt prüft. + +## Prävention und Gegenmaßnahmen. + +* Wenn möglich, sollte eine Multi-Faktor-Authentifizierung implementiert und deren Nutzung durchgesetzt werden, um automatisiertes Credential Stuffing, Brute-Force-Angriffe und die Wiederverwendung gestohlener Zugangsdaten zu verhindern. + +* Wenn möglich, die Nutzung von Passwort-Managern fördern und ermöglichen, um Nutzer:innen bessere Entscheidungen bei der Passwortwahl zu erleichtern. + +* Liefern Sie die Anwendung nicht mit Standard Login-Daten aus, insbesondere nicht für Admin-Konten. + +* Implementieren Sie Prüfungen auf schwache Passwörter, wie z. B. durch den Vergleich von neuen oder geänderten Passwörtern mit der Liste der 10.000 schlechtesten Passwörter. + +* Bei der Erstellung neuer Konten und Passwortänderungen Zugangsdaten gegen Listen bekannter kompromittierter Passwörter prüfen (z. B. mit [haveibeenpwned.com](https://haveibeenpwned.com)). + +* Angleichung der Passwortlänge, -komplexität und -rotation an die Richtlinien des National Institute of Standards and Technology (NIST) 800-63b in [Abschnitt 5.1.1 „Memorized Secrets"](https://pages.nist.gov/800-63-3/sp800-63b.html#:~:text=5.1.1%20Memorized%20Secrets) oder andere moderne, bewährte Passwortrichtlinien. + +* Passwortrotation nicht erzwingen, es sei denn, es besteht ein Verdacht auf eine Kompromittierung. Bei Verdacht sofortige Passwort-Resets durchsetzen. + +* Sicherstellen, dass die Registrierung, die Wiederherstellung von Zugangsdaten und die API-Pfade gegen Angriffe zur Ermittlung von Konten gehärtet sind, indem für alle Resultate die gleiche Nachricht ausgegeben wird („Ungültiger Benutzername oder Passwort.”). + +* Begrenzen oder bremsen Sie fehlgeschlagene Anmeldeversuche immer weiter aus, aber achten Sie darauf, dass hierbei kein Denial-of-Service-Szenario entsteht. Loggen Sie alle Fehlversuche und alarmieren Sie die Administrator:innen, wenn Credential Stuffing, Brute Force oder andere Angriffe erkannt oder vermutet werden. + +* Verwenden Sie einen serverseitigen, sicheren, integrierten Sitzungsmanager, der für jede Sitzung eine neue zufällige Sitzungs-ID mit hoher Entropie erzeugt. Die Sitzungs-ID sollte nicht in der URL enthalten sein, sicher in einem sicheren Cookie gespeichert und nach Abmeldung, Inaktivität und absoluten Timeouts invalidiert werden. + +* Idealerweise ein bewährtes, vertrauenswürdiges System für Authentifizierung, Identitätsverwaltung und Session-Management verwenden. Dieses Risiko wann immer möglich durch den Einsatz eines gehärteten und gut getesteten Systems auslagern. + +* Die vorgesehene Verwendung bereitgestellter Zugangsdaten prüfen, z. B. bei JWTs die `aud`- und `iss`-Claims sowie Scopes validieren. + + +## Beispielhafte Angriffsszenarien. + +**Szenario Nr. 1:** Credential Stuffing, die Verwendung von Listen bekannter Benutzernamen- und Passwortkombinationen, ist heute ein sehr verbreiteter Angriff. Jüngst wurde beobachtet, dass Angreifer:innen Passwörter basierend auf typischem menschlichem Verhalten „inkrementieren" oder abwandeln, z. B. von „Winter2025" zu „Winter2026" oder von „ILoveMyDog6" zu „ILoveMyDog7". Diese Methode wird als hybrider Credential-Stuffing-Angriff oder Password-Spray-Angriff bezeichnet und kann noch effektiver sein als die klassische Variante. Verfügt eine Anwendung über keine Abwehrmechanismen gegen automatisierte Angriffe oder Credential Stuffing, kann sie als Passwort-Orakel genutzt werden, um gültige Zugangsdaten zu ermitteln und unbefugten Zugriff zu erlangen. + +**Szenario Nr. 2:** Die meisten erfolgreichen Authentifizierungsangriffe erfolgen aufgrund der andauernden Verwendung von Passwörtern als einzigem Authentifizierungsfaktor. Die früher als Best Practices geltenden Anforderungen an Passwortwechsel und -komplexität verleiten Nutzer:innen sowohl zur Wiederverwendung als auch zur Wahl schwacher Passwörter. Organisationen wird empfohlen, diese Praktiken gemäß NIST 800-63 einzustellen und die Nutzung von Multi-Faktor-Authentisierung auf allen wichtigen Systemen durchzusetzen. + +**Szenario Nr. 3:** Die Session-Timeouts von Anwendungen sind nicht korrekt implementiert. Eine Nutzer:in verwendet einen öffentlichen Computer und schließt die Browser-Registerkarte, anstatt sich abzumelden. Ein weiteres Beispiel: Eine SSO-Sitzung kann nicht per Single Logout (SLO) geschlossen werden – ein einzelner Login gewährt Zugang zu mehreren Systemen (z. B. E-Mail, Dokumente, Chat), aber der Logout erfolgt nur im aktuellen System. Greifen Angreifer:innen danach auf denselben Browser zu, haben sie Zugriff auf alle noch aktiven Sitzungen. Dasselbe Problem kann in Büros auftreten, wenn eine sensible Anwendung nicht ordnungsgemäß beendet wurde und Kolleg:innen vorübergehend Zugriff auf den entsperrten Computer haben. + +## Referenzen. + +* [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) + +* [OWASP Secure Coding Practices](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/01-introduction/05-introduction) + + +## Liste der zugeordneten CWEs + +* [CWE-258 Empty Password in Configuration File](https://cwe.mitre.org/data/definitions/258.html) + +* [CWE-259 Use of Hard-coded Password](https://cwe.mitre.org/data/definitions/259.html) + +* [CWE-287 Improper Authentication](https://cwe.mitre.org/data/definitions/287.html) + +* [CWE-288 Authentication Bypass Using an Alternate Path or Channel](https://cwe.mitre.org/data/definitions/288.html) + +* [CWE-289 Authentication Bypass by Alternate Name](https://cwe.mitre.org/data/definitions/289.html) + +* [CWE-290 Authentication Bypass by Spoofing](https://cwe.mitre.org/data/definitions/290.html) + +* [CWE-291 Reliance on IP Address for Authentication](https://cwe.mitre.org/data/definitions/291.html) + +* [CWE-293 Using Referer Field for Authentication](https://cwe.mitre.org/data/definitions/293.html) + +* [CWE-294 Authentication Bypass by Capture-replay](https://cwe.mitre.org/data/definitions/294.html) + +* [CWE-295 Improper Certificate Validation](https://cwe.mitre.org/data/definitions/295.html) + +* [CWE-297 Improper Validation of Certificate with Host Mismatch](https://cwe.mitre.org/data/definitions/297.html) + +* [CWE-298 Improper Validation of Certificate with Host Mismatch](https://cwe.mitre.org/data/definitions/298.html) + +* [CWE-299 Improper Validation of Certificate with Host Mismatch](https://cwe.mitre.org/data/definitions/299.html) + +* [CWE-300 Channel Accessible by Non-Endpoint](https://cwe.mitre.org/data/definitions/300.html) + +* [CWE-302 Authentication Bypass by Assumed-Immutable Data](https://cwe.mitre.org/data/definitions/302.html) + +* [CWE-303 Incorrect Implementation of Authentication Algorithm](https://cwe.mitre.org/data/definitions/303.html) + +* [CWE-304 Missing Critical Step in Authentication](https://cwe.mitre.org/data/definitions/304.html) + +* [CWE-305 Authentication Bypass by Primary Weakness](https://cwe.mitre.org/data/definitions/305.html) + +* [CWE-306 Missing Authentication for Critical Function](https://cwe.mitre.org/data/definitions/306.html) + +* [CWE-307 Improper Restriction of Excessive Authentication Attempts](https://cwe.mitre.org/data/definitions/307.html) + +* [CWE-308 Use of Single-factor Authentication](https://cwe.mitre.org/data/definitions/308.html) + +* [CWE-309 Use of Password System for Primary Authentication](https://cwe.mitre.org/data/definitions/309.html) + +* [CWE-346 Origin Validation Error](https://cwe.mitre.org/data/definitions/346.html) + +* [CWE-350 Reliance on Reverse DNS Resolution for a Security-Critical Action](https://cwe.mitre.org/data/definitions/350.html) + +* [CWE-384 Session Fixation](https://cwe.mitre.org/data/definitions/384.html) + +* [CWE-521 Weak Password Requirements](https://cwe.mitre.org/data/definitions/521.html) + +* [CWE-613 Insufficient Session Expiration](https://cwe.mitre.org/data/definitions/613.html) + +* [CWE-620 Unverified Password Change](https://cwe.mitre.org/data/definitions/620.html) + +* [CWE-640 Weak Password Recovery Mechanism for Forgotten Password](https://cwe.mitre.org/data/definitions/640.html) + +* [CWE-798 Use of Hard-coded Credentials](https://cwe.mitre.org/data/definitions/798.html) + +* [CWE-940 Improper Verification of Source of a Communication Channel](https://cwe.mitre.org/data/definitions/940.html) + +* [CWE-941 Incorrectly Specified Destination in a Communication Channel](https://cwe.mitre.org/data/definitions/941.html) + +* [CWE-1390 Weak Authentication](https://cwe.mitre.org/data/definitions/1390.html) + +* [CWE-1391 Use of Weak Credentials](https://cwe.mitre.org/data/definitions/1391.html) + +* [CWE-1392 Use of Default Credentials](https://cwe.mitre.org/data/definitions/1392.html) + +* [CWE-1393 Use of Default Password](https://cwe.mitre.org/data/definitions/1393.html) diff --git a/2025/docs/de/A08_2025-Software_or_Data_Integrity_Failures.md b/2025/docs/de/A08_2025-Software_or_Data_Integrity_Failures.md new file mode 100644 index 000000000..bcc669ce0 --- /dev/null +++ b/2025/docs/de/A08_2025-Software_or_Data_Integrity_Failures.md @@ -0,0 +1,123 @@ +# A08:2025 Fehler bei der Software- oder Datenintegrität ![icon](../assets/TOP_10_Icons_Final_Software_and_Data_Integrity_Failures.png){: style="height:80px;width:80px" align="right"} + +## Hintergrund. + +Fehler bei der Software- oder Datenintegrität verbleibt auf Platz #8, mit einer leichten, klarstellenden Namensänderung von „Fehlern bei der Software *und* Datenintegrität". Diese Kategorie konzentriert sich auf das Versäumnis, Vertrauensgrenzen einzuhalten und die Integrität von Software, Code und Datenartefakten auf einer niedrigeren Ebene als Software Supply Chain Failures zu überprüfen. Der Schwerpunkt liegt auf Annahmen in Bezug auf Software-Updates und kritische Daten, ohne die Integrität zu überprüfen. Zu den erwähnenswerten Common Weakness Enumerations (CWEs) gehören *CWE-829: Inclusion of Functionality from Untrusted Control Sphere*, *CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes* und *CWE-502: Deserialization of Untrusted Data*. + + +## Punktetabelle. + + + + + + + + + + + + + + + + + + + + + + + + + +
Zugeordnete CWEs + Max. Häufigkeit + Durchschn. Häufigkeit + Max. Abdeckung + Durchschn. Abdeckung + Durchschn. gewichtete Ausnutzbarkeit + Durchschn. gewichtete Auswirkung + Gesamtanzahl + Summe CVEs +
14 + 8.98% + 2.75% + 78.52% + 45.49% + 7.11 + 4.79 + 501,327 + 3,331 +
+ + + +## Beschreibung. + +Software- und Datenintegritätsfehler beziehen sich auf Code und Infrastruktur, die keinen Schutz dagegen bieten, dass ungültiger oder nicht vertrauenswürdiger Code oder Daten als vertrauenswürdig und gültig behandelt werden. Ein Beispiel hierfü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 kann das Potenzial für unbefugten Zugriff, bösartigen Code oder Systemkompromittierung bieten. Ein weiteres Beispiel ist eine CI/CD-Pipeline, die Code oder Artefakte aus nicht vertrauenswürdigen Quellen bezieht und/oder diese vor der Verwendung nicht überprüft (z. B. durch Prüfung der Signatur oder eines ähnlichen Mechanismus). +Schließlich enthalten viele Anwendungen heute eine automatische Update-Funktion, bei der Updates ohne ausreichende Integritätsprüfung heruntergeladen und auf die zuvor vertrauenswürdige Anwendung angewendet werden. Angreifer:innen könnten ihre eigenen Updates hochladen, die dann auf alle Installationen verbreitet und ausgeführt werden. Ein weiteres Beispiel besteht darin, dass Objekte oder Daten in eine Struktur kodiert oder serialisiert werden, die Angreifer:innen sehen und ändern können, und die durch eine unsichere Deserialisierung verwundbar sind. + + +## Prävention und Gegenmaßnahmen. + + + +* Verwenden Sie digitale Signaturen oder ähnliche Mechanismen, um sicherzustellen, dass die Software oder Daten aus der erwarteten Quelle stammen und nicht verändert wurden. +* Stellen Sie sicher, dass Bibliotheken und Abhängigkeiten, wie z. B. npm oder Maven, ausschließlich vertrauenswürdige Repositories nutzen. Wenn Sie ein höheres Risikoprofil haben, sollten Sie in Erwägung ziehen, ein internes Repository zu hosten, das als vertrauenswürdig gilt und überprüft wurde. +* Stellen Sie sicher, dass es einen Überprüfungsprozess für Code- und Konfigurationsänderungen gibt, um das Risiko zu minimieren, dass bösartiger Code oder bösartige Konfigurationen in Ihre Software-Pipeline eingeschleust werden +* Stelle Sie sicher, dass Ihre CI/CD-Pipeline über eine angemessene Trennung, Konfiguration und Zugriffskontrolle verfügt, um die Integrität des Codes zu gewährleisten, der den Build- und Bereitstellungsprozess durchläuft. +* Stellen Sie sicher, dass unsignierte oder unverschlüsselte serialisierte Daten nicht von nicht vertrauenswürdigen Clients empfangen und anschließend ohne eine Form der Integritätsprüfung oder digitalen Signatur verwendet werden, um Manipulation oder ein erneutes Einspielen der serialisierten Daten zu erkennen. + + +## Beispielhafte Angriffsszenarien. + +**Szenario Nr. 1 – Einbindung von Web-Funktionalität aus einer nicht vertrauenswürdigen Quelle:** Ein Unternehmen nutzt einen externen Dienstleister für Support-Funktionalität. Der Bequemlichkeit halber wurde ein DNS-Mapping von `myCompany.SupportProvider.com` auf `support.myCompany.com` eingerichtet. Das bedeutet, dass alle Cookies – einschließlich Authentifizierungs-Cookies –, die für die Domain `myCompany.com` gesetzt wurden, nun an den Support-Anbieter gesendet werden. Jede Person mit Zugang zur Infrastruktur des Support-Anbieters kann die Cookies aller Nutzer:innen stehlen, die `support.myCompany.com` besucht haben, und einen Session-Hijacking-Angriff durchführen. + +**Szenario Nr. 2 – Update ohne Signierung:** Viele Heimrouter, Set-Top-Boxen, Geräte-Firmware und andere Systeme überprüfen Updates nicht anhand signierter Firmware. Unsignierte Firmware wird zunehmend zum Angriffsziel und es ist davon auszugehen, dass sich dies weiter verschlechtern wird. Dies ist besonders problematisch, da es häufig keinen Mechanismus zur Behebung gibt, außer einen Fix in einer zukünftigen Version bereitzustellen und zu warten, bis ältere Versionen nicht mehr verwendet werden. + +**Szenario Nr. 3 – Verwendung eines Pakets aus einer nicht vertrauenswürdigen Quelle:** Ein:e Entwickler:in hat Schwierigkeiten, die aktualisierte Version eines benötigten Pakets zu finden, und lädt es daher nicht vom regulären, vertrauenswürdigen Paketmanager herunter, sondern von einer Website im Internet. Das Paket ist nicht signiert, sodass keine Möglichkeit besteht, die Integrität sicherzustellen. Das Paket enthält bösartigen Code. + +**Szenario Nr. 4 – Unsichere Deserialisierung:** Eine React-Anwendung ruft eine Reihe von Spring-Boot-Microservices auf. Als funktionale Programmierer:innen haben sie versucht, ihren Code unveränderlich zu gestalten. Die gewählte Lösung besteht darin, den Nutzerzustand zu serialisieren und mit jeder Anfrage hin- und herzuschicken. Ein:e Angreifer:in erkennt die Java-Objektsignatur „rO0" (in Base64) und nutzt den [Java Deserialization Scanner](https://github.com/federicodotta/Java-Deserialization-Scanner), um Remote Code Execution auf dem Anwendungsserver zu erlangen. + +## Referenzen. + +* [OWASP Cheat Sheet: Software Supply Chain Security](https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Infrastructure as Code](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Deserialization](https://wiki.owasp.org/index.php/Deserialization_Cheat_Sheet) +* [SAFECode Software Integrity Controls](https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) +* [A 'Worst Nightmare' Cyberattack: The Untold Story Of The SolarWinds Hack](https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack) +* [CodeCov Bash Uploader Compromise](https://about.codecov.io/security-update) +* [Securing DevOps by Julien Vehent](https://www.manning.com/books/securing-devops) +* [Insecure Deserialization by Tenendo](https://tenendo.com/insecure-deserialization/) + + +## Liste der zugeordneten CWEs + +* [CWE-345 Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html) + +* [CWE-353 Missing Support for Integrity Check](https://cwe.mitre.org/data/definitions/353.html) + +* [CWE-426 Untrusted Search Path](https://cwe.mitre.org/data/definitions/426.html) + +* [CWE-427 Uncontrolled Search Path Element](https://cwe.mitre.org/data/definitions/427.html) + +* [CWE-494 Download of Code Without Integrity Check](https://cwe.mitre.org/data/definitions/494.html) + +* [CWE-502 Deserialization of Untrusted Data](https://cwe.mitre.org/data/definitions/502.html) + +* [CWE-506 Embedded Malicious Code](https://cwe.mitre.org/data/definitions/506.html) + +* [CWE-509 Replicating Malicious Code (Virus or Worm)](https://cwe.mitre.org/data/definitions/509.html) + +* [CWE-565 Reliance on Cookies without Validation and Integrity Checking](https://cwe.mitre.org/data/definitions/565.html) + +* [CWE-784 Reliance on Cookies without Validation and Integrity Checking in a Security Decision](https://cwe.mitre.org/data/definitions/784.html) + +* [CWE-829 Inclusion of Functionality from Untrusted Control Sphere](https://cwe.mitre.org/data/definitions/829.html) + +* [CWE-830 Inclusion of Web Functionality from an Untrusted Source](https://cwe.mitre.org/data/definitions/830.html) + +* [CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes](https://cwe.mitre.org/data/definitions/915.html) + +* [CWE-926 Improper Export of Android Application Components](https://cwe.mitre.org/data/definitions/926.html) diff --git a/2025/docs/de/A09_2025-Security_Logging_and_Alerting_Failures.md b/2025/docs/de/A09_2025-Security_Logging_and_Alerting_Failures.md new file mode 100644 index 000000000..c44e18404 --- /dev/null +++ b/2025/docs/de/A09_2025-Security_Logging_and_Alerting_Failures.md @@ -0,0 +1,135 @@ +# A09:2025 Unzureichendes Sicherheitslogging und Alarmierung ![icon](../assets/TOP_10_Icons_Final_Security_Logging_and_Monitoring_Failures.png){: style="height:80px;width:80px" align="right"} + + +## Hintergrund. + +„Unzureichendes Sicherheitslogging und Alarmierung“ behält seinen Platz auf Rang 9. Der Name dieser Kategorie wurde leicht geändert, um die Alarmierungsfunktion hervorzuheben, die erforderlich ist, um bei relevanten Protokollereignissen Maßnahmen auszulösen. Diese Kategorie wird in den Daten stets unterrepräsentiert sein und wurde von den Teilnehmer:innen der Community-Umfrage bereits zum dritten Mal auf einen Platz in der Liste gewählt. Diese Kategorie ist unglaublich schwer zu testen und in den CVE/CVSS-Daten nur minimal vertreten (nur 723 CVEs); sie kann jedoch erhebliche Auswirkungen auf die Transparenz, die Benachrichtigung bei Vorfällen und die Forensik haben. Diese Kategorie umfasst Probleme mit *properly handling output encoding to log files (CWE-117), inserting sensitive data into log files (CWE-532), und insufficient logging (CWE-778).* + + +## Punktetabelle. + + + + + + + + + + + + + + + + + + + + + + + + + +
Zugeordnete CWEs + Max. Häufigkeit + Durchschn. Häufigkeit + Max. Abdeckung + Durchschn. Abdeckung + Durchschn. gewichtete Ausnutzbarkeit + Durchschn. gewichtete Auswirkung + Gesamtanzahl + Summe CVEs +
5 + 11.33% + 3.91% + 85.96% + 46.48% + 7.19 + 2.65 + 260,288 + 723 +
+ + + +## Beschreibung. + +Ohne Protokollierung und Überwachung lassen sich Angriffe und Sicherheitsverletzungen nicht erkennen, und ohne Warnmeldungen ist es sehr schwierig, bei einem Sicherheitsvorfall schnell und effektiv zu reagieren. Eine unzureichende Protokollierung, kontinuierliche Überwachung, Erkennung und Warnmeldung zur Einleitung aktiver Maßnahmen kommt immer dann vor, wenn Folgendes zutrifft: + + +* Nachvollziehbare Ereignisse, wie Anmeldungen, fehlgeschlagene Anmeldungen und wertvolle Transaktionen, werden nicht protokolliert (zum Beispiel nur erfolgreiche Anmeldungen protokollieren, nicht aber fehlgeschlagene Versuche). +* Warnungen und Fehler erzeugen keine, unangemessene oder unklare Log-Einträge. +* Die Integrität der Protokolle ist nicht ausreichend vor Manipulationen geschützt. +* Die Logs von Anwendungen und APIs werden nicht auf verdächtige Aktivitäten überwacht. +* Protokolle werden nur lokal gespeichert und nicht angemessen gesichert. +* Geeignete Schwellenwerte für Warnmeldungen und Eskalationsprozesse für Gegenmaßnahmen sind nicht vorhanden oder nicht wirksam. Benachrichtigungen werden nicht innerhalb einer angemessenen Frist empfangen oder geprüft. +* Penetrationstests und Scans durch DAST-Tools (Dynamic Application Security Testing) (wie Burp oder ZAP) lösen keine Alarme aus. +* Die Anwendung kann Angriffe weder in Echtzeit noch nahezu in Echtzeit erkennen, eskalieren oder Alarm schlagen. +* Sie sind anfällig für den Verlust sensibler Informationen, wenn Sie Protokollierungs- und Warnereignisse für eine:n Benutzer:in oder eine:n Angreifer:in sichtbar machen (siehe [A01:2025-Mangelhafte Zugriffskontrolle](A01_2025-Broken_Access_Control.md)) oder wenn Sie sensible Informationen protokollieren, die nicht protokolliert werden sollten (wie z. B. personenbezogene Daten oder geschützte Gesundheitsdaten). +* Sie sind anfällig für Injection oder Angriffe auf die Protokollierungs- oder Überwachungssysteme, wenn Protokolldaten nicht encoded sind. +* Die Anwendung erkennt Fehler und andere Ausnahmebedingungen nicht oder sie behandelt diese falsch, sodass das System nicht erkennt, dass ein Fehler aufgetreten ist, und daher nicht protokollieren kann, dass ein Problem vorlag. +* Es fehlen angemessene „Anwendungsfälle“ für die Ausgabe von Warnmeldungen oder diese sind veraltet, um eine besondere Situation zu erkennen. +* Zu viele Fehlalarme machen es unmöglich, wichtige Warnmeldungen von unwichtigen zu unterscheiden, was dazu führt, dass sie zu spät oder gar nicht erkannt werden (physische Überlastung des SOC-Teams). +* Erkannte Warnmeldungen können nicht korrekt verarbeitet werden, da das Handbuch für den Anwendungsfall unvollständig, veraltet oder nicht vorhanden ist. + +## Prävention und Gegenmaßnahmen. + +Je nach dem Risiko der Anwendung sollten Entwickler:innen einige oder alle der folgenden Maßnahmen ergreifen: + +* Sicherstellen, dass alle Anmeldevorgänge, Zugriffskontrollen und Fehler bei der serverseitigen Eingabeüberprüfung mit ausreichendem Sitzungskontext der Nutzer:innen erfasst werden, um verdächtige oder böswillige Anwender:innen zu identifizieren und ausreichend lange gespeichert werden, um eine spätere forensische Analyse zu ermöglichen. +* Sicherstellen, dass jeder Teil Ihrer App, der eine Sicherheitsprüfung enthält, protokolliert wird, unabhängig davon, ob diese erfolgreich ist oder fehlschlägt. +* Sicherstellen, dass die Protokolle in einem Format gespeichert werden, das von Protokollmanagement-Lösungen leicht verarbeitet werden kann. +* Es sollte sichergestellt werden, dass die Protokolldaten korrekt encoded werden, sodass Injection-Angriffe oder Angriffe auf Logging- oder Überwachungssysteme verhindert werden. +* Es soll sichergestellt sein, dass alle Transaktionen einen Prüfpfad mit Integritätskontrollen aufweisen um Manipulationen oder Löschungen zu verhindern, z. B. durch Datenbanktabellen, die nur erweitert werden können, oder ähnliches. +* Sicherstellen, dass alle Transaktionen, bei denen ein Fehler auftritt, zurückgesetzt und neu gestartet werden. Wähle stets die „Fail-Closed“-Strategie. +* Wenn sich Ihre Anwendung oder deren Nutzer:innen verdächtig verhalten, geben Sie eine Warnmeldung aus. Erstellen Sie zu diesem Thema Leitlinien für Ihre Entwickler:innen, damit diese entsprechende Maßnahmen in den Code integrieren können, oder erwerben Sie ein System, das diese Aufgabe übernimmt. +* DevSecOps-Teams sollten eine effektive Überwachung und Alarmierung einrichten, sodass verdächtige Aktivitäten vom Security Operations Center (SOC)-Team schnell erkannt und darauf reagiert werden kann. +* Fügen Sie „Honeytokens“ als Fallen für Angreifer:innen in Ihre Anwendung ein, z. B. in die Datenbank, in Daten oder als echte und/oder technische Benutzeridentität. Da diese im normalen Geschäftsbetrieb nicht verwendet werden, erzeugt jeder Zugriff Protokolldaten, die nahezu ohne Fehlalarme gemeldet werden können. +* Verhaltensanalysen und KI-Unterstützung könnten optional als zusätzliche Technik eingesetzt werden, um die Fehlalarmquote bei Warnmeldungen zu senken. +* Erstellen oder übernehmen Sie einen Notfallplan für die Reaktion auf Vorfälle und für die Wiederherstellung, wie z. B. dem Leitfaden des National Institute of Standards and Technology (NIST) 800-61r2 oder neuer. Bringen Sie Ihren Softwareentwickler:innen bei, wie Angriffe auf Anwendungen und Vorfälle aussehen, damit sie diese melden können. + +Es gibt kommerzielle und Open-Source-Frameworks zum Schutz von Anwendungen wie das OWASP ModSecurity Core Rule Set, und Open-Source-Log correlation software, wie Elasticsearch, Logstash, Kibana (ELK) Stack, die individuelle Dashboards und Warnmeldungen bereitstellen. Es gibt auch kommerzielle Observability-Tools, mit denen Sie nahezu in Echtzeit auf Angriffe reagieren oder diese abwehren können. + + + +## Beispielhafte Angriffsszenarien. + +**Szenario Nr. 1:** Der Betreiber der Website eines Anbieters von Kinderkrankenversicherungen konnte das Eindringen in das System aufgrund mangelnder Überwachung und Protokollierung nicht erkennen. Eine externe Partei informierte den Krankenversicherungsanbieter, dass Angreifer:innen auf Tausende der mehr als 3,5 Millionen sensiblen Gesundheitsdaten der Kinder zugegriffen und diese verändert haben. Eine Überprüfung nach dem Vorfall ergab, dass die Entwickler:innen der Website wesentliche Schwachstellen nicht behoben hatten. Da es weder eine Protokollierung noch eine Überwachung des Systems gab, bestand die Datenlücke möglicherweise bereits seit 2013, also über einen Zeitraum von mehr als sieben Jahren. + +**Szenario Nr. 2:** Bei einer größeren indischen Fluggesellschaft kam es zu einer Datenpanne, die mehr als zehn Jahre lang personenbezogene Daten von Millionen von Fluggästen betraf, einschließlich Reisepass- und Kreditkartendaten. Die Datenpanne trat bei einem externen Cloud-Hosting-Anbieter auf, der die Fluggesellschaft nach einiger Zeit über die Lücke informierte. + +**Szenario Nr. 3:** Bei einer großen europäischen Fluggesellschaft kam es zu einem meldepflichtigen Verstoß gegen die DSGVO. Der Verstoß wurde Berichten zufolge durch Sicherheitsschwachstellen in Zahlungsanwendungen verschuldet, die von Angreifer:innen ausgenutzt wurden, die mehr als 400.000 Zahlungsdatensätze von Kunden abfingen. Die Fluggesellschaft wurde daraufhin von der Datenschutzbehörde mit einer Geldstrafe von 20 Millionen Pfund belegt. + + +## Referenzen. + +- [OWASP Proactive Controls: C9: Implement Logging and Monitoring](https://top10proactive.owasp.org/archive/2024/the-top-10/c9-security-logging-and-monitoring/) + +- [OWASP Application Security Verification Standard: V16 Security Logging and Error Handling](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x25-V16-Security-Logging-and-Error-Handling.md) + +- [OWASP Cheat Sheet: Application Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Application_Logging_Vocabulary_Cheat_Sheet.html) + +- [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) + +- [Data Integrity: Recovering from Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-11/final) + +- [Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-25/final) + +- [Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-26/final) + +- [Real world example of such failures in Snowflake Breach](https://www.huntress.com/threat-library/data-breach/snowflake-data-breach) + + +## Liste der zugeordneten CWEs + +* [CWE-117 Improper Output Neutralization for Logs](https://cwe.mitre.org/data/definitions/117.html) + +* [CWE-221 Information Loss of Omission](https://cwe.mitre.org/data/definitions/221.html) + +* [CWE-223 Omission of Security-relevant Information](https://cwe.mitre.org/data/definitions/223.html) + +* [CWE-532 Insertion of Sensitive Information into Log File](https://cwe.mitre.org/data/definitions/532.html) + +* [CWE-778 Insufficient Logging](https://cwe.mitre.org/data/definitions/778.html) diff --git a/2025/docs/de/A10_2025-Mishandling_of_Exceptional_Conditions.md b/2025/docs/de/A10_2025-Mishandling_of_Exceptional_Conditions.md new file mode 100644 index 000000000..970d85f0b --- /dev/null +++ b/2025/docs/de/A10_2025-Mishandling_of_Exceptional_Conditions.md @@ -0,0 +1,146 @@ +# A10:2025 – Fehlerhafte Behandlung von Ausnahmezuständen ![icon](../assets/TOP_10_Icons_Final_Mishandling_of_Exceptional_Conditions.png){: style="height:80px;width:80px" align="right"} + + +## Hintergrund. + +Fehlerhafte Behandlung von Ausnahmezuständen ist eine neue Kategorie für 2025. Diese Kategorie enthält 24 CWEs und konzentriert sich auf unsachgemäße Fehlerbehandlung, logische Fehler, „Failing Open" sowie andere verwandte Szenarien, die aus abnormalen Zuständen resultieren, mit denen Systeme konfrontiert werden können. Einige der enthaltenen CWEs waren zuvor der schlechten Codequalität zugeordnet. Das war uns zu allgemein; nach unserer Einschätzung bietet diese spezifischere Kategorie eine bessere Orientierung. + +Bemerkenswerte CWEs in dieser Kategorie: *CWE-209 Generation of Error Message Containing Sensitive Information, CWE-234 Failure to Handle Missing Parameter, CWE-274 Improper Handling of Insufficient Privileges, CWE-476 NULL Pointer Dereference* und *CWE-636 Not Failing Securely ('Failing Open')*. + + +## Beurteilungskriterien. + + + + + + + + + + + + + + + + + + + + + + + + + +
Zugeordnete CWEs + Max. Häufigkeit + Durchschn. Häufigkeit + Max. Abdeckung + Durchschn. Abdeckung + Durchschn. gewichtete Ausnutzbarkeit + Durchschn. gewichtete Auswirkung + Gesamtanzahl + Summe CVEs +
24 + 20.67% + 2.95% + 100.00% + 37.95% + 7.11 + 3.81 + 769,581 + 3,416 +
+ + + +## Beschreibung. + +Fehlerhafte Behandlung von Ausnahmezuständen in Software tritt auf, wenn Programme außergewöhnliche und unvorhersehbare Situationen weder verhindern, erkennen noch darauf reagieren – was zu Abstürzen, unerwartetem Verhalten und mitunter zu Schwachstellen führt. Dies kann einen oder mehrere der folgenden drei Mängel umfassen: Die Anwendung verhindert eine ungewöhnliche Situation nicht, sie erkennt sie nicht, während sie eintritt, und/oder sie reagiert anschließend unzureichend oder gar nicht darauf. + + + +Ausnahmezustände können durch fehlende, mangelhafte oder unvollständige Eingabevalidierung entstehen, durch späte oder übergeordnete Fehlerbehandlung anstatt dort, wo die Fehler auftreten, durch unerwartete Umgebungszustände wie Speicher-, Berechtigungs- oder Netzwerkprobleme, inkonsistente Ausnahmebehandlung oder vollständig unbehandelte Ausnahmen, die das System in einen unbekannten und unvorhersehbaren Zustand versetzen. Jedes Mal, wenn eine Anwendung über ihre nächste Anweisung unsicher ist, wurde ein Ausnahmezustand fehlerhaft behandelt. Schwer auffindbare Fehler und Ausnahmen können die Sicherheit der gesamten Anwendung über lange Zeit gefährden. + + + +Bei fehlerhafter Behandlung von Ausnahmezuständen können vielfältige Schwachstellen entstehen, wie logische Fehler, Überläufe, Race Conditions, betrügerische Transaktionen oder Probleme mit Speicher, Zustand, Ressourcen, Timing, Authentifizierung und Autorisierung. Diese Schwachstellen können die Vertraulichkeit, Verfügbarkeit und/oder Integrität eines Systems oder seiner Daten beeinträchtigen. Angreifer:innen nutzen die fehlerhafte Fehlerbehandlung einer Anwendung aus, um diese Schwachstelle auszunutzen. + + +## Prävention und Gegenmaßnahmen. + +Um Ausnahmezustände korrekt zu behandeln, müssen wir solche Situationen einplanen (vom Schlimmsten ausgehen). Wir müssen jeden möglichen Systemfehler direkt an der Stelle abfangen, an der er auftritt, und ihn dann behandeln (d. h. etwas Sinnvolles tun, um das Problem zu lösen und die Wiederherstellung sicherzustellen). Als Teil der Behandlung sollten wir einen Fehler werfen (um die/den Benutzer:in verständlich zu informieren), das Ereignis protokollieren sowie bei Bedarf einen Alarm auslösen. Wir sollten außerdem einen globalen Exception-Handler einrichten, für den Fall, dass uns etwas entgangen ist. Idealerweise verfügen wir zusätzlich über Monitoring- und/oder Observability-Werkzeuge, die auf wiederholte Fehler oder Muster hinweisen, die auf einen laufenden Angriff hindeuten, und eine Reaktion, Abwehr oder Blockierung auslösen können. Dies hilft uns, Skripte und Bots zu blockieren und darauf zu reagieren, die unsere Schwachstellen in der Fehlerbehandlung ausnutzen. + + + +Das Abfangen und Behandeln von Ausnahmezuständen stellt sicher, dass die zugrunde liegende Infrastruktur unserer Programme nicht mit unvorhersehbaren Situationen allein gelassen wird. Befindet man sich mitten in einer Transaktion jeglicher Art, ist es äußerst wichtig, die gesamte Transaktion zurückzusetzen und neu zu beginnen (auch bekannt als „Failing Closed"). Der Versuch, eine Transaktion mittendrin wiederherzustellen, ist oft der Punkt, an dem unbehebbare Fehler entstehen. + + + +Wo immer möglich sollten Rate Limiting, Ressourcenkontingente, Throttling und andere Begrenzungen eingesetzt werden, um Ausnahmezustände von vornherein zu verhindern. Nichts in der Informationstechnologie sollte unbegrenzt sein, da dies zu mangelnder Anwendungsresilienz, Denial-of-Service, erfolgreichen Brute-Force-Angriffen und enormen Cloud-Kosten führt. + +Es sollte überlegt werden, ob identische, sich wiederholende Fehler ab einer bestimmten Rate nur noch als Statistik ausgegeben werden sollten, die anzeigt, wie oft und in welchem Zeitraum sie aufgetreten sind. Diese Information sollte an die ursprüngliche Meldung angehängt werden, um automatisiertes Logging und Monitoring nicht zu beeinträchtigen, siehe [A09:2025 Unzureichendes Sicherheitslogging und Alarmierung](A09_2025-Security_Logging_and_Alerting_Failures.md). + +Darüber hinaus sollten wir strikte Eingabevalidierung (mit Bereinigung oder Escaping potenziell gefährlicher Zeichen, die wir akzeptieren müssen) sowie *zentralisierte* Fehlerbehandlung, Logging, Monitoring und Alerting mit einem globalen Exception-Handler einsetzen. Eine Anwendung sollte nicht mehrere Funktionen zur Behandlung von Ausnahmezuständen haben – dies sollte einheitlich an einer Stelle erfolgen. Wir sollten zudem Sicherheitsanforderungen für alle Empfehlungen dieses Abschnitts definieren, Bedrohungsmodellierung und/oder sichere Design-Reviews in der Entwurfsphase durchführen, Code-Reviews oder statische Analysen vornehmen sowie Stress-, Performance- und Penetrationstests am fertigen System ausführen. + + + +Wenn möglich, sollte die gesamte Organisation Ausnahmezustände einheitlich behandeln, da dies die Überprüfung und Auditierung des Codes auf Fehler in dieser wichtigen Sicherheitsmaßnahme erleichtert. + + +## Beispielhafte Angriffsszenarien. + +**Szenario Nr. 1:** Ressourcenerschöpfung durch fehlerhafte Behandlung von Ausnahmezuständen (Denial of Service) kann auftreten, wenn die Anwendung beim Datei-Upload Ausnahmen abfängt, die Ressourcen danach jedoch nicht ordnungsgemäß freigibt. Jede neue Ausnahme hinterlässt gesperrte oder anderweitig nicht verfügbare Ressourcen, bis alle Ressourcen verbraucht sind. + +**Szenario Nr. 2:** Offenlegung sensibler Daten durch fehlerhafte Behandlung von Datenbankfehlern, die den vollständigen Systemfehler an die/den Benutzer:in weitergeben. Die/Der Angreifer:in erzwingt weiterhin Fehler, um die sensiblen Systeminformationen für einen gezielteren SQL-Injection-Angriff zu nutzen. Die sensiblen Daten in den Fehlermeldungen dienen dabei als Aufklärung. + +**Szenario Nr. 3:** Zustandskorruption bei Finanztransaktionen kann durch ein:e Angreifer:in verursacht werden, der eine mehrstufige Transaktion durch Netzwerkunterbrechungen stört. Angenommen, die Transaktionsreihenfolge lautet: Nutzerkonto belasten, Zielkonto gutschreiben, Transaktion protokollieren. Wenn das System bei einem Fehler mittendrin die gesamte Transaktion nicht ordnungsgemäß zurücksetzt (Failing Closed), könnte die/der Angreifer:in das Konto der/des Nutzer:in leeren oder über eine Race Condition Geld mehrfach an das Zielkonto senden. + + +## Referenzen. + +OWASP MASVS‑RESILIENCE + +- [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) + +- [OWASP Cheat Sheet: Error Handling](https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html) + +- [OWASP Application Security Verification Standard (ASVS): V16.5 Error Handling](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x25-V16-Security-Logging-and-Error-Handling.md#v165-error-handling) + +- [OWASP Testing Guide: 4.8.1 Testing for Error Handling](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) + +* [Best practices for exceptions (Microsoft, .Net)](https://learn.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions) + +* [Clean Code and the Art of Exception Handling (Toptal)](https://www.toptal.com/developers/abap/clean-code-and-the-art-of-exception-handling) + +* [General error handling rules (Google for Developers)](https://developers.google.com/tech-writing/error-messages/error-handling) + +* [Example of real-world mishandling of an exceptional condition](https://www.firstreference.com/blog/human-error-and-internal-control-failures-cause-us62m-fine/) + +## Liste der zugeordneten CWEs +* [CWE-209 Generation of Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/209.html) +* [CWE-215 Insertion of Sensitive Information Into Debugging Code](https://cwe.mitre.org/data/definitions/215.html) +* [CWE-234 Failure to Handle Missing Parameter](https://cwe.mitre.org/data/definitions/234.html) +* [CWE-235 Improper Handling of Extra Parameters](https://cwe.mitre.org/data/definitions/235.html) +* [CWE-248 Uncaught Exception](https://cwe.mitre.org/data/definitions/248.html) +* [CWE-252 Unchecked Return Value](https://cwe.mitre.org/data/definitions/252.html) +* [CWE-274 Improper Handling of Insufficient Privileges](https://cwe.mitre.org/data/definitions/274.html) +* [CWE-280 Improper Handling of Insufficient Permissions or Privileges](https://cwe.mitre.org/data/definitions/280.html) +* [CWE-369 Divide By Zero](https://cwe.mitre.org/data/definitions/369.html) +* [CWE-390 Detection of Error Condition Without Action](https://cwe.mitre.org/data/definitions/390.html) +* [CWE-391 Unchecked Error Condition](https://cwe.mitre.org/data/definitions/391.html) +* [CWE-394 Unexpected Status Code or Return Value](https://cwe.mitre.org/data/definitions/394.html) +* [CWE-396 Declaration of Catch for Generic Exception](https://cwe.mitre.org/data/definitions/396.html) +* [CWE-397 Declaration of Throws for Generic Exception](https://cwe.mitre.org/data/definitions/397.html) +* [CWE-460 Improper Cleanup on Thrown Exception](https://cwe.mitre.org/data/definitions/460.html) +* [CWE-476 NULL Pointer Dereference](https://cwe.mitre.org/data/definitions/476.html) +* [CWE-478 Missing Default Case in Multiple Condition Expression](https://cwe.mitre.org/data/definitions/478.html) +* [CWE-484 Omitted Break Statement in Switch](https://cwe.mitre.org/data/definitions/484.html) +* [CWE-550 Server-generated Error Message Containing Sensitive Information](https://cwe.mitre.org/data/definitions/550.html) +* [CWE-636 Not Failing Securely ('Failing Open')](https://cwe.mitre.org/data/definitions/636.html) +* [CWE-703 Improper Check or Handling of Exceptional Conditions](https://cwe.mitre.org/data/definitions/703.html) +* [CWE-754 Improper Check for Unusual or Exceptional Conditions](https://cwe.mitre.org/data/definitions/754.html) +* [CWE-755 Improper Handling of Exceptional Conditions](https://cwe.mitre.org/data/definitions/755.html) +* [CWE-756 Missing Custom Error Page](https://cwe.mitre.org/data/definitions/756.html) diff --git a/2025/docs/de/X01_2025-Next_Steps.md b/2025/docs/de/X01_2025-Next_Steps.md new file mode 100644 index 000000000..b3c38d730 --- /dev/null +++ b/2025/docs/de/X01_2025-Next_Steps.md @@ -0,0 +1,319 @@ +# Nächste Schritte + +Die OWASP Top 10 sind von Natur aus auf die zehn bedeutendsten Risiken beschränkt. Jede OWASP Top 10 hat Risiken, die an der Schwelle zur Aufnahme in die Top 10 stehen, es letztendlich jedoch nicht in die Liste geschafft haben. Die anderen Risiken waren weiter verbreitet und hatten größere Auswirkungen. + +Die folgenden drei Themen sind es wert, identifiziert und behoben zu werden – insbesondere für Organisationen, die ein ausgereiftes Anwendungssicherheitsprogramm aufbauen möchten, sowie für Sicherheitsberatungsunternehmen oder Werkzeughersteller, die +ihre Abdeckung erweitern möchten. + + +## X01:2025 Mangelnde Resilienz der Anwendung + +### Hintergrund. + +Dies ist eine Umbenennung des Themas „Denial of Service" aus dem Jahr 2021. Die Umbenennung erfolgte, da der frühere Begriff ein Symptom beschrieb und nicht die eigentliche Ursache. Diese Kategorie konzentriert sich auf CWEs (Common Weakness Enumerations – Auflistungen häufiger Schwachstellen), die Schwächen im Zusammenhang mit Resilienzproblemen beschreiben. Die Bewertung dieser Kategorie lag sehr nahe an A10:2025 – Fehlerhafte Behandlung von Ausnahmezuständen. Relevante CWEs umfassen: *CWE-400 Unkontrollierter Ressourcenverbrauch, CWE-409 Unsachgemäße Behandlung von stark komprimierten Daten (Datenverstärkung), CWE-674 Unkontrollierte Rekursion* und *CWE-835 Schleife mit unerreichbarer Abbruchbedingung ('Endlosschleife')*. + + +### Punktetabelle. + + + + + + + + + + + + + + + + + + + + + + + + +
Zugeordnete CWEs + Max. Häufigkeit + Durchschn. Häufigkeit + Max. Abdeckung + Durchschn. Abdeckung + Durchschn. gewichtete Ausnutzbarkeit + Durchschn. gewichtete Auswirkung + Gesamtanzahl + Summe CVEs +
16 + 20.05% + 4.55% + 86.01% + 41.47% + 7.92 + 3.49 + 865,066 + 4,423 +
+ + + +### Beschreibung. + +Diese Kategorie stellt eine systemische Schwäche darin dar, wie Anwendungen auf Belastungen, Ausfälle und Grenzfälle reagieren, von denen sie sich nicht erholen können. Wenn eine Anwendung unerwartete Zustände, Ressourcenengpässe und andere ungünstige Ereignisse nicht ordnungsgemäß behandelt, übersteht oder sich davon erholt, kann dies leicht zu Verfügbarkeitsproblemen führen (tritt am häufigsten auf), aber auch zu Datenschädigung, Offenlegung sensibler Daten, Kaskadenausfällen und/oder der Umgehung von Sicherheitskontrollen. + +Darüber hinaus können [X02:2025 Speicherverwaltungsfehler](#x022025-speicherverwaltungsfehler) ebenfalls zum Ausfall der Anwendung oder sogar des gesamten Systems führen. + + +### Prävention und Gegenmaßnahmen. +Um diese Art von Schwachstelle zu verhindern, müssen Sie Ihre Systeme auf Fehlertoleranz und Wiederherstellung auslegen. + +* Fügen Sie Begrenzungen, Kontingente und Failover-Funktionalität hinzu, und achten Sie dabei besonders auf die ressourcenintensivsten Vorgänge. +* Identifizieren Sie ressourcenintensive Seiten und planen Sie voraus: Reduzieren Sie die Angriffsfläche, indem Sie insbesondere keine unnötigen Funktionen und Komponenten, die viele Ressourcen (z. B. Prozessor, Arbeitsspeicher) benötigen, gegenüber unbekannten oder nicht vertrauenswürdigen Benutzer:innen exponieren. +* Führen Sie eine strikte Eingabevalidierung mit Positivlisten und Größenbeschränkungen durch und testen Sie diese gründlich. +* Begrenzen Sie die Größe von Antworten und senden Sie niemals unverarbeitete Rohantworten an den Client zurück (Verarbeitung auf der Serverseite). +* Standardmäßig sicher/geschlossen konfigurieren (niemals offen), standardmäßig ablehnen und bei einem Fehler zurücksetzen. +* Vermeiden Sie blockierende synchrone Aufrufe in Anfrage-Threads (verwenden Sie asynchrone/nicht-blockierende Verarbeitung, setzen Sie Zeitüberschreitungen und Parallelitätsbeschränkungen ein usw.). +* Testen Sie Ihre Fehlerbehandlungsfunktionalität sorgfältig. +* Implementieren Sie Resilienzmuster wie Schutzschalter (Circuit Breaker), Schotten (Bulkheads), Wiederholungslogik (Retry Logic) und schrittweisen Leistungsabbau (Graceful Degradation). +* Führen Sie Leistungs- und Lasttests durch; setzen Sie bei ausreichender Risikobereitschaft auch Chaos-Engineering ein. +* Implementieren Sie Redundanz, wo dies sinnvoll und wirtschaftlich vertretbar ist, und berücksichtigen Sie diese bei der Systemarchitektur. +* Implementieren Sie Überwachung, Beobachtbarkeit und Alarmierung. +* Filtern Sie ungültige Absenderadressen gemäß RFC 2267. +* Blockieren Sie bekannte Botnetze anhand von Fingerabdrücken, IP-Adressen oder dynamisch anhand ihres Verhaltens. +* Arbeitsnachweis (Proof-of-Work): Initiieren Sie ressourcenintensive Vorgänge auf der Seite der Angreifer:innen, die normale Benutzer:innen kaum beeinträchtigen, jedoch Bots behindern, die versuchen, eine große Anzahl von Anfragen zu senden. Erhöhen Sie den Schwierigkeitsgrad des Arbeitsnachweises, wenn die allgemeine Systemlast steigt, insbesondere für Systeme, die weniger vertrauenswürdig erscheinen oder sich wie Bots verhalten. +* Begrenzen Sie die serverseitige Sitzungsdauer basierend auf Inaktivität und einer maximalen Gesamtdauer. +* Begrenzen Sie die sitzungsgebundene Informationsspeicherung. + + +### Beispielhafte Angriffsszenarien. + +**Szenario Nr. 1:** Angreifer:innen verbrauchen gezielt Anwendungsressourcen, um Ausfälle im System auszulösen und so einen Denial-of-Service zu verursachen. Dies kann durch Arbeitsspeichererschöpfung, Auffüllen des Festplattenspeichers, Prozessorüberlastung oder das Öffnen endloser Verbindungen geschehen. + +**Szenario Nr. 2:** Eingabe-Fuzzing, das zu manipulierten Antworten führt, die die Geschäftslogik der Anwendung außer Kraft setzt. + +**Szenario Nr. 3:** Angreifer:innen konzentrieren sich auf die Abhängigkeiten der Anwendung, indem sie Schnittstellen (APIs) oder andere externe Dienste zum Ausfall bringen, sodass die Anwendung nicht mehr weiterarbeiten kann. + + + +### Referenzen. + +* [OWASP Cheat Sheet: Denial of Service](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html) +* [OWASP MASVS‑RESILIENCE](https://mas.owasp.org/MASVS/11-MASVS-RESILIENCE/) +* [ASP.NET Core Best Practices (Microsoft)](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/best-practices?view=aspnetcore-9.0) +* [Resilience in Microservices: Bulkhead vs Circuit Breaker (Parser)](https://medium.com/@parserdigital/resilience-in-microservices-bulkhead-vs-circuit-breaker-54364c1f9d53) +* [Bulkhead Pattern (Geeks for Geeks)](https://www.geeksforgeeks.org/system-design/bulkhead-pattern/) +* [NIST Cybersecurity Framework (CSF)](https://www.nist.gov/cyberframework) +* [Avoid Blocking Calls: Go Async in Java (Devlane)](https://www.devlane.com/blog/avoid-blocking-calls-go-async-in-java) + +### Liste der zugeordneten CWEs +* [CWE-73 External Control of File Name or Path](https://cwe.mitre.org/data/definitions/73.html) +* [CWE-183 Permissive List of Allowed Inputs](https://cwe.mitre.org/data/definitions/183.html) +* [CWE-256 Plaintext Storage of a Password](https://cwe.mitre.org/data/definitions/256.html) +* [CWE-266 Incorrect Privilege Assignment](https://cwe.mitre.org/data/definitions/266.html) +* [CWE-269 Improper Privilege Management](https://cwe.mitre.org/data/definitions/269.html) +* [CWE-286 Incorrect User Management](https://cwe.mitre.org/data/definitions/286.html) +* [CWE-311 Missing Encryption of Sensitive Data](https://cwe.mitre.org/data/definitions/311.html) +* [CWE-312 Cleartext Storage of Sensitive Information](https://cwe.mitre.org/data/definitions/312.html) +* [CWE-313 Cleartext Storage in a File or on Disk](https://cwe.mitre.org/data/definitions/313.html) +* [CWE-316 Cleartext Storage of Sensitive Information in Memory](https://cwe.mitre.org/data/definitions/316.html) +* [CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')](https://cwe.mitre.org/data/definitions/362.html) +* [CWE-382 J2EE Bad Practices: Use of System.exit()](https://cwe.mitre.org/data/definitions/382.html) +* [CWE-419 Unprotected Primary Channel](https://cwe.mitre.org/data/definitions/419.html) +* [CWE-434 Unrestricted Upload of File with Dangerous Type](https://cwe.mitre.org/data/definitions/434.html) +* [CWE-436 Interpretation Conflict](https://cwe.mitre.org/data/definitions/436.html) +* [CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')](https://cwe.mitre.org/data/definitions/444.html) +* [CWE-451 User Interface (UI) Misrepresentation of Critical Information](https://cwe.mitre.org/data/definitions/451.html) +* [CWE-454 External Initialization of Trusted Variables or Data Stores](https://cwe.mitre.org/data/definitions/454.html) +* [CWE-472 External Control of Assumed-Immutable Web Parameter](https://cwe.mitre.org/data/definitions/472.html) +* [CWE-501 Trust Boundary Violation](https://cwe.mitre.org/data/definitions/501.html) +* [CWE-522 Insufficiently Protected Credentials](https://cwe.mitre.org/data/definitions/522.html) +* [CWE-525 Use of Web Browser Cache Containing Sensitive Information](https://cwe.mitre.org/data/definitions/525.html) +* [CWE-539 Use of Persistent Cookies Containing Sensitive Information](https://cwe.mitre.org/data/definitions/539.html) +* [CWE-598 Use of GET Request Method With Sensitive Query Strings](https://cwe.mitre.org/data/definitions/598.html) +* [CWE-602 Client-Side Enforcement of Server-Side Security](https://cwe.mitre.org/data/definitions/602.html) +* [CWE-628 Function Call with Incorrectly Specified Arguments](https://cwe.mitre.org/data/definitions/628.html) +* [CWE-642 External Control of Critical State Data](https://cwe.mitre.org/data/definitions/642.html) +* [CWE-646 Reliance on File Name or Extension of Externally-Supplied File](https://cwe.mitre.org/data/definitions/646.html) +* [CWE-653 Improper Isolation or Compartmentalization](https://cwe.mitre.org/data/definitions/653.html) +* [CWE-656 Reliance on Security Through Obscurity](https://cwe.mitre.org/data/definitions/656.html) +* [CWE-657 Violation of Secure Design Principles](https://cwe.mitre.org/data/definitions/657.html) +* [CWE-676 Use of Potentially Dangerous Function](https://cwe.mitre.org/data/definitions/676.html) +* [CWE-693 Protection Mechanism Failure](https://cwe.mitre.org/data/definitions/693.html) +* [CWE-799 Improper Control of Interaction Frequency](https://cwe.mitre.org/data/definitions/799.html) +* [CWE-807 Reliance on Untrusted Inputs in a Security Decision](https://cwe.mitre.org/data/definitions/807.html) +* [CWE-841 Improper Enforcement of Behavioral Workflow](https://cwe.mitre.org/data/definitions/841.html) +* [CWE-1021 Improper Restriction of Rendered UI Layers or Frames](https://cwe.mitre.org/data/definitions/1021.html) +* [CWE-1022 Use of Web Link to Untrusted Target with window.opener Access](https://cwe.mitre.org/data/definitions/1022.html) +* [CWE-1125 Excessive Attack Surface](https://cwe.mitre.org/data/definitions/1125.html) + + +## X02:2025 Speicherverwaltungsfehler + +### Hintergrund. +Sprachen wie Java, C#, JavaScript/TypeScript (node.js), Go und „sicheres" Rust sind speichersicher. Speicherverwaltungsprobleme treten typischerweise in nicht speichersicheren Sprachen wie C und C++ auf. Diese Kategorie erzielte in der Umfrage in der Gemeinschaft (Community) die niedrigste Bewertung und war auch in den Daten gering vertreten, obwohl sie die drittmeisten zugehörigen CVEs aufweist. Wir führen dies auf die Dominanz von Webanwendungen gegenüber traditionellen Desktop-Anwendungen zurück. Speicherverwaltungsschwachstellen weisen häufig die höchsten CVSS-Bewertungen auf. + +### Punktetabelle. + + + + + + + + + + + + + + + + + + + + + + + + +
Zugeordnete CWEs + Max. Häufigkeit + Durchschn. Häufigkeit + Max. Abdeckung + Durchschn. Abdeckung + Durchschn. gewichtete Ausnutzbarkeit + Durchschn. gewichtete Auswirkung + Gesamtanzahl + Summe CVEs +
24 + 2.96% + 1.13% + 55.62% + 28.45% + 6.75 + 4.82 + 220,414 + 30,978 +
+ + + +### Beschreibung. + +Wenn eine Anwendung gezwungen ist, den Arbeitsspeicher selbst zu verwalten, können leicht Fehler entstehen. Speichersichere Sprachen werden zwar zunehmend eingesetzt, jedoch gibt es weltweit noch viele veraltete Systeme im produktiven Betrieb, neue systemnahe Anwendungen, die den Einsatz nicht speichersicherer Sprachen erfordern, sowie Webanwendungen, die mit Großrechnern, IoT-Geräten, Firmware und anderen Systemen interagieren, die möglicherweise ihren eigenen Arbeitsspeicher verwalten müssen. Repräsentative CWEs sind *CWE-120 Pufferkopie ohne Überprüfung der Eingabegröße (‚Klassischer Pufferüberlauf')* und *CWE-121 Stapelbasierter Pufferüberlauf. Speicherverwaltungsfehler* können auftreten, wenn: + +* Sie nicht genügend Arbeitsspeicher für eine Variable reservieren +* Sie Eingaben nicht validieren und dadurch einen Überlauf des Heaps, des Stapelspeichers oder eines Puffers verursachen +* Sie einen Datenwert speichern, der größer ist als der Datentyp der Variable aufnehmen kann +* Sie versuchen, nicht reservierten Arbeitsspeicher oder Adressbereiche zu verwenden +* Sie Einzel-Versatz-Fehler erzeugen (Zählung ab 1 statt ab 0) +* Sie versuchen, auf ein Objekt zuzugreifen, nachdem dessen Speicher bereits freigegeben wurde +* Sie nicht initialisierte Variablen verwenden +* Sie Arbeitsspeicher verlieren oder anderweitig den gesamten verfügbaren Arbeitsspeicher verbrauchen, bis Ihre Anwendung abstürzt + +Speicherverwaltungsfehler können zum Ausfall der Anwendung oder sogar des gesamten Systems führen; siehe auch [X01:2025 Mangelnde Resilienz der Anwendung](#x012025-mangelnde-resilienz-der-anwendung). + + +### Prävention und Gegenmaßnahmen. + +Der beste Weg zur Vermeidung von Speicherverwaltungsfehlern ist die Verwendung einer speichersicheren Sprache. Beispiele hierfür sind Rust, Java, Go, C#, Python, Swift, Kotlin, JavaScript usw. Versuchen Sie bei der Entwicklung neuer Anwendungen, Ihre Organisation davon zu überzeugen, dass der Aufwand für den Umstieg auf eine speichersichere Sprache gerechtfertigt ist. Wenn eine vollständige Überarbeitung durchgeführt wird, setzen Sie sich dafür ein, den Code in einer speichersicheren Sprache neu zu schreiben, sofern dies möglich und machbar ist. + +Falls die Verwendung einer speichersicheren Sprache nicht möglich ist, führen Sie folgende Maßnahmen durch: + +* Aktivieren Sie die folgenden Serverfunktionen, die die Ausnutzung von Speicherverwaltungsfehlern erschweren: Adressraumanordnungs-Zufälligkeit (address space layout randomization / ASLR), Datenausführungsschutz (Data Execution Protection / DEP) und Strukturierter-Ausnahmebehandlungs-Überschreibungsschutz (Structured Exception Handling Overwrite Protection / SEHOP). +* Überwachen Sie Ihre Anwendung auf Arbeitsspeicherlecks. +* Validieren Sie alle Eingaben in Ihrem System sehr sorgfältig und weisen Sie alle Eingaben zurück, die nicht den Erwartungen entsprechen. +* Analysieren Sie die von Ihnen verwendete Programmiersprache und erstellen Sie eine Liste unsicherer und sichererer Funktionen. Teilen Sie diese Liste mit Ihrem gesamten Team. Fügen Sie sie, wenn möglich in Ihre Richtlinien oder Standards für sicheres Programmieren ein. Bevorzugen Sie beispielsweise in C die Funktion strncpy() gegenüber strcpy() und strncat() gegenüber strcat(). +* Wenn Ihre Programmiersprache oder Ihr Framework Bibliotheken für Arbeitsspeichersicherheit anbietet, verwenden Sie diese. Beispiele hierfür sind Safestringlib oder SafeStr. +* Verwenden Sie nach Möglichkeit verwaltete Puffer und Zeichenketten anstelle von unbearbeiteten (raw) Feldern und Zeigern. +* Nehmen Sie an Schulungen für sicheres Programmieren teil, die sich auf Speicherprobleme und/oder Ihre bevorzugte Programmiersprache konzentrieren. Teilen Sie Ihrem Schulungsanbieter mit, dass Sie Speicherverwaltungsfehler als besonderes Risiko betrachten. +* Führen Sie Quellcode-Überprüfungen und/oder statische Analysen durch. +* Verwenden Sie Compiler-Werkzeuge, die bei der Speicherverwaltung helfen, wie StackShield, StackGuard und Libsafe. +* Führen Sie Fuzzing für alle Eingaben in Ihrem System durch. +* Wenn ein Penetrationstest durchgeführt wird, informieren Sie die Tester:innen, dass Sie Speicherverwaltungsfehler als besonderes Risiko betrachten und dass sie diesen Aspekt beim Testen besonders berücksichtigen soll. +* Beheben Sie alle Compiler-Fehler und Warnungen. Ignorieren Sie Warnungen nicht, nur weil Ihr Programm erfolgreich kompiliert. +* Stellen Sie sicher, dass Ihre zugrundeliegende Infrastruktur regelmäßig mit Sicherheitsaktualisierungen versorgt, überprüft und gehärtet wird. +* Überwachen Sie Ihre zugrundeliegende Infrastruktur gezielt auf potenzielle Speicherschwachstellen und andere Ausfälle. +* Erwägen Sie den Einsatz von [Canary-Werten (Prüfwerte)](https://en.wikipedia.org/wiki/Buffer_overflow_protection#Canaries), um Ihren Adressstapel vor Überlaufangriffen zu schützen. + +### Beispielhafte Angriffsszenarien. + +**Szenario Nr. 1:** Pufferüberläufe sind die bekannteste Speicherschwachstelle – eine Situation, in der Angreifer:innen mehr Daten in ein Eingabefeld eingeben, als dieses aufnehmen kann, sodass der für die zugrundeliegende Variable angelegte Puffer überläuft. Bei einem erfolgreichen Angriff überschreiben die überlaufenden Zeichen den Stapelzeiger, was es ihnen ermöglicht, schadhaften Programmcode in Ihre Anwendung einzuschleusen. + +**Szenario Nr. 2:** Use-After-Free (UAF) – Zugriff auf bereits freigegebenen Speicher – tritt häufig genug auf, um eine gängige Einsendung in Browser-Fehlerprämienprogrammen (bug bounty) zu sein. Stellen Sie sich einen Webbrowser vor, der JavaScript verarbeitet, das DOM-Elemente manipuliert. Die/Der Angreifer:in erstellt eine JavaScript-Nutzlast, die ein Objekt (z. B. ein DOM-Element) erzeugt und Verweise darauf erhält. Durch gezielte Manipulation veranlasst sie/er den Browser, den Speicher des Objekts freizugeben, während ein hängender Zeiger darauf bestehen bleibt. Bevor der Browser erkennt, dass der Speicher freigegeben wurde, reserviert die/der Angreifer:in ein neues Objekt, das denselben Speicherbereich belegt. Wenn der Browser versucht, den ursprünglichen Zeiger zu verwenden, verweist dieser nun auf von der/dem Angreifer:in kontrollierte Daten. Falls dieser Zeiger auf eine virtuelle Funktionstabelle zeigte, kann die/der Angreifer:in die Programmausführung auf ihre/seine Nutzlast umleiten. + + +**Szenario Nr. 3:** Hierbei handelt es sich um einen Netzwerkdienst, der Benutzereingaben entgegennimmt, diese nicht ordnungsgemäß validiert oder bereinigt und sie dann direkt an die Protokollierungsfunktion weitergibt. Die Benutzereingabe wird als syslog(user_input) statt als syslog("%s", user_input) an die Protokollierungsfunktion übergeben, ohne dass ein Formatbezeichner angegeben wird. Angreifer:innen senden schadhafte Nutzlasten mit Formatbezeichnern wie %x, um Stapelspeicherinhalte auszulesen (Offenlegung sensibler Daten), oder %n, um in Speicheradressen zu schreiben. Durch die Verkettung mehrerer Formatbezeichner können sie den Stapelspeicher kartieren, wichtige Adressen lokalisieren und diese anschließend überschreiben. Dies wäre eine Formatzeichenketten-Schwachstelle (unkontrolliertes Zeichenkettenformat). + +Hinweis: Moderne Browser verwenden viele Schutzebenen, um sich gegen solche Angriffe zu verteidigen, darunter [Browser-Sandboxing](https://www.geeksforgeeks.org/ethical-hacking/what-is-browser-sandboxing/#types-of-browser-sandboxing), ASLR, DEP/NX, RELRO und PIE. Ein Speicherverwaltungsangriff auf einen Browser ist kein einfach durchzuführender Angriff. + +### Referenzen. + +* [OWASP community pages: Memory leak,](https://owasp.org/www-community/vulnerabilities/Memory_leak) [Doubly freeing memory,](https://owasp.org/www-community/vulnerabilities/Doubly_freeing_memory) [& Buffer Overflow](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow) +* [Awesome Fuzzing: a list of fuzzing resources](https://github.com/secfigo/Awesome-Fuzzing) +* [Project Zero Blog](https://googleprojectzero.blogspot.com) +* [Microsoft MSRC Blog](https://www.microsoft.com/en-us/msrc/blog) + +### Liste der zugeordneten CWEs +* [CWE-14 Compiler Removal of Code to Clear Buffers](https://cwe.mitre.org/data/definitions/14.html) +* [CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer](https://cwe.mitre.org/data/definitions/119.html) +* [CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')](https://cwe.mitre.org/data/definitions/120.html) +* [CWE-121 Stack-based Buffer Overflow](https://cwe.mitre.org/data/definitions/121.html) +* [CWE-122 Heap-based Buffer Overflow](https://cwe.mitre.org/data/definitions/122.html) +* [CWE-124 Buffer Underwrite ('Buffer Underflow')](https://cwe.mitre.org/data/definitions/124.html) +* [CWE-125 Out-of-bounds Read](https://cwe.mitre.org/data/definitions/125.html) +* [CWE-126 Buffer Over-read](https://cwe.mitre.org/data/definitions/126.html) +* [CWE-190 Integer Overflow or Wraparound](https://cwe.mitre.org/data/definitions/190.html) +* [CWE-191 Integer Underflow (Wrap or Wraparound)](https://cwe.mitre.org/data/definitions/191.html) +* [CWE-196 Unsigned to Signed Conversion Error](https://cwe.mitre.org/data/definitions/196.html) +* [CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition](https://cwe.mitre.org/data/definitions/367.html) +* [CWE-415 Double Free](https://cwe.mitre.org/data/definitions/415.html) +* [CWE-416 Use After Free](https://cwe.mitre.org/data/definitions/416.html) +* [CWE-457 Use of Uninitialized Variable](https://cwe.mitre.org/data/definitions/457.html) +* [CWE-459 Incomplete Cleanup](https://cwe.mitre.org/data/definitions/459.html) +* [CWE-467 Use of sizeof() on a Pointer Type](https://cwe.mitre.org/data/definitions/467.html) +* [CWE-787 Out-of-bounds Write](https://cwe.mitre.org/data/definitions/787.html) +* [CWE-788 Access of Memory Location After End of Buffer](https://cwe.mitre.org/data/definitions/788.html) +* [CWE-824 Access of Uninitialized Pointer](https://cwe.mitre.org/data/definitions/824.html) + + + +## X03:2025 Unangebrachtes Vertrauen in KI-generierten Code (‚Vibe Coding') + +### Hintergrund. + +Derzeit spricht und nutzt die gesamte Welt Künstliche Intelligenz (KI), das schließt Softwareentwickler:innen ein. Obwohl es derzeit keine CVEs oder CWEs im Zusammenhang mit KI-generiertem Code gibt, ist allgemein bekannt und dokumentiert, dass KI-generierter Code häufig mehr Schwachstellen enthält als von Menschen geschriebener Code. + +### Beschreibung. + +Wir beobachten, dass sich die Softwareentwicklungspraxis dahingehend verändert, dass nicht nur Code mit Unterstützung von KI geschrieben wird, sondern Code nahezu vollständig ohne menschliche Aufsicht erstellt und eingereicht wird (oft als „Vibe Coding" bezeichnet). So wie es noch nie eine gute Idee war, Codeausschnitte aus Blogs oder Webseiten gedankenlos zu kopieren, wird das Problem in diesem Fall noch verschärft. Gute, sichere Codeausschnitte waren und sind selten und werden von KI aufgrund systemischer Einschränkungen möglicherweise statistisch vernachlässigt. + + +### Prävention und Gegenmaßnahmen. +Wir fordern alle Personen, die Code schreiben, auf, beim Einsatz von KI Folgendes zu berücksichtigen: + +* Sie sollten in der Lage sein, den gesamten von Ihnen eingereichten Code zu lesen und vollständig zu verstehen, auch wenn er von einer KI geschrieben oder aus einem Online-Forum kopiert wurde. Sie sind für jeden Code verantwortlich, den Sie einreichen. +* Sie sollten jeden KI-unterstützten Code gründlich auf Schwachstellen überprüfen, idealerweise mit eigenen Augen und zusätzlich mit Sicherheitswerkzeugen, die für diesen Zweck entwickelt wurden (z. B. statische Analyse). Ziehen Sie klassische Quellcode-Überprüfungstechniken in Betracht, wie sie in der [OWASP-Spickzettel-Reihe: Sichere Quellcode-Überprüfung](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html) beschrieben werden. +* Im Idealfall schreiben Sie Ihren eigenen Code, lassen die KI Verbesserungen vorschlagen, überprüfen den KI-Code und lassen die KI Korrekturen vornehmen, bis Sie mit dem Ergebnis zufrieden sind. +* Erwägen Sie den Einsatz eines Retrieval Augmented Generation (RAG)-Servers mit Ihren eigenen gesammelten und geprüften sicheren Codebeispielen und Dokumentationen, wie z. B. den Richtlinien, Standards oder Vorgaben Ihrer Organisation für sicheres Programmieren, und lassen Sie den RAG-Server die Einhaltung dieser Richtlinien und Standards durchsetzen. +* Erwägen Sie den Erwerb von Werkzeugen, die Schutzmaßnahmen für Datenschutz und Sicherheit für die Verwendung mit Ihrer/Ihren KI-Lösung(en) implementieren. +* Erwägen Sie den Erwerb einer privaten KI-Lösung, idealerweise mit einer Vertragsvereinbarung (einschließlich einer Datenschutzvereinbarung), dass die KI nicht mit den Daten, Anfragen, dem Code oder anderen sensiblen Informationen Ihrer Organisation trainiert wird. +* Erwägen Sie die Implementierung eines Model Context Protocol (MCP)-Servers zwischen Ihrer Entwicklungsumgebung und der KI und konfigurieren Sie diesen so, dass er den Einsatz Ihrer bevorzugten Sicherheitswerkzeuge erzwingt. +* Implementieren Sie Richtlinien und Prozesse als Teil Ihres Softwareentwicklungslebenszyklus (SDLC), um Entwickler:innen (und alle Mitarbeiter:innen) darüber zu informieren, wie KI innerhalb Ihrer Organisation verwendet werden soll und wie nicht. +* Erstellen Sie eine Liste guter und wirksamer Eingabeaufforderungen (Prompts), die bewährte IT-Sicherheitspraktiken berücksichtigen. Idealerweise sollten diese auch Ihre internen Richtlinien für sicheres Programmieren einbeziehen. Entwickler:innen können diese Eingabeaufforderungen als Ausgangspunkt für ihre Programme verwenden. +* KI wird voraussichtlich Teil jeder Phase Ihres Softwareentwicklungslebenszyklus werden – sowohl hinsichtlich des effektiven als auch des sicheren Einsatzes. Verwenden Sie KI mit Bedacht. +* Es wird ausdrücklich **nicht** empfohlen, Vibe Coding für komplexe Funktionen, geschäftskritische Programme oder Programme, die über einen langen Zeitraum genutzt werden, einzusetzen. +* Implementieren Sie technische Prüfungen und Schutzmaßnahmen gegen die Verwendung von Schatten-KI (Shadow AI). +* Schulen Sie Ihre Entwickler:innen in Bezug auf Ihre Richtlinien sowie den sicheren KI-Einsatz und bewährte Praktiken für die Verwendung von KI in der Softwareentwicklung. + +### Referenzen. + +* [OWASP Cheat Sheet: Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html) + + +### Liste der zugeordneten CWEs +- keine diff --git a/2025/docs/de/index.md b/2025/docs/de/index.md new file mode 100644 index 000000000..7ca3e35b9 --- /dev/null +++ b/2025/docs/de/index.md @@ -0,0 +1,38 @@ +# OWASP Top 10:2025 + +Willkommen bei den OWASP Top 10:2025. + +Die OWASP Top 10 ist ein Standarddokument zur Sensibilisierung von Entwickler:innen für die Sicherheit von Webanwendungen. Sie spiegelt einen breiten Konsens über die kritischsten Sicherheitsrisiken für Webanwendungen wider. + +## Über diese Veröffentlichung + +Dies ist die **2025**-Version der OWASP Top 10. Diese Version enthält Aktualisierungen auf der Grundlage der neuesten Daten und Sicherheitstrends. + +## Hauptseite des Projekts + +Auf der [Hauptseite des Projekts](https://github.com/OWASP/www-project-top-ten) finden Sie Informationen zu älteren Versionen sowie Metadaten zu diesem Projekt. + +## Erste Schritte + +Beginnen Sie mit der [Einführung](0x00_2025-Introduction.md), um mehr über die Neuerungen in der Version 2025 zu erfahren. + +## Navigation + +- [Einführung](0x00_2025-Introduction.md) +- [Über OWASP](0x01_2025-About_OWASP.md) +- [Was sind Sicherheitsrisiken für die Anwendungen?](0x02_2025-What_are_Application_Security_Risks.md) +- [Aufbau eines modernen Programms zur Anwendungssicherheit](0x03_2025-Establishing_a_Modern_Application_Security_Program.md) + +### Liste der Top 10:2025 + +1. [A01:2025 - Mangelhafte Zugriffskontrolle](A01_2025-Broken_Access_Control.md) +2. [A02:2025 - Sicherheitsrelevante Fehlkonfiguration](A02_2025-Security_Misconfiguration.md) +3. [A03:2025 - Schwachstellen in der Software-Lieferkette](A03_2025-Software_Supply_Chain_Failures.md) +4. [A04:2025 - Fehlerhafter Einsatz von Kryptografie](A04_2025-Cryptographic_Failures.md) +5. [A05:2025 - Injection](A05_2025-Injection.md) +6. [A06:2025 - Unsicheres Design](A06_2025-Insecure_Design.md) +7. [A07:2025 - Fehlerhafte Authentifizierung](A07_2025-Authentication_Failures.md) +8. [A08:2025 - Fehler bei der Software- oder Datenintegrität](A08_2025-Software_or_Data_Integrity_Failures.md) +9. [A09:2025 - Unzureichendes Sicherheitslogging und Alarmierung](A09_2025-Security_Logging_and_Alerting_Failures.md) +10. [A10:2025 - Fehlerhafte Behandlung von Ausnahmezuständen](A10_2025-Mishandling_of_Exceptional_Conditions.md) + diff --git a/2025/mkdocs.yml b/2025/mkdocs.yml index 365826928..c943a6aaa 100644 --- a/2025/mkdocs.yml +++ b/2025/mkdocs.yml @@ -70,7 +70,28 @@ plugins: A08 Software or Data Integrity Failures: A08 Selhání integrity softwaru nebo dat A09 Security Logging and Alerting Failures: A09 Selhání bezpečnostního logování a upozorňování A10 Mishandling of Exceptional Conditions: A10 Nesprávné zpracování výjimečných stavů - Next Steps: Další kroky + Next Steps: Další kroky + - locale: de + name: de - Deutsch + build: true + nav_translations: + Home: Startseite + Introduction: Einführung + About OWASP: Über OWASP + What are Application Security Risks?: Was sind Sicherheitsrisiken für die Anwendungen? + Establishing a Modern Application Security Program: Aufbau eines modernen Programms zur Anwendungssicherheit + Top 10:2025 List: Liste der Top 10:2025 + A01 Broken Access Control: A01 Mangelhafte Zugriffskontrolle + A02 Security Misconfiguration: A02 Sicherheitsrelevante Fehlkonfiguration + A03 Software Supply Chain Failures: A03 Schwachstellen in der Software-Lieferkette + A04 Cryptographic Failures: A04 Fehlerhafter Einsatz von Kryptografie + A05 Injection: A05 Injection + A06 Insecure Design: A06 Unsicheres Design + A07 Authentication Failures: A07 Fehlerhafte Authentifizierung + A08 Software or Data Integrity Failures: A08 Fehler bei der Software- oder Datenintegrität + A09 Security Logging and Alerting Failures: A09 Unzureichendes Sicherheitslogging und Alarmierung + A10 Mishandling of Exceptional Conditions: A10 Fehlerhafte Behandlung von Ausnahmezuständen + Next Steps: Nächste Schritte - locale: es name: es - Español build: true @@ -221,9 +242,9 @@ extra: - name: es - Español link: ./es/ lang: es -# - name: de - Deutsch -# link: ./de/ -# lang: de + - name: de - Deutsch + link: ./de/ + lang: de - name: it - Italiano link: ./it/ lang: it