CMS. Gängige Methoden zum Ausnutzen von Sicherheitslücken und deren Vermeidung. Jewgenija Konrad

Transkript

1 CMS Gängige Methoden zum Ausnutzen von Sicherheitslücken und deren Vermeidung Jewgenija Konrad Fachhochschule Augsburg Studiengang: Master of Science Juni 2007 Kurzfassung: Die nachfolgende Ausarbeitung beschäftigt sich mit dem Problem Websicherheit. Dabei wird verstärkt das Cross-Site Scripting beleuchtet, sowie und einige Spezialfälle davon, wie z.b. SQL Injection, werden vorgestellt. Darüber hinaus werden Möglichkeiten mit ihren Vor- und Nachteilen gezeigt, um die eigenen Webseiten vor derartigen Angriffen zu schützen. Kategorien: Sicherheit Schlüsselwörter: Content Management, Cross-Site Scripting (XSS), SQL Injection 1 Einleitung Jedes CMS System, das dazu verwendet wird, einen Online-Auftritt zu gestalten, findet sich im WWW einer Vielzahl von Angreifern gegenüber. Je mehr Besucher diese Seite anzieht, desto mehr Angreifer werden von ihr angelockt. Die möglichen Angriffe können dabei in passive und aktive Attacken unterteilt werden. Zu den passiven Angriffen gehören dabei das Sniffing, also das Mithören der im Klartext versendeten Daten, oder auch die gezielte Umleitung von Daten durch Manipulation von Routing-Tabellen. Wer dabei glaubt, dass das Mithören schwer zu realisieren sei, irrt sich, denn Tools zum Mithören (vorausgesetzt man benutzt diese nur zu Administrationszwecken) sind legal und damit leicht aufzutreiben. Das Manipulieren von Daten, die im Internet zur Verfügung stehen, zählt dagegen zu den aktiven Attacken. IP Spoofing dient als Basis für andere Angriffe - dabei wird meist die IP-Quelladresse geändert, so dass man Datenpakete an seine Opfer versenden kann, ohne die Gefahr der Rückverfolgbarkeit, denn statt der echten IP-Adresse des Angreifers würde die durch den Angreifer veränderte IP in den Logdateien auftauchen. Auch Port-Scans durch automatische Tools gehören zu den aktiven Angriffen. Dabei werden an eine bestimmte IP-Adresse und Portnummer systematisch Datenpakete gesendet. Durch Auswerten der Antwort wird bestimmt, ob der Port erreichbar ist. Teilweise ist es auch möglich, anhand der vom Port benötigten Antwortzeit herauszufinden, welche Aufgabe diesem Port zugeordnet ist [16]. Von allen diesen Möglichkeiten, Angriffe über das WWW durchzuführen, wird jedoch nur eine bestimmte Art der aktiven Angriffe - das Cross-Site Scripting - näher diskutiert. Auch Möglichkeiten, diese Angriffe abzuwehren werden vorgestellt. 2 Cross-Site Scripting (XSS) Das Cross-Site Scripting (im nachfolgenden XSS genannt) kann dazu verwendet werden, Daten der Originalseite zu verändern und zählt damit zu den aktiven Angriffen. Leider wird dieser

