WEBAPP: Prüfung von Webapplikationen

Ausgangslage

Bei Webapplikationen besteht grundsätzlich ein hohes Risiko, dass unautorisiert auf Daten sowohl des Kunden als auch von Dritten zugegriffen werden kann, was einem Verlust an Vertraulichkeit gleichkommt. Zusätzlich ist die Interaktion des Benutzers mit der Website relevant, denn besonders durch Cross-Site Scripting (XSS)- Schwachstellen können sowohl externe als auch interne Benutzer gefährdet werden. Eine Besonderheit bei Webapplikationen ist die meist komplexe Abhängigkeit von anderen Systemen, zum Beispiel Applikations- oder Datenbankservern. Diese können durch Schwachstellen in der Applikation ebenfalls beeinträchtigt werden. Im Falle einer Datenbankanbindung könnten unter Umständen sogar schützenswerte Informationen aus der Datenbank gewonnen werden. Diese Abhängigkeiten können auch bezüglich eingesetzter Middleware und – im organisatorischen Sinn – bezüglich herangezogener Lieferanten bestehen. Zudem kann die Sicherheit einer Webapplikation nicht allein durch die Applikation selbst, sondern auch durch ein möglicherweise als Grundlage verwendetes Content Management System (CMS) bestimmt werden. Eine weitere Besonderheit von Webapplikationen ist, dass viele Sicherheitsprobleme nach deren Bekanntwerden auch von Laien nachvollzogen werden können. Dies geht oft mit einem Imageschaden und Vertrauensverlust einher.

Zielsetzung

Auch bei diesem Testmodul besteht die Aufgabe darin, festzustellen, ob die oben genannten Risiken vorliegen. Die Bewertung des Risikos einer einzelnen Schwachstelle erhält bei diesem Test eine höhere Bedeutung, denn das Vorhandensein eines konkreten Risikos deutet meistens auf ein allgemeines Problem hinsichtlich der Anwendungsentwicklung hin: Beispielsweise weist eine XSS-Lücke auf eine generell unsauber implementierte serverseitige Eingabevalidierung hin. Ein weiterer Testschwerpunkt behandelt die Frage, ob es möglich ist, durch Ausnutzung der typischen Schwachstellen von Webapplikationen Einsicht in Daten des Kunden oder Dritter zu erhalten. Das Sicherheitsniveau der Anwendung wird abschließend eingeschätzt und Maßnahmen zur Behebung eventueller Schwachstellen werden vorgeschlagen.

Durchführung

Die Durchführung eines Penetrationstests ist bei Webapplikationen stark von deren Funktion und Aufbau abhängig. Ein festes Schema für den Testablauf kann daher nicht aufgestellt werden, der Ablauf entspricht aber grob dem folgenden Muster:

Prüfung der Providing Infrastructure: Wird lediglich eine Prüfung der Webanwendung, nicht jedoch auch eine gründliche Analyse der Providing Infrastructure beauftragt, so werden weitere, möglicherweise auf dem Webserver erreichbare Dienste nicht mitgeprüft. Wird die Analyse der Providing Infrastructure explizit gewünscht, so finden zusätzlich Portscans zur Ermittlung weiterer auf diesen Systemen erreichbarer Dienste statt. Im Anschluss werden sämtliche Dienste einer Schwachstellenanalyse unterzogen (wie im Modul IP-RANGE). Zum Beispiel werden auch Schwächen in der Konfiguration des eingesetzten Webservers selbst sowie in eingesetzten SSL/TLS-Komponenten analysiert. Hierbei kommen in Abhängigkeit von den erreichbaren Diensten unterschiedliche Werkzeuge zum Einsatz. Schwachstellenscanner wie z. B. Nessus gehören zum Standardrepertoire bei derartigen Tests. Ziel dieser Überprüfung ist es, auch Schwachstellen abseits der für die Webapplikation bereitgestellten Dienste zu identifizieren.

