Security Testing Guide

Motivation und Ziele

Ein Datentreuhänder (DTH) verwaltet Daten von Datengebenden und stellt diese Datennutzenden zur Verfügung. Um dabei das Vertrauen zwischen beiden Stakeholdern zu stärken, ist die Einhaltung gängiger Sicherheitsstandards womöglich eine der wichtigsten Anforderungen, die ein DTH umzusetzen hat.

Angesichts der zunehmenden Bedrohungen durch Cyberkriminalität und Datenschutzverletzungen ist es unerlässlich, dass Betreiber von DTH ihre Sicherheitsvorkehrungen ständig überprüfen und verbessern, um zu gewährleisten, dass die von ihnen verwalteten Daten sicher und geschützt bleiben.

Ein Prüfkatalog kann dabei helfen, sicherzustellen, dass alle relevanten Bereiche der Datensicherheit geprüft werden und dass der DTH die erforderlichen Sicherheitsstandards erfüllt.

In diesem Prüfkatalog werden verschiedene Aspekte der Datensicherheit wie sichere Konfiguration und sicheres Deployment, Authentisierung und Autorisierung, Identity und Session Management, Eingabevalidierung oder Clientsicherheit betrachtet. Dabei orientiert sich der Katalog an dem OWASP Web Security Testing Guide (WSTG). Da dieser jedoch in seiner Art eher deskriptiv ist, wurden konkrete Prüfkriterien abgeleitet, welche die Bewertung des Sicherheitsniveaus eines zu prüfenden DTH erleichtern sollen.

Eine gründliche Überprüfung der oben genannten Bereiche kann dazu beitragen, dass die Betreiber von DTH ihre Sicherheitsmaßnahmen verbessern und somit das Vertrauen der Kunden und Nutzer in die Sicherheit ihrer Daten stärken.

Der OWASP Web Security Testing Guide

Aus technischer Sicht sind DTH in den meisten Fällen als Webanwendung realisiert. Daher gelten für DTH auch viele Sicherheitsanforderungen, wie sie auch für Webanwendungen gelten.

Für das Security-Testing von Webanwendungen hat sich der OWASP Web Security Testing Guide (WSTG) unter weiteren Best Practices, Leitfäden und Guidelines als wegweisend etabliert. Er ist ein umfassender Leitfaden für die Durchführung von Sicherheitstests an Webanwendungen. Er wurde entwickelt, um Entwicklern, Testern und Sicherheitsprofis einen umfassenden Überblick über die Methoden, Techniken und Tools zu geben, die bei der Durchführung von Web-Sicherheitstests angewendet werden können.

Der Leitfaden wurde von einem Team von Fachleuten aus der Web-Sicherheitsbranche zusammengestellt und enthält eine detaillierte Beschreibung von Techniken und Methoden, die bei der Identifizierung von Sicherheitslücken und Schwachstellen in Webanwendungen eingesetzt werden können. Der OWASP WSTG ist eine praxisorientierte Ressource, die darauf abzielt, Sicherheitsprobleme in Webanwendungen aufzudecken und entsprechende Maßnahmen zur Behebung dieser Probleme zu empfehlen.

Der Leitfaden ist in verschiedene Abschnitte unterteilt, die sich auf verschiedene Aspekte der Web-Sicherheit konzentrieren, wie z.B. Identifizierung von Schwachstellen, Risikobewertung, Testplanung und Testdurchführung. Jeder Abschnitt enthält eine detaillierte Beschreibung der Techniken, Methoden und Tools, die zur Durchführung von Tests in diesem Bereich eingesetzt werden können.

Insgesamt ist der OWASP Web Security Testing Guide ein unverzichtbares Werkzeug für alle, die mit der Entwicklung und dem Testen von Webanwendungen betraut sind, da er dazu beitragen kann, die Sicherheit von Webanwendungen zu erhöhen und das Risiko von Angriffen und Datenschutzverletzungen zu minimieren.

Prüfkatalog für Datentreuhänder

Dieses Kapitel bildet den Hauptteil des Prüfkatalogs. Gemäß den einzelnen Themenbereichen des OWASP WSTG werden hier die Prüfpunkte aufgeführt. Das Schema eines Prüfpunktes ist dabei stets gleich: Das Threat scenario beschreibt einen oder mehrere Techniken von Angreifern zum Ausnutzen bestimmter Schwachstellen. Das Objective beschreibt das Ziel, das Betreiber von DTH verfolgen sollten, um das Risiko für das Threat scenario zu minimieren. Die Definition of done beschreibt die eigentlichen Prüfpunkte, die seitens der Betreiber, Entwickler und Administratoren umgesetzt werden müssen, um dem Threat scenario entgegenzuwirken.

Die Definition of Done ist hier als Minimum zu verstehen und hat genauso wenig Anspruch auf Vollständigkeit, wie es einen Anspruch auf vollständige IT-Sicherheit gibt. Dieser Prüfkatalog ist als lebendes Dokument zu verstehen, das permanent weiterentwickelt und aktualisiert werden muss, um mittel- bis langfristig ein hohes Sicherheitsniveau für DTH-Implementierungen zu erreichen.

An einigen Stellen sind die Prüfpunkte in diesem Dokument relativ generalistisch gehalten. Hier liegen die tatsächliche Umsetzung und insbesondere der Umfang der Prüfung im Ermessen des DTH-Betreibers. In manchen Fällen kann es ausreichen, stichprobenhaft zu überprüfen, in manchen muss automatisiert oder gar zusätzlich manuell überprüft werden.

Das Kapitel „Testing for Business Logic“, das ursprünglich im OWASP WSTG vorkommt, wurde aus dem Prüfkatalog gestrichen wurde, da es auf konzeptioneller Ebene alles behandelt, was bereits in den anderen Kapiteln aus technischer Sicht beschrieben wird. Die Betrachtung der Business Logic liegt nicht im Scope dieses Dokuments.

Abschließend sei erwähnt, dass dieser Katalog die Sicht von Entwickler und Betreiber annimmt, der OWASP WSTG jedoch häufig die Perspektive von Testern, die in Black- oder Graybox-Szenarien keine oder nur beschränkte Kenntnis über den Code haben. Da hier jedoch eine vollständige Kenntnis über den Code angenommen wird, können viele Schwachstellen zusammengefasst werden, da ihre Ursache häufig die gleiche ist, (z.B. fehlende oder fehlerhafte Inputvalidierung bei vielen Injection-Schwachstellen) und die Präventionsmaßnahmen entsprechend auch übereinstimmen (z.B. ordnungsgemäße Eingabevalidierung).