2 Angriff heutzutage immer noch sehr häufig unterschätzt. So sind einige Administratoren immer noch der Meinung, dass XSS nur ein Spiel Halbwüchsiger ist, das höchstens dazu benutzt werden kann, lästige Pop-up Fenster ungefragt zu öffnen. Dabei ist XSS eine der am häufigsten verbreiteten Methoden, Angriffe auf ungeschützte Webseiten auszuführen und wird in der Verwendung nur noch vom Bufferoverflow, bei dem Teile des Speichers überschrieben werden um den Programmablauf zu verändern, übertroffen. Beim XSS werden Informationen durch einen Angreifer in eine vermeintlich sichere Seite eingebettet. Dabei ist es für den Angreifer zum Teil möglich, sensitive Daten von Benutzern der veränderten Webseite zu stehlen, wie z.b. Bankdaten, Zugangsdaten oder persönliche und finanzielle Informationen. Natürlich können damit auch Fehlinformationen verbreitet und Nutzer überwacht werden. Es ist auch ein Szenario denkbar, bei dem der Angreifer in eine Webseite, die für mehrere Tausend Besucher täglich ausgelegt ist, Code injiziert. Dieser Code veranlasst einen Download großer Dateien vom Server des Opfers. Da das bei mehreren Tausend Benutzern passiert wird damit also eine Denial of Service (DoS) 1 Attacke) auslöst, was genügen sollte, um den angegriffenen Server unerreichbar zu machen. Obwohl XSS nur durch Ausnutzen von Sicherheitslücken einer Seite möglich ist, sind viele große und bekannte Webseiten wie icq.com, und sogar der Web-Auftritt der Hamburger Sparkasse bereits davon betroffen gewesen. In Abbildung 1 ist die Webseite der Hamburger Sparkasse, nach einem erfolgreichen Abbildung 1: XSS bei Hamburger Sparkasse [9] XSS-Angriff, zu sehen. Dabei wäre es auch möglich den präparierten Bereich durch ein Formular zu ersezten, das die Kontodaten des Bankkunden abfragt und an den Angreifer verschickt. Laut [4] wurde das Feld Konto nicht geprüft und ermöglichte es Angreifern, Code einzubetten. Diese Sicherheitslücke wurde inzwischen allerdings behoben. XSS Attacken können auf drei unterschiedliche Arten erfolgen, die nun erklärt werden. 2.1 Reflektiertes XSS Das reflektierte - oder auch serverseitige - XSS ist der häufigste Vertreter von XSS-Angriffen und wird im Phishingmarkt angewendet. Hierbei muss ein Opfer eine präparierte URL anklicken. In 1 Dabei wird ein Server ausgelastet bis dieser nicht mehr erreichbar ist oder nur noch eingeschränkt arbeiten kann.

3 Variablen und Parametern dieser URL wird Code eingefügt, den die Anwendung auf dem Server übernimmt und in die Webseite einbettet. Das kann ein Suchausdruck, ein Username oder auch eine Adresse sein. Der Angriff läuft folgendermaßen ab: die vom Angreifer veränderte URL wird durch ein Opfer angeklickt und somit an den betroffenen Server als Anfrage verschickt. Hier ist die Web-Applikation fehlerhaft und ermöglicht dem Angreifer, den dynamisch generierten HTML-Code zu verändern. Der Benutzer sieht nun die manipulierte Seite in seinem Browser. 2.2 Persistentes (beständiges) XSS Auch das persistente XSS ist Serverseiteig, d.h. die Veränderungen werden auf dem Server vorgenommen und der Schadcode wird über die URL an den Browser zurück geschickt. Allerdings wird hierbei der Inhalt der Datenbank ebenfalls verändert. Deswegen kann dieser Schadcode auch Benutzer erreichen, die die manipulierte URL nicht angeklickt haben. Um die Attacke zu starten, reicht es hier völlig, wenn der Angreifer selbst den manipulierten Link anklickt. Dieser Angriff wird zwar ähnlich dem reflektierenden XSS ausgelöst, verläuft aber etwas anders. Wie schon beschrieben, ruft der Angreifer eine manipulierte URL auf und sendet somit eine Anfrage an den Server. Die fehlerhafte Web-Applikation verarbeitet die Anfrage und speichert den injizierten Code in der Datenbank. Von nun an wird jeder Besucher dieser Seite den veränderten HTML-Code vorfinden. 2.3 Lokales (DOM 2 -basiertes) XSS Wie der Name schon vermuten lässt, ist das lokale XSS clientseitig, d.h. der komplette Angriff findet auf dem Rechner des Opfers statt. Dieser Angriff findet häufig bei Web 2.0 Anwendungen statt, da hier der Java oder Java-Script Code im Browser des Benutzers ausgeführt wird. Da der Angriff im Browser des Benutzers stattfindet, wird auch der schädliche Code in der Sprache des Browsers gehalten und als Parameter an die Webseite übergeben. Falls dieser Code in der Webseite wieder enthalten ist, kann es passieren, dass der Browser des Benutzers diesen Code ausführt und evtl. Daten in ein Formular der generierten Seite einträgt, die anschließend an den Angreifer weitergeleitet werden. Besonders gefährlich wird dieser Angriff, wenn die manipulierte Seite besondere Rechte im Browser besitzt. Je nach verwendeter Skriptsprache könnte die manipulierte Anwendung Cookies mit Anmeldeinformationen stehlen oder mit den Rechten des lokalen Benutzers Daten auf dem Rechner verändern. Dies könnte sich besonders bei Windows-Systemen als fatal erweisen, da der lokale Benutzer oft gleichzeitig der Administrator ist. Ein Angriff würde wie folgt ablaufen: der Benutzer klickt wieder eine manipulierte URL an und schickt damit eine Anfrage an die Web-Applikation. Diese antwortet, indem der Skriptcode (der fehlerhaft, jedoch nicht manipuliert ist) an den Browser übergeben wird, um dort die Ausführung des Skripts zu starten. Die manpulierten Parameter aus der URL werden nun im Browser des Benutzers als Teil des Skripts interpretiert und ausgeführt. Über DOM-Zugriffe wird die im Browser dargestellte Webseite verändert, der Benutzer sieht nun die manipulierte Seite. 2.4 XSS eine kleine Anleitung Zunächst müssen potentielle Opfer gefunden werden 3, d.h. es muss nach Anzeichen für die Angreifbarkeit einer Seite gesucht werden. Das ist bei Anwendungen der Fall, die die vom Benutzer 2 DOM bedeutet Document Object Model. 3 Beispiel nach[5] und [15].