Strukturermittlung: Bezüglich des eigentlichen Tests der Webapplikation wird in einer ersten Phase die Struktur der zu prüfenden Webanwendung analysiert. Hierfür kommen neben verschiedenen automatisierten Methoden (Spider/Crawler) auch manuelle Verfahren zum Einsatz. Das vorrangige Ziel dieser Phase ist, die für einen Angreifer interessanten Bereiche der Anwendung zu identifizieren.

Test des Authentifizierungskonzepts und der Sitzungsverwaltung: Erfordert die Anwendung eine Benutzeranmeldung, so werden in einem nächsten Schritt mögliche Angriffe gegen das Authentifizierungskonzept eruiert. Hierbei werden neben rein technischen (z. B. Umgehung der Authentifizierung durch SQL Injection-Angriffe) auch programmatisch-konzeptionelle Schwachstellen (z. B. Möglichkeiten der Benutzerenumeration, Passwort-Reset-Funktionen, Passwort-Rate-Angriffe, Kontensperrungen usw.) betrachtet. Alle weiteren Tests werden optimalerweise unter Verwendung mehrerer Benutzerkonten mit – wenn möglich – unterschiedlichen Rollen durchgeführt. Anschließend erfolgt – falls vorhanden – eine Untersuchung des implementierten Sitzungskonzepts. Im Fokus stehen hierbei grundsätzliche Schwachstellen, die die Durchführung von Identitätsdiebstählen ermöglichen können. Geprüft werden unter anderem Sitzungsbezeichner, Cookie-Attribute, Session Handling und Pre-Authentication-Schwachstellen.

Prüfung der Eingabevalidierung: Im Vordergrund steht hierbei eine Prüfung der Funktionalität der serverseitigen Payload-Verifikation mittels klassischer Angriffsvektoren (verschiedene Formen des Cross-Site Scripting, SQL Injection, URL Injection, LDAP Injection, OS Command Injection, XPath Injection, XML Injection usw.). Hierfür werden neben manuellen Eingabeprüfungen auch Payload-Manipulationen unter Verwendung von Browser-Plug-ins und Analyseproxys, wie z. B. der Burp Suite Professional, durchgeführt. Wo bedingt durch Umfang und Komplexität der Anwendung angebracht, kommen automatisierte Webapplikationsscanner zum Einsatz, deren Ergebnisse im Anschluss manuell verifiziert werden.

Analyse der Applikationslogik und des Autorisierungskonzepts: In einem weiteren Schritt wird die Applikation auf möglicherweise fehlerhafte Konsistenz- oder Plausibilitätsprüfungen innerhalb der Anwendungslogik untersucht. Klassische Beispiele wären an dieser Stelle die Möglichkeit einer Preismanipulation innerhalb eines Webshops, Anfälligkeiten für gefälschte Antworten von eingebundenen Drittsystemen – etwa Zahlungsdienstleister – oder unerlaubte Verzweigungen innerhalb der Anwendungslogik, etwa durch Manipulation von in den Client verlagerten Logikkomponenten, die beispielsweise über Hidden Fields transportiert werden. Zudem wird das von der Anwendung umgesetzte Autorisierungskonzept geprüft. Auch hierfür sollten idealerweise mehrere Testkonten zur Verfügung gestellt werden, um Zugriffsmöglichkeiten auf Daten und Funktionen anderer Benutzer bzw. Rollen effizient prüfen zu können.

Reverse Engineering: Optional können vom Server ausgelieferte (auch binäre) Clientkomponenten analysiert werden, z. B. Java-Applets oder Flash-Anwendungen. Hierfür werden spezielle Decompiler sowie Reverse Engineering-Techniken eingesetzt. Grundsätzlich wird – abhängig von den jeweils gemachten Feststellungen – eine als Proof of Concept (PoC) geeignete Angriffssoftware entwickelt. Ziel ist hierbei in erster Linie die Verifikation der Feststellungen sowie die Erlangung weiterer Informationen oder Berechtigungen.

