Sicherheitsanalyse Webserver

Inhaltsverzeichnis

1 Einleitung
1.1 Problemstellung
1.2 Zielsetzung

2 Quellcode
2.1 Fehler und Risiken
2.2 Passwortgeschützter Zugang
2.2.1 HTML und clientseitige Skripte
2.2.2 Serverseitige Skripte
2.2.3 Referer Header und Cookies
2.2.4 Codebeispiele
2.2.4.1 Beispiel 1 - Sourcecodeanalyse
2.2.4.2 Beispiel 2 - Sourcefehler
2.2.4.3 Beispiel 3 - Sessions
2.2.4.4 Beispiel 4 - Skriptinjections & Referer & Cookies
2.2.4.5 Beispiel 5 - Dateien außerhalb des Webverzeichnisses / Includes
2.2.4.6 Beispiel 6 - SQL-Injections
2.3 Angriffsmethoden
2.3.1 Spoofing
2.3.1.1 Adress Resolution Protocol-Spoofing
2.3.1.2 Domain Naming Service-Spoofing
2.3.1.3 IP-Spoofing
2.3.1.4 Route-Spoofing
2.3.2 Denial of Service
2.3.2.1 Flooding
2.3.2.2 Intern Control Message Protocol - Angriffe
2.3.3 Scanning
2.3.3.1 Portscanning
2.3.3.2 Sniffing
2.3.4 Cracking
2.3.5 Phishing

3 Internet Information Server
3.1 Risiken
3.2 Standardeinstellungen und Konfiguration
3.2.1 Änderungen an den Standardeinstellungen
3.2.2 Sicherheitsmaßnahmen
3.2.2.1 Sicherheitsrichtlinie
3.2.2.2 Logging
3.2.2.3 Checkliste
3.2.3 Verbesserungen gegenüber IIS 5
3.3 Security Analyse
3.4 Hotfixes
3.4.1 Aktuelle Sicherheitslöcher
3.4.1.1 Kompressionsfehler verursacht Zugriffsverletzungen
3.4.1.2 Kennwortänderungsseiten
3.4.1.3 WebDAV-XML Message Handler
3.4.1.4 FTP-Resume-Feature
3.4.1.5 ASP.NET und Set-Cookie
3.4.2 Herstellerverhalten
3.5 Systeme die auf den Webserver einwirken
3.5.1 Betriebssystem
3.5.2 Intrusion Detection System
3.5.3 Demilitarized Zone
3.5.4 Firewall
3.5.5 Viruskiller

4 Apache
4.1 Risiken
4.2 Standardeinstellungen und Konfiguration
4.2.1 Änderungen an den Standardeinstellungen
4.2.2 Sicherheitsmaßnahmen
4.2.2.1 Logging
4.2.2.2 Checkliste
4.2.3 Verbesserungen gegenüber Apache 1.3 bzw. 2.0
4.2.3.1 Verbesserungen von Apache 2.0 gegenüber 1.3
4.2.3.2 Verbesserungen von Apache 2.2 gegenüber 2.0
4.3 Securityanalyse
4.4 Updates
4.4.1 Aktuelle Sicherheitslöcher
4.4.1.1 Referer Cross-Site Scripting
4.4.1.2 Behobene Sicherheitslöcher in Version 2.0.58
4.4.1.3 Behobene Sicherheitslöcher in Version 2.0.55
4.4.2 Herstellerverhalten
4.5 Systeme die auf den Webserver einwirken
4.5.1 Betriebssystem
4.5.2 Intrusion Detection System
4.5.3 Demilitarized Zone
4.5.4 Firewall
4.5.5 Viruskiller

5 Ergebnisse und Schlussfolgerungen

6 Zusammenfassung

7 Verzeichnisse
7.1 Literaturverzeichnis
7.2 Abbildungsverzeichnis
7.3 Tabellenverzeichnis
7.4 Listingverzeichnis
7.5 Formelzeichen, Indizes und Abkürzungen

Danksagung

Auch an dieser Stelle möchte ich persönlich darauf hinweisen, dass trotz der Kritik die sowohl kommerziell Softwarehersteller und auch Open Source Entwickler laufend von allen Seiten hinnehmen müssen, die Produkte Internet Information Server und Apache ganz ausgezeichnete sind. Ich kenne selbst noch die Zeit, wo ein Viruskiller die einzige Sicherheitsmaßnahme am Rechner war und auch die ersten Versionen von Windows (DOS), Apache und IIS. Anwender verwünschen oft die Hersteller für deren Entwicklungen, Fehler der Software, Abstürze usw., vergessen aber meiner Meinung nach häufig, dass wenn man die Komplexität der Software heranzieht, es bereits unglaublich ist, dass ein Computer überhaupt bootet. Wenn man die Softwareprodukte im Laufe der Zeit vergleicht und beobachtet, kann man leicht entdecken, dass die Komplexität ständig zunimmt, aber trotzdem Millionen Benutzer ein verwendungsfähiges System vor sich haben.

Persönlich danke ich meinem Betreuer DI. Rainer Schmidt für seine Inputs zu den einzelnen Themen. Sein Fachwissen selbst zu tiefgehenden Themen hat mich bei jedem Gespräch aufs Neue beeindruckt.

Weiters danke ich meinem persönlichen Freund MBA Werner Kölbl für seine kreativen Anmerkungen und seine technische Unterstützung.

Darüber hinaus danke ich dem Team meines Studiengangs für die umfassende und interessante Ausbildung.

Last but not least danke ich meinem persönlichen Freundeskreis für die Geduld, die Unterstützung und das aufgebrachte Verständnis während meines Studiums und während der Erstellung dieser Arbeit.

Reinhard Hofer

30.05.2006

Kurzfassung Deutsch

Die Diplomarbeit setzt am Punkt Internet an, dem zentralen Werkzeug zur Kommunikation bzw. Informationsbeschaffung. Da das Thema Internet und auch Sicherheit ein sehr umfangreiches ist, spezialisiert sich die Arbeit auf die Server, die hinter dem Webseiten stehen und von alltäglichen Benutzern nicht wahrgenommen werden. Es ist nicht Ziel dieser Arbeit, sonstige Bereiche der Kommunikation, Sicherheit, Internet oder Plattformen zu behandeln. Es ist weiters nicht Ziel, neue Sicherheitslöcher in Webserverprodukten aufzudecken oder detailliert auf Mittel und Wege hinzuweisen, Webserver oder Webseiten zu kompromittieren. Sehr wohl ist aber wichtig, nicht nur die Server selbst zu untersuchen, sondern auch grundsätzlich die Clientseite und hier im Speziellen den Sourcecode zu erklären.

Die Arbeit ist in drei Abschnitte unterteilt. Der einleitende Abschnitt beinhaltet Theorie zu gängigen Angriffsformen auf Webserver und Webseiten und beinhaltet damit auch gängige Formen zum widerrechtlichen Erlangen von Passworten oder zum Umgehen von passwortgeschützten Techniken. Zusätzlich zum theoretischen Ansatz beinhaltet dieses Dokument Beispiele für mögliche Techniken und deren Schwachstellen. Im Sourcecode-Abschnitt wird gezeigt, wie man den Zugang zu Webserverressourcen beschränken kann und worauf man dabei achten muss bzw. wo und wie Angreifer ansetzen können. Dazu gibt es mehrere Beispiele, die an Komplexität zunehmen und aufsteigend angeführt werden.

