Leseprobe
Fachhochschulstudiengänge Burgenland GmbH
Thomas A. Edison Straße 2
A-7000 Eisenstadt
Studiengang ,,Information and Communication Solutions"
Information and Communication Solutions
Diplomarbeit
Sicherheitsanalyse Webserver
Reinhard Hofer
betreut durch
DI Rainer Schmidt
Eisenstadt, Sommersemester 2006
Sicherheitsanalyse Webserver
Reinhard Hofer
1
1 Ehrenwörtliche Erklärung
Ich habe diese Diplomarbeit selbstständig verfasst, alle meine Quellen und
Hilfsmittel angegeben, keine unerlaubten Hilfen eingesetzt und die Arbeit bisher in
keiner Form als Prüfungsarbeit vorgelegt.
Mannersdorf, 30.5.2006
Reinhard Hofer
Sicherheitsanalyse Webserver
Reinhard Hofer
2
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
Eisenstadt,
30.05.2006
Sicherheitsanalyse Webserver
Reinhard Hofer
3
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.
Sicherheitsanalyse Webserver
Reinhard Hofer
4
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.
Sicherheitsanalyse Webserver
Reinhard Hofer
5
Inhaltsverzeichnis
Seite
1 Einleitung ...1
1.1 Problemstellung...1
1.2 Zielsetzung ...2
2 Quellcode ...4
2.1 Fehler
und
Risiken ...4
2.2 Passwortgeschützter Zugang ...6
2.2.1 HTML und clientseitige Skripte...6
2.2.2 Serverseitige Skripte ...7
2.2.3 Referer
Header und Cookies ...8
2.2.4 Codebeispiele... 10
2.2.4.1 Beispiel 1 - Sourcecodeanalyse ... 10
2.2.4.2 Beispiel 2 Sourcefehler ... 13
2.2.4.3 Beispiel 3 - Sessions ... 16
2.2.4.4 Beispiel 4 Skriptinjections & Referer & Cookies... 16
2.2.4.5 Beispiel 5 Dateien außerhalb des Webverzeichnisses / Includes ... 19
2.2.4.6 Beispiel 6 SQL-Injections ... 20
2.3 Angriffsmethoden ... 26
2.3.1 Spoofing ... 26
2.3.1.1 Adress Resolution Protocol-Spoofing ... 27
2.3.1.2 Domain Naming Service-Spoofing ... 30
2.3.1.3 IP-Spoofing... 32
2.3.1.4 Route-Spoofing ... 35
2.3.2 Denial of Service ... 36
2.3.2.1 Flooding ... 36
2.3.2.2 Intern Control Message Protocol - Angriffe... 37
2.3.3 Scanning... 38
2.3.3.1 Portscanning ... 38
2.3.3.2 Sniffing... 39
2.3.4 Cracking ... 40
2.3.5 Phishing... 42
3 Internet
Information Server... 45
3.1 Risiken ... 45
3.2 Standardeinstellungen und Konfiguration... 46
3.2.1 Änderungen an den Standardeinstellungen ... 46
3.2.2 Sicherheitsmaßnahmen ... 48
3.2.2.1 Sicherheitsrichtlinie... 48
3.2.2.2 Logging ... 49
3.2.2.3 Checkliste ... 52
3.2.3 Verbesserungen
gegenüber IIS 5... 54
3.3 Security Analyse ... 56
3.4 Hotfixes ... 59
3.4.1 Aktuelle
Sicherheitslöcher... 59
3.4.1.1 Kompressionsfehler verursacht Zugriffsverletzungen... 59
3.4.1.2 Kennwortänderungsseiten ... 60
Sicherheitsanalyse Webserver
Reinhard Hofer
6
3.4.1.3 WebDAV-XML Message Handler ... 60
3.4.1.4 FTP-Resume-Feature ... 61
3.4.1.5 ASP.NET und Set-Cookie ... 61
3.4.2 Herstellerverhalten ... 62
3.5
Systeme die auf den Webserver einwirken... 64
3.5.1 Betriebssystem... 64
3.5.2 Intrusion
Detection System ... 66
3.5.3 Demilitarized Zone... 67
3.5.4 Firewall... 69
3.5.5 Viruskiller... 71
4 Apache ... 75
4.1 Risiken ... 75
4.2 Standardeinstellungen und Konfiguration... 76
4.2.1 Änderungen an den Standardeinstellungen ... 76
4.2.2 Sicherheitsmaßnahmen ... 77
4.2.2.1 Logging ... 77
4.2.2.2 Checkliste ... 79
4.2.3 Verbesserungen
gegenüber Apache 1.3 bzw. 2.0 ... 81
4.2.3.1 Verbesserungen von Apache 2.0 gegenüber 1.3... 81
4.2.3.2 Verbesserungen von Apache 2.2 gegenüber 2.0... 82
4.3 Securityanalyse ... 83
4.4 Updates... 85
4.4.1 Aktuelle
Sicherheitslöcher... 85
4.4.1.1 Referer Cross-Site Scripting ... 85
4.4.1.2 Behobene Sicherheitslöcher in Version 2.0.58 ... 85
4.4.1.3 Behobene Sicherheitslöcher in Version 2.0.55 ... 86
4.4.2 Herstellerverhalten ... 86
4.5
Systeme die auf den Webserver einwirken... 88
4.5.1 Betriebssystem... 88
4.5.2 Intrusion
Detection System ... 89
4.5.3 Demilitarized Zone... 89
4.5.4 Firewall... 89
4.5.5 Viruskiller... 89
5 Ergebnisse
und
Schlussfolgerungen... 90
6 Zusammenfassung... 96
7 Verzeichnisse ... 98
7.1 Literaturverzeichnis... 98
7.2 Abbildungsverzeichnis ... 101
7.3 Tabellenverzeichnis... 102
7.4 Listingverzeichnis ... 102
7.5 Formelzeichen,
Indizes und Abkürzungen ... 103
Sicherheitsanalyse Webserver
Reinhard Hofer
1
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
Sicherheitsanalyse Webserver
Reinhard Hofer
2
bestimmten Bereich sind. Tomcat beispielsweise ist weniger ein Webserver,
sondern eine Servletengine
1
. 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
1
Eine Servletengine dient zum Ausführen von Programmcode. Im Fall von Tomcat zum Ausführen
von Javacode bzw. von Java Server Pages.
Sicherheitsanalyse Webserver
Reinhard Hofer
3
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.
Sicherheitsanalyse Webserver
Reinhard Hofer
4
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.
2
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."
3
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
2
Vgl. Cert, Zugriff am 27.3.2006
3
SANS, Zugriff am 27.3.2006
Sicherheitsanalyse Webserver
Reinhard Hofer
5
ö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
Sicherheitsanalyse Webserver
Reinhard Hofer
6
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.
4
Die Konfigurationsoptionen der gängigen Browser erlauben das
Deaktivieren von Java.
4
Vgl. Krüger (2002), S. 887
Sicherheitsanalyse Webserver
Reinhard Hofer
7
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.
5
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
5
Vgl. Koch (2001), S. 407
Sicherheitsanalyse Webserver
Reinhard Hofer
8
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
Sicherheitsanalyse Webserver
Reinhard Hofer
9
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.
6
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.
7
Abbildung 2.1: Beispielcookie von www.amazon.de
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
6
Vgl. Arbeiterkammer, Zugriff am 21.3.2006 bzw. Bundesministerium für Inneres, Zugriff am
21.3.2006
7
In der englischen Version von Windows.
Sicherheitsanalyse Webserver
Reinhard Hofer
10
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.
8
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.1Beispiel 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 HTML-
File. Im folgenden Beispiel gibt es nur einen Benutzer und Passwort, da die
Prozedur für jeden weiteren Benutzer gleich ist.
<html><title>
Passwortzugang</title><head>
<script language="
JavaScript
" src="
passwort.js
" text="
javascript/text
">
</script>
</head>
8
Vgl. Lessig (2003), S. 53
Sicherheitsanalyse Webserver
Reinhard Hofer
11
<button type=
passwort
onclick=
passwort()
>Passworteingabe
</html>
Listing 1: HTML-Seite mit Aufruf der JavaScriptdatei.
function
passwort()
{
check
= prompt("
Bitte Passwort eingeben
","");
if
(
check
== "
geheim
")
{
ergebnis =
open
("
seite1.htm
");
}
else
alert
("
falsches Passwort!
");
}
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
Sicherheitsanalyse Webserver
Reinhard Hofer
12
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:
Sicherheitsanalyse Webserver
Reinhard Hofer
13
Sourcecode gibt Hinweise.
Unterseiten und Dateien sind nicht geschützt bzw. von Suchmaschinen
indexierbar.
Webcrawler haben Zugriff.
Verzeichnisinhalte auflisten
möglich.
2.2.4.2Beispiel 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
Sicherheitsanalyse Webserver
Reinhard Hofer
14
<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.
<!DOCTYPE html PUBLIC "">
<html><head></head><body>
<%
String name=request.getParameter("name");
String passwort=request.getParameter("passwort");
if(name.equals("johndoe"))
{
if(passwort.equals("geheim"))
out.println("<a href=seite1.htm>Hier kommen Sie weiter!</a>");
}
else
{
out.println("falsche Eingabe");
}
%>
</body></html>
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
Sicherheitsanalyse Webserver
Reinhard Hofer
15
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.
9
<?php
$authorisation = false;
if ($benutzername == 'johndoe' and $passwort == 'geheim')
&authorisation = true;
?>
<? php if (!$authorisation):?>
<form action="<?php_self?> method="post">
Benutzername: <input type="text" name=benutzername">Passwort: <input
type="password" name="passwort"> <input type="submit"></form>
<?php else:?>
Korrekte Eingabe!
<?php endif;?>
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
.
9
Vgl. Yank (2003), S. 200
Sicherheitsanalyse Webserver
Reinhard Hofer
16
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.
<?php session_start();
if ($_POST['benutzername'] == 'johndoe' and $_POST['passwort' ==
'geheim')
$_SESSION['authorisation'] = true;
?>
<?php if (!$_SESSION['authorisation']):?>
<form action="<?php_self?> method="post">
Benutzername: <input type="text" name=benutzername">Passwort: <input
type="password" name="passwort"> <input type="submit"></form>
<?php else:?>
Korrekte Eingabe!
<?php endif;?>
Listing 5: PHP-Passwortabfrage. Funktioniert mit abgeschaltetem
register_globals
.
2.2.4.4Beispiel 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
Ende der Leseprobe aus 112 Seiten
- Arbeit zitieren
- DI (fh) Reinhard Hofer (Autor:in), 2006, Sicherheitsanalyse Webserver, München, GRIN Verlag, https://www.grin.com/document/186191
Ähnliche Arbeiten
Kostenlos Autor werden
✕
Leseprobe aus
112
Seiten
Kommentare