Informationsbeschaffung

Die Sammlung von Informationen über das System oder die Anwendung, um mögliche Angriffsvektoren oder Schwachstellen zu identifizieren, ist typischerweise der erste Schritt bei einem Angriffsversuch auf ein System.

Die Informationsbeschaffung kann verschiedene Methoden umfassen, wie beispielsweise die Durchführung von Portscans, Netzwerkscans, Recherche von öffentlichen Informationen über das System oder die Anwendung, Durchführung von Angriffen mit geringer Auswirkung, wie etwa Fingerprinting, und Social Engineering-Techniken.

Ziel der Informationsbeschaffung im Security Testing ist es, das System oder die Anwendung aus Sicht eines potenziellen Angreifers zu betrachten und zu identifizieren, welche Informationen zugänglich sind. Durch diese Art von Tests können frühzeitig und minimalinvasiv Schwachstellen aufgedeckt werden, die sonst möglicherweise übersehen werden könnten.

Der Großteil der Prüfpunkte in diesem Abschnitt setzt voraus, dass der DTH bereits aktiv in Betrieb und öffentlich erreichbar ist. Sofern der zu untersuchende DTH noch nicht in diesem Stadium ist, kann die Prüfung der entsprechenden Punkte bis zum Go-Live vorübergehend ausgesetzt werden.

Die Prüfpunkte aus diesem Prüfabschnitt wurden vom OWASP Web Security Testing Guide, Kapitel 4.1 („Information Gathering“) abgeleitet. Die folgenden Unterkapitel wurden nicht berücksichtigt:

Leaks durch gezielte Suchmaschinenanfragen 🔗

Threat scenario:

Angreifer können sensible Design- und Konfigurationsinformationen des DTH und dessen betreibender Organisation mittels gängiger Suchmaschinen ausfindig machen. Durch gezielte Manipulation der Suchqueries (site, inurl, intitle, intext, inbody, filetype) lassen sich hier gezielt Informationen aus einzelnen Webseiten filtern. Dabei ist es unerheblich, ob die Informationen direkt (auf der Website der Organisation) oder indirekt (über Dienste von Drittanbietern) bezogen werden können. Sensible Inhalte können beispielsweise betriebsinterne oder vertrauliche Dokumente, Konfigurationsdaten von Systemen oder Credentials sein.

Objective:

Die Betreiber von DTH müssen sicherzustellen, dass Angreifer keine kritischen Daten und Dateien über gezielte Suchmaschinensuche identifizieren können. Zur Überprüfung sind explizit mehrere Suchmaschinen zu verwenden, da verschiedene Anbieter auch verschiedene Suchmaschinenergebnisse produzieren können.

Definition of Done:

Webserver-Fingerprinting 🔗

Threat scenario:

Gezielte Requests an Webserver liefern häufig eine Antwort, die Rückschlüsse auf die verwendete Applikation, einschließlich deren Version, erlauben. Diese Informationen werden je nach Anwendung unter Umständen in den Response-Header geschrieben und können so unmittelbar ausgelesen werden („Banner-Grabbing“). Hierzu helfen häufig einfachste Kommandozeilentools zum Senden von HTTP-Requests, beispielsweise Netcat (nc).

Objective:

Beim Deployment eines DTH müssen die Betreiber darauf achten, dass keine der nach außen bereitgestellten Dienste die verwendeten Anwendungen und Versionen preisgibt. Das Obfuszieren der Responses kann hierbei meist in den Konfigurationen der jeweiligen Anwendung vorgenommen werden.

Definition of Done:

Webserver-Metadaten 🔗

Threat scenario:

Standardmäßig stellen die meisten Webseiten Dateien zur Verfügung, aus denen beispielsweise Suchmaschinen oder andere automatisierte Tools Metadaten extrahieren können.

Objective:

Die Betreiber von DTH müssen daher sicherstellen, dass Standarddateien keine sensiblen Informationen enthalten.

Definition of Done:

Identifikation von Anwendungen 🔗

Threat scenario:

Port- und Versionsscans gehören zu typischen Aktivitäten innerhalb der Reconnaissance-Phase eines Angriffs. Angreifer können mit Portscannern wie Nmap Services enumerieren und dadurch Anwendungen identifizieren, die möglicherweise nicht für die Öffentlichkeit bestimmt sind, beispielsweise Ports für Debugging oder Remotezugriffe.

Objective:

Beim Deployment müssen Betreiber von DTH darauf zu achten, dass nur die für den Betrieb notwendigen Services bereitgestellt werden. Der Zugriff auf Remote-Protokolle wie etwa SSH sollte auf ein Minimum reduziert werden, sodass sich nur ein ausgewählter Personenkreis in die betroffenen Systeme einloggen kann.

Definition of Done:

Leaks aus Webseiteninhalten 🔗

Threat scenario:

In vielen Release Candidates verbleiben Codefragmente aus der Entwicklungsphase, die ungewollt der Öffentlichkeit zugänglich gemacht werden. Typische Beispiele hierfür sind Kommentare in Code, die Passwörter oder Access Tokens enthalten. Angreifer können diese Informationen einfach auslesen, indem sie beispielsweise den Seitenquelltext mit Browsern analysieren.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass Angreifer keine sensiblen Inhalte in den öffentlichen Teilen des Quelltextes auslesen können.

Definition of Done:

Initial Footholds in Applikationen 🔗

Threat scenario:

Sämtliche Endpunkte, in denen clientseitig Daten an das Backend übergeben werden, stellen eine potenzielle Angriffsfläche dar. Für den Fall, dass die Eingabe an den jeweiligen Endpunkten nicht ordnungsgemäß validiert wird (z.B. bei GET-Query- oder POST-Body-Parametern), können Angreifer aus dem vorgesehenen Scope der Eingabe ausbrechen und im schlechtesten Falle serverseitigen Code ausführen. Bekannte Beispiele hierfür sind SQL und Command Injections sowie Cross-site Scripting; allesamt Schwachstellen, die nach wie vor zu den am häufigsten vorkommenden in Webapplikationen gehören.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass die Parameter aller Request-Endpunkte nach Vorgaben von Best Practices bereinigt werden und vor Missbrauch geschützt sind.