4 vorgenommenen Eingaben wieder ausgeben - ob es ein Suchstring oder ein Foreneintrag ist, spielt dabei keine Rolle. Auch das Einbetten des vom Benutzer vorgenommenen Textes in Fehlermeldungen kann ein Anzeichen für die Anfälligkeit auf XSS sein. Dafür werden die Bereiche auf Seiten gesucht, die Eingaben durch Benutzer zulassen, wie z.b. Login-Fenster, Suchfelder und Ähnliches. Foreneinträge und Message Boards sind dafür prädestiniert, da die Eingabe durch Nutzer auf jeden Fall wieder angezeigt wird. jedoch gilt hier immer noch zu prüfen, ob eine Anfälligkeit auf XSS vorhanden ist. Sobald ein potentiell betroffenes Feld gefunden wurde, trägt man einen beliebigen String in dieses Feld ein, z.b. test. Nach einer Bestätigung wird die Übertragung zum Server gestartet und in der Antwort des Servers wird der vorher eingegebene String gesucht. Der gesuchte String könnte z.b. in Form einer Fehlermeldung wie Invalid login test wieder auftauchen. Falls der Teststring ausgegeben wurde, kann getestet werden, ob die Seite gegen XSS geschützt ist. Dazu wird in das selbe Feld JavaScript Code eingetragen, wie z.b. <script>alert( hello )</script> und an den Server übermittelt. Falls nun ein Pop-up-Fenster aufgeht, in dem hello zu sehen ist, ist die untersuchte Seite eindeutig von XSS betroffen. Auch wenn kein Fenster aufgeht, kann es sein, dass der neu generierte HTML-Code den eingetragenen String enthält und dieser nur nicht vom verwendeten Browser ausgeführt wurde, da beispielsweise JavaScript deaktiviert ist. Um also sicher ausschließen zu können, dass die Seite diesem kleinen Anschlag widerstanden hat, sollte der generierte HTML-Code untersucht und geprüft werden, ob der eingetragene String (<script>alert( hello )</script>) im HTML-Code der Seite auftaucht oder nicht. 2.5 Codeinjektion Wie bereits aus dem Text zu erkennen ist, ist Codeinjektion die Grundlage für XSS und geschieht in variablen Bereichen dynamischer Webseiten, also überall dort, wo Benutzer etwas selbstständig eintragen dürfen. Entscheidend hierbei ist, dass der Browser, in dem eine manipulierte Webseite dargestellt wird, nichts über den Zweck oder Ursprung des in dieser Seite enthaltenen Codes wissen kann und deswegen auch den injizierten Code gewissenhaft ausführen würde. Da der hinzugefügte Code nun Teil der Seite ist, verfügt er auch über die Berechtigungen der Seite, weswegen Verschlüsselungstechniken und ähnliche Sicherheitsvorkehrungen nutzlos werden. Vor allem bei Webseiten, die die Eingabe von Benutzern anschließend anzeigen und dabei diese Eingaben vorher nicht ausreichend filtern und prüfen, kann Code injiziert werden. Werden die Eingaben in Gästebüchern, Foren, privaten Nachrichten oder anderen Anwendungen, die auf den gleichen Prinzipien basieren, nicht ausreichend geprüft, könnten diese zum injizieren von Code verwendet werden. In [15] wird ein Beispiel anhand einer dynamischen Seite, die mit PHP geschrieben wurde, demonstriert. Diese Seite hat ein Titel- und ein Text-Feld, die um des Beispiels willen ungefiltert übernommen werden. Mit Hilfe der Zeile: setcookie("xss", "This content will be stored in a cookie" ); wird ein Cookie mit dem Namen xss angelegt, das den Inhalt This content will be stored in a cookie hat. Um dieses Cookie zu stehlen, kann der Angreifer (nachdem der Inhalt des Textfelds und des Titelfelds nicht gefiltert wird) in das Textfeld folgenden JavaScript-Code eintragen: <scrpt>document.location=" info="+document.cookie;</script>