Die beiden anderen Abschnitte behandeln die beiden Webserver Internet Information Server 6 und Apache 2.2 und sind gleich aufgebaut und zeigen eine vergleichende Sicht auf das jeweilige Produkt. Im Vordergrund steht auch hier der Sicherheitsaspekt. Welche Schwachstellen weist das jeweilige System auf und wie kann man sich schützen? Die Beschreibung der Konfiguration bzw. der Schritte zur Absicherung des Systems zeigen auch, wo die jeweiligen Schwachstellen liegen und welcher Konfigurationsaufwand dabei entsteht. Das Abschlusskapitel zeigt die resultierenden Ergebnisse.

Kurzfassung Englisch

Security is no longer about a second lock for your door or about buying an alarm system. Today’s networking and the geographical extension of computers and Internet leads to new security threats. The Internet is today’s centre of communication and information gathering. As web servers are at the centre of almost all online communication and are therefore the centre for security measures, this thesis focuses on the servers which are not visible by common users. The aim of this work is not to explain operating systems, Internet communication, platforms etc. Furthermore, the author doe not intend to discover new security leaks in actual web server software or to explain in detail how to compromise a web server system. That is to say, it takes a look at the clients and explains the source code executed on their side.

The thesis is divided into three sections. The introductory section includes the theoretical background of common attack scenarios on web servers and websites. It also refers to common ways of avoiding or bypassing password protected techniques. In addition to the theoretical part, the thesis includes examples of source code and their weaknesses. This section shows methods to restrict access to resources and describes the possibilities available to hostile users. The complexity of the examples increases and is in ascending order. The examples shown describe client side and server side code and are written in script languages like PHP, JavaScript, VB.(NET) and JSP.

The other sections cover the two web servers that have the largest market share. The chapters about Internet Information Server 6 and Apache 2.2 have the same structure and compare both products. Certainly, security is given priority. Which weaknesses are there and how can one protect oneself? Additionally both chapters mention basic security measures. The explanation of configuration and first steps show the complexity and effort needed. Besides the substantial research the reader can find multiple analyses on network traffic as well as scans of the server systems and a comparison of security holes. The final chapter shows the results.

1 Einleitung

1.1 Problemstellung

Bereits der Amerikaner Abraham H. Maslow hat in seinem Studium über die Bedürfnisse der Menschen Sicherheit als wesentlichen Bestandteil aufgenommen. Genauer ist in seiner „Hierarchy of the prepotency of human needs“, übersetzbar mit Bedürfnispyramide, der Punkt Sicherheit auf Stufe 2 und somit unmittelbar nach den Grundbedürfnissen. Sicherheit ist ein Begriff der viele Aspekte im Leben und in der Gesellschaft vereint und eine Möglichkeit zum Befriedigen des Sicherheitsbedürfnisses ist Vorbeugung bzw. Implementierung von Schutzmechanismen.

Betrachtet man das Thema Sicherheit im Rahmen der IT, dann wird deutlich, wie weit verzweigt dieses Thema wirklich ist. IT-Sicherheit war mehr als 20 Jahre nicht von Nöten. Das Urnetz ARPANET war eine Vernetzung von vier Rechnern zwischen Universitäten in den USA. Die Teilnehmer kannten sich untereinander. Das World Wide Web, das 1989 von Cern entwickelt wurde, hat die Situation geändert. Plötzlich war die Allgemeinheit eingebunden und damit das Netzwerk unkontrollierbar. Reichte vor einem Jahrzehnt noch ein guter Virenkiller aus, so ist heutzutage ein ungeschützter Server im Internet innerhalb von Minuten das Opfer irgendeiner Form eines Angriffs.

Von allen Sicherheitsmechanismen wie Intrusion Detection Systems, Honeypots, Sicherheitsrichtlinien usw. ist in dieser Arbeit vor allem die Sicherheit von Webservern im Vordergrund. Ein Webserver steht natürlich nicht auf sich selbst gestellt im Netz. Eine Firewall ist obligatorisch und jedes System, das das Netzwerk bzw. den Server selbst schützt, unterstützt die Sicherheit des Webserver mit. Die Fragen, die sich stellen sind, welchen Webserver man verwenden soll und worauf man achten muss bzw. welche Möglichkeiten man bei der Konfiguration hat. Der heute marktführende Webserver ist Apache, gefolgt vom Internet Information Server. Es gibt weitere Webserver die mitunter spezialisiert in einem bestimmten Bereich sind. Tomcat beispielsweise ist weniger ein Webserver, sondern eine Servletengine¹. MyServer ist ein weiteres Open Source Project mit GNU General Public License (GPL) oder Zeus stellt einen High Performance Webserver dar. Im Zuge dieser Arbeit werden die beiden wohl bekanntesten, sicher aber wichtigsten Server Apache und IIS evaluiert und verglichen.

1.2 Zielsetzung

Ziel ist, die Risiken beim Einsatz von Webservern aufzuzeigen und auf entsprechende Lösungen hinzuweisen. Die Arbeit beantwortet, welcher Webserver unter welchen Bedingungen der bessere und sichere ist. Dies beginnt bei der Konfiguration, die bei beiden Produkten sehr umfangreich und oft verwirrend ist. Jeder Server hat seine eigenen Schwächen, wobei einige bekannt sind bzw. von den Herstellern behoben, andere nicht. Vor allem die Möglichkeiten zur Beeinträchtigung der Funktionalität und Erlangen von geheimer Information sind wichtig. Welche Möglichkeiten gibt es, sich vor Eindringlingen zu schützen? Welche Risiken bestehen generell? Nicht nur das fertige Endprodukt wird untersucht, sondern auch das Verhalten der Hersteller. Nur Microsoft und die Apache Software Foundation können Sicherheitsmängel beheben. Hier wird untersucht, wie das Verhalten der Hersteller ist und wie schnell aufgedeckte Mängel behoben werden.

Die benutzten Betriebssysteme stehen hier im Hintergrund. Apache läuft zwar auf allen Linuxderivaten und auf Windows, jedoch ist für IIS Windows Voraussetzung. Die Systeme rund um den Webserver stehen im Hintergrund. Selbstverständlich wird auf Entsprechendes hingewiesen, es ist jedoch nicht Ziel dieser Arbeit, die Konfiguration des Netzwerks oder eine Anleitung zur Erstellung von Sicherheitsrichtlinien zu liefern. Noch weniger ist es Ziel eine Anleitung zum Hacken zu liefern. Viel mehr werden Fehler aufgezeigt und die Möglichkeit zur Vermeidung eben dieser.

Ein Kapitel widmet sich dem Sourcecode selbst. Jeder Webserver dient letztendlich nur der Umwandlung der Source in lesbaren Text, d.h. der Ausgabe für den Browser. Der beste Server kann nicht verhindern, dass das Passwort der Seite im Sourcecode steht. Solche Fehler im Sourcecode sind natürlich ebenfalls zu vermeiden.