Definition of Done:

Identifikation kritischer Pfade 🔗

Threat scenario:

Kritische Pfade bilden den geläufigsten Eintrittsvektor beim Angriff von Webapplikationen. Ein Angreifer kann hier auf vielfältige Weise tätig werden, beispielsweise durch die Identifikation von kritischen Pfaden, die nicht für die Öffentlichkeit bestimmt sind oder das Ausnutzen von fehlerhafter Eingabevalidierung, wie sie bei SQL-Injections oder Cross-site Scripting Verwendung findet.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass es keine kritischen Pfade gibt, die von Angreifern ausgenutzt werden können.

Definition of Done:

Web-Framework-Fingerprinting 🔗

Threat scenario:

Die Kenntnis eines Angreifers über mögliche Web-Frameworks, zum Beispiel von Drittanbietern, erhöht deren Kenntnisstand über das Zielsystem und erlaubt ihnen, gezielter nach Schwachstellen oder Exploits zu suchen.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass keine sensiblen Informationen über (3rd-Party-) Software nach außen gelangen, die der DTH verwendet.

Definition of Done:

Konfiguration und Deployment

Das Ziel von Konfigurations- und Deployment-Tests im Security Testing ist es, sicherzustellen, dass das System oder die Anwendung sicher und geschützt ist, bevor oder spätestens während das System in einer produktionsnahen Umgebung eingesetzt wird. Durch diesen Prozess können potenzielle Schwachstellen und Angriffspunkte identifiziert werden, bevor sie von böswilligen Angreifern ausgenutzt werden können.

Zusätzlich zu der Überprüfung von Konfigurationseinstellungen und Deployment-Tests können auch andere Tests durchgeführt werden, wie etwa Penetrationstests, um Schwachstellen im System oder in der Anwendung aufzudecken.

Die Prüfpunkte aus diesem Prüfabschnitt wurden vom OWASP Web Security Testing Guide, Kapitel 4.2 („Configuration and Deployment Management Testing“) abgeleitet. Die folgenden Unterkapitel wurden nicht berücksichtigt:

Netzwerkinfrastruktur 🔗

Threat scenario:

Die Suche nach Schwachstellen in der gesamten Netzwerkinfrastruktur gehört zum Standardvorgehen von Angreifern. Nach erfolgreichem Enumerieren der Systeme werden diese in aller Regel auf bekannte Schwachstellen überprüft. Dazu gehören nicht nur öffentlich bekannte Exploits, sondern auch das Identifizieren von Standardbenutzernamen und -passwörtern, die im durch die Verbreitung im Internet mittlerweile in einer Vielzahl von Wordlists gesammelt werden.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass die Netzwerkinfrastruktur so wenig Angriffsfläche wie möglich bietet.

Definition of Done:

Konfiguration der Applikationsplattform 🔗

Threat scenario:

Angreifer können durch gezielte Suche nach Dateinamen von Standarddateien einerseits Rückschlüsse auf die verwendeten Frameworks und Libraries eines DTH ziehen und einerseits bei ihrer Suche auf sensible Daten stoßen.

Objective:

Die Betreiber von DTH müssen, soweit es ihnen möglich ist, auf die Verwendung von Standarddateinamen verzichten. Diese sind nach Möglichkeit so zu Obfuszieren, dass Angreifer nicht automatisiert nach ihnen suchen können.

Definition of Done:

Dateiendungen 🔗

Threat scenario:

Angreifer können bei Webseiten gezielt nach kritischen Dateiendungen suchen. Darunter fallen beispielsweise vertrauliche Konfigurationen oder Backups, die nur für interne Zwecke vorgesehen sind. Darüber hinaus können Angreifer eine zu lockere Policy für Dateiendungen auch missbrauchen, um serverseitig ausführbare Dateien hochzuladen.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass Dateien mit kritischem Dateiformat weder gelesen noch geschrieben werden können.

Definition of Done:

HTTP-Methoden 🔗

Threat scenario:

Der Missbrauch von HTTP-Methoden kann zu vielen verschiedenen Bedrohungsszenarien für DTH werden. Einer hiervon kann beispielsweise ein Cross-site Tracing (XST)-Angriff sein, der durch die Zweckentfremdung der TRACE-Methode ermöglicht wird. Ein anderes Beispiel ist ein Authentication-Bypass-Angriff durch Überschreiben von existierenden Credentials mittels PUT oder POST.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass nicht pauschal alle HTTP-Methoden für alle Endpunkte erlaubt sind. Vielmehr müssen Endpunkte kontextspezifisch sein und nur die nötigsten HTTP-Methoden erlauben. Dies gilt insbesondere für die Methoden PUT und DELETE.

Definition of Done:

HTTP Strict Transport Security 🔗

Threat scenario:

Im Falle von unverschlüsselten Verbindungen können Angreifer möglicherweise den Datenverkehr zwischen Nutzer und DTH abfangen und somit die Vertraulichkeit des DTH beeinträchtigen.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass der DTH HTTP Strict Transport Security (HSTS) verwendet. Dadurch wird erzwungen, dass Clients ausschließlich über HTTPS mit dem DTH kommunizieren.

Definition of Done:

RIA Cross-Domain-Policy 🔗

Threat scenario:

Wenn der DTH einen zu freizügigen Cross-Domain-Zugriff von anderen Webseiten erlaubt, können Angreifer dies als Grundlage für einen Cross-Site-Request-Forgery (CSRF)-Angriff nutzen.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass der erlaubte Zugriff von anderen Domänen auf ein Minimum reduziert wird.

Definition of Done:

Subdomain Takeover 🔗

Threat scenario:

Besitzt der DTH Subdomain-Einträge im Domain Name Server (DNS), die nicht mehr aktiv verwendet werden, können Angreifer bei einem externen Dienst die Subdomain für sich beanspruchen. Im schlechtesten Fall prüft der externe Dienst den Besitz der Subdomain nicht ordnungsgemäß und der Angreifer kann die Subdomain auf eine eigene, schädliche Anwendung zeigen lassen.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass keine unbenutzten Subdomain-Einträge im DNS vorliegen.

Definition of Done:

Identity Management