OWASP Top 10: Bei der Suche nach Schwachstellen orientiert sich die SySS stark an den jeweils aktuellen OWASP Top 10. Das Open Web Application Security Project (OWASP) pflegt seit vielen Jahren eine Liste der zehn häufigsten Risiken bei Webapplikationen. Diese Liste ist dynamisch und wird regelmäßig überarbeitet. Darüber hinaus wird auch eine Reihe weiterer Schwachstellenklassen geprüft, die entweder nicht in den OWASP Top 10 enthalten sind oder seitdem neu veröffentlicht wurden.

Schwachstellenscannern kommt bei diesem Testmodul nur eine unterstützende Rolle zu. Dies gilt auch für diejenigen, die speziell für den Test von Webapplikationen vorgesehen sind, da Scanner nur sehr eingeschränkt in der Lage sind, kontextbezogene Informationen zu verwerten und zu beurteilen. Daher ist das Hauptwerkzeug bei der Untersuchung von Webapplikationen immer ein Browser, mit dem manuelle Prüfungen durchgeführt werden. Bevorzugt wird hier Mozilla Firefox eingesetzt, da für diesen Browser eine große Auswahl an Add-ons zur Verfügung steht. Zusätzlich werden zur Verifizierung und Demonstration von Schwachstellen bei Bedarf eigene Skripte geschrieben.

Dennoch kann die Untersuchung von Webapplikationen durch den Einsatz von Security-Scannern bzw. entsprechenden Proxys sinnvoll unterstützt werden. Zum Einsatz kommen hier unter anderem Nessus, SQLmap und Burp Suite Professional.

Mitwirkung des Kunden

Für den Test muss auf jeden Fall die URL der Webapplikation mitgeteilt werden. Ferner muss definiert werden, welche Bereiche der Webapplikation geprüft werden sollen. Beispiele hierfür sind öffentlich erreichbare Bereiche der Seite, nur für angemeldete Benutzer verfügbare Funktionen sowie zu einem möglicherweise zum Einsatz kommenden Content Management System gehörende Bereiche, zum Beispiel Administrationsoberflächen. Zudem muss geklärt werden, von wo aus der Test erfolgt (über das Internet, aus einem bestimmten Intranetbereich heraus o. Ä.).

Ansprechperson: Die Analyse von Webapplikationen unterscheidet sich nicht nur beim Vorgehen erheblich von anderen Testmodulen. Wie bereits erwähnt, können Sicherheitsprobleme in der Webapplikation auch weitere Dienste betreffen, insbesondere Datenbanken und E-Mail-Dienste.

Darüber hinaus kommen Webapplikationen bzw. deren Funktionalität in der Regel nicht aus einer Hand: Die Gestaltung kann in den Händen einer Agentur liegen, das Programmieren der Webapplikation kann sowohl von internen als auch von externen Programmierern übernommen werden. Die Hardware selbst kann wiederum von einem Webhoster gestellt und auch betreut werden. Insbesondere zur Behebung der festgestellten Sicherheitsschwächen ist es notwendig, mit denjenigen Personen Kontakt aufzunehmen, die für die jeweils betroffenen Elemente zuständig sind. Daher ist es für den durchführenden Consultant von sehr großer Bedeutung, die Kontaktdaten der Ansprechpartner zu kennen.

Ist kein direkter Ansprechpartner definiert oder verfügbar, können daraus zweierlei Probleme entstehen:

• Rückfragen während des Tests, die zur Verifizierung von Sicherheitsschwächen dienen, können nicht beantwortet werden, was wiederum zu Verzögerungen führt.
• Sind die Verantwortlichen für eine Funktion, die von einer Sicherheitslücke betroffen ist, nicht bekannt, verzögert sich die Behebung der Schwachstelle erheblich.

Aus diesem Grund sollte rechtzeitig vor dem Test mit der Klärung der Zuständigkeiten und Feststellung der Verantwortlichen begonnen werden, auch wenn dies im ersten Schritt aufwendig zu sein scheint. Anschließend sollten die Betroffenen über Termin und Ziel des Tests informiert werden. Ebenso wie bei anderen Testmodulen können sie auf Wunsch dem Test beiwohnen. Falls Dritte betroffen sind, müssen diese der Durchführung des Tests zustimmen (in Form einer schriftlichen Einverständniserklärung). Zusätzlich sollte während des Tests ein Ansprechpartner, der mit der Webapplikation aus der Benutzerperspektive vertraut ist, für Rückfragen zur Verfügung stehen.