5 Anschließend wird im Browser der in Abbildung 2 zu sehende Link angezeigt. Wie man deutlich erkennen kann, sind die Daten aus dem Cookie ausgelesen und nun dem Angreifer bekannt. Abbildung 2: Anzeige eines Browsers (nach Umleitung zu einem anderen Server) mit den gestohlenen Cookie-Daten als Parameter. [15] Das Freeware-Tool phpbb, das es dem Benutzer ermöglicht, auch ohne weiterführende Programmier- oder HTML-Kenntnisse Foren zu erstellen und zu administrieren, wurde durch eine PHP Anweisung anfällig auf XSS. Dies wird mit einem Beispiel aus [9] vorgeführt. Mit der Anweisung include_once($phpbb_root_path= common.php ) wird die Datei common.php aus dem Root-Verzeichnis geladen. Dies ließ sich jedoch ausnutzen, indem man die dynamische Seite mit folgendem Code fütterte : /plugin.php&phpbb_root_path= Dies führte dazu, dass statt der gewünschten Datei die Datei ausgeführt wurde. LDAP-, SSI-, XPath- als auch SQL Injection sind zur Zeit wichtige Begriffe im Bereich der Codeinjektion. Davon ist die SQL Injection die zur Zeit wohl am meisten genutzte Attacke, weswegen diese anschließend genauer in Augenschein genommen wird. Dabei nutzen die jeweiligen Injektionen die Eigenheiten der verwendeten Sprache, so dass die XPath Injection für die Manipulation von XML-Dokumenten verwendet wird, während die SQL-Injection SQL-Anweisungen manipuliert. Allerdings liegt allen Injektionen die selbe Schwachstelle zu Grunde: mangelnde Filterung der Benutzereingaben, weswegen die Verbesserungsvorschläge, die für SQL Injection gelten, auch für andere Codeinjektionen verwendet werden können - außer natürlich bei codespezifischen Eigenheiten, die dem Benutzer die Absicherung von Internetauftritten erleichtern. 2.6 SQL Injection Da viele Content Management Systeme eine Datenbank Anbindung haben und diese sich über eine Web-Oberfläche steuern lässt, ist es nahe liegend, einen Angriff auf die Datenbank zu unternehmen, um empfindliche Daten zu stehlen oder gar die Kontrolle über den Server zu erlangen. Auch die SQL Injection ist durch Ausnutzen einer Sicherheitslücke möglich, die durch mangelnde Maskierung bzw. Überprüfung in Benutzereingaben entsteht. Dabei werden SQL-Kommandos entweder eingeschleust oder manipuliert. Auch hier wird über die Parameter der URL der zu injizierende Code an die Webseite weitergereicht. Laut [9] treten bei.asp und.cfm Skripten am häufigsten Probleme auf, die eine SQL Injection ermöglichen. Nachfolgend ist eine Login-Abfrage in SQL zu sehen, die anschließend angegriffen werden soll. SELECT * FROM users WHERE name = $username AND password= $password Falls keine Filterung die Zeichen, die in SQL als Sonderzeichen behandelt werden, unschädlich macht - auch escapen genannt - könnte ein Angreifer statt dem Benutzernamen "admin --" eintragen was zu einer SQL - Abfrage wie unten aufgeführt führen würde.

