Eine wesentliche Grundregel für die Sicherheit jeglicher Applikation lautet, allen Eingaben des Benutzers zu misstrauen. Alles, was vom Benutzer editiert werden kann, ermöglicht das potentielle Einfügen von Schadcode und gilt als unsicher, bis das Gegenteil bewiesen wurde. Eine einfache Möglichkeit, Eingaben zu prüfen, besteht darin, sie nach ungültigen Elementen zu durchsuchen und sie aufgrund der Resultate als ungültig einzustufen.
So könnte eine Webseite, die es dem Benutzer ermöglicht, eigene HTML-Anweisungen einzugeben, die Eingabe auf die Verwendung von JavaScript filtern. So nützlich dies zunächst klingt, so offensichtlich liegt der Nachteil dieses Verfahrens auf der Hand: Sofern der Filter nicht sämtliche Angriffsmethoden in allen denkbaren Varianten erkennt, werden stets Sicherheitslücken existieren.
Daher ist es oft sinnvoll, ent-
gegengesetzt zu arbeiten. Statt gewisse Elemente zu verbieten und den Rest zu erlauben, wird alles mit einigen zulässigen Ausnahmen verboten. So könnte eine Webseite für Benutzereingaben beispielsweise generell alle HTML-Anweisungen ausfiltern, mit Ausnahme derer, die explizit erwünscht sind. Der Aufwand, einen solchen Filter im Bedarfsfall um ein oder mehrere weitere erlaubte Anweisung zu erweitern, ist im Hinblick auf die erreichte Sicherheit zu vernachlässigen.
Eingabeprüfung
Doch nicht immer sind diese aufwendigen Prüfungen überhaupt notwendig. Stattdessen reicht es häufig schon aus, gewisse Richtlinien zu beachten, so dass es unmöglich wird, Schadcode einzufügen. Solche Verfahren für vier gängige Angriffsmethoden – Pufferüberläufe, Cross-Site-Scripting, SQL- und XPath-Injection sowie Kanonisierung – werden im Folgenden vorgestellt.
Pufferüberläufe stellen eine sehr weit verbreitete Angriffsmethode dar und basieren auf dem Konzept, dass in zahlreichen Anwendungen davon ausgegangen wird, dass eine Eingabe eine gewisse Länge nicht überschreitet. Falls diese vermutete maximale Länge allerdings doch überschritten wird, so kann es zu nicht vorhersagbaren Resultaten kommen. In der Regel wird Speicher überschrieben, der für andere Aufgaben gedacht ist – eventuell auch Speicher, der ausführbaren Code enthält.
Indem ein Angreifer also bewusst überlange Eingaben erzeugt, kann er unter Umständen eigenen Code in Speicherstellen injizieren, die normalerweise Code der Anwendung enthalten. Um dies zu verhindern, lautet die erste Grundregel:
- Jede Eingabe muss auf ihre maximal gültige Länge geprüft werden.
Bei Cross-Site-Scripting-Angriffen (XSS) werden unsichere und sichere Informationen vermischt, die in der Regel von verschiedenen Webseiten stammen. So könnte einer Webseite über eine Benutzer-
eingabe beispielsweise JavaScript-Code untergeschoben werden, der Daten der Webseitenbesucher an den Angreifer versendet. Dadurch kann dieser beispielsweise die Benutzernamen und Session-IDs der Surfer ermitteln, um schliesslich deren Session zu übernehmen.
Je nachdem, ob der Schadcode auf dem Client oder auf dem Server ausgeführt wird, spricht man von client- oder serverseitigem Cross-Site-Scripting. Der einzige Schutz gegen diese Art von Angriffen ist das weiter oben bereits erwähnte Filtern von Eingaben und die Prüfung anhand erlaubter Elemente. Die zweite Grundregel lautet also:
- Jede Eingabe ist als unsicher zu betrachten, bis das Gegenteil bewiesen wurde.
SQL-Injection ist ein Verfahren, SQL-Anweisungen in eine Anwendung einzuschleusen. Begründet werden die meisten Schwachstellen dadurch, dass Parameter für SQL-Anweisungen nicht auf Sonderzeichen überprüft werden, so dass diese genutzt werden können, um die SQL-Anweisung zu verändern. Abhilfe schaffen hier das konsequente Maskieren von Parametern oder die Verwendung spezieller Parameter-Objekte, wie sie beispielsweise in .NET enthalten sind.
Obwohl SQL-Injection inzwischen relativ weit bekannt ist, lässt sich das Prinzip ohne Probleme auf andere Technologien übertragen, bei denen das Gefahrenpotential vielen Entwicklern nicht bewusst ist, obgleich es sich im Prinzip um den gleichen Angriff handelt. So ist das Prinzip der SQL-Injection auch für XPath und XQuery nutzbar. Um sich vor Injection-Angriffen zu schützen, lautet die dritte Grundregel:
- Sämtliche Parameter müssen überprüft und maskiert werden.
Die letzte Methode der Eingabeüberprüfung basiert auf der Tatsache, dass ein Zeichen auf verschiedene Arten dargestellt werden kann. In HTML lassen sich Zeichen beispielsweise ausser durch sich selbst auch mit Hilfe ihres Unicode-Wertes codiert darstellen. Auf diese Art können Filter, die nur nach verbotenen Elementen suchen, ausgetrickst werden, da sie eine verschleierte Darstellung unter Umständen nicht erkennen.
Um solche Angriffe zu verhindern, müssen Zeichen immer auf die denkbar einfachste Form gebracht werden, was als Kanonisierung bezeichnet wird. Dieser Vorgang muss unter Umständen mehrfach durchgeführt werden, um die kanonisierte Darstellung eines Zeichens zu ermitteln. Die vierte Grundregel lautet also:
- Sämtliche Eingaben müssen in ihre kanonisierte Darstellung gebracht werden, bevor sie geprüft werden können.
Parametermanipulation
Eingaben können jedoch nicht nur über Eingabefelder in eine Anwendung gelangen. Statt dessen bieten auch andere Elemente einer Webanwendung Möglichkeiten, Eingaben zu manipulieren. Dazu gehören Abfragezeichenfolgen, Formularfelder, Cookies und HTTP-Header.
Abfragezeichenfolgen werden in der Regel an Webadressen angehängt, um Parameter zu übergeben. Beispielsweise wird in Communities auf der Profilseite zumeist ein solcher Parameter genutzt, um das anzuzeigende Profil zu bestimmen. Solange solche Abfragezeichenfolgen nur Werte annehmen, die im Rahmen der Anwendung zulässig sind, funktioniert alles einwandfrei.
Angreifer können diese Werte aber manipulieren, um bewusst Fehler zu provozieren. Sind Webanwendungen nicht so programmiert, dass sie im Fehlerfall auf einen Standardwert zurückgreifen oder zumindest eine angepasste Fehlerseite anzeigen, läuft man Gefahr, dass eine detaillierte, technische Fehlermeldung ausgegeben wird, die dem Angreifer nähere Informationen über das System liefert. Die fünfte Grundregel lautet also:
- Jede Abfragezeichenfolge muss auf Gültigkeit überprüft und im Zweifelsfall auf einen Standardwert zurückgesetzt werden.
Ebenso kann mit versteckten Formularfeldern verfahren werden, in denen häufig Statusinformationen abgelegt werden. Um einen solchen Angriff zu verhindern, kann über die an den Client ausgelieferten Daten eine Prüfsumme errechnet werden, die ebenfalls mit ausgeliefert wird.
Wird das Formular an den Server zurückgeschickt, wird mit Hilfe der Prüfsumme ermittelt, ob Statusinformationen manipuliert worden sind. Dieses Verfahren wird in .NET zum Beispiel im Konzept des View State eingesetzt. Die sechste Grundregel lautet also:
- Versteckte Formularfelder werden mit einer Prüfsumme gegen clientseitige Manipulationen geschützt.
Ausser versteckten Formularfeldern können auf der Clientseite auch Cookies manipuliert werden, um einer Anwendung beispielsweise eine gekaperte Session-ID unterzuschieben. Solche Angriffe können dadurch zumindest teilweise verhindert werden, dass zu jedem angemeldeten Client seine IP-Adresse gespeichert und darauf geachtet wird, dass eine Session nicht von mehreren IP-Adressen gleichzeitig genutzt wird. Die siebte Grundregel lautet also:
- Cookies müssen auf ihre Herkunft überprüft werden, um die Übernahme von Sessions zu verhindern.
Authentifizierung
Authentifizierung und Autorisierung sind zwei Verfahren, die in der Regel gemeinsam genutzt werden. Während die Authentifizierung dazu dient, einen Benutzer zu erkennen, wird die Autorisierung genutzt, um einem Benutzer Zugriff auf bestimmte Ressourcen zu gewähren.
Die einfachste Variante für einen Angreifer, sich als einen anderen Benutzer auszugeben, liegt darin, den Netzwerkverkehr abzuhören. Werden sensitive Informationen wie beispielsweise Anmeldedaten unverschlüsselt übertragen, kann ein Angreifer bereits auf diese einfache Art an die notwendigen Informationen gelangen, um ein Benutzerkonto zu übernehmen. Um sich gegen einen solchen Angriff zu schützen, lautet die achte Grundregel:
- Sämtliche Verbindungen zwischen Client und Server, über die sensitive Daten übertragen werden, müssen verschlüsselt und gegebenenfalls digital signiert werden.
Sofern es einem Angreifer nicht gelingt, an die notwendigen Daten durch simples Abhören zu gelangen, stehen ihm zwei weitere naheliegende Wege offen: Kennwörter können geraten werden, indem systematisch alle Kombinationen versucht werden, was als Brute-Force-Angriff bezeichnet wird. Je länger Kennwörter sind, je mehr verschiedene Zeichen und je mehr verschiedene Arten von Zeichen sie enthalten, desto sicherer sind sie.
Da die wenigsten Benutzer komplexe Kennwörter wie beispielsweise «c7WgeX!b8a#xXyk5» einsetzen, sondern in der Regel auf einfach merkbare Wörter zurückgreifen, kann eine Brute-Force-Attacke zunächst wörterbuchbasiert durchgeführt werden. Das heisst, der Angreifer geht systematisch sämtliche Wörter durch, die in einem Wörterbuch stehen, in der Hoffnung, ein schlecht gewähltes Kennwort zu treffen. Die neunte Grundregel lautet daher:
- Sämtliche Kennwörter müssen zwingend einer Kennwortrichtlinie genügen, die eine Mindestlänge und eine gewisse Komplexität vorschreibt.
Gelingt auch dies nicht, kann ein Angreifer des weiteren versuchen, Cookies eines anderen Benutzers entweder durch Abhören des Datenverkehrs oder durch Cross-Site-Scripting-Angriffe zu ermitteln. Sofern diese Cookies zur Authentifizierung genutzt werden, kann er versuchen, sie in eigenen Anfragen zu senden, was als Cookie-Replay-Angriff bezeichnet wird. Um sich gegen solche Angriffe zu schützen, lautet die zehnte Grundregel:
- Cookies dürfen nur begrenzt haltbar sein und müssen ausnahmslos über eine verschlüsselte Verbindung ausgetauscht werden.
Autorisierung
Gelingt es einem Angreifer, sein Benutzerkonto in eine höhere Berechtigungsgruppe wie beispielsweise die Gruppe der Administratoren einzutragen, erhält er Zugriff auf weitere Teile der Anwendung und eventuell auch auf den Server, auf dem die Webanwendung ausgeführt wird.
Da solche Angriffe per se nicht verhindert werden können, kann hier lediglich präventiv Schadensbegrenzung betrieben werden. Dazu sollten sämtliche Benutzer jeweils nur über die Rechte verfügen, die zum Betrieb der Anwendung absolut notwendig sind. Dies gilt dabei nicht nur für die Benutzer der Webanwendung, sondern auch für die Systembenutzer, mit denen beispielsweise der Webserver ausgeführt oder auf die Datenbank zugegriffen wird.
Die elfte Grundregel lautet demnach:
- Jeder Benutzer darf nur über die für seine Aufgabe wirklich notwendigen Berechtigungen verfügen.
Des weiteren können Angreifer versuchen, mit nicht vertrauenswürdigem Code den vertrauenswürdigen Code der Anwendung zu kapern, um über diesen und in dessen Kontext Anweisungen auszuführen. Dies wird als lauernder Angriff bezeichnet. In .NET bietet Code Access Security ein Verfahren, um sich vor solchen Angriffen zu schützen. Um sich generell vor solchen Angriffen zu schützen, gilt deshalb die zwölfte Grundregel:
- Der Zugriff auf vertrauenswürdigen Code ist durch entsprechende Prüfungen abgesichert.
So funktioniert SQL-Injection
So funktionieren Cookie-Replay-Angriffe
Fazit
Elementar für die Sicherheit von Webanwendungen ist, grundsätzlich sämtlichen Eingaben zu misstrauen und prinzipiell eine Fehlerbehandlung für ungültige Eingaben vorzunehmen. Viele Angriffe sind nur deshalb erfolgreich, weil es dem Angreifer gelingt, einen Fehler zu provozieren, der von der Anwendung nicht abgefangen wird.
Die zwölf Grundregeln in diesem Artikel können daher als Richtlinie dienen, Code an den entsprechenden Stellen auf potentielle Angriffsflächen zu überprüfen. Gleichzeitig muss aber berücksichtigt werden, dass es sich dabei doch bloss um einen ersten Schritt hin zu sicheren Web-Anwendungen handeln kann, dem weitere Massnahmen folgen müssen.
