Im ersten Teil dieses Artikels wurden bereits die ersten fünf präventiven Sicherheitsmaßnahmen C1 bis C5 der OWASP Top 10 Proactive Controls vorgestellt. Dieser zweite Teil knüpft daran an und geht nun näher auf die Proactive Controls C6 bis C10 ein.
Insgesamt zählt OWASP die folgenden präventiven Sicherheitsmaßnahmen als die zehn wichtigsten Proactive Controls auf [1]:
- C1: Festlegung von Sicherheitsanforderungen
- C2: Nutzung von Sicherheitsframeworks und Bibliotheken
- C3: Sicherer Zugriff auf Datenbanken
- C4: Encodierung und Maskierung von Daten
- C5: Validierung aller Eingaben
- C6: Implementierung einer Benutzerverwaltung
- C7: Durchsetzung von Zugriffskontrollen
- C8: Durchgängiger Schutz von Daten
- C9: Implementierung von Logging und Monitoring
- C10: Behandlung von Fehlern und Ausnahmen
C6: Implementierung einer Benutzerverwaltung
Laut dem National Institute of Standards and Technology (NIST) wird digitale Identität definiert als die einzigartige Darstellung eines Benutzers, der an einer Online-Transaktion beteiligt ist. Die Benutzerverwaltung basiert auf einer solchen digitalen Identität. Dabei sind zwei Begriffe zentral: Authentifizierung – die Überprüfung, ob ein Benutzer auch derjenige ist, der er vorgibt zu sein – und Sitzungsverwaltung – der Prozess, bei dem ein Server den Status der Benutzerauthentifizierung aufrechterhält, damit ein Benutzer ein System weiterhin benutzen kann, ohne sich ständig erneut authentifizieren zu müssen. Daher sieht C6 (Implement Digital Identity) das Implementieren einer digitalen Identität bzw. einer Benutzerverwaltung vor.
Diese Proactive Control baut im Hinblick auf die Authentifizierung auf dem NIST 800-63b auf, einem Standard mit Richtlinien zum Thema digitale Identität und Benutzerverwaltung, der ausgehend vom Vertraulichkeitsgrad der enthaltenen Daten drei verschiedenen Ebenen der Authentifizierung (Authentication Assurance Level, AAL) festlegt. [2] Diese Ebenen reichen von Anwendungen mit geringem Risiko, die keine personenbezogenen oder vertraulichen Daten enthalten, bis hin zu Anwendungen mit hohem Risiko, bei denen die Kompromittierung von Daten unter anderem zu hohem persönlichen Schaden oder immensem finanziellen Verlust führen könnte. Je höher somit die Ebene, desto höher auch die Anforderungen an die Authentifizierung. Für die erste Ebene reicht in der Regel ein Authentifizierungsfaktor aus – meist in Form eines Passworts. Jedoch gibt es dabei im Zusammenhang mit Passwörtern einige grundlegende Regeln zu beachten, anderenfalls könnten durch schwache Passwörter wiederum neue Schwachstellen entstehen. Der NIST-Standard enthält auch ausführliche Empfehlungen zur Sicherheit von Passwörtern, die in manchen Teilen der konventionellen Weisheit widersprechen. So rät der NIST-Standard beispielsweise davon ab, Komplexitätsanforderungen zu stellen oder regelmäßige Passwortwechsel zu erzwingen. Neben der Sicherheit der Passwörter an sich ist zudem eine sichere Speicherung von Passwörtern als Hashes zu gewährleisten, damit Authentifizierungskontrollen sicher sind und im Falle einer Kompromittierung nicht direkt auf Informationen zugegriffen werden kann. Für höhere Ebenen sind über ein Passwort hinaus weitere zusätzliche Authentifizierungsfaktoren, zum Beispiel ein Smartphone, oder sogar der Nachweis des Besitzes eines Schlüssels durch ein kryptografisches Protokoll erforderlich.
Sobald sich ein Benutzer über eines der zuvor beschriebenen Verfahren authentifiziert hat, wird dieser Zustand durch die Anwendung nachverfolgt und für eine bestimmte Zeit aufrechterhalten. So kann der Benutzer die Anwendung verwenden, ohne sich immer wieder erneut authentifizieren zu müssen. Die Nachverfolgung des Benutzerstatus nennt man Sitzungsverwaltung (auch Session Management).
Die Sitzung, über die der Zustand eines Benutzers nachverfolgt wird, wird für gewöhnlich auf dem Server gespeichert. Der Benutzer erhält eine Sitzungs-ID oder ein Token, damit festgestellt werden kann, welche serverseitige Sitzung die richtigen Benutzerdaten enthält. Der Client muss lediglich diese Sitzungs-ID bzw. dieses Token aufrechterhalten; dadurch bleiben sensible serverseitige Daten auch beim Server und gelangen nicht zum Client.
Beim Implementieren oder Entwickeln einer Lösung zur Sitzungsverwaltung ist darauf zu achten, dass die Sitzungs-ID einmalig, lang und zufällig ist. Während der Authentifizierung und bei erneuter Authentifizierung sollte die Anwendung eine neue Sitzung erzeugen oder die Sitzungs-ID zumindest wechseln. Zudem sollte neben einem Timeout, durch den die Sitzung nach einer bestimmten inaktiven Zeit abläuft, eine maximale Dauer für jede Sitzung festgelegt werden, nach deren Ablauf sich ein Benutzer erneut authentifizieren muss.
Ein gängiges Verfahren zum Speichern von Sitzungs-IDs sind Browser-Cookies. Beim Verwenden solcher Cookies gilt es einige Punkte zu berücksichtigen. Wenn Browser-Cookies zur Nachverfolgung der Sitzung eines authentifizierten Benutzers verwendet werden, sollten diese nur für die minimal notwendige Anzahl an Domänen und Pfaden verfügbar sein und mit oder kurz nach Ablauf einer Sitzung ebenfalls ablaufen. Zudem sollte das «Secure»-Flag gesetzt werden, um sicherzustellen, dass die Übertragung ausschließlich über einen sicheren Kanal erfolgt (Transport Layer Security, TLS). Neben diesem Flag sollte auch das «HttpOnly»-Flag gesetzt werden, um den Zugriff über JavaScript auf das Cookie zu verhindern. Schließlich sollte das «SameSite»-Flag passend gesetzt werden, um Cross-Site Request Forgery (CSRF) vorzubeugen.
Für manche Authentifizierungsverfahren können serverseitige Sitzungen einschränkend sein. Sogenannte «zustandslose» Dienste ermöglichen die Verwaltung von Sitzungsdaten auf dem Client. Solche zustandslosen Anwendungen erzeugen Zugriffstokens mit einer kurzen Lebensdauer, über die eine Client-Anfrage authentifiziert werden kann, ohne die Anmeldedaten des Benutzers nach der ersten Authentifizierung zu senden. Dabei sind sämtliche sicherheitsrelevanten Informationen zentral in einem Token verpackt. Die am weitesten verbreitete Art solcher Token sind JSON Web Token (JWT), deren Integrität durch digitale Signaturen gewährleistet wird. Auch beim Implementieren und Bereitstellen solcher Token gilt es bestimmte Anforderungen zu beachten, da die Tokens ansonsten neue Schwachstellen hervorrufen können. Daher sollten unbedingt die geltenden Good Practices für eine sichere Implementierung herangezogen werden. [3]
Bei dieser Proactive Control ist zu bedenken, dass Benutzerverwaltung, Authentifizierung und Sitzungsverwaltung komplexe und umfangreiche Themengebiete sind. Die Ausführung der C6 kratzt daher – wie auch die Proactive Controls generell – nur an der Oberfläche. Bei solider Implementierung können diese Schutzmaßnahmen eine Anwendung gegen Schwachstellen in der Authentifizierung und Sitzungsverwaltung schützen.
C7: Durchsetzung von Zugriffskontrollen
Für die Sicherheit einer Anwendung sind Zugriffskontrollen wesentlich. Aus diesem Grund beschäftigt sich die Proactive Control C7 (Enforce Access Controls) mit der Durchsetzung solcher Kontrollen. Die Zugriffskontrolle – oder auch Autorisierung – umfasst das Gewähren oder Verweigern von bestimmten Anfragen eines Benutzers, Programms oder Prozesses. Zur Zugriffskontrolle gehört auch das Gewähren und Entziehen von Berechtigungen. Dabei ist die Zugriffskontrolle nicht zu verwechseln mit der Authentifizierung. Je nach Komplexität kann sich ein System zur Zugriffskontrolle über mehrere Softwarebereiche erstrecken.
Zugriffskontrollen basieren auf unterschiedlichen Verfahren zur Vergabe von Zugriffsrechten; diese können zum Beispiel ausgehend von Rollen oder der Benutzeridentität erteilt werden.
Bei der Zugriffskontrolle gilt es daneben einige grundlegende Prinzipien zu beachten: Vor allen Dingen sollte die Zugriffskontrolle vorab und sorgfältig entworfen werden, denn das Anpassen eines Musters für die Zugriffskontrolle kann komplex und zeitaufwändig sein. Diese Kontrolle stellt eine der Hauptkomponenten der Anwendungssicherheit dar, daher muss sie zwingend gründlich durchgeführt werden. Aus diesem Grund muss bereits bei der Auswahl eines Musters bzw. eines vorhandenen bewährten Frameworks (gemäß C2) eingehend geprüft werden, ob das ausgewählte Framework die gewünschten Grundvoraussetzungen mitbringt und eine Anpassung an die konkrete Anwendung ermöglicht. Ein Beispiel für eine solche Anforderung ist Mandantenfähigkeit (Multi-Tenancy).
Des Weiteren sollten sämtliche Anfragen eine Art von Zugriffskontrolle durchlaufen. Zu diesem Zweck können Java-Filter oder andere Mechanismen zur automatischen Verarbeitung von Anfragen eingesetzt werden. Grundsätzlich sollte außerdem das «Deny by Default»-Prinzip verfolgt werden. Dabei werden alle Anfragen verweigert, die nicht ausdrücklich erlaubt sind. Ein weiterer zu berücksichtigender Grundsatz ist das Least-Privilege-Prinzip: Alle Benutzer, Programme oder Prozesse erhalten nur die Rechte, die sie wirklich benötigen. Zudem sollte auf das Hartcodieren von Rollen verzichtet werden, stattdessen sollten bevorzugt Berechtigungen verwendet werden. Darüber hinaus wird die Protokollierung sämtlicher Ereignisse im Zusammenhang mit der Zugriffskontrolle empfohlen, da diese Ereignisse wertvolle Hinweise auf einen potenziellen Angreifer liefern können.
Durch Berücksichtigen dieser Proactive Control kann eine Anwendung sicherer gestaltet werden, sodass Benutzer nicht außerhalb ihrer vorgesehenen Berechtigungen agieren können und erwünschter Zugriff durch Angreifer schneller erkannt wird.
C8: Durchgängiger Schutz von Daten
C8 (Protect Data Everywhere) empfiehlt den durchgängigen Schutz von Daten. Insbesondere sensible Daten wie Passwörter, Kreditkartennummern und Gesundheitsdaten müssen geschützt werden, vor allem wenn sie unter Datenschutzgesetze fallen. Angreifer können über verschiedene Wege Daten stehlen, zum Beispiel wenn Daten unverschlüsselt über das Internet gesendet werden oder der Angreifer sich SQL Injection zunutze macht, um Passwörter zu stehlen und offenzulegen.
Um einen sicheren Schutz gewährleisten zu können, müssen zunächst sämtliche Daten klassifiziert werden. Konkret bedeutet dies, dass bestimmt werden muss, welcher Vertraulichkeitsstufe die jeweiligen Daten angehören. Die Kategorien können dann den jeweils erforderlichen Schutzregeln zugeordnet werden.
Auch Verschlüsselung ist ein wichtiger Faktor für den Schutz von Daten. Zum einen müssen Daten bei der Übertragung verschlüsselt werden; das gängigste Verschlüsselungsprotokoll für eine sichere Kommunikation ist TLS. Zum anderen müssen Daten bei der Speicherung verschlüsselt werden. Dabei gilt der Grundsatz, wo möglich auf das Speichern sensibler Daten zu verzichten. Wenn Speichern solcher Daten unumgänglich ist, sollte eine entsprechende Verschlüsselung sichergestellt werden, um die Preisgabe oder Manipulation der Daten zu verhindern. Verschlüsselung bzw. Kryptografie ist jedoch ein sehr komplexer Bereich der Informationssicherheit und bedarf umfassender Schulung und Erfahrung. Daher sollte auf geprüfte und offene Lösungen, z. B. Google Tink oder Libsodium, zurückgegriffen und von der eigenständigen Entwicklung von Verschlüsselungsfunktionen abgesehen werden.
Bei Mobilanwendungen ist das Risiko des Informationsabflusses besonders hoch, da Mobilgeräte samt sensibler Daten häufig verloren gehen oder gestohlen werden. Somit sollte im Allgemeinen nur die mindestens erforderliche Menge an Daten auf solchen Geräten gespeichert werden. Wenn Daten gespeichert werden müssen, sollte die Speicherung im jeweils dedizierten Speicherverzeichnis des jeweiligen Betriebssystems erfolgen, z. B. in der iOS Keychain.
Auch Anwendungsgeheimnisse müssen durchgängig geschützt werden. Zu solchen Geheimnissen zählen unter anderem Zertifikate, Passwörter und SSH-Schlüssel, die für sicherheitsrelevante Prozesse erforderlich sind. Werden solche Geheimnisse offengelegt oder manipuliert, kann dies zur vollständigen Kompromittierung von Systemen führen. Generell sollten Geheimnisse nicht in Code und Konfigurationsdateien gespeichert und ebenso nicht durch Umgebungsvariablen weitergegeben werden. Um Repositories nach Geheimnissen zu durchsuchen, können Tools wie Gitrob [4] herangezogen werden. Schlüssel und andere Geheimnisse auf Anwendungsebene sind in einem sicheren Geheimnisspeicher wie KeyWhiz oder Amazon KMS zu hinterlegen, um für eine sichere Speicherung und sicheren Zugriff zu sorgen.
All diese Maßnahmen tragen dazu bei, die Preisgabe von sensiblen Informationen und damit verbundene Konsequenzen zu verhindern.
C9: Implementierung von Logging und Monitoring
C9 (Implement Security Logging and Monitoring) beschreibt den Nutzen der Protokollierung und Überwachung von Sicherheitsinformationen für die Anwendungssicherheit. Die meisten Entwickler sollten die Protokollierung (Logging) bereits zur Fehlerbehebung (Debugging) und -diagnose einsetzen. Das Loggen von Sicherheitsinformationen ist ein ebenso grundlegendes Konzept. Während beim Logging die Sicherheitsinformationen während der Laufzeit einer Anwendung protokolliert werden, umfasst die Überwachung (Monitoring) das Live-Überprüfen der aufgezeichneten Informationen mithilfe verschiedener Automatisierungsmethoden.
Die Protokollierung solcher Daten bringt eine Reihe von Vorteilen mit sich. Zum einen können Intrusion-Detection-Systeme (IDS) davon profitieren, zum anderen können die Daten für forensische Analysen und Untersuchungen herangezogen werden. Darüber hinaus hilft das Logging dabei, Anforderungen zur Einhaltung von Vorschriften zu erfüllen.
Für die Implementierung empfiehlt C9 die folgenden Good Practices: Innerhalb eines Systems und systemübergreifend sollte ein gängiges Protokollierungsformat und -verfahren eingesetzt werden, ein häufig verwendetes Logging-Framework ist beispielsweise Apache Logging Services [5]. Zudem gilt der Grundsatz, nicht zu viele, aber auch nicht zu wenige Informationen zu protokollieren. Zum Beispiel sollten stets der Zeitstempel und Daten, die der Identifikation dienen, wie Source-IP und Benutzer-IP, erfasst werden, niemals jedoch vertrauliche Daten. Darüber hinaus sollte auf die Zeitsynchronisierung zwischen den einzelnen Systemen geachtet werden, damit die Zeitstempel konsistent sind.
Protokollierung ermöglicht ein frühzeitiges Erkennen von Aktivitäten, die auf einen Angriff schließen lassen. Solche Aktivitäten können unterschiedlich aussehen: Daten, die sich außerhalb eines erwarteten numerischen Bereichs befinden; Daten, die Änderungen an Informationen umfassen, die eigentlich nicht geändert werden dürfen, oder Anfragen, die gegen Regeln zur serverseitigen Zugriffskontrolle verstoßen.
Sollten in einer Anwendung derartige Aktivitäten auftreten, sollte die Anwendung diese zumindest protokollieren und als schwerwiegendes Problem kennzeichnen. Im Idealfall reagiert die Anwendung auch auf den identifizierten möglichen Angriff, indem die Sitzung des Benutzers ungültig gemacht und das Benutzerkonto gesperrt wird.
Damit das Logging die erwünschte Wirkung erzielt, muss das Protokollierungsdesign von der Entwicklung bis zur Verwaltung sicher sein. Um dies zu erreichen, müssen sämtliche potenziell gefährlichen Zeichen vor der Protokollierung encodiert und validiert werden, sodass Injection- oder Log-Forging-Angriffe verhindert werden. Des Weiteren sollten Protokolle niemals sensible Informationen enthalten, wie Passwörter, Sitzungs-ID etc. Der Schutz der Integrität der Protokolle muss sichergestellt werden, da ein Angreifer versuchen könnte, die Protokolle zu manipulieren. Für eine zentrale Überwachung sollten Protokolle von verteilten Systemen an einen zentralen Protokollierungsdienst weitergeleitet werden. So gehen Daten nicht verloren, wenn ein einzelnes System kompromittiert wird.
C10: Behandlung von Fehlern und Ausnahmen
Die letzte Proactive Control der Liste (Handling all Errors and Exceptions) weist auf die Behandlung von Fehlern und Ausnahmen hin. Hierbei handelt es sich um ein Programmierkonzept, das verschiedene Reaktionen einer Anwendung auf unterschiedliche Fehlerzustände (z. B. Netzwerkausfall) ermöglicht. Dieses Konzept ist essenziell für sicheren und zuverlässigen Code und ist in allen Bereichen der Anwendung zu finden, sowohl in kritischer Geschäftslogik als auch in Sicherheitsfunktionen und Framework-Code.
Die Fehlerbehandlung spielt auch eine wichtige Rolle für das Erkennen von Angriffen, da bestimmte Angriffe möglicherweise Fehler auslösen, die dann wiederum Rückschlüsse auf einen Angriffsversuch ziehen lassen.
Wird die Fehlerbehandlung mangelhaft implementiert, kann dies zu unterschiedlichen Schwachstellen führen: Es kann zum Beispiel zum Abfließen von Informationen kommen, wenn Fehlermeldungen sensible Informationen enthalten. Folglich sollten solche Meldungen keine internen Informationen zum Fehler oder Stack Traces enthalten, da diese einem Angreifer wertvolle Hinweise liefern können. Detaillierte Informationen müssen für forensische Untersuchungen und zu Debugging-Zwecken protokolliert werden, sollten aber niemals exponiert werden, vor allem nicht an einen externen Client. Neben dem Informationsabfluss ist auch ein Denial of Service möglich, der wiederum von einem Angreifer sehr leicht ausgenutzt werden kann. Ein bekanntes Beispiel für mangelhafte Fehlerbehandlung ist die Apple «goto fail»-Schwachstelle: Dabei wurden aufgrund eines Fehlers im Code beim Aufbau von SSL-Verbindungen essenzielle Validierungsschritte übersprungen, wodurch sämtliche Signaturen akzeptiert wurden. [6]
Für eine sichere Behandlung von Fehlern und Ausnahmen sollten die nachfolgenden Tipps der Proactive Control 10 angewendet werden: Ausnahmen sollten zentral verwaltet werden, um doppelte try/catch-Blöcke im Code zu vermeiden und sicherzustellen, dass jegliches unerwartetes Verhalten innerhalb der Anwendung richtig gehandhabt wird. Es muss gewährleistet sein, dass Fehlermeldungen, die Benutzern angezeigt werden, keine kritischen Informationen enthalten, aber immer noch so ausführlich sind, dass eine angemessene Benutzerreaktion möglich ist. Ausnahmen müssen in einer Form protokolliert werden, die dem Support, der Forensik oder dem Incident Response Team ausreichend Informationen bereitstellt, damit diese das vorliegende Problem verstehen können. Abschließend sollte sämtlicher Code zur Fehlerbehandlung sorgfältig getestet und geprüft werden.
Fazit
Angesichts der Vielseitigkeit der in diesem zweiteiligen Artikel vorgestellten Proactive Controls lässt sich festhalten, dass beim Thema Anwendungssicherheit vor allen Dingen sehr breit gedacht werden muss. Verschiedenste Faktoren wirken sich auf die Sicherheit einer Anwendung aus. Je mehr dieser Faktoren bereits bei der Entwicklung berücksichtigt werden, desto mehr Schwachstellen können präventiv verhindert werden.
Dabei ist die Top Ten der Proactive Controls keinesfalls als ein vollständiger Bauplan für sichere Anwendungen zu verstehen. Die Liste legt lediglich die zehn wichtigsten präventiven Sicherheitsmaßnahmen nahe, mit denen sich Entwickler dringend auseinandersetzen sollten, um die Sicherheit ihrer Anwendungen zu erhöhen. Dabei kratzt die Auflistung nur an der Oberfläche der jeweiligen Themenbereiche, die oftmals sehr komplex sind und dementsprechende Kenntnisse und Erfahrung erfordern.
Die Proactive Controls reichen vom initialen Festlegen von allgemeinen Sicherheitsanforderungen hin zu konkreten Sicherheits- und Überwachungsverfahren. Für all diese Maßnahmen gilt der Grundsatz, dass Entwickler beim Thema Anwendungssicherheit keinesfalls das Rad neu erfinden müssen, stattdessen sollten sie auf bewährte Standards und Methoden zurückgreifen. Hierzu zählt beispielsweise der OWASP Application Security Verification Standard (ASVS).
Über Oneconsult
Die Oneconsult-Unternehmensgruppe ist seit 2003 Ihr renommierter Schweizer Cybersecurity Services Partner mit Büros in der Schweiz und Deutschland und 2000+ weltweit durchgeführten Security-Projekten.
Erhalten Sie kompetente Beratung vom inhabergeführten und herstellerunabhängigen Cybersecurity-Spezialisten mit 40+ hochqualifizierten Cybersecurity Experten, darunter zertifizierte Ethical Hacker / Penetration Tester (OPST, OPSA, OSCP, OSCE, GXPN), IT-Forensiker (GCFA, GCFE, GREM, GNFA), ISO Security Auditoren (ISO 27001 Lead Auditor, ISO 27005 Risk Manager, ISO 27035 Incident Manager) und dedizierte IT Security Researcher, um auch Ihre anspruchsvollsten Herausforderungen im Informationssicherheitsbereich zu bewältigen. Gemeinsam gehen wir Ihre externen und internen Bedrohungen wie Malware-Infektionen, Hacker-Attacken und APT sowie digitalen Betrug und Datenverlust mit Kerndienstleistungen wie Penetration Tests / Ethical Hacking, APT Tests unter Realbedingungen und ISO 27001 Security Audits an. Bei Notfällen können Sie rund um die Uhr (24 h x 365 Tage) auf die Unterstützung des Digital Forensics & Incident Response (DFIR) Expertenteams von Oneconsult zählen.