2 Quellcode

2.1 Fehler und Risiken

Seit dem Jahr 2000 gibt es einen sprunghaften Anstieg an publizierten Schwachstellen in Soft- und Hardware. Dieser Anstieg korreliert mit einem Anstieg an Sicherheitszwischenfällen, die unter anderem solche Schwachstellen ausnutzen. Weiters muss berücksichtigt werden, dass nicht jeder Zwischenfall erkannt oder gemeldet wird, was die Zahlen noch weiter in die Höhe treibt. Von den finanziellen Kosten her betrachtet, sind Viren und Denial-of-Service - Angriffe die kostspieligsten. Die Gründe hierfür liegen einerseits in der relativ einfachen Verbreitung von Viren und der geringeren Komplexität von Zerstörungsangriffen im Vergleich zu Einbrüchen in Systeme.² Ein Virus, das sich selbst per Mail verbreitet, indem es sich selbst beim Ausführen an alle Mailkontakte des Mailclients versendet, kann in sehr kurzer Zeit eine hohe Anzahl an Clients infizieren und beinträchtigen. Der sprunghafte Anstieg im Jahr 2000 ist damit allein noch nicht erklärt, vielmehr korreliert dieser Anstieg mit der gestiegenen Anzahl an Computern bzw. Internetanschlüssen. „Die Survival Time eines nicht gepatchen Windows XP PC an einer Auswahl an Breitbandnetzwerken ohne Firewall in einem normalen Betriebszustand betrug im März 2006 mindestens 15 Minuten. Einhergehende Messungen in Kabelnetzen zeigen 50 - 60 Portscans und Einbruchsversuche an einem Anschluss pro Minute.“³ Es ist auch interessant, dass laut Sans bei den ersten fünf Schwachstellen bei Windows der Webserver und Services an oberster Stelle steht und bei Unix der Webserver an zweiter Stelle steht. Ein als Teil dieser Arbeit stattgefundener Versuch mit einem gepatchen Windows XP SP 2 Client ohne Firewall an einem Kabelanschluss hatte nach 30 Minuten Surfen im Internet unter dem Administratorkonto das Ad-aware 6.181 - Scanergebnis von 7 erkannten Objekten, wobei es sich bei fünf um Cookies handelte jedoch ein Registrykey und ein Registryvalue enthalten waren. Ein weiterer Versuch an einem Debian Woody 3.0 Server mit Apache 2 Webserver und öffentlicher statischer IP zeigte durch Analyse der Serverprotokolle etwa einen Angriff pro Sekunde, wobei unter Angriff auch Portscans gewertet wurden. Die Firewall auf dem Rechner, auf dem dieses Dokument erstellt wurde, zeigt vom Zeitpunkt der Installation des Systems, dem 3.6.2005 bis zum 27.3.2006 insgesamt 483.648 Vorfälle, wobei davon 53.537 als kritisch angesehen werden. Dies ergibt etwa einen Angriff pro Sekunde, wobei man noch hinzurechnen muss, dass der Rechner nur geschätzt etwa ein Viertel der Zeit wirklich online war. Die verwendeten Firewalls waren Zonealarm 5 und 6.

Es gibt eine ganze Reihe an Gefahren für ein Netzwerk bzw. Server, von Naturgewalten beginnend über Angriffe bis hin zu fehlerhaftem Code. Für die meisten Szenarien gibt es Schutzmechanismen und Vorgehensweisen, jedoch kann das sicherste System keinen Fehler im Sourcecode verhindern. Selbst die beste Firewall und der sicherste Webserver können nicht verhindern, dass Unbefugte Zugriff auf geschützte Seiteninhalte haben, wenn das Passwort im Sourcecode steht oder noch schlimmer, auf einem Zettel unter der Tastatur klebt. Laut den Microsoft Certified System Engineer - Unterlagen ist der erste Schritt für ein sicheres System das Abschließen des Serverraums. Tatsächlich kann man jemand Unbefugten, der physischen Zugriff auf einen Server hat, nicht mehr aufhalten. Mittels Software zum Cracken von Passworten kann man einen Windows Client innerhalb von Augenblicken mittels einer entsprechend präparierten Diskette knacken, wobei der Vorgang bei einem Domaincontroller etwa 30 Minuten dauert, da man hier auch die Registry bearbeiten muss. Ein im Zuge dieser Arbeit entsprechend durchgeführter Versuch an einem Windows XP Client und zusätzlich an einem Windows 2000 Server als Domaincontroller hat Erfolg gezeigt, wobei damit im Detail das Zurücksetzen des lokalen Administratorkontopassworts gemeint ist. Die entsprechende Diskette zum Booten des Systems wurde mit der Software Offline NT Password & Registry Editor erstellt. Durch das Zurücksetzen des Passworts auf leeren Inhalt, ist danach das Einloggen als lokaler Administrator ohne Passwort möglich, was bei einem Domaincontroller den Zugriff auf die ganze Domäne inklusive aller Clientrechner bedeutet. Zugegebenermaßen hinterlässt man Spuren, da einerseits das Passwort nicht mehr gesetzt ist, was beim ersten Einloggen des Zuständigen bemerkt wird, zweitens wird das Herunterfahren des Systems für den Boot mit der Diskette protokolliert bzw. ab Windows Server 2003 beim Neustart darauf hingewiesen. Die noch einfachere Variante wäre, die Festplatte auszubauen und an einem eigenen Rechner mit Administratorrechten einzubauen und im Betriebssystem den Besitz über die gesamte Verzeichnisstruktur zu übernehmen. Dadurch erreicht man zwar keinen Zugriff auf das komplette Netzwerk, jedoch auf die auf der Platte gespeicherten Daten inklusive eventuell vorhandener Passworten.

2.2 Passwortgeschützter Zugang

2.2.1 HTML und clientseitige Skripte

Die Hypertext Markup Language an sich birgt kein Risiko, da HTML eine Auszeichnungssprache ist und keine aktiven Inhalte hat. Clientseitige Skripte werden jedoch in HTML eingebunden. Aktive Inhalte können bösartigen Code enthalten, der ein entsprechendes Sicherheitsrisiko darstellen kann. Aktive Inhalte können Dynamic HTML, VB-Script oder JavaScript sein. Clientseitige Technologien sind die etwas einfachere Lösung, da man keinen Webserver benötigt, der den Code interpretiert, jedoch sind serverseitige Technologien state of the art und mächtiger. Java-Applets werden oft von Banken für Onlinebanking verwendet. Java-Applets stellen Javacode dar, der von einer virtuellen Javamaschine interpretiert wird. Es gibt Sicherheitsmechanismen bzw. das Sandkastensystem, das einem Applet Einschränkung auferlegt, so dass das Ändern von Systemdateien nicht möglich ist. Der Sandkasten ist eine eigene Laufzeitumgebung. Die einzig relevante Gefahr von Java-Applets ist eine komplette Auslastung der Ressourcen eines Rechners und auch dies ist nicht wesentlich. Applets wurden mit der Idee eingeführt, aktive Inhalte für Webseiten zu bieten, ohne einen ständigen Datentransfer mit dem Server zu benötigen. Servlets sind in etwa das serverseitige Gegenstück.⁴ Die Konfigurationsoptionen der gängigen Browser erlauben das Deaktivieren von Java.