Im Rahmen von Identity Management-Tests soll sichergestellt werden, dass Benutzerkonten- und Berechtigungen ordnungsgemäß konfiguriert sind. Insbesondere soll in diesem Abschnitt überprüft werden, ob Rollendefinitionen sowie Registrierungs- und Accountbereitstellungsprozesse widerspruchsfrei definiert sind und keinen Spielraum für Authentication Bypass-Angriffe lassen.

Die Prüfpunkte aus diesem Prüfabschnitt wurden vom OWASP Web Security Testing Guide, Kapitel 4.3 („Identity Management Testing“) abgeleitet.

Rollendefinitionen 🔗

Threat scenario:

Die verschiedenen Rollen und Rechte, die in einem DTH umgesetzt werden, können eine erhöhte Angriffsfläche bieten, wenn sie nicht korrekt umgesetzt werden. Ein Angreifer könnte, ausgehend von einer unsachgemäßen Konfiguration des Rollen- und Rechtekonzeptes, eine Privilege Escalation durchführen und sich damit seinen technischen Handlungsspielraum deutlich erhöhen.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass Nutzer ihre eigenen Rollen und Berechtigungen nicht unrechtmäßig manipulieren können.

Definition of Done:

Nutzerregistrierung 🔗

Threat scenario:

Die Registrierung neuer Nutzer ist im Idealfall ein strenger Prozess, der klar definierte Eingabewerte erwartet und in jedem Schritt der Prozesskette ein eindeutiges Vorgehen und eindeutige Verantwortliche benennt. Dabei ist es unerheblich, ob der Registrierungsprozess manuell, teilautomatisiert oder automatisiert erfolgt: In jedem Fall können Angreifer versuchen, aus dem Standardprozess auszubrechen.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass Nutzer nicht unrechtmäßig aus dem Scope des Registrierungsprozesses ausbrechen können.

Definition of Done:

Accountbereitstellung 🔗

Threat scenario:

Eine unsachgemäße Konfiguration der Accountbereitstellung kann zur Folge haben, dass Angreifer möglicherweise andere Nutzer sich selbst oder andere Nutzer auf- oder abzuwerten, um ihnen entweder a) mehr Berechtigungen zu gewähren als vorgesehen, oder ihnen b) Berechtigungen zu entziehen, um ihren Handlungsspielraum bewusst zu beschneiden.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass Nutzer die Rollen und Berechtigungen anderer Nutzer nicht unrechtmäßig manipulieren können.

Definition of Done:

Enumerieren von Accounts 🔗

Threat scenario:

Für einen erfolgreichen Brute-Force-Angriff genügt in den seltensten Fällen die alleinige Kenntnis über ein Passwort. In den meisten Fällen ist zusätzlich die Kenntnis über den Benutzernamen erforderlich. Angreifer können die Rückmeldung von fehlgeschlagenen Loginversuchen nutzen, um Benutzernamen zu identifizieren.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass Angreifer nicht durch bewusste, falsche Benutzer- oder Passworteingaben auf den Benutzernamen schließen können.

Definition of Done:

Schwache Policies 🔗

Threat scenario:

Schwache Passwörter bilden nach wie vor einer der häufigsten Angriffsvektoren in Webapplikationen. In modernen Webapplikationen ist daher eine zeitgemäße Password-Policy notwendig. Nicht vorhandene, schwache oder umgehbare Policies sorgen dafür, dass Nutzer potenziell schwache Passwörter verwenden können, die sich einfacher erraten lassen.

Objective:

Die Betreiber von DTH sind (mit) dafür verantwortlich, ihren Nutzern die Verwendung von einfach zu erratenden Benutzernamen oder Passwörter zu verbieten.

Definition of Done:

Authentisierung

Authentisierung bezieht sich auf den Prozess der Überprüfung der Identität einer Person oder eines Systems, um sicherzustellen, dass sie tatsächlich die Person oder das System sind, die sie vorgeben zu sein. Die Authentisierung ist ein wichtiger Bestandteil der Informationssicherheit, da sie sicherstellt, dass nur autorisierte Benutzer auf bestimmte Ressourcen zugreifen können.

Die Sicherheit der Authentisierung hängt von verschiedenen Faktoren ab, wie z.B. der Stärke der Authentisierungsmethoden, der Sicherheit der Übertragung von Authentisierungsinformationen, der Überwachung von fehlgeschlagenen Authentisierungsversuchen sowie der serverseitigen Vorgabe von Passwortrichtlinien. Alle diese Aspekte werden in den folgenden Unterabschnitten behandelt.

Die Prüfpunkte aus diesem Prüfabschnitt wurden vom OWASP Web Security Testing Guide, Kapitel 4.4 („Authentication Testing“) abgeleitet. Die folgenden Unterkapitel wurden nicht berücksichtigt:

Verschlüsselte Übertragung von Credentials 🔗

Threat scenario:

Ein Angreifer kann durch einen Man-in-the-Middle-Angriff versuchen, unerlaubt Credentials von Nutzern auszulesen. Dies kann insbesondere dann erfolgreich sein, wenn die Zugangsdaten unverschlüsselt übertragen werden, wie dies beispielsweise bei Basic Authentication der Fall ist.

Objective:

Die Betreiber eines DTH müssen sicherstellen, dass Zugangsdaten stets verschlüsselt von Client zu Server übertragen werden.

Definition of Done:

Standard-Credentials 🔗

Threat scenario:

Die gezielte Suche nach häufig verwendeten oder Standard-Credentials kann einen Angreifer unter Umständen schneller zum Ziel führen als reines Bruteforcing. Es existiert eine Vielzahl an öffentlich verfügbaren Wordlists mit Standard-Credentials, wie etwa rockyou.txt, die Angreifer automatisiert durchiterieren können.

Objective:

Die Betreiber von DTH müssen die Verwendung von Standard-Credentials durch Nutzer aktiv unterbinden.

Definition of Done:

Schwache Lock-Out-Mechanismen 🔗

Threat scenario:

Mittels Bruteforcing können Angreifer mit Kenntnis des Benutzernamens versuchen, das Passwort (gezielt) zu erraten.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass Bruteforce-Angriffe aktiv verhindert werden.

Definition of Done:

Bypass von Authentisierung 🔗

Threat scenario:

Je nach Konfiguration eines DTH können Angreifer die vorgesehene Authentisierung umgehen, indem sie beispielsweise die Flags von HTTP-Requests manipulieren, wenn dies nicht aktiv unterbunden wird. Ein Beispiel hierfür ist das Ändern von authenticated=no zu authenticated=yes. Sofern Session-IDs nicht zufallsgeneriert sind, können sie unter Umständen berechnet werden. Das einfachste Beispiel hierfür ist eine inkrementierende Ganzzahl.

Objective:

Die Betreiber von DTH müssen aktiv verhindern, dass Angreifer oder unberechtigte Nutzer die vorgegebenen Authentisierungsmaßnahmen umgehen.

Definition of Done:

„Passwort merken“-Funktionalität 🔗

Threat scenario:

Angreifer können durch Stehlen der Session-Cookies im schlechtesten Fall Rückschlüsse auf die ursprünglichen Zugangsdaten des Benutzers schließen und ihren Angriff dadurch persistieren.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass Session-IDs nach gängigen Best-Practices erzeugt werden und keine sensiblen Informationen enthalten.

Definition of Done:

Browser-Cache-Schwachstellen 🔗

Threat scenario:

Sobald Angreifer Zugriff auf den Browser-Cache von Nutzern haben, können sie diesen auslesen. Im schlechtesten Fall enthält der Cache sensible Informationen wie Adressen, Kreditkartennummern, Sozialversicherungsnummern oder Benutzernamen.

Objective:

Die Betreiber von DTH müssen aktiv unterbinden, dass sensible Information im Cache des Browsers seiner Nutzer gespeichert wird.

Definition of Done:

Es befinden sich zu keinem Testzeitpunkt sensible Daten im Browsercache.

Schwache Passwort-Policies 🔗

Threat scenario:

Das Bruteforcing von Passwörtern ist nach wie vor einer der häufigsten Angriffsvektoren. Je niedriger die Entropie eines Passworts, desto eher kann es durch gezieltes Ausprobieren erraten werden. Dabei müssen Angreifer nicht einmal sämtliche Kombinationen ausprobieren, es genügt oft das Verwenden von großen Wordlists und deren Permutation, um an das Ziel zu gelangen.

Objective:

Die Betreiber von DTH müssen die Verwendung unsicherer Passwörter durch Nutzer so weit wie möglich einschränken.

Definition of Done:

· 20 bis 25 Zeichen lang bei Verwendung von zwei Zeichenarten

· 8 bis 12 Zeichen lang bei Verwendung von vier Zeichenarten

· 8 Zeichen lang bei Verwendung von drei Zeichen und Multi-Faktor-Authentisierung

Schwache Passwort-Resets oder -Änderungen 🔗

Threat scenario:

In einem fortgeschrittenen Stadium kann ein Angreifer bei Kenntnis eines Benutzernamens und Zugang zu dessen Mail-Postfach versuchen, das Abhandenkommen eines Passworts vorzutäuschen.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass das Zurücksetzen von Passwörtern nur Administratoren und den jeweiligen Besitzern der entsprechenden Accounts gestattet ist.

Definition of Done:

Schwächere Authentisierung in alternativen Anwendungen 🔗

Threat scenario:

Sollte ein DTH unter https://example.com mehrere Unteranwendungen bereitstellen, beispielsweise bei mobilen Ansichten über die Subdomain https://m.example.com oder Schnittstellen über https://api.example.com, so kann ein Angreifer gezielt nach Inkonsistenzen zwischen Unter- und Hauptanwendung suchen. Sollten für die Hauptanwendung alle Anforderungen an die Authentisierung erfüllt sein, muss dies noch nicht zwangsläufig für die Unteranwendung gelten. Ein Angreifer kann im Falle von Schwachstellen in den Unteranwendungen einen Authentication Bypass durchführen, ohne die Hauptanwendung angegriffen zu haben.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass für alternative Anwendungen die gleichen Anforderungen an Authentisierung gelten wie für die Hauptanwendung.

Definition of Done:

Autorisierung

Autorisierung bezieht sich auf den Prozess der Überprüfung, ob ein authentisierter Benutzer berechtigt ist, auf eine bestimmte Ressource oder eine bestimmte Funktion zuzugreifen oder eine bestimmte Aktion auszuführen. Die Autorisierung ist ein wichtiger Bestandteil der Informationssicherheit, da sie sicherstellt, dass nur autorisierte Benutzer auf bestimmte Ressourcen zugreifen und bestimmte Aktionen ausführen können.

Im Gegensatz zur Authentisierung, die die Identität einer Person oder eines Systems überprüft, um sicherzustellen, dass sie tatsächlich die Person oder das System sind, die sie vorgeben zu sein, überprüft die Autorisierung, ob der authentisierte Benutzer die erforderlichen Berechtigungen hat, um auf die angeforderte Ressource oder Funktion zuzugreifen oder die angeforderte Aktion auszuführen.

Die Autorisierung wird in der Regel durch Zugriffskontrollen oder Berechtigungen implementiert, die den Benutzern oder Gruppen von Benutzern bestimmte Zugriffsrechte auf Ressourcen oder Funktionen gewähren oder verweigern.

Die Prüfpunkte aus diesem Prüfabschnitt wurden vom OWASP Web Security Testing Guide, Kapitel 4.5 („Authorization Testing“) abgeleitet. Die folgenden Unterkapitel wurden nicht berücksichtigt:

Directory Traversal File Inclusion 🔗

Threat scenario:

Angreifer können an verschiedenen Stellen in der Anwendung prüfen, ob Query- oder Bodyparameter Dateien inkludieren ohne auf Zugriffsberechtigung zu prüfen. Ein Beispiel hierfür ist der Zugriff auf die kritische Datei /etc/passwd, die Passworthashes aller Systemnutzer erhält. Ein solcher Zugriff könnte über eine File Inclusion erfolgen, beispielsweise: https://example.com/index.jsp?item=../../../../etc/passwd

Objective:

Die Betreiber von DTH müssen sicherstellen, dass Angreifer nicht aus dem Scope der Anwendung ausbrechen und dadurch auf den betreibenden Server zugreifen können.

Definition of Done:

· Nicht-codiert und URL-codiert

· Forward-Slash (/)- sowie Backward-Slash ()-separierte Pfade

