IT-Security – Worauf es ankommt (Teil II): Sichere Webanwendungen

Realisierung sicherer Webanwendungen

Aktueller Sicherheitsstatus von Webanwendungen

Der aktuelle Status weltweit – bezogen auf die Sicherheitslücken in Webanwendungen – ist durch einige gemeinnützige Organisationen sehr transparent. Sie bieten sehr detaillierte Informationen, wie:

• Hitlisten aktueller Lücken gewichtet nach Häufigkeit und Auswirkung
• technische Zusammenhänge dieser kriminellen Nutzungen
• Auswirkung und Gefährdungspotenzial
• konkrete Lösungen oder Alternativen

Hervorzuhebende Informationsquellen zu bekannten Sicherheitslücken sind:

• Bundesamt für Sicherheit [1]
• Common Weakness Enumeration, betrieben von der MITRE, gesponsert durch die Regierung der Vereinigten Staaten [3]
• Common Attack Pattern Enumeration and Classification, ebenfalls betrieben von der MITRE [6]
• OWASP: Open Web Application Security Project [4]

Alle Organisationen pflegen unabhängig voneinander gewichtete Hitlisten von den am häufigsten vorkommenden Sicherheitslücken unter Berücksichtigung ihres Gefährdungspotenzials. Inhaltlich unterscheiden sich diese Hitlisten der einzelnen Organisationen kaum. 

Interessanterweise, ja sogar erschreckenderweise, gibt es in diesen Hitlisten über einen längeren Zeitraum kaum Veränderungen. Die Naivität, mit der weltweit viele Webanwendungen realisiert sind, ist beängstigend und gefährlich. Und das, obwohl das Wissen um die Existenz der Gefährdungen und der Vermeidungsmöglichkeit im Detail bekannt und jedem über das Internet verfügbar ist.

Einige exzellente Referenzen zur Realisierung von sicheren Webanwendungen gilt es hervorzuheben. Das Bundesamt für Sicherheit in der Informationstechnik [1] publizierte bereits 2006 einen allgemein zugänglichen Ratgeber mit dem Titel „Sicherheit von Webanwendungen; Maßnahmenkatalog und Best Practices". Obwohl bereits 10 Jahre alt, ist es leider nach wie vor eine Pflichtlektüre für jeden, der an der Konzeption und Implementierung von Webanwendungen beteiligt ist. 2013 folgten die Publikationen „Leitfaden zur Entwicklung sicherer Webanwendungen" ‒ jeweils eine dedizierte Ausgabe für Anforderungen an die Auftragnehmer und für Auftraggeber aus der öffentlichen Verwaltung. Hier werden der komplette Entwicklungsprozess zur Realisierung und die Inbetriebnahme von sicheren Webanwendungen dargestellt. Hinzu kommen konkrete Hilfestellungen bei der Verwendung unterschiedlicher Technologien. Besonders hervorzuheben sind die Hinweise zu „Low Hanging Fruits"; Hinweise, wie man mit wenig Aufwand viele schwerwiegende Sicherheitslücken schließen oder vermeiden kann.

Eigentlich könnte der Artikel hier enden. Inhaltlich kann dieser nicht mit den BSI-Veröffentlichungen konkurrieren, die umfassend und leicht verständlich sind. Trotzdem versuchen wir mit diesem Artikel „bottom up" das Verständnis zu wecken, wie über Beachtung einiger weniger Grundprinzipien oder Prämissen viele kritische Sicherheitslücken zu vermeiden sind. 

Für jede Webanwendung gilt:

• Alle Eingabedaten an eine Webanwendung sind als gefährlich einzuschätzen und müssen explizit validiert werden, bevor sie zur Anwendung kommen.
• Alle Daten, die an den Browser eines Anwenders zurückgegeben werden, müssen explizit validiert werden.
• Kritische Informationen dürfen auch innerhalb der Webanwendung nur verschlüsselt genutzt werden.

Für den verantworlichen Lieferanten der Anwendung gilt:

• Sicherheit ist keine statische Größe, sie ist ein bewegliches Ziel.
• Bisher nicht bekannte Sicherheitslücken können jederzeit aufgedeckt werden.
• Es bedarf der fortlaufenden Beobachtung der Publizierung von neu aufgedeckten Sicherheitslücken.
• Aufgedeckte, relevante Sicherheistlücken müssen schnell und sicher behoben werden.

Validierung von Eingabedaten

Prüfen vor der Übernahme als Operant oder Operator

Relevanz:

• Top 1: „SQL Injections" [2]
• Top 2: „OS command injection" [2]
• Top 13: „Pathname to a Restricted Directory ('Path Traversal')" [2]
• Suche nach „sql injection" aufgedeckt in den letzten 3 Monaten: 28 [16]
• Suche nach „command injection" aufgedeckt in den letzten 3 Monaten: 2 [16]

Die spezifischen SQL-Begrenzungszeichen, wie das Anführungszeichen oder Apostroph, in Benutzernamen oder Passwörtern führen zu dem Problem. Für das Top-2-Problem sind es „..", Schrägstrich und das Semikolon. Deswegen ist es zwingend notwendig, Eingabedaten auf sinnvolle und erlaubte Zeichen hin zu überprüfen. 

Das BSI [1] empfiehlt ein positives Sicherheitsmodel, d. h. die Prüfung einer Eingabe über eine kontextspezifische „whitelist". Der alternative Ansatz „blacklist" prüft nur auf illegale Zeichen. Dieser Ansatz ist zwar einfacher zu realisieren, aber ein „vergessenes" Zeichen öffnet eine Lücke. Inzwischen bieten Programmierumgebungen wie z. B. JAVA oder PHP Funktionen zur Validierung an. OWASP versucht über das Projekt ESAPI (Enterprise Security API) einen Standard zu schaffen, aber scheinbar stagniert der Fortschritt hier seit 2013.

Prüfen des Inhalts von Dateien nach „upload"

Relevanz:

• Top 9: „Unrestricted Upload of File with Dangerous Type" [2]
• Suche nach „upload" aufgedeckt in den letzten 3 Monaten: 14 [16]

Die Validierung von Eingabedaten schließt den Inhalt von Datei-Uploads mit ein. Die alleinige Prüfung auf den Dateityp über die Endung des Dateinamens reicht nicht. Ansonsten kann ein Anwender unter falscher Namensendung Programmlogik zum Beispiel als Bilddatei tarnen. 

Prüfen der Länge

Relevanz:

• Top 3: „Classic Buffer Overflow" [2]
• Top 20: „Incorrect Calculation of Buffer Size"[2]
• Top 24: „Integer Overflow or Wraparound" [2]
• Suche nach „buffer overflow"aufgedeckt in den letzten 3 Monaten: 87 [16]
• Suche nach „integer overflow" aufgedeckt in den letzten 3 Monaten: 38 [16]

Benutzereingaben müssen zusätzlich zu der Überprüfung auf sinnvollen Inhalt auch auf ihre maximal sinnvolle Länge hin überprüft werden. Es vermeidet Speicherüberschreitungen (Buffer Overflows), wenn die Eingabe längenlimitiert ist. Geschieht dies über das Web unkontrolliert und wiederholt, reicht es für eine „DoS"-Attacke, da die Fehlerbehandlung erfahrungsgemäß eine höhere CPU-Last oder höheren Speicherbedarf durch die Webanwendung verursacht. 

Erfolgen das Überschreiten der Puffergrenzen durch den Anwender gezielt unter Kenntnis der Umgebung der Webanwendung, kann er in den Programmablauf der Web- Applikation eingreifen und damit sogar gezielte Operationen wie „create executable file" z.B. über die Systembibliotheken, die ihn die Webanwendung eingebunden sind, ausführen.

Das Problem sind typische Anwendungen, realisiert in der Programmiersprache „C" oder „C++", in der viele Standard-Webkomponenten der Apache Foundation realisiert sind. Zur Vermeidung des Problems kann man verbesserte Libraries einsetzen, die bei Kopierfunktionen implizit gegen Puffergrenzen prüfen. Einige Compiler bieten optional die automatische Generierung von Prüfungen an (Beispiel: Microsoft Visual Studio/GS). Andere Lösungen versuchen durch „Address Space Layout Randomization" (ASLR) das Einbringen von Schad-Code zu bekannten, festen Speicheradressen zu verhindern. Je nach CPU-Typ des Servers kann über das Betriebssystem die Ausführung von Programmcode in Datenbereichen blockiert werden (NX-Bit - Data Execution Protection).

Zusätzlich zur Prüfung auf Puffergrenzen müssen Eingabedaten vor der Nutzung als Datentyp auf den Wertebereich hin geprüft werden, um ein „wraparound" zu vermeiden. Das Ergebnis nach einem „wraparound" wäre eine Zahl, die kleiner ist als notwendig. Tritt dies z. B. bei der Berechnung einer Puffergröße auf, erreicht der Angreifer trotz Längenprüfung in der Anwendung ein „Buffer Overflow". 

Prüfen von Eingabetexten 

Relevanz:

• Top 4: „XSS Cross-site Scripting" [2]
• Top 12: „CSRF Cross-Site Request Forgery" [2]
• Top 14: „Download of Code Without Integrity Check" [2]
• Top 16: „Inclusion of Functionality from Untrusted Control Sphere" [2]
• Top 22: „URL Redirection to Untrusted Site" [2]
• Suche nach „xss" aufgedeckt in den letzten 3 Monaten: 141 [16]
• Suche nach „forgery" aufgedeckt in den letzten 3 Monaten: 21 [16]

Mit diesen Attacken wird nicht eine Webanwendung selbst gefährdet, sondern sie wird missbraucht, um Schad-Code in die Systeme späterer Anwender einzuschleusen. Ein Angreifer versucht, Skript-Code in Texteingabefelder einzubringen in der Erwartung, dass dieser Text ungeprüft in dynamischen Webseiten wiedergegeben wird. Bei einem späteren Aufruf einer solchen Webseite wird versucht, den Skript-Code über den Browser eines Anwenders zur Ausführung zu bringen. Je nach lokaler Sicherheitseinstellung eines Anwendersystems ist es damit möglich, Nutzerdaten an Webseiten eines Angreifers zu senden oder von dort Schad-Code zu injizieren.

Aus diesem Grund ist es die Aufgabe der Webanwendung, die Verteilung von illegalem Skript-Code zu verhindern.

Die Angriffe sind in zwei Kategorien zu unterteilen:

• XSS: Hier versucht ein Angreifer, Skript-Code unterzubringen, der bei Abruf Schad-Code in das Zielsystem installiert.
• CSRF: Hier ist die Zielrichtung des Angriffs, die dynamischen Anwenderdaten aus „cookies" an eine andere kriminelle URL abzuliefern. Da in diesen „cookies" gewöhnlich dynamische Sitzungsdaten abgelegt werden, kann der Angreifer mit diesen Sitzungsdaten z. B. ohne Authorisierung über Namen und Passwort in die Sitzung eingreifen oder sie sogar übernehmen.

Verschlüsselung von kritischen Daten

Relevanz:

• Top 25: „Use of a One-Way Hash without a Salt" [2]
• Da ein unautorisierter Zugriff auf Daten der Webanwendung trotz vieler Maßnahmen nicht ausgeschlossen werden kann, ist es notwendig, kritische Informationen wie z. B. Passwörter, Kreditkartennummern usw. verschlüsselt und nicht im Klartext zu nutzen oder in der Datenbank zu speichern. Der Schutz der Verschlüsselung muss  ausreichend hoch sein, entsprechend einem möglichen Schaden bei lesbarem Zugriff.
• Einfache kryptografische „hashes" sind nicht mehr ausreichend. Im Internet gibt es sogenannte „rainbow tables", die eine schnelle Suche nach dem Originalwert  unterstützen. Durch Hinzunahmen eines zweiten Hash-parameters, dem sogenannten "salt", erhöht sich der Aufwand für eine Entschlüsselung drastisch. „rainbow  tables" für „hash" mit „salt" werden extrem lang und damit nicht mehr handhabbar. Je nach „hash"-Algorithmus ist der Schutz mehr oder weniger sicher bzw. es ist   mehr oder weniger aufwendig, ein Passwort zu restaurieren. Stand der Technik ist zur Zeit der SHA-2-Algorythmus, da „md5" einfach zu entschlüsseln und SHA-0 kaum  sicherer ist. SHA-1 bietet etwas Schutz.
• Da die gelisteten Algorithmen sehr schnell sind, kann man in einer kurzen Zeit auch mit vielen Versuchen zum Entschlüsseln rechnen. Durch eine Verlangsamung des  Algorithmus erhöht man diese Zeit. Gerade bei Passwortprüfung in Anwenderdialogen sind langsamere Algorithmen wie die Funktion „bcrypt" kaum spürbar, erhöhen aber signifkant die Zeit beim automatisierten Entschlüsseln und damit die Sicherheit von verschlüsselten Passwörtern.

Verifizierung einer Webanwendung

Die Überprüfung der Qualitätsziele bezogen auf die Robustheit der Webanwendung gegenüber Sicherheitsattacken muss als fester Teil eines Qualitätszyklus etabliert werden. Es gibt einige verfügbare Tools oder Hilfsmittel, die nutzbar sein könnten. Sicherheitstests werden fachsprachlich Penetrationstests genannt. Da es aber keine absolute Sicherheit gibt, muss der Aufwand kommerziell zu rechtfertigen sein. Es erscheint sinnvoll, den Aufwand und die Kosten in Relation zu einem möglichen Schaden zu stellen.

Die folgende Liste fasst wichtige Informationsquellen zusammen.