JavaScript ist der wohl bekannteste Vertreter der clientseitigen Skriptsprachen und hat nichts mit der Programmiersprache Java zu tun. Die gängigsten Anwendungsgebiete sind Formulare und Popups. Man kann sogar programmieren, dass beim Schließen eines Fensters ein neues oder eine Vielzahl geöffnet wird. Das ist jedoch nicht das wesentliche Sicherheitsrisiko. Erheblicher sind Angriffe, die Sicherheitslücken von Browsern ausnutzen. Skripte können in den gängigen Browsern deaktiviert werden. JavaScript beinhaltet jedoch Sicherheitsmechanismen wie die Überprüfung der Herkunft eines Skripts und Signed Scripts. JavaScript kann nur auf Webseiten der gleichen Quelle unbeschränkt zugreifen. Dadurch wird verhindert, dass mit JavaScript Daten eines anderen offenen Browserfensters ausgelesen werden. Mit gleicher Quelle ist der Domainname gemeint, wobei weder ein anderes Protokoll (ftp:// statt http://) noch ein anderer Port vorkommen darf. Signed Scripts dienen zur Erweiterung bzw. Aufhebung ehemaliger Beschränkungen. Dadurch ist es nun möglich, Dateien am Client zu lesen oder zu ändern, Fenster ohne Rahmen zu erzeugen, die vor allem für Popups geeignet sind, Emails zu versenden usw. Zur Erzeugung von Signed Scripts benötigt man ein Zertifikat, welches angekauft werden muss. Es herrscht jedoch ein großer Preisunterschied bei privaten und kommerziellen Zertifikaten. Einige Browser erlauben es, das obligatorische Einbinden eines Zertifikates zu deaktivieren. Ein Zertifikat informiert über den Ersteller eines Programms und soll bei der Entscheidung helfen, ob man den Inhalten einer Seite oder eines Programms vertraut und diese nutzt. Das Zertifikat, ausgestellt von einer Certificate Authority, garantiert die Identität einer Person oder Firma und stellt eine digitale Unterschrift dar, die auf Verschlüsselung basiert. Weiters garantiert ein Zertifikat, dass die Codeinhalte seit dem Erstellen bzw. dem Release nicht verändert wurden. JavaScript an sich kann in gängigen Browsern deaktiviert werden.⁵

2.2.2 Serverseitige Skripte

Serverseitige Skripte stellen Code dar, der am Webserver ausgeführt wird und wo nur das Ergebnis an den Client gesendet wird. Dadurch eignen sich diese besser für sensible Anwendungsgebiete als clientseitiger Code. Die bekanntesten Vertreter dieser Technologie sind Active Server Pages, Java Server Pages, PHP und Perl. ASP benötigt den Internet Information Server und ist eine Microsofttechnologie, deren letzte Version ASP.NET darstellt. ASP benötigt im Gegensatz zu den folgenden Sprachen keine eigene Installation zusätzlicher Komponenten, vom obligatorischen Webserver abgesehen. JSP basiert auf Javacode und benötigt Tomcat als Servletengine. Tomcat stellt die Umgebung zum Ausführen des Javacodes auf dem Webserver dar, womit JSP eine Softwarekomponente mehr benötigt. PHP basiert von der Syntax auf C und obwohl C nicht objektorientiert ist, bietet PHP diese Möglichkeit. PHP muss auf dem System installiert sein, um vom Webserver ausgeführt werden zu können, genau wie es bei Perl der Fall ist. Perl hat den Ruf einfach und doch mächtig zu sein.

Jede Sprache hat ihre Vor- und Nachteile, wobei der Webserver bei serverseitigen Skripten zur Ausführung obligatorisch ist, was bei clientseitigen Technologien nicht der Fall ist. Die Sicherheitsproblematiken sind grundsätzlich ähnlich.

2.2.3 Referer Header und Cookies

Internetbenutzer sind meist der Überzeugung, sich in einer gewissen Anonymität zu bewegen. Vom gesetzlichen Standpunkt trifft dies auch zu, da in Österreich das Datenschutzrecht sehr streng ist. Wirklich anonym ist man jedoch nie, außer man benutzt öffentliche Hot Spots für WLAN. Es ist ohnehin eine gute Idee, sich für Webseiten, die eine Registrierung verlangen, eine zweite Identität zuzulegen oder so genannte Anonymizerprogramme zu verwenden. Dies ist vor allem eine Maßnahme, um sich vor Spam und Weitergabe privater Daten wie Serverhalten zu schützen. Bei sicherheitskritischen Seiten wie Telebanking muss man die eigene Identität ohnehin nachweisen. Genauso gilt dies beim Abschluss von online Verträgen. Dabei ist man ebenfalls zur wahrheitsgemäßen Angabe verpflichtet. Anonymität hat aber auch hier ihre Grenzen. Zumindest der eigene Internetprovider weiß, wer seine Benutzer sind. Bei analogem Zugang wird man durch die Telefonnummer identifiziert und bei sonstigen wie Kabel, Satellit usw. durch die IP-Adresse. Alle Verbindungen laufen über den Internetprovider und werden meist auch protokolliert. Diese persönlichen und somit sensiblen Daten dürfen natürlich nicht einfach weitergegeben werden. Der Provider selbst kann aber bei Vorliegen von entsprechenden Gründen zur Herausgabe der Daten verpflichtet werden. Solche Gründe können beispielsweise gesetzliche Ermächtigung bei Strafverfolgung oder Gerichtsverhandlungen sein.⁶

Nicht nur der Internetprovider hat ein Interesse daran, wer seine Dienste benutzt. Der Betreiber des Servers, mit dem man sich verbindet, kann ebenso ein Interesse daran haben, wer auf seine Informationen zugreift. Der Webserverbetreiber hat es bereits etwas schwieriger, da dieser weniger Daten zur Verfügung hat. Natürlich sieht man auch am Ziel, welche IP-Adressen gerade zugreifen bzw. im Webserverprotokoll, wer worauf zugegriffen hat. Weniger hilfreich ist dies, wenn mit einer dynamisch vergebenen IP-Adresse zugegriffen wird, da derselbe Benutzer mit unterschiedlichen IP-Adressen auf die Webserverressourcen zugreift. Dieses Problem kann man mit Cookies umgehen. Wenn man auf Webressourcen zugreift, kann der Server zusätzlich Cookies senden. Cookies sind Textdateien. In Windows XP werden diese beim Benutzer auf der Systempartition unter \Documents and Settings\Benutzername\Cookies abgelegt.⁷

Abbildung 2.1: Beispielcookie von www.amazon.de

Abbildung in dieser Leseprobe nicht enthalten

Diese Textdatei wird ab diesem Zeitpunkt bei jeder Anfrage an den Webserver geschickt. Durch diese Methode kann der Webserver alle Zugriffe eines Benutzers miteinander in Beziehung bringen. Prinzipiell kann dadurch aber nur der betreffende Zielserver das Surfverhalten mitprotokollieren bzw. auswerten. Das liegt daran, dass Cookies nur dann verwendet werden können, wenn sich der Benutzerrechner und der Webserver in derselben Netzwerkdomäne befinden. Somit kann der Webserver der Webseite mit der URL www.seite1.at nicht Cookies der Webseite mit der URL www.seite2.at auslesen. Zusätzlich zu den abgerufenen Seiten wird durch den Browser auch mitgeteilt, wenn der Benutzer über den Link einer anderen Webseite kam. Diese Angabe wird Referer-Header bezeichnet. Durch die Verbindung von Cookie und Referer-Header und dem daraus entstandenem Wissen, welcher Benutzer welche Seiten betrachtet, ist es möglich, Benutzern gezielt Werbung anzuzeigen. Letztendlich laufen diese Maßnahmen auf den gläsernen Kunden hinaus.⁸ Vor allem Internetwerbefirmen nutzen diese Information, da Werbebanner auf verschiedenen Seiten von einer Werbefirma betreut werden. Diese Firma ist somit nicht nur in der Lage, Kundenpräferenzen einer einzelnen Domäne zu kennen, sondern von allen Domänen auf denen Anzeigen der Firma platziert sind.

Abgesehen von der Datenschutzproblematik können Cookies für Passworte oder für automatische Anmeldung verwendet werden. Da Cookies meist nicht verschlüsselt übertragen werden, sind diese anfällig für Sniffing. Es gibt mehrere Möglichkeiten für Benutzer Cookies auszuschalten. Einerseits können diese im Browser deaktiviert werden oder nur bestimmten Domänen erlaubt werden, Cookies zu setzten. Man kann auch das ganze Cookieverzeichnis sperren und einen Schreibschutz im Betriebssystem setzen.

2.2.4 Codebeispiele

2.2.4.1 Beispiel 1 - Sourcecodeanalyse

Es gibt unterschiedliche Methoden, um den Zugang auf eine Seite zu regeln. Je nach Möglichkeit kann man einfache oder komplexe Methoden einsetzen. Die technisch einfachste ist ein Passwortvergleich mittels JavaScript direkt im HTMLFile. Im folgenden Beispiel gibt es nur einen Benutzer und Passwort, da die Prozedur für jeden weiteren Benutzer gleich ist.

Abbildung in dieser Leseprobe nicht enthalten

Listing 1: HTML-Seite mit Aufruf der JavaScriptdatei.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2: JavaScriptfunktion zur Passwortabfrage.

In Listing 1 wird die Funktion zur Passwortabfrage in einer separaten JavaScript- Datei gespeichert. Das ist nicht zwingen notwendig, da der JavaScriptsource auch direkt in der HTML-Datei stehen kann. Das Einzige, was ein Betrachter dieser Seite tun muss, ist, sich den Sourcecode anzeigen zu lassen, was gängige Browser erlauben. Darin steht klar und deutlich das Passwort. Das separate Speichern der Funktion erhöht die Sicherheit nur minimal, da man den Inhalt der Datei passwort.js ebenfalls im Browser darstellen lassen kann. Internetexplorer ab Version 6 zeigt bei direkter Eingabe der JavaScript-Datei nicht deren Inhalt an, alle vorhergehenden Versionen sowie Mozilla aber sehr wohl. Den Namen der Funktionsdatei erhält man leicht durch den Inhalt der HTML-Datei. Jeder Angreifer wird zuerst den Source betrachten, um zu wissen, welche Technik des Passwortschutzes gewählt wurde. Selbst das Speichern des Passworts in einer separaten Datei, damit dieses nicht direkt im Source steht, nützt nichts, wenn diese Passwortdatei nicht verschlüsselt ist.

Selbst wenn dieser einfache Mechanismus funktioniert und jemand das Passwort nicht herausbekommt, bleibt immer noch der Versuch, einfach eine Seite dahinter aufzurufen. Man benötigt oft nur eine einzelne Seite dahinter bzw. deren URL, um auf alle Inhalte hierarchisch darunter stehend zuzugreifen. Viele Seiten sind nach dem gleichen Schema aufgebaut und beginnen mit der Startdatei index.htm(l). Manche Webspaceserver fordern diese Datei aus organisatorischen Gründen. Unterseiten können natürlich alle möglichen Namen haben, jedoch sind main.htm, left.htm, frame.htm, seite1.htm usw. nahe liegende Versuche. Einerseits wählen die Ersteller von Webseiten einfache und eindeutige Namen, um den Erstellprozess der ganzen Webseite zu vereinfachen, zusätzlich schlagen diverse HTML-Editoren wie Frontpage zum Beispiel beim Erstellen von Frameseiten solche Dateinamen vor. Selbst wenn man keinen einzigen Treffer errät, geben Suchmaschinen oft Hinweise auf Unterseiten bei der Ausgabe der Trefferliste, da deren Robots das Internet durchforsten und gefundene Seiten indexieren. Oftmals werden Formulare verwendet, die eine Aktion aufrufen, in der mitgeteilt wird, was beim Klicken des Formulars erfolgen soll. Steht hier im Attribut action das Ziel, kann man die Unterseite auch direkt aufrufen. Auch wenn hier kein Erfolg beschert ist, gibt es immer noch die Möglichkeit, statt einer einzelnen Seite einfach das Verzeichnis aufzurufen. Dazu lässt man in der Adressleiste des Browsers die Seite selbst weg. Wurde im Webserver konfiguriert, dass das Auflisten von Verzeichnisinhalten möglich ist, werden daraufhin alle Dateien des Webserververzeichnisses angezeigt, die man daraufhin auch einzeln aufrufen kann. Ist diese Option aktiviert, hilft auch nicht, dass die aktive Funktion der Passwortabfrage am Webserver durchgeführt wird. Verzeichnisinhalte auflisten deaktivieren reicht jedoch nicht aus als Schutz gegen Webcrawlern, die komplette Homepages runterladen. Dazu muss man nur die Starturl einer Homepage kennen, die ja kein Geheimnis ist und den Download beginnen. Der Webcrawler lädt dann alle Seiten inklusive der Verzeichnisstruktur in ein lokales Verzeichnis. Manche Programme erlauben auch den Download bestimmter Dateitypen wie JPEG oder AVI usw. Um Webcrawler fernzuhalten, benötigt man entweder entsprechend aufgebauten Code wo Seiten prüfen, ob man authentifiziert ist bzw. Berechtigung hat oder man konfiguriert das Webverzeichnis mit entsprechenden Berechtigungen bzw. setzt Sessions ein.

Schwachstellen:

- Sourcecode gibt Hinweise.
- Unterseiten und Dateien sind nicht geschützt bzw. von Suchmaschinen indexierbar.
- Webcrawler haben Zugriff.
- Verzeichnisinhalte auflisten möglich.

2.2.4.2 Beispiel 2 - Sourcefehler

Die Passwortabfrage kann auch serverseitig erfolgen. Bei serverseitigen Skriptsprachen sieht man nur das Ergebnis und nicht den Code dahinter. Genau so kann das Passwort in einer Datei gespeichert werden. Oft ist es nicht nötig, das Passwort selbst zu wissen, um an die Inhalte zu kommen. Gesetz dem Fall die aufgerufene Seite findet die Passwortdatei nicht, dann vergleicht die Passwortabfrage die Eingabe mit Nichts. Ist das Eingabefeld leer, so würde die Funktion zur Passwortabfrage true zurückgeben und den Zugriff gewähren. Der erste Schritt beim Testen, ob ein passwortgeschützter Zugang sicher ist, ist die Eingabe eines leeren Passworts.

Der Sourcecode einer Datei an sich ist möglicherweise korrekt, jedoch können Angreifer diesen nicht nur einsehen, sondern auch kopieren und eigene Dateien damit erstellen. In diesen lokalen Dateien kann der Inhalt dementsprechend geändert werden. Dies kann dazu benutzt werden um eigene Werte zurückzugeben. Weiters gibt es auf beinah jeder Seite mit Passwortzugang die Möglichkeit, sich ein Passwort an die eigene Emailadresse senden zu lassen. Professionell wird das Versenden von Emails mittels einem serverseitigen Skripts erledigt, jedoch sieht auch reines HTML diese Möglichkeit vor. Besonders in diesem Fall ist es ein Leichtes, die eingetragene Emailadresse einfach auf die eigene zu ändern, um sich das Passwort einfach zusenden zu lassen. Man sieht recht deutlich, je einfacher die verwendete Technik umso unsicherer das Ergebnis.

Formulare sind generell mit Vorsicht zu genießen. Zwar erlauben serverseitige Skripte die Auswertung des Formularinhalts am Server womit der Sourcecode dieses Vorgangs dem Benutzer verborgen bleibt, jedoch werden diese Formulardaten letztendlich auch irgendwie übermittelt. In HTML gibt es die Möglichkeit bei Eingabefeldern den Typ mit password zu definieren. Dadurch sieht man bei der Eingabe nur ********. Jeder HTML-Formular hat jedoch im Element

<form> das Attribut get oder post, welches die Übertragungsmethode definiert. Suchmaschinen verwendet meist das Attribut get, welches den Inhalt des Sucheingabefeldes in der Adressleiste anhängt. Dadurch sieht man den eingegebenen Text und kann die Ergebnisseiten bequem kopieren und einfügen, um immer zu der richtigen Seite zu gelangen. Wird jetzt im Formular ein Passwort eingegeben, so wird dieses ebenfalls in der Adressleiste angezeigt. In JSP könnte dies so aussehen: http://testseite1.htm?name=johndoe&passwort=geheim. Durch Verwenden des Attributes post vermeidet man dieses Problem.

Abbildung in dieser Leseprobe nicht enthalten

Listing 3: Beispielpasswortabfrage mittels JSP. Diese Datei wird von einem Formular in einer separaten HTML-Datei aufgerufen. Hat ein Angreifer diese Datei erst ein Mal in seinen Händen, nützt es auch nichts, dass dieser Code serverseitig ausgeführt wird.

Skripte können Eingabefeldinhalte auslesen. Diese Inhalte werden in Variablen gespeichert und übergeben. Selbst wenn man diese Variablen mit deren Inhalte in der Adressleiste des Browsers nicht sieht, kann man Variableninhalte in der Adressleiste anhängen bzw. ändern. Hat man jetzt in einem Skript programmiert, dass bei korrekter Eingabe des Benutzernamens und des Passworts die Variable authorisation auf true, also korrekt, gesetzt wird und man danach weitergeleitet wird, so können Angreifer einfach dies Variable inklusive des Wertes true in der Adresszeile anhängen und es wird dem Skript am Server übergeben. Die Eingaben an sich mögen zwar falsch sein, der Wert der Variable die dies entscheidet sagt aber aus, dass die Eingabe korrekt ist. Die Abhilfe ist recht simpel, man setzt einfach im Skript, das von der Formularseite aufgerufen wird, den Wert der Variable authorisation standardmäßig zu Beginn auf false. Wird jetzt von der Passworteingabeseite die Variable authorisation mit true übergeben, dann wird diese sofort beim Ausführen des Skripts auf false gesetzt, danach die Benutzereingaben überprüft und bei Korrektheit wieder auf true gesetzt. Der entscheidende Punkt ist jedoch, dass bei falscher Eingabe der Wert der Variable false bleibt und der Code danach, der die Seite dahinter aufruft, nicht ausgeführt wird.⁹

Abbildung in dieser Leseprobe nicht enthalten

Listing 4: PHP-Passwortabfrage. Die Codeinhalte bekommt der Benutzer nicht zu sehen, sondern sieht bei falscher Eingabe ein Formular mit zwei Eingabefeldern oder eben den Text „Korrekte Eingabe!“. Dieses Skript funktioniert aber nur bei aktiviertem register_globals.

Schwachstellen:

- Leeres Passwort funktioniert.
- Sourcecode kann lokal geändert werden.
- Formularmethode get.
- Übergebene Variablen veränderbar.

2.2.4.3 Beispiel 3 - Sessions

Um zu verhindern, dass Benutzer einfach Unterseiten direkt aufrufen, kann man Sessions verwenden. Jeder authentifizierte Benutzer baut eine eigene Session auf und in dieser wird festgehalten, dass sich der Benutzer authentifiziert hat. Sessionvariablen können aber ebenfalls über Benutzereingaben modifiziert werden. Das kann wiederum ausgenutzt werden, um die Sessionvariable einfach auf true zu setzen. Eine Lösung des Problems ist register_globals abschalten, wodurch globale Variablen nicht mehr gelten. Dann funktioniert das Skript aber an sich nicht mehr. Deswegen speichert man die Sessiondaten in Arrays.

Abbildung in dieser Leseprobe nicht enthalten

Listing 5: PHP-Passwortabfrage. Funktioniert mit abgeschaltetem register_globals.

2.2.4.4 Beispiel 4 - Skriptinjections & Referer & Cookies

Referer dienen dazu, einem Server mitzuteilen, woher der Besucher kommt. Um zu verhindern, dass Besucher einfach die Seiten unter der Passwortabfrage aufrufen, kann man prüfen, ob diese Besucher auch vorher die Seite mit der Passwortabfrage aufgerufen haben und von dieser weitergeleitet wurden. Nur wenn Besucher von der Seite mit der Passwortabfrage kommen wird ihnen der Inhalt im Browser angezeigt. Dadurch nützt einem Angreifer auch nicht das Wissen über die Verzeichnisstruktur bzw. den Dateinamen der Unterseiten, da er diese nicht direkt aufrufen kann. Benutzer, die ihren Browser konfiguriert haben Refererinformationen zu unterdrücken, können dann selbst bei richtiger Passworteingabe keinerlei Seiten betrachten. Der Browser sendet somit die Information an den Webserver. Was der Browser nun tatsächlich sendet, kann manipuliert werden. Die Refererabfrage kann mit Skriptsprachen realisiert werden. Serverseitige Scripts geben hier einen gewissen Schutz, aber auch diese können nur Information verarbeiten, die diese bekommen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Paketanalyse beim Aufrufen eines Links mit Referer.

Abgesehen von Informationen wie Browser, Betriebssystem und Sprache sieht man auch die Quelladresse, von der der Benutzer gekommen ist.

Eine einfache Version zur Refererabfrage ist mittels JavaScript. Dazu verwendet man die Funktion document.referer. In jedem Browser kann man JavaScript direkt in der Adressleiste ausführen. Um beispielsweise eine Textbox mit Hallo angezeigt zu bekommen, gibt man in die Adressleiste javascript:alert('Hallo'); ein. Eine solche Änderung von Seiteninhalten oder Formularinhalten nennt man JavaScriptinjections. Dadurch kann man ebenfalls die Refererinformation ändern, wodurch der betreffende Server getäuscht werden kann.¹⁰

Ähnlich wie bei Referern verhält es sich mit Cookies. Ein Cookie speichert Informationen am Client, die der Server bei jedem Besuch der Webserverseite oder bei Aufruf einer entsprechenden Funktion wieder ausliest. Mal abgesehen davon, dass man mit Cookies Sessions simulieren kann, wird dies vor allem verwendet, um Benutzern das wiederholte Einloggen auf einer Webseite zu ersparen. Für gewöhnlich werden sensible Cookieinhalte mittels eines Algorithmus verschlüsselt. Falls das aber nicht der Fall ist, kann man Inhalte mittels JavaScript in der Adressleiste anzeigen lassen. Der Befehl dazu lautet javascript:alert(document.cookie);. Falls im Cookie der Seite die Benutzerautorisation gespeichert wird, kann man den Inhalt des Cookies ebenfalls mit JavaScript verändern. Angenommen das Cookie der Seite zeigt den Namen einer Variable mit Benutzerautorisation oder Ähnlichem an und dem dazu gehörenden Wert false, oder 0 oder no oder was auch immer. Ist dies der Fall so kann man den Wert dieses Cookieeintrags mittels javascript:void(document.cookie="Autorisationsvariable=Variblenwert"); auf positiv setzen und gilt für die Seite als bereits früher autorisiert und man kann jede Unterseite aufrufen. Passworteingaben sollten ohnehin niemals in Cookies gespeichert werden.¹¹

Eine weitere Möglichkeit der Injections betreffen Dateiuploads. Es gibt Seiten, die es erlauben Dateien hoch zu laden. Oftmals findet man dies in Foren, wo es erlaubt ist, Bilder hoch zu laden. Das kann genutzt werden, um eigene Skriptdateien hoch zu laden und diese dann auszuführen. Im Skript kann enthalten sein, dass der Inhalt des Verzeichnisses in dem sich die Datei befindet ausgegeben oder verändert wird. Das kann durch die korrekte Konfiguration am Webserver verhindert werden.

Abbildung in dieser Leseprobe nicht enthalten

Listing 6: Beispiel auf einem Unixsystem mit Apachewebserver. Die Konfiguration verbietet PHP-Dateien im Verzeichnis img der virtuellen Seite fh in der Datei .htaccess.

Eine weitere Möglichkeit der Injection ist die direkte Eingabe von Code in das Eingabefeld. Dazu muss man die verwendete Skriptsprache herausfinden und deren Syntax kennen. Am Beispiel von PHP bedeutet das, dass der Inhalt des Textfeldes von PHP ausgelesen und verarbeitet wird. Wird beispielsweise der eingegebene Text mittels des Befehls echo() ausgegeben, kann man danach diesen Text auf einer sonst leeren Seite im Browser sehen. Hängt man nun andere Befehle an diesen an, so werden diese ebenfalls ausgeführt. Dies kann man erreichen, indem man hinter die eigentliche Eingabe im Textfeld die eigenen Befehle anhängt. Gibt man ein PHP-Textfeld zusätzlich zur Eingabe die Server Side Include - Eingabe <!--#exec cmd="ls" --> ein, so werden alle Dateien des aktuellen Serververzeichnisses ausgegeben, vorausgesetzt, der Webserver läuft auf einem Unixsystem.¹²

2.2.4.5 Beispiel 5 - Dateien außerhalb des Webverzeichnisses / Includes

Um der Gefahr, dass Webserververzeichnisinhalte einsehbar sind, Passwortdateien bzw. Sourcecode in Webserververzeichnissen ausgelesen werden können usw. vorzubeugen, empfiehlt es sich, diese sensiblen Dateien erst gar nicht in irgendeinem Verzeichnis abzulegen, das Teil der Webserververzeichnisstruktur ist. Dadurch schaltet man einige Risiken aus und kann die Benutzerautorisation entsprechend flexibler gestalten. Auf Linux kann man mittels der Datei .htaccess ohnehin einfach konfigurieren, welche Benutzer auf welche Ressourcen zugreifen dürfen. Gleiches gilt für Windows, wenn man dadurch auch redundante Benutzer im Active Directory hat. Aus diesem Grund werden Benutzerdaten oftmals in Datenbanken gespeichert. Die PHP-Funktion include erlaubt die Verwendung von Include-dateien. Dazu muss jedoch in der Konfigurationsdatei php.ini ein entsprechendes Includeverzeichnis unter den include_path - Einstellungen eingetragen werden. Auf dieses Verzeichnis bzw. den Dateien darin kann man dann in PHP direkt verweisen, ohne dass deren Inhalte für Webbenutzer einsehbar sind. In einer Include - Datei mit der Dateinamenserweiterung inc werden die Daten zur Verbindungsaufnahme mit der Datenbank eingetragen. Der PHP-Code beinhaltet dann nur noch den Befehl zum Einbinden der Include - Datei und den Aufruf der Datenbank.¹³

Abbildung in dieser Leseprobe nicht enthalten

Listing 7: PHP-Datei die Include verwendet.

2.2.4.6 Beispiel 6 - SQL-Injections

Benutzerdaten von Webseiten werden meist in Datenbanken gespeichert. Selbst Windows speichert seit der Version 2003 (XP) in dessen Active Directory Datenbank, lokale Passworte ausgenommen, die wie bei Linux in einer entsprechenden Datei gespeichert werden (Windows: sam, Linux: passwd). Fürs Protokoll: Genau genommen sind Datenbanken auch nur Dateien und in Unixsystemen ist ohnehin alles eine Datei. Die Autorisation erfolgt mit einer Skriptsprache in der in einem If-Block abgefragt wird, ob die Eingaben aus den Eingabefeldern auch den Daten in der Datenbank entsprechen. Für die Zugriffe auf die Datenbank, die bei Registrierung ein Schreiben und bei der Abfrage ein Lesen in der Datenbank vornehmen, verwendet man SQL-Skript. Der SQL-Teil der Abfrage sieht in jeder Skriptsprache gleich aus, mit Ausnahme der Variablennamen.

Abbildung in dieser Leseprobe nicht enthalten

Listing 8: Einfaches SQL-Skript.

Das Beispiel in Listing 8 fragt den Benutzername und Passwort aus der Tabelle Benutzer ab und vergleicht anschließend mit den Variablen strBenutzername und strPasswort. Den Variablen müssen vorher die Werte der Benutzereingaben zugewiesen werden. Gibt die Abfrage nichts zurück, dann gilt der Benutzer als nicht berechtigt. Wird in das Benutzer- und Passworteingabefeld einfach ' or '=' eingeben, so entsteht die SQL-Abfrage „select Benutzername from Benutzer where Benutzername = ' 'or '=' ' and Passwort = ' 'or '='“, womit ein Anführungszeichen mit einem Anführungszeichen verglichen wird und somit true zurückgegeben wird.¹⁴

SQL-Injections nutzen die Möglichkeit aus, eigenen SQL-Code in das Eingabefeld einzugeben. Dieser wird dann anstatt des korrekten Sourcecodes ausgeführt. Die einfachste Variante wäre einfach, an eine bestehende Abfrage einen eigenen Teil anzufügen. Nimmt man mittels SQL-Skript eine Suche in einer Datenbank vor und sucht nach dem übergebenen Artikel, so ergibt sich folgendes SQL-Skript: „select artikelname from artikeltabelle where artikelname = 'gesuchter Artikel'“. Hängt man an die Eingabe auch den Befehl '; drop table *; an, so wird nach der Suche jede Tabelle der aktuellen Datenbank gelöscht. Es gibt eine Reihe von einfachen Injections, um Daten zu sehen, die nicht dafür vorgesehen waren. Mittels des SQL-Befehls union select ist es beispielsweise möglich, mehrere select - Abfragen vorzunehmen und somit andere Tabellenspalten oder andere Tabellen einzusehen. Selbst inkorrekte Eingaben oder die Eingabe von Errormessages können nützliche Informationen wie die Tabellenstruktur zurückgeben. Eine Methode bei Errormessages bei ASP ist having, das Teil des select - Befehls ist. Gibt ein

Angreifer in das Benutzereingabefeld ' having 1=1-- ein, so produziert er die Fehlermeldung mit der Angabe über die Spalte mit den Benutzern.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: In diesem Fall zeigt die Fehlermeldung den Namen der Spalte users.id.

Der nächste Schritt bei dieser Vorgehensweise ist die Eingabe von group by users.id having 1=1-- usw. Dadurch kann man die Tabellenspalten herausfinden. Weiters kann man die Datentypen der Tabellenspalten feststellen, um auch zu wissen, welche Eingaben in der Tabelle erlaubt sind.

Eine Abhilfe gegen SQL-Injections sind reguläre Ausdrücke. Damit kann man prüfen, welche Zeichen in einer Variable enthalten sind bzw. kann man definieren, dass eine Eingabe nur bestimmte Zeichen enthalten darf. Der reguläre Ausdruck [0-9a-zA-Z] beinhaltet Ziffern, Klein- und Großbuchstaben. Enthält eine Benutzereingaben nun Sonderzeichen wie für einen Zeilenumbruch (\n) oder Anführungszeichen, so wird der nachfolgende Code nicht ausgeführt und die Benutzereingabe verworfen.

Abbildung in dieser Leseprobe nicht enthalten

Listing 9: PHP-Formularauswertung bei dem die Länge der Eingabe im Benutzerfeld mit dem Namen name, der Inhalt des Emailfeldes und der Inhalt des URL-Feldes geprüft wird. Sind alle drei Voraussetzungen erfüllt wird eine positive Nachricht ausgegeben.

Weiters kann man im HTML-Teil in den Eigenschaften der Eingabefelder festlegen, welche maximale Länge die Eingabe haben darf. Dies kann die Eingabe von manchen SQL-Befehlen unmöglich machen, wenn man auch bedenken muss, dass SQL-Injections auch über die Adressleiste funktionieren können. Die nahe liegende Lösung ist eine programmiertechnische. Man parst einfach Eingaben auf SQL- Befehle und verwirft die Eingabe bei Auffinden eines solchen. Dazu implementiert man eine Funktion, die Benutzereingaben auf select, insert, update, delete und drop durchsucht, um größeren Schaden zu vermeiden. Das Parsen des zusammengesetzten SQL-Befehls selbst wäre zu wenig, da man zwar verhindern kann, dass beispielsweise eine select - Abfrage zusätzliche Attribute beinhaltet, man jedoch nicht verhindern kann, dass die select - Werte korrekt sind.

Abbildung in dieser Leseprobe nicht enthalten

Listing 10: VB-Skript zur Prüfung der Eingabe auf Schlüsselworte.

Eine weitere Methode zum Verhindern von SQL-Injections ist, Benutzereingaben nicht direkt in die SQL-Abfrage einzubauen, sondern diese in Variablen zwischenzuspeichern. In ASP.NET erfolgt dann die Übergabe über die ParametersCollection der Klasse OleDbCommand bzw. SqlCommand. Damit wird die benutzte Variable mit deren Wert übergeben.¹⁵

Abbildung in dieser Leseprobe nicht enthalten

Listing 11: Beispiel in ASP.NET wobei Benutzername (Eingabefeldname tb_us) und Passwort (Eingabefeldname tb_pw) in den Variablen mit @ beginnend gespeichert werden. Die verwendete Datenbank ist hier Microsoft Access.

Abgesehen von SQL-Injections muss die Datenbank selbst gegen unbefugten Zugriff geschützt werden. Was nützt ein sicherer Code, wenn man sich direkt mit der Datenbank verbinden kann oder Rootrechte auf der Datenbank erhält. Auch Datenbanken haben ein eigenes Berechtigungssystem in dem definiert ist, wer auf welche Ressourcen Zugriff hat. Meist werden Datenbanken auch auf eigenen Servern betrieben, was den zusätzlichen Sicherheitseffekt bringt, dass man nur Verbindungen zum Datenbankserver vom Webserver aus zulässt und somit einerseits der Datenbankserver nicht direkt im Internet steht und weiters das direkte Anmelden an der Datenbank selbst durch Umgehung der Webserverskripte nicht möglich ist. Ebenso sollte man auf die Sicherheit bei Datenbankadministrationstools achten, da diese ein weiteres Interface zur Datenbank darstellen, das ebenfalls ein entsprechendes Berechtigungssystem enthalten muss. Ist man erstmal direkt mit der Datenbank verbunden und hat die entsprechenden Berechtigungen erlangt, so kann man alle Daten einsehen bzw. manipulieren.

[...]

---

¹ Eine Servletengine dient zum Ausführen von Programmcode. Im Fall von Tomcat zum Ausführen von Javacode bzw. von Java Server Pages.

² Vgl. Cert, Zugriff am 27.3.2006

³ SANS, Zugriff am 27.3.2006

⁴ Vgl. Krüger (2002), S. 887

⁵ Vgl. Koch (2001), S. 407

⁶ Vgl. Arbeiterkammer, Zugriff am 21.3.2006 bzw. Bundesministerium für Inneres, Zugriff am 21.3.2006

⁷ In der englischen Version von Windows.

⁸ Vgl. Lessig (2003), S. 53

⁹ Vgl. Yank (2003), S. 200

¹⁰ Vgl. HTMLGoodies, Zugriff am 15.4.2006

¹¹ Vgl. HTMLGoodies, Zugriff am 15.4.2006

¹² Vgl. Thefreedictionary, Zugriff am 13.4.2006

¹³ Vgl. Yank (2003), S. 160

¹⁴ Vgl. Microsoft, MSDN, Zugriff am 31.3.2006

¹⁵ Lorenz (2003), S. 538