· Local File Inclusion (param=../) sowie Remote File Inclusion (param=[http://malicious/url](http://malicious/url))

Unsichere Objektreferenzierungen 🔗

Threat scenario:

Ein Angreifer kann versuchen, auf Objekte zuzugreifen, die nicht für ihn bestimmt sind, zum Beispiel über direkten Zugriffsversuch auf ein Objekt mittels ID: http://foo.bar/somepage?invoice=12345.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass Nutzer auf eigene Objekte zugreifen können und nicht auf Objekte anderer Nutzer.

Definition of Done:

Sitzungsmanagement

Sicherheitsprobleme im Zusammenhang mit Session-Management können schwerwiegende Auswirkungen auf die Sicherheit einer Anwendung haben. Ein erfolgreicher Angriff auf die Session-Management-Mechanismen einer Anwendung kann es einem Angreifer ermöglichen, die Identität eines Benutzers zu stehlen oder eine Sitzung zu übernehmen, was zu unbefugtem Zugriff auf vertrauliche Daten oder sogar zur Übernahme der gesamten Anwendung führen kann. Daher ist es wichtig, dass Anwendungen umfassendem Testing unterzogen werden, um sicherzustellen, dass die Session-Management-Mechanismen ordnungsgemäß implementiert und robust genug sind, um vor Angriffen zu schützen. Dies umfasst die Überprüfung von Sitzungstoken, das Ablaufen von Sitzungen, sowie Sitzungsinformationen in Cookies oder URL-Parametern.

Die Prüfpunkte aus diesem Prüfabschnitt wurden vom OWASP Web Security Testing Guide, Kapitel 4.6 („Session Management Testing“) abgeleitet. Die folgenden Unterkapitel wurden nicht berücksichtigt:

Cookie-Attribute 🔗

Threat scenario:

Ein Angreifer kann bei unsicherer Konfiguration von Session-Cookies möglicherweise sensible Inhalte aus diesen auslesen oder gar eigene Session-Cookies berechnen und somit einen Authentication-Bypass durchführen.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass ihre Cookies sicher erzeugt werden. Das bedeutet insbesondere, dass die Cookies keine sensiblen Daten beinhalten und nicht deterministisch erzeugt werden.

Definition of Done:

Session Fixation 🔗

Threat scenario:

Zunächst erzeugt der Angreifer eine Session ohne Authentifizierung, beispielsweise indem er Shopping-Items einem Einkaufswagen hinzufügt. Bringt der Angreifer ein potenzielles Opfer anschließend dazu, auf Links mit diesem Cookie zu klicken, etwa via Mail, so könnte die Session des Opfers nach einem anschließenden Login „fixiert“ werden. Bei einer Session Fixation bleiben Cookies vor und nach einer Authentisierung identisch. Das bedeutet, dass der Angreifer in diesem Fall erfolgreich über den Login des Opfers authentisiert wird, da es über den Authentisierungsprozess hinweg gleich bleibt.

Objective:

Betreiber von DTH müssen sicherstellen, dass Session-Cookies nach einer erfolgreichen Authentisierung stets „refreshed“ werden.

Definition of Done:

Offenlegung von Session-Variablen 🔗

Threat scenario:

Werden Session-Variablen offengelegt, können Angreifer diese möglicherweise stehlen und somit einen Authentication-Bypass bewirken.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass Session-IDs geschützt und nicht an Drittsysteme übertragen werden.

Definition of Done:

Cross-Site Request Forgery (CSRF) 🔗

Threat scenario:

Ein Angreifer kann über eine Mail oder eine externe Seite Inhalte an ein potenzielles Opfer schicken, die auf die Webseite des DTH verweisen, im Hintergrund aber beispielsweise böswillige Aktionen auf der Seite des DTH ausführt.

Objective:

Betreiber eines DTH müssen sicherstellen, dass Session-Cookies über zusätzliche Maßnahmen vor Missbrauch durch externe Seiten geschützt werden

Definition of Done:

Logout 🔗

Threat scenario:

Bei fehlerhafter Implementierung von Logouts kann ein Angreifer eine Session fortführen, obwohl der Nutzer davon ausgeht, dass diese bereits beendet wurde.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass ein Logout die Beendigung von Sessions und das Löschen relevanter Session-Informationen erzwingt.

Definition of Done:

Session Timeout 🔗

Threat scenario:

Wenn ein Angreifer einen CSRF-Angriff durchgeführt hat, so kann er ihn persistieren, sofern keine Gegenmaßnahmen ergriffen wurden.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass Sessions bei Inaktivität nicht beliebig lange aufrechterhalten bleiben.

Definition of Done:

Eingabevalidierung

Eingabevalidierung ist ein wichtiger Schritt bei der Entwicklung von Software, der sicherstellen soll, dass alle Eingaben, die von Benutzern oder anderen Systemen in eine Anwendung eingegeben werden, gültig sind und keinen Schaden anrichten können.

Die Eingabevalidierung ist notwendig, weil es möglich ist, dass Benutzer absichtlich oder unbeabsichtigt ungültige, schädliche oder unerwartete Eingaben in eine Anwendung eingeben. Diese Eingaben können dazu führen, dass die Anwendung abstürzt, falsche Ergebnisse liefert, unerwünschte Datenzugriffe ermöglicht oder Sicherheitslücken aufweist.

Beispiele für Eingabevalidierungen sind die Überprüfung, ob E-Mail-Adressen oder Passwörter korrekt formatiert sind, ob eingegebene Zahlen innerhalb eines gültigen Bereichs liegen oder ob eingegebener Code sicher ausgeführt werden kann.

Die Prüfpunkte aus diesem Prüfabschnitt wurden vom OWASP Web Security Testing Guide, Kapitel 4.7 („Input Validation Testing“) abgeleitet. Die folgenden Unterkapitel wurden nicht berücksichtigt:

Cross-Site Scripting (XSS)

Threat scenario:

Mittels XSS können Angreifer HTML-Tags oder JavaScript-Befehle an den DTH senden. Dadurch können Angreifer entweder unmittelbar auf Ressourcen zugreifen (Reflected XSS) oder auf Ressourcen anderer Zugreifen, indem sie ihren Angriff persistieren und dieser jedes Mal aufgerufen wird, wenn ein potenzielles Opfer die persistierte Ressource anfordert (Stored XSS). Entsprechend handelt es sich bei letzterer Variante um die kritischere Form von XSS, da sich ein Angreifer somit beispielsweise Session Cookies anderer Nutzer zusenden lassen kann.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass Nutzer weder HTML-Tags noch JavaScript-Code verwenden können, die clientseitig ausgeführt werden.

Definition of Done:

Injection-Schwachstellen

Threat scenario:

Injection-Schwachstellen existieren in vielfältiger Form, haben jedoch allesamt gemeinsam, dass Angreifer die unsachgemäße oder fehlende Validierung von Benutzereingaben als Eintrittsvektor nutzen, um dann vom DTH Befehle ausführen zu lassen, was nicht in seiner ursprünglichen Funktionalität vorgesehen war. Diese Befehle können sich beispielsweise auf die Datenbank- aber auch die Betriebssystemebene beziehen.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass Nutzer keine Befehle einschleusen können, die vom DTH serverseitig ausgeführt werden.

Definition of Done:

Server-Side Request Forgery 🔗

Threat scenario:

In einigen Anwendungsfällen können Angreifer den DTH als Proxy nutzen, um Requests an ein weiteres Ziel zu senden, die nicht vom Angreifer selbst unmittelbar erreichbar sind.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass Nutzer keine Requests über den DTH erzeugen und versenden können.

Definition of Done:

Fehlerbehandlung

Die Sicherheitsimplikationen bei der Fehlerbehandlung von Software werden oftmals vernachlässigt, dabei kann unzureichende Fehlerbehandlung dazu führen, dass Fehlermeldungen oder Protokolle vertrauliche Informationen wie z.B. Benutzernamen, Passwörter oder Systemdetails preisgeben. Diese Informationen können von Angreifern ausgenutzt werden, um Angriffe wie beispielsweise Phishing- oder SQL-Injection-Angriffe durchzuführen.

Die Prüfpunkte aus diesem Prüfabschnitt wurden vom OWASP Web Security Testing Guide, Kapitel 4.8 („Testing for Error Handling“) abgeleitet. Die folgenden Unterkapitel wurden nicht berücksichtigt:

Unsachgemäße Fehlerbehandlung 🔗

Threat scenario:

Durch gezieltes Auslösen von Fehlermeldungen kann ein Angreifer möglicherweise wichtige Interna des DTH in Erfahrung bringen.

Objective:

Betreiber von DTH müssen sicherstellen, dass an den Nutzer zurückgegebene Fehlermeldungen keine Rückschlüsse auf Systeminterna zulassen.

Definition of Done:

Kryptographie

Kryptographie und die Überprüfung kryptographischer Konfiguration in Systemen sind ein Thema für sich. In diesem Abschnitt soll ausschließlich die kryptographische Konfiguration von Webservern betrachtet werden. Dies bezieht sich hauptsächlich auf die sichere Konfiguration von Transport Layer Security sowie der sicheren Verwendung von Schlüsselaustausch- und Verschlüsselungsverfahren gemäß gängiger Best Practices.

Die Prüfpunkte aus diesem Prüfabschnitt wurden vom OWASP Web Security Testing Guide, Kapitel 4.9 („Testing for Weak Cryptography“) abgeleitet. Die folgenden Unterkapitel wurden nicht berücksichtigt:

Schwache Transport Layer Security (TLS) 🔗

Threat scenario:

Für den Fall, dass der DTH eine veraltete TLS-Konfiguration verwendet, können Angreifer die Vertraulichkeit des DTH gefährden. Für veraltete Krypto-Algorithmen existieren zahlreiche Exploits, welche die Verschlüsselung des Nachrichtenkanals brechen können.

Objective:

Der Betreiber eines DTH muss sicherstellen, dass die TLS-Konfiguration dem State of the Art entspricht.

Definition of Done:

(Die nachfolgende Konfiguration entspricht den modernen Kompatibilitätsempfehlungen der Mozilla Foundation gemäß dem Stand von April 2023. Es ist eigenständig auf Aktualität der Werte zu achten.)

· TLS_AES_128_GCM_SHA256

· TLS_AES_256_GCM_SHA384

· TLS_CHACHA20_POLY1305_SHA256

· X25519

· prime256v1

· secp384r1

Schwache Verschlüsselungsverfahren 🔗

Threat scenario:

Analog zur Nutzung schwacher TLS-Konfigurationen birgt auch die Nutzung schwacher Schlüsselaustausch- und Verschlüsselungsverfahren abseits von TLS die Gefahr, dass ein Angreifer die Verschlüsselung eines Nachrichtenkanals brechen kann.

Objective:

Der Betreiber eines DTH muss sicherstellen, dass ausschließlich State-of-the-Art Schlüsselaustausch- und Verschlüsselungsverfahren verwendet werden.

Definition of Done:

(Die nachfolgende Konfiguration entspricht Empfehlungen von OWASP gemäß dem Stand von April 2023. Es ist eigenständig auf Aktualität der Werte zu achten.)

· Im Falle von AES128 oder AES256 sollte der Initialisierungsvektor gemäß FIPS 140-2 konfiguriert sein

· Für asymmetrische Verschlüsselung sollte bevorzugt Elliptic Curve Cryptography (ECC) mit sicheren Kurven wie Curve25519 verwendet werden, alternativ RSA mit zumindest 2048 bit Schlüssellänge

· Wenn RSA zum Signieren verwendet wird, soll PSS-Padding verwendet werden

· Von schwachen Hash- und Verschlüsselungsverfahren ist gänzlich abzusehen, insbesondere MD5, RC4, DES, Blowfish, SHA1, 1024-bit RSA, 1024-bit DAS, 160-bit ECDSA, sowie 80/112-bit 2TDEA.

Clients

Obgleich serverseitiger Schwachstellen in den meisten Fällen die größere Bedrohung für die Vertraulichkeit, Integrität und Verfügbarkeit von Webanwendungen sind, so sind auch clientseitige Sicherheitsüberprüfungen notwendig, um ein ganzheitlich hohes Sicherheitsniveau zu erreichen.

So können Schwachstellen auf der Clientseite auftreten und häufig genutzt werden, um Benutzerdaten zu stehlen. Daher muss beim Web Security Testing die Prävention von XSS auf der Clientseite getestet werden.

Die Prüfpunkte aus diesem Prüfabschnitt wurden vom OWASP Web Security Testing Guide, Kapitel 4.10 („Client-side Testing“) abgeleitet. Die folgenden Unterkapitel wurden nicht berücksichtigt:

Clientseitige Manipulation von Ressourcen 🔗

Threat scenario:

Ein Angreifer kann einen Link an sein Opfer senden, das eine maliziöse URL in die eigentliche URL des DTH einbettet, beispielsweise mit folgendem String: https://dth.de/#http://evil.com/html.html.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass Nutzer keinen Ressourcenzugriff auf Remote-URLs durchführen können.

Definition of Done:

Cross-Origin Resource Sharing (CORS) 🔗

Threat scenario:

Mittels CORS können Angreifer unter Umständen Inhalte von fremden Webseiten in den DTH einbetten, um dadurch schädliche Aktivitäten durchzuführen.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass nicht beliebige Domänen CORS durchführen können.

Definition of Done:

Clickjacking 🔗

Threat scenario:

Ein Angreifer kann unter Umständen UI-Funktionalitäten von Webseiten vortäuschen, die nicht vom Betreiber des DTH vorgesehen sind, um so Schaden bei Nutzern zu erzeugen. Ein Beispiel ist ein Clickjacking-Angriff, bei dem ein Angreifer einen iFrame mit dem ursprünglichen Inhalt des DTH lädt und diesen iFrame in seine eigene, böswillige Seite einbettet und dort schädliche Aktivitäten durchführt.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass ihre Seite nicht von beliebigen anderen Nutzern über iFrames eingebettet werden kann.

Definition of Done:

WebSockets 🔗

Threat scenario:

Bei einer Full-Duplex-Verbindung über WebSockets gelten die gleichen Sicherheitsvoraussetzungen wie für HTTP-Verbindungen. Auch hier kann ein Angreifer unverschlüsselte Verbindungen als Man-in-the-Middle mitlesen und somit die Vertraulichkeit und Integrität der Anwendung brechen.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass bei der Verwendung von WebSockets gängige Sicherheitsstandards eingehalten werden.

Definition of Done:

Web Messaging 🔗

Threat scenario:

Mit Einführung der Messaging API und der postMessage-Methode können Anwendungen unmittelbar miteinander kommunizieren. Bei zu lockerer Konfiguration können Angreifer die Messaging API missbrauchen und einen Kommunikationskanal über eine maliziöse Anwendung erzwingen.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass bei der Verwendung der Messaging API gängige Sicherheitsstandards eingehalten werden.

Definition of Done:

Browserspeicher 🔗

Threat scenario:

Browser bieten die clientseitige Möglichkeit zum Speichern von lokalen-, Session- IndexedDB-, Web SQL- und Cookie-Daten. Im Falle einer Kompromittierung des Browsers können Angreifer diese Daten unter Umständen auslesen.

Objective:

Die Betreiber von DTH müssen sicherstellen, dass sensible Daten nicht clientseitig vorgehalten werden.

Definition of Done:

Schnittstellen

Da APIs einen offenen Zugangspunkt zu Anwendungsdaten und -funktionen bereitstellen, sind sie häufig ein Ziel für Angriffe von Angreifern. Einige häufige Bedrohungen für APIs zielen auf Authentifizierung und Autorisierung, Injections oder Denial of Service ab.

Um API-Sicherheitsprobleme zu vermeiden, müssen Entwickler sicherstellen, dass APIs sicher implementiert und konfiguriert werden. Dies umfasst die Verwendung von sicheren Authentifizierungs- und Autorisierungsmethoden, die Implementierung von Zugriffskontrollen, die Überwachung von API-Aufrufen und die Begrenzung von Zugriffen auf vertrauliche Daten und Funktionen.

Die Prüfpunkte aus diesem Prüfabschnitt wurden vom OWASP Web Security Testing Guide, Kapitel 4.11 („API Testing“) abgeleitet. In dem vorliegenden Dokument wurde von den Autoren der Abschnitt „OpenAPI“ ergänzt.

GraphQL 🔗

Threat scenario:

Angreifer können, wie reguläre Nutzer auch, unmittelbar mit einer Schnittstelle interagieren. Diese kann anfällig für fehlerhafte Eingabevalidierung sein und somit der Eintrittsvektor für gängige Webschwachstellen wie SQL Injection, Cross-site Scripting oder Path Traversal sein.

Objective:

Der Betreiber eines DTH muss sicherstellen, dass Schnittstellen wie GraphQL sicher konfiguriert sind.

Definition of Done:

OpenAPI

Threat scenario:

Angreifer können, wie reguläre Nutzer auch, unmittelbar mit einer Schnittstelle interagieren. Diese kann anfällig für fehlerhafte Eingabevalidierung sein und somit der Eintrittsvektor für gängige Webschwachstellen wie SQL Injection, Cross-site Scripting oder Path Traversal sein.

Objective:

Der Betreiber eines DTH muss sicherstellen, dass Schnittstellen wie OpenAPI sicher konfiguriert sind.

Definition of Done:

Zusammenfassung und nächste Schritte

In diesem Dokument wurde die erste Fassung eines Prüfkatalogs für Datentreuhänder vorgelegt. Es beschreibt Datentreuhänder als eine Spezialform von Webanwendungen. Aus technischer Sicht ist dieser Katalog daher abgeleitet von den Best Practices des OWASP Web Security Testing Guides zur Absicherung von Webanwendungen.

Dieses Dokument ist bisweilen weiter ausbaufähig. Einige Prüfpunkte in verschiedenen Unterabschnitten überschneiden sich teilweise. Weiterhin kann auch in diesem Katalog, wie in so ziemlich allen Prüfkatalogen in der IT-Sicherheit, keine Vollständigkeit gewährleistet sein. Dieses Dokument ist daher als Version 1.0 zu verstehen und muss künftig sowohl erweitert als auch gekürzt, umsortiert und auch stellenweise möglicherweise komplett überarbeitet werden.

Insgesamt soll dieses Dokument als erster Schritt verstanden werden, die technischen Sicherheitsaspekte von Datentreuhändern greifbarer und umsetzbarer zu gestalten.

Mittelfristig soll mit der Schärfung des Themenkomplexes rund um Datentreuhänder schließlich auch dieser Prüfkatalog weiterentwickelt werden, um allen Entwicklern, die einen Datentreuhändern entwickeln und betreiben wollen, ein nützliches Werkzeug zu sein.