6 SELECT * FROM users WHERE name = admin -- AND password= $password Da -- in SQL ein Kommentarzeichen ist, wird eigentlich nur die folgende Abfrage ausgeführt: SELECT * FROM users WHERE name = admin Somit wird also ein passwortloser Zugang zum Server gewährt, da das Passwort nun in der Abfrage nicht mehr relevant ist, d.h. man müsste nur noch den korrekten Benutzernamen kennen um sich einloggen zu können. Zwar ist das eine relativ simple Möglichkeit, sich Zugang zu einem Server zu verschaffen und sollte heutzutage nicht mehr möglich sein, dennoch erlaubte laut [9] 2006 das Karriereforum von T-Online einen ebensolchen passwortlosen Zugriff als Administrator. Ein Beispiel soll nun den Ablauf einer SQL Injektion verdeutlichen. 4 Zunächst muss natürlich eine Webseite gefunden werden, die Parameter an eine Datenbank übergibt. Wie bereits oben angesprochen, treten die meisten SQL Injection Probleme bei Skriptaufrufen mit den Endungen.asp und.cmf auf. Deswegen bietet es sich an, verstärkt danach zu suchen. Sobald man fündig geworden ist, folgt man zunächst dem Link um vor Ort zu prüfen, ob die gewählte Seite auf Injektion anfällig ist oder nicht. Dafür gibt es zwei Methoden und beide sollten ausprobiert werden. Es ist bereits bekannt dass Code über die Parameter der URL injiziert werden kann. Deswegen werden hier die Parameter der URL (z.b. ausgetauscht - in diesem Beispiel die Zahl 512. Bei der ersten Variante wird der komplette Wert durch ein einfaches Anführungszeichen ausgetauscht, d.h. aus name=value wird name=. Die zweite Variante verlangt das Setzen des Anführungszeichens in die Mitte von value, so dass anschließend eine Parameterübergabe so aussieht: name=val ue. Die so veränderte URL wird mit Enter bestätigt, um zu prüfen, ob eine Datenbank-Fehlermeldung von der betroffenen Seite ausgegeben wird. Die gesuchten Fehlermeldungen können wie folgt aussehen: Fehlermeldungsart 1: Microsoft OLE DB Provider for SQL Server error 80040e14 Unclosed quotation mark before the character string 51 ORDER BY some_name. /some_directory/some_file.asp, line 5 Fehlermeldungsart 2: ODBC Error Code = S1000 (General error) [Oracle][ODBC][Ora]ORA-00933: SQL command not properly ended Wie auch schon im Kapitel 2.4 beschrieben wurde, kann die gesuchte Fehlermeldung im HTML Code liegen ohne angezeigt zu werden. Deswegen muss also auch der Code angesehen werden. Am leichtesten ist es nach den Ausdrücken Microsoft OLEDB oder [ODBC] zu suchen. Werden die beschriebenen Fehlermeldungen gefunden, ist nachgewiesen, dass die untersuchte Anwendung für SQL-Injection zugänglich ist. 4 Beispiel anhand [6].

7 3 Gegenmaßnahmen Viele Programmiersprachen bringen von Haus aus Sicherheitsoptionen mit sich, die auch eingesetzt werden sollten, wie z.b. die Möglichkeiten die PHP mitbringt, um Zugriffe von außen zu vermeiden. Da PHP eine der Skriptsprachen ist, die heutzutage am häufigsten verwendet wird, um Internetauftritte zu gestalten, werden einige der relevanten Sicherheitsoptionen nachfolgend kurz vorgestellt. 5 : allow_url_fopen = off Diese Option erlaubt es, PHP-Skripten nur noch lokale Dateien des Servers einzubinden. Damit können keine Skripte von externen Servern mehr ausgeführt werden. open_basedir = /pfad/zum/www-ordner schränkt den Arbeitsbereich der Anwendung auf ein Verzeichnis ein. Die Applikation ist nicht mehr in der Lage, Dateien außerhalb dieses Verzeichnisses zu öffnen. Die Unterordner dieses Verzeichnisses können weiterhin benutzt werden. save-mode = on schränkt die Zugriffsrechte der PHP-Anwendung ein auf Dateien die dem Nutzer gehören. Darüber hinaus werden auch einige gefährliche Funktionen wie shell-exec() gesperrt. Eine weitere Steuerung ist durch weitere Optionen dennoch möglich. display_errors = off Da manche Angriffe gezielt Fehlermeldungen provozieren um z.b. Systempfade zur Applikation auszulesen, bietet diese Option die Möglichkeit, das Ausgeben von Fehlermeldungen zu unterbinden. Auch SQL bietet eigene Möglichkeiten, um sich vor SQL Injection Angriffen zu schützen. Eine dieser Möglichkeiten ist das Benutzen von Stored procedures. Das ist eine Funktion, die einige Datenbank-Management-Systeme mitbringen und es dem Benutzer ermöglichen ganze Abläufe von Anweisungen unter einem Namen zu speichern. Damit erfolgt statt vieler einzelner Anfragen vom Client ein Aufruf. Der Hauptvorteil dieser Methode gegenüber SQL Injection, ist allerdings der, dass die stored procedures zusätzliche Befehle zur Ablaufsteuerung und Auswertung erfolgter Anweisungen enthalten können. Jedoch ist der Einsatz von Prepared statements vorzuziehen. Prepared statements sind, wie der Name schon sagt, vorbereitete Statements für ein Datenbank- System, die jedoch noch keine Parameterwerte enthalten. Statt der Parameter werden Platzhalter an das Datenbanksystem übergeben, d.h. die SQL-Befehle und die tatsächlichen Parameterwerte (die dann statt den Platzhaltern eingetragen werden), werden vom Skript getrennt an das API 6 übertragen und somit ist die für die SQL Injection nötige Durchmischung nicht mehr ohne weiteres zu erreichen. Darüber hinaus werden die Parameter beim Eintragen zunächst vom DB-System auf Gültigkeit geprüft bevor sie verarbeitet werden. Als angenehmen Nebeneffekt bringen die Prepared statements den Vorteil mit sich, dass durch die Vorverarbeitung der Abfragen eine schnellere Verarbeitungszeit der Abfragen möglich ist. Hinzu kommt noch die Möglichkeit, die eigene Homepage mit Hilfe von frei verfügbaren Tools auf Schwachstellen gegenüber SQL Injection zu durchsuchen. Ein solches Tool ist der SQL Injection Bruteforcer SQLLibf, das mittels Brute-Force-Angriffen die dynamischen Variablen einer Seite auf Schwachstellen testet. Da der Mensch allerdings gerade bei destruktiven Aufgaben weit mehr kreative Energie aufbringen kann als dieses Tool, kann auch dieses Tool keine absolute Sicherheit garantieren. So ist zu empfehlen Datenbankabfragen korrekt zu formulieren. Einige 5 Quelle: [9]. 6 Application Programming Interface

8 Beispiele (in unterschiedlichen Programmiersprachen), wie man korrekte Abfragen schreibt, sind in [7] zu finden. Allgemein lässt sich festhalten, dass es für den Programmierer einer Anwendung nicht reicht, nur sauber zu programmieren. Er sollte darüber hinaus auch grundsätzlich allen Daten, die in irgendeiner Form von außen manipuliert worden sein könnten, misstrauen und diese als unsicher ansehen. Daraus folgt natürlich, dass alle Daten zunächst auf Gültigkeit geprüft werden müssen - das gilt auch für die Variablen in den URLs! Das heißt natürlich auch, dass keine ungefilterten Strings zur Weiterverarbeitung durchgereicht werden, also z.b. Steuerzeichen durch ihre Escapesequenzen 7 ersetzt werden. Zwar würde dadurch kein unerwünschter Befehl mehr ausgeführt werden, allerdings hat das Ersetzen der Sonderzeichen mit ihren Escape-Sequenzen den Nachteil, dass auch Tags geblockt würden. Und in manchen Foren ist es erwünscht, dass der Benutzer weiterhin die Möglichkeit hat, seinen Text zu formatieren, wodurch das beschriebene Verfahren unbrauchbar werden würde. Deswegen gibt es listenbasierte Filter, bei denen nicht alle, sondern nur die potentiell schädlichen Tags verändert werden. Dabei gibt es das Whitelisting und das Blacklisting. Auch eine Vermischung dieser beiden Filterarten ist möglich. Während das Whitelisting explizit Zeichen erlaubt (z.b. ist es beim Geburtsjahr nicht nötig, Zahlen zu erlauben die kleiner als 1900 sind) verbietet das Blacklisting einige Zeichen, wie z.b. Steuerzeichen (< >) oder ganze Tags (<script>...</script>). Mischt man diese beiden Verfahren, hat man die Möglichkeit, zuerst mit Whitelisting den größten Teil der möglichen Angriffe abzuwehren und anschließend via Blacklisting besondere Randbedingungen abzudecken. Allerdings hat auch diese Art der Absicherung einen Nachteil. Werden die regulären Ausdrücke dieser Listen nicht auf dem neuesten Stand gehalten, ist die pseudo-geschützte Seite zwar gegen einige Angriffe sicher, ist aber jedem Angriff mit noch nicht veröffentlichten Angriffsvektoren 8 schutzlos ausgeliefert. Es ist aber auch wichtig zu beachten, dass, obwohl man seine Seite gegen XSS abgesichert hat, ein mitgehörtes Administratorpasswort jedem Angreifer weiterhin Tür und Tor offen hält. Deswegen ist es ebenfalls wichtig, sensitive Daten nur auf verschlüsselten Kanälen, beispielsweise mit SSL zu übertragen. 4 Fazit Auch wenn XSS vielleicht eher wie Spielerei anmutet als eine ernsthafte Möglichkeit, Webbasierte Systeme anzugreifen, bietet es laut Paul Sebastian Ziegler doch nahezu unendliche Mögichkeiten, Informationen zu stehlen und Schaden anzurichten [15]. Deswegen ist es wichtig, weiterhin die Entwicklung von neuen Angriffsvektoren im Auge zu behalten und Sicherheitslücken möglichst frühzeitig zu schließen. Bislang wurde nur auf Beispiele eingegangen, bei denen ein Benutzer eine manipulierte URL anklicken musste, um einen Angriff auszulösen, was die Gefahr zu schmälern scheint. Denn vermeintlich würde ja wohl keiner einen Link anklicken, der manipuliert ist und in dem eindeutig JavaScript (oder andere) Befehle zu sehen sind, die dazu dienen Daten, zu stehlen. 7 Indem man Sonderzeichen escapet wird die Ausfürhung der Befehle verhindert, der Text wird aber im Browser vollständig angezeigt. Also wird aus <script> <script> 8 Angriffsweg und die Angriffstechnik die von Angreifern verwendet wird

9 Jedoch sollte man das nicht als Grund sehen, die Gefahr, dass ein derartiger Angriff ausgelöst wird, zu unterschätzen, denn zum Einen werden manipulierte Links mit URL-Spoofing-Techniken und Kodierungsverfahren getarnt um harmlos zu wirken. Zum Anderen gibt es im WWW viele User, die weder Skriptsprachen kennen noch verstehen, wie ein Link eigentlich funktioniert und somit wohl auch einen nicht frisierten und eindeutig schädlichen Link wohl anklicken würden. Ein weiterer Punkt ist, dass man manchmal gar keinen Link anklicken muss, um einen Angriff zu starten, denn mit Hilfe von onmouseover -Effekten kann man die Ausführung einer Attacke bereits veranlassen, sobald der Mauszeiger eines Benutzers über einem mit so einem Effekt versehenen Feld oder Text ist. Auch ist es möglich, Webspider 9 zu missbrauchen, um präparierte Links aufzurufen. Dabei wird in den Logs des attackierten Servers die IP-Adresse des Webspiders zu finden sein und nicht die des tatsächlichen Angreifers. Das sind einige der Gründe, warum es wichtig ist, seine Applikationen sauber zu schreiben und die verwendeten Filter immer wieder zu aktualisieren, um nicht einem neuen Angriffsvektor zum Opfer zu fallen. Denn obwohl seit Längerem bekannt ist, wie man die zu verarbeitenden Daten Filtern kann und sollte, werden täglich neue Schwachstellen, selbst in großen Webanwendungen gefunden. Es ist auch wichtig zu beachten, dass trotz der besten Sicherungsmechanismen auf Software-Ebene die eigenen Server auch physisch geschützt werden sollten. Denn bei vielen Angriffen auf Online-Systeme ist es für einen Angreifer lukrativer, tatsächlich in ein Gebäude einzubrechen und die Daten samt Festplatten zu stehlen, als Möglichkeiten zu suchen, eine Seite über das WWW anzugreifen und zu verhindern, dass die eigene IP-Adresse bei dem durchgeführten Angriff protokolliert wird. Auf jeden Fall ist sicher, dass immer vertraulichere Daten mit Hilfe von Anwendungen ausgetauscht werden und diese Daten vor Übergriffen gesichert werden müssen. Es liegt in der Verantwortung des Betreibers einer Anwendung, wie viel Sicherheit als ausreichend angesehen wird. Jedoch sollte niemand mit dieser Verantwortung zu leichtfertig mit dem Begriff Sicherheit umgehen, da eine einmal korrumpierte Seite diesen Ruf nur schwer wieder los wird. Literatur [1] Security Hacks. Abfragedatum: 24.Mai /05/18/top-15-free-sql-injection-scanners [2] Astalavista Group. Abfragedatum: 24.Mai [3] XSS (Cross-Site Scripting) Cheat Sheet. Abfragedatum: 24.Mai ckers.org/xss.html [4] heise Security news Sparkassen schlampen bei Online-Banking-Sicherheit. Heise Zeitschriften Verlag. Abfragedatum: 24.Mai news/meldung/89885 [5] Caleb Sima: Locking the Door Behind You: Hacker Protection for Your Web Applications. Abfragedatum: 24.Mai education/articles/hacker-protection.html 9 Automatisierte Tools, die Webseiten nach Links durchsuchen und diese Links nach einander durchlaufen, werden Webspider genannt (auch weil sie sich einem Netz ähnlich fortbewegen). Webspider werden z.b. von Suchmaschinen eingesetzt um möglichst viele Webseiten finden zu können.

10 [6] Bryan Sullivan: Malicious Code Injection: It s Not Just for SQL Anymore. Abfragedatum: 24.Mai articles/code-injection.html [7] SQL-Injektion. Abfragedatum: 20.Juni index.php?title=sql-injektion&diff= &oldid= [8] Andreas Gröbl, Thomas Radler: Risiko CMS? Sicherheitsanalyse bei NPS 6 Fiona. Fachhochschule Augsburg, SS 2006 [9] Christiane Rütten, Tobias Glemser: Gesundes Misstrauen Sicherheit von Webanwendungen. C t 2006, Heft 26, S. 234ff [10] Kai Fuhrberg, Dirk Häger, Stefan Wolf: Internet-Sicherheit Browser, Firewalls und Verschlüsselung, 3. Auflage. Hanser Verlag, ISBN [11] Jörg Schwenk: Sicherheit und Krypthographie im Internet Von sicherer bis zu IP-Verschlüsselung, 1. Auflage. Vieweg Verlag, Oktober ISBN [12] Othmar Kyas: Sicherheit im Internet, 2. Auflage. MITP-Verlag, ISBN [13] Sicherheit in Verwaltungs- und Kliniknetzen Anforderungen, Möglichkeiten, Empfehlungen. Bericht der Arbeitsgruppe Verwaltungen nd Kliniken im Hochschulnetz. Bayerisches Staatsministerium für Unterricht, Kultus, Wissenschaft und Kunst, 1998 [14] Stefan Nusser: Sicherheitskonzepte im WWW. Springer Verlag Berlin Heidelberg, ISBN X [15] Paul Sebastian Ziegler: XSS Cross-Site Scripting. hakin9 - Hard Core IT Security Magazin 2007, Heft 1, S. 20ff [16] Gespräch mit Prof. Dr. Kowarschick (FH Augsburg) am

11 Erstellungserklärung Hiermit erkläre ich, Jewgenija Konrad, dass ich die vorgelegte Arbeit selbstständig verfasst, noch nicht anderweitig für Prüfungszwecke vorgelegt, keine anderen als die angegebenen Quellen oder Hilfsmittel benutzt, sowie wörtliche und sinngemäße Zitate als solche gekennzeichnet habe. Jewgenija Konrad Augsburg, den 26. Juni 2007.