Die Tests erfolgen stets in enger Zusammenarbeit mit den Ansprechpartnern. Hierdurch wird zum einen garantiert, dass eventuell auftretende Verfügbarkeitsprobleme zeitnah erkannt und ausgeräumt werden können. Zum anderen wird sichergestellt, dass vor allem die kritischen Schwachstellen sofort behoben werden können.

Abhängigkeiten: Organisatorische und technische Abhängigkeiten sollten der SySS mitgeteilt werden. Dies kann im Rahmen des Kick-off-Gesprächs geschehen.

Status der Webapplikationen: Die zu testenden Funktionen müssen möglichst durchgängig verfügbar sein. In der sehr frühen oder mittleren Umsetzungsphase einer neuen Webapplikation bringt ein Test keine nachhaltigen Ergebnisse. Er kann aber dennoch sinnvoll sein, wenn möglichst früh entscheidungsrelevante Ergebnisse vorliegen müssen.

Zudem sollte davon abgesehen werden, während der Testzeit Updates durchzuführen. Das hat den Hintergrund, dass sich zum einen die Testtiefe verringern kann, da während des Updates keine Tests durchgeführt werden können. Zum anderen kann keine zuverlässige Aussage über den aktuellen Sicherheitsstand der Applikation getroffen werden, wenn sich während der Testzeit Funktionalitäten ändern und dadurch nicht umfassend geprüft werden.

Anmeldeinformationen: Viele Webapplikationen bieten zusätzliche Funktionen in einem internen Bereich an, der erst nach erfolgreicher Anmeldung sichtbar wird, beispielsweise bei einem Kundenportal.

Für den Test dieser Funktionen benötigt die SySS mindestens zwei Benutzerkonten mit unterschiedlichen Berechtigungsstufen, aus deren Sicht der Test durchgeführt werden soll. Stehen keine entsprechenden Konten zur Verfügung, kann ein Test nur aus der Perspektive eines Besuchers der Webseite durchgeführt werden. Dies führt meist zu lediglich geringen Erkenntnissen bezüglich des Sicherheitsniveaus der Webapplikation. Die Erfahrung zeigt, dass ein Angreifer mit genügend Zeit und dem Einsatz von Social Engineering-Techniken mit hoher Wahrscheinlichkeit in der Lage ist, einen Benutzer zu übernehmen. Daher wird empfohlen, diese Testnutzer zur Verfügung zu stellen, vor allem, weil der Penetrationstest in einem beschränkten zeitlichen Rahmen stattfindet. Um sinnvolle Ergebnisse zu erhalten, dürfen die Rechte der Benutzerkonten gegenüber denen regulärer Anwender nicht eingeschränkt sein. Wie diese Konten erzeugt werden, wird beim Kick-off-Gespräch besprochen.

Testdaten oder Testsystem: Falls der Test nicht mit produktiven Daten oder auf produktiven Systemen durchgeführt werden soll, kann auch an einem Produktivsystem mit Testdaten oder nur an einem Testsystem gearbeitet werden. Testdatensätze, auf die die für den Test verwendeten Benutzerkonten zugreifen können, sollten bereits vor Testbeginn zur Verfügung stehen.

Bei der Arbeit mit reinen Testsystemen ist das Ergebnis des Sicherheitstests nur aussagekräftig, wenn ihre Funktionalität zu großen Teilen mit der des Produktivsystems übereinstimmt.

Sollte keine Möglichkeit zur Bereitstellung einer Testinstanz bestehen, so wird die Vorgehensweise entsprechend justiert. Beispielsweise soll dadurch verhindert werden, dass die Benutzer einer zu testenden, produktiven Webapplikation Verfügbarkeitsbeeinträchtigungen während des Tests ausgesetzt sind. Insbesondere die automatisierten Schwachstellenscans werden in einem solchen Fall sehr moderat konfiguriert oder nur bei ausgewählten Funktionen eingesetzt.