diff --git a/security-c4po-angular/src/app/pentest/pentest-content/pentest-content.component.html b/security-c4po-angular/src/app/pentest/pentest-content/pentest-content.component.html index b695110..45db242 100644 --- a/security-c4po-angular/src/app/pentest/pentest-content/pentest-content.component.html +++ b/security-c4po-angular/src/app/pentest/pentest-content/pentest-content.component.html @@ -1,13 +1,13 @@
- - + + - + - + diff --git a/security-c4po-angular/src/app/pentest/pentest-content/pentest-content.component.scss b/security-c4po-angular/src/app/pentest/pentest-content/pentest-content.component.scss index 3c5ef5a..608d8c2 100644 --- a/security-c4po-angular/src/app/pentest/pentest-content/pentest-content.component.scss +++ b/security-c4po-angular/src/app/pentest/pentest-content/pentest-content.component.scss @@ -3,10 +3,13 @@ height: 100%; .content { - overflow: auto !important; height: 95%; - // check fixed height - // background-color: #8f9bb3; + overflow: auto !important; + + // ToDo: Fixes tab header but also disables scrolling for content + /*nb-tab { + position: fixed; + }*/ } .content-footer { diff --git a/security-c4po-angular/src/app/pentest/pentest-content/pentest-content.component.ts b/security-c4po-angular/src/app/pentest/pentest-content/pentest-content.component.ts index 3f080f9..b16efe8 100644 --- a/security-c4po-angular/src/app/pentest/pentest-content/pentest-content.component.ts +++ b/security-c4po-angular/src/app/pentest/pentest-content/pentest-content.component.ts @@ -13,6 +13,7 @@ import {Pentest} from '@shared/models/pentest.model'; styleUrls: ['./pentest-content.component.scss'] }) export class PentestContentComponent implements OnInit { + // HTML only readonly fa = FA; pentest$: BehaviorSubject = new BehaviorSubject(null); @@ -23,11 +24,10 @@ export class PentestContentComponent implements OnInit { constructor(private store: Store) { } ngOnInit(): void { - this.store.select(ProjectState.pentest).pipe( + this.store.selectOnce(ProjectState.pentest).pipe( untilDestroyed(this) ).subscribe({ next: (selectedPentest: Pentest) => { - console.warn('Selected Pentest: ', selectedPentest); this.pentest$.next(selectedPentest); const findings = selectedPentest.findingsIds ? selectedPentest.findingsIds.length : 0; this.currentNumberOfFindings$.next(findings); diff --git a/security-c4po-angular/src/app/pentest/pentest-content/pentest-info/pentest-info.component.html b/security-c4po-angular/src/app/pentest/pentest-content/pentest-info/pentest-info.component.html index 3aaf377..fa84cdd 100644 --- a/security-c4po-angular/src/app/pentest/pentest-content/pentest-info/pentest-info.component.html +++ b/security-c4po-angular/src/app/pentest/pentest-content/pentest-info/pentest-info.component.html @@ -1 +1,9 @@ -

pentest-info works!

+
+

+ {{ getPentestHeaderForObjective(pentestInfo$.getValue().refNumber) | translate}} +

+

+ {{ getPentestInfoForObjective(pentestInfo$.getValue().refNumber) | translate }} +

+ +
diff --git a/security-c4po-angular/src/app/pentest/pentest-content/pentest-info/pentest-info.component.scss b/security-c4po-angular/src/app/pentest/pentest-content/pentest-info/pentest-info.component.scss index e69de29..26061f8 100644 --- a/security-c4po-angular/src/app/pentest/pentest-content/pentest-info/pentest-info.component.scss +++ b/security-c4po-angular/src/app/pentest/pentest-content/pentest-info/pentest-info.component.scss @@ -0,0 +1,12 @@ +.pentest-info { + overflow-y: scroll; + overflow-x: hidden; + // overflow: auto !important; + position: relative !important; + + .description { + width: 60vw; + font-size: 1rem; + white-space: pre-line; + } +} diff --git a/security-c4po-angular/src/app/pentest/pentest-content/pentest-info/pentest-info.component.ts b/security-c4po-angular/src/app/pentest/pentest-content/pentest-info/pentest-info.component.ts index 315d6e0..89bca9c 100644 --- a/security-c4po-angular/src/app/pentest/pentest-content/pentest-info/pentest-info.component.ts +++ b/security-c4po-angular/src/app/pentest/pentest-content/pentest-info/pentest-info.component.ts @@ -1,4 +1,8 @@ -import { Component, OnInit } from '@angular/core'; +import {Component, Input, OnInit} from '@angular/core'; +import {BehaviorSubject} from 'rxjs'; +import {Pentest} from '@shared/models/pentest.model'; +import {getPentestInfoForObjective} from '@shared/functions/infos/get-pentest-info-for-objective'; +import {getTitleKeyForRefNumber} from '@shared/functions/categories/get-title-key-for-ref-number.function'; @Component({ selector: 'app-pentest-info', @@ -7,9 +11,21 @@ import { Component, OnInit } from '@angular/core'; }) export class PentestInfoComponent implements OnInit { + @Input() + pentestInfo$: BehaviorSubject = new BehaviorSubject(null); + constructor() { } ngOnInit(): void { + console.warn('Selected Pentest: ', this.pentestInfo$.getValue()); + } + + getPentestHeaderForObjective(refNumber: string): string { + return getTitleKeyForRefNumber(refNumber); + } + + getPentestInfoForObjective(refNumber: string): string { + return getPentestInfoForObjective(refNumber); } } diff --git a/security-c4po-angular/src/app/pentest/pentest.component.ts b/security-c4po-angular/src/app/pentest/pentest.component.ts index bc34068..8ddc177 100644 --- a/security-c4po-angular/src/app/pentest/pentest.component.ts +++ b/security-c4po-angular/src/app/pentest/pentest.component.ts @@ -11,7 +11,6 @@ export class PentestComponent implements OnInit { ngOnInit(): void { // tslint:disable-next-line:no-console - console.info('pentest component renderd'); } } diff --git a/security-c4po-angular/src/assets/i18n/de-DE.json b/security-c4po-angular/src/assets/i18n/de-DE.json index a27f872..6fd9e7f 100644 --- a/security-c4po-angular/src/assets/i18n/de-DE.json +++ b/security-c4po-angular/src/assets/i18n/de-DE.json @@ -75,6 +75,19 @@ "delete.failed": "Projekt konnte nicht gelöscht werden" } }, + "categories": { + "INFORMATION_GATHERING": "Informationsbeschaffung", + "CONFIGURATION_AND_DEPLOY_MANAGEMENT_TESTING": "Konfig- & Einsatzmanagement-Testing", + "IDENTITY_MANAGEMENT_TESTING": "Identitätsmanagement-Testing", + "AUTHENTICATION_TESTING": "Authentifizierungs-Testing", + "AUTHORIZATION_TESTING": "Autorisations-Testing", + "SESSION_MANAGEMENT_TESTING": "Sitzungsmanagement-Testing", + "INPUT_VALIDATION_TESTING": "Eingabevalidierungs-Testing", + "ERROR_HANDLING": "Fehlerbehandlung", + "CRYPTOGRAPHY": "Kryptographie", + "BUSINESS_LOGIC_TESTING": "Business-Logik-Testing", + "CLIENT_SIDE_TESTING": "Clientseitiges-Testing" + }, "pentest": { "testId": "Nr.", "title": "Titel", @@ -94,7 +107,7 @@ "003": "Prüfe Webserver-Metadateien auf Informationslecks", "004": "Anwendungen auf dem Webserver auflisten", "005": "Prüfe Webseitenkommentare und Metadaten auf Informationslecks", - "006": "Einstiegspunkte für Identitätsanträge", + "006": "Identifizieren der Einstiegspunkte", "007": "Zuordnen von Ausführungspfade der Anwendung", "008": "Framework für Fingerabdruck-Webanwendungen", "009": "Fingerabdruck-Webanwendungen", @@ -152,29 +165,29 @@ "002": "Testen auf konserviertes Cross Site Scripting", "003": "Testen auf HTTP-Verb-Manipulation", "004": "Prüfung auf HTTP-Parameterverschmutzung", - "005": "N/A", - "006": "Testen auf SQL-Injection", - "006_1": "Oracle-Tests", - "006_2": "SQL Server-Tests", - "006_3": "Testen von PostgreSQL", - "006_4": "MS-Access-Tests", - "006_5": "Testen auf NoSQL-Injection", - "007": "Testen auf LDAP-Injection", - "008": "Prüfung auf ORM-Injection", - "009": "Testen auf XML-Injection", - "010": "Prüfung auf SSI-Injection", - "011": "Testen auf XPath-Injection", - "012": "IMAP/SMTP-Injection", - "013": "Testen auf Code-Injection", - "013_1": "Testen der lokalen Dateieinbindung", - "013_2": "Testen der Remote-Dateieinbindung", - "014": "Testen auf BefehlInjection", - "015": "Test auf Pufferüberlauf", - "015_1": "Test auf Heap-Überlauf", - "015_2": "Test auf Stack-Überlauf", - "015_3": "Testen auf Formatzeichenfolge", - "016": "Testen auf inkubierte Schwachstellen", - "017": "Testen auf HTTP-Splitting/-Schmuggel" + "005": "Testen auf SQL-Injection", + "005_1": "Oracle-Tests", + "005_2": "MySQL-Tests", + "005_3": "SQL Server-Tests", + "005_4": "Testen von PostgreSQL", + "005_5": "MS-Access-Tests", + "005_6": "Testen auf NoSQL-Injection", + "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" }, "err": { "001": "Analyse von Fehlercodes", @@ -211,18 +224,130 @@ "012": "Lokalen Speicher testen" } }, - "categories": { - "INFORMATION_GATHERING": "Informationsbeschaffung", - "CONFIGURATION_AND_DEPLOY_MANAGEMENT_TESTING": "Konfig- & Einsatzmanagement-Testing", - "IDENTITY_MANAGEMENT_TESTING": "Identitätsmanagement-Testing", - "AUTHENTICATION_TESTING": "Authentifizierungs-Testing", - "AUTHORIZATION_TESTING": "Autorisations-Testing", - "SESSION_MANAGEMENT_TESTING": "Sitzungsmanagement-Testing", - "INPUT_VALIDATION_TESTING": "Eingabevalidierungs-Testing", - "ERROR_HANDLING": "Fehlerbehandlung", - "CRYPTOGRAPHY": "Kryptographie", - "BUSINESS_LOGIC_TESTING": "Business-Logik-Testing", - "CLIENT_SIDE_TESTING": "Clientseitiges-Testing" + "objectives": { + "info": { + "001": "Ziel ist es zu verstehen, welche sensiblen Design- und Konfigurationsinformationen der Anwendung, des Systems oder der Organisation direkt (auf der Website der Organisation) oder indirekt (auf der Website eines Drittanbieters) offengelegt werden.\n\n Es gibt direkte und indirekte Elemente der Suchmaschinenerkennung und -aufklärung.\n Direkte Methoden beziehen sich auf das Durchsuchen der Indizes und der zugehörigen Inhalte aus Caches.\n Indirekte Methoden beziehen sich auf das Sammeln vertraulicher Design- und Konfigurationsinformationen durch das Durchsuchen von Foren, Newsgroups und Ausschreibungswebsites.\n\n Verwenden Sie eine Suchmaschine, um nach Folgendem zu suchen:\n• Netzwerkdiagramme und -konfigurationen\n• Archivierte Beiträge und E-Mails von Administratoren oder anderen wichtigen Mitarbeitern\n• Anmeldeverfahren und Benutzernamenformate\n• Benutzernamen und Passwörter\n• Inhalt der Fehlermeldung\n• Entwicklungs-, Test-, UAT- und Staging-Versionen der Website", + "002": "Das Ziel besteht darin, die Version und den Typ eines laufenden Webservers zu finden, um bekannte Schwachstellen und die geeigneten Exploits zu ermitteln, die während des Tests verwendet werden können.\n\n Webserver-Fingerprinting ist eine kritische Aufgabe für den Penetrationstester.\nDie Kenntnis der Version und des Typs eines laufenden Webservers ermöglicht es Testern, bekannte Schwachstellen und die geeigneten Exploits zu ermitteln, die während des Tests verwendet werden können.\n\n Es gibt heute mehrere verschiedene Anbieter und Versionen von Webservern auf dem Markt. Die Kenntnis des Typs des getesteten Webservers hilft erheblich beim Testprozess und kann auch den Verlauf des Tests verändern. Die einfachste und grundlegendste Art, einen Webserver zu identifizieren, besteht darin, sich das Serverfeld im HTTP-Antwortheader anzusehen.\n\n Indem der Tester weiß, wie jeder Webservertyp auf bestimmte Befehle reagiert, und diese Informationen in einer Fingerprint-Datenbank des Webservers speichert, kann ein Penetrationstester diese Befehle an den Webserver senden, die Antwort analysieren und sie mit der Datenbank bekannter Signaturen vergleichen.", + "003": "Das Ziel hier ist, die robots.txt-Datei auf Informationslecks des Verzeichnisses oder der Ordnerpfade der Webanwendung zu überprüfen.\n\n 1. Informationsverlust des Verzeichnisses oder der Ordnerpfade der Webanwendung.\n 2. Erstellen Sie die Liste der Verzeichnisse, die von Spiders, Robots oder Crawlern vermieden werden sollen.\n\n Darüber hinaus kann die Liste der Verzeichnisse, die von Spidern, Robots oder Crawlern vermieden werden sollen, auch als Abhängigkeit für Map execution paths durch die Anwendung erstellt werden.\n Webspider, Robots oder Crawler rufen eine Webseite ab und durchlaufen dann rekursiv Hyperlinks, um weitere Webinhalte abzurufen. Ihr akzeptiertes Verhalten wird durch das Robots Exclusion Protocol der robots.txt-Datei im Web-Root-Verzeichnis angegeben.", + "004": "Das Ziel besteht darin, die Anwendungen innerhalb des Gültigkeitsbereichs aufzuzählen, die auf einem Webserver vorhanden sind.\n\n Viele Anwendungen haben bekannte Schwachstellen und bekannte Angriffsstrategien, die ausgenutzt werden können, um eine Fernsteuerung zu erlangen oder Daten auszunutzen. Außerdem sind viele Anwendungen oft falsch konfiguriert oder werden nicht aktualisiert.\n Die Erkennung von Webanwendungen ist ein Prozess, der darauf abzielt, Webanwendungen in einer bestimmten Infrastruktur zu identifizieren. Letzteres wird normalerweise als eine Reihe von IP-Adressen (möglicherweise ein Netzblock) angegeben, kann aber auch aus einer Reihe symbolischer DNS-Namen oder einer Mischung aus beiden bestehen.", + "005": "Ziel ist es, Webseitenkommentare und Metadaten zu überprüfen, um die Anwendung besser zu verstehen und Informationslecks zu finden.\n\n HTML-Kommentare werden häufig von den Entwicklern verwendet, um Debugging-Informationen über die Anwendung einzufügen. Manchmal vergessen sie die Kommentare.\n\n Überprüfen Sie den HTML-Quellcode auf Kommentare mit vertraulichen Informationen, die dem Angreifer helfen können, mehr Einblick in die Anwendung zu gewinnen. Dies können SQL-Code, Benutzernamen und Passwörter, interne IP-Adressen oder Debugging-Informationen sein.", + "006": "Ziel ist es zu verstehen, wie Anfragen gebildet werden und typische Antworten der Anwendung.\n\n Die Aufzählung der Anwendung und ihrer Angriffsfläche ist ein wichtiger Vorläufer bevor gründliche Tests durchgeführt werden können, da es dem Tester ermöglicht, wahrscheinliche Schwachstellen zu identifizieren. Dies soll dazu beitragen, Bereiche innerhalb der Anwendung zu identifizieren und zu kartieren, die untersucht werden sollten, sobald die Aufzählung und Kartierung abgeschlossen sind.\n\n Achten Sie beim Durchlaufen der Anwendung besonders auf alle HTTP-Anforderungen (GET- und POST-Methoden, auch bekannt als Verben) sowie auf alle Parameter und Formularfelder, die an die Anwendung übergeben werden.\n Beachten Sie außerdem alle interessanten Parameter in der URL, den benutzerdefinierten Headern oder dem Text der Anfragen/Antworten und speichern Sie sie.\n Sobald jeder Bereich der Anwendung abgebildet ist, gehen Sie die Anwendung durch und testen Sie jeden der identifizierten Bereiche und machen Sie sich Notizen darüber, was funktioniert hat und was nicht.", + "007": "Ziel ist es, die Zielanwendung abzubilden und die wichtigsten Arbeitsabläufe zu verstehen.\n\n Bevor Sie mit Sicherheitstests beginnen, ist es von größter Bedeutung, die Struktur der Anwendung zu verstehen.\nEs gibt mehrere Möglichkeiten, an das Testen und Messen der Codeabdeckung heranzugehen:\n\n 1. Pfad:\n Testen Sie jeden der Pfade durch eine Anwendung, die kombinatorische und Grenzwertanalysetests für jeden Entscheidungspfad umfasst. Während dieser Ansatz Gründlichkeit bietet, wächst die Anzahl der testbaren Pfade exponentiell mit jedem Entscheidungszweig.\n\n 2. Datenfluss (oder Taint-Analyse):\n Testet die Zuweisung von Variablen durch externe Interaktion (normalerweise Benutzer).\n Konzentriert sich auf die Abbildung des Flusses, der Transformation und der Verwendung von Daten in einer Anwendung.\n\n 3. Rennen:\n Testet mehrere gleichzeitige Instanzen der Anwendung, die dieselben Daten manipulieren.", + "008": "Ziel ist es, den Typ des verwendeten Web-Frameworks zu definieren, um ein besseres Verständnis der Sicherheitstestmethodik zu erlangen.\n\n Die Art des Frameworks zu kennen, kann automatisch einen großen Vorteil bringen, wenn ein solches Framework bereits vom Penetrationstester getestet wurde. Nicht nur die bekannten Schwachstellen in ungepatchten Versionen, sondern auch spezifische Fehlkonfigurationen im Framework und der bekannten Dateistruktur machen den Fingerprinting-Prozess so wichtig.\n\n Es gibt mehrere gängige Orte, an denen Sie nachsehen können, um den aktuellen Rahmen zu definieren:\n• HTTP-Header\n• Cookies\n• HTML-Quellcode\n• Bestimmte Dateien und Ordner", + "009": "Ziel ist es, die Webanwendung und -version zu identifizieren, um bekannte Schwachstellen und die geeigneten Exploits zu ermitteln, die während des Tests verwendet werden können.\n\n Bei der großen Anzahl von Free- und Open-Source-Softwareprojekten, die weltweit aktiv entwickelt und eingesetzt werden, ist es sehr wahrscheinlich, dass ein Anwendungssicherheitstest auf eine Zielseite trifft, die ganz oder teilweise von diesen bekannten Anwendungen abhängig ist (z. B. Wordpress, phpBB, Mediawiki usw.).\n\nDie Kenntnis der zu testenden Webanwendungskomponenten hilft erheblich beim Testprozess.\nDiese wohlbekannten Webanwendungen haben bekannte HTML-Kopfzeilen, Cookies und Verzeichnisstrukturen, die aufgezählt werden können, um die Anwendung zu identifizieren.", + "010": "Die Anwendungsarchitektur muss durch einige Tests abgebildet werden, um festzustellen, welche verschiedenen Komponenten zum Erstellen der Webanwendung verwendet werden.\n\n In kleinen Setups, wie z. B. einer einfachen CGI-basierten Anwendung, kann ein einzelner Server verwendet werden, auf dem der Webserver ausgeführt wird, der die C-, Perl- oder Shell-CGIs-Anwendung und möglicherweise auch den Authentifizierungsmechanismus ausführt.\n Bei komplexeren Setups können mehrere Server beteiligt sein. Dazu können ein Reverse-Proxy, ein Frontend-Webserver, ein Anwendungsserver und ein Datenbankserver oder LDAP-Server gehören.\nJeder dieser Server wird für unterschiedliche Zwecke verwendet und kann sogar in verschiedene Netzwerke mit Firewalls dazwischen (DMZs) unterteilt sein.\n\n Darüber hinaus ist das Verständnis der bereitgestellten Konfiguration des Servers, auf dem die Webanwendung gehostet wird, fast so wichtig wie das Testen der Anwendungssicherheit selbst." + }, + "config": { + "001": "Die intrinsische Komplexität einer vernetzten und heterogenen Webserver-Infrastruktur, die Hunderte von Webanwendungen umfassen kann, macht das Konfigurationsmanagement und die Überprüfung zu einem grundlegenden Schritt beim Testen und Bereitstellen jeder einzelnen Anwendung. Es braucht nur eine einzige Schwachstelle, um die Sicherheit der gesamten Infrastruktur zu untergraben. Um diese Probleme anzugehen, ist es von größter Bedeutung, eine gründliche Überprüfung der Konfiguration und bekannter Sicherheitsprobleme durchzuführen.\n\nZum Testen der Konfigurationsmanagement-Infrastruktur müssen die folgenden Schritte ausgeführt werden:\n\nSchritt 1:\n Die verschiedenen Elemente, aus denen die Infrastruktur besteht, müssen bestimmt werden, um zu verstehen, wie sie mit einer Webanwendung interagieren und wie sie sich auf deren Sicherheit auswirken.\n\nSchritt 2:\n Alle Elemente der Infrastruktur müssen überprüft werden, um sicherzustellen, dass sie keine bekannten Schwachstellen enthalten.\n\nSchritt 3:\n Es muss eine Überprüfung der Verwaltungsinstrumente durchgeführt werden, die zur Pflege aller verschiedenen Elemente verwendet werden.\n\nSchritt 4:\n Die Authentifizierungssysteme müssen überprüft werden, um sicherzustellen, dass sie die Anforderungen der Anwendung erfüllen und nicht von externen Benutzern manipuliert werden können, um den Zugriff zu nutzen.\n\nSchritt 5:\n Eine Liste definierter Ports, die für die Anwendung erforderlich sind, sollte gepflegt und unter Änderungskontrolle gehalten werden.", + "002": "Die Überprüfung und das Testen der Konfiguration ist eine kritische Aufgabe beim Erstellen und Verwalten einer Architektur. Dies liegt daran, dass viele verschiedene Systeme normalerweise mit generischen Konfigurationen bereitgestellt werden, die möglicherweise nicht für die Aufgabe geeignet sind, die sie an dem spezifischen Standort ausführen, an dem sie installiert sind.\n\n Während die typische Web- und Anwendungsserverinstallation viele Funktionen (wie Anwendungsbeispiele, Dokumentation, Testseiten) enthält, sollte das, was nicht unbedingt erforderlich ist, vor der Bereitstellung entfernt werden, um eine Ausnutzung nach der Installation zu vermeiden.\n\nCGI-Scanner enthalten eine detaillierte Liste bekannter Dateien und Verzeichnisbeispiele, die von verschiedenen Web- oder Anwendungsservern bereitgestellt werden.\nAußerdem enthalten Ereignisprotokolle oft Daten, die für einen Angreifer nützlich sind (Information Leakage) oder direkt in Exploits verwendet werden können.", + "003": "Dateierweiterungen werden häufig in Webservern verwendet, um einfach zu bestimmen, welche Technologien, Sprachen und Plugins verwendet werden müssen, um die Webanforderung zu erfüllen.\nObwohl dieses Verhalten mit RFCs und Webstandards übereinstimmt, liefert die Verwendung von Standarddateierweiterungen dem Penetrationstester nützliche Informationen über die zugrunde liegenden Technologien, die in einer Web-Appliance verwendet werden.\n\n Die Feststellung, wie Webserver Anfragen verarbeiten, die Dateien mit unterschiedlichen Erweiterungen entsprechen, kann helfen, das Verhalten von Webservern in Abhängigkeit von der Art der Dateien, auf die zugegriffen wird, zu verstehen.\n\nDie folgenden Dateierweiterungen sollten niemals von einem Webserver zurückgegeben werden, da sie sich auf Dateien beziehen, die möglicherweise vertrauliche Informationen enthalten:\n • .asa \n• .inc\n\n Die folgenden Dateierweiterungen beziehen sich auf Dateien, die beim Zugriff entweder angezeigt oder vom Browser heruntergeladen werden.\n Daher müssen Dateien mit diesen Erweiterungen überprüft werden, um sicherzustellen, dass sie tatsächlich geliefert werden sollen:\n• .zip, .tar, .gz, .tgz, .rar, ...: (Komprimierte) Archivdateien\n• .java: Kein Grund, Zugriff auf Java-Quelldateien zu gewähren\n• .txt: Textdateien\n• .pdf: PDF-Dokumente\n• .doc, .rtf, .xls, .ppt, ...: Office-Dokumente\n• .bak, .old und andere Erweiterungen, die auf Sicherungsdateien hinweisen\n\n Um Dateien mit bestimmten Erweiterungen zu identifizieren, kann eine Mischung von Techniken eingesetzt werden.\nDiese Techniken können Vulnerability Scanners, Spidering- und Mirroring-Tools, die manuelle Überprüfung der Anwendung oder Abfragen von Suchmaschinen umfassen.", + "004": "Eine wichtige Schwachstellenquelle sind Dateien, die nichts mit der Anwendung zu tun haben, aber als Folge der Bearbeitung von Anwendungsdateien oder nach dem Erstellen von Sicherungskopien im laufenden Betrieb oder durch das Belassen alter Dateien im Webbaum oder ohne Referenz erstellt wurden Dateien.\n\n Theoretisch sollte die Untersuchung von Hand durchgeführt werden, um gründlich zu sein. Da jedoch in den meisten Fällen Kopien von Dateien oder Backup-Dateien unter Verwendung der gleichen Namenskonventionen erstellt werden, kann die Suche einfach per Skript durchgeführt werden.", + "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." + }, + "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.", + "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." + }, + "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.", + "002": "Häufig sind Anwendungen nach der Installation nicht ordnungsgemäß konfiguriert, und die für die anfängliche Authentifizierung und Konfiguration bereitgestellten Standardanmeldeinformationen werden nie geändert.\n\n Wenn Sie eine Anwendungsschnittstelle identifiziert haben, beispielsweise eine Cisco-Router-Webschnittstelle oder ein Weblogic-Administratorportal, prüfen Sie, ob die bekannten Benutzernamen und Kennwörter für diese Geräte nicht zu einer erfolgreichen Authentifizierung führen. Dazu können Sie die Dokumentation des Herstellers konsultieren oder, viel einfacher, allgemeine Anmeldeinformationen mithilfe einer Suchmaschine oder einer der im Abschnitt „Referenz“ aufgeführten Websites oder Tools finden.\n\n Wenn wir mit Anwendungen konfrontiert werden, für die wir keine Liste mit Standard- und allgemeinen Benutzerkonten haben, können wir versuchen, gültige Standardanmeldeinformationen zu erraten.\n Viele Anwendungen haben ausführliche Fehlermeldungen, die die Site-Benutzer über die Gültigkeit der eingegebenen Benutzernamen informieren. Diese Informationen sind beim Testen auf standardmäßige oder erratbare Benutzerkonten hilfreich.\n\nDa diese Arten von Standardanmeldeinformationen häufig an Administratorkonten gebunden sind, können Sie zunächst die folgenden Benutzernamen ausprobieren: \n• admin \n• administrator \n• root \n• system \n• guest \n• operator \n• super", + "003": "Kontosperrmechanismen werden verwendet, um Brute-Force-Angriffe zum Erraten von Passwörtern abzuschwächen. Konten werden in der Regel nach 3 bis 5 erfolglosen Anmeldeversuchen gesperrt und können erst nach einem festgelegten Zeitraum über einen Self-Service-Entsperrmechanismus oder den Eingriff eines Administrators entsperrt werden.\n\n Um die Stärke von Sperrmechanismen zu testen, benötigen Sie in der Regel Zugriff auf ein Konto, das Sie sperren möchten oder sich leisten können:\n\n Schritt 1:\n Bewerten Sie die Fähigkeit des Kontosperrmechanismus, das Erraten von Brute-Force-Passwörtern zu mindern.\n\n Schritt 2:\nBewerten Sie die Widerstandsfähigkeit des Entsperrmechanismus gegen das unbefugte Entsperren von Konten.\n\n Ohne einen starken Sperrmechanismus ist die Anwendung möglicherweise anfällig für Brute-Force-Angriffe. Nach einem erfolgreichen Brute-Force-Angriff könnte ein böswilliger Benutzer Zugriff auf Folgendes haben:\n• Vertrauliche Informationen oder Daten\n• Administratoroberflächen\n• Möglichkeiten für weitere Angriffe", + "004": "Während die meisten Anwendungen eine Authentifizierung erfordern, um Zugriff auf private Informationen zu erhalten oder Aufgaben auszuführen, ist nicht jede Authentifizierungsmethode in der Lage, angemessene Sicherheit zu bieten.\n\n Es gibt mehrere Methoden zum Umgehen des Authentifizierungsschemas, das von einer Webanwendung verwendet wird:\n• Direkter Seitenaufruf (Forced Browsing)\n• Parameteränderung\n• Session-ID-Vorhersage\n• SQL-Injektion", + "005": "Browser fragen einen Benutzer manchmal, ob er sich das soeben eingegebene Passwort merken möchte.\n\n Das Speichern von Passwörtern im Browser ist nicht nur für Endbenutzer, sondern auch für Angreifer praktisch. Wenn ein Angreifer Zugriff auf den Browser des Opfers erlangen kann (z. B. XSS-Angriff), kann er die gespeicherten Passwörter abrufen.\n Wenn benutzerdefinierte „Remember Me“-Funktionen eingerichtet werden, können außerdem Schwachstellen bei der Speicherung des Tokens auf dem Client-PC die Passwörter der Benutzer offenlegen.\n\n Stellen Sie sicher, dass keine Zugangsdaten im Klartext gespeichert oder in verschlüsselter oder verschlüsselter Form in Cookies leicht abrufbar sind:\n• Suchen Sie nach Passwörtern, die in Cookies gespeichert sind\n• Untersuchen Sie den Hashing-Mechanismus\n• Stellen Sie sicher, dass Anmeldeinformationen nur während der Anmeldung gesendet werden\n• Berücksichtigen Sie sensible Formularfelder", + "006": "Browser können Informationen für Caching- und Verlaufszwecke speichern. Caching dient der Leistungssteigerung, sodass zuvor angezeigte Informationen nicht erneut heruntergeladen werden müssen.\n Wenn dem Benutzer sensible Informationen angezeigt werden, können diese Informationen zu Cache- oder Verlaufszwecken gespeichert und daher durch Überprüfen des Cache des Browsers oder durch einfaches Drücken der Schaltfläche „Zurück“ des Browsers abgerufen werden.\n\n Technisch gesehen ist die Schaltfläche „Zurück“ ein Verlauf und kein Cache. Der Cache und der Verlauf sind zwei verschiedene Entitäten. Sie teilen jedoch die gleiche Schwäche, zuvor angezeigte sensible Informationen zu präsentieren.\n\nDie Schaltfläche „Zurück“ kann daran gehindert werden, sensible Daten anzuzeigen.\nDies kann erfolgen durch:\n• Bereitstellung der Seite über HTTPS.\n• Einstellung Cache-Control: must-re-validate", + "007": "Der am weitesten verbreitete und am einfachsten zu verwaltende Authentifizierungsmechanismus ist ein statisches Passwort. Es wird bedauert, dass die gängigsten Passwörter immer noch sind: 123456, Passwort und qwerty.\n\nBestimmen Sie den Widerstand der Anwendung gegen Brute-Force-Passworterraten mithilfe verfügbarer Passwortwörterbücher, indem Sie die Anforderungen an Länge, Komplexität, Wiederverwendung und Alterung von Passwörtern bewerten.\n\n Schritt 1:\n Welche Zeichen sind in einem Passwort erlaubt und welche verboten?\nMuss der Benutzer Zeichen aus unterschiedlichen Zeichensätzen wie Klein- und Großbuchstaben, Ziffern und Sonderzeichen verwenden?\n\n Schritt 2:\n Wie oft kann ein Benutzer sein Passwort ändern?\nWie schnell kann ein Benutzer sein Passwort nach einer vorherigen Änderung ändern?\n Benutzer können die Anforderungen des Passwortverlaufs umgehen, indem sie ihr Passwort fünfmal hintereinander ändern.\n\n Schritt 3:\n Wann muss ein Benutzer sein Passwort ändern?\nNach 90 Tagen?\nNach Kontosperrung wegen übermäßiger Anmeldeversuche?\n\n Schritt 4:\n Wie oft kann ein Benutzer ein Passwort wiederverwenden?\n Verwaltet die Anwendung einen Verlauf der zuvor verwendeten 8 Passwörter des Benutzers?\n\n Schritt 5:\n Wie unterschiedlich muss das nächste Passwort vom letzten Passwort sein?\n\n Schritt 6:\nWird der Benutzer daran gehindert, seinen Benutzernamen oder andere Kontoinformationen (z. B. Vor- oder Nachname) im Passwort zu verwenden?", + "008": "Oft als „geheime“ Fragen und Antworten bezeichnet, werden Sicherheitsfragen und -antworten oft verwendet, um vergessene Passwörter wiederherzustellen, oder als zusätzliche Sicherheit zusätzlich zum Passwort.\n\n Sie werden normalerweise bei der Kontoerstellung generiert und erfordern, dass der Benutzer aus einigen vorgenerierten Fragen eine Auswahl trifft und eine entsprechende Antwort liefert. Sie können dem Benutzer ermöglichen, seine eigenen Frage-Antwort-Paare zu generieren.\n Beide Methoden sind anfällig für Unsicherheiten. Im Idealfall sollten Sicherheitsfragen Antworten generieren, die nur dem Benutzer bekannt und nicht erratbar oder auffindbar sind.\n\n Der Schlüssel zum erfolgreichen Ausnutzen und Umgehen eines schwachen Sicherheitsfrageschemas besteht darin, eine Frage oder eine Reihe von Fragen zu finden, die die Möglichkeit bieten, die Antworten leicht zu finden. \n\n Schritt 1:\nVersuchen Sie, eine Liste mit Sicherheitsfragen zu erhalten, indem Sie ein neues Konto erstellen oder dem „Ich erinnere mich nicht an mein Passwort“-Prozess folgen.\n\n Schritt 2:\n Versuchen Sie, Sicherheitsfragen zu erstellen, indem Sie ein neues Konto erstellen oder die Kennwortwiederherstellungseigenschaften Ihres vorhandenen Kontos konfigurieren.\nWenn das System dem Benutzer erlaubt, seine eigenen Sicherheitsfragen zu generieren, ist es anfällig dafür, dass unsichere Fragen erstellt werden.\n\n Schritt 3:\n Stellen Sie fest, ob eine Reihe falsch eingegebener Sicherheitsantworten einen Sperrmechanismus auslösen.", + "009": "Die Funktion zum Ändern und Zurücksetzen von Kennwörtern einer Anwendung ist ein Self-Service-Mechanismus zum Ändern oder Zurücksetzen von Kennwörtern für Benutzer.\n Dieser Self-Service-Mechanismus ermöglicht es Benutzern, ihr Passwort schnell zu ändern oder zurückzusetzen, ohne dass ein Administrator eingreifen muss.\n\n Schritt 1:\n Bestimmen Sie den Widerstand der Anwendung gegen die Subversion des Kontoänderungsprozesses, der es jemandem ermöglicht, das Kennwort eines Kontos zu ändern.\n\n Schritt 2:\nBestimmen Sie die Widerstandsfähigkeit der Funktion zum Zurücksetzen von Passwörtern gegen Erraten oder Umgehen.\n\n Sowohl für die Passwortänderung als auch für das Zurücksetzen des Passworts ist es wichtig, dies zu überprüfen.\n\n.. wenn andere Benutzer als Administratoren Kennwörter für andere Konten als ihre eigenen ändern oder zurücksetzen können.\n.. wenn Benutzer den Prozess zum Ändern oder Zurücksetzen von Passwörtern manipulieren oder untergraben können.\n.. wenn der Prozess zum Ändern oder Zurücksetzen des Passworts anfällig für CSRF ist.", + "010": "Auch wenn die primären Authentifizierungsmechanismen keine Schwachstellen enthalten, kann es sein, dass Schwachstellen in alternativen legitimen Benutzerkanälen für die Authentifizierung für dieselben Benutzerkonten vorhanden sind.\n\n Es sollten Tests durchgeführt werden, um alternative Kanäle zu identifizieren und, vorbehaltlich des Testumfangs, Schwachstellen zu identifizieren.\n Einige dieser Kanäle können selbst separate Webanwendungen sein, die unterschiedliche Hostnamen oder Pfade verwenden. Zum Beispiel:\n• Standard-Website\n• Mobile Website\n• Zugänglichkeitsoptimierte Website\n• Parallele Websites, die dieselben Benutzerkonten verwenden\n• Entwicklung, UAT und Versionen der Standard-Website\n\n Es könnten aber auch andere Arten von Anwendungen oder Geschäftsprozessen sein:\n• App für mobile Geräte\n• Desktopanwendung\n• Call-Center-Betreiber\n• Interaktive Sprachantwort oder Telefonbaumsysteme" + }, + "authz": { + "001": "Viele Webanwendungen verwenden und verwalten Dateien im Rahmen ihres täglichen Betriebs. Durch die Verwendung von Eingabevalidierungsmethoden, die nicht gut entwickelt oder eingesetzt wurden, könnte ein Angreifer das System ausnutzen, um Dateien zu lesen oder zu schreiben, auf die nicht zugegriffen werden soll. In bestimmten Situationen kann es möglich sein, beliebigen Code oder Systembefehle auszuführen.\n\n Bei Webservern und Webanwendungen tritt diese Art von Problem bei Path Traversal/File Include-Angriffen auf. Während einer Bewertung müssen Tester zwei verschiedene Phasen durchführen, um Path Traversal und File Include-Fehler zu entdecken:\n\n Stufe 1:\n Input Vectors Enumeration (eine systematische Auswertung jedes Input-Vektors)\n\n Stufe 2:\n Testtechniken (eine methodische Bewertung jeder Angriffstechnik, die von einem Angreifer verwendet wird, um die Schwachstelle auszunutzen)\n\n Die nächste Testphase besteht in der Analyse der in der Webanwendung vorhandenen Eingabevalidierungsfunktionen. Unter Verwendung des vorherigen Beispiels lädt die dynamische Seite namens getUserProfile.jsp statische Informationen aus einer Datei und zeigt Benutzern den Inhalt an. Ein Angreifer könnte die böswillige Zeichenfolge „../../../../etc/passwd“ einfügen, um die Passwort-Hash-Datei einzufügen.\n Es ist ein häufiger Fehler von Entwicklern, nicht jede Form der Codierung zu erwarten und daher nur grundlegende codierte Inhalte zu validieren. Wenn die Testzeichenfolge zunächst nicht erfolgreich ist, versuchen Sie es mit einem anderen Codierungsschema.", + "002": "Diese Art von Test konzentriert sich darauf, zu überprüfen, wie das Autorisierungsschema für jede Rolle oder jedes Privileg implementiert wurde, um Zugriff auf reservierte Funktionen und Ressourcen zu erhalten.\n\nFür jede spezifische Rolle, die der Tester während der Bewertung innehat, für jede Funktion und Anforderung, die die Anwendung während der Phase nach der Authentifizierung ausführt, muss Folgendes überprüft werden:\n • Ist es möglich, auf diese Ressource zuzugreifen, selbst wenn der Benutzer nicht authentifiziert ist?\n • Kann nach dem Abmelden auf diese Ressource zugegriffen werden?\n • Ist es möglich, auf Funktionen und Ressourcen zuzugreifen, die einem Benutzer mit einer anderen Rolle oder Berechtigung zugänglich sein sollten?\n\n Versuchen Sie, als Administrator auf die Anwendung zuzugreifen, und verfolgen Sie alle Verwaltungsfunktionen:\n • Ist der Zugriff auf Verwaltungsfunktionen auch dann möglich, wenn der Tester als Benutzer mit Standardrechten angemeldet ist?\n• Ist es möglich, diese Verwaltungsfunktionen als Benutzer mit einer anderen Rolle zu verwenden, und wem sollte diese Aktion verweigert werden?", + "003": "Eine Rechteausweitung tritt auf, wenn ein Benutzer Zugriff auf mehr Ressourcen oder Funktionen erhält, als ihm normalerweise gestattet sind.\n\n Während dieser Phase sollte der Tester sicherstellen, dass es einem Benutzer nicht möglich ist, seine Berechtigungen oder Rollen innerhalb der Anwendung auf eine Weise zu ändern, die Angriffe zur Rechteausweitung ermöglichen könnte.\n Der Grad der Eskalation hängt davon ab, welche Privilegien der Angreifer besitzen darf und welche Privilegien bei einem erfolgreichen Exploit erworben werden können.\n\n In jedem Teil der Anwendung, in dem ein Benutzer Informationen in der Datenbank erstellen (z. B. eine Zahlung vornehmen oder eine Nachricht senden), Informationen empfangen (Kontoauszug, Bestelldetails usw.) oder Informationen löschen (Benutzer löschen, Nachrichten usw.), ist es notwendig, diese Funktionalität aufzuzeichnen.\n Versuchen Sie, als anderer Benutzer auf solche Funktionen zuzugreifen, um zu überprüfen, ob es möglich ist, auf eine Funktion zuzugreifen, die aufgrund der Rolle/Berechtigung des Benutzers nicht zulässig sein sollte.", + "004": "Unsichere direkte Objektverweise treten auf, wenn eine Anwendung basierend auf Benutzereingaben direkten Zugriff auf Objekte bereitstellt.\n Durch diese Schwachstelle können Angreifer die Autorisierung umgehen und direkt auf Ressourcen im System zugreifen, beispielsweise Datenbankeinträge oder Dateien.\n\n Unsichere direkte Objektreferenzen ermöglichen es Angreifern, die Autorisierung zu umgehen und direkt auf Ressourcen zuzugreifen, indem sie den Wert eines Parameters ändern, der verwendet wird, um direkt auf ein Objekt zu verweisen.\n\n Um diese Schwachstelle zu testen, muss der Tester zunächst alle Stellen in der Anwendung abbilden, an denen Benutzereingaben verwendet werden, um direkt auf Objekte zu verweisen.\n Der beste Weg, um auf direkte Objektreferenzen zu testen, wäre, mindestens zwei (häufig mehr) Benutzer zu haben, um verschiedene Objekte und Funktionen im Besitz abzudecken.\n Indem er mehrere Benutzer hat, spart der Tester wertvolle Testzeit beim Erraten unterschiedlicher Objektnamen, da er versuchen kann, auf Objekte zuzugreifen, die dem anderen Benutzer gehören." + }, + "sess": { + "001": "Um eine kontinuierliche Authentifizierung für jede Seite einer Website oder eines Dienstes zu vermeiden, implementieren Webanwendungen verschiedene Mechanismen, um Anmeldeinformationen für einen festgelegten Zeitraum zu speichern und zu validieren.\n Diese Mechanismen werden als Sitzungsverwaltung bezeichnet.\n\n In diesem Test möchte der Tester überprüfen, ob Cookies und andere Sitzungstoken auf sichere und unvorhersehbare Weise erstellt werden. Ein Angreifer, der in der Lage ist, ein schwaches Cookie vorherzusagen und zu fälschen, kann leicht die Sitzungen legitimer Benutzer kapern.\n Aufgrund der Bedeutung der von ihnen gespeicherten Daten sind Cookies daher für die Gesamtsicherheit der Anwendung von entscheidender Bedeutung. Bei diesem Test muss der Tester überprüfen, ob die an Clients ausgegebenen Cookies einer Vielzahl von Angriffen widerstehen können, die darauf abzielen, die Sitzungen legitimer Benutzer und die Anwendung selbst zu stören.\n\n Normalerweise sind die Hauptschritte des Angriffsmusters die folgenden:\n• Cookie-Sammlung\n• Cookie-Reverse-Engineering\n• Cookie-Manipulation\n\n Ein weiteres Angriffsmuster besteht darin, einen Cookie zum Überlaufen zu bringen. Genau genommen hat dieser Angriff einen anderen Charakter, da Tester hier nicht versuchen, ein vollkommen gültiges Cookie nachzubilden. Stattdessen besteht das Ziel darin, einen Speicherbereich zum Überlaufen zu bringen und dadurch das korrekte Verhalten der Anwendung zu stören.", + "002": "Cookies sind oft ein wichtiger Angriffsvektor für böswillige Benutzer, und die Anwendung sollte immer die gebotene Sorgfalt walten lassen, um Cookies zu schützen. In diesem Abschnitt wird erläutert, wie eine Anwendung beim Zuweisen von Cookies die erforderlichen Vorkehrungen treffen und testen kann, ob diese Attribute korrekt konfiguriert wurden.\n\n Aufgrund der sensiblen Natur von Informationen in Cookies werden diese typischerweise kodiert oder verschlüsselt, um die darin enthaltenen Informationen zu schützen.\n Sobald der Tester verstanden hat, wie Cookies gesetzt werden, wann sie gesetzt werden, wofür sie verwendet werden, warum sie verwendet werden und welche Bedeutung sie haben, sollten sie sich ansehen, welche Attribute für ein Cookie gesetzt werden können und wie sie getestet werden wenn sie sicher sind.\n\nDurch die Verwendung eines abfangenden Proxys oder eines Browser-Plug-ins zum Abfangen von Datenverkehr fangen Sie alle Antworten ab, bei denen ein Cookie von der Anwendung gesetzt wird (unter Verwendung der Set-cookie-Anweisung), und untersuchen Sie das Cookie auf Folgendes:\n• Secure-Attribut\n• HttpOnly-Attribut\n• Domain-Attribut\n• Path-Attribut\n• Expires-Attribut", + "003": "Wenn eine Anwendung ihre Sitzungscookies nach einer erfolgreichen Benutzerauthentifizierung nicht erneuert, könnte es möglich sein, eine Schwachstelle bei der Sitzungsfixierung zu finden und einen Benutzer zu zwingen, ein dem Angreifer bekanntes Cookie zu verwenden. In diesem Fall könnte ein Angreifer die Benutzersitzung stehlen (Session-Hijacking).\n\n Sicherheitslücken bei der Sitzungsfixierung treten auf, wenn..\n ... eine Webanwendung einen Benutzer authentifiziert, ohne zuerst die vorhandene Sitzungs-ID ungültig zu machen, wodurch die bereits mit dem Benutzer verknüpfte Sitzungs-ID weiterhin verwendet wird\n.. ein Angreifer in der Lage ist, einem Benutzer eine bekannte Sitzungs-ID aufzuzwingen, sodass der Angreifer nach der Authentifizierung des Benutzers Zugriff auf die authentifizierte Sitzung hat.\n\n Beim generischen Exploit von Sicherheitslücken zur Sitzungsfixierung erstellt ein Angreifer eine neue Sitzung in einer Webanwendung und zeichnet die zugehörige Sitzungskennung auf. Der Angreifer veranlasst dann das Opfer, sich mit derselben Sitzungskennung beim Server zu authentifizieren, wodurch der Angreifer während der aktiven Sitzung Zugriff auf das Konto des Benutzers erhält.", + "004": "Die Sitzungstoken (Cookie, Sitzungs-ID, verborgenes Feld) ermöglichen es einem Angreifer normalerweise, sich als Opfer auszugeben und unrechtmäßig auf die Anwendung zuzugreifen, wenn sie offengelegt werden. Es ist wichtig, dass sie jederzeit vor Abhören geschützt sind, insbesondere während der Übertragung zwischen dem Client-Browser und den Anwendungsservern.\n\n Über einen persönlichen Proxy kann zu jeder Anfrage und Antwort Folgendes festgestellt werden:\n • Verwendetes Protokoll (z. B. HTTP vs. HTTPS)\n • HTTP-Header\n • Nachrichtentext (z. B. POST oder Seiteninhalt)\n\n Schutz vor Lauschangriffen wird oft durch SSL-Verschlüsselung bereitgestellt, kann aber auch andere Tunnel oder Verschlüsselung beinhalten. Wenn die Sitzungs-ID von einem Angreifer der Anwendung präsentiert werden könnte, um sich Zugriff zu verschaffen, muss sie während der Übertragung geschützt werden, um dieses Risiko zu mindern. Daher sollte sichergestellt werden, dass die Verschlüsselung für alle Anfragen oder Antworten, bei denen die Sitzungs-ID übergeben wird, sowohl standardmäßig als auch durchgesetzt wird, unabhängig vom verwendeten Mechanismus.\n\n Jedes Mal, wenn die Authentifizierung erfolgreich ist, sollte der Benutzer Folgendes erwarten:\n• Ein anderes Sitzungstoken\n• Ein Token, das für jede HTTP-Anforderung über einen verschlüsselten Kanal gesendet wird", + "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." + }, + "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 „ an die betroffene Seiten-URL anhängen, was bei Ausführung das Warnfeld anzeigen würde. In diesem Fall würde der angehängte Code nicht an den Server gesendet, da alles nach dem #-Zeichen vom Browser nicht als Teil der Abfrage, sondern als Fragment behandelt wird.\n\n Testen auf DOM-basierte XSS-Schwachstellen:\n Blackbox-Tests für DOM-basiertes XSS werden normalerweise nicht durchgeführt, da der Zugriff auf den Quellcode immer verfügbar ist, da er zur Ausführung an den Client gesendet werden muss.\n Viele Websites verlassen sich auf große Funktionsbibliotheken, die sich oft über Hunderttausende von Codezeilen erstrecken und nicht selbst entwickelt wurden. In diesen Fällen wird das Top-Down-Testen oft zur einzig wirklich praktikablen Option.\n Dasselbe gilt auch für Top-Down-Tests, wenn die Eingaben oder deren Fehlen nicht von vornherein identifiziert werden. Benutzereingaben erfolgen in zwei Hauptformen:\n • Eingaben, die vom Server auf eine Weise auf die Seite geschrieben werden, die kein direktes XSS zulässt\n • Von clientseitigen JavaScript-Objekten erhaltene Eingaben\n\n Automatisiertes Testen hat nur sehr begrenzten Erfolg beim Identifizieren und Validieren von DOM-basiertem XSS, da es XSS normalerweise identifiziert, indem es eine bestimmte Nutzlast sendet und versucht, es in der Serverantwort zu beobachten.\n Daher sollten manuelle Tests durchgeführt werden, die durch Untersuchen von Bereichen im Code durchgeführt werden können, in denen auf Parameter verwiesen wird, die für einen Angreifer nützlich sein können.", + "002": "Eine JavaScript-Injection-Schwachstelle ist eine Unterart von Cross Site Scripting (XSS), bei der beliebiger JavaScript-Code injiziert werden kann, der von der Anwendung im Browser des Opfers ausgeführt wird.\n Diese Sicherheitsanfälligkeit kann viele Konsequenzen haben, wie die Offenlegung von Sitzungscookies eines Benutzers, die verwendet werden könnten, um sich als das Opfer auszugeben, oder allgemeiner kann es dem Angreifer ermöglichen, den von den Opfern gesehenen Seiteninhalt oder das Anwendungsverhalten zu ändern.\n\n Eine solche Schwachstelle tritt auf, wenn der Anwendung eine ordnungsgemäße vom Benutzer bereitgestellte Eingabe- und Ausgabevalidierung fehlt. JavaScript wird verwendet, um Webseiten dynamisch zu füllen, diese Injektion erfolgt während dieser Inhaltsverarbeitungsphase und wirkt sich folglich auf das Opfer aus.\n Wenn Sie versuchen, diese Art von Problemen auszunutzen, bedenken Sie, dass einige Zeichen von verschiedenen Browsern unterschiedlich behandelt werden.", + "003": "HTML-Injektion ist eine Art von Injektionsproblem, das auftritt, wenn a\nDer Benutzer kann einen Eingabepunkt steuern und beliebigen HTML-Code in eine anfällige Webseite einfügen.\nDiese Schwachstelle kann viele Konsequenzen haben, wie z. B. die Offenlegung\nvon Sitzungscookies eines Benutzers, die verwendet werden könnten, um sich als das auszugeben\nOpfer, oder allgemeiner kann es dem Angreifer ermöglichen, die zu ändern\nSeiteninhalte, die von den Opfern gesehen wurden.\n\n Diese Sicherheitsanfälligkeit tritt auf, wenn die Benutzereingabe nicht ordnungsgemäß bereinigt und die Ausgabe nicht codiert ist. Eine Injektion ermöglicht es dem Angreifer, eine bösartige HTML-Seite an ein Opfer zu senden. Der angegriffene Browser ist nicht in der Lage, die legitimen von den bösartigen Teilen zu unterscheiden (zu vertrauen) und wird folglich alle im Opferkontext als legitim analysieren und ausführen.\n\n Es gibt eine breite Palette von Methoden und Attributen, die zum Rendern von HTML-Inhalten verwendet werden können. Wenn diese Methoden mit einer nicht vertrauenswürdigen Eingabe versehen sind, besteht ein hohes XSS-Risiko.\n Bösartiger HTML-Code könnte beispielsweise über innerHTML eingeschleust werden, das verwendet wird, um vom Benutzer eingefügten HTML-Code wiederzugeben. Eine unsachgemäße Verwendung dieser Eigenschaft bedeutet mangelnde Bereinigung durch nicht vertrauenswürdige Eingaben und fehlende Ausgabecodierung.\n Wenn Zeichenfolgen nicht korrekt bereinigt werden, kann das Problem zu einer XSS-basierten HTML-Injektion führen.\n Eine andere Methode könnte document.write() sein.\n\nWenn Sie versuchen, diese Art von Problemen auszunutzen, bedenken Sie, dass einige Zeichen von verschiedenen Browsern unterschiedlich behandelt werden.", + "004": "Die clientseitige URL-Umleitung, auch bekannt als offene Umleitung, ist ein Eingabevalidierungsfehler, der auftritt, wenn eine Anwendung eine benutzergesteuerte Eingabe akzeptiert, die einen Link angibt, der zu einer externen URL führt, die bösartig sein könnte.\nDiese Art von Schwachstelle könnte verwendet werden, um einen Phishing-Angriff durchzuführen oder ein Opfer auf eine infizierte Seite umzuleiten.\n\nDiese Schwachstelle tritt auf, wenn eine Anwendung nicht vertrauenswürdige Eingaben akzeptiert, die einen URL-Wert enthalten, ohne sie zu bereinigen. Dieser URL-Wert könnte dazu führen, dass die Webanwendung den Benutzer auf eine andere Seite umleitet, beispielsweise eine bösartige Seite, die vom Angreifer kontrolliert wird.\n\n Durch das Ändern einer nicht vertrauenswürdigen URL-Eingabe zu einer bösartigen Website kann ein Angreifer erfolgreich einen Phishing-Betrug starten und Benutzeranmeldeinformationen stehlen.\n Darüber hinaus könnten offene Umleitungen auch verwendet werden, um böswillig eine URL zu erstellen, die die Zugriffskontrollprüfungen der Anwendung umgeht und den Angreifer dann zu privilegierten Funktionen weiterleitet, auf die er normalerweise keinen Zugriff hätte.\n\n Testen auf Sicherheitslücken bei der Client-seitigen URL-Umleitung:\nWenn Tester manuell nach dieser Art von Schwachstelle suchen müssen, müssen sie feststellen, ob clientseitige Umleitungen im clientseitigen Code implementiert sind.\n Diese Umleitungen könnten beispielsweise in JavaScript über das Objekt „window.location“ implementiert werden, mit dem der Browser durch einfaches Zuweisen eines Strings auf eine andere Seite geleitet werden kann. Wenn das Skript keine Validierung der Variablen „redir“ durchführt, wird diese nicht validierte Eingabe an das windows.location-Objekt weitergeleitet, wodurch eine URL-Umleitungs-Schwachstelle entsteht.", + "005": "Eine CSS-Injection-Schwachstelle beinhaltet die Möglichkeit, beliebigen CSS-Code im Kontext einer vertrauenswürdigen Website einzufügen, und dieser wird im Browser des Opfers gerendert.\nDie Auswirkungen einer solchen Schwachstelle können je nach bereitgestellter CSS-Payload variieren: Sie könnte unter Umständen zu Cross-Site Scripting, zu Datenexfiltration im Sinne des Extrahierens sensibler Daten oder zu UI-Modifikationen führen.\n\n Eine solche Schwachstelle tritt auf, wenn die Anwendung die Bereitstellung von benutzergeneriertem CSS zulässt oder es möglich ist, irgendwie in die legitimen Stylesheets einzugreifen.\n Das Einfügen von Code in den CSS-Kontext gibt dem Angreifer die Möglichkeit, JavaScript unter bestimmten Bedingungen auszuführen sowie sensible Werte durch CSS-Selektoren und Funktionen zu extrahieren, die HTTP-Anforderungen generieren können.\n\n Insbesondere könnte der Angreifer das Opfer angreifen, indem er es auffordert, die folgenden URLs zu besuchen:\n • www.victim.com/#red;-o-link:’javascript:alert(1)’;-o-linksource:current; (Oper [8,12])\n • www.victim.com/#red;-:expression(alert(URL=1)); (IE 7/8)\n\n Viel interessantere Angriffsszenarien beinhalten die Möglichkeit, Daten durch die Übernahme reiner CSS-Regeln zu extrahieren.\nSolche Angriffe können über CSS-Selektoren durchgeführt werden und zum Beispiel dazu führen, Anti-CSRF-Token zu stehlen.\n\n Testen auf CSS-Injection-Schwachstellen:\n Es müssen manuelle Tests durchgeführt und der JavaScript-Code analysiert werden, um zu verstehen, ob die Angreifer eigene Inhalte im CSS-Kontext einfügen können. Insbesondere sollte uns interessieren, wie die Website CSS-Regeln auf Basis der Eingaben zurückgibt.", + "006": "Eine ClientSide Resource Manipulation-Schwachstelle ist ein Fehler bei der Eingabevalidierung, der auftritt, wenn eine Anwendung eine benutzergesteuerte Eingabe akzeptiert, die den Pfad einer Ressource angibt (d. h. die Quelle eines Iframes, js, Applets).\nEine solche Schwachstelle besteht insbesondere in der Möglichkeit, die URLs zu kontrollieren, die auf einige auf einer Webseite vorhandene Ressourcen verweisen.\n Die Auswirkungen können je nach Art des Elements variieren, dessen URL vom Angreifer kontrolliert wird, und es wird normalerweise verwendet, um Cross-Site-Scripting-Angriffe durchzuführen.\n\n Eine solche Schwachstelle tritt auf, wenn die Anwendung Benutzer verwendet\nkontrollierte URLs zum Verweisen auf externe/interne Ressourcen.\n Unter diesen Umständen ist es möglich, das Verhalten der erwarteten Anwendung zu beeinträchtigen, indem schädliche Objekte geladen und wiedergegeben werden.\n\n Testen auf Sicherheitslücken in Bezug auf clientseitige Ressourcenmanipulation:\nUm manuell nach dieser Art von Schwachstelle zu suchen, müssen wir feststellen, ob die Anwendung Eingaben verwendet, ohne sie korrekt zu validieren. Diese stehen unter der Kontrolle des Benutzers, der möglicherweise die URL einiger Ressourcen angeben kann.\n Da es viele Ressourcen gibt, die in die Anwendung aufgenommen werden könnten, sollten clientseitige Skripts, die die zugehörigen URLs verarbeiten, auf mögliche Probleme untersucht werden. \n\n Nachfolgend sind die möglichen Injektionsstellen (Sink) aufgeführt, die überprüft werden sollten: \n • Ressource: Frame \n • Tag/Methode: iframe \n • Sink: src \n\n • Ressource: Link \n • Tag/Methode: a \n • Sink: href\n\n • Ressource: AJAX Request \n • Tag/Methode: xhr.open(method, [url], true); \n • Sink: URL href\n\n • Ressource: CSS \n • Tag/Methode: link \n\n • Ressource: Image \n • Tag/Methode: img \n\n • Ressource: Object \n • Tag/Methode: object \n • Sink: src\n\n • Ressource: Script \n • Tag/Methode: script \n • Sink: data src", + "007": "Cross Origin Resource Sharing oder CORS ist ein Mechanismus, der es einem Webbrowser ermöglicht, „domänenübergreifende“ Anforderungen mithilfe der XMLHttpRequest L2-API auf kontrollierte Weise auszuführen.\n In der Vergangenheit erlaubte die XMLHttpRequest L1-API nur das Senden von Anforderungen innerhalb desselben Ursprungs, da sie durch dieselbe Ursprungsrichtlinie eingeschränkt war.\n\n Cross-Origin-Anfragen haben einen Origin-Header, der die Domäne identifiziert, die die Anfrage initiiert, und immer an den Server gesendet wird. CORS definiert das Protokoll, das zwischen einem Webbrowser und einem Server verwendet werden soll, um festzustellen, ob eine Cross-Origin-Anforderung zulässig ist.\n Um dieses Ziel zu erreichen, sind an diesem Prozess einige HTTP-Header beteiligt, die von allen gängigen Browsern unterstützt werden, darunter:\n • Origin \n • Access-Control-Request-Method \n • Access-Control-Request-Headers \n • Access-Control-Allow-Origin \n • Access-Control-Allow-Credentials \n • Access-Control-Allow-Methods \n • Access-Control-Allow-Headers\n\n Die CORS-Spezifikation schreibt vor, dass für nicht einfache Anforderungen, wie z. B. andere Anforderungen als GET oder POST oder Anforderungen, die Anmeldeinformationen verwenden, im Voraus eine OPTIONS-Anforderung vor dem Flug gesendet werden muss, um zu prüfen, ob sich der Anforderungstyp negativ auf die Daten auswirkt .\n Die Preflight-Anforderung prüft die vom Server zugelassenen Methoden und Header, und wenn Anmeldeinformationen zulässig sind, entscheidet der Browser basierend auf dem Ergebnis der OPTIONS-Anforderung, ob die Anforderung zugelassen wird oder nicht.\n\n Überprüfen Sie die HTTP-Header, um zu verstehen, wie CORS verwendet wird, insbesondere sollten wir uns sehr für den Origin-Header interessieren, um zu erfahren, welche Domänen zulässig sind.\n Außerdem ist eine manuelle Überprüfung des JavaScripts erforderlich, um festzustellen, ob der Code aufgrund einer unsachgemäßen Handhabung von Benutzereingaben anfällig für Code-Injection ist.", + "008": "ActionScript ist die auf ECMAScript basierende Sprache, die von Flash-Anwendungen verwendet wird, wenn es um interaktive Anforderungen geht.\n Dort sind drei\nVersionen der ActionScript-Sprache. ActionScript 1.0 und ActionScript 2.0 sind sich sehr ähnlich, wobei ActionScript 2.0 eine Erweiterung von ActionScript 1.0 ist. ActionScript 3.0, eingeführt mit Flash Player 9, ist eine Neufassung der Sprache, um objektorientiertes Design zu unterstützen.\n\n ActionScript hat wie jede andere Sprache einige Implementierungsmuster, die zu Sicherheitsproblemen führen können.\n Da Flash-Anwendungen oft in Browser eingebettet sind, können Schwachstellen wie DOM-basiertes Cross-Site Scripting (XSS) in fehlerhaften Flash-Anwendungen vorhanden sein.\n\n Dekompilierung\n Da SWF-Dateien von einer im Player selbst eingebetteten virtuellen Maschine interpretiert werden, können sie möglicherweise dekompiliert und analysiert werden. Der bekannteste und kostenlosste ActionScript 2.0-Decompiler ist Flare.\n Die Dekompilierung hilft Testern, da sie ein quellcodegestütztes oder White-Box-Testen der Flash-Anwendungen ermöglicht. Das kostenlose Tool SWFScan von HP kann sowohl ActionScript 2.0 als auch ActionScript 3.0 dekompilieren.\n\n Angriffe und Flash-Player-Version Seit Mai 2007 wurden drei neue Versionen des Flash-Players von Adobe veröffentlicht. Jede neue Version schränkt einige der Angriffe ein.\n\n Player-Version: v9.0 r47/48\n • asfunction: Ja\n • Externe Schnittstelle: Ja\n • GetURL: Ja\n • HTML-Injektion: Ja\n\n Player-Version: v9.0 r115\n • asfunction: Nein\n • Externe Schnittstelle: Ja\n • GetURL: Ja\n • HTML-Injektion: Ja\n\n Player-Version: v9.0 r124\n • asfunction: Nein\n • Externe Schnittstelle: Ja\n • GetURL: Ja\n • HTML-Injection: Teilweise", + "009": "„Clickjacking“ (das eine Teilmenge des „UI-Redressing“ ist) ist eine bösartige Technik, die darin besteht, einen Webbenutzer dazu zu verleiten, mit etwas zu interagieren, das anders ist als das, womit der Benutzer glaubt, dass er interagiert.\n Diese Art von Angriff, der allein oder in Kombination mit anderen Angriffen verwendet werden kann, könnte möglicherweise nicht autorisierte Befehle senden oder vertrauliche Informationen preisgeben, während das Opfer auf scheinbar harmlosen Webseiten interagiert.\n\n Ein Clickjacking-Angriff verwendet scheinbar harmlose Funktionen von HTML und Javascript, um das Opfer zu unerwünschten Aktionen zu zwingen, wie z. B. das Klicken auf eine Schaltfläche, die scheinbar eine andere Operation ausführt.\n\n Um diese Art von Technik auszuführen, muss der Angreifer eine scheinbar harmlose Webseite erstellen, die die Zielanwendung durch die Verwendung eines Iframes lädt.\n Sobald dies geschehen ist, könnte der Angreifer das Opfer dazu bringen, mit seiner fiktiven Webseite zu interagieren.\nSobald das Opfer auf der fiktiven Webseite surft, denkt es, dass es mit der sichtbaren Benutzeroberfläche interagiert, tatsächlich führt es jedoch Aktionen auf der versteckten Seite aus.\n\nDiese Art von Angriff ist häufig darauf ausgelegt, einer angreifenden Website zu ermöglichen, Benutzeraktionen auf der Ziel-Website zu veranlassen, selbst wenn Anti-CSRF-Token verwendet werden. . Daher ist es wichtig, wie beim CSRF-Angriff, Webseiten der Zielseite so zu kennzeichnen, dass sie Eingaben des Benutzers entgegennehmen.\n\nWir müssen herausfinden, ob die Website, die wir testen, keinen Schutz vor Clickjacking-Angriffen hat oder, ob die Entwickler Schutzmaßnahmen implementiert haben, ob diese Techniken umgangen werden können.\nMethoden zum Schutz einer Webseite vor Clickjacking können in zwei Makrokategorien unterteilt werden:\n • Clientseitiger Schutz: Frame Busting\n • Serverseitiger Schutz: X-Frame-Optionen\n\n Einige Frame-Busting-Techniken versuchen, Frames zu unterbrechen, indem sie dem Attribut „parent.location“ in der „counter-action“-Anweisung einen Wert zuweisen. Solche Aktionen sind zum Beispiel:\n • self.parent.location = document.location\n • parent.location.href = self.location\n • parent.location = self.location", + "010": "Traditionell erlaubt das HTTP-Protokoll nur eine Anfrage/Antwort pro TCP-Verbindung. Asynchronous JavaScript and XML (AJAX) ermöglicht es Clients, Daten asynchron an den Server zu senden und zu empfangen, AJAX erfordert jedoch, dass der Client die Anforderungen initiiert und auf die Serverantworten wartet (Halbduplex).\n\n HTML5-WebSockets ermöglichen es dem Client/Server, „Vollduplex“-Kommunikationskanäle (zwei Wege) zu erstellen, sodass Client und Server wirklich asynchron kommunizieren können. WebSockets führen ihren anfänglichen „Upgrade“-Handshake über HTTP durch und von da an wird die gesamte Kommunikation über TCP-Kanäle unter Verwendung von Frames ausgeführt.\n\n 1: Identifizieren Sie, dass die Anwendung WebSockets verwendet\n • Untersuchen Sie den clientseitigen Quellcode auf das URI-Schema ws:// oder wss://\n • Verwenden Sie Browser Developer Tools, um die Netzwerk-WebSocket-Kommunikation anzuzeigen\n • Verwenden Sie die WebSocket-Registerkarte von OWASP Zed Attack Proxy (ZAP).\n\n 2: Ursprung\n • Versuchen Sie mithilfe eines WebSocket-Clients, eine Verbindung zum Remote-WebSocket-Server herzustellen\n • Wenn eine Verbindung hergestellt wird, überprüft der Server möglicherweise nicht den Ursprungsheader des WebSocket-Handshakes\n\n 3: Vertraulichkeit und Integrität\n • Überprüfen Sie, ob die WebSocket-Verbindung SSL verwendet, um vertrauliche Informationen zu übertragen (wss://)\n • Überprüfen Sie die SSL-Implementierung auf Sicherheitsprobleme (gültiges Zertifikat, BEAST, CRIME, RC4 usw.).\n\n 4: Authentifizierung\n • WebSockets führen keine Authentifizierung durch, es sollten normale Blackbox-Authentifizierungstests durchgeführt werden\n\n 5: Autorisierung\n • WebSockets behandeln keine Autorisierung, es sollten normale Blackbox-Autorisierungstests durchgeführt werden\n\n 6: Eingangsbereinigung\n • Verwenden Sie die WebSocket-Registerkarte von OWASP Zed Attack Proxy (ZAP), um WebSocket-Anforderungen und -Antworten wiederzugeben und zu fuzzen", + "011": "Web Messaging (auch bekannt als Cross Document Messaging) ermöglicht Anwendungen, die auf verschiedenen Domänen ausgeführt werden, auf sichere Weise zu kommunizieren.\n Diese Einschränkung im Browser dient dazu, eine böswillige Website daran zu hindern, vertrauliche Daten von anderen iFrames, Registerkarten usw. zu lesen. Es gibt jedoch einige legitime Fälle, in denen zwei vertrauenswürdige Websites Daten untereinander austauschen müssen. Um diesem Bedarf gerecht zu werden, wurde Cross Document Messaging innerhalb der WHATWG-HTML5-Entwurfsspezifikation eingeführt und in allen gängigen Browsern implementiert.\n Es ermöglicht eine sichere Kommunikation zwischen mehreren Ursprüngen über iFrames, Registerkarten und Fenster hinweg.\n\n Die Messaging-API führte die Methode postMessage() ein, mit der Klartext-Nachrichten ursprungsübergreifend versendet werden können. Es besteht aus zwei Parametern, Nachricht und Domäne.\n\n Es gibt einige Sicherheitsbedenken bei der Verwendung von „*“ als Domain, die wir unten besprechen. Um dann Nachrichten zu empfangen, muss die empfangende Website einen neuen Event-Handler hinzufügen und hat die folgenden Attribute:\n • data: Der Inhalt der eingehenden Nachricht\n • Herkunft: Die Herkunft des Absenderdokuments\n • Quelle: Quellfenster\n\nEs müssen manuelle Tests durchgeführt und der JavaScript-Code analysiert werden, um herauszufinden, wie Web Messaging implementiert ist.\nInsbesondere sollte uns interessieren, wie die Website Nachrichten von nicht vertrauenswürdigen Domänen einschränkt und wie die Daten selbst für vertrauenswürdige Domänen gehandhabt werden.", + "012": "Lokaler Speicher, auch als Webspeicher oder Offlinespeicher bekannt, ist ein Mechanismus zum Speichern von Daten als Schlüssel/Wert-Paare, die an eine Domäne gebunden sind und durch dieselbe Ursprungsrichtlinie (SOP) erzwungen werden.\n Es gibt zwei Objekte, localStorage, das persistent ist und Neustarts des Browsers/Systems überstehen soll, und sessionStorage, das temporär ist und nur existiert, bis das Fenster oder die Registerkarte geschlossen wird.\n Im Durchschnitt erlauben Browser in diesem Speicher etwa 5 MB pro Domain zu speichern, was im Vergleich zu den 4 KB Cookies ein großer Unterschied ist, aber der Hauptunterschied aus Sicherheitsperspektive besteht darin, dass die in diesen beiden Objekten gespeicherten Daten im Client und niemals gespeichert werden an den Server gesendet.\n\n Zunächst müssen wir prüfen, ob der Local Storage verwendet wird. Dies kann überprüft werden, wenn Sie das Browser-Tool verwenden, und dann unter Ressourcen zu „Lokaler Speicher“ und „Webspeicher“ gehen.\n\n Als nächstes müssen manuelle Tests durchgeführt werden, um festzustellen, ob die Website sensible Daten im Speicher speichert, die ein Risiko darstellen und die Auswirkungen eines Informationslecks dramatisch erhöhen werden.\n Überprüfen Sie auch den Code, der den Speicher verarbeitet, um festzustellen, ob er anfällig für Injektionsangriffe ist, ein häufiges Problem, wenn der Code der Eingabe oder Ausgabe nicht entkommt." + }, + "no_info": "Kein Informationen für die gegebene Referenznummer gefunden." } } diff --git a/security-c4po-angular/src/assets/i18n/en-US.json b/security-c4po-angular/src/assets/i18n/en-US.json index 063246a..aaaf10d 100644 --- a/security-c4po-angular/src/assets/i18n/en-US.json +++ b/security-c4po-angular/src/assets/i18n/en-US.json @@ -75,6 +75,19 @@ "delete.failed": "Project could not be deleted" } }, + "categories": { + "INFORMATION_GATHERING": "Information Gathering", + "CONFIGURATION_AND_DEPLOY_MANAGEMENT_TESTING": "Config & Deploy Management Testing", + "IDENTITY_MANAGEMENT_TESTING": "Identity Management Testing", + "AUTHENTICATION_TESTING": "Authentication Testing", + "AUTHORIZATION_TESTING": "Authorization Testing", + "SESSION_MANAGEMENT_TESTING": "Session Management Testing", + "INPUT_VALIDATION_TESTING": "Input Validation Testing", + "ERROR_HANDLING": "Error Handling", + "CRYPTOGRAPHY": "Cryptography", + "BUSINESS_LOGIC_TESTING": "Business Logic Testing", + "CLIENT_SIDE_TESTING": "Client Side Testing" + }, "pentest": { "testId": "No.", "title": "Title", @@ -94,7 +107,7 @@ "003": "Review Webserver Metafiles for Information Leakage", "004": "Enumerate Applications on Webserver", "005": "Review Webpage Comments and Metadata for Information Leakage", - "006": "Identity application entry points", + "006": "Identify application entry points", "007": "Map execution paths through application", "008": "Fingerprint Web Application Framework", "009": "Fingerprint Web Application", @@ -152,29 +165,29 @@ "002": "Testing for Stored Cross Site Scripting", "003": "Testing for HTTP Verb Tampering", "004": "Testing for HTTP Parameter pollution", - "005": "N/A", - "006": "Testing for SQL Injection", - "006_1": "Oracle Testing", - "006_2": "SQL Server Testing", - "006_3": "Testing PostgreSQL", - "006_4": "MS Access Testing", - "006_5": "Testing for NoSQL Injection", - "007": "Testing for LDAP Injection", - "008": "Testing for ORM Injection", - "009": "Testing for XML Injection", - "010": "Testing for SSI Injection", - "011": "Testing for XPath Injection", - "012": "IMAP/SMTP Injection", - "013": "Testing for Code Injection", - "013_1": "Testing Local File Inclusion", - "013_2": "Testing Remote File Inclusion", - "014": "Testing for Command Injection", - "015": "Testing for Buffer overflow", - "015_1": "Testing for Heap overflow", - "015_2": "Testing for Stack overflow", - "015_3": "Testing for Format string", - "016": "Testing for incubated vulnerabilities", - "017": "Testing for HTTP Splitting/Smuggling" + "005": "Testing for SQL Injection", + "005_1": "Oracle Testing", + "005_2": "MySQL Testing", + "005_3": "SQL Server Testing", + "005_4": "Testing PostgreSQL", + "005_5": "MS Access Testing", + "005_6": "Testing for NoSQL Injection", + "006": "Testing for LDAP Injection", + "007": "Testing for ORM Injection", + "008": "Testing for XML Injection", + "009": "Testing for SSI Injection", + "010": "Testing for XPath Injection", + "011": "IMAP/SMTP Injection", + "012": "Testing for Code Injection", + "012_1": "Testing Local File Inclusion", + "012_2": "Testing Remote File Inclusion", + "013": "Testing for Command Injection", + "014": "Testing for Buffer overflow", + "014_1": "Testing for Heap overflow", + "014_2": "Testing for Stack overflow", + "014_3": "Testing for Format string", + "015": "Testing for incubated vulnerabilities", + "016": "Testing for HTTP Splitting/Smuggling" }, "err": { "001": "Analysis of Error Codes", @@ -211,17 +224,129 @@ "012": "Test Local Storage" } }, - "categories": { - "INFORMATION_GATHERING": "Information Gathering", - "CONFIGURATION_AND_DEPLOY_MANAGEMENT_TESTING": "Config & Deploy Management Testing", - "IDENTITY_MANAGEMENT_TESTING": "Identity Management Testing", - "AUTHENTICATION_TESTING": "Authentication Testing", - "AUTHORIZATION_TESTING": "Authorization Testing", - "SESSION_MANAGEMENT_TESTING": "Session Management Testing", - "INPUT_VALIDATION_TESTING": "Input Validation Testing", - "ERROR_HANDLING": "Error Handling", - "CRYPTOGRAPHY": "Cryptography", - "BUSINESS_LOGIC_TESTING": "Business Logic Testing", - "CLIENT_SIDE_TESTING": "Client Side Testing" + "objectives": { + "info": { + "001": "The objective is to understand what sensitive design and configuration information of the application/system/organization is exposed both directly (on the organization’s website) or indirectly (on a third party website).\n\n There are direct and indirect elements to search engine discovery and reconnaissance. \n Direct methods relate to searching the indexes and the associated content from caches.\n Indirect methods relate to gleaning sensitive design and configuration information by searching forums, newsgroups, and tendering websites.\n\n Use a search engine to search for:\n• Network diagrams and configurations\n• Archived posts and emails by administrators and other key staff\n• Log on procedures and username formats\n• Usernames and passwords\n• Error message content\n• Development, test, UAT and staging versions of the website", + "002": "The objective is to find the version and type of a running web server to determine known vulnerabilities and the appropriate exploits to use during testing.\n\n Web server fingerprinting is a critical task for the penetration tester.\nKnowing the version and type of a running web server allows testers to determine known vulnerabilities and the appropriate exploits to use during testing.\n\n There are several different vendors and versions of web servers on the market today. Knowing the type of web server that is being tested significantly helps in the testing process and can also change the course of the test. The simplest and most basic form of identifying a web server is to look at the Server field in the HTTP response header.\n\n By knowing how each type of web server responds to specific commands and keeping this information in a web server fingerprint database, a penetration tester can send these commands to the web server, analyze the response, and compare it to the database of known signatures.", + "003": "The objective here is to check the robots.txt file for information leakage of the web application’s directory or folder path(s).\n\n 1. Information leakage of the web application’s directory or folder path(s). \n 2. Create the list of directories that are to be avoided by Spiders, Robots, or Crawlers. \n\n Furthermore, the list of directories that are to be avoided by Spiders, Robots, or Crawlers can also be created as a dependency for Map execution paths through application.\n Web Spiders, Robots, or Crawlers retrieve a web page and then recursively traverse hyperlinks to retrieve further web content. Their accepted behavior is specified by the Robots Exclusion Protocol of the robots.txt file in the web root directory.", + "004": "The objective is enumerate the applications within scope that exist on a web server.\n\n Many applications have known vulnerabilities and known attack strategies that can be exploited in order to gain remote control or to exploit data. In addition, many applications are often misconfigured or not updated. \n Web application discovery is a process aimed at identifying web applications on a given infrastructure. The latter is usually specified as a set of IP addresses (maybe a net block), but may consist of a set of DNS symbolic names or a mix of the two.", + "005": "The objective is to review webpage comments and metadata to better understand the application and to find any information leakage.\n\n HTML comments are often used by the developers to include debugging information about the application. Sometimes they forget aboutthe comments and they leave them on in production.\n\n Check HTML source code for comments containing sensitive information that can help the attacker gain more insight about the application. It might be SQL code, usernames and passwords, internal IP addresses, or debugging information.", + "006": "The objective is to understand how requests are formed and typical responses from the application.\n\n Enumerating the application and its attack surface is a key precursor before any thorough testing can be undertaken, as it allows the tester to identify likely areas of weakness. This aims to help identify and map out areas within the application that should be investigated once enumeration and mapping have been completed.\n\n While walking through the application, pay special attention to all HTTP requests (GET and POST Methods, also known as Verbs), as well as every parameter and form field that is passed to the application.\n In addition, take note of any interesting parameters in the URL, custom headers, or body of the requests/responses, and save them. \n Once every area of the application is mapped out, go through the application and test each of the areas that have been identified and make notes for what worked and what didn’t work.", + "007": "The objective is to Map the target application and understand the principal workflows.\n\n Before commencing security testing, understanding the structure of the application is paramount.\nThere are several ways to approach the testing and measurement of code coverage:\n\n 1. Path:\n Test each of the paths through an application that includes combinatorial and boundary value analysis testing for each decision path. While this approach offers thoroughness, the number of testable paths grows exponentially with each decision branch.\n\n 2. Data flow (or taint analysis): \n Tests the assignment of variables via external interaction (normally users).\n Focuses on mapping the flow, transformation and use of data throughout an application.\n\n 3. Race:\n Tests multiple concurrent instances of the application manipulating the same data.", + "008": "The objective is to define type of used web framework so as to have a better understanding of the security testing methodology. \n\n Knowing the type of framework can automatically give a great advantage if such a framework has already been tested by the penetration tester. It is not only the known vulnerabilities in unpatched versions but specific misconfigurations in the framework and known file structure that makes the fingerprinting process so important.\n\n There are several most common locations to look in in order to define the current framework:\n• HTTP headers\n• Cookies\n• HTML source code\n• Specific files and folders", + "009": "The objective is to identify the web application and version to determine known vulnerabilities and the appropriate exploits to use during testing.\n\n With the vast number of free and open source software projects that are actively developed and deployed around the world, it is very likely that an application security test will face a target site that is entirely or partly dependent on these well known applications (e.g. Wordpress, phpBB, Mediawiki, etc).\n\nKnowing the web application components that are being tested significantly helps in the testing process.\nThese well known web applications have known HTML headers, cookies, and directory structures that can be enumerated to identify the application.", + "010": "The application architecture needs to be mapped through some test to determine what different components are used to build the web application.\n\n In small setups, such as a simple CGI-based application, a single server might be used that runs the web server which executes the C, Perl, or Shell CGIs application, and perhaps also the authentication mechanism.\n On more complex setups multiple servers might be involved. These may include a reverse proxy, a frontend web server, an application server and a database server or LDAP server. \nEach of these servers will be used for different purposes and might be even be divided in different networks with firewalls between them (DMZs). \n\n In addition, understanding the deployed configuration of the server hosting the web application is almost as important as the application security testing itself." + }, + "config": { + "001": "The intrinsic complexity of interconnected and heterogeneous webserver infrastructure, which can include hundreds of web applications, makes configuration management and review a fundamental step in testing and deploying every single application. It takes only a single vulnerability to undermine the security of the entire infrastructure. In order to address these problems, it is of utmost importance to perform an indepth review of configuration and known security issues.\n\nThe following steps need to be taken to test the configuration management infrastructure:\n\nStep 1:\n The different elements that make up the infrastructure need to be determined in order to understand how they interact with a web application and how they affect its security.\n\nStep 2:\n All the elements of the infrastructure need to be reviewed in order to make sure that they don’t contain any known vulnerabilities.\n\nStep 3:\n A review needs to be made of the administrative tools used to maintain all the different elements.\n\nStep 4:\n The authentication systems, need to reviewed in order to assure that they serve the needs of the application and that they cannot be manipulated by external users to leverage access.\n\nStep 5:\n A list of defined ports which are required for the application should be maintained and kept under change control.", + "002": "Configuration review and testing is a critical task in creating and maintaining an architecture. This is because many different systems will be usually provided with generic configurations that might not be suited to the task they will perform on the specific site they’re installed on.\n\n While the typical web and application server installation will contain a lot of functionality (like application examples, documentation, test pages) what is not essential should be removed before deployment to avoid post-install exploitation. \n\nCGI scanners include a detailed list of known files and directory samples that are provided by different web or application servers.\nAlso will event logs often contain data that is useful to an attacker (information leakage) or can be used directly in exploits.", + "003": "File extensions are commonly used in web servers to easily determine which technologies, languages and plugins must be used to fulfill the web request. \nWhile this behavior is consistent with RFCs and Web Standards, using standard file extensions provides the penetration tester useful information about the underlying technologies used in a web appliance. \n\n Determining how web servers handle requests corresponding to files having different extensions may help in understanding web server behavior depending on the kind of files that are accessed.\n\nThe following file extensions should never be returned by a web server, since they are related to files which may contain sensitive information:\n • .asa\n• .inc \n\n The following file extensions are related to files which, when accessed, are either displayed or downloaded by the browser. \n Therefore, files with these extensions must be checked to verify that they are indeed supposed to be served:\n• .zip, .tar, .gz, .tgz, .rar, ...: (Compressed) archive files\n• .java: No reason to provide access to Java source files\n• .txt: Text files\n• .pdf: PDF documents\n• .doc, .rtf, .xls, .ppt, ...: Office documents\n• .bak, .old and other extensions indicative of backup files \n\n To identify files having a given extensions a mix of techniques can be employed. \nThese techniques can include Vulnerability Scanners, spidering and mirroring tools, manually inspecting the application or querying search engines.", + "004": "An important source of vulnerability lies in files which have nothing to do with the application, but are created as a consequence of editing application files, or after creating on-the-fly backup copies, or by leaving in the web tree old files or unreferenced files.\n\n Theoretically the examination should be performed by hand to be thorough. However, since in most cases copies of files or backup files tend to be created by using the same naming conventions, the search can be easily scripted.", + "005": "Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.\n\nAn application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. \nSuch changes may include: \n• user account provisioning\n• site design and layout \n• data manipulation\n• configuration changes\n\nThe following describes vectors that may be used to test for the presence of administrative interfaces: \n• Directory and file enumeration \n• Brute forcing tools like THC-HYDRA \n• Comments and links in source code \n• Reviewing server and application documentation \n• Publicly available information (e.g. default passwords) \n• Alternative server port \n• Parameter tampering", + "006": "To perform this test, the tester needs some way to figure out which HTTP methods are supported by the web server that is being examined. The OPTIONS HTTP method provides the tester with the most direct and effective way to do that. RFC 2616 states that, “The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI”.\n\n Some of the HTTP methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users. More specifically, the methods that should be disabled are the following: \n• PUT: allows client to upload files to web server \n• DELETE: allwas client to delete files from web server \n• CONNECT: allows client to use web server as proxy \n• TRACE: echoes back to client whatever he sent to server", + "007": "The HTTP Strict Transport Security (HSTS) feature lets a web application to inform the browser, through the use of a special response header, that it should never establish a connection to the the specified domain servers using HTTP.\n\n The HTTP strict transport security header uses two directives: \n• max-age \n• includeSubDomains \n\nTesting for the presence of HSTS header can be done by checking for the existence of the HSTS header in the server’s response in an interception proxy, or by using curl.", + "008": "Rich Internet Applications (RIA) have adopted Adobe’s crossdomain.xml policy files to allow for controlled cross domain access to data and service consumption using technologies such as Oracle Java, Silverlight, and Adobe Flash. Therefore, a domain can grant remote access to its services from a different domain. \nHowever, often the policy files that describe the access restrictions are poorly configured. Poor configuration of the policy files enables Cross-site Request Forgery attacks. \n\n To test for RIA policy file weakness the tester should try to retrieve the policy files crossdomain.xml and clientaccesspolicy.xml from the application’s root, and from every folder found." + }, + "ident": { + "001": "The objective is to validate the system roles defined within the application sufficiently define and separate each system and business role to manage appropriate access to system functionality and information. \n\n It is common in modern enterprises to define system roles to manage users and authorization to system resources. \nImportant to remember is that cold, hard authorization isn’t the only way to manage access to system objects. In more trusted environments where confidentiality is not critical, softer controls such as application workflow and audit logging can support data integrity requirements while not restricting user access to functionality.\n\n Either with or without the help of the system developers or administrators, develop an role versus permission matrix. The matrix should enumerate all the roles that can be provisioned and explore the permissions that are allowed.", + "002": "Some websites offer a user registration process that automates (or semi-automates) the provisioning of system access to users. The identity requirements for access vary from positive identification to none at all, depending on the security requirements of the system. \n\n Step 1: \n Verify that the identity requirements for user registration are aligned with business and security requirements. \n\n Step 2: \n Validate the registration process. \n\n Verify that the identity requirements for user registration are aligned with business and security requirements: \n• Can anyone register for access? \n• Are registrations vetted by a human? \n• Can the same person or identity register multiple times? \n• Can users register for different roles or permissions? \n• What proof of identity is required for a registration? \n• Are registered identities verified? \n\n Validate the registration process: \n • Can identity information be easily forged or faked? \n • Can the exchange of identity information be manipulated?", + "003": "Verify which accounts may provision other accounts and of what type. \n\n The provisioning of accounts presents an opportunity for an attacker to create a valid account without application of the proper identification and authorization process.\nDetermine which roles are able to provision users and what sort of accounts they can provision.", + "004": "The scope of this test is to verify if it is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. \nThis test will be useful for brute force testing, in which the tester verifies if, given a valid username, it is possible to find the corresponding password. \n\nIn some cases, a message is received that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, testers can enumerate the existing users by sending a username and an empty password. \n If the application is vulnerable, the tester receives a response message that reveals, directly or indirectly, some information useful for enumerating users.", + "005": "The objective is to determine whether a consistent account name structure renders the application vulnerable to account enumeration. Determine whether the application’s error messages permit account enumeration. \n\n User account names are often highly structured (e.g. Joe Bloggs account name is jbloggs and Fred Nurks account name is fnurks) and valid account names can easily be guessed. \n • Determine the structure of account names.\n• Evaluate the application’s response to valid and invalid account names.\n• Use different responses to valid and invalid account names to enumerate valid account names.\n• Use account name dictionaries to enumerate valid account names.", + "006": "Guest and Training accounts are useful ways to acquaint potential users with system functionality prior to them completing the authorisation process required for access. \n Evaluate consistency between access policy and guest/training account access permissions.", + "007": "Verify the identity requirements for user registration align with business/security requirements. \n\nValidate the registration process." + }, + "authn": { + "001": "The analysis focuses simply on trying to understand if the data travels unencrypted from the web browser to the server, or if the web application takes the appropriate security measures using a protocol like HTTPS. \n\n Testing for credentials transport means verifying that the user’s\nauthentication data are transferred via an encrypted channel to avoid being intercepted by malicious users. \n\n You can use WebScarab or any web proxy in order to capture packet headers and to inspect them. \n Check if HTTPS is used in every sensitive request, like those in log in pages, to prevent unauthorized users to intercept the data.", + "002": "Often are applications, once installed, not properly configured and the default credentials provided for initial authentication and configuration are never changed. \n\n When you have identified an application interface, for example a Cisco router web interface or a Weblogic administrator portal, check that the known usernames and passwords for these devices do not result in successful authentication. To do this you can consult the manufacturer’s documentation or, in a much simpler way, you can find common credentials using a search engine or by using one of the sites or tools listed in the Reference section. \n\n When facing applications where we do not have a list of default and common user accounts we can attempt to guess valid default credentials. \n Many applications have verbose error messages that inform the site users as to the validity of entered usernames. This information will be helpful when testing for default or guessable user accounts. \n\nSince these types of default credentials are often bound to administrative accounts you can try the following usernames for the start: \n• admin \n• administrator \n• root \n• system \n• guest \n• operator \n• super", + "003": "Account lockout mechanisms are used to mitigate brute force password guessing attacks. Accounts are typically locked after 3 to 5 unsuccessful login attempts and can only be unlocked after a predetermined period of time, via a self-service unlock mechanism, or intervention by an administrator. \n\n Typically, to test the strength of lockout mechanisms, you will need access to an account that you are willing or can afford to lock: \n\n Step 1: \n Evaluate the account lockout mechanism’s ability to mitigate brute force password guessing. \n\n Step 2: \nEvaluate the unlock mechanism’s resistance to unauthorized account unlocking. \n\n Without a strong lockout mechanism, the application may be susceptible to brute force attacks. After a successful brute force attack, a malicious user could have access to: \n• Confidential information or data \n• Administration panels \n• Opportunities for further attacks", + "004": "While most applications require authentication to gain access to private information or to execute tasks, not every authentication method is able to provide adequate security. \n\n There are several methods of bypassing the authentication schema that is used by a web application: \n• Direct page request (forced browsing) \n• Parameter modification \n• Session ID prediction \n• SQL Injection", + "005": "Browsers will sometimes ask a user if they wish to remember the password that they just entered. \n\n Having the browser store passwords is not only a convenience for end-users, but also for an attacker. If an attacker can gain access to the victim’s browser (e.g. XSS attack), then they can retrieve the stored passwords. \n Additionally where custom “remember me” functions are put in place weaknesses in how the token is stored on the client PC could expose the users passwords. \n\n Ensure that no credentials are stored in clear text or are easily retrievable in encoded or encrypted forms in cookies: \n• Look for passwords stored in cookie \n• Examine the hashing mechanism \n• Verify that credentials are only send during login \n• Consider sensitive form fields", + "006": "Browsers can store information for purposes of caching and history. Caching is used to improve performance, so that previously displayed information doesn’t need to be downloaded again. \n If sensitive information is displayed to the user, then this information could be stored for purposes of caching or history, and therefore retrievable through examining the browser’s cache or by simply pressing the browser’s “Back” button. \n\n Technically, the “Back” button is a history and not a cache. The cache and the history are two different entities. However, they share the same weakness of presenting previously displayed sensitive information. \n\nThe “Back” button can be stopped from showing sensitive data. \nThis can be done by: \n• Delivering the page over HTTPS. \n• Setting Cache-Control: must-re-validate", + "007": "The most prevalent and most easily administered authentication mechanism is a static password. It is lamented that most common passwords are still: 123456, password and qwerty. \n\nDetermine the resistance of the application against brute force password guessing using available password dictionaries by evaluating the length, complexity, reuse and aging requirements of passwords. \n\n Step 1: \n What characters are permitted and forbidden for use within a password? \nIs the user required to use characters from different character sets such as lower and uppercase letters, digits and special symbols? \n\n Step 2: \n How often can a user change their password? \nHow quickly can a user change their password after a previous change? \n Users may bypass password history requirements by changing their password 5 times in a row. \n\n Step 3: \n When must a user change their password? \nAfter 90 days? \nAfter account lockout due to excessive log on attempts? \n\n Step 4: \n How often can a user reuse a password? \n Does the application maintain a history of the user’s previous used 8 passwords? \n\n Step 5: \n How different must the next password be from the last password? \n\n Step 6: \nIs the user prevented from using his username or other account information (such as first or last name) in the password?", + "008": "Often called “secret” questions and answers, security questions and answers are often used to recover forgotten passwords, or as extra security on top of the password. \n\n They are typically generated upon account creation and require the user to select from some pre-generated questions and supply an appropriate answer. They may allow the user to generate their own question and answer pairs. \n Both methods are prone to insecurities. Ideally, security questions should generate answers that are only known by the user, and not guessable or discoverable. \n\n The key to successfully exploiting and bypassing a weak security question scheme is to find a question or set of questions which give the possibility of easily finding the answers. \n\n Step 1: \nTry to obtain a list of security questions by creating a new account or by following the “I don’t remember my password”-process.\n\n Step 2: \n Try to create security questions by creating a new account or by configuring your existing account’s password recovery properties.\nIf the system allows the user to generate their own security questions, it is vulnerable to having insecure questions created. \n\n Step 3: \n Determine if a number of incorrectly supplied security answers trigger a lockout mechanism.", + "009": "The password change and reset function of an application is a self-service password change or reset mechanism for users. \n This self-service mechanism allows users to quickly change or reset their password without an administrator intervening. \n\n Step 1: \n Determine the resistance of the application to subversion of the account change process allowing someone to change the password of an account. \n\n Step 2: \nDetermine the resistance of the passwords reset functionality against guessing or bypassing. \n\n For both password change and password reset it is important to check.. \n\n.. if users, other than administrators, can change or reset passwords for accounts other than their own. \n.. if users can manipulate or subvert the password change or reset process. \n.. if the password change or reset process is vulnerable to CSRF.", + "010": "Even if the primary authentication mechanisms do not include any vulnerabilities, it may be that vulnerabilities exist in alternative legitimate authentication user channels for the same user accounts. \n\n Tests should be undertaken to identify alternative channels and, subject to test scoping, identify vulnerabilities. \n Some of these channels may themselves be separate web applications using different host names or paths. For example: \n• Standard website \n• Mobile website \n• Accessibility optimized website \n• Parallel websites that utilize same user accounts \n• Development, UAT and versions of the standard website \n\n But they could also be other types of application or business processes: \n• Mobile device app \n• Desktop application \n• Call center operators \n• Interactive voice response or phone tree systems" + }, + "authz": { + "001": "Many web applications use and manage files as part of their daily operation. Using input validation methods that have not been well designed or deployed, an aggressor could exploit the system in order to read or write files that are not intended to be accessible. In particular situations, it could be possible to execute arbitrary code or system commands. \n\n In web servers and web applications, this kind of problem arises in path traversal/file include attacks. During an assessment, to discover path traversal and file include flaws, testers need to perform two different stages: \n\n Stage 1: \n Input Vectors Enumeration (a systematic evaluation of each input vector) \n\n Stage 2: \n Testing Techniques (a methodical evaluation of each attack technique used by an attacker to exploit the vulnerability) \n\n The next stage of testing is analyzing the input validation functions present in the web application. Using the previous example, the dynamic page called getUserProfile.jsp loads static information from a file and shows the content to users. An attacker could insert the malicious string “../../../../etc/passwd” to include the password hash file. \n It’s a common mistake by developers to not expect every form of encoding and therefore only do validation for basic encoded content. If at first the test string isn’t successful, try another encoding scheme.", + "002": "This kind of test focuses on verifying how the authorization schema has been implemented for each role or privilege to get access to reserved functions and resources. \n\nFor every specific role the tester holds during the assessment, for every function and request that the application executes during the post-authentication phase, it is necessary to verify: \n • Is it possible to access that resource even if the user is not authenticated? \n • Is it possible to access that resource after the log-out? \n • Is it possible to access functions and resources that should be accessible to a user that holds a different role or privilege? \n\n Try to access the application as an administrative user and track all the administrative functions: \n • Is it possible to access administrative functions also if the tester is logged as a user with standard privileges?\n• Is it possible to use these administrative functions as a user with adifferent role and for whom that action should be denied?", + "003": "Privilege escalation occurs when a user gets access to more resources or functionality than they are normally allowed. \n\n During this phase, the tester should verify that it is not possible for a user to modify his or her privileges or roles inside the application in ways that could allow privilege escalation attacks. \n The degree of escalation depends on what privileges the attacker is authorized to possess, and what privileges can be obtained in a successful exploit. \n\n In every portion of the application where a user can create information in the database (e.g., making a payment, or sending a message), can receive information (statement of account, order details, etc.), or delete information (drop user, messages, etc.), it is necessary to record that functionality. \n Try to access such functions as another user in order to verify if it is possible to access a function that should not be permitted by the user’s role/privilege.", + "004": "Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. \n As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files. \n\n Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. \n\n To test for this vulnerability the tester first needs to map out all locations in the application where user input is used to reference objects directly. \n The best way to test for direct object references would be by having at least two (often more) users to cover different owned objects and functions. \n By having multiple users the tester saves valuable testing time in guessing different object names as he can attempt to access objects that belong to the other user." + }, + "sess": { + "001": "In order to avoid continuous authentication for each page of a website or service, web applications implement various mechanisms to store and validate credentials for a pre-determined timespan. \n These mechanisms are known as Session Management. \n\n In this test, the tester wants to check that cookies and other session tokens are created in a secure and unpredictable way. An attacker who is able to predict and forge a weak cookie can easily hijack the sessions of legitimate users. \n Due to the importance of the data that they store, cookies are there fore vital in the overall security of the application. In this test the tester has to check whether the cookies issued to clients can resist a wide range of attacks aimed to interfere with the sessions of legitimate users and with the application itself. \n\n Usually the main steps of the attack pattern are the following: \n• cookie collection \n• cookie reverse engineering \n• cookie manipulation \n\n Another pattern of attack consists of overflowing a cookie. Strictly speaking, this attack has a different nature, since here testers are not trying to recreate a perfectly valid cookie. Instead, the goal is to overflow a memory area, thereby interfering with the correct behavior of the application.", + "002": "Cookies are often a key attack vector for malicious users and the application should always take due diligence to protect cookies. This section looks at how an application can take the necessary precautions when assigning cookies, and how to test that these attributes have been correctly configured. \n\n Due to the sensitive nature of information in cookies, they are typically encoded or encrypted in an attempt to protect the information they contain. \n Once the tester has an understanding of how cookies are set, when they are set, what they are used for, why they are used, and their importance, they should take a look at what attributes can be set for a cookie and how to test if they are secure. \n\nBy using an intercepting proxy or traffic intercepting browser plugin, trap all responses where a cookie is set by the application (using the Set-cookie directive) and inspect the cookie for the following:\n• Secure Attribute\n• HttpOnly Attribute\n• Domain Attribute\n• Path Attribute\n• Expires Attribute", + "003": "When an application does not renew its session cookie(s) after a successful user authentication, it could be possible to find a session fixation vulnerability and force a user to utilize a cookie known by the attacker. In that case, an attacker could steal the user session (session hijacking).\n\n Session fixation vulnerabilities occur when..\n .. a web application authenticates a user without first invalidating the existing session ID, thereby continuing to use the session ID already associated with the user \n.. an attacker is able to force a known session ID on a user so that, once the user authenticates, the attacker has access to the authenticated session. \n\n In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using the same session identifier, giving the attacker access to the user’s account through the active session.", + "004": "The Session Tokens (Cookie, SessionID, Hidden Field), if exposed, will usually enable an attacker to impersonate a victim and access the application illegitimately. It is important that they are protected from eavesdropping at all times, particularly whilst in transit between the client browser and the application servers. \n\n Using a personal proxy, it is possible to ascertain the following about each request and response: \n • Protocol used (e.g., HTTP vs. HTTPS) \n • HTTP Headers \n • Message Body (e.g., POST or page content) \n\n Protection from eavesdropping is often provided by SSL encryption, but may incorporate other tunneling or encryption. If the Session ID could be presented by an attacker to the application to gain access, then it must be protected in transit to mitigate that risk. It should therefore be ensured that encryption is both the default and enforced for any request or response where the Session ID is passed, regardless of the mechanism used. \n\n Every time the authentication is successful, the user should expect to receive: \n• A different session token \n• A token sent via encrypted channel for every HTTP Request ", + "005": "CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated.\nA successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is the administrator account, a CSRF attack can compromise the entire web application. \n CSRF relies on the following: \n\n Point 1: \n Web browser behavior regarding the handling of session-related information such as cookies and http authentication information; \n\n Point 2: \n Knowledge by the attacker of valid web application URLs; \n\n Point 3: \n Application session management relying only on information which is known by the browser; \n\n Point 4: \n Existence of HTML tags whose presence cause immediate access to an http[s] resource; for example the image tag img \n\n The tester must know URLs in the restricted (authenticated) area. If they possess valid credentials, they can assume both roles – the attacker and the victim. In this case, testers know the URLs to be tested just by browsing around. \n\n If session management relies only on client side values (information available to the browser), then the application is vulnerable. \n For an application to not be vulnerable, it must include session-related information in the URL, in a form of unidentifiable or unpredictable by the user.", + "006": "Session termination is an important part of the session lifecycle. Reducing to a minimum the lifetime of the session tokens decreases the likelihood of a successful session hijacking attack. This can be seen as a control against preventing other attacks like Cross Site Scripting and Cross Site Request Forgery. Such attacks have been known to rely on a user having an authenticated session present. \n\n A secure session termination requires at least the following components: \n • Availability of user interface controls that allow the user to manually log out \n • Session termination after a given amount of time without activity (session timeout) \n • Proper invalidation of server-side session state \n\n The proper value for the session timeout depends on the purpose of the application and should be a balance of security and usability.", + "007": "In this phase testers check that the application automatically logs out a user when that user has been idle for a certain amount of time, ensuring that it is not possible to “reuse” the same session and that no sensitive data remains stored in the browser cache. \n\n The idle timeout limits the chances that an attacker has to guess and use a valid session ID from another user, and under certain circumstances could protect public computers from session reuse. Session timeout management and expiration must be enforced server-side. If some data under the control of the client is used to enforce the session timeout, an attacker could manipulate these to extend the session duration. \n\n Step 1: \nTesters have to check whether a timeout exists, for instance, by logging in and waiting for the timeout log out to be triggered. As in the log out function, after the timeout has passed, all session tokens should be destroyed or be unusable. \n\n Step 2: \n If the timeout is configured, testers need to understand whether the timeout is enforced by the client or by the server. \n\n As a general rule, everything should be checked server-side and it should not be possible, by re-setting the session cookies to previous values, to access the application again.", + "008": "Session Variable Overloading (Session Puzzling) is an application level vulnerability which can enable an attacker to perform a variety of malicious actions, including by not limited to.. \n.. bypass efficient authentication enforcement mechanisms, and impersonate legitimate users. \n.. elevate the privileges of a malicious user account, in an environment that would otherwise be considered foolproof. \n.. skip over qualifying phases in multi-phase processes, even if the process includes code level restrictions. \n.. manipulate server-side values in indirect methods that cannotbe predicted or detected. \n.. execute traditional attacks in locations that were previously unreachable, or even considered secure. \n\n This vulnerability occurs when an application uses the same session variable for more than one purpose. It can be detected and exploited by enumerating all of the session variables used by the application and in which context they are valid. In particular this is possible by accessing a sequence of entry points and then examining exit points." + }, + "inpval": { + "001": "Reflected Cross-site Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response. \nThe injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page. \nThe attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim. One of the primary difficulties in preventing XSS vulnerabilities is proper character encoding. \n In some cases, the web server or the web application could not be filtering some encodings of characters, so, for example, the web application might filter out “ to the affected page URL which would, when executed, display the alert box. In this instance, the appended code would not be sent to the server as everything after the # character is not treated as part of the query by the browser but as a fragment. \n\n Testing for DOM-Based XSS vulnerabilities:\n Blackbox testing for DOM-Based XSS is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed. \n Many websites rely on large libraries of functions, which often stretch into the hundreds of thousands of lines of code and have not been developed in-house. In these cases, top-down testing often becomes the only really viable option. \n The same can also be said for top-down testing if the inputs or lack thereof is not identified to begin with. User input comes in two main forms: \n • Input written to the page by the server in a way that does not allow direct XSS \n • Input obtained from client-side JavaScript objects \n\n Automated testing has only very limited success at identifying and validating DOM-based XSS as it usually identifies XSS by sending a specific payload and attempts to observe it in the server response. \n Manual testing should therefore be undertaken and can be done by examining areas in the code where parameters are referred to that may be useful to an attacker.", + "002": "A JavaScript Injection vulnerability is a subtype of Cross Site Scripting (XSS) that involves the ability to inject arbitrary JavaScript code that is executed by the application inside the victim’s browser. \n This vulnerability can have many consequences, like disclosure of a user’s session cookies that could be used to impersonate the victim, or, more generally, it can allow the attacker to modify the page content seen by the victims or the application behavior. \n\n Such vulnerability occurs when the application lacks of a proper user supplied input and output validation. JavaScript is used to dynamically populate web pages, this injection occur during this content processing phase and consequently affect the victim. \n When trying to exploit this kind of issues, consider that some characters are treated differently by different browsers.", + "003": "HTML injection is a type of injection issue that occurs when a\nuser is able to control an input point and is able to inject arbitrary HTML code into a vulnerable web page. \nThis vulnerability can have many consequences, like disclosure\nof a user’s session cookies that could be used to impersonate the\nvictim, or, more generally, it can allow the attacker to modify the\npage content seen by the victims. \n\n This vulnerability occurs when the user input is not correctly sanitized and the output is not encoded. An injection allows the attacker to send a malicious HTML page to a victim. The targeted browser will not be able to distinguish (trust) the legit from the malicious parts and consequently will parse and execute all as legit in the victim context. \n\n There is a wide range of methods and attributes that could be used to render HTML content. If these methods are provided with an untrusted input, then there is an high risk of XSS. \n Malicious HTML code could be injected for example via innerHTML, that is used to render user inserted HTML code. An improper usage of this property, that means lack of sanitization from untrusted input and missing output encoding. \n If strings are not correctly sanitized the problem could lead to XSS based HTML injection.\n Another method could be document.write() \n\n When trying to exploit this kind of issues, consider that some characters are treated differently by different browsers.", + "004": "Client Side URL Redirection, also known as Open Redirection, is an input validation flaw that exists when an application accepts an user controlled input which specifies a link that leads to an external URL that could be malicious. \nThis kind of vulnerability could be used to accomplish a phishing attack or redirect a victim to an infection page. \n\nThis vulnerability occurs when an application accepts untrusted input that contains an URL value without sanitizing it. This URL value could cause the web application to redirect the user to another page as, for example, a malicious page controlled by the attacker. \n\n By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials.\n Moreover open redirections could also be used to maliciously craft an URL that would bypass the application’s access control checks and then forward the attacker to privileged functions that they would normally not be able to access. \n\n Testing for Client Side URL Redirect vulnerabilities: \nWhen testers have to manually check for this type of vulnerability they have to identify if there are client side redirections implemented in the client side code. \n These redirections could be implemented, for example in JavaScript, using the “window.location” object that can be used to take the browser to another page by simply assigning a string to it. If the script does not perform any validation of the variable “redir”, then this unvalidated input is passed to the windows.location object originating a URL redirection vulnerability.", + "005": "A CSS Injection vulnerability involves the ability to inject arbitrary CSS code in the context of a trusted web site, and this will be rendered inside the victim’s browser. \nThe impact of such a vulnerability may vary on the basis of the supplied CSS payload: it could lead to Cross-Site Scripting in particular circumstances, to data exfiltration in the sense of extracting sensitive data or to UI modifications. \n\n Such a vulnerability occurs when the application allows to supply user-generated CSS or it is possible to somehow interfere with the legit stylesheets. \n Injecting code in the CSS context gives the attacker the possibility to execute JavaScript in certain conditions as well as extracting sensitive values through CSS selectors and functions able to generate HTTP requests. \n\n Specifically the attacker could target the victim by asking her to visit the following URLs: \n • www.victim.com/#red;-o-link:’javascript:alert(1)’;-o-linksource:current; (Opera [8,12]) \n • www.victim.com/#red;-:expression(alert(URL=1)); (IE 7/8) \n\n Much more interesting attack scenarios involve the possibility to extract data through the adoption of pure CSS rules. \nSuch attacks can be conducted through CSS selectors and leading for instance to grab anti-CSRF tokens. \n\n Testing for CSS Injection vulnerabilities: \n Manual testing needs to be conducted and the JavaScript code analyzed in order to understand whether the attackers can inject its own content in CSS context. In particular we should be interested in how the website returns CSS rules on the basis of the inputs.", + "006": "A ClientSide Resource Manipulation vulnerability is an input validation flaw that occurs when an application accepts an user controlled input which specifies the path of a resource (i.e. source of an iframe, js, applet). \nSpecifically, such a vulnerability consists in the ability to control the URLs which link to some resources present in a web page. \n The impact may vary on the basis of the type of\the element whose URL is controlled by the attacker, and it is usually adopted to conduct Cross-Site Scripting attacks. \n\n Such a vulnerability occurs when the application employs user\ncontrolled URLs for referencing external/internal resources. \n In these circumstances it is possible to interfere with the expected application’s behavior in the sense of making it load and render malicious objects. \n\n Testing for Client Side Resource Manipulation vulnerabilities:\nTo manually check for this type of vulnerability we have to identify whether the application employs inputs without correctly validating them; these are under the control of the user which could be able to specify the url of some resources. \n Since there are many resources that could be included into the application, client side scripts which handle the associated URLs should be investigated for potential issues. \n\n The following shows the possible injection points (sink) that should be checked: \n • Resource: Frame \n • Tag/Method: iframe \n • Sink: src \n\n • Resource: Link \n • Tag/Method: a \n • Sink: href\n\n • Resource: AJAX Request \n • Tag/Method: xhr.open(method, [url], true); \n • Sink: URL href\n\n • Resource: CSS \n • Tag/Method: link \n\n • Resource: Image \n • Tag/Method: img \n\n • Resource: Object \n • Tag/Method: object \n • Sink: src\n\n • Resource: Script \n • Tag/Method: script \n • Sink: data src", + "007": "Cross Origin Resource Sharing or CORS is a mechanism that enables a web browser to perform “cross-domain” requests using the XMLHttpRequest L2 API in a controlled manner. \n In the past, the XMLHttpRequest L1 API only allowed requests to be sent within the same origin as it was restricted by the same origin policy. \n\n Cross-Origin requests have an Origin header, that identifies the domain initiating the request and is always sent to the server. CORS defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed. \n In order to accomplish this goal, there are a few HTTP headers involved in this process, that are supported by all major browsers including: \n • Origin \n • Access-Control-Request-Method \n • Access-Control-Request-Headers \n • Access-Control-Allow-Origin \n • Access-Control-Allow-Credentials \n • Access-Control-Allow-Methods \n • Access-Control-Allow-Headers \n\n The CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will have a bad impact on the data.\n The pre-flight request checks the methods, headers allowed by the server, and if credentials are permitted, based on the result of the OPTIONS request, the browser decides whether the request is allowed or not. \n\n Check the HTTP headers in order to understand how CORS is used, in particular we should be very interested in the Origin header to learn which domains are allowed. \n Also, manual inspection of the JavaScript is needed to determine whether the code is vulnerable to code injection due to improper handling of user supplied input.", + "008": "ActionScript is the language, based on ECMAScript, used by Flash applications when dealing with interactive needs. \n There are three\nversions of the ActionScript language. ActionScript 1.0 and ActionScript 2.0 are very similar with ActionScript 2.0 being an extension of ActionScript 1.0. ActionScript 3.0, introduced with Flash Player 9, is a rewrite of the language to support object orientated design. \n\n ActionScript, like every other language, has some implementation patterns which could lead to security issues.\n In particular, since Flash applications are often embedded in browsers, vulnerabilities like DOM based Cross-Site Scripting (XSS) could be present in flawed Flash applications.\n\n Decompilation \n Since SWF files are interpreted by a virtual machine embedded in the player itself, they can be potentially decompiled and analysed. The most known and free ActionScript 2.0 decompiler is flare. \n Decompilation helps testers because it allows for source code assisted, or white-box, testing of the Flash applications. HP’s free SWFScan tool can decompile both ActionScript 2.0 and ActionScript 3.0.\n\n Attacks and Flash Player Version Since May 2007, three new versions of Flash player were released by Adobe. Every new version restricts some of the attacks. \n\n Player Version: v9.0 r47/48 \n • asfunction: Yes \n • Externalinterface: Yes \n • GetURL: Yes \n • HTML Injection: Yes\n\n Player Version: v9.0 r115 \n • asfunction: No \n • Externalinterface: Yes \n • GetURL: Yes \n • HTML Injection: Yes\n\n Player Version: v9.0 r124 \n • asfunction: No \n • Externalinterface: Yes \n • GetURL: Yes \n • HTML Injection: Partially", + "009": "“Clickjacking” (which is a subset of the “UI redressing”) is a malicious technique that consists of deceiving a web user into interacting with something different to what the user believes they are interacting with. \n This type of attack, that can be used alone or in combination with other attacks, could potentially send unauthorized commands or reveal confidential information while the victim is interacting on seemingly harmless web pages. \n\n A Clickjacking attack uses seemingly innocuous features of HTML and Javascript to force the victim to perform undesired actions, such as clicking on a button that appears to perform another operation. \n\n To carry out this type of technique the attacker has to create a seemingly harmless web page that loads the target application through the use of an iframe. \n Once this is done, the attacker could induce the victim to interact with his fictitious web page.\nOnce the victim is surfing on the fictitious web page, he thinks that he is interacting with the visible user interface, but effectively he is performing actions on the hidden page.\n\nThis type of attack is often designed to allow an attacker site to induce user’s actions on the target site even if anti-CSRF tokens are being used. . So it’s important, like for the CSRF attack, to individuate web pages of the target site that it take input from the user.\n\nWe have to discover if the website that we are testing has no protections against clickjacking attacks or, if the developers have implemented some forms of protection, if these techniques are liable to bypass. \nMethods to protect a web page from clickjacking can be divided in two macro-categories: \n • Client side protection: Frame Busting \n • Server side protection: X-Frame-Options \n\n Some frame busting techniques try to break frame by assigning a value to the “parent.location” attribute in the “counter-action” statement. Such actions are, for example: \n • self.parent.location = document.location \n • parent.location.href = self.location \n • parent.location = self.location", + "010": "Traditionally the HTTP protocol only allows one request/response per TCP connection. Asynchronous JavaScript and XML (AJAX) allows clients to send and receive data asynchronously to the server, however, AJAX requires the client to initiate the requests and wait for the server responses (half-duplex). \n\n HTML5 WebSockets allow the client/server to create a ‘full-duplex’ (two-way) communication channels, allowing the client and server to truly communicate asynchronously. WebSockets conduct their initial ‘upgrade’ handshake over HTTP and from then on all communication is carried out over TCP channels by use of frames. \n\n 1: Identify that the application is using WebSockets \n • Inspect the client-side source code for the ws:// or wss:// URI scheme\n • Use Browser Developer Tools to view the Network WebSocket communication \n • Use OWASP Zed Attack Proxy (ZAP)’s WebSocket tab \n\n 2: Origin \n • Using a WebSocket client attempt to connect to the remote WebSocket server \n • If a connection is established the server may not be checking the origin header of the WebSocket handshake \n\n 3: Confidentiality and Integrity \n • Check that the WebSocket connection is using SSL to transport sensitive information (wss://) \n • Check the SSL Implementation for security issues s (Valid Certificate, BEAST, CRIME, RC4, etc). \n\n 4: Authentication \n • WebSockets do not handle authentication, normal black box authentication tests should be carried out \n\n 5: Authorization \n • WebSockets do not handle authorization, normal black-box authorization tests should be carried out \n\n 6: Input Sanitization \n • Use OWASP Zed Attack Proxy (ZAP)’s WebSocket tab to replay and fuzz WebSocket request and responses", + "011": "Web Messaging (also known as Cross Document Messaging) allows applications running on different domains to communicate in a secure manner. \n This restriction within the browser is in place to restrict a malicious website to read confidential data from other iframes, tabs, etc, however there are some legitimate cases where two trusted websites need to exchange data between each other. To meet this need Cross Document Messaging was introduced within he WHATWG HTML5 draft specification and implemented in all major browsers. \n It enables secure communication between multiple origins across iframes, tabs and windows. \n\n The Messaging API introduced the postMessage() method, with which plain-text messages can be sent cross-origin. It consists of two parameters, message and domain. \n\n There are some security concerns when using ‘*’ as the domain that we discuss below. Then, in order to receive messages the receiving website needs to add a new event handler, and has the following attributes: \n • data: The content of the incoming message \n • origin: The origin of the sender document \n • source: source window \n\nManual testing needs to be conducted and the JavaScript code analyzed looking for how Web Messaging is implemented. \nIn particular we should be interested in how the website is restricting messages from untrusted domain and how the data is handled even for trusted domains.", + "012": "Local Storage also known as Web Storage or Offline Storage is a mechanism to store data as key/value pairs tied to a domain and enforced by the same origin policy (SOP). \n There are two objects, localStorage that is persistent and is intended to survive browser/system reboots and sessionStorage that is temporary and will only exists until the window or tab is closed. \n On average browsers allow to store in this storage around 5MB per domain, that compared to the 4KB of cookies is a big difference, but the key difference from the security perspective is that the data stored in these two objects is kept in the client and never sent to the server. \n\n First of all, we need to check whether the Local Storage is used. This can be checked when using the Browser Tool and then go under Resources you will see ‘Local Storage’ and ‘Web Storage’. \n\n Next manual testing needs to be conducted in order to determine whether the website is storing sensitive data in the storage that represents a risk and will increase dramatically the impact of a information leak. \n Also check the code handling the Storage to determine if it is vulnerable to injection attacks, common issue when the code does not escape the input or output." + }, + "no_info": "No information for given reference number found." } } diff --git a/security-c4po-angular/src/shared/functions/categories/INPVAL/pentests.function.ts b/security-c4po-angular/src/shared/functions/categories/INPVAL/pentests.function.ts index 91722cc..8ac68bd 100644 --- a/security-c4po-angular/src/shared/functions/categories/INPVAL/pentests.function.ts +++ b/security-c4po-angular/src/shared/functions/categories/INPVAL/pentests.function.ts @@ -27,40 +27,45 @@ export function getINPVAL_Pentests(): Pentest[] { { category: Category.INPUT_VALIDATION_TESTING, refNumber: 'OTG-INPVAL-005', - status: PentestStatus.NOT_STARTED - }, - { - category: Category.INPUT_VALIDATION_TESTING, - refNumber: 'OTG-INPVAL-006', status: PentestStatus.NOT_STARTED, childEntries: [ { category: Category.INPUT_VALIDATION_TESTING, - refNumber: 'OTG-INPVAL-006_1', + refNumber: 'OTG-INPVAL-005_1', status: PentestStatus.NOT_STARTED }, { category: Category.INPUT_VALIDATION_TESTING, - refNumber: 'OTG-INPVAL-006_2', + refNumber: 'OTG-INPVAL-005_2', status: PentestStatus.NOT_STARTED }, { category: Category.INPUT_VALIDATION_TESTING, - refNumber: 'OTG-INPVAL-006_3', + refNumber: 'OTG-INPVAL-005_3', status: PentestStatus.NOT_STARTED }, { category: Category.INPUT_VALIDATION_TESTING, - refNumber: 'OTG-INPVAL-006_4', + refNumber: 'OTG-INPVAL-005_4', status: PentestStatus.NOT_STARTED }, { category: Category.INPUT_VALIDATION_TESTING, - refNumber: 'OTG-INPVAL-006_5', + refNumber: 'OTG-INPVAL-005_5', + status: PentestStatus.NOT_STARTED + }, + { + category: Category.INPUT_VALIDATION_TESTING, + refNumber: 'OTG-INPVAL-005_6', status: PentestStatus.NOT_STARTED }, ] }, + { + category: Category.INPUT_VALIDATION_TESTING, + refNumber: 'OTG-INPVAL-006', + status: PentestStatus.NOT_STARTED + }, { category: Category.INPUT_VALIDATION_TESTING, refNumber: 'OTG-INPVAL-007', @@ -89,61 +94,56 @@ export function getINPVAL_Pentests(): Pentest[] { { category: Category.INPUT_VALIDATION_TESTING, refNumber: 'OTG-INPVAL-012', - status: PentestStatus.NOT_STARTED + status: PentestStatus.NOT_STARTED, + childEntries: [ + { + category: Category.INPUT_VALIDATION_TESTING, + refNumber: 'OTG-INPVAL-012_1', + status: PentestStatus.NOT_STARTED + }, + { + category: Category.INPUT_VALIDATION_TESTING, + refNumber: 'OTG-INPVAL-012_2', + status: PentestStatus.NOT_STARTED + } + ] }, { category: Category.INPUT_VALIDATION_TESTING, refNumber: 'OTG-INPVAL-013', - status: PentestStatus.NOT_STARTED, - childEntries: [ - { - category: Category.INPUT_VALIDATION_TESTING, - refNumber: 'OTG-INPVAL-013_1', - status: PentestStatus.NOT_STARTED - }, - { - category: Category.INPUT_VALIDATION_TESTING, - refNumber: 'OTG-INPVAL-013_2', - status: PentestStatus.NOT_STARTED - } - ] - }, - { - category: Category.INPUT_VALIDATION_TESTING, - refNumber: 'OTG-INPVAL-014', status: PentestStatus.NOT_STARTED }, { category: Category.INPUT_VALIDATION_TESTING, - refNumber: 'OTG-INPVAL-015', + refNumber: 'OTG-INPVAL-014', status: PentestStatus.NOT_STARTED, childEntries: [ { category: Category.INPUT_VALIDATION_TESTING, - refNumber: 'OTG-INPVAL-015_1', + refNumber: 'OTG-INPVAL-014_1', status: PentestStatus.NOT_STARTED }, { category: Category.INPUT_VALIDATION_TESTING, - refNumber: 'OTG-INPVAL-015_2', + refNumber: 'OTG-INPVAL-014_2', status: PentestStatus.NOT_STARTED }, { category: Category.INPUT_VALIDATION_TESTING, - refNumber: 'OTG-INPVAL-015_3', + refNumber: 'OTG-INPVAL-014_3', status: PentestStatus.NOT_STARTED } ] }, + { + category: Category.INPUT_VALIDATION_TESTING, + refNumber: 'OTG-INPVAL-015', + status: PentestStatus.NOT_STARTED + }, { category: Category.INPUT_VALIDATION_TESTING, refNumber: 'OTG-INPVAL-016', status: PentestStatus.NOT_STARTED }, - { - category: Category.INPUT_VALIDATION_TESTING, - refNumber: 'OTG-INPVAL-017', - status: PentestStatus.NOT_STARTED - }, ]; } diff --git a/security-c4po-angular/src/shared/functions/infos/get-pentest-info-for-objective.ts b/security-c4po-angular/src/shared/functions/infos/get-pentest-info-for-objective.ts new file mode 100644 index 0000000..81ed371 --- /dev/null +++ b/security-c4po-angular/src/shared/functions/infos/get-pentest-info-for-objective.ts @@ -0,0 +1,64 @@ +export function getPentestInfoForObjective(refNumber: string): string { + let translationKey = 'objectives.'; + let subRefNumberKey; + const refNumberKey = refNumber.slice(refNumber.length - 3); + const HTMLsuffix = '_html'; + + switch (true) { + case refNumber.includes('INFO'): { + translationKey += 'info.' + refNumberKey; + break; + } + case refNumber.includes('CONFIG'): { + translationKey += 'config.' + refNumberKey; + break; + } + case refNumber.includes('IDENT'): { + translationKey += 'ident.' + refNumberKey; + break; + } + case refNumber.includes('AUTHN'): { + translationKey += 'authn.' + refNumberKey; + break; + } + case refNumber.includes('AUTHZ'): { + translationKey += 'authz.' + refNumberKey; + break; + } + case refNumber.includes('SESS'): { + translationKey += 'sess.' + refNumberKey; + break; + } + case refNumber.includes('INPVAL'): { + if (refNumber.includes('_')) { + subRefNumberKey = refNumber.slice(refNumber.length - 5); + translationKey += 'inpval.' + subRefNumberKey; + } else { + translationKey += 'inpval.' + refNumberKey; + } + break; + } + case refNumber.includes('ERR'): { + translationKey += 'err.' + refNumberKey; + break; + } + case refNumber.includes('CRYPST'): { + translationKey += 'crypst.' + refNumberKey; + break; + } + case refNumber.includes('BUSLOGIC'): { + translationKey += 'buslogic.' + refNumberKey; + break; + } + case refNumber.includes('CLIENT'): { + translationKey += 'client.' + refNumberKey; + break; + } + default: { + translationKey = 'objectives.no_info'; + console.error('Invalid category number: ', refNumber.slice(4 - refNumber.length)); + break; + } + } + return translationKey; +} diff --git a/security-c4po-angular/src/shared/stores/project-state/project-state.ts b/security-c4po-angular/src/shared/stores/project-state/project-state.ts index 1a1ba25..f6f3310 100644 --- a/security-c4po-angular/src/shared/stores/project-state/project-state.ts +++ b/security-c4po-angular/src/shared/stores/project-state/project-state.ts @@ -12,7 +12,7 @@ export interface ProjectStateModel { // Manages Categories disabledCategories: Array; selectedCategory: Category; - // Manages Pentests of Category + // Manages objectives of Category disabledPentests: Array; selectedPentest: Pentest; } diff --git a/security-c4po-api/src/test/kotlin/com/securityc4po/api/pentest/PentestControllerIntTest.kt b/security-c4po-api/src/test/kotlin/com/securityc4po/api/pentest/PentestControllerIntTest.kt index 712a34e..e8c8dac 100644 --- a/security-c4po-api/src/test/kotlin/com/securityc4po/api/pentest/PentestControllerIntTest.kt +++ b/security-c4po-api/src/test/kotlin/com/securityc4po/api/pentest/PentestControllerIntTest.kt @@ -110,7 +110,7 @@ class PentestControllerIntTest : BaseIntTest() { category = PentestCategory.INFORMATION_GATHERING, title = "Fingerprint Web Server", refNumber = "OTG-INFO-002", - status = PentestStatus.COMPLETED, + status = PentestStatus.IN_PROGRESS, findingIds = emptyList(), commentIds = emptyList() )