From df29652c9b2e242febed2142dd9027d7b27195e9 Mon Sep 17 00:00:00 2001 From: mhg Date: Fri, 24 Nov 2023 21:35:24 +0100 Subject: [PATCH] feat: As an user I want to have the latest Testing Guide (4.2) information --- .../src/app/header/header.component.html | 2 + .../objective-categories.component.ts | 3 - .../objective-table.component.ts | 2 +- .../src/assets/i18n/de-DE.json | 123 ++++++++++-------- .../src/assets/i18n/en-US.json | 119 ++++++++++------- .../src/shared/config/global-variables.ts | 2 +- .../categories/APIIT/pentests.function.ts | 14 ++ .../categories/CLIENT/pentests.function.ts | 6 + .../categories/CONFIG/pentests.function.ts | 18 +++ .../categories/CRYPST/pentests.function.ts | 6 + .../categories/IDENT/pentests.function.ts | 12 -- .../categories/INPVAL/pentests.function.ts | 66 ++++++---- .../categories/SESS/pentests.function.ts | 6 + ...get-temp-pentests-for-category.function.ts | 5 + .../get-title-key-for-ref-number.function.ts | 4 + .../infos/get-pentest-info-for-objective.ts | 4 + .../src/shared/models/category.model.ts | 3 +- .../finding-dialog.component.html | 8 +- .../finding-dialog.component.scss | 2 +- .../shared/services/api/pentest.service.ts | 2 +- .../api/pentest/PentestCategory.kt | 3 +- .../api/project/ProjectController.kt | 2 - .../src/main/resources/application.properties | 6 +- .../reporting/remote/APIService.kt | 3 +- .../remote/model/api/PentestCategory.kt | 3 +- .../reporting/report/ReportService.kt | 12 +- .../src/main/resources/application.properties | 4 +- 27 files changed, 272 insertions(+), 168 deletions(-) create mode 100644 security-c4po-angular/src/shared/functions/categories/APIIT/pentests.function.ts diff --git a/security-c4po-angular/src/app/header/header.component.html b/security-c4po-angular/src/app/header/header.component.html index ed0b6728..8c25ac76 100644 --- a/security-c4po-angular/src/app/header/header.component.html +++ b/security-c4po-angular/src/app/header/header.component.html @@ -19,6 +19,8 @@

{{SECURITYC4PO_TITLE}}