• BSI bietet Testchecklisten. [1]
• OWASP bietet Testdaten und Hinweise für die Durchführung von Tests. [12]
• OWASP stellt Test-Guidelines zur Verfügung. [13]
• BSI bietet einen Praxisleitfaden für die Durchführung von Penetrationstests. [15]
• „Kali" stellt eine Linux-basierte „Penetration Test Umgebung" zur Verfügung. [14]

Neben der reinen Testabdeckung ist es wichtig, in eine automatisierte Verifikation einer Webanwendung zu investieren. Nur so ist es realistisch, neu aufgedeckte Sicherheitslücken kurzfristig für Anwendungen operativ zu beheben.

Sicherheitsradar

Eine Anwendung ist so lange als „relativ sicher" zu betrachten, bis eine neue, bisher ungekannte Sicherheitslücke aufgedeckt wird. Dabei sind nicht nur Sicherheitslücken in der eigenen Anwendung relevant, sondern auch die in den eingesetzten Technologien oder Plattformen. Deswegen ist es notwendig, regelmäßig aktuelle Informationen zu verfolgen, die

•  neue Sicherheitslücken veröffentlichen,
•  Korrektur-Patches für die verwendeten Technologien und Plattformen ankündigen.

Fazit

Webanwendungen signifikant sicherer zu machen, ist mit vertretbarem Aufwand durch die Vermeidung der typischen und häufigen Fehler möglich, die dieser Artikel skizziert. Je nach Kritikalität einer Anwendung reicht dies allerdings nicht. Hier helfen die gelisteten Internetreferenzen als Informationsquelle, um weitere Sicherheitslücken in dem eingesetzten Technology Stack der eigenen Webanwendung zu identifizieren und zu beseitigen. Zudem liefern diese Portale auch Anleitungen zur Behebung oder Umgehung von Sicherheitsproblemen. Regelmäßiges Prüfen auf neue entdeckte Sicherheitslücken ist notwendig, um einen erreichten Sicherheitslevel auch über die Zeit zu halten.

Der Artikel behandelt nicht die Aspekte einer sicheren Authentifizierung von Anwendern und der Sicherstellung der Datenintegrität und Geheimhaltung bei der Übertragung über das Internet. Dies bleibt einem nachfolgenden Artikel vorbehalten.

Links/Quellen

[1] Bundesamtes für Sicherheit in der Informationstechnik: https://www.bsi.bund.de
[2] Common Weakness Enumeration Plattform US Home Land Security: https://cwe.mitre.org/top25/index.html
[3] Common Attack Pattern Enumeration and Classifi cation Plattform US Home Land Security: http://capec.mitre.org/
[4] OWASP: Open Web Application Security Project: https://www.owasp.org
[5] OWASP Top 10 – 2013: Die 10 häufigsten Sicherheitsrisiken für Webanwendungen; Deutsche Übersetzung Version 1.0: https://www.owasp.org/images /4/42/OWASP_Top_10_2013_DE_Versi-on_1_0.pdf
[6] Übersicht über die aktuellen Cyberangriffe auf DTAG-Sensoren der Deutschen Telekom: http://sicherheitstacho.eu/
[7] Öffentliches Forum/Info-Austausch aktuellster Sicherheitslücken: http://seclists.org/fulldisclosure/
[8] CWE/SANS TOP 25 Most Dangerous Software Errors: https://www.sans.org/top25-software-errors
[9] Angriffstechniken: https://www.corelan.be/index.php/articles/
[10] CIS Critical Security Controls: https://www.sans.org/critical-security-controls
[11] Lernumgebung zum Erkennen und Verifizieren bekannter Sicherheitslücken über eine beispielhafte unsichere JEE-basierte Webanwendung: https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project
[12] OWASP Cheat Sheets (Testdaten zur Verifikation gegenüber bekannten Lücken): https://www.owasp.org/index.php/Cheat_Sheets
[13] OWASP Testing Guide: https://www.owasp.org/index.php/Category:OWASP_Testing_Project
[14] Penetration Testing Distribution: https://www.kali.org/
[15] Ein Praxis-Leitfaden für IS-Penetrationstests: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Sicherheits-beratung/Pentest_Webcheck/Leitfaden_IS_Penetrationstest.pdf?__blob=publicationFile&v=1
[16] National Vulnerability Database: Alle entdeckten Sicherheitslücken mit Abfragen nach Type und Zeitraum, mit technischen Hintergrundinformationen mit möglicher Umgehungen oder Behebung: https://web.nvd.nist.gov/view/vuln/search?search_type=all&cves=o

Bildnachweis

© freepik.com | Onlyyouqj | Hand-pressing-security.