In Webanwendungen entdeckte Schwachstellen bewerten
Ergebnis: offen
Je besser Penetrationstests von Webanwendungen vorbereitet sind, desto mehr Erkenntnisse über Schwachstellen lassen sich damit gewinnen. Das eigentliche Ergebnis steht und fällt aber mit dem Ordnen der Informationsflut.
Während es im ersten Teil dieses Überblicks ums systematisierte Abtasten der Anwendung ging [1], steht nun das Entdecken von Einfallstoren im Vordergrund. Nicht alles, was Pentestern dabei auffällt, ist eine Schwachstelle. Vieles weicht nur von Best Practices ab. Darüber hinaus lassen sich manche Schwachstellen nur mit hohem Aufwand ausnutzen. So könnte man auf dem Standpunkt stehen, dass der sagenhafte Man in the Middle sicher nicht ausgerechnet im eigenen Unternehmen auftaucht. Oder wen kümmert Directory-Browsing? Keine Content Security Policy – na und?
Doch Vorfälle in der IT-Sicherheit sind oft das Ergebnis vieler kleiner Nachlässigkeiten und beginnen mit einem als unwahrscheinlich angesehenen Ereignis. Die sprichwörtliche „unglückliche Verkettung ungünstiger Umstände“ kann man meistens mit einfachen Maßnahmen verhindern.
Ordnungsgemäße Konfiguration
Folgt man dem Schema des OWASP Testing Guide (OTG), ist zunächst die vorgefundene Server- und Anwendungskonfiguration zu bewerten (OTG-CONFIG, siehe auch V19 im Application Security Verification Standard, ASVS). Dabei sind unter anderem die folgenden Fragen zur Plattformkonfiguration von Interesse:
Weisen die Plattformen, Frameworks und andere Komponenten bekannte Schwachstellen auf? Es versteht sich dabei von selbst, dass der Tester die Angaben eines Schwachstellenscanners nicht unreflektiert übernimmt, sondern auf Grundlage der jeweiligen Verweise, etwa CVE-Bezeichnern et cetera, zumindest auf Stichhaltigkeit überprüft und im Kontext der Anwendung einordnet.
Liegen Informationslecks vor? Diese reichen von detaillierten Angaben zu Frameworks, Plug-ins und Modulen und deren Versionen über die Preisgabe interner Details (etwa durch Debug-Informationen in Fehlermeldungen) bis hin zum unbeabsichtigten Abfließen von Anwenderdaten. So hat der Autor einmal erlebt, dass bei der Anmeldung nicht nur die Daten für den angemeldeten Benutzer, sondern gleich zu mehreren Benutzern übers Netz gingen.
Ist die Anwendung angemessen von anderen Anwendungen isoliert? Laufen mehrere auf einer Plattform, sollte der Tester auf verdeckte Querbezüge achten, etwa ob eine Anmeldung oder eine Session für Anwendung A zu einer Session für Anwendung B führt.
Sind sämtliche implementierten Funktionen notwendig? Debug-, Demo- oder Test-Features haben in einer Produktivumgebung nichts zu suchen.
Verwendet der Server die HTTP-Header zu Framing, Schutz vor Cross-Site-Scripting (XSS), Content Security Policy, Strict Transport Security, Caching und Zeichensatz gemäß anerkannter Best Practice? Das OWASP Secure Headers Project etwa nennt einige Vorgaben dazu (siehe [a] in den Links zu diesem Artikel unter ix.de/ix1804084).
Lässt sich der Server als Proxy missbrauchen? Hier gibt es zwei Möglichkeiten: über das CONNECT-Verb und über eine entsprechende Gestaltung eines GET-Requests, etwa wenn man eine Anfrage wie GET http://example.com/ HTTP/1.1 an example.org sendet. Im Prinzip könnte man darüber auf interne Ressourcen zugreifen.
Verarbeitet der Server den Host-Header korrekt? Mit dessen kreativer Gestaltung haben sich Anwendungen schon verwirren lassen. Die ideale Reaktion auf einen seltsamen Host-Header ist eine Antwort mit HTTP-Statuscode 404 (Not Found).
Wie reagiert gegebenenfalls eine Web Application Firewall auf Header à la X-Forwarded-For? Eine WAF, die etwas auf sich hält, sollte sich nicht täuschen lassen, etwa wenn man da 127.0.0.1 oder andere unverfängliche IP-Adressen gemäß RFC 1918 wie 192.168.0.5 einträgt.
Bietet der Server die Anwendung TLS-geschützt an? Ungeschütztes HTTP für Anwendungen mit Anmeldung ist grob fahrlässig.
Birgt die TLS-Konfiguration Schwächen oder zeigen die Zertifikate oder die Zertifikatskette Auffälligkeiten? Dazu gehören Altlasten wie SSLv3 oder Cipher-Suites mit Triple-DES-CBC oder AES-CBC, RC4, MD5 oder SHA-1, aber auch kurze RSA-Schlüssel, kurze DH-Parameter für Ephemeral Diffie-Hellman oder unvollständig ausgelieferte Zertifikatsketten. Auch TLSv1.0 gehört nicht mehr zu den empfohlenen Protokollen (PCI-DSS verbietet es sogar); TLSv1.2 ist vielmehr Stand der Technik.
Gibt es Verzeichnisse, für die Directory Browsing möglich ist? Hier kann der Tester erstmals den Proxy aktiv nutzen, also in der Burp Suite das Target-Tool und den Intruder, einen „Fuzzer“. Zunächst erstellt man eine Liste der bisher beobachteten Ressourcen im Scope, indem man die entsprechenden Rohdaten aus dem Target-Tool in eine Textdatei kopiert und die Liste der infrage kommenden Verzeichnisse mit einer geeigneten Kombination aus grep, sed, awk, cut oder gleich Python, Perl oder Ruby extrahiert. Dann dient der Intruder dazu, in einer Anfrage der Art GET / HTTP/1.1 das Verzeichnis / nacheinander durch die Einträge der Liste zu ersetzen. Die Ergebnisse kann man anschließend nach „index of“ durchsuchen, um Fälle von Directory Browsing zu entdecken.