+ + diff --git a/security-c4po-angular/src/app/objective-overview/objective-categories/objective-categories.component.ts b/security-c4po-angular/src/app/objective-overview/objective-categories/objective-categories.component.ts index 696d82a6..d814287e 100644 --- a/security-c4po-angular/src/app/objective-overview/objective-categories/objective-categories.component.ts +++ b/security-c4po-angular/src/app/objective-overview/objective-categories/objective-categories.component.ts @@ -1,14 +1,11 @@ import {Component, OnDestroy, OnInit} from '@angular/core'; import {NbMenuItem, NbMenuService} from '@nebular/theme'; -import {of, Subject} from 'rxjs'; import {Store} from '@ngxs/store'; import {ChangeCategory} from '@shared/stores/project-state/project-state.actions'; import {Category} from '@shared/models/category.model'; import {untilDestroyed} from 'ngx-take-until-destroy'; import {TranslateService} from '@ngx-translate/core'; import {ProjectState} from '@shared/stores/project-state/project-state'; -import {catchError, switchMap, tap} from 'rxjs/operators'; -import {Pentest, transformPentestsToObjectiveEntries} from '@shared/models/pentest.model'; import {UntilDestroy} from '@ngneat/until-destroy'; @Component({ diff --git a/security-c4po-angular/src/app/objective-overview/objective-table/objective-table.component.ts b/security-c4po-angular/src/app/objective-overview/objective-table/objective-table.component.ts index 08ce4110..fb1b6bb4 100644 --- a/security-c4po-angular/src/app/objective-overview/objective-table/objective-table.component.ts +++ b/security-c4po-angular/src/app/objective-overview/objective-table/objective-table.component.ts @@ -45,7 +45,7 @@ export class ObjectiveTableComponent implements OnInit { getters: NbGetters = { dataGetter: (node: ObjectiveEntry) => node, childrenGetter: (node: ObjectiveEntry) => node.childEntries || undefined, - expandedGetter: (node: ObjectiveEntry) => !!node.expanded, + expandedGetter: (node: ObjectiveEntry) => !!node.expanded }; constructor( diff --git a/security-c4po-angular/src/assets/i18n/de-DE.json b/security-c4po-angular/src/assets/i18n/de-DE.json index d76da649..1e8d8143 100644 --- a/security-c4po-angular/src/assets/i18n/de-DE.json +++ b/security-c4po-angular/src/assets/i18n/de-DE.json @@ -197,7 +197,8 @@ "ERROR_HANDLING": "Fehlerbehandlung", "CRYPTOGRAPHY": "Kryptographie", "BUSINESS_LOGIC_TESTING": "Business-Logik-Testing", - "CLIENT_SIDE_TESTING": "Clientseitiges-Testing" + "CLIENT_SIDE_TESTING": "Clientseitiges-Testing", + "API_TESTING": "API Testing" }, "finding": { "findingId": "Fund Id", @@ -351,20 +352,21 @@ "001": "Netzwerk-/Infrastrukturkonfiguration testen", "002": "Testen Sie die Konfiguration der Anwendungsplattform", "003": "Testen der Behandlung von Dateierweiterungen für vertrauliche Informationen", - "004": "Backup und nicht referenzierte Dateien für sensible Informationen", + "004": "Prüfen von Backups und Dateien für sensible Informationen", "005": "Aufzählen der Infrastruktur- und Anwendungsverwaltungsschnittstellen", "006": "HTTP-Methoden testen", "007": "Testen Sie HTTP Strict Transport Security", - "008": "Testen der domänenübergreifende RIA-Richtlinie" + "008": "Testen der domänenübergreifende RIA-Richtlinie", + "009": "Dateiberechtigung testen", + "010": "Test auf Subdomain-Übernahme", + "011": "Cloud-Speicher testen" }, "ident": { "001": "Rollendefinitionen testen", "002": "Registrierungsprozess testen", "003": "Konto-Bereitstellungsprozess testen", "004": "Testen auf Kontoaufzählung und erratbares Benutzerkonto", - "005": "Test auf schwache oder nicht erzwungene Richtlinie für Benutzernamen", - "006": "Testberechtigungen von Gast-/Schulungskonten", - "007": "Sperrung/Wiederaufnahme des Kontos testen" + "005": "Test auf schwache oder nicht erzwungene Richtlinie für Benutzernamen" }, "authn": { "001": "Testen auf Anmeldeinformationen, die über einen verschlüsselten Kanal transportiert werden", @@ -392,11 +394,12 @@ "005": "Prüfung auf Cross-Site-Request-Forgery", "006": "Testen der Abmeldefunktion", "007": "Testen der Sitzungszeitüberschreitung", - "008": "Testen auf Session-Rätsel" + "008": "Testen auf Session-Puzzle", + "009": "Testen auf Session Hijacking" }, "inpval": { - "001": "Testen auf reflektiertes Cross-Site-Scripting", - "002": "Testen auf konserviertes Cross Site Scripting", + "001": "Testen auf Reflected Cross-Site-Scripting", + "002": "Testen auf Stored Cross-Site-Scripting", "003": "Testen auf HTTP-Verb-Manipulation", "004": "Prüfung auf HTTP-Parameterverschmutzung", "005": "Testen auf SQL-Injection", @@ -406,31 +409,34 @@ "005_4": "Testen von PostgreSQL", "005_5": "MS-Access-Tests", "005_6": "Testen auf NoSQL-Injection", + "005_7": "Testen auf ORM-Injection", + "005_8": "Testen für Clientseite", "006": "Testen auf LDAP-Injection", - "007": "Prüfung auf ORM-Injection", - "008": "Testen auf XML-Injection", - "009": "Prüfung auf SSI-Injection", - "010": "Testen auf XPath-Injection", - "011": "IMAP/SMTP-Injection", - "012": "Testen auf Code-Injection", - "012_1": "Testen der lokalen Dateieinbindung", - "012_2": "Testen der Remote-Dateieinbindung", - "013": "Testen auf BefehlInjection", - "014": "Test auf Pufferüberlauf", - "014_1": "Test auf Heap-Überlauf", - "014_2": "Test auf Stack-Überlauf", - "014_3": "Testen auf Formatzeichenfolge", - "015": "Testen auf inkubierte Schwachstellen", - "016": "Testen auf HTTP-Splitting/-Schmuggel" + "007": "Testen auf XML-Injection", + "008": "Prüfung auf SSI-Injection", + "009": "Testen auf XPath-Injection", + "010": "IMAP/SMTP-Injection", + "011": "Testen auf Code-Injection", + "011_1": "Testen der lokalen Dateieinbindung", + "011_2": "Testen der Remote-Dateieinbindung", + "012": "Testen auf Command Injection", + "013": "Testen auf Format-String-Injection", + "014": "Testen auf bestehende Schwachstellen", + "015": "Testen auf HTTP-Splitting/-Smuggling", + "016": "Testen auf eingehende HTTP-Anfragen", + "017": "Testen auf Host-Header-Injection", + "018": "Testen auf serverseitige Template-Injection", + "019": "Testen auf serverseitige Request Forgery" }, "err": { "001": "Analyse von Fehlercodes", "002": "Analyse von Stack-Traces" }, "crypst": { - "001": "Testen auf schwache SSL/TSL-Chiffren, unzureichenden Transportschichtschutz", + "001": "Testen auf schwache SSL/TLS-Chiffren, unzureichenden Transportschichtschutz", "002": "Testen für Padding Oracle", - "003": "Prüfung auf sensible Informationen, die über unverschlüsselte Kanäle gesendet werden" + "003": "Prüfung auf sensible Informationen, die über unverschlüsselte Kanäle gesendet werden", + "004": "Testing auf Schwache Verschlüsselung" }, "buslogic": { "001": "Testen Sie die Datenvalidierung der Geschäftslogik", @@ -455,7 +461,11 @@ "009": "Test auf Clickjacking", "010": "Testen von WebSockets", "011": "Testen von Web-Messaging", - "012": "Lokalen Speicher testen" + "012": "Lokalen Speicher testen", + "013": "Testen auf Cross-Site-Script-Integration" + }, + "api": { + "001": "Testen von GraphQL" } }, "objectives": { @@ -479,16 +489,17 @@ "005": "Administratorschnittstellen können in der Anwendung oder auf dem Anwendungsserver vorhanden sein, um bestimmten Benutzern zu ermöglichen, privilegierte Aktivitäten auf der Website durchzuführen. Es sollten Tests durchgeführt werden, um festzustellen, ob und wie diese privilegierte Funktionalität von einem nicht autorisierten oder normalen Benutzer abgerufen werden kann.\n\nEine Anwendung erfordert möglicherweise eine Administratorschnittstelle, um einem privilegierten Benutzer den Zugriff auf Funktionen zu ermöglichen, die Änderungen an der Funktionsweise der Site vornehmen können.\nSolche Änderungen können Folgendes umfassen:\n• Bereitstellung von Benutzerkonten\n• Website-Design und -Layout\n• Datenmanipulation\n• Konfigurationsänderungen\n\nIm Folgenden werden Vektoren beschrieben, die zum Testen auf das Vorhandensein von Verwaltungsschnittstellen verwendet werden können:\n• Verzeichnis- und Dateiaufzählung\n• Brute-Forcing-Tools wie THC-HYDRA\n• Kommentare und Links im Quellcode\n• Überprüfung der Server- und Anwendungsdokumentation\n• Öffentlich zugängliche Informationen (z. B. Standardpasswörter)\n• Alternativer Serverport\n• Manipulation von Parametern", "006": "Um diesen Test durchzuführen, muss der Tester irgendwie herausfinden, welche HTTP-Methoden werden vom untersuchten Webserver unterstützt. Die HTTP-Methode OPTIONS bietet dem Tester am meisten direkter und effektiver Weg, dies zu tun. RFC 2616 besagt: „Die OPTIONS-Methode stellt eine Anfrage nach Informationen über die verfügbaren Kommunikationsoptionen in der Anfrage-/Antwortkette dar, die durch den Request-URI identifiziert wird“.\n\n Einige der HTTP-Methoden können potenziell ein Sicherheitsrisiko für eine Webanwendung darstellen, da sie es einem Angreifer ermöglichen, die auf dem Webserver gespeicherten Dateien zu ändern und in einigen Szenarien die Anmeldeinformationen legitimer Benutzer zu stehlen. Genauer gesagt, die Methoden, die deaktiviert werden sollten, sind die folgenden:\n• PUT: Ermöglicht dem Client, Dateien auf den Webserver hochzuladen\n• DELETE: Allwas-Client zum Löschen von Dateien vom Webserver\n• CONNECT: ermöglicht dem Client, den Webserver als Proxy zu verwenden\n• TRACE: Gibt an den Client zurück, was er an den Server gesendet hat", "007": "Die HTTP Strict Transport Security (HSTS)-Funktion ermöglicht es einer Webanwendung, den Browser durch die Verwendung eines speziellen Antwortheaders darüber zu informieren, dass er niemals eine Verbindung zu den angegebenen Domänenservern über HTTP herstellen sollte.\n\n Der strenge HTTP-Transportsicherheitsheader verwendet zwei Anweisungen:\n• max-age\n• includeSubDomain\n\nDas Testen auf das Vorhandensein des HSTS-Headers kann durchgeführt werden, indem das Vorhandensein des HSTS-Headers in der Antwort des Servers in einem Interception-Proxy überprüft wird, oder indem curl verwendet wird.", - "008": "Rich Internet Applications (RIA) haben die crossdomain.xml-Richtliniendateien von Adobe übernommen, um einen kontrollierten domänenübergreifenden Zugriff auf Daten und Dienstnutzung mit Technologien wie Oracle Java, Silverlight und Adobe Flash zu ermöglichen. Daher kann eine Domäne den Fernzugriff auf ihre Dienste von einer anderen Domäne aus gewähren.\nOft sind die Richtliniendateien, die die Zugriffsbeschränkungen beschreiben, jedoch schlecht konfiguriert. Eine schlechte Konfiguration der Richtliniendateien ermöglicht Cross-Site Request Forgery-Angriffe.\n\n Um die Schwäche der RIA-Richtliniendatei zu testen, sollte der Tester versuchen, die Richtliniendateien crossdomain.xml und clientaccesspolicy.xml aus dem Stammverzeichnis der Anwendung und aus jedem gefundenen Ordner abzurufen." + "008": "Rich Internet Applications (RIA) haben die crossdomain.xml-Richtliniendateien von Adobe übernommen, um einen kontrollierten domänenübergreifenden Zugriff auf Daten und Dienstnutzung mit Technologien wie Oracle Java, Silverlight und Adobe Flash zu ermöglichen. Daher kann eine Domäne den Fernzugriff auf ihre Dienste von einer anderen Domäne aus gewähren.\nOft sind die Richtliniendateien, die die Zugriffsbeschränkungen beschreiben, jedoch schlecht konfiguriert. Eine schlechte Konfiguration der Richtliniendateien ermöglicht Cross-Site Request Forgery-Angriffe.\n\n Um die Schwäche der RIA-Richtliniendatei zu testen, sollte der Tester versuchen, die Richtliniendateien crossdomain.xml und clientaccesspolicy.xml aus dem Stammverzeichnis der Anwendung und aus jedem gefundenen Ordner abzurufen.", + "009": "Wenn einer Ressource eine Berechtigungseinstellung zugewiesen wird, die einem größeren Spektrum an Akteuren als erforderlich Zugriff gewährt, kann dies zur Offenlegung vertraulicher Informationen oder zur Änderung dieser Ressource durch unbeabsichtigte Parteien führen. Dies ist besonders gefährlich, wenn die Ressource mit der Programmkonfiguration, der Ausführung oder vertraulichen Benutzerdaten zusammenhängt.\n\nEin klares Beispiel ist eine Ausführungsdatei, die von nicht autorisierten Benutzern ausgeführt werden kann. Ein weiteres Beispiel: Kontoinformationen oder ein Token-Wert für den Zugriff auf eine API – was zunehmend in modernen Webdiensten oder Microservices vorkommt – können in einer Konfigurationsdatei gespeichert werden, deren Berechtigungen bei der Installation standardmäßig auf weltweit lesbar eingestellt sind. Solche sensiblen Daten können durch interne böswillige Akteure des Hosts oder durch einen Remote-Angreifer offengelegt werden, der den Dienst durch andere Schwachstellen kompromittiert, sich aber nur normale Benutzerrechte verschafft hat.\n\nZu den Dateien und Verzeichnissen, die einen Dateiberechtigungstest erfordern, gehören unter anderem:\n• Webdateien/Verzeichnis\n• Konfigurationsdateien/Verzeichnis\n• Sensible Dateien (verschlüsselte Daten, Passwort, Schlüssel)/Verzeichnis\n• Protokolldateien (Sicherheitsprotokolle, Betriebsprotokolle, Administratorprotokolle)/Verzeichnis\n• Ausführbare Dateien (Skripte, EXE, JAR, Klasse, PHP, ASP)/Verzeichnis\n• Datenbankdateien/Verzeichnis\n• Temporäre Dateien/Verzeichnis\n• Dateien/Verzeichnis hochladen", + "010": "Eine erfolgreiche Ausnutzung dieser Art von Schwachstelle ermöglicht es einem Gegner, die Subdomain des Opfers zu beanspruchen und die Kontrolle über sie zu übernehmen.\nDieser Angriff beruht auf Folgendem:\n\n1. Der externe DNS-Server-Subdomain-Eintrag des Opfers ist so konfiguriert, dass er auf eine nicht vorhandene oder nicht aktive Ressource/einen externen Dienst/Endpunkt verweist. Die Verbreitung von XaaS-Produkten (Anything as a Service) und öffentlichen Cloud-Diensten bietet viele potenzielle Ziele, die es zu berücksichtigen gilt.\n\n2. Der Dienstanbieter, der die Ressource/den externen Dienst/den Endpunkt hostet, führt die Überprüfung des Subdomain-Eigentums nicht ordnungsgemäß durch.\n\nWenn die Subdomain-Übernahme erfolgreich ist, sind vielfältige Angriffe möglich (Bereitstellung bösartiger Inhalte, Phishing, Diebstahl von Benutzersitzungscookies, Anmeldeinformationen usw.). Diese Schwachstelle könnte für eine Vielzahl von DNS-Ressourceneinträgen ausgenutzt werden, darunter: A, CNAME, MX, NS, TXT usw. In Bezug auf die Angriffsschwere hat eine NS-Subdomänenübernahme (wenn auch weniger wahrscheinlich) die größte Auswirkung, da ein erfolgreicher Angriff dies könnte Dies führt zu vollständiger Kontrolle über die gesamte DNS-Zone und die Domäne des Opfers.\n\nTestziele:\n• Zählen Sie alle möglichen Domänen auf (vorherige und aktuelle).\n• Identifizieren Sie vergessene oder falsch konfigurierte Domänen", + "011": "Cloud-Speicherdienste ermöglichen Webanwendungen und -diensten das Speichern und Zugreifen auf Objekte im Speicherdienst. Eine unsachgemäße Konfiguration der Zugriffskontrolle kann jedoch dazu führen, dass vertrauliche Informationen offengelegt werden, Daten manipuliert werden oder unbefugter Zugriff erfolgt.\n\nEin bekanntes Beispiel ist die Fehlkonfiguration eines Amazon S3-Buckets, obwohl auch die anderen Cloud-Speicherdienste ähnlichen Risiken ausgesetzt sein können. Standardmäßig sind alle S3-Buckets privat und können nur von Benutzern aufgerufen werden, denen explizit Zugriff gewährt wurde. Benutzer können öffentlichen Zugriff sowohl auf den Bucket selbst als auch auf einzelne in diesem Bucket gespeicherte Objekte gewähren. Dies kann dazu führen, dass ein unbefugter Benutzer neue Dateien hochladen, gespeicherte Dateien ändern oder lesen kann.\n\nIdentifizieren Sie zunächst die URL für den Zugriff auf die Daten im Speicherdienst und ziehen Sie dann die folgenden Tests in Betracht:\n• Die nicht autorisierten Daten lesen\n• Laden Sie eine neue beliebige Datei hoch\n\nTestziele:\n• Stellen Sie sicher, dass die Zugriffskontrollkonfiguration für die Speicherdienste ordnungsgemäß vorhanden ist" }, "ident": { - "001": "Das Ziel besteht darin, die in der Anwendung definierten Systemrollen zu validieren, um jedes System und jede Geschäftsrolle ausreichend zu definieren und zu trennen, um den angemessenen Zugriff auf Systemfunktionen und -informationen zu verwalten.\n\n In modernen Unternehmen ist es üblich, Systemrollen zu definieren, um Benutzer und Berechtigungen für Systemressourcen zu verwalten.\nDenken Sie daran, dass die kalte, harte Autorisierung nicht die einzige Möglichkeit ist, den Zugriff auf Systemobjekte zu verwalten. In vertrauenswürdigeren Umgebungen, in denen die Vertraulichkeit nicht kritisch ist, können weichere Kontrollen wie Anwendungsworkflow und Audit-Protokollierung die Anforderungen an die Datenintegrität unterstützen, ohne den Benutzerzugriff auf Funktionen einzuschränken.\n\n Entwickeln Sie entweder mit oder ohne Hilfe der Systementwickler oder Administratoren eine Rollen-Berechtigungs-Matrix. Die Matrix sollte alle Rollen auflisten, die bereitgestellt werden können, und die zulässigen Berechtigungen untersuchen.", + "001": "Das Ziel besteht darin, die in der Anwendung definierten Systemrollen zu validieren, jedes System und jede Geschäftsrolle ausreichend zu definieren und zu trennen, um den angemessenen Zugriff auf Systemfunktionen und -informationen zu verwalten.\n\nAnwendungen verfügen über verschiedene Arten von Funktionalitäten und Diensten und diese erfordern Zugriffsberechtigungen, die auf den Bedürfnissen des Benutzers basieren. Dieser Benutzer könnte sein:\n• ein Administrator, der die Anwendungsfunktionen verwaltet.\n• ein Wirtschaftsprüfer, der die Antragstransaktionen überprüft und einen detaillierten Bericht erstellt.\n• ein Support-Techniker, der Kunden beim Debuggen und Beheben von Problemen in ihren Konten unterstützt.\n• ein Kunde, der mit der Anwendung interagiert und von deren Diensten profitiert.\n\nIn vertrauenswürdigeren Umgebungen, in denen die Vertraulichkeit keine entscheidende Rolle spielt, können sanftere Kontrollen wie Anwendungsworkflow und Audit-Protokollierung die Anforderungen an die Datenintegrität unterstützen, ohne den Benutzerzugriff auf Funktionen einzuschränken. Entwickeln Sie mit oder ohne Hilfe der Systementwickler oder Administratoren eine Rollen-Berechtigungs-Matrix. Die Matrix sollte alle Rollen auflisten, die bereitgestellt werden können, und die zulässigen Berechtigungen untersuchen.\n\nTestziele:\n• Identifizieren und dokumentieren Sie die von der Anwendung verwendeten Rollen.\n• Versuchen Sie, eine andere Rolle zu wechseln, zu ändern oder darauf zuzugreifen.\n• Überprüfen Sie die Granularität der Rollen und die Anforderungen hinter den erteilten Berechtigungen", "002": "Einige Websites bieten einen Benutzerregistrierungsprozess an, der die Bereitstellung des Systemzugriffs für Benutzer automatisiert (oder halbautomatisiert). Die Identitätsanforderungen für den Zugriff variieren von positiver Identifizierung bis zu überhaupt keiner, abhängig von den Sicherheitsanforderungen des Systems.\n\n Schritt 1:\n Stellen Sie sicher, dass die Identitätsanforderungen für die Benutzerregistrierung mit den Geschäfts- und Sicherheitsanforderungen abgestimmt sind.\n\n Schritt 2:\n Bestätigen Sie den Registrierungsprozess.\n\n Stellen Sie sicher, dass die Identitätsanforderungen für die Benutzerregistrierung mit den Geschäfts- und Sicherheitsanforderungen abgestimmt sind:\n• Kann sich jeder für den Zugang registrieren?\n• Werden Registrierungen von einem Menschen überprüft?\n• Kann sich dieselbe Person oder Identität mehrmals registrieren?\n• Können sich Benutzer für verschiedene Rollen oder Berechtigungen registrieren?\n• Welcher Identitätsnachweis ist für eine Anmeldung erforderlich?\n• Werden registrierte Identitäten verifiziert?\n\n Bestätigen Sie den Registrierungsprozess:\n • Können Identitätsinformationen leicht gefälscht oder gefälscht werden?\n • Kann der Austausch von Identitätsinformationen manipuliert werden?", - "003": "Überprüfen Sie, welche Konten andere Konten bereitstellen können und welchen Typs.\n\n Die Bereitstellung von Konten bietet einem Angreifer die Möglichkeit, ein gültiges Konto zu erstellen, ohne den ordnungsgemäßen Identifizierungs- und Autorisierungsprozess anzuwenden.\nBestimmen Sie, welche Rollen Benutzer bereitstellen können und welche Art von Konten sie bereitstellen können.", - "004": "Der Zweck dieses Tests besteht darin, zu überprüfen, ob es möglich ist, eine Reihe gültiger Benutzernamen zu sammeln, indem mit dem Authentifizierungsmechanismus der Anwendung interagiert wird.\nDieser Test ist für Brute-Force-Tests nützlich, bei denen der Tester überprüft, ob es möglich ist, bei einem gültigen Benutzernamen das entsprechende Passwort zu finden.\n\nIn einigen Fällen wird eine Nachricht empfangen, die anzeigt, ob die bereitgestellten Anmeldeinformationen falsch sind, weil ein ungültiger Benutzername oder ein ungültiges Passwort verwendet wurde. Manchmal können Tester die vorhandenen Benutzer aufzählen, indem sie einen Benutzernamen und ein leeres Passwort senden.\n Wenn die Anwendung angreifbar ist, erhält der Tester eine Antwortnachricht, die direkt oder indirekt einige nützliche Informationen zum Aufzählen von Benutzern enthält.", - "005": "Das Ziel besteht darin, festzustellen, ob eine konsistente Kontonamenstruktur die Anwendung anfällig für eine Kontoaufzählung macht. Stellen Sie fest, ob die Fehlermeldungen der Anwendung eine Kontoaufzählung zulassen.\n\n Benutzerkontonamen sind oft stark strukturiert (z. B. lautet der Kontoname von Joe Bloggs jbloggs und der Kontoname von Fred Nurks fnurks) und gültige Kontonamen können leicht erraten werden.\n • Bestimmen Sie die Struktur von Kontonamen.\n• Bewerten Sie die Antwort der Anwendung auf gültige und ungültige Kontonamen.\n• Verwenden Sie unterschiedliche Antworten auf gültige und ungültige Kontonamen, um gültige Kontonamen aufzuzählen.\n• Verwenden Sie Wörterbücher für Kontonamen, um gültige Kontonamen aufzuzählen.", - "006": "Gast- und Schulungskonten sind nützliche Möglichkeiten, potenzielle Benutzer mit den Systemfunktionen vertraut zu machen, bevor sie den für den Zugriff erforderlichen Autorisierungsprozess abschließen. \n\n Bewerten Sie die Konsistenz zwischen Zugriffsrichtlinie und Zugriffsberechtigungen für Gast-/Schulungskonten.", - "007": "Überprüfen Sie, ob die Identitätsanforderungen für die Benutzerregistrierung mit den Geschäfts-/Sicherheitsanforderungen übereinstimmen.\n\nBestätigen Sie den Registrierungsprozess." + "003": "Überprüfen Sie, welche Konten andere Konten bereitstellen können und welchen Typs.\n\nDie Bereitstellung von Konten bietet einem Angreifer die Möglichkeit, ein gültiges Konto zu erstellen, ohne den ordnungsgemäßen Identifizierungs- und Autorisierungsprozess anzuwenden.\n\nSo testen Sie\n\nBestimmen Sie, welche Rollen Benutzer bereitstellen können und welche Art von Konten sie bereitstellen können:\n• Gibt es eine Überprüfung, Prüfung und Autorisierung von Bereitstellungsanfragen?\n• Gibt es eine Überprüfung, Prüfung und Autorisierung von De-Provisioning-Anfragen?\n• Kann ein Administrator andere Administratoren oder nur Benutzer bereitstellen?\n• Kann ein Administrator oder ein anderer Benutzer Konten mit Berechtigungen versehen, die über ihre eigenen hinausgehen?\n• Kann ein Administrator oder Benutzer die Bereitstellung selbst aufheben?\n• Wie werden die Dateien oder Ressourcen verwaltet, die dem deprovisionierten Benutzer gehören? Werden sie gelöscht? Wird der Zugriff übertragen?", + "004": "Der Zweck dieses Tests besteht darin, zu überprüfen, ob es möglich ist, durch Interaktion mit dem Authentifizierungsmechanismus der Anwendung einen Satz gültiger Benutzernamen zu sammeln. Dieser Test ist für Brute-Force-Tests nützlich, bei denen der Tester überprüft, ob es bei einem gültigen Benutzernamen möglich ist, das entsprechende Passwort zu finden.\n\nIn manchen Fällen wird eine Meldung empfangen, die Aufschluss darüber gibt, ob die angegebenen Anmeldeinformationen falsch sind, weil ein ungültiger Benutzername oder ein ungültiges Passwort verwendet wurde. Manchmal können Tester die vorhandenen Benutzer aufzählen, indem sie einen Benutzernamen und ein leeres Passwort senden. Wenn die Anwendung angreifbar ist, erhält der Tester eine Antwortnachricht, die direkt oder indirekt einige Informationen enthält, die für die Enumeration von Benutzern nützlich sind.\n\nTestziele\n• Überprüfen Sie Prozesse, die sich auf die Benutzeridentifizierung beziehen (z. B. Registrierung, Anmeldung usw.).\n• Erfassen Sie Benutzer nach Möglichkeit mithilfe einer Antwortanalyse", + "005": "Das Ziel besteht darin, festzustellen, ob eine konsistente Kontonamenstruktur die Anwendung anfällig für die Kontoaufzählung macht. Stellen Sie fest, ob die Fehlermeldungen der Anwendung eine Kontoaufzählung zulassen.\n\nTestziele\n• Stellen Sie fest, ob eine konsistente Kontonamenstruktur die Anwendung anfällig für die Kontoaufzählung macht.\n• Stellen Sie fest, ob die Fehlermeldungen der Anwendung eine Kontoaufzählung zulassen.\n\nBenutzerkontonamen sind häufig stark strukturiert (z. B. lautet der Kontoname von Joe Bloggs jbloggs und der Kontoname von Fred Nurk lautet fnurks), und gültige Kontonamen können leicht erraten werden.\n\nSo testen Sie\n• Bestimmen Sie die Struktur von Kontonamen.\n• Bewerten Sie die Reaktion der Anwendung auf gültige und ungültige Kontonamen.\n• Verwenden Sie unterschiedliche Antworten auf gültige und ungültige Kontonamen, um gültige Kontonamen aufzulisten.\n• Verwenden Sie Kontonamenwörterbücher, um gültige Kontonamen aufzulisten." }, "authn": { "001": "Die Analyse konzentriert sich einfach darauf, zu verstehen, ob die Daten unverschlüsselt vom Webbrowser zum Server übertragen werden oder ob die Webanwendung mithilfe eines Protokolls wie HTTPS die geeigneten Sicherheitsmaßnahmen ergreift.\n\n Das Testen auf den Transport von Anmeldeinformationen bedeutet, dass überprüft wird, ob die des Benutzers\nAuthentifizierungsdaten werden über einen verschlüsselten Kanal übertragen, um zu verhindern, dass sie von böswilligen Benutzern abgefangen werden.\n\n Sie können WebScarab oder einen beliebigen Web-Proxy verwenden, um Paket-Header zu erfassen und zu untersuchen.\n Überprüfen Sie, ob HTTPS in jeder sensiblen Anfrage verwendet wird, wie z. B. in Anmeldeseiten, um zu verhindern, dass unbefugte Benutzer die Daten abfangen.", @@ -516,7 +527,8 @@ "005": "CSRF ist ein Angriff, der einen Endbenutzer dazu zwingt, unerwünschte Aktionen auf einer Webanwendung auszuführen, in der er/sie gerade authentifiziert ist.\nEin erfolgreicher CSRF-Exploit kann die Daten und den Betrieb von Endbenutzern gefährden, wenn er auf einen normalen Benutzer abzielt. Wenn der Zielbenutzer das Administratorkonto ist, kann ein CSRF-Angriff die gesamte Webanwendung gefährden.\n CSRF stützt sich auf Folgendes:\n\n Punkt 1:\n Verhalten des Webbrowsers in Bezug auf den Umgang mit sitzungsbezogenen Informationen wie Cookies und HTTP-Authentifizierungsinformationen;\n\n Punkt 2:\n Kenntnis des Angreifers von gültigen Webanwendungs-URLs;\n\n Punkt 3:\n Anwendungssitzungsverwaltung, die sich nur auf Informationen stützt, die dem Browser bekannt sind;\n\n Punkt 4:\n Vorhandensein von HTML-Tags, deren Vorhandensein einen sofortigen Zugriff auf eine http[s]-Ressource bewirkt; zum Beispiel das Image-Tag img\n\n Der Tester muss URLs im eingeschränkten (authentifizierten) Bereich kennen. Wenn sie über gültige Anmeldeinformationen verfügen, können sie beide Rollen einnehmen – Angreifer und Opfer. In diesem Fall kennen Tester die zu testenden URLs, indem sie sich einfach umsehen.\n\n Wenn sich die Sitzungsverwaltung nur auf clientseitige Werte stützt (Informationen, die dem Browser zur Verfügung stehen), ist die Anwendung anfällig.\n Damit eine Anwendung nicht anfällig ist, muss sie sitzungsbezogene Informationen in der URL enthalten, und zwar in einer Form, die für den Benutzer nicht identifizierbar oder unvorhersehbar ist.", "006": "Die Sitzungsbeendigung ist ein wichtiger Teil des Sitzungslebenszyklus. Das Verkürzen der Lebensdauer der Sitzungstoken auf ein Minimum verringert die Wahrscheinlichkeit eines erfolgreichen Sitzungs-Hijacking-Angriffs. Dies kann als Kontrolle gegen andere Angriffe wie Cross Site Scripting und Cross Site Request Forgery angesehen werden. Es ist bekannt, dass solche Angriffe darauf beruhen, dass ein Benutzer eine authentifizierte Sitzung hat.\n\n Eine sichere Sitzungsbeendigung erfordert mindestens die folgenden Komponenten:\n • Verfügbarkeit von Steuerelementen der Benutzeroberfläche, mit denen sich der Benutzer manuell abmelden kann\n • Sitzungsbeendigung nach einer bestimmten Zeit ohne Aktivität (Session-Timeout)\n • Ordnungsgemäße Invalidierung des serverseitigen Sitzungsstatus\n\n Der richtige Wert für das Sitzungs-Timeout hängt vom Zweck der Anwendung ab und sollte ein Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit darstellen.", "007": "In dieser Phase überprüfen Tester, ob die Anwendung einen Benutzer automatisch abmeldet, wenn dieser Benutzer eine bestimmte Zeit lang inaktiv war, um sicherzustellen, dass dieselbe Sitzung nicht „wiederverwendet“ werden kann und dass keine sensiblen Daten im Browser-Cache gespeichert bleiben .\n\n Das Leerlaufzeitlimit schränkt die Wahrscheinlichkeit ein, dass ein Angreifer eine gültige Sitzungs-ID eines anderen Benutzers erraten und verwenden muss, und könnte unter bestimmten Umständen öffentliche Computer vor der Wiederverwendung von Sitzungen schützen. Verwaltung und Ablauf von Sitzungszeitüberschreitungen müssen serverseitig erzwungen werden. Wenn einige Daten unter der Kontrolle des Clients verwendet werden, um das Sitzungs-Timeout zu erzwingen, könnte ein Angreifer diese manipulieren, um die Sitzungsdauer zu verlängern.\n\n Schritt 1:\nTester müssen prüfen, ob ein Timeout vorliegt, indem sie sich beispielsweise anmelden und auf das Auslösen des Timeout-Logouts warten. Wie bei der Abmeldefunktion sollten nach Ablauf des Timeouts alle Sitzungstoken zerstört oder unbrauchbar sein.\n\n Schritt 2:\n Wenn das Timeout konfiguriert ist, müssen Tester verstehen, ob das Timeout vom Client oder vom Server erzwungen wird.\n\n Generell sollte serverseitig alles überprüft werden und es sollte nicht möglich sein, durch Zurücksetzen der Session-Cookies auf vorherige Werte wieder auf die Anwendung zuzugreifen.", - "008": "Das Überladen von Sitzungsvariablen (Session Puzzling) ist eine Schwachstelle auf Anwendungsebene, die es einem Angreifer ermöglichen kann, eine Vielzahl von böswilligen Aktionen auszuführen, einschließlich, aber nicht beschränkt auf ...\n.. effiziente Mechanismen zur Durchsetzung der Authentifizierung umgehen und sich als legitime Benutzer ausgeben.\n.. erhöhen der Rechte eines böswilligen Benutzerkontos in einer Umgebung, die ansonsten als narrensicher gelten würde.\n.. Qualifizierungsphasen in mehrphasigen Prozessen überspringen, selbst wenn der Prozess Einschränkungen auf Codeebene enthält.\n.. serverseitige Werte mit indirekten Methoden manipulieren, die nicht vorhergesagt oder erkannt werden können.\n.. herkömmliche Angriffe an Orten ausführen, die zuvor unerreichbar waren oder sogar als sicher galten.\n\n Diese Schwachstelle tritt auf, wenn eine Anwendung dieselbe Sitzungsvariable für mehr als einen Zweck verwendet. Es kann erkannt und ausgenutzt werden, indem alle Sitzungsvariablen, die von der Anwendung verwendet werden, und in welchem \u200B\u200BKontext sie gültig sind, aufgelistet werden. Dies ist insbesondere möglich, indem auf eine Folge von Einstiegspunkten zugegriffen und dann Ausstiegspunkte untersucht werden." + "008": "Das Überladen von Sitzungsvariablen (Session Puzzling) ist eine Schwachstelle auf Anwendungsebene, die es einem Angreifer ermöglichen kann, eine Vielzahl von böswilligen Aktionen auszuführen, einschließlich, aber nicht beschränkt auf ...\n.. effiziente Mechanismen zur Durchsetzung der Authentifizierung umgehen und sich als legitime Benutzer ausgeben.\n.. erhöhen der Rechte eines böswilligen Benutzerkontos in einer Umgebung, die ansonsten als narrensicher gelten würde.\n.. Qualifizierungsphasen in mehrphasigen Prozessen überspringen, selbst wenn der Prozess Einschränkungen auf Codeebene enthält.\n.. serverseitige Werte mit indirekten Methoden manipulieren, die nicht vorhergesagt oder erkannt werden können.\n.. herkömmliche Angriffe an Orten ausführen, die zuvor unerreichbar waren oder sogar als sicher galten.\n\n Diese Schwachstelle tritt auf, wenn eine Anwendung dieselbe Sitzungsvariable für mehr als einen Zweck verwendet. Es kann erkannt und ausgenutzt werden, indem alle Sitzungsvariablen, die von der Anwendung verwendet werden, und in welchem \u200B\u200BKontext sie gültig sind, aufgelistet werden. Dies ist insbesondere möglich, indem auf eine Folge von Einstiegspunkten zugegriffen und dann Ausstiegspunkte untersucht werden.", + "009": "Ein Angreifer, der Zugriff auf Benutzersitzungscookies erhält, kann sich durch die Bereitstellung solcher Cookies als diese ausgeben. Dieser Angriff wird als Session-Hijacking bezeichnet. Betrachtet man Netzwerkangreifer, d. h. Angreifer, die das vom Opfer verwendete Netzwerk kontrollieren, können Sitzungscookies dem Angreifer über HTTP unangemessen zugänglich gemacht werden. Um dies zu verhindern, sollten Sitzungscookies mit dem Attribut „Sicher“ gekennzeichnet werden, sodass sie nur über HTTPS kommuniziert werden.\n\nTestziele\n• Identifizieren Sie anfällige Sitzungscookies.\n• Kapern Sie anfällige Cookies und bewerten Sie das Risikoniveau.\n\nSo testen Sie\nHier sind die Schritte zur Durchführung dieses Tests:\n1. Melden Sie sich als Opfer auf der Website an und gelangen Sie zu einer beliebigen Seite, die eine sichere Funktion bietet, die eine Authentifizierung erfordert.\n2. Löschen Sie alle Cookies aus der Keksdose, die eine der folgenden Bedingungen erfüllen.\n• Falls keine HSTS-Übernahme erfolgt: Das Secure-Attribut ist gesetzt.\n• bei teilweiser HSTS-Einführung: Das Secure-Attribut ist gesetzt oder das Domain-Attribut ist nicht gesetzt.\n3. Speichern Sie einen Schnappschuss der Keksdose.\n4. Lösen Sie die in Schritt 1 identifizierte sichere Funktion aus.\n5. Beobachten Sie, ob der Vorgang in Schritt 4 erfolgreich durchgeführt wurde. Wenn ja, war der Angriff erfolgreich.\n6. Leeren Sie die Keksdose, melden Sie sich als Angreifer an und gelangen Sie zur Seite bei Schritt 1.\n7. Schreiben Sie die in Schritt 3 gespeicherten Kekse nacheinander in die Keksdose.\n8. Lösen Sie die in Schritt 1 identifizierte Sicherheitsfunktion erneut aus.\n9. Leeren Sie die Keksdose und melden Sie sich erneut als Opfer an.\n10. Beobachten Sie, ob der Vorgang in Schritt 8 im Konto des Opfers erfolgreich durchgeführt wurde. Wenn ja, war der Angriff erfolgreich; andernfalls ist die Site vor Session-Hijacking geschützt.\n\nBeachten Sie, dass das Secure-Attribut auch verwendet werden sollte, wenn die Webanwendung vollständig über HTTPS bereitgestellt wird, da sonst der folgende Cookie-Diebstahl-Angriff möglich ist. Gehen Sie davon aus, dass example.com vollständig über HTTPS bereitgestellt wird, seine Sitzungscookies jedoch nicht als „sicher“ markiert.\n\nFolgende Angriffsschritte sind möglich:\n1. Das Opfer sendet eine Anfrage an http://another-site.com.\n2. Der Angreifer manipuliert die entsprechende Antwort, sodass eine Anfrage an http://example.com ausgelöst wird.\n3. Der Browser versucht nun, auf http://example.com zuzugreifen.\n4. Obwohl die Anfrage fehlschlägt, werden die Sitzungscookies im Klartext über HTTP weitergegeben.\n\nWenn das Domänenattribut festgelegt ist, können Sitzungscookies über Subdomänen hinweg gemeinsam genutzt werden. Die Verwendung von HTTP mit Subdomains sollte vermieden werden, um die Offenlegung unverschlüsselter, über HTTP gesendeter Cookies zu verhindern. Um diese Sicherheitslücke zu veranschaulichen, gehen wir davon aus, dass die Website example.com HSTS ohne die Option includeSubDomains aktiviert. Die Website gibt Sitzungscookies aus, wobei das Domain-Attribut auf example.com festgelegt ist.\n\nFolgender Angriff ist möglich:\n1. Das Opfer sendet eine Anfrage an http://another-site.com.\n2. Der Angreifer manipuliert die entsprechende Antwort, sodass eine Anfrage an http://fake.example.com ausgelöst wird.\n3. Der Browser versucht nun, auf http://fake.example.com zuzugreifen, was die HSTS-Konfiguration zulässt.\n4. Da die Anfrage an eine Unterdomäne von example.com mit festgelegtem Domänenattribut gesendet wird, enthält sie die Sitzungscookies, die im Klartext über HTTP durchgesickert sind." }, "inpval": { "001": "Reflected Cross-Site Scripting (XSS) tritt auf, wenn ein Angreifer ausführbaren Browsercode in eine einzelne HTTP-Antwort einfügt.\nDer eingeschleuste Angriff wird nicht in der Anwendung selbst gespeichert; Es ist nicht dauerhaft und wirkt sich nur auf Benutzer aus, die einen in böser Absicht erstellten Link oder eine Webseite eines Drittanbieters öffnen.\nDie Angriffszeichenfolge ist Teil der präparierten URI- oder HTTP-Parameter, wird von der Anwendung nicht ordnungsgemäß verarbeitet und an das Opfer zurückgegeben. Eine der Hauptschwierigkeiten beim Verhindern von XSS-Schwachstellen ist die richtige Zeichencodierung.\n In einigen Fällen filtert der Webserver oder die Webanwendung möglicherweise einige Zeichencodierungen nicht, sodass die Webanwendung beispielsweise „