90
Masterarbeit Konzept zur Absicherung einer J2EE-Anwendung gegen SQL-Injektion am Beispiel einer Web-Anwendung Zur Erlangung des akademischen Grades eines Master of Science - Media Processing and Interactive Services - Fakultät Informatik Referent: Prof. Dr. Oliver Braun Korreferent: Dipl.-Inf.(FH) René Brothuhn Eingereicht von: Martin Schüler Matr.-Nr. 260257 Dorfstraße 28 06577 Gorsleben Schmalkalden, den 30.04.2012

Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

  • Upload
    padsfhs

  • View
    78

  • Download
    3

Embed Size (px)

Citation preview

Page 1: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

Masterarbeit

Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

Zur Erlangung des akademischen Grades einesMaster of Science- Media Processing and Interactive Services -

Fakultät InformatikReferent: Prof. Dr. Oliver BraunKorreferent: Dipl.-Inf.(FH) René Brothuhn

Eingereicht von:Martin SchülerMatr.-Nr. 260257Dorfstraße 2806577 Gorsleben

Schmalkalden, den 30.04.2012

Page 2: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

Danksagung

An dieser Stelle möchte ich mich bei meinen Eltern Silvia und Dieter Schüler so-wie meiner Schwester Anika Schüler und meiner Lebenspartnerin Mandy Schrickelbedanken. Sie haben mich während der ganzen Zeit unterstützt, mir den Rücken frei-gehalten und mich selbst bei Rückschlägen wieder aufgebaut. Ein besonderer Dankgilt hierbei meinen Eltern, ohne die dieses Studium nicht möglich gewesen wäre.

Des Weiteren möchte ich mich bei der Firma Inverso GmbH bedanken, welche eserst ermöglichte, dieses Thema zu bearbeiten, und mir dabei über den gesamtenZeitraum unterstützend zur Seite stand. Speziell gilt dabei mein Dank Markus Iwig,Nadine Schuchhardt und Enrico Horn.

Ein herzlicher Dank gilt zudem Herrn Professor Oliver Braun, welcher sofort bereitwar, sich als Betreuer dieser Arbeit zur Verfügung zu stellen, und mich währenddes gesamten Zeitraums sehr gut unterstützt hat. Zum Schluss möchte ich mich beiRené Brothuhn bedanken, der sofort bereit war, mich als Korreferent zu betreuen.

Page 3: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

Inhaltsverzeichnis

1 Einleitung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Grundlagen 52.1 Das Unternehmen Inverso GmbH . . . . . . . . . . . . . . . . . . . . 52.2 Die Web-Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Zweck der Web-Anwendung . . . . . . . . . . . . . . . . . . . 62.2.2 Architektur der Web-Anwendung . . . . . . . . . . . . . . . . 7

2.3 OpenCMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Structured Query Language . . . . . . . . . . . . . . . . . . . . . . . 102.5 Java Database Connectivity . . . . . . . . . . . . . . . . . . . . . . . 102.6 Java Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.7 Rational Application Developer . . . . . . . . . . . . . . . . . . . . . 102.8 ACID-Prinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.9 Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Die Informationssicherheit 123.1 Definition und Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Kern-Schutzziele der Informationssicherheit . . . . . . . . . . . . . . . 143.3 Sicherheitskonzept für eine Softwareanwendung . . . . . . . . . . . . 163.4 Ermittlung von Sicherheitslücken durch Penetrationstest . . . . . . . 183.5 Sicherheitslücken in Web-Anwendungen . . . . . . . . . . . . . . . . . 18

3.5.1 SQL-Injektion . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.5.2 Cross-Site Scripting . . . . . . . . . . . . . . . . . . . . . . . . 23

Martin SchülerII

Page 4: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

Inhaltsverzeichnis Fachhochschule Schmalkalden 2012

4 Aktueller Stand der Anwendung 244.1 Vorhandene Sicherheitsmechanismen . . . . . . . . . . . . . . . . . . 24

4.1.1 Request-Validator . . . . . . . . . . . . . . . . . . . . . . . . . 244.1.2 Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . 254.1.3 Autorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Bedrohungsszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.1 SQL-Injektion . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.2 Cross-Site Scripting . . . . . . . . . . . . . . . . . . . . . . . . 294.2.3 Analyse der Ergebnisse . . . . . . . . . . . . . . . . . . . . . . 30

5 Konzepte zur Absicherung 325.1 Web Application Firewall . . . . . . . . . . . . . . . . . . . . . . . . 325.2 Object-Relational Mapping-Tools . . . . . . . . . . . . . . . . . . . . 335.3 Prepared Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.4 Neuentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.5 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6 Das OR-Mapper Tool Hibernate 396.1 Objektzustände in Hibernate . . . . . . . . . . . . . . . . . . . . . . . 396.2 Mapping-Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.2.1 Mapping mit XML-Dokumenten . . . . . . . . . . . . . . . . . 416.2.2 Mapping mit Annotations . . . . . . . . . . . . . . . . . . . . 42

6.3 Datenbankabfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.3.1 Hibernate Query Language . . . . . . . . . . . . . . . . . . . . 446.3.2 Abfragen mit Criteria . . . . . . . . . . . . . . . . . . . . . . . 44

6.4 Cache-Methoden in Hibernate . . . . . . . . . . . . . . . . . . . . . . 456.4.1 First-Level-Cache . . . . . . . . . . . . . . . . . . . . . . . . . 456.4.2 Second-Level-Cache . . . . . . . . . . . . . . . . . . . . . . . . 46

6.5 Connection-Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7 Prototypische Umsetzung 487.1 Umsetzung mit Hibernate . . . . . . . . . . . . . . . . . . . . . . . . 48

7.1.1 Konfiguration von Hibernate . . . . . . . . . . . . . . . . . . . 487.1.2 Datenbankmapping mit Annotations . . . . . . . . . . . . . . 517.1.3 Änderung des bestehenden Java-Codes . . . . . . . . . . . . . 52

7.2 Einsatz von Prepared Statements . . . . . . . . . . . . . . . . . . . . 587.2.1 NamedParameterStatement-Klasse . . . . . . . . . . . . . . . 597.2.2 Setzen von Werten . . . . . . . . . . . . . . . . . . . . . . . . 62

Martin SchülerIII

Page 5: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

Inhaltsverzeichnis Fachhochschule Schmalkalden 2012

7.2.3 Änderungen bei Select-Anweisungen . . . . . . . . . . . . . . 627.2.4 Änderungen bei Update-Befehlen . . . . . . . . . . . . . . . . 65

7.3 Bewertung der beiden Varianten . . . . . . . . . . . . . . . . . . . . . 67

8 Test der prototypischen Umsetzung 698.1 Sicherheitstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

8.1.1 SQL-Injektion . . . . . . . . . . . . . . . . . . . . . . . . . . . 698.1.2 Cross-Site Scripting . . . . . . . . . . . . . . . . . . . . . . . . 718.1.3 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

8.2 Automatisierter Test mit Selenium . . . . . . . . . . . . . . . . . . . 72

9 Abschließende Betrachtungen 759.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759.2 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Literaturverzeichnis 78

Eidesstattliche Erklärung 85

Martin SchülerIV

Page 6: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

1 Einleitung

1.1 Motivation

Diese Masterarbeit entsteht in Zusammenarbeit mit der Firma Inverso GmbH, des-sen Sitz sich in Ilmenau befindet. Dieses stellt individuelle IT-Lösungen für verschie-dene Finanzdienstleister her. Die einzelnen Anwendungen werden auf die spezifischenBedürfnisse der jeweiligen Kunden abgestimmt. Eines der wichtigsten Anforderun-gen ist dabei die Sicherheit der Programme und vor allem der Schutz von sensiblenKundendaten.

Diese Prämisse ist generell im laufe der geschichtlichen Entwicklung des Internetsimmer wichtiger geworden. Durch die zunehmende Digitalisierung, welche vor allemdurch die stärkere Vernetzung von IT-Systemen, sowie die immer leistungsfähige-ren Netze gefördert wird, hat das Internet sowohl im privaten Haushalten als auchfür Unternehmen eine zentrale Rolle eingenommen. So werden immer mehr Ge-schäftsprozesse als Web-Anwendung in das Internet verlagert, welche längst überdie reine Suche von Informationen hinausgehen. So können Beispielsweise Verträ-ge über das Internet abgeschlossen, Kunden verwaltet oder Überweisungen getätigtwerden.

Dieser Trend der Digitalisierung wird auch in Zukunft weiter anhalten, da durchden ständigen und immer stärkeren Wandel der Technologien, neue Funktionen undDienste entstehen. Dies wiederum führt schon heute zu einer starken Abhängig-keit von diesem Medien. Wie stark diese ist, wird jedoch erst bei einem Ausfall desjeweiligen Systems bemerkt. Im privaten Umfeld ist der daraus resultierende Scha-den in den meisten Fällen verschwindend gering. Dagegen kann der Ausfall einesSystems für ein Unternehmen einen finanziellen Verlust darstellen, da zum BeispielMitarbeiter ihre Arbeit nicht verrichten können.

Neben den Schutz der IT-Systeme vor Ausfällen, spielt auch der Schutz der ver-arbeiten Informationen eine wichtige Rolle. Denn die zunehmende Digitalisierungbringt nicht nur Konsumenten zum Vorschein, welche eine Anwendung gemäß ih-

Martin Schüler Seite 1 von 85

Page 7: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

1. Einleitung Fachhochschule Schmalkalden 2012

res Zwecks verwendet, sondern auch solche Nutzer mit kriminellen Gedanken. Dieseversuchen durch Sicherheitslücken von IT-Systemen oder von Web-Anwendungen ansensible Daten zu gelangen. Gerade für Unternehmen kann dies zu einem enormenfinanziellen Schaden führen.

Wie wichtig das Thema IT-Sicherheit in unserer heutigen Gesellschaft ist, kann manauch an der Einrichtung des „Bundesamt für Sicherheit in der Informationstechnik“erkennen (kurz BSI). Diese stellt Methoden und Vorgehensweisen für zur Verfügung,welche ausschließlich den Schutz von IT-Systemen, sowie der dabei verwendetenInformationen dienen. Dabei hat sich die BSI als Ziel gesetzt, schnell und flexibelauf veränderte Rahmenbedingungen zu reagieren.

Aus diesen vorhergehenden Gründen, ist die Firma Inverso GmbH daran Interessiert,dass ihre Anwendung ein hohes Maß an Sicherheit haben und eventuelle Schwach-stellen so schnell wie möglich geschlossen werden.

1.2 Problemstellung

Bei der Erstellung des Konzeptes sowie bei der prototypischen Umsetzung muss einWeg gefunden werden, die Benutzerfreundlichkeit und die Sicherheit der Anwendunggleichermaßen zu erhöhen. Um dies zu gewährleisten muss im Rahmen dieser Ar-beit ein Konzept erstellt werden, dass die Eingabe aller Sonderzeichen zulässt undgleichzeitig SQL-Injektion verhindert. Derzeit werden Sonderzeichen konsequent her-ausgefiltert, was zu einer Steigerung der IT-Sicherheit führt, aber den Anwender beider Verwendung der Web-Anwendung stark einschränkt.

1.3 Zielsetzung

Ziel dieser Arbeit ist es, die Web-Anwendung auf Sicherheitslücken zu überprüfen.Dabei sollen verschiedene Bedrohungsszenarien, mit besonderem Schwerpunkt aufSQL-Injektion, entwickelt und entsprechend ihres Risikos analysiert werden. Hierfürist ein Konzept zu erstellen, welches die gefundenen Lücken schließt, aber gleichzeitigdie Benutzerfreundlichkeit der Anwendung erhöht. Anschließend soll dieses Konzeptprototypisch umgesetzt und erneut auf Schwachstellen anhand des Bedrohungssze-narios getestet werden.

Martin Schüler Seite 2 von 85

Page 8: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

1. Einleitung Fachhochschule Schmalkalden 2012

1.4 Abgrenzung

Diese Arbeit beschäftigt sich ausschließlich mit der Sicherheitslücke SQL-Injektion.Zusätzlich wird geprüft, ob innerhalb der Anwendung die Möglichkeit von XSS-Attacken besteht. Sind diese möglich, wird innerhalb dieser Arbeit jedoch kein Kon-zept zur Vermeidung von Cross-Site Scripting entwickelt.

Die prototypische Implementierung des erarbeiteten Konzeptes beschränkt sich indieser Arbeit auf den Abschnitt Kampagnen. Die restliche Umstellung geschiehtaußerhalb dieser Arbeit.

Aus Gründen des Datenschutzes werden alle Grafiken innerhalb dieser Arbeit anony-misiert dargestellt. Zudem werden in den dargestellten Listings alle Informationenzu Datenbanken, Tabellen und Benutzern verfremdet. Außerdem möchte das Unter-nehmen, dass aus Sicherheitsgründen nicht der Name der Web-Anwendung genanntwird.

1.5 Aufbau der Arbeit

In diesem Kapitel wird ein Überblick über den Aufbau dieser Masterarbeit gegeben,welche insgesamt in neun Kapitel gegliedert ist.

Im zweiten Abschnitt werden das Unternehmen Inverso GmbH sowie die Web-Anwendung vorgestellt. Des Weiteren werden benötigte Grundlagen der Arbeit kurzvorgestellt.

Der dritten Absatz beschäftigt sich mit dem Begriff der Informationssicherheit sowiedessen Bedeutung; dazu gehört die Vorstellung der drei Kernschutzziele. Anschlie-ßend wird erörtert, welche Schritte zu einem Sicherheitskonzept gehören. Im weiterenVerlauf werden Sicherheitslücken von Web-Anwendungen beschrieben.

Im Kapitel vier wird der Ist-Zustand der Web-Anwendung bezüglich der Sicherheitanalysiert. Zu Beginn wird geprüft, welche Maßnahmen zur Vermeidung von Si-cherheitslücken bereits in der Web-Anwendung vorhanden sind. Anschließend wirddie Web-Anwendung nach weiteren Schwachstellen untersucht, welche nachfolgendnäher analysiert werden sollen.

Im fünften Abschnitt werden verschiedene Konzepte vorgestellt, welche die Sicher-heit der Web-Anwendung erhöhen und somit die aus dem vierten Kapitel entdecktenSchwachstellen schließen sollen. Im Anschluss daran werden die einzelnen Varian-

Martin Schüler Seite 3 von 85

Page 9: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

1. Einleitung Fachhochschule Schmalkalden 2012

ten miteinander verglichen. Dadurch soll festgestellt werden, ob die Umstellung aufeinen Persistenz Leyer die bessere Variante ist.

Von dem Unternehmen wird die Umstellung auf Hibernate favorisiert. Aus diesemGrund wird in dem sechsten Abschnitt Hibernate als Persistenz Leyer näher vorge-stellt.

Im siebten Absatz wird die eigentliche prototypische Implementierung der optimalenVarianten näher erläutert.

In Kapitel acht wird die prototypische Implementierung bezüglich ihrer Sicherheitgetestet. Anschließend prüft ein automatisierter Test die Funktionsfähigkeit allerKampagnen.

Im letzten Abschnitt dieser Masterarbeit folgt eine abschließende Betrachtung, wel-che eine Zusammenfassung, eine Bewertung sowie einen Ausblick enthält.

Martin Schüler Seite 4 von 85

Page 10: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

2 Grundlagen

In diesem Abschnitt werden das Unternehmen Inverso GmbH sowie die verwendeteWeb-Anwendung näher vorgestellt. Anschließend werden die benötigten Grundlagender Arbeit dargestellt.

2.1 Das Unternehmen Inverso GmbH

Die Inverso GmbH wurde 1997 mit Hauptsitz in Ilmenau und einer Niederlassungin München von Professor Doktor Reinhold Schönfeld und Heinz Prokop gegrün-det. Im Jahr 2002 wurde mit dem Ausscheiden von Herrn Schönfeld der Hauptsitznach München verlegt. Eine weitere Geschäftsstelle wurde im Jahr 2001 in Jenaeröffnet. Insgesamt arbeiten zur Zeit etwa 79 Mitarbeiter in dem mittelständischenUnternehmen.

Das Unternehmen hat sich auf IT-Lösungen für Finanzdienstleister spezialisiert.Dabei liegen die Kernkompetenzen in der Entwicklung von maßgeschneiderten, in-novativen und professionellen Anwendungslösungen für Versicherungsunternehmen,welche auf die spezifischen Bedürfnisse der einzelnen Anwender abgestimmt werden.Zudem analysiert, unterstützt und berät Inverso seine Kunden beim Einsatz vonIT- und CRM-Anwendungen.

Bei Inverso hat das Wort „Innovation“ eine sehr große Bedeutung. So werden in-novative Lösungsansätze mit langjähriger Erfahrung, technischem Know-How undfachlichem Hintergrundwissen kombiniert, wodurch optimale Ergebnisse garantiertwerden. Dadurch ist es möglich, dass neue, hochwertige und individuelle Lösungenfür Finanzdienstleister entstehen. Das Ziel von Inverso ist es, dass seine Kundendurch den Einsatz der auf sie zugeschnittenen Software eine Spitzenposition imWettbewerb erlangen.

Seit der Gründung konnte sich Inverso GmbH amMarkt etablieren und wuchs stetig.Die Geschäftsführung besteht heute aus Diplom-Informatiker Roland Schachtschabel

Martin Schüler Seite 5 von 85

Page 11: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

2. Grundlagen Fachhochschule Schmalkalden 2012

und Diplom-Kaufmann Harry Maack. 1

2.2 Die Web-Anwendung

In diesem Abschnitt wird zunächst über den Zweck der Web-Anwendung gesprochenund anschließen die eingesetzte Architektur näher beschrieben.

2.2.1 Zweck der Web-Anwendung

Bei der Web-Anwendung handelt es sich um ein Serviceportal für Individualkundensowie für Geschäfts- und Vertriebspartner von Versicherungsunternehmen. Darausergeben sich folgende Benutzergruppen, welche innerhalb der Anwendung unter-schiedliche Berechtigungen und Funktionen besitzen:

• Agentur

• Makler

• Kommunen

• Kirchen

• Krankenhäuser

• Sparkassen

• Banken

Innerhalb der Anwendung können Tarifberechnungen durchgeführt, entsprechendeAnträge gestellt sowie allgemeine produkt- und vertriebsspezifische Informationenabgerufen werden. Zudem erhält der Nutzer die Möglichkeit, seinen Ansprechpart-ner direkt über die Web-Anwendung zu kontaktieren. Vertriebspartner können überdas Portal Bestellungen für Vertriebsmaterialien oder Werbemittel aufgeben. Dar-über hinaus können Änderungs-, Schadens- und Jahresmeldungen über die Web-Anwendung versendet werden.

Zusätzlich beinhaltet das System ein zentrales sowie dezentrales Kampagnenmana-gementsystem mit Anbindung an Lettershops für individuelle Anschreiben. LaufendeKampagnen können so gezielt durchgeführt und ausgewertet werden.

1Vgl. [Invb]

Martin Schüler Seite 6 von 85

Page 12: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

2. Grundlagen Fachhochschule Schmalkalden 2012

Bei der Web-Anwendung handelt es sich um eine mandantenfähige J2EE-Lösung.Das heißt, verschiedene Kunden oder Auftraggeber nutzen das gleiche physischeSystem. Die Unterschiede zwischen den einzelnen Mandanten liegen vor allem imDesign, in der Navigationsstruktur, den einzelnen Modulen sowie in den verwen-deten Formularen. Dies gewährleistet, dass ein neuer Mandant mit relativ wenigAnpassungen hinzugefügt werden kann.2

2.2.2 Architektur der Web-Anwendung

Die Web-Anwendung besteht aus einer „Drei-Schicht-Architektur“. Dies hat denVorteil, dass die Anwendung gut skalierbar ist, da die einzelnen Schichten logischvoneinander abgegrenzt sind. Dabei dürfen Objekte nur auf die eigene oder dienächst tiefere Ebene zugreifen.

Die Abbildung 2.1 stellt die logischen Komponenten der Web-Anwendung dar. Siebeschreibt die drei Ebenen der Architektur, welche auf einen WebSphere-Server be-ziehungsweise auf den Browser des Clients betrieben werden. Die erste Schicht ist diesogenannte Präsentationsschicht, welche auf dem Browser des Users läuft. Sie dientdabei als Schnittstelle zwischen dem User und dem entsprechenden Anwendungskerndes Systems. Dies besteht aus der Dialogsteuerung und generierten JSPs. Die zweiteSchicht beinhaltet den Anwendungskern, welcher aus allen Anwendungsobjekten undGeschäftsprozessen besteht. Die Dateien, welche zu dieser Ebene gehören, sind als„Agent“ gekennzeichnet. Die letzte Ebene besteht aus der Datenverwaltung und denBackend-Adaptern, welche die Backend-Systeme vom Rest der Anwendung trennen.Die zu der Persistenz-Schicht gehörenden Daten, sind als „Factory“ gekennzeichnet.Als Datenverwaltung wird in der Web-Anwendung eine DB2-Datenbank eingesetzt,welche auf einem separaten Server läuft. Zusätzlich werden der Web-AnwendungSchnittstellen zu anderen Systemen bereitgestellt. So liegen zum Beispiel die Datenfür Vertriebsmaterialien und Werbemittel in einem Lotus Notes-System und könnendort zentral verwaltet werden. Zusätzlich wird in der dritten Schicht eine Verbindungzu anderen Backend-Systemen bereitgestellt.

Die Informationen für die einzelnen Bereiche der Web-Anwendung, wie zum BeispielBenutzerinformationen oder Kampagnendaten, befinden sich in fünf unterschiedli-chen Datenbanken. Dies ermöglicht eine logische Trennung der Inhalte und verein-facht die Pflege der Daten.

2Vgl. [Invc]3Vgl. [Inva]4Vgl. [Inva]

Martin Schüler Seite 7 von 85

Page 13: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

2. Grundlagen Fachhochschule Schmalkalden 2012

Abbildung 2.1: Logische Komponenten der Web-Anwendung 3

Martin Schüler Seite 8 von 85

Page 14: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

2. Grundlagen Fachhochschule Schmalkalden 2012

Abbildung 2.2: Schematische Darstellung der Kopplung von OpenCMS und der Web-Anwendung 4

Die Abbildung 2.2 stellt die Kopplung von OpenCMS und der Web-Anwendung dar.Das Content-Management-System enthält sowohl die statischen Inhalte als auch dieMenüstruktur der Applikation. Die Menüstruktur enthält die Adressierung der stati-schen Inhalte aus dem CMS sowie die dynamischen Inhalte aus der Web-Anwendung.Durch die Verwendung verschiedener Eigenschaften wird die Sichtbarkeit der ein-zelnen Menüpunkte gesteuert, so dass jeder Anwender seine individuelle Navigati-onsstruktur erhält. Die statischen Inhalte werden vom Fachbereich der jeweiligenMandanten selbstständig verwaltet und gepflegt. Im Gegensatz dazu werden diedynamischen Inhalte von der Anwendung generiert. 5

2.3 OpenCMS

OpenCMS ist ein Content-Management-System, welches als freie Software unter derLGPL veröffentlicht wird und auf Java sowie JSP basiert. Es besitzt ein ausgereiftesRedaktionssystem in Form eines Dateiexplorers. Alle Ressourcen werden in Ordnernorganisiert und dort als Dokumente verwaltet. Dies hat den Vorteil, dass der Zugriff

5Vgl. [Inva]

Martin Schüler Seite 9 von 85

Page 15: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

2. Grundlagen Fachhochschule Schmalkalden 2012

auf alle Inhalte über eine einheitliche Oberfläche gesteuert wird. 6

2.4 Structured Query Language

Structured Query Language (SQL) wurde in den 70er Jahren im Rahmen einesForschungsauftrages von der Firma IBM entwickelt. Aufgrund der Standardisierungdurch das ANSI (American National Standards Institute) wird es von den meistverwendeten Datenbanksystemen genutzt. Dadurch ist es möglich, Anwendungenunabhängig von der verwendeten Datenbank zu erstellen. Mit SQL hat man dieMöglichkeit zur Definition, Manipulation sowie zur Integritätskontrolle von Daten-sätzen. 7

2.5 Java Database Connectivity

Java Database Connectivity (JDBC) stellt die Verbindung zwischen Datenbankenund in Java programmierten Anwendungen her. Die Applikation kann unabhän-gig zu dem verwendeten Datenbanksystem programmiert werden, denn der JDBC-Treiber übernimmt die Kommunikation mit der Datenbank. Ihm muss lediglich mit-geteilt werden, welche Datenbank verwendet wird und wie diese konfiguriert ist. 8

2.6 Java Reflection

Durch den Einsatz von Reflection ist es möglich, auf Informationen von Klassenund Objekten zur Laufzeit zuzugreifen sowie diese zu modifizieren. Dies wird dannnotwendig, wenn die entsprechende Klasse nicht bereits beim Kompilieren definiertist oder Informationen über diese abgefragt werden müssen. 9

2.7 Rational Application Developer

Der Rational Application Developer (kurz RAD) wird als Entwicklungsumgebungbei der Firma Inverso verwendet. Der RAD wurde von der Firma IBM entwickelt

6Vgl. [ConoA] Seite 26-307Vgl. [AB01] Seite 4328Vgl. [Hor]9Vgl. [Ull]

Martin Schüler Seite 10 von 85

Page 16: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

2. Grundlagen Fachhochschule Schmalkalden 2012

und löste das Produkt WebSphere Studio Application Developer ab. Dabei basiert esauf dem Open-Source-Tool Eclipse, wodurch die Entwicklungsumgebung individuellangepasst und erweitert werden kann. Der RAD ist besonders für den Einsatz miteinem WebSphere-Server optimiert. Es beinhaltet verschiedene Tools, welche denProgrammierer während der Entwicklung unterstützen. 10

2.8 ACID-Prinzip

Das ACID-Prinzip beschreibt die Eigenschaften von Verarbeitungsschritten in Da-tenbanken sowie von verteilten Systemen. Im Deutschen werden sie auch AKID-Eigenschaften genannt und stehen für Atomarität, Konsistenz, Isoliertheit sowieDauerhaftigkeit. Diese Funktionen sind die Anforderungen für Verlässlichkeit vonSystemen.

Atomarität bedeutet, dass eine Operation ganz ausgeführt werden muss. Tritt bei derAusführung ein Fehler auf, müssen alle Änderungen, welche bis zu diesem Zeitpunktgetätigt wurden, rückgängig gemacht werden. Der Begriff Konsistenz beschreibt,dass Daten nach der Beendigung einer Transaktion weiterhin widerspruchsfrei seinmüssen, sofern sie es davor bereits waren. Bei der Isolation dürfen sich nebenläufigeOperationen nicht gegenseitig beeinflussen. Wurde eine Transaktion erfolgreich ab-geschlossen, müssen die Daten permanent gespeichert werden; dies sagt der BegriffDauerhaftigkeit aus. Nach einem Systemfehler darf es zu keinem Datenverlust oderzu einer Verfälschung der Daten kommen. 11

2.9 Selenium

Mit Hilfe von Selenium können Funktionstests für Webseiten erstellt werden. Eshandelt sich dabei um ein Testframework, welches unter der Apache-2.0-Lizenzveröffentlicht wird. Mittels eines Firefox-Add-Ons können Interaktionen mit Web-Anwendungen aufgezeichnet und anschließend beliebig oft ausgeführt werden. MitHilfe von JUnit kann der Entwickler einen Testfall in Java schreiben. Dies ermög-licht den Einsatz von komplexen Oberflächentests verbunden mit der Überprüfungauf bestimmte Bedingungen. 12

10Vgl. [IBM]11Vgl. [WEK]12Vgl. [Har]

Martin Schüler Seite 11 von 85

Page 17: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

3 Die Informationssicherheit

In diesem Kapitel geht es um die Informationssicherheit im Allgemeinen. Zudemwird im letzten Abschnitt über Sicherheitslücken in Web-Anwendungen gesprochen.

3.1 Definition und Zielsetzung

Unter dem Begriff Informationssicherheit versteht man alle Maßnahmen zum Schutzvon Informationen und IT-Systemen vor Gefahren und Bedrohungen. Dadurch solldas Risiko von Schäden minimiert werden. Die Hauptschutzziele (Vertraulichkeit,Verfügbarkeit und Integrität) bilden dabei die Grundlage der Informationssicherheit.Die Bedrohungen können laut dem Bundesamt für Sicherheit in der Informationssi-cherheit (kurz BSI) in folgende Kategorien eingeordnet werden: 13

• Elementare Gefährdung

• Höhere Gewalt

• Organisatorische Mängel

• Menschliche Fehlhandlungen

• Technisches Versagen

• Vorsätzliche Handlungen 14

Der Informationssicherheit kommt eine hohe Bedeutung zu, da das Thema Sicher-heit ein grundlegendes Bedürfnis der Gesellschaft darstellt. Dies wird gerade in derheutigen Zeit weiter verstärkt, da durch die zunehmende Globalisierung die Abhän-gigkeit von IT-Systemen immer stärker zunimmt. 15 So wären heutige Geschäftspro-zesse oder Aufgaben ohne die Unterstützung durch Computer nicht mehr vorstell-beziehungsweise durchführbar, da eine große Menge an Daten durch diese erzeugt,

13Vgl. [Bre] Seite 314Vgl. [Bunb] Seite 1615Vgl. [Bund] Seite 10

Martin Schüler Seite 12 von 85

Page 18: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

3. Die Informationssicherheit Fachhochschule Schmalkalden 2012

abgelegt, weitergeleitet oder geändert werden. Aus diesem Grund ist der Schutzdieser Systeme für alle Beteiligten von großer Bedeutung. 16

Die nachfolgende Abbildung 3.1 stellt verschiedene Gefahrenbereiche dar, von denenSchäden für die Informationssicherheit ausgehen können. Die Reihenfolge der einzel-nen Bedrohungen richtet sich nach der Bedeutung für die befragten Unternehmen.Die jeweiligen Prozentwerte geben an, wie häufig dadurch ein Schaden verursachtwurde. Man kann deutlich erkennen, dass der Mensch die größte Gefährdung für einUnternehmen darstellt. Die Gründe hierfür liegen zum einen an fehlenden Schulun-gen in dem Bereich IT-Sicherheit und zum anderen in der Nachlässigkeit oder demVorsatz der eigenen Mitarbeiter.17

Abbildung 3.1: Bedeutung der verschiedenen Gefahrenbereiche 18

Wurde ein Unternehmen Opfer eines erfolgreichen Angriffes auf die IT-Sicherheit,ergeben sich daraus verschiedene Konsequenzen. Diese werden in der Abbildung3.2 aufgelistet. Anhand dieser Grafik ist erkennbar, dass jede zweite Firma, welcheangegriffen wurde, einen Ausfall von IT-Systemen hatte und dies zu Produktivitäts-verlusten führte. Die bedrohlichste Folge ist dabei der Imageschaden des betroffenenUnternehmens. Dieser Schaden wirkt sich langfristig auf die betroffene Firma aus.19

16Vgl. [Bunb] Seite 1117Vgl. [Bunc] Seite 1018Vgl. [Bunc] Seite 1019Vgl. [Wol]20Vgl. [Wol]

Martin Schüler Seite 13 von 85

Page 19: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

3. Die Informationssicherheit Fachhochschule Schmalkalden 2012

Abbildung 3.2: Konsequenzen aus Angriffen auf die IT-Sicherheit von Firmen 20

Trotz aller Vorkehrungen und Vorsichtsmaßnahmen kann niemals eine hundertpro-zentige Sicherheit erreicht werden. Dennoch ist es wichtig, das Risiko eines Angriffsoder das eines Ausfalls des IT-Systems auf ein Minimum zu reduzieren. Als Faust-regel gilt hierfür: Eine Anwendung beziehungsweise ein System gilt dann als sicher,wenn der Aufwand für einen erfolgreichen Angriff größer ist als der Nutzen für dieangreifende Person. 21

3.2 Kern-Schutzziele der Informationssicherheit

In diesem Abschnitt werden die drei klassischen Schutzziele (Vertraulichkeit, Ver-fügbarkeit und Integrität) der Informationssicherheit kurz erläutert. Je nach An-wendungsbereich können diese noch weiter zerlegt werden, wodurch beispielsweisefolgende Ziele hinzukommen können:

• Abrechenbarkeitg

• Anonymisierung

• Authentizität

• Verbindlichkeit 22

21Vgl. [Töl]22Vgl. [Sch]

Martin Schüler Seite 14 von 85

Page 20: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

3. Die Informationssicherheit Fachhochschule Schmalkalden 2012

Vertraulichkeit

Unter dem Begriff Vertraulichkeit versteht man, dass Informationen vertraulich be-handelt und gegen Missbrauch geschützt werden müssen. Dies bedeutet, dass Datennur von einem autorisierten Nutzer gelesen und geändert werden dürfen, was sowohlfür den Zugriff auf lokale Daten als auch für die Datenübertragung gilt. 23

Verfügbarkeit

Als verfügbar gelten IT-Systeme dann, wenn sie immer oder innerhalb einer vorgege-benen Zeitspanne erreichbar sind und somit genutzt werden können. Es darf währendder Nutzung zu keinen Ausfällen oder Einschränkungen kommen. Die Verfügbarkeitbezieht sich auf alle Teile eines Systems angefangen von der Anwendung des Benut-zers bis hin zur zugrundeliegenden Infrastruktur. Auch Daten oder Informationenfallen unter dieses Schutzziel. 24

Integrität

Integrität bedeutet, dass keine Daten unbemerkt oder unerlaubt verändert werdendürfen. Dies stellt somit eine der schwierigsten Bereiche in der Informationssicherheitdar, denn wurden zu Beginn keine Maßnahmen getroffen, um den Ursprung einerInformation nachvollziehen zu können, ist dies im Nachhinein kaum noch möglich.

Der Schaden, welcher bei der Verletzung der Integrität entsteht, kann in zwei Be-reiche unterteilt werden. Ein Gebiet stellt die Verletzung der Systemintegrität dar.Dabei erhält ein Angreifer Administratorzugang über eine Sicherheitslücke und er-zeugt sich weitere Accounts. Wird die Lücke geschlossen, kann ein Hacker das Rech-nersystem weiterhin über seine Accounts manipulieren.

Der zweite Bereich ist der Verlust der Datenintegrität, wobei Daten oder Informatio-nen manipuliert werden. Dies kann durch einen Virus, einen fehlerhaften Datenträgeroder durch eigenes Verschulden geschehen. 25

23Vgl. [Sch]24Vgl. [Sch]25Vgl. [Sch]

Martin Schüler Seite 15 von 85

Page 21: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

3. Die Informationssicherheit Fachhochschule Schmalkalden 2012

3.3 Sicherheitskonzept für eine Softwareanwendung

Wie bereits festgestellt wurde, kann keine allgemeingültige Aussage darüber getrof-fen werden, welche Maßnahmen nötig sind, um die Informationssicherheit innerhalbeiner Anwendung zu erhöhen. Diese richten sich nach dem Wert der zu schützendenInformation. Ein Hauptproblem ist dabei die Gradwanderung zwischen zu hohenSicherheitsmechanismen, welche zu Kosten- und Akzeptanzproblemen führen, undzu niedrigen Sicherheitsmaßnahmen, wodurch Sicherheitslücken innerhalb eines Sys-tems vorhanden sein können. Aus diesen genannten Gründen muss ein individuellesSicherheitskonzept erstellt werden. Nachfolgend wird die von dem Bundesamt für Si-cherheit (BSI) empfohlene Vorgehensweise zur Erstellung eines Sicherheitskonzepteskurz erläutert. Da kein langfristiger Schutz damit gewährleistet werden kann, mussdie Wirksamkeit sowie die Effizienz der verwendeten Schutzmechanismen regelmäßigüberprüft werden.

Abbildung 3.3: Erstellung des Sicherheitskonzeptes 26

26Vgl. [Buna] Seite 36

Martin Schüler Seite 16 von 85

Page 22: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

3. Die Informationssicherheit Fachhochschule Schmalkalden 2012

Die Abbildung 3.3 zeigt die notwendigen Schritte, welche zur Erstellung eines Si-cherheitskonzeptes erforderlich sind. Zu Beginn steht die Strukturanalyse, welchedie Grundlagen für die nachfolgenden Abläufe schafft. Dazu müssen Fragen überdie Beschaffenheit der Anwendung, die verwendete Infrastruktur oder die einge-setzten Computersysteme geklärt werden. Als nächstes ist der daraus resultierendeSchutzbedarf zu ermitteln. Diese erfolgt für alle Objekte aus der Strukturanalyse.Dabei konzentriert sich der Schutzbedarf auf möglichen Schäden, welche aus derVerletzung der drei Kernziele für das jeweilige Unternehmen entstehen können. ImIT-Grundschutz des Bundesamts für Sicherheit wird sich auf die Einteilung desSchutzbedarfes in drei Kategorien beschränkt (siehe Tabelle 3.1).

Schutzbedarfskategorie„normal“ Die Schadensauswirkungen sind begrenzt und

überschaubar.„hoch“ Die Schadensauswirkungen können beträchtlich

sein.„sehr hoch“ Die Schadensauswirkungen können ein existentiell

bedrohliches, katastrophales Ausmaß erreichen.

Tabelle 3.1: Einteilung des Schutzbedarfs

Nachdem der Schritt der Schutzbedarfsfeststellung abgeschlossen ist, werden ent-sprechende Maßnahmen zum Schutz des Systems ermittelt. Dazu kann der IT-Grundschutzkatalog der BSI herangezogen werden. Dieser enthält einzelne Bau-steine mit empfohlenen Maßnahmen, welche auf die verschiedenen Komponentenund IT-Systeme zugeschnitten sind. Diese Handlungsanweisungen richten sich zu-dem nach der Wahrscheinlichkeit eines Angriffes. Als nächster Schritt erfolgt derBasis-Sicherheitscheck, in dem ein „Soll-Ist-Vergleich“ durchgeführt wird. Dieser istin drei weitere Schritte unterteilt. Zunächst findet die organisatorische Vorbereitungstatt. Anschließend wird der eigentliche Vergleich durchgeführt, welcher mit Hilfevon Kontrollen sowie Interviews realisiert wird. Im letzten Schritt werden die Ergeb-nisse dokumentiert. Mit Hilfe einer Risikoanalyse können die Maßnahmen aus demIT-Grundschutz durch weitere Bestimmungen ergänzt werden. Nach einer weiterenÜberprüfung der Maßnahmen findet die eigentliche Umsetzung dieser statt. 27

27Vgl. [Buna] Seite 36-70

Martin Schüler Seite 17 von 85

Page 23: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

3. Die Informationssicherheit Fachhochschule Schmalkalden 2012

3.4 Ermittlung von Sicherheitslücken durchPenetrationstest

Bei einem Penetrationstest werden Angriffe auf ein IT-System unter kontrolliertenBedingungen durchgeführt. Dadurch ist es möglich, Schwachstellen eines IT-Systemszu ermitteln beziehungsweise herauszufinden, ob die eingesetzten Sicherheitsmaß-nahmen den Angriffen standhalten. Dabei kommen die gleichen Methoden zum Ein-satz, welche auch von einem realen Angreifer verwendet werden. Dieses Verfahrenführt zu einer realitätsnahen Einschätzung der Sicherheitslage eines IT-Systems,aufgrund derer geeignete Schritte schon vor einer Attacke eingeleitet werden kön-nen. Gerade die schnelle Entwicklung im IT-Bereich macht es jedoch nicht möglich,nach einem Penetrationstest verlässliche Aussagen bezüglich der Sicherheit treffenzu können. So kann eine bislang unentdeckte Schwachstelle zu einem erfolgreichenAngriff führen. Des Weiteren können durch die Weiterentwicklung der Anwendungneue Sicherheitslücken entstehen. Aus diesem Grund ist der Schutzbedarf der Infra-struktur zu ermitteln. Je höher dieser ist, desto häufiger müssen die Tests wiederholtwerden. Damit wird gewährleistet, dass die Informationssicherheit auf einem hohemNiveau bleibt. 28

3.5 Sicherheitslücken in Web-Anwendungen

Die Abbildung 3.4 zeigt die Einstufung von verschiedenen Sicherheitslücken in Web-Anwendungen. Die Einordung erfolgt dabei nicht nach der Häufigkeit von Angriffen,sondern nach dem daraus resultierenden Risiko für ein Unternehmen. In diesemAbschnitt werden die zwei größten und somit gefährdetsten Schwachstellen nähererläutert.

3.5.1 SQL-Injektion

Zu den gefährlichsten Bedrohungen für Web-Anwendung zählen SQL-Injektionen(siehe Abbildung 3.4). Dies ist dem anhaltenden Trend der Digitalisierung geschul-det. Im Rahmen dessen werden Web-Anwendungen immer komplexer und speichernihre benötigten Informationen zunehmend in Datenbanken, wodurch das Anzei-gen von dynamischen Inhalten unterstützt wird. In diesen Datenbanken befinden28Vgl. [Rey05] Seite 1 -1029Vgl. [OWA]

Martin Schüler Seite 18 von 85

Page 24: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

3. Die Informationssicherheit Fachhochschule Schmalkalden 2012

Abbildung 3.4: Top zehn Risiken für die Anwendungssicherheit aus dem Jahr 2010 29

Martin Schüler Seite 19 von 85

Page 25: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

3. Die Informationssicherheit Fachhochschule Schmalkalden 2012

sich nicht nur statische Inhalte, sondern es werden immer häufiger auch sensibleoder personenbezogene Daten in ihnen gespeichert. Durch die wachsende Zahl derAnwendungen, steigt auch dass Interesse, an die in ihnen gespeicherten Informa-tionen zu gelangen. Die besonderen Angriffsziele sind dabei die Anmeldung ohneBenutzername und Kennwort, sowie einen Angriff auf den Web-Server selbst. UmSQL-Injektion auszuführen, benötigt es relativ wenige Kenntnisse, wodurch Websei-te nicht nur durch erfahrene Angreifer attackiert werden, sondern auch von Nutzern,welche es aus reinem Interesse versuchen. Aus diesen Gründen befindet sich dieseArt der Angriffsmethode schon seit langem auf der Liste der Top zehn Risiken fürdie Anwendungssicherheit. Häufig werden zum Ausnutzen dieser Schwachstelle soge-nannte HTML-Formulare verwendet. Mit Hilfe der „Request“-Methode werden diedahinterstehenden SQL-Anweisungen manipuliert. Dies kann durch die Eingabe spe-zieller Zeichen, wie zum Beispiel die Eingabe eines Hochkommas, eines Semikolonsoder durch Kommentarzeichen, geschehen.

Um solche Angriffe erfolgreich durchführen zu können, muss ein Fehler innerhalb desProgrammcodes vorliegen. Dies ist speziell dann der Fall, wenn Benutzereingabenohne Überprüfung direkt in den SQL-String eingesetzt werden. Das nachfolgendeListing 3.1 zeigt ein Beispiel für eine Anmeldung mit Benutzername und Passwort.

Listing 3.1: Beispiel einer Java-Methode für ein Login

1 private ResultSet getBenutzer ( Statement pStatement ,String strBenutzername , String strPasswort ) {

2

3 String lQuery = "SELECT * FROM USER WHERE BENUTZERNAME= ’" + strBenutzername + "’ AND Passwort = ’" +strPasswort + "’";

4 ResultSet pRS = null;5 try {6 pRs = pStatement . executeQuery (lQuery);7 } catch ( SQLException e) {8 throw e;9 }

10 return pRs;11 }

Die erste Zeile des Listings 3.2 zeigt, wie der SQL-Befehl ohne Manipulation in-nerhalb der Datenbank ausgeführt wird. Stimmen diese Werte (Benutzername undPasswort) mit einem Benutzer in der Datenbank überein, erhält man alle dazuge-hörenden Attribute und die Anmeldung ist erfolgreich. Ist dagegen das „ResultSet“leer, wird der Login verweigert. Die zweite Zeile zeigt eine Attacke mit einem Hoch-

Martin Schüler Seite 20 von 85

Page 26: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

3. Die Informationssicherheit Fachhochschule Schmalkalden 2012

komma. Durch diese Anweisung kommt es zu einem Datenbankfehler, da diese nichtmehr dem Syntax entspricht. In der dritten Zeile wird eine Hochkomma mit einemKommentarzeichen verwendet. Stimmt der eingegebene Benutzername mit einem inder Datenbank überein, wird die Anmeldung auch ohne die Eingabe eines Passworteserfolgreich ausgeführt, da die Anweisung dem Syntax entspricht.

Listing 3.2: Beispiel für Select-Anweisungen für SQL-Injektion

1 SELECT * FROM USER WHERE BENUTZERNAME = ’benutzername ’AND PASSWORT = ’passwort ’

2

3 SELECT * FROM USER WHERE BENUTZERNAME = ’benutzer ’name ’AND PASSWORT = ’passwort ’

4

5 SELECT * FROM USER WHERE BENUTZERNAME = ’benutzername ’--’AND PASSWORT = ’passwort ’

Im Gegensatz zu den lesenden SQL-Befehle („Select“) sind die Anweisungen zumÄndern oder zum Hinzufügen („UPDATE“ oder „INSERT“) neuer Informationenviel gefährlicher. Durch diese können Datensätze neu angelegen oder bestehende ver-ändert werden, ohne dass dies bemerkt werden würde. In Zeile eins des Listings 3.3ist ein „Update“-Befehl zu sehen, welcher ein neues Passwort setzt. Durch die Mani-pulation der Anweisung in Zeile zwei kann das Passwort statt für den Benutzer mitder Kennung „benutzername“ für den Administrator geändert werden. Die eigentli-che „WHERE“-Bedingung wird mit dem Kommentarzeichen außer Kraft gesetzt. Inder dritten Zeile wird in das Passwortfeld „passwortneu ’–ëingesetzt. Dadurch wer-den alle Passwörter innerhalb einer Tabelle verändert, da die „Where“-Bedingungauskommentiert wird.

Listing 3.3: Beispiel für Update-Anweisungen für SQL-Injektion

1 UPDATE USER SET PASSWORT = ’passwortneu ’ WHEREBENUTZERNAME = ’benutzername ’

2

3 UPDATE USER SET PASSWORT = ’passwortneu ’ WHEREBENUTZERNAME = ’administrator ’ -- WHERE BENUTZERNAME =

’benutzername ’4

5 UPDATE USER SET PASSWORT = ’passwortneu ’ -- WHEREBENUTZERNAME = ’benutzername ’

Dem Anwender wird es durch manche Datenbanksysteme erlaubt, Ergebnisse vonSQL-Anweisungen in Dateien auf dem Datenbankserver zu speichern. Im Gegenzug

Martin Schüler Seite 21 von 85

Page 27: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

3. Die Informationssicherheit Fachhochschule Schmalkalden 2012

können diese Dateien auch eingelesen werden, sodass diese Informationen auf derWeb-Oberfläche dargestellt werden können. Mit Hilfe von SQL-Injektion kann die-se Funktion so ausgenutzt werden, dass die im Unix-System vorhandene Passwort-Datei ausgegeben werden würde. Das Listing 3.4 zeigt die dafür manipulierte Anwei-sung. Bei dieser Variante könnte der Angreifer sogar Zugangsdaten zum komplettenWeb-Server erhalten und somit einen noch größeren Schaden verursachen.

Listing 3.4: SQL-Injektion zum Lesen der passwd-Datei

1 SELECT * FROM information WHERE id=’1’ UNION ALL SELECT1,2,3, LOAD FILE(’/etc/passwd ’)

Bei der SQL-Injektion kann zwischen zwei Arten von Angriffen unterschieden wer-den. Zum einen wird von einem „blinden“-Angriff, wenn keine Kenntnisse über dieverwendete Infrastruktur vorhanden sind, gesprochen. Bei diesem wird zu Beginnversucht, alle benötigten Informationen zu erhalten, bevor der eigentliche Angriff er-folgen kann. Die zweite Art der Angriffe ist diese, wo die Kenntnisse bereits vorhan-den sind. Für diese Gruppe ist ein Angriff leichter, da sie wissen, welches IT-Systemverwendet wird und wie die Datenbank aufgebaut ist. In diesem Abschnitt wurdedavon ausgegangen, dass das Wissen über das verwendete Datenbanksystem sowieüber die verwendeten Tabellen existiert.30 31

Zusammenfassend kann gesagt werden, wenn es einem Angreifer gelingt, eine SQL-Anweisung zu manipulieren, hat er ein breites Spektrum an Möglichkeiten, mit denener einen Schaden verursachen kann:

• Er kann unberechtigten Zugriff auf sensible Daten erhalten.

• Er kann Daten manipulieren, ohne dass man diese Änderungen nachvollziehenkönnte.

• Ist die Datenbank schlecht gesichert, kann er Befehle auch auf Betriebssyste-mebene ausführen, wodurch er die Kontrolle über den Datenbankserver erlan-gen könnte.32

30Vgl. [Bet]31Vgl. [Bunb] Seite 97832Vgl. [Bunb] Seite 978

Martin Schüler Seite 22 von 85

Page 28: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

3. Die Informationssicherheit Fachhochschule Schmalkalden 2012

3.5.2 Cross-Site Scripting

Beim Cross-Site Scripting, oder auch „XSS“ genannt, schleust der Hacker Script-Codes in die Anwendung ein, damit diese anschließend auf dem Rechner eines an-deren Clients ausgeführt werden. Als Sprache wird hierfür überwiegend JavaScriptverwendet, da diese in den meisten Browsern aktiviert ist. Jedoch sind auch Sprachenwie HTML, VBScript, ActiveX oder Flash möglich.

Ähnlich wie bei SQL-Injektion können auch beim XSS-Angriffen Eingabefelder aus-genutzt werden. Eine einfache Cross-Site Scripting-Anweisung wird im Listing 3.5dargestellt.

Listing 3.5: Beispielcode für Cross-Site Scripting

1 <script type="text/ javascript ">Alert(’XSS Test ’) </script >

Dabei wird eine einfache Fehlermeldung mit dem Text „XSS Test“ geöffnet. Wirddiese Meldung nicht angezeigt, kann an dieser Stelle kein XSS-Angriff durchgeführtwerden.

Beim Cross-Site Scripting gibt es verschiedene Möglichkeiten eines Angriffs. So wirdbei einem persistenten Angriff der Schadcode dauerhaft auf einer Seite integriert undwird dadurch bei jedem Aufruf ausgeführt. Dabei wird mit Hilfe eines Eingabefeldesder Befehl zum Beispiel in einer Datenbank gespeichert. Bei jeder Abfrage diesesDatensatzes wird der Code an den Browser übergeben und anschließend ausgeführt.Um einen nicht persistenten Angriff handelt es sich dagegen, wenn der Schadcodedurch eine manipulierte URL ausgeführt wird. Dieser wird meistens in einer E-Mailals normaler Link getarnt. Das Ausführen des Codes geht meist in Sekundenschnelle,ohne dass dies bemerkt wird. Das Risiko eines persistenten Angriffs ist wesentlichhöher, da dieser kaum Benutzerinteraktion benötigt. 33

Die möglichen Folgen eines XSS-Angriffs:

• Umsetzung einer primitiven Denial of Service

• Ausspähen eines Cookies

• Einblendung von fremden Inhalten

33Vgl. [Vul]

Martin Schüler Seite 23 von 85

Page 29: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

4 Aktueller Stand der Anwendung

In diesem Kapitel werden zunächst die bereits eingesetzten Sicherheitsmaßnahmendargestellt. Im Anschluss daran werden in dem Bedrohungsszenario Schwachstellenoffen gelegt.

4.1 Vorhandene Sicherheitsmechanismen

In diesem Abschnitt werden einige vorhandene Sicherheitsmaßnahmen der Web-Anwendung vorgestellt. Dabei werden die Sicherheitseinstellungen der Server, derDatenbanken sowie der Infrastruktur vernachlässigt.

4.1.1 Request-Validator

Der Request-Validator ist ein von Inverso entwickelter Schutzmechanismus. Er dientdazu, alle Anfragen, welche vom Client an den Server geschickt werden, auf bestimm-te Sonderzeichen zu überprüfen. Dabei arbeitet dieser nach dem Blacklist-Prinzip.Das heißt, es sind alle Zeichen erlaubt, solange sie nicht als zu blockierendes Zei-chen definiert wurden. Die dafür notwendigen Regeln werden in einer XML-Dateigespeichert. Zudem kann für jede Seite separat festgelegt werden, ob die Parameterüberprüft werden beziehungsweise welche Sonderzeichen an einer Stelle nicht erlaubtsind.

Sendet der Client eine Anfrage an den Server, wird zuerst der Request-Validatoraufgerufen. An diesen werden alle eingegebenen Parameter sowie die entsprechen-den Dialogpfade übergeben. Anhand der Pfadangabe wird die zugehörige Regel aufalle übermittelten Informationen angewendet. Tritt dabei ein nicht erlaubtes Zei-chen auf, beispielsweise ein Hochkommata oder ein Semikolon, wird dieses durchein Sternsymbol („*“) ersetzt und der Benutzer wird durch eine Fehlermeldung dar-über informiert (siehe Abbildung 4.1). Sind alle Eingaben gültig, so werden die-se innerhalb der Web-Anwendung weiterverarbeitet. Dadurch soll die Anfälligkeit

Martin Schüler Seite 24 von 85

Page 30: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

4. Aktueller Stand der Anwendung Fachhochschule Schmalkalden 2012

der Intranet-Anwendung gegenüber SQL-Injektion und Cross-Site Scripting gesenktwerden.

Abbildung 4.1: Fehlermeldung vom Request-Validator 34

In manchen Bereichen der Web-Anwendung, speziell in Notizfeldern, möchte derNutzer jedoch keine Einschränkungen haben. Für diese Situation kann die Überprü-fung für eine komplette Seite abgeschaltet werden, so dass der User alle zur Ver-fügung stehenden Sonderzeichen nutzen kann. Dies könnte jedoch zur Folge haben,dass durch die Deaktivierung Sicherheitslücken entstehen. 35

4.1.2 Authentifizierung

Unter Authentifizierung versteht man ein Verfahren zum Nachweis einer Identität.Dies geschieht in der Regel durch die Übermittlung einer Kennung und eines Pass-wortes an einen Server. Ein unberechtigter Zugriff auf geschützte Daten soll dadurchverhindert werden.

Um in den geschlossenen Bereich der Web-Anwendung zu gelangen, muss der An-wender seine Zugangskennung eingeben. Der Benutzername sowie das Kennwortmüssen bestimmte Vorgaben erfüllen. Sobald eine Eingabe nicht diesen Anforde-rungen entspricht, wird die Anmeldung abgebrochen und der User wird darüberinformiert. Dies stellt einen wirkungsvollen Schutz gegen SQL-Injektion dar, dennEingaben wie „’1=1“ sind an dieser Stelle nicht möglich. Zusätzlich wird bei ei-ner Anmeldung die Sicherheit des Passwortes überprüft. Entspricht dieses nicht denSicherheitsanforderungen, wird der Benutzer aufgefordert, dieses zu ändern. 36

4.1.3 Autorisierung

Bei der Autorisierung wird der Zugriff von bestimmten Benutzergruppen auf Sys-temressourcen beschränkt. Dies soll die Vertraulichkeit der jeweiligen Anwendungen34Eigene Darstellung35Vgl. [Inva]36Vgl. [Inva]

Martin Schüler Seite 25 von 85

Page 31: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

4. Aktueller Stand der Anwendung Fachhochschule Schmalkalden 2012

erhöhen. Setzt ein Dialog im in der Web-Anwendung gewisse Zugriffsrechte vor-aus, werden diese beim Aufruf vom „DialogMgr.“ überprüft. Besitzt ein User nichtdie benötigten Rechte, wird die Anfrage abgebrochen und der Benutzer erhält eineFehlermeldung.

Bei mandantenfähigen Web-Anwendungen müssen weitere Sicherungsmaßnahmengetroffen werden. So gibt es zum Beispiel verschiedene Administratoren aus unter-schiedlichen Organisationen. Jeder einzelne darf aber nur auf die Daten und Benut-zer seiner Organisation zugreifen und diese ändern. Dies wird durch die verwendeten„Agents“ gewährleistet. 37

4.2 Bedrohungsszenarien

Zu Beginn dieses Bedrohungsszenarios werden Schwachstellen für SQL-Injektion ge-sucht und die daraus resultierenden Konsequenzen dargestellt. Zudem wird auf diebestehende Möglichkeit von Cross Site-Scripting eingegangen.

4.2.1 SQL-Injektion

Nachfolgend werden die verschiedenen Bedrohungsszenarien von SQL-Injektion auf-gelistet und näher beschrieben.

Anzeigen von SQL-Fehlermeldungen

Damit eine SQL-Injektion möglich ist, muss zunächst eine geeignete Schwachstel-le innerhalb der Web-Anwendung gefunden werden. Dies kann mit Hilfe geeigneterProgramme geschehen oder durch manuelles Probieren. Bei beiden Varianten wirdauf die Reaktion der jeweiligen Anwendung geachtet. Die Abbildung 4.2 zeigt eineSQL-Fehlermeldung der Web-Applikation. Anhand dieser Ausgabe kann man er-kennen, dass an dieser Stelle ein Angriff möglich ist. In diesem Fall handelt es sichum das Eingabefeld „Suche“. Der Request-Validator ist für diesen Teil der Kam-pagne abgeschaltet, was die Eingabe von Sonderzeichen ermöglicht. Diese werdenungeprüft in den SQL-String eingesetzt.

37Vgl. [Inva]38Eigene Darstellung

Martin Schüler Seite 26 von 85

Page 32: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

4. Aktueller Stand der Anwendung Fachhochschule Schmalkalden 2012

Abbildung 4.2: SQL-Fehlermeldung der Datenbank 38

Anzeigen aller Datensätzen einer Tabelle

Damit die Vertraulichkeit der Informationen gewährleistet ist, darf ein Nutzer nurauf die für ihn bestimmten Daten zugreifen. Gerade bei einer mandantenfähigenWeb-Anwendung ist dies besonders wichtig, da zum Beispiel verschiedene Firmenauf einem System arbeiten. Die Firma Inverso löst dieses Problem mit Hilfe einerentsprechenden Vermittlernummer, anhand dieser die Zuordnung der Datensätzeerfolgt. Wird nun eine Kampagne aufgerufen, bekommt der Benutzer nur die für ihnbestimmten Informationen zu sehen. Die Abbildung 4.3 zeigt ein Beispiel mit zwölfDatensätzen.

Abbildung 4.3: Zwölf Datensätze ohne SQL-Injektion 39

Wie bereits ermittelt, besteht für das Eingabefeld „Suchen“ die Möglichkeit einerManipulation der entsprechenden SQL-Anweisung. Das Listing 4.2 zeigt beispiel-haft den Standartbefehl, welcher bei einer regulären Suche ausgeführt wird. Diezweite Zeile zeigt die manipulierte Eingabe für das entsprechende Feld „Suche“. An-schließend wird die manipulierte SQL-Anweisung angegeben. Durch diese erhält derAnwender den kompletten Zugriff auf die Datensätze der Tabelle „Kampagne“. DieseÄnderung wird in der Abbildung 4.4 dargestellt. An dieser ist deutlich zu erkennen,dass 3124 statt zwölf Datensätze vorhanden sind.

Listing 4.1: Verwendete SQL-Befehle um Daten zu anzuzeigen

1 // implementierte SQL -Anweisung2 Select * from Kampagne where HV in ( hv_nummer ) and (Name

like ’%suche%’)

39Eigene Darstellung

Martin Schüler Seite 27 von 85

Page 33: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

4. Aktueller Stand der Anwendung Fachhochschule Schmalkalden 2012

3

4 // Manipulation des Eingabefeldes5 %’) or (HV in (select HV from Kampagne ))--6

7 // Manipulierte SQL - Anweisung8 Select * from Kampagne where HV in ( hv_nummer ) and (Name

like ’%%’) or (HV in (select HV from Kampagne ))-- %’)

Abbildung 4.4: Datensätze mit SQL-Injektion 40

Verändern von Werten einer Tabelle

Eine weitere Sicherheitslücke besteht auf der Detailseite einer Kampagne mit abge-schalteten Request-Validator, wo bei allen Eingabefeldern eine SQL-Injektion mög-lich ist. An dieser Stelle ist ein Angriff besonders gefährlich, weil es sich bei der imple-mentierten SQL-Anweisung um einen „UPDATE“-Befehl handelt. Dadurch könnenInformationen einer ganzen Tabelle manipuliert werden. Die Abbildung 4.5 zeigteinen Datensatz ohne jegliche Veränderung an. Das Bild 4.6 dagegen weist eine Ma-nipulation des „Straße“-Wertes von „Test“ auf „Masterarbeit“ auf. Das Listing 4.2zeigt die verwendeten SQL-Befehle. Der Anwender hat normalerweise an dieser Stel-le keine Möglichkeit, diesen Wert zu ändern. Die Manipulation wurde mit Hilfe desNotizfeldes durchgeführt.

Listing 4.2: Verwendete SQL-Befehle um Daten zu ändern

1 // normale UPDATE -Anweisung2 UPDATE KAMPAGNE set Termin=’01.05.2012 ’, Beschreibung =’

Beschreibung ’ Notiz=’Notiz ’ where Versnr=’47’;3

4 //SQL -Injektion Notizfeld5 , Strasse =’Masterarbeit ’6

7 // Manipulierte UPDATE -Anweisung

40Eigene Darstellung

Martin Schüler Seite 28 von 85

Page 34: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

4. Aktueller Stand der Anwendung Fachhochschule Schmalkalden 2012

8 UPDATE KAMPAGNE set Termin=’01.05.2012 ’, Beschreibung =’Beschreibung ’, Notiz=’’ , Strasse =’Masterarbeit ’ where

Versnr=’47’;

Abbildung 4.5: Datensatz ohne SQL-Injektion 41

Abbildung 4.6: Datensatz mit SQL-Injektion 42

Bei einem weiteren Angriff könnten alle Datensätze der Tabelle mit denselben Wer-ten überschrieben werden. Dazu würde es reichen, ein Hochkomma und zwei Binde-striche einzugeben. Dies hätte zur Folge, dass die „where“-Bedingung als Kommentargilt und von der Datenbank nicht mehr ausgeführt wird, wodurch alle Datensätzeinnerhalb der Tabelle überschrieben würden.

4.2.2 Cross-Site Scripting

An der gleichen Stelle wie in Kapitel 4.2.1 (Verändern von Werten einer Tabelle) isteine dauerhafte Cross-Site Scripting-Attacke möglich. Als dauerhaft gilt diese, da derSchadcode fest in die Datenbank geschrieben wird. Wie in Abbildung 4.7 dargestellt,

41Eigene Darstellung42Eigene Darstellung

Martin Schüler Seite 29 von 85

Page 35: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

4. Aktueller Stand der Anwendung Fachhochschule Schmalkalden 2012

wird der Code bei jedem Öffnen des manipulierten Datensatzes ausgeführt. In diesemBeispiel wird eine Alert-Box aufgerufen, was zu keinem nennenswerten Schadenführt.

Abbildung 4.7: XSS-Attacke 43

4.2.3 Analyse der Ergebnisse

Zusammenfassend kann man sagen, dass die Anwendung bereits sehr gute Maß-nahmen zur Gewährleistung der Sicherheit enthält. Alle in dieser Arbeit gefundenenLücken können nur als angemeldeter User ausgenutzt werden, da zum aktuellen Zeit-punkt keine Schwachstellen im öffentlichen Bereich der Web-Anwendung gefundenwurden. Jede ermittelte Sicherheitslücke ist nur an Stellen entstanden, an denen derRequest-Validator abgeschaltet wurde. Die Gründe für diese Abschaltung wurden imKapitel 4.1.1 bereits vorgestellt. Nachfolgend wird der Vorteil der DB2-Datenbankund das aus den Schwachstellen resultierende Gefahrenpotential näher beschrieben.

Ein wichtiger Vorteil des verwendeten Datenbanksystems DB2 ist es, dass es ankeiner Stelle möglich ist, zwei SQL-Anweisungen gleichzeitig auszuführen. Das be-deutet, dass der implementierte Befehl nicht mit Hilfe eines Semikolons beendetwerden kann, um anschließend einen weiteren Befehl auszuführen. Sobald dies ver-sucht wird, erscheint die in Abbildung 4.8 dargestellte Fehlermeldung.

Abbildung 4.8: Fehlermeldung von der DB2-Datenbank 44

43Eigene Darstellung44Eigene Darstellung

Martin Schüler Seite 30 von 85

Page 36: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

4. Aktueller Stand der Anwendung Fachhochschule Schmalkalden 2012

Die entdeckten Sicherheitslücken innerhalb der Web-Anwendung haben ein unter-schiedliches Gefahrenpotenzial. Als weniger kritisch ist die Schwachstelle bei Such-feldern („Anzeigen aller Datensätze einer Tabelle“) einzustufen. Die Lücke verletztdas Kernschutzziel „Vertraulichkeit“, da ein User sich alle Datensätze einer Tabelleanzeigen lassen kann. Jedoch können keine Daten an dieser Stelle manipuliert wer-den, sodass das Kernschutzziel „Integrität“ nicht verletzt wird. Dennoch sollte diesbei einer mandantenfähigen Web-Anwendung vermieden werden, da jeder Mandantnur auf die für ihn bestimmten Daten zugreifen darf. Für einen Laien ist es sehrschwierig, diese Schwachstelle erfolgreich auszunutzen, da der Benutzer Kenntnisseüber den in der Anwendung implementierten SQL-Befehl benötigt.

Die Sicherheitslücken auf den Detailseiten haben ein höheres Gefahrenpotenzial.Hier kann die Integrität der Daten verletzt werden, ohne dass nachvollzogen werdenkann, wer welche Daten wie verändert hat. Mit Hilfe der Fehlermeldung, welchevom System angezeigt wird, kann der Nutzer die Eingabe erfolgreich manipulieren.Viel dramatischer ist es, dass alle Datensätze mit identischen Werten überschriebenwerden können. Hierzu fügt ein Angreifer zwei Bindestriche ein, welche in SQL-Anweisungen als Kommentar zählen. Dadurch wird die „Where“-Bedingung der An-weisung nicht mehr berücksichtigt. Dies kann sogar unbeabsichtigt geschehen, dahierfür nur die Zeichenfolge „%’–„ eingegeben werden muss. Deshalb ist es notwen-dig, dass die Schwachstellen geschlossen werden. Um dies zu realisieren, wird in demnachfolgenden Abschnitt ein geeignetes Konzept erarbeitet.

Martin Schüler Seite 31 von 85

Page 37: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

5 Konzepte zur Absicherung

In diesem Kapitel werden Konzepte aufgezeigt, wie SQL-Injektionen vermieden wer-den können. Abschließend wird anhand der Auswertung das für die Inverso GmbHam besten geeignete Konzept dargelegt.

5.1 Web Application Firewall

Web Application Firewalls (WAF), auch Web Shields genannt, sollen die Web-Anwendung vor Angriffen aus dem Internet schützen. Im Gegensatz zu normalenFirewalls wird hierbei nicht die Kommunikation auf Netzwerkebene überwacht, son-dern das Hypertext Transfer Protokoll. Das Verfahren wird serverseitig eingesetztund überwacht den gesamten Datenverkehr zwischen der Web-Anwendung und demBrowser des Clients. Wird dabei ein schadhafter Inhalt identifiziert, wird der Trans-fer abgebrochen oder es wird eine vorher festgelegte Aktion ausgeführt. Dies hatden Vorteil, dass ein Angriff bereits blockiert wird, bevor er die Web-Anwendungbeziehungsweise den User erreicht. Die für die Filterung benötigten Kriterien kannman entweder manuell oder durch eine vorgeschaltete Lernphase festlegen. MancheWeb Application Firewalls überwachen nicht nur die eingehenden Daten, sondernauch diese, die zum Client gesendet werden. Die Abbildung 5.1 zeigt den Aufbaueiner WAF.

Gerade bei älteren Anwendungen ist der Einsatz von Web Shields oft die günsti-gere Variante. Denn wird eine Sicherheitslücke entdeckt, muss der Quellcode ent-sprechend geändert werden, um die Schwachstelle zu schließen. Diese Änderungenkönnen jedoch zu unerwünschten Fehlern in anderen Teilen der Applikation füh-ren, welche man nur durch aufwendige und somit kostspielige Tests ausschließenkann. Zudem ist es oftmals nicht möglich, die Lücken selbst zu schließen, da dieAnwendung durch ein anderes Unternehmen erstellt wurde. Hier ist man darauf an-gewiesen, dass dieses die Sicherheitslücke schließt. Bis dahin kann man durch denEinsatz einer Web Application Firewall das Risiko eines Angriffs minimieren.

Martin Schüler Seite 32 von 85

Page 38: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

5. Konzepte zur Absicherung Fachhochschule Schmalkalden 2012

Der Einsatz einer WAF hat aber auch einige Nachteile. So sollte diese nicht alsErsatz für eine sichere Web-Anwendung dienen, denn die Möglichkeit eines erfolg-reichen Angriffs besteht weiterhin, da die Firewall umgangen werden kann. Jedochkann man die WAF als zusätzlichen Schutz integrieren, wodurch eine weitere Sicher-heitsebene hinzugefügt wird. Eine falsch konfigurierte Firewall kann zu Störungenbei der Benutzung oder zur Unachtsamkeit während der Entwicklung führen. 45 46

Abbildung 5.1: Aufbau einer Web Application Firewall 47

5.2 Object-Relational Mapping-Tools

Durch ein Object-Relational Mapping (ORM) werden die Objekte einer höherenProgrammiersprache mit Hilfe von verschiedenen Attributen auf Objekte der Spei-cherschicht von relationalen Datenbanken abgebildet. Durch den Einsatz eines ORMsoll der sogenannte Strukturbruch verhindert werden. Dieser entsteht, wenn Objekteeiner objektorientierten Programmiersprache, wie zum Beispiel Java, in relationalenDatenbankstrukturen gespeichert werden sollen. Durch den Einsatz eines Mapping-Tools werden beim Auslesen aus der Datenbank automatisch Informationen zu kom-plexen Objekten zusammengefasst. Im Gegenzug werden diese beim Speichern ent-sprechend ihrer Eigenschaften in die Datenbank geschrieben. 48

Der Einsatz eines OR-Mappers führt zu einer Steigerung der IT-Sicherheit. Diesliegt zum einen daran, dass diese in der Regel Prepared Statements für Datenban-kabfragen verwenden. Zum anderen werden innerhalb des Quellcodes kaum noch

45Vgl. [Bune] Seite 9846Vgl. [Höl]47Vgl. [Tec]48Vgl. [Bee06] Seite 9

Martin Schüler Seite 33 von 85

Page 39: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

5. Konzepte zur Absicherung Fachhochschule Schmalkalden 2012

SQL-Anweisungen eingesetzt, was die Übersichtlichkeit sowie die Wartbarkeit derAnwendung erhöht. Des Weiteren benötigt der Programmierer keinerlei Kenntnis-se über den Aufbau der verwendeten Datenbank, da er nur auf die Objekte desOR-Mappers zugreifen muss. Dadurch wird eine komplette Abstraktion der verwen-deten Datenbank erreicht. Durch ausgereifte Caching-Mechanismen kann zudem diePerformance der Anwendung gesteigert werden. 49

5.3 Prepared Statements

Prepared Statements sind SQL-Anweisungen, welche noch keine Parameterwerte be-sitzen. Anstelle dieser Werte werden dem Datenbankmanagementsystem Platzhalterübergeben, welche zur Laufzeit mit den entsprechenden Werten gefüllt werden. Diesstellt einen wirkungsvollen Schutz gegen SQL-Injektion dar, da die Gültigkeit derKonstanten vom Datenbanksystem überprüft wird, bevor diese verarbeitet werden.Nachfolgend wird der Unterschied zwischen herkömmlichen SQL-Anweisungen undPrepared Statements im Java Code dargestellt.

Wie man im zweiten Beispiel des Listings 5.1 erkennen kann, wird der Platzhalterüber das Fragezeichen („?“) definiert. Um diesen mit Parameterwerten füllen zukönnen, muss eine, zu dem Datentyp passende „Set“-Methode aufgerufen werden;in diesem Beispiel ist es „setString“. Die Zuordnung zu dem Attribut erfolgt dabeiüber die Integer-Werte eins und zwei und richtet sich nach der Reihenfolge innerhalbder SQL-Anweisung. Bei dem direkten Vergleich der beiden Beispiele fällt auf, dassman mit wenig Aufwand eine höhere Sicherheit der Anwendung erreichen kann. 50

Listing 5.1: Beispiel für eine Prepared Statement-Anweisung

1 // Prepared Statement2 lQuery = "Select * From USER where LOWER(NAME) like ?;3

4 lStatement = lConnection . prepareStatement (lQuery);5 lStatement . setString (1, "Martin");

49Vgl. [Bune]50Vgl. [The]

Martin Schüler Seite 34 von 85

Page 40: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

5. Konzepte zur Absicherung Fachhochschule Schmalkalden 2012

5.4 Neuentwicklung

Mit der Entwicklung der Anwendung wurde im Jahr 2000 begonnen und seit demist diese stetig gewachsen. Hinzu kommt, dass im Laufe der Jahre verschiedene Pro-grammierer daran gearbeitet haben. Des Weiteren wurde gerade in der Anfangszeitwenig Wert auf die Sicherheit gelegt, da die bestehenden Risiken zu dem Zeitpunktnoch nicht bekannt waren. Durch eine Neuentwicklung hätte man die Möglichkeit,die Programmierung dahingehend auszurichten, dass die Sicherheit der Anwendungsteigt. Dazu muss im Vorfeld ein genaues Sicherheitskonzept erarbeitet werden.

Ein weiterer Vorteil der Neuentwicklung ist es, dass man dadurch die Möglichkeithätte, neue Technologien zu verwenden. Denn gerade in diesem Bereich ist in denletzten Jahren einiges geschehen. So wurde zum Beispiel im Jahr 2004 die neue Pro-grammiersprache Scala vorgestellt. Diese hat den Vorteil, dass sie Java unterstütztund als Laufzeitumgebung die Java Virtual Machine benötigt. Dadurch können be-reits bestehende Java-Bibliotheken weiterhin eingesetzt werden. Ein weiterer Grund,welcher für den Einsatz der neuen Programmiersprache spricht, ist die Reduzierungdes Quellcodes. Mit ihr können im Vergleich zur herkömmlichen Programmierungin Java 50-80 % des Codes eingespart werden, was wiederum zu einer Reduzierungvon Fehlern in der Anwendung führt, da mit zunehmenden Code diese steigen.

Lift ist ein Web-Framework, welches in der Programmiersprache Scala geschriebenwurde. Dieses erleichtert die Arbeit gerade in Hinblick auf die Programmierungvon Web-Anwendungen. In Lift wurden einige wichtige Schutzfunktionen integriert,welche viele Sicherheitslücken der Grafik 3.4 schließen. So werden zum Beispiel SQL-Injektion durch den integrierten Mapper verhindert. Dieser „escaped“ den komplet-ten Query, bevor dieser an die Datenbank übertragen wird. Eine weitere Schutzfunk-tion soll Cross-Site Scripting verhindern, indem alle Strings vor der Übermittlungzum Browser umgewandelt werden. Diese Maßnahmen sind automatisch integriertund müssen von dem Programmierer nicht weiter beachtet werden. 51 52

Allerdings wäre der Kosten- und Zeitaufwand für eine Neuentwicklung enorm, da-mit die neue Web-Anwendung dem Stand der jetzigen entspricht. Zudem käme einunkalkulierbarer Aufwand für das Testen und die anschließende Fehlerbeseitigunghinzu. Durch die hohe Komplexität und Funktionsvielfalt der Anwendung bezüglicheiner Neuentwicklung lässt sich keine aussagefähige Kosten-Nutzen-Betrachtung er-stellen.

51Vgl. [Lif]52Vgl. [o.A]

Martin Schüler Seite 35 von 85

Page 41: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

5. Konzepte zur Absicherung Fachhochschule Schmalkalden 2012

5.5 Bewertung

Nachfolgend werden die für die Präferenzmatrix entscheidenden Kriterien aufge-führt:

a) Kosten

b) Sicherheit

c) Ressourcen

d) Verwendung des Know-Hows

In der nachfolgenden Tabelle werden die Entscheidungskriterien mit Hilfe einer Prä-ferenzmatrix gegenübergestellt. Je häufiger ein bestimmtes Kriterium in der Tabellevorhanden ist, desto stärker ist die spätere Gewichtung.

• a) b) c) d)a) - - - -b) b) - - -c) a) b) - -d) a) b) c) -

Tabelle 5.1: Präferenzmatrix

Das ergibt eine Verteilung von:

• Kosten = 33 %

• Sicherheit = 50 %

• Ressourcen = 17 %

• Know-How = 0 %

Die größte Gewichtung bei der Entscheidung, welche Variante umgesetzt wird, hatdie Sicherheit der Anwendung und die dazugehörenden Daten. Dies liegt vor allemdaran, dass die Anwendung sensible Kundendaten beinhaltet und dadurch ein enor-mer Imageschaden entstehen kann, sofern diese durch einen erfolgreichen Angriffentwendet werden.

Betrachtet man die entscheidenden Kriterien aus betriebswirtschaftlicher Sicht, dür-fen die im Zuge der Umsetzung entstehenden Kosten nicht vernachlässigt werden.Aus diesem Grund kommt ihnen eine Gewichtung von 33 % zu.

Martin Schüler Seite 36 von 85

Page 42: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

5. Konzepte zur Absicherung Fachhochschule Schmalkalden 2012

Das Kerngeschäft der Inverso ist die Softwareentwicklung für Versicherungsunterneh-men. Aus diesem Grund wird dem Kriterium Know-How keine Beachtung geschenkt.

Die nachfolgende Nutzwertanalyse soll klären, welche der vorgestellten Varianten ambesten ist und somit zur Erhöhung der Sicherheit beiträgt. Es werden Punkte vonnull bis zehn für die Abdeckung der Kriterien vergeben. Diese werden anschließendmit der Gewichtung multipliziert und in das Ergebnis eingetragen. Die einzelnenResultate werden addiert und die Variante mit der größten Gesamtpunktzahl istfolglich am besten für die Umsetzung geeignet.

Tabelle 5.2: Nutzwertanalyse

Anhand der Präferenzmatrix wurde ermittelt, dass die Sicherheit der Anwendungeine große Rolle spielt. Die höchste Sicherheit wird durch den Einsatz eines OR-Mappers erreicht. Dies liegt vor allem daran, dass dieser zum einen Prepared State-ments für Datenbankabfragen verwendet und zum anderen die Übersichtlichkeit desQuelltextes erhöht. Den geringsten Schutz vor Sicherheitslücken bietet der Einsatzeiner Web Application Firewall. Sie sollte, wie bereits erwähnt, nur kurzfristig dazuverwendet werden, um Sicherheitslücken vorübergehend zu schützen. Die eigentlicheSchwachstelle innerhalb der Anwendung bleibt jedoch bestehen, sodass die Firewallmit genügend Know-How umgangen werden kann.

Eine weitere wichtige Rolle für die Entscheidungsfindung spielen die Kosten. Diesesind bei der Umstellung auf Prepared Statements am geringsten, da lediglich dievorhandenen SQL-Abfragen umgestellt werden müssten. Dadurch braucht man dieLogik der Anwendung nicht zu verändern. Im Gegensatz dazu ist der Einsatz ei-nes OR-Mappers mit wesentlich mehr Aufwand verbunden. Hierfür muss zunächstfür jede Tabelle in der Datenbank eine eigene Mapping-Datei erstellt werden undanschließend muss die Zugriffsschicht der Anwendung auf die Verwendung des OR-Mappers angepasst werden. Die höchsten Kosten würden bei der Neuentwicklungentstehen, da die Anwendung im Laufe der Jahre enorm angewachsen ist. Dies wirktsich auch auf die Auslastung der Ressourcen aus, da ein Großteil der Mitarbeitermit der Erstellung beschäftigt wäre und Änderungswünsche des Kunden nicht mehrso schnell umsetzbar sind.

Martin Schüler Seite 37 von 85

Page 43: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

5. Konzepte zur Absicherung Fachhochschule Schmalkalden 2012

Anhand der Nutzwertanalyse würde die Entscheidung zugunsten der Umstellung aufPrepared Statements ausfallen. Wie jedoch bereits in der Einleitung beschrieben, lagdie Preferenz des Unternehmens beim Einsatz eines OR-Mappers. Aus diesem Grundwird bei der prototypischen Implementierung sowohl der Einsatz eines PersistenzLayers als auch die Umstellung auf Prepared Statements realisiert.

Martin Schüler Seite 38 von 85

Page 44: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

6 Das OR-Mapper Tool Hibernate

Das von der Inverso favorisierte OR-Mapping Tool ist Hibernate. Es ist einer derbekanntesten Persistenz Layer und hat somit einen hohen Reifegrad. Es handelt sichdabei um ein Open-Source Produkt, welches von JBoss Inc. weiterentwickelt wird.Aus diesem Grund wird in diesem Kapitel Hibernate vorgestellt und die Verwendungnäher erläutert.

6.1 Objektzustände in Hibernate

In Hibernate gibt es drei verschiedene Objektzustände, welche in der Abbildung 6.1dargestellt sind. Als Transient gilt ein Objekt, welches neu erstellt wurde, aber nochnicht mit einer Session verbunden ist und noch keinen Datenbankeintrag besitzt. ImGegensatz dazu spricht man von einem Persistent, wenn ein Objekt aktuell mit einerSession verbunden ist und einen Eintrag in der Datenbank enthält. Um DetachedObjekte handelt es sich dann, wenn diese nicht mehr mit einer Session verbundensind, aber dennoch ein entsprechender Datenbankeintrag existiert.

Hibernate verwendet beim Laden von Objekten das sogenannte Lazy-Loding. Da-bei werden referenzierte Objekte des zu ladenden Datensatzes nicht sofort geholt,sondern erst dann, wenn diese benötigt werden. Dies soll die Geschwindigkeit beiAbfragen erhöhen und zusätzlich den Arbeitsspeicherverbrauch senken. Dies ist vorallem dann von Vorteil, wenn nicht das gesamte Objekt innerhalb eines Arbeits-schrittes benötigt wird. Dieses Verfahren kann sich dennoch negativ auf die Perfor-mance auswirken. Vor allem dann, wenn das komplette Objekt mit allen Referenzenbenötigt wird. In dieser Situation lädt Hibernate zunächst das Wurzelobjekt, um an-schließend die referenzierten Datensätze schrittweise nachzuladen. Es entsteht dassogenannte „1+n“-Problem.

53Vgl. [dou] Seite 11

Martin Schüler Seite 39 von 85

Page 45: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

6. Das OR-Mapper Tool Hibernate Fachhochschule Schmalkalden 2012

Abbildung 6.1: Objektzustände von Hibernate 53

6.2 Mapping-Dateien

Mit Hilfe der Mapping-Dateien kann Hibernate mit relationalen Datenbanken kom-munizieren. Es beinhaltet dabei die wesentlichen Informationen über die Architek-tur, wie Primär- und Fremdschlüssel, Spalten oder Tabellen. Dadurch können Ob-jekte in einer Datenbank gespeichert oder aus dieser geladen werden. In dem nach-folgenden Abschnitt werden verschiedene Arten von Mapping-Methoden vorgestellt.Alle aufgeführten Beispiele beruhen auf der in Abbildung 6.2 dargestellten Tabelle„User“ und dienen ausschließlich zum Erklären der jeweiligen Funktion. 54

Abbildung 6.2: Beispiel einer User-Tabelle 55

54Vgl. [Bee06] Seite 5755Eigene Darstellung

Martin Schüler Seite 40 von 85

Page 46: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

6. Das OR-Mapper Tool Hibernate Fachhochschule Schmalkalden 2012

6.2.1 Mapping mit XML-Dokumenten

Bei dieser Variante wird ein XML-Dokument für eine jeweilige Klasse erzeugt. Indieser Datei wird beschrieben, auf welche Tabelle zugegriffen werden soll. Zudemwerden die jeweiligen Attribute den entsprechenden Feldern zugeordnet. Nachfol-gend wird in dem Listing 6.1 eine Mapping-Datei für die Beispieltabelle „User“(Abbildung 6.2) erstellt.

Listing 6.1: XML-Mapping-Klasse

1 <?xml version ="1.0"?>2 <!DOCTYPE hibernate - mapping PUBLIC3 " -// Hibernate / Hibernate Mapping DTD 3.0// EN" http ://

hibernate . sourceforge .net/hibernate -mapping -3.0. dtd">

4 <hibernate -mapping >5 <class name=" mypackage .User" table="USER">6 <id name="id" column="ID" type=" integer ">7 <generator class="native"/>8 </id >9 <property name="name" column="NAME" type="string" not

-null="true"/>10 <property name=" passwort " column=" PASSWORT " type="

string"/>11 </class >12 </hibernate -mapping >

Dieses Beispiel zeigt die Datei „user.hbm.xml“ und dient als Grundlage für dasMapping. In dem „class“-Element wird unter dem Attribut „name“ die entsprechen-de Java-Klasse ausgewählt, welche nachfolgend dargestellt ist. Das Attribut „table“gibt die entsprechende Tabelle in der Datenbank an. Der Primärschlüssel wird durchdas „id“-Element festgelegt. Unter dem Attribut „name“ wird die jeweilige Variableangegeben und mit Hilfe des Attributs „column“ einer Spalte in der Tabelle zugeord-net. Mit „type“ wird der Datentyp der Spalte angegeben. Des Weiteren kann manmit „not-null“ festlegen, ob in der Datenbank Null-Werte erlaubt sind oder nicht.

Listing 6.2: Getter- und Setter-Klasse

1 package mypackage ;2

3 import java.util .*;4

5 public class User {

Martin Schüler Seite 41 von 85

Page 47: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

6. Das OR-Mapper Tool Hibernate Fachhochschule Schmalkalden 2012

6 private int id;7 private String name;8 private String passwort9

10 public int getId () {11 return id;12 }13 public String getName () {14 return name;15 }16 public String getPasswort () {17 return passwort ;18 }19

20 public void setId(int id) {21 this.id = id;22 }23 public void setName (String name) {24 this.name = name;25 }26 public void setPasswort (String passwort ) {27 this. passowrt = passwort ;28 }29 }

Diese in Listing 6.2 dargestellte Java-Klasse liefert die „get“- und „set“-Methodenfür die Attribute der Datei „user.hbm.xml“. Mit Hilfe dieser Variablen kann manObjekte aus der Datenbank lesen oder in diese schreiben. 56

6.2.2 Mapping mit Annotations

Durch die Einführung von EJB3 wird die Trennung der Definition des Mappingsin einer XML-Datei und die Beschreibung des Geschäftsobjekts in einer Klasse auf-gehoben. Das nachfolgende Listing 6.3 zeigt das Mapping unter Verwendung vonAnnotations.

Listing 6.3: Mapping-Klasse mit Annotations

1 package mypackage ;2

3 import java.util .*;4

56Vgl. [Bee06] Seite 57 - 59

Martin Schüler Seite 42 von 85

Page 48: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

6. Das OR-Mapper Tool Hibernate Fachhochschule Schmalkalden 2012

5 @Entity6 @Table(name="USER")7

8 public class User {9

10 public User () {11 }12

13 @ID14 @Column (name="ID")15 Integer ID;16

17 @Column (name="NAME")18 String NAME;19

20 @Column (name=" PASSWORT ")21 String PASSWORT ;22

23 public int getId () {24 return ID;25 }26 public String getName () {27 return NAME;28 }29 public String getPasswort () {30 return PASSWORT ;31 }32

33 public void setId(int id) {34 ID = id;35 }36 public void setName (String name) {37 NAME = name;38 }39 public void setPasswort (String passwort ) {40 PASSWORT = passwort ;41 }42 }

Durch die @Entity-Annotation wird festgelegt, welche Java-Klasse persistent ist. Mit„@Table“ wird die zugehörige Tabelle in der Datenbank angegeben. Die Zuordnungder Spalten zu den Attributen wir durch „@Column“ realisiert.

Der Vorteil dieser Variante des Mappings ist die Beschränkung auf eine Java-Klasse.Das reduziert die Gesamtanzahl von Dateien innerhalb eines Programmes, was wie-

Martin Schüler Seite 43 von 85

Page 49: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

6. Das OR-Mapper Tool Hibernate Fachhochschule Schmalkalden 2012

derum die Wartbarkeit sowie die Übersichtlichkeit erhöhen. 57

6.3 Datenbankabfragen

In diesem Abschnitt werden verschiedene Methoden für die Datenbankkommunika-tion dargestellt. Alle Codebeispiele beziehen sich weiterhin auf die Beispieltabelle„User“ (Abbildung 6.2).

6.3.1 Hibernate Query Language

Die Hibernate Query Language (HQL) ist ähnlich aufgebaut wie die Syntax vonSQL. Ein wichtiger Unterschied ist jedoch, dass die Groß- und Kleinschreibung beiHQL nicht von Bedeutung ist. Im nachfolgenden Codebeispiel 6.4 werden alle Da-tensätze der Tabelle „User“ geholt und an eine Liste übergeben:

Listing 6.4: Codebeispiel für eine HQL-Anweisung

1 Query q = session . createQuery ("from User");2 List <user > alleUser = q.list ();

Um diese Anfrage ausführen zu können, muss vorher eine Session erzeugt werdenund über die gesamte Dauer der Abfrage aktiv sein. Solang diese mit der Daten-bank verbunden ist, enthält die Liste „alleUser“ persistente Objekte. Dadurch ist esmöglich, dass Änderungen automatisch in die Datenbank geschrieben werden. 58

6.3.2 Abfragen mit Criteria

Criterias bieten in Hibernate eine weitere typsichere Form der Datenbankabfrage.Das Listing 6.5 stellt dies dar. In der ersten Zeile wird das Criteria an eine Sessiongebunden. Dazu muss die entsprechende Mapping-Datei als Ergebnistyp angegebenwerden. Die nachfolgende Zeile zeigt eine einfache Abfrage, um den kompletten In-halt einer Tabelle abzufragen. Mit Hilfe von Kriterien können die Ergebnismengeneingeschränkt werden. Als Ergebnis werden alle Benutzer mit dem Namen Mül-ler ausgegeben. Diese Kriterien können beliebig erweitert werden. Dabei beherrschtCriteria alle bekannten Abfrageoperationen.

57Vgl. [Bee06] Seite 310 - 31158Vgl. [Bee06] Seite 149 - 159

Martin Schüler Seite 44 von 85

Page 50: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

6. Das OR-Mapper Tool Hibernate Fachhochschule Schmalkalden 2012

Listing 6.5: Codebeispiel für eine Abfrage mit Criteria

1 List user = session . createCriteria (user.class)2 .add( Restrictions .like("name", "%Martin%"))3 .list ();

Im Gegensatz zu HQL-Anweisungen ist es nicht möglich, Abfragen mit Joins zuerstellen. Ein weiterer Nachteil von Criteria ist die schlechtere Übersicht im Vergleichzu HQL-Anweisungen. 59

6.4 Cache-Methoden in Hibernate

Durch das Zwischenspeichern von Daten wird der Lesezugriff erhöht, denn diesewerden von einem langsamen Speichermedium, wie zum Beispiel der Festplatte, inden schnelleren Arbeitsspeicher geladen. Wird eine Abfrage von Hibernate gestar-tet, wird zunächst überprüft, ob diese Daten bereits im Cache vorhanden sind. Istdies der Fall, werden diese von dort geholt und weiterverarbeitet. Existieren fürdie Abfrage keine Einträge im Speicher, wird eine Datenbankabfrage gestartet unddas zurückgelieferte Ergebnis in den Cache abgelegt. Dies ermöglicht eine enormePerformancesteigerung, gerade bei sich wiederholenden Anfragen, was wiederrum zuverringerten Datenbankzugriffen führt. In Hibernate gibt es zwei Arten von Cache-Methoden(siehe Abbildung 6.3), welche nachfolgend vorgestellt werden. 60

6.4.1 First-Level-Cache

Der First-Level-Cache ist ein sehr kurzlebiger Speicher, welcher meist mehrfach vor-handen ist, denn jede Session besitzt ihren eigenen Speicher. Dieser wird beim Er-zeugen einer Session an diese gebunden und ist bis zum Ende der Session vorhanden.Jede enthält dabei ihren eigenen First-Level-Cache. Um diesen verwenden zu kön-nen, bedarf es keiner weiteren Einstellung, da dies in Hibernate von Anfang anaktiviert ist. 62

59Vgl. [Bee06] Seite 159 - 16160Vgl. [Bee06] Seite 139 - 14161Vgl. [ORD]62Vgl. [Bee06] Seite 139 - 141

Martin Schüler Seite 45 von 85

Page 51: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

6. Das OR-Mapper Tool Hibernate Fachhochschule Schmalkalden 2012

Abbildung 6.3: Darstellung des Hibernate-Caches 61

6.4.2 Second-Level-Cache

Zusätzlich zum First-Level-Cache kann in Hibernate der Second-Level-Cache konfi-guriert werden. Hierbei handelt es sich um einen optionalen Cache, welchen man nursehr vorsichtig einsetzen sollte, denn es kann leicht zu inkonsistenten Datensätzenkommen. Bei einer falschen Konfiguration kann es zudem zu einer Performancever-schlechterung führen.

Der Cache ist ein langlebiger Speicher, da er zusammen mit der Session-Factoryinitialisiert wird. Im Gegensatz zu dem First-Level-Cache existiert dieser nur einmalin jeder Anwendung. 63

6.5 Connection-Pool

Das Erzeugen einer Datenbankverbindung ist sehr teuer, da es viel Zeit in Anspruchnimmt. Aus diesem Grund wird beim Start ein gewisser Vorrat solcher Verbindungenerzeugt und im zentralen Connection-Pool abgelegt. Bei jeder Abfrage holt sichHibernate eine Verbindung aus dem Pool, welche am Ende der Transaktion wiederin dem Pool abgelegt werden und für eine andere Abfrage genutzt werden können.64

Hibernate unterstützt drei verschiedene Arten von Connection-Pools:

63Vgl. [Bee06] Seite 139 - 14164Vgl. [Bee06] Seite 91 - 93

Martin Schüler Seite 46 von 85

Page 52: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

6. Das OR-Mapper Tool Hibernate Fachhochschule Schmalkalden 2012

1. Hibernate verwaltet den Connection-Pool selbstständig. Diese Variante ist fürden Einsatz außerhalb eines Web-Servers gedacht.

2. Für den Einsatz in einem Web-Server wird empfohlen, dass Hibernate sich dieDataSource über JNDI holt, welche wiederum eine Connection zurückliefert.Hierbei werden die Einstellungen des Pools im Application-Server vorgenom-men.

3. Bei dieser Variante bekommt die Session eine Connection von der Anwendungzugewiesen, so dass Hibernate sich diese nicht mehr selbstständig holen muss.Dieser Fall ist besonders dann geeignet, wenn Datenbankzugriffe auch inner-halb der Anwendung ohne Hibernate stattfinden. 65

65Vgl. [Bee06] Seite 93

Martin Schüler Seite 47 von 85

Page 53: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7 Prototypische Umsetzung

In diesem Kapitel werden zwei verschiedene Varianten vorgestellt. Zu Beginn wirddie Implementierung von Hibernate erörtert und anschließend die Umsetzung mitPrepared Statements. Dies soll den Umfang der Veränderungen im Vergleich ver-deutlichen, da beide Varianten einen ähnlichen Nutzen bezüglich der Sicherheit dar-stellen.

7.1 Umsetzung mit Hibernate

In diesem Abschnitt werden der Ablauf und die Umsetzung der Variante mit Hiber-nate aufgelistet und näher erläutert.

7.1.1 Konfiguration von Hibernate

Für die Konfiguration von Hibernate werden zwei Dateien benötigt. Dabei enthältdie „Hibernate.cfg.xml“, welche im Listing 7.1 dargestellt ist, alle wesentlichen In-formationen. Diese gilt nur für die Verbindung zu einer Datenbank. Deshalb mussfür die Web-Anwendung der Firma Inverso GmbH für alle fünf Datenbanken eineeigene Konfigurationsdatei erstellt werden.

Das verwendete Datenbanksystem wird in Hibernate über einen Datenbanktreibereingebunden. Für die Web-Anwendung entspricht dies einem DB2-Treiber, wel-cher unter "connection.driver-classëingebunden wird. Mit Hilfe der nachfolgenden„property“-Tags werden die Adresse der Datenbank sowie die dazugehörigen Zu-gangsdaten angegeben. Für die prototypische Implementierung wurden bei Hiber-nate eigene Connection-Pools mit der Größe 2 verwendet. Im produktiven Einsatzsollte der Connection-Pool durch einen anderen ersetzt werden. Eine sehr wichtigeKonfiguration ist der SQL-Dialekt. Dieser steuert die Zugriffe von Hibernate auf dieDatenbank und gleicht die Eigenheiten eines DBMS aus. Der Second-Level-Cachekann unter „cache.provider-class“ konfiguriert werden, worauf in dieser prototypi-

Martin Schüler Seite 48 von 85

Page 54: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

schen Implementierung verzichtet wurde. Alle innerhalb der Web-Anwendung benö-tigten Mapping-Klassen müssen in der Konfigurationsdatei unter dem Mapping-Tageingetragen sein, sonst kann Hibernate nicht auf diese zugreifen.

Listing 7.1: Die Konfigurationsdatei von Hibernate (Hibernate.cfg.xml)

1 <! DOCTYPE hibernate - configuration PUBLIC2 " -// Hibernate / Hibernate Configuration DTD 3.0//

EN"3 "http :// www. hibernate .org/dtd/hibernate -

configuration -3.0. dtd">4

5 <hibernate - configuration >6 <session -factory >7 <!-- Database connection settings -->8 <property name=" connection . driver_class ">com.ibm.db2.

jcc.DB2Driver </ property >9 <property name=" connection .url">jdbc:db2://

IP_Datenbank:Port/Datenbank_Name </property >10 <property name=" connection . username ">username </

property >11 <property name=" connection . password ">passwort </

property >12

13 <!-- JDBC connection pool (use the built -in) -->14 <property name=" connection . pool_size " >2</ property

>15

16 <!-- SQL dialect -->17 <property name=" dialect ">org. hibernate . dialect .

DB2Dialect </ property >18

19 <!-- Disable the second -level cache -->20 <property name="cache. provider_class ">org.

hibernate .cache. NoCacheProvider </ property >21

22 <!-- Echo all executed SQL to stdout -->23 <property name=" show_sql ">true </ property >24

25 <!-- Drop and re -create the database schema onstartup >

26 <property name=" hbm2ddl .auto">update </ property -->27

28 <!-- Names the annotated entity class -->29 <mapping class=" backend . hibernate_mapping .

Kampa1_mapping "/>

Martin Schüler Seite 49 von 85

Page 55: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

30 <mapping class=" backend . hibernate_mapping .Kampa1Update_mapping "/>

31 <mapping class=" backend . hibernate_mapping . Kampa2"/>

32 <mapping class=" backend . hibernate_mapping .Kampa2Update "/>

33 </session -factory >34 </hibernate -configuration >

Das nachfolgende Listing 7.2 zeigt den Aufbau der Klasse „Hibernateutil“. Mit Hilfedieser Datei wird eine Session in Hibernate erstellt. Dazu wird die entsprechendeKonfigurationsdatei eingebunden. In diesem Listing werden zwei Sessions für zweiDatenbanken erstellt.

Listing 7.2: Aufbau der Datei Hibernateutil

1 public class HibernateUtil {2 private static final SessionFactory

sessionFactoryRisiTest ;3 static{4 sessionFactoryRisiTest = new AnnotationConfiguration

(). configure ("/ hibernate .cfg.xml").buildSessionFactory ();

5 }6 public static SessionFactory getSessionFactoryRisiTest

() throws HibernateException {7 return sessionFactoryRisiTest ;8 }9

10 private static final SessionFactorysessionFactoryKampa2 ;

11 static{12 sessionFactoryKampa2 = new AnnotationConfiguration ().

configure ("/ hibernateKampa2 .cfg.xml").buildSessionFactory ();

13 }14 public static SessionFactory getSessionFactoryKampa2 ()

throws HibernateException {15 return sessionFactoryKampa2 ;16 }17 }

Martin Schüler Seite 50 von 85

Page 56: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

7.1.2 Datenbankmapping mit Annotations

Das nachfolgende Listing 7.3 zeigt das Datenbankmapping von Hibernate innerhalbder Web-Anwendung. Während der prototypischen Implementierung wurden alleMapping-Klassen mit Annotations realisiert.

Listing 7.3: Auszug aus der Mapping-Datei mit Annotations

1 @Entity2 @Table(name = "Kampa2", schema = "dbms")3 public class Kampa2 {4

5 @Id6 @Column (name="VERSNR")7 private String VERSNR;8

9 @Column (name="TITEL")10 private String TITEL;11

12 @Column (name="NAME")13 private String NAME;14

15 public String getVERSNR () {16 return VERSNR;17 }18 public void setVERSNR (String versnr) {19 VERSNR = versnr;20 }21 public String getTITEL () {22 return TITEL;23 }24 public void setTITEL (String titel) {25 TITEL = titel;26 }27 public String getNAME () {28 return NAME;29 }30 public void setNAME (String name) {31 NAME = name;32 }33 }

Durch die Verwendung von „@Entity“ wird die Klasse Kampa2 als Entity definiertund kennzeichnet diese als Mapping-Klasse. Die Annotation „@Table“ legt fest, dassauf die Tabelle Kampa2 in dem Schema DBMS zugegriffen wird. Als Primärschlüssel

Martin Schüler Seite 51 von 85

Page 57: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

wird die Spalte „VERSNR“ verwendet. Die Namen der Attribute entsprechen denNamen der Spalten, wie man an der Zuordnung erkennen kann.

7.1.3 Änderung des bestehenden Java-Codes

Bei der prototypischen Implementierung beschränkt sich die Umsetzung auf denKampagnen-Bereich der Web-Anwendung. Für diese Umsetzung sind im Laufe derArbeit zwei verschiedene Konzepte entstanden, welche nachfolgend vorgestellt wer-den. Die beiden Varianten unterscheiden sich im Umfang der durchzuführenden Än-derungen und darin, wie stark das Hibernate-Konzept umgesetzt wird. Die Abbil-dung 7.1 verdeutlicht die Verwendung der CKMap.

Abbildung 7.1: Sequenzdiagramm der CKMap 66

66Eigene Darstellung

Martin Schüler Seite 52 von 85

Page 58: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

Konzept 1

Bei dieser Variante wird versucht, die Änderungen lediglich auf die Persistenz-Schicht zu beschränken. Dabei wird die bestehende CKMap mit ihrem eigenen Da-tentypen weiterverwendet.

Das Listing 7.4 zeigt einen Teil der HQL-Anweisungen, welche in den jeweiligenMappingklassen ausgelagert werden. Diese sind nicht allgemeingültig, sondern müs-sen für jede Tabelle neu implementiert werden, da sich die Spalten unterscheidenkönnen.

Listing 7.4: Beispiel für HQL-Anweisungen in den Mapping-Dateien

1 @NamedQueries ({2 @NamedQuery (3 name = " KAMPA1getBestand ",4 query = "from backend . hibernate_mapping .

Kampa1_mapping Kampa1 where " +5 " Kampa1.HV in (:hv) " +6 "and (lower(Kampa1.VERSNR) like (: suche) " +7 "or lower(Kampa1.NAME1) like (: suche) " +8 "or lower(Kampa1. VORNAME1 ) like (: suche) " +9 "or lower(Kampa1.PLZ) like (: suche) " +

10 "or lower(Kampa1.ORT) like (: suche) " +11 "or lower(Kampa1. STATUS_BESCHREIBUNG ) like (: suche)

)"12 ),13 @NamedQuery (14 name = " Kampa1getCount ",15 query = "select count (*) from backend .

hibernate_mapping . Kampa1 _mapping Kampa1 where "+

16 Kampa1.HV in (:hv) "17 ),18 @NamedQuery (19 name = " Kampa1details ",20 query = "from backend . hibernate_mapping . Kampa1

_mapping Kampa1 where " +21 " Kampa1.VERSNR = :versnr"22 )23 })

Das Listing 7.5 zeigt exemplarisch die Änderungen an der CKFactory für die Be-standsübersicht der Kampagnen. Zu Beginn wird die Session für die Datenbank ge-holt. Anschließend wird der ausgelagerte HQL-Befehl an die Variable StringQuery

Martin Schüler Seite 53 von 85

Page 59: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

übergeben. In der darauffolgenden Zeile wird ein neuer HQL-Befehl erzeugt, wel-cher aus dem „StringQuery“, der Sortierbedingung und der Anzahl der zu holendenDatensätze besteht. Dieser Zwischenschritt ist notwendig, da der User auf der Ober-fläche festlegen kann, wie er die Daten sortiert haben möchte und Hibernate keinePlatzhalter innerhalb von Sortierbedingungen unterstützt. In den nächsten Schrittenwerden die Platzhalter der HQL-Anweisungen mit Werten gefüllt. Durch den Befehl„q.list()“ findet die eigentliche Datenbankabfrage statt und die Informationen ausder Datenbank werden dem Hibernate-Objekt übergeben. Die nächste Zeile ruft eineMethode auf, welche die Umwandlung in eine CKMap realisiert. Dafür benötigt dieMethode das Hibernate-Objekt sowie den Pfad der Mapping-Klasse.

Listing 7.5: Änderungen an der CKFactory

1 Session session = HibernateFactory . getSession ( pConfig );2 String StringQuery = session . getNamedQuery ( pConfig .

getCsvView () + " getBestand "). getQueryString ();3

4 Query q = session . createQuery ( StringQuery +lSortierKlausel + lAnzahlKlausel );

5

6 q. setParameterList ("hv",intArray );7

8 q. setString ("suche","%" + pSuchbegriff . toLowerCase () +"%");

9

10 List hibernateList = q.list ();11

12 int lAnzahl = hibernateList .size ();13

14 lReturn = HibernateFactory . createCKMapUebersicht (hibernateList , pConfig );

Das Listing 7.6 zeigt, wie die Umwandlung des Hibernate-Objektes in eine CKMapimplementiert wurde. Hierfür werden mit Hilfe von Java Reflection alle Attributemit dem dazugehörenden Namen aus dem Objekt in die CKMap geschrieben.

Listing 7.6: Umwandlung des Hibernate-Objektes

1 public static Object createCKMapUebersicht (ListhibernateList , ICKConfig pConfig ) throws Exception {

2

3 Map lFachlObjektDetail ;4 CKUebersicht lFachlObjekt = pConfig . getUebersichtObjekt

();

Martin Schüler Seite 54 von 85

Page 60: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

5 List spaltenListe = pConfig . getUebersichtsSpalten ();6

7 for(int i=0; i< hibernateList .size (); i++){8 lFachlObjektDetail = new CKMap ();9 for(int x=0; x< spaltenListe .size ();x++){

10 String SpaltenName = (String) spaltenListe .get(x);11 String getSpalte = "get" + SpaltenName ;12

13 Object HibernateObject = hibernateList .get(i);14 Method method = HibernateObject . getClass ().

getMethod ( getSpalte );15 Object wert = method.invoke( HibernateObject );16 lFachlObjektDetail .put(SpaltenListe , wert);17 }18 lFachlObjekt . getListe ().add( lFachlObjektDetail );19 }20 return lFachlObjekt ;21 }

Die Verarbeitung in den höheren Schichten wird weiterhin mit Hilfe der CKMaprealisiert, wodurch keine weiteren Änderungen in diesen Bereichen anfallen. BeimSpeichern der neuen Werte wird ein umgekehrter Weg vollzogen. Für das Updateneines Datensatzes wird eine neue Mapping-Datei benötigt. Der Grund hierfür wurdebereits in der Ausgangssituation beschrieben. An diesem Punkt stellen die eigenenDatentypen ein weiteres Problem dar. Diese müssen vor dem Schreiben umgewan-delt werden. Das Listing 7.7 zeigt die für das Updaten eines Datensatzes benötigtenSchritte. Diese Methode ist allgemeingültig gestaltet und schreibt alle Werte einerCKMap per Hibernate in die entsprechende Datenbank. Zu Beginn dieser Metho-de muss der aktuelle Datensatz, welcher verändert werden soll, aus der Datenbankgeholt werden. Dies ist notwendig, da das vorhergehende Hibernate-Objekt auf derentsprechenden View beruht und das Updaten auf der Tabelle geschieht. Anschlie-ßend werden die Daten der CKMap umgewandelt. Dazu durchläuft die Schleife alleAttribute des Hibernate-Objektes und ersetzt die Werte, welche geändert werdensollen durch die der CKMap. Da diese zum Teil eigene Datentypen sind, werdendiese entsprechend umgewandelt. Die letzten vier Zeilen dienen zur Speicherung desHibernate-Objektes. Dies zeigt deutlich, dass das Speichern innerhalb von Hibernatesehr einfach realisierbar wäre, wenn nicht die CKMap verwendet werden würde.

Listing 7.7: Auszug aus dem Quellcode der updateKampa()-Methode

1 public static void updateKampa (CKMap CKMap , StringHibernateClass ){

Martin Schüler Seite 55 von 85

Page 61: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

2 Session session = HibernateUtil . getSessionFactoryKampa2(). openSession ();

3 session . beginTransaction ();4

5 List HibernateList = session . createCriteria (HibernateClass )

6 .add( Restrictions .ilike("VERSNR",CKMap.get("VERSNR")7 . toString ())).list ();8

9 Object HibernateObject = HibernateList .get (0);10

11 MessageMgr lMessageManager = MessageMgr . getInstance ();12 Field [] field = HibernateObject . getClass ().

getDeclaredFields ();13

14 for(int i=0; i<field.length;i++){15 String setString = field[i]. getName ();16 Object tmp = CKMap.get( setString );17 Object wert = null;18 try {19 if (tmp instanceof Text) {20 wert = TextToString (tmp);21 }22 else if (tmp instanceof Zahl) {23 wert = ZahlToDouble (tmp);24 }25

26 ///....27

28 if(wert != null){29 if(! field[i]. getName ().equals(" Z_USERKEY ")){30 field[i]. setAccessible (true);31 System.out. println ( setString );32 field[i]. set( HibernateObject , wert);33 }34 else {35 field[i]. setAccessible (true);36 field[i]. set( HibernateObject ,37 Integer . parseInt (tmp. toString ()));38 }39 }40

41 }42 //catch -Block .....43 }44 org. hibernate . Transaction tx = session . beginTransaction

Martin Schüler Seite 56 von 85

Page 62: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

();45 session .update( HibernateObject );46 tx.commit ();47 session .close ();48 }

Durch das vorgestellte Konzept sind wesentlich weniger Anpassungen am Quelltextvorzunehmen. Es müssen lediglich die entsprechenden Mapping-Dateien erstellt so-wie die kampagnenspezifischen Factorys angepasst werden. Für die Änderungen anDatensätzen kann die in diesem Konzept erarbeitete Methode verwendet werden.Dazu muss lediglich der Aufruf in dem entsprechenden Agent geändert werden.

Dennoch wird bei dieser Variante das Hibernate-Konzept nicht umgesetzt. So werdendie Daten aus der Datenbank mehrfach umgewandelt, wodurch auch die Vorteile derObjektzustände von Hibernate verloren gehen. Des Weiteren ist bei der Aktualisie-rung eines Datensatzes ein doppelter Zugriff auf die Datenbank nötig, was wiederumdie Geschwindigkeit beeinträchtigt.

Konzept 2

Bei dieser Variante wurde nach einem Weg gesucht, der das Hibernate-Konzeptbesser umsetzt. Die Mapping-Klassen mit den dazugehörenden HQL-Anweisungenaus dem ersten Konzept kommen in diesem ebenfalls zum Einsatz. Der einzige Un-terschied innerhalb der Persistenz-Schicht besteht bei dem Rückgabetyp. Es wirdnicht mehr die CKMap zurückgegeben, sondern das Hibernate-Objekt, in dem dieDaten enthalten sind. Daraus ergeben sich jedoch massive Änderungen innerhalbder Dialog-Schicht. Diese muss so angepasst werden, dass sie die Daten aus demHibernate-Objekt verwendet und nicht wie bisher aus der CKMap. Das Listing 7.8zeigt die Änderungen für das Feld „Name“, welche beim Lesen und beim Speichernder Werte notwendig sind. Diese Anpassungen müssen für jedes Feld in den einzelnenKampagnen durchgeführt werden.

Listing 7.8: Änderungen in der Dialog-Schicht

1 //Lesen2 //alt:3 pDialogModel . setDetailKundeName ( lMapfachlObjekt .

stringToText ("NAME",""));4 //neu:5 pDialogModel . setDetailKundeName (new Text (map. getNAME

()));

Martin Schüler Seite 57 von 85

Page 63: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

6

7 // Speichern8 //alt:9 lMapfachlObjekt .put(Kampa1.SPALTE_NAME , pDialogModel .

getDetailKundeName ().toJDBC ());10 //neu:11 Kampa1. setNAME ( pDialogModel . getDetailKundeName ().

toJDBC ());

Um diese Variante in der gesamten Anwendung zu implementieren, sind sehr vieleAnpassungen notwendig. So muss für jede Tabelle in der Datenbank eine passendeMapping-Datei erstellt werden; dieser Schritt wird generell für Hibernate benötigt.Im Anschluss daran müssen die bestehenden SQL-Anweisungen in einen HQL-Befehlumgeändert werden, damit ein Sicherheitsvorteil überhaupt entsteht. Die aufwen-digsten Anpassungen müssen in der Dialog-Schicht vorgenommen werden, damitdiese mit dem Hibernate-Objekt umgehen kann. Hierbei tritt jedoch ein weiteresProblem auf, denn beim Speichern der Daten werden eigene Datentypen wie „Geld“oder „E-Mail“ verwendet. Diese müssen, bevor sie an das Hibernate-Objekt überge-ben werden, in einfache Datentypen umgewandelt werden.

7.2 Einsatz von Prepared Statements

Wie im Kapitel 5.3 beschrieben, werden bei Prepared Statements keine Parame-terwerte an die Datenbank übergeben. Stattdessen werden Fragezeichen als Platz-halter genutzt. Bevor die Anweisung ausgeführt werden kann, müssen jedoch alleParameter mit Werten gefüllt werden, ansonsten führt dies automatisch zu einerFehlermeldung. Bei der Belegung der Platzhalter überprüft das Datenbanksystemdie Variablen auf ihre Gültigkeit. Aus diesem Grund steht für jeden Datentyp ei-ne eigene „set()“-Methode zur Verfügung. Die Zuordnung erfolgt dabei mit einereindeutigen ID, welche jedes Fragezeichen besitzt. Diese beginnt bei eins und wirdmit jedem weiteren Platzhalter um eins erhöht. Ein großer Vorteil von Hibernate istdie Unterstützung von benannten Parametern. Aus diesem Grund wurde nach einerMöglichkeit gesucht, diese auch bei Prepared Statements verwenden zu können. Dieerarbeitete Lösung wird in diesem Abschnitt beschrieben.

Martin Schüler Seite 58 von 85

Page 64: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

7.2.1 NamedParameterStatement-Klasse

Die neue Java-Klasse „NamedParamterStatement“ ermöglicht die Nutzung von be-nannten Platzhaltern bei der Verwendung von Prepared Statements. Dadurch wirddie Erstellung von Datenbankabfragen einfacher, da der Quellcode übersichtlicherist. Die Listings 7.9 und 7.10 zeigen dabei im Vergleich die Unterschiede der beidenVarianten.

Listing 7.9: Beispiel für eine Prepared Statement-Anweisung

1 // Prepared Statement2 lQuery = "Select * From Kampa1 where LOWER(NAME) like ? "3 + " OR LOWER( VORNAME ) like ? "4 + " OR PLZ = ? "5 + " OR LOWER(VERSNR) like ?"6 + " OR LOWER(ORT) like ?";7

8 lStatement = lConnection . prepareStatement (lQuery);9 lStatement . setString (1, searchstring . toLowerCase ());

10 lStatement . setString (2, searchstring . toLowerCase ());11 lStatement .setInt (3, plzInt);12 lStatement . setString (4, searchstring . toLowerCase ());13 lStatement . setString (5, searchstring . toLowerCase ());14 lRs = lStatement . executeQuery ();

Listing 7.10: Beispiel für eine Prepared Statement-Anweisung mit benannten Parametern

1 // NamedParameterStatement2 lQuery = "Select * From Kampa1 where LOWER(NAME) like :

search "3 + " OR LOWER( VORNAME ) like :search"4 + " OR PLZ = : searchPLZ "5 + " OR LOWER(VERSNR) like :search "6 + " OR LOWER(ORT) like :search ";7

8 NamedParameterStatement p =new NamedParameterStatement (con , lQuery);

9 p. setString ("search", "%" + searchstring . toLowerCase () +"%");

10 p.setInt(" searchPLZ ", plzInt);11 lRs = p. executeQuery ();

Die neue Java-Klasse ist ein sogenannter Wrapper, welcher den SQL-String mit be-nannten Parametern entgegennimmt und diesen anschließend in eine reguläre Pre-

Martin Schüler Seite 59 von 85

Page 65: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

pared Statement-Anweisung mit Fragezeichen umwandelt. Beim Erzeugen des Ob-jekts „NamedParameterStatement“ muss die Connection sowie die SQL-Anweisungmit bezeichneten Parametern übergeben werden. Das Listing 7.11 zeigt, was dabeigeschieht. Für die Umwandlung des Strings sorgt die „pars()“-Methode. Da jederbenannte Platzhalter mit einem Doppelpunkt eingeläutet werden muss, untersuchtdiese den String nach genau diesem Zeichen. Wird dieses Symbol innerhalb derAnweisung entdeckt, werden alle Buchstaben oder Ziffern, welche bis zum nächstenLeerzeichen vorkommen, als Name des Platzhalters definiert und innerhalb des SQL-Strings durch ein Fragezeichen ersetzt. Der ermittelte Name wird als Key in einerHashmap gespeichert, sofern dieser noch nicht in ihr enthalten ist. Des Weiterenwird in einer Liste die entsprechende ID abgelegt, welche in der Map zu dem pas-senden Schlüssel angehangen wird. Enthält diese bereits den Platzhalter, wird dieListe um die weitere Identifikationsnummer erweitert. Der Quelltext dazu befindetsich im Listing 7.12. Die „pars()“-Methode liefert anschließend den umgewandeltenString zurück, welcher danach per Prepared Statement-Befehl an die Datenbankübermittelt wird.

Listing 7.11: Quellcode der NamedParameterStatement-Methode 67

1 public NamedParameterStatement ( Connection connection ,String query) throws SQLException {

2 indexMap =new HashMap ();3 String parsedQuery =parse(query , indexMap );4 statement = connection . prepareStatement ( parsedQuery );5 }

Wie bei der herkömmlichen Variante von Prepared Statements müssen auch hier allePlatzhalter vor dem Ausführen des Datenbankbefehls gefüllt sein, da ansonsten vonder Datenbank eine Fehlermeldung zurückgegeben wird. Das Listing 7.13 zeigt, wiedie einzelnen Parameter mit Werten gefüllt werden können. Es gibt auch hier fürjeden Datentyp eine entsprechende „set()“-Methode. Der Unterschied zur herkömm-lichen Variante besteht jedoch darin, dass die Zuordnung der Werte nicht mit einerID, sondern mit dem Namen des Platzhalters, erfolgt. Dazu sucht die Java-Klassein ihrer Map nach dem entsprechenden Parameter. Ist dieser vorhanden, wird dieListe mit den dazugehörigen Identifikationsnummern zurückgegeben. Anschließendwird für jeden Eintrag in der Liste ein Prepared Statement-Befehl mit der ID unddem Wert ausgeführt. 68

67Vgl. [Cru]68Vgl. [Cru]

Martin Schüler Seite 60 von 85

Page 66: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

Listing 7.12: Auszug aus der parse()-Methode 69

1 for(int i=0;i<length;i++) {2 char c=query.charAt(i);3 if( inSingleQuote ) {4 if(c==’\’’) {5 inSingleQuote =false;6 }7 } else if( inDoubleQuote ) {8 if(c==’"’) {9 inDoubleQuote =false;

10 }11 } else {12 if(c==’\’’) {13 inSingleQuote =true;14 } else if(c==’"’) {15 inDoubleQuote =true;16 } else if(c==’:’ && i+1< length &&17 Character . isJavaIdentifierStart (query.charAt(i+1))) {18 int j=i+2;19 while(j<length && Character . isJavaIdentifierPart (

query.charAt(j))) {20 j++;21 }22 String name=query. substring (i+1,j);23 c=’?’; // replace the parameter with a question mark24 i+= name.length (); // skip past the end if the parameter25 List indexList =( List) paramMap .get(name);26 if( indexList == null) {27 indexList =new LinkedList ();28 paramMap .put(name , indexList );29 }30 indexList .add(new Integer (index));31 index ++;32 }

Listing 7.13: Beispiel für eine Methode zum Setzen von Parametern 70

1 public void setString (String name , String value) throwsSQLException {

2 int[] indexes = getIndexes (name);3 for(int i=0; i < indexes .length; i++) {4 statement . setString ( indexes [i], value);5 }6 }

69Vgl. [Cru]

Martin Schüler Seite 61 von 85

Page 67: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

7.2.2 Setzen von Werten

Wie bei einer normalen Prepared Statement-Anweisung müssen vor dem „execute“-Befehl alle Platzhalter mit Werten belegt sein. Ist dies nicht der Fall, wird von demDatenbanksystem eine Fehlermeldung zurückgegeben. Für jeden Datentyp steht ei-ne geeignete „set()“-Methode zur Verfügung. Der einzige Unterschied besteht darin,dass die Zuordnung nicht mit Hilfe der ID geschieht, sondern der Name des entspre-chenden Platzhalters verwendet wird. Sind mehrere Platzhalter mit dem gleichenNamen vorhanden, wird der angegebene Wert automatisch allen zugewiesen.

Zum Setzen der Werte stehen folgende Methoden zur Verfügung:

• setString(String name, String value);

• setDate(String name, Date value);

• setDatum(String name, Datum value);

• setFloat(String name, Float value);

• setDouble(String name, Double value);

• setBoolean(String name, Boolean value);

• setObject(String name, Object value);

• setTimestamp(String name, Timestamp value);

• setCKMap(CKMap map);

• setNamedMap(Map valueMap);

Es ist zudem möglich, eigene Methoden zu implementieren, welche die Logik für eineentsprechende Zuweisung enthalten.

7.2.3 Änderungen bei Select-Anweisungen

Die Änderungen bei Select-Anweisungen werden exemplarisch für die Methoden „ge-tResultsetBestandUebersicht()“ (siehe Listing 7.14) und „getWhereKlauselSuchbe-griff()“ dargestellt. Jede Kampagne hat ihre eigene spezifische „Where“-Bedingungmit unterschiedlichen Parametern, welche von der CKFactory aufgerufen wird. Da-mit die Datenbankabfrage weiterhin allgemeingültig bleibt, wurde die „NamedPa-rameterMap“ eingeführt. In dieser werden die Namen des Platzhalters sowie der

70Vgl. [Cru]

Martin Schüler Seite 62 von 85

Page 68: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

dazugehörenden Werte gespeichert. Vor dem Ausführen des SQL-Strings wird dieseHilfsmap an die Klasse „NamedParameterStatement“ übergeben, welche das Setzenper Prepared Statements an der entsprechenden Stelle der SQL-Anweisung über-nimmt. Das Listing 7.16 mit der Methode „setNamedMap()“ stellt diese Funktiondar. Die Methode prüft, ob der benannte Platzhalter aus der SQL-Anweisung in derHilfsmap enthalten ist. Ist dies der Fall, wird anhand des Datentyps die entsprechen-de „set()“-Methode aufgerufen, wo die Belegung der Platzhalter mit dem gleichenNamen geschieht.

Das Listing 7.15 zeigt ein Beispiel der Methode „getWhereKlauselSuchbegriff()“.In ihr wird die Suchbedingung der jeweiligen Kampagne zusammengesetzt. Als be-nannte Platzhalter werden dabei „searchstring“, „searchdouble“ und „searchdate“verwendet, welche mit einem Doppelpunkt versehen innerhalb der SQL-Anweisungstehen. Anschließend wird in der Hilfsmap der Name des Platzhalters mit dem da-zugehörenden Wert gespeichert.

Listing 7.14: Auszug aus der Methode getResultsetBestandUebersicht()

1 Map <String ,Object > NamedParameterMap = new HashMap <String, Object >();

2 String lSchema = super. mSchemaKampa2 ;3 if ( pConfig . getNameDB ().equals( ICKConfig . DB_KAMPAGNE ))4 lSchema = super. mSchemaKampagne ;5 String lTabelle = pConfig . getUebersichtstabelle ();6 String lSpalten = "*";7 if ( pConfig . getUebersichtsSpalten () != null)8 lSpalten = listToString ( pConfig . getUebersichtsSpalten ()

, ’,’);9

10 String lQuery = "select " + lSpalten + " from " + lSchema11 + "." + lTabelle + " where "12 + getWhereKlauselVNr (pZielgruppe , pHVNrn ,13 pContrNrn , CKAgent . HIERARCHIE_BESTAND , NamedParameterMap )14 + getWhereKlauselSuchbegriff (pSuchbegriff ,

NamedParameterMap )15 + lSortierKlausel + lAnzahlKlausel ;16

17 try {18 Connection con = pStatement . getConnection ();19 NamedParameterStatement p =new NamedParameterStatement (

con , lQuery);20 p. setNamedMap ( NamedParameterMap );21 pRs = p. executeQuery ();22 p.close ();

Martin Schüler Seite 63 von 85

Page 69: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

23 log.debug("\n Query: " + lQuery + ":\n");24

25 } catch ( SQLException e) {26 ....27 }28 log.debug("end");29 return pRs;30 }

Listing 7.15: Auszug aus der Methode getWhereKlauselSuchbegriff

1 if ( pSuchbegriff != null && ! pSuchbegriff .equals("")) {2 lWhereKlausel = " AND (LOWER("+ SPALTE_NAME +") like :

searchstring "3 + " OR LOWER("+ SPALTE_VORNAME +") like : searchstring "4 + " OR LOWER("+ SPALTE_PLZ +") like : searchstring "5 + " OR LOWER("+ SPALTE_ORT +") like : searchstring "6 + " OR LOWER("+ SPALTE_STATUS_BESCHREIBUNG +") like :

searchstring "7 + " ";8 NamedParameterMap .put(" searchstring ", "%" +

pSuchbegriff . toLowerCase () + "%");9 if (( Datum. parseDatum ( pSuchbegriff )) instanceof Datum)

{10 lWhereKlausel += " OR " + SPALTE_VERSANDDATUM + " = :

searchdate OR "11 + SPALTE_GEBURTSDATUM + " = : searchdate ";12 NamedParameterMap .put(" searchdate ", Datum. parseDatum (

pSuchbegriff ));13 }14 lWhereKlausel += ") ";15 }

Listing 7.16: Auszug aus der Methode setNamedMap

1 if (! valueMap . isEmpty ()){2 for( Iterator itr= indexMap . entrySet (). iterator (); itr.

hasNext ();) {3 Map.Entry entry =( Map.Entry)itr.next ();4 String name = (String) entry.getKey ();5 if( valueMap . containsKey (name)){6 Object value = valueMap .get(name);7 if (value instanceof String) {8 setString (name , value. toString ());9 }

Martin Schüler Seite 64 von 85

Page 70: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

10 else if (....){11 ......12 }13 }14 }15 }

7.2.4 Änderungen bei Update-Befehlen

Das Listing 7.17 zeigt den Quelltext zum Updaten eines Datensatzes mit Hilfe vonbenannten Platzhaltern. Zu Beginn der Methode wird eine Verbindung zu einerDatenbank aufgebaut und an die „getUPDATEName()“-Methode übergeben. Die-se erzeugt einen passenden SQL-String mit benannten Platzhaltern, welche sie ausden übermittelten Parametern erzeugt. Als Rückgabewert wird ein Objekt der Klas-se „NamedParameterStatement“ erzeugt (siehe Listing 7.18). Im Anschluss daranmüssen nur noch alle Platzhalter in der Datenbank mit Werten gefüllt werden. Dazuwird die CKMap übergeben. Diese enthält bereits als Schlüssel den Namen der Spal-te sowie den passenden Wert. Das Listing 7.19 zeigt, wie die Werte aus der CKMapgeholt und per Prepared Statement an die Datenbank gesendet werden. Dazu wirdgeprüft, ob der Name eines Platzhalters in der Map vorhanden ist oder nicht. Istdies der Fall, wird der dazugehörende Wert ausgelesen und anhand des Datentypswird ermittelt, welche „set()“-Methode verwendet werden muss. Zum Schluss wirdmit Hilfe von „executeUpdate()“ der Update-Befehl ausgeführt.

Listing 7.17: Auszug aus dem Quellcode zum Updaten von Datenbankeinträgen

1 try {2 lNamedParameterStatement = getUPDATEName (lConnection ,3 mSchemaKampa2 , TABELLE_PHVVHVCS ,4 "versnr = :" + SPALTE_VERSNR ,5 SPALTE_STATUS , SPALTE_BEARBEITUNGSDATUM ,6 SPALTE_TERMIN , SPALTE_STATUS_BESCHREIBUNG ,7 SPALTE_NOTIZ , SPALTE_Z_NAME , SPALTE_Z_VORNAME ,8 SPALTE_Z_USERID , SPALTE_Z_USERKEY );9 lNamedParameterStatement . setCKMap ( pfachlObjekt );

10 lNamedParameterStatement . executeUpdate ();11 } catch ( SQLException e) {12 } finally {13 cleanUpNamedParameterStatement (lConnection ,

lNamedParameterStatement );14 }

Martin Schüler Seite 65 von 85

Page 71: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

Die „getUPDATEName()“-Methode erzeugt aus den übergebenen Parametern zu-nächst einen Update-String. Seit Java fünf können sogenannte Varargs verwendetwerden. Diese ermöglichen es, eine variable Anzahl von Objekten zu übergeben.In dieser Methode wird es für die Übergabe der Spalten, welche einen neuen Wertzugewiesen bekommen, genutzt. Die „for-Schleife“ durchläuft diese Objekte und er-zeugt einen Teil der SQL-Anweisung. Dieser entspricht der Form „Spaltenname =:Spaltenname“ und erzeugt somit einen benannten Platzhalter. Zum Schluss wirdder SQL-String mit Hilfe der restlichen Parameter zusammengesetzt und ein neuesObjekt der Klasse „NamedParameterStatement“ zurückgegeben.

Listing 7.18: Quellcode zum Erzeugen eines Update-Strings

1 StringBuilder values = new StringBuilder ();2 for (String columnName : pColumnNames ) {3 if (values.length () != 0) {4 values.append(",");5 }6 values.append( columnName );7 values.append("= :");8 values.append( columnName );9 }

10 return new NamedParameterStatement (pConn ,("UPDATE " +pSchema + "." + pTableName

11 + " SET " + values. toString () + ( pAuswahlkriterien !=null ? " WHERE "

12 + pAuswahlkriterien : "")));

Listing 7.19: Quellcode zum Setzen von Parametern mit Hilfe einer CKMap

1 for( Iterator itr= indexMap . entrySet (). iterator (); itr.hasNext ();) {

2 Map.Entry entry =( Map.Entry)itr.next ();3 String name = (String) entry.getKey ();4 if(map. containsKey (name)){5 int[] indexes = getIndexes (name);6 Object value = map.get(name);7 if(value == null){8 for(int i=0; i < indexes .length; i++) {9 statement . setString ( indexes [i], null);

10 }11 }else if(value instanceof Text){12 Text valueText = (Text) value;13 if( valueText .equals(Text. EMPTY_TEXT )) {14 for(int i=0; i < indexes .length; i++) {

Martin Schüler Seite 66 von 85

Page 72: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

15 statement . setString ( indexes [i], null);16 }17 } else18 for(int i=0; i < indexes .length; i++) {19 statement . setString ( indexes [i], valueText .

toString ());20 }21 }else if (value instanceof Zahl){22

23 }24 }25 }26 }

7.3 Bewertung der beiden Varianten

Zusammenfassend können beide Alternativen wie folgt bewertet werden:

Für die Umstellung der Web-Anwendung auf Hibernate müssen bei beiden Vari-anten sehr viele Änderungen vorgenommen werden, damit das Hibernate-Konzeptoptimal umgesetzt wird. Des Weiteren müssen Mapping-Klassen für alle Tabellenund Views erstellt werden, damit Daten aus der Datenbank gelesen oder in diesegeschrieben werden können. Die zusätzliche Mapping-Datei für die Views könntedadurch vermieden werden, indem sie innerhalb der Mapping-Klasse der jeweiligenTabellen abgebildet wird. Hierfür müssen jedoch zusätzliche Änderungen vorgenom-men werden. Ein weiteres Problem stellen die eigenen Datentypen innerhalb derWeb-Anwendung dar. Um dieses zu lösen, gibt es ebenfalls zwei Varianten. Die Kon-vertierung zwischen den jeweiligen Datentypen müsste innerhalb von Hibernate inden jeweiligen „Setter“- und „Getter“-Klassen implementiert werden, was wiederumden Implementierungs- und den Testaufwand erhöhen würde. Bei der zweiten Alter-native wird auf die Verwendung der eigenen Datentypen verzichten. Dafür müssenjedoch sehr viele Bereiche der Anwendung geändert werden, da diese nicht nur inder Dialogschicht, sondern auch in vielen Bereichen der Logik, verwendet werden.

Für die Umstellung auf Prepared Statements sind dagegen wesentlich weniger Än-derungen nötig, da sich die Anpassungen lediglich auf die Persistentz-Schicht be-schränken. Zudem stellen die eigenen Datentypen bei dieser Variante kein größeresProblem dar, da im Gegensatz zu der Umstellung auf Hibernate die Konvertierungan einer zentralen Stelle vorgenommen wird.

Martin Schüler Seite 67 von 85

Page 73: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

7. Prototypische Umsetzung Fachhochschule Schmalkalden 2012

Dadurch wird deutlich, dass die Umstellung auf Prepared Statements die besse-re Alternative ist, da weniger Änderungen vorgenommen werden müssen. Um eineabschließende Aussage darüber treffen zu können, wird nachfolgen der Test auf SQL-Injektion und Cross-Site-Scripting wiederholt.

Martin Schüler Seite 68 von 85

Page 74: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

8 Test der prototypischenUmsetzung

In diesem Kapitel wird die prototypische Implementierung mit Hibernate und Pre-pared Statements auf Schwachstellen überprüft. Anschließend wird mit Hilfe vonSelenium ein allgemeiner Funktionstest durchgeführt.

8.1 Sicherheitstest

In diesem Abschnitt werden die Tests aus dem Kapitel 4.3 wiederholt. Hierbei sollgeprüft werden, ob die Manipulationen weiterhin möglich sind. Da bei beiden pro-totypischen Implementierungen (Hibernate und Prepared Statements) die gleichenResultate bezüglich der Sicherheit erzielt wurden, wird an dieser Stelle nur der Tes-tablauf mit Prepared Statements dargestellt.

8.1.1 SQL-Injektion

Anzeigen von SQL-Fehlermeldungen

Die Grafik 8.1 zeigt, dass an keiner Stelle der Web-Anwendung eine Fehlermeldun-gen zurückgegeben wird. Stattdessen wird nach einem Datensatz gesucht, welcherein Semikolon enthält. Da kein passender Eintrag mit diesem Suchkriterium in derDatenbank existiert, werden demzufolge auch keine Daten auf der Übersichtsseiteangezeigt. An dieser Stelle kann man eigentlich schon schlussfolgern, dass auf diesemWeg keine SQL-Injektion mehr möglich ist. Um sicherzugehen, werden die Tests fürdas Anzeigen aller Datensätze sowie für das Verändern von Werten wiederholt.

71Eigene Darstellung

Martin Schüler Seite 69 von 85

Page 75: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

8. Test der prototypischen Umsetzung Fachhochschule Schmalkalden 2012

Abbildung 8.1: Test zum Anzeigen der Fehlermeldung 71

Anzeigen aller Datensätze einer Tabelle

Anhand der Grafik 8.2 kann man erkennen, dass auch an dieser Stelle nach einemDatensatz gesucht wird, welcher den eingegebenen Suchbegriff enthält. Als Nutzerhat man also keine Möglichkeit mehr, dass auch Daten anderer User angezeigt wer-den. Dadurch wird der Schutz der Vertraulichkeit gewährleistet.

Abbildung 8.2: Test zur Manipulation der Suchanfrage 72

Verändern von Werten einer Tabelle

Die Grafik 8.3 wurde nach dem Abspeichern der Werte aufgenommen. Vor der Um-stellung auf Prepared Statements wurde der Wert des Feldes „Strasse“ überschrie-ben. Nun wird die Eingabe als Notiz gespeichert und verändert kein anderes Feldin der Datenbank. Dies zeigt, dass auch an dieser Stelle keine SQL-Injektion mehrmöglich ist.

72Eigene Darstellung73Eigene Darstellung

Martin Schüler Seite 70 von 85

Page 76: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

8. Test der prototypischen Umsetzung Fachhochschule Schmalkalden 2012

Abbildung 8.3: Notizfeld der Web-Anwendung nach dem Abspeichern 73

8.1.2 Cross-Site Scripting

Im Gegensatz zu dem erfolgreich verlaufenen Test für SQL-Injektion, ist Cross-SiteScripting weiterhin möglich. Die Vorgehensweise dafür ist nach der Umstellung aufPrepared Statements jedoch eine andere. In dem Test aus Kapitel 4.3 wurde das Feld„Strasse“ mit einem Schadcode versehen. Da dies nicht mehr manipuliert werdenkann, wird der Code als Text in dem Notizfeld angezeigt. Das Bild 8.3 verdeutlicht,dass es keine Auswirkungen auf die Web-Anwendung besitzt. Durch eine Änderungdes Eingabetextes kann die „XSS“-Attacke dennoch ausgeführt werden. Dazu wirddem Code ein schließendes „Textareas“-Tag vorangestellt. Dadurch interpretiert derBrowser die es nicht mehr als Text des Notizfeldes, sondern führt den nachfolgendenCode aus, wie man aus der Grafik 8.4 erkennen kann.

Abbildung 8.4: XSS-Attacke mit Prepared Statements 74

8.1.3 Bewertung

Anhand des durchgeführten Tests kann festgestellt werden, dass die Umstellungauf Prepared Statements oder auf Hibernate zu einer Steigerung der IT-Sicherheitbeitragen. Die Ergebnisse der beiden Varianten unterscheidet sich dabei nicht. Aus

74Eigene Darstellung

Martin Schüler Seite 71 von 85

Page 77: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

8. Test der prototypischen Umsetzung Fachhochschule Schmalkalden 2012

diesem Grund wurde in diesem Abschnitt nur das Ergebnis für Prepared Statementsdargestellt.

Zusammenfassend kann gesagt werden, dass beide Varianten SQL-Injektion ver-hindern, jedoch für Cross-Site Scripting ein weiterer Schutz notwendig wird. Ausdiesem Grund ist für die Web-Anwendung die Umstellung auf Prepared Statementsdie bessere Variante, da bei gleicher Sicherheit weniger Änderungen vorgenommenwerden.

8.2 Automatisierter Test mit Selenium

Das Unternehmen Inverso GmbH suchte nach einer Möglichkeit, alle umgestelltenKampagnen automatisiert zu testen. Dadurch soll zum einen sichergestellt werden,dass durch die Implementierung keine Fehler in den umgestellten Kampagnen vor-handen sind. Zudem soll der Entwickler dieses Testverfahren auch in Zukunft einset-zen können, um sicherzustellen, dass Änderungen am Quellcode keine Auswirkungenauf die anderen Kampagnen haben. Hierfür ist ein automatisierter Test besondersvon Vorteil, da die Programmierer keine Zeit haben, um alle Funktionen der Kam-pagnen zu testen.

Abbildung 8.5: Testfälle mit Selenium 75

Für das automatisierte Testverfahren wird das Oberflächentool Selenium verwendet,welches die Möglichkeit bietet, Tests direkt auf der Oberfläche durchzuführen. Esgibt zwei verschiedene Arten, Selenium einzusetzen. Zum einen kann es als Browser-

75Eigene Darstellung

Martin Schüler Seite 72 von 85

Page 78: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

8. Test der prototypischen Umsetzung Fachhochschule Schmalkalden 2012

Plugin eingesetzt werden, wo man im Vorfeld den Test manuell aufzeichnen muss.Dieses Verfahren bietet jedoch keine Möglichkeiten, logische Auswertung der Inhalteoder andere Operationen auszuführen. Dies wird jedoch von der anderen Varianteunterstützt, da Selenium innerhalb eines JUnit-Test verwendet wird.

Die Schwierigkeit bei der Erstellung eines allgemeingültigen Tests, war vor allem derunterschiedliche Aufbau der einzelnen Kampagnen. In der Web-Anwendung gibt esmomentan noch zwei Arten von Kampagnen-Frameworks (alt und neu), welche vondem Testfall abgedeckt werden müssen. In dem nachfolgenden Listing 8.1 werdendie Grundfunktionen einer Kampagne mit neuem Framework getestet. Dies betrifftdas Setzen eines Versanddatums für Kampagnen. Die Abbildung 8.5 zeigt einenlaufenden Selenium-Test.

Listing 8.1: Auszug aus einem Selenium-Testfall für das Setzen eines Versanddatums

1 String [] strPath = {" Kampagnen ", "alle oeffnen ","//a[@id=’"+id+" ’]"};

2 try {3 NavigateTo ( strPath );4 } catch ( Exception e) {5 strErgebnis = KampaName +" konnte nicht geoeffnet

werden! " + e;6 }7 if ( strErgebnis .length () >0) {8 fail( strErgebnis );9 }

10 selenium .click("// IMG[@id = ’3000 ’]");11 selenium . waitForPageToLoad ("90000");12 int i = 1;13 List <String > versandDatum = new ArrayList <String >();14 String tmpSpalte ;15 String tmpValue ;16

17 try {18 while( selenium . isElementPresent ("// table/tbody/tr [9]/ td

[2]/ table/tbody/tr [2]/ td["+i+"]")){19 if(i==1){20 tmpSpalte = selenium . getText ("// table/tbody/tr [9]/ td

[2]/ table/tbody/tr/td/a/b").trim ();21 tmpValue = selenium . getText ("// table/tbody/tr [9]/ td

[2]/ table/tbody/tr [2]/ td").trim ();22 }23 if( tmpSpalte .equals("Versand -\n datum") | tmpSpalte .

equals("Versand -\ ndatum")){

Martin Schüler Seite 73 von 85

Page 79: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

8. Test der prototypischen Umsetzung Fachhochschule Schmalkalden 2012

24 for(int x = 0; x <25; x++){25 if( selenium . isElementPresent ("// table/tbody/tr [9]/

td [2]/ table/tbody/tr["+(x+2)+"]/td["+i+"]")){26 tmpValue = selenium . getText ("// table/tbody/tr [9]/

td [2]/ table/tbody/tr["+(x+2)+"]/td["+i+"]").trim ();

27 versandDatum .add( tmpValue );28 }29

30 }31 break;32 }33 i++;

Martin Schüler Seite 74 von 85

Page 80: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

9 Abschließende Betrachtungen

In diesem Abschnitt findet die Zusammenfassung der Resultate, eine Bewertungdieser Ergebnisse sowie einen Ausblick der Arbeit statt.

9.1 Zusammenfassung

Ziel dieser Arbeit war es, für die Web-Anwendung der Firma Inverso GmbH ein Kon-zept gegen SQL-Injektion zu entwickeln. Dafür wurde zu Beginn dieser Arbeit dieBedeutung der IT-Sicherheit, die möglichen Folgen aus einem erfolgreichen Angriff,sowie die zwei gefährlichsten Sicherheitslücken dargestellt. Um ein Konzept gegenSQL-Injektion erstellen zu können, musste zunächst die Web-Anwendung diesbezüg-lich untersucht werden. Dabei lag ein besonderes Augenmerk darauf, welche Vorkeh-rungen bereits getroffen wurden, sowie wo mögliche Schwachstellen noch existierenkönnten. Die daraus resultierenden Ergebnisse wurden in dem Bedrohungsszenarioverwendet, um Schwachstellen innerhalb der Anwendung aufzudecken.

Anschließend wurden verschiedene Konzepte vorgestellt, wie diese Sicherheitslückengeschlossen werden könnten. Aufgrund der Randbedingungen (Sicherheit, Kosten)fiel die Entscheidung zugunsten der Prepared Statements aus. Da die Inverso GmbHjedoch die Arbeit mit dem Ziel der Umstellung auf Hibernate in Auftrag gegebenhatte, wurde dies zusätzlich in der prototypischen Umsetzung berücksichtigt. Damitsollte herausgefunden werden, welche der beiden Konzepte besser geeignet ist. Zumbesseren Verständnis wurde Hibernate im sechsten Kapitel genauer beschrieben.

Die prototypische Umsetzung von Hibernate und Prepared Statements wurde imsiebten Abschnitt dargestellt. Aus der Umsetzung der beiden Varianten resultiertdie Feststellung, dass Prepared Statements aufgrund geringeren Implementierungs-aufwand bei gleichen Sicherheitsniveau besser geeignet sind.

Um die Aussage mit dem Sicherheitsniveau bekräftigen zu können, wurde anschlie-ßend geprüft, ob SQL-Injektion weiterhin möglich ist. Da bei beiden Umsetzungs-möglichkeiten die selben Resultate erzielt wurden, konnte dies bestätigt werden.

Martin Schüler Seite 75 von 85

Page 81: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

9. Abschließende Betrachtungen Fachhochschule Schmalkalden 2012

9.2 Bewertung

Abschließend kann gesagt werden, dass mit Hilfe dieser Arbeit SQL-Injektion ver-mieden werden können. Dafür wurde die Variante mit der Umstellung auf Hibernatemit der auf Prepared Statements verglichen. Der auschlaggebende Grund für die ver-wendete Variante war der geringere Implementierungsaufwand bei gleichem Nutzen.Im Rahmen dieser Arbeit wurde die Umstellung für den gesamten Kampagnen-Bereich vollzogen. Die restlichen bestehenden Teile der Web-Anwendung werdennach und nach umgestellt und neue Funktionen werden mit Prepared Statementsimplementiert.

Sobald die Web-Anwendung komplett auf Prepared Statements umgestellt wurde,könnte der Request Validator so angepasst werden, dass Cross-Site Scripting weiter-hin verhindert wird, jedoch zu einer Steigerung der Usibility führt. Dafür müsstennicht mehr alle Sonderzeichen blockiert werden, sondern es würde reichen bestimmteKombinationen an Zeichen, welche typisch für Cross-Site Scripting-Attacken sind,zu verbieten. Ein anderer Ansatz wird kurz im nachfolgenden Abschnitt erläutert.

9.3 Ausblick

Mit Hilfe dieser Arbeit konnte ein Konzept entwickelt werden, welches, wenn es inder kompletten Anwendung implementiert wird, zur Steigerung der IT-Sicherheitbeiträgt. Im Laufe der prototypischen Implementierung wurde die Umstellung vonPrepared Statements nur im Kampagnen-Bereich der Anwendung vorgenommen.Die restlichen Abschnitte der Web-Anwendung werden nach und nach umgestellt,sobald der Entwickler Änderungen in diesem Bereich durchführt. Bei Neuentwick-lungen werden Prepared Statements direkt für Datenbankabfragen eingesetzt.

Wie bereits durch den Test der prototypischen Umsetzung ermittelt wurde, ist Cross-Site Scripting weiterhin möglich. Hierfür muss in naher Zukunft ein Konzept zurVermeidung dieser Attacken erstellt werden. Ein sehr erfolgversprechender Ansatzkönnte in diesem Zusammenhang das „Escapen“ der Ein- und Ausgaben sein. Hier-für könnte ein Filter im WebSphere implementiert werden, welcher alle Requestsvor dem Ausführen der Anwendung entsprechend umwandelt. Ein anderer Ansatzhierfür wäre ein Umbau des bereits bestehenden Request Validators. Da in einemAbschnitt der Anwendung weiterhin HTML-Elemente übermittelt werden müssen,könnte entweder die Umwandlung für diesen Bereich abgeschaltet werden oder manverbietet solche HTML-Elemente, welche für Cross-Site Scripting notwendig sind.

Martin Schüler Seite 76 von 85

Page 82: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

9. Abschließende Betrachtungen Fachhochschule Schmalkalden 2012

Entscheidet man sich für die Blacklist-Variante muss man regelmäßig überprüfen,ob die Liste noch den aktuellen Sicherheitsmaßnahmen entspricht. Erst wenn gegenCross-Site Scripting ein passendes Konzept erstellt und umgesetzt wurde, kann dieUsibility für den Anwender erhöht werden.

Martin Schüler Seite 77 von 85

Page 83: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

Literaturverzeichnis

[AB01] Andrea Back, Jorg Becker und Wolfgang K.: Lexikon der Wirtschaftsin-formatik. Springer-Verlag, 2001

[Bee06] Beeger, Robert F.: Hibernate - Persistenz in Java-Systemen mit Hibernate3. dpunkt-Verlag, 2006

[Bet] Betz, Johann: Sicherheitsaspekte in Kommunikationsnetzen Sicherheitsa-spekte in Kommunikationsnetzen SQL Injection. www.ks.uni-freiburg.de, Abruf: 10.11.2011

[Bre] Breitner, Caroline Neufert; Michael H.: Mit Zertifizierungen in einesicherere Informationsgesellschaft. http://www.iwi.uni-hannover.de/publikationen/IWIDP10k.pdf, Abruf: 07.11.2011

[Buna] Bundesamt für Sicherheit in der Informationstechnik: BSI-Standard 100-2. https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/ITGrundschutzstandards/standard_1002_pdf.pdf?__blob=publicationFile, Abruf: 22.12.2011

[Bunb] Bundesamt für Sicherheit in der Informationstechnik: IT-Grundschutz-Kataloge. https://gsb.download.bva.bund.de/BSI/ITGSK12EL/IT-Grundschutz-Kataloge-12-EL.pdf, Abruf: 07.11.2011

[Bunc] Bundesamt für Sicherheit in der Informationstechnik: Lage-bericht 2007. https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Lageberichte/lagebericht2007_pdf.pdf?__blob=publicationFile, Abruf: 09.02.2012

[Bund] Bundesamt für Sicherheit in der Informationstechnik: Leitfa-den der Informationssicherheit. https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Leitfaden/GS-Leitfaden_pdf.pdf?__blob=publicationFile, Abruf: 07.11.2011

Martin Schüler78

Page 84: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

Literaturverzeichnis Fachhochschule Schmalkalden 2012

[Bune] Bundesamt für Sicherheit in der Informationstechnik: Si-cherheit von Webanwendungen. https://www.bsi.bund.de/cae/servlet/contentblob/476464/publicationFile/30632/WebSec_pdf.pdf, Abruf:05.01.2012

[ConoA] Contentmanager.de: Content Management Systeme im Überblick.http://img.contentmanager.de/download/contentmanager_ebook_opensource_cms.pdf. Version: o.A.

[Cru] Crume, Adam: Named Parameters for PreparedStatement.http://www.javaworld.com/javaworld/jw-04-2007/jw-04-jdbc.html,Abruf: 06.01.2012

[dou] doubleSlash Net-Business GmbH: Java-Persistenz mit Hiber-nate. http://blog.doubleslash.de/wp-content/uploads/2007/03/java-persistenz-mit-hibernate.pdf, Abruf: 12.03.2012

[Har] Harlan, Gregor: Testframework Selenium. http://www1.inf.tu-dresden.de/~rm1/Belege/Selenium.pdf, Abruf: 04.04.2012

[Höl] Hölterhoff, Marc: Web Application Security. http://it-republik.de/jaxenter/artikel/Web-Application-Security-2615.html, Abruf:01.11.2011

[Hor] Horn, Torsten: SQL mit Java. http://www.torsten-horn.de/techdocs/java-sql.htm, Abruf: 01.11.2011

[IBM] IBM: Rational Application Developer Standard Edition for Web-Sphere Software. http://www-142.ibm.com/software/products/de/de/ratiappldevestaneditforwebssoft/, Abruf: 09.02.2012

[Inva] Inverso GmbH: Architektur der Web-Anwendung - internes Dokument

[Invb] Inverso GmbH: Daten und Fakten. http://www.inverso.de/inverso/unternehmen/datenundfakten/index.html, Abruf: 02.01.2012

[Invc] Inverso GmbH: Projekte. http://www.inverso.de/inverso/projekte/index.html, Abruf: 02.01.2012

[Lif] Lift: Lift::Home. http://liftweb.net/, Abruf: 04.04.2012

[o.A] o.A.: Seven Things. http://seventhings.liftweb.net/security, Abruf:04.04.2012

Martin Schüler79

Page 85: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

Literaturverzeichnis Fachhochschule Schmalkalden 2012

[ORD] ORDIX AG: Caching in Hibernate. http://www.ordix.de/ORDIXNews/3_2006/JavaXML/hibernate.html, Abruf: 23.02.2012

[OWA] OWASP: Die 10 häufigsten Sicherheitsrisiken für Webanwendun-gen. https://www.owasp.org/images/b/b8/OWASPTop10_DE_Version_1_0.pdf, Abruf: 10.11.2011

[Rey05] Rey, Michael; Baier D. Enno; Thumann T. Enno; Thumann: Mehr IT-Sicherheit durch Pen-Tests. Vieweg Verlag, 2005

[Sch] Schmidtmann, Achim: IT-Sicherheit. http://www.sicherheitsthemen.de/it-sicherheit.php, Abruf: 16.11.2011

[Tec] Tecchhannel.de: Web Application Firewalls - Grundlagen und Markt-übersicht. http://www.tecchannel.de/bild-zoom/2019855/3/939817/d2e128-media/, Abruf: 13.01.2012

[The] The PHP Group: Prepared Statements und Stored Procedures. http://php.net/manual/de/pdo.prepared-statements.php, Abruf: 04.04.2012

[Töl] Töllner, Christian: IT Sicherheit - Grundlagen Teil2. http://www.ana-be.de/index.php/IT-Sicherheit/IT-Sicherheit-Grundlagen-Teil-2.html, Abruf: 20.04.2012

[Ull] Ullenboom, Christian: Java ist auch eine Insel - Kapitel 25. http://openbook.galileocomputing.de/javainsel9/javainsel_25_001.htm,Abruf: 09.01.2012

[Vul] Vulnerability Lab: Cross Site Scripting. http://www.vulnerability-lab.com/resources/documents/198.pdf, Abruf:01.11.2011

[WEK] WEKA MEDIA GmbH: ACID-Prinzip. http://www.weka.de/datenschutz/4750747-ACID-Prinzip.html, Abruf: 09.01.2012

[Wol] Wolff, Tanja: Die größten Gefahren Die größten Gefahren:5 IDC-Ratschläge für mehr IT-Sicherheit. http://www.cio.de/knowledgecenter/security/2255199/index.html, Abruf: 09.02.2012

Martin Schüler80

Page 86: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

Abbildungsverzeichnis

2.1 Logische Komponenten der Web-Anwendung . . . . . . . . . . . . . . 82.2 Schematische Darstellung der Kopplung von OpenCMS und der Web-

Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Bedeutung der verschiedenen Gefahrenbereiche . . . . . . . . . . . . . 133.2 Konsequenzen aus Angriffen auf die IT-Sicherheit von Firmen . . . . 143.3 Erstellung des Sicherheitskonzeptes . . . . . . . . . . . . . . . . . . . 163.4 Top zehn Risiken für die Anwendungssicherheit aus dem Jahr 2010 . 19

4.1 Fehlermeldung vom Request-Validator . . . . . . . . . . . . . . . . . 254.2 SQL-Fehlermeldung der Datenbank . . . . . . . . . . . . . . . . . . . 274.3 Zwölf Datensätze ohne SQL-Injektion . . . . . . . . . . . . . . . . . . 274.4 Datensätze mit SQL-Injektion . . . . . . . . . . . . . . . . . . . . . . 284.5 Datensatz ohne SQL-Injektion . . . . . . . . . . . . . . . . . . . . . . 294.6 Datensatz mit SQL-Injektion . . . . . . . . . . . . . . . . . . . . . . . 294.7 XSS-Attacke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.8 Fehlermeldung von der DB2-Datenbank . . . . . . . . . . . . . . . . . 30

5.1 Aufbau einer Web Application Firewall . . . . . . . . . . . . . . . . . 33

6.1 Objektzustände von Hibernate . . . . . . . . . . . . . . . . . . . . . . 406.2 Beispiel einer User-Tabelle . . . . . . . . . . . . . . . . . . . . . . . . 406.3 Darstellung des Hibernate-Caches . . . . . . . . . . . . . . . . . . . . 46

7.1 Sequenzdiagramm der CKMap . . . . . . . . . . . . . . . . . . . . . . 52

8.1 Test zum Anzeigen der Fehlermeldung . . . . . . . . . . . . . . . . . 708.2 Test zur Manipulation der Suchanfrage . . . . . . . . . . . . . . . . . 708.3 Notizfeld der Web-Anwendung nach dem Abspeichern . . . . . . . . . 718.4 XSS-Attacke mit Prepared Statements . . . . . . . . . . . . . . . . . 718.5 Testfälle mit Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Martin Schüler81

Page 87: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

Tabellenverzeichnis

3.1 Einteilung des Schutzbedarfs . . . . . . . . . . . . . . . . . . . . . . . 17

5.1 Präferenzmatrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.2 Nutzwertanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Martin Schüler82

Page 88: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

Listings

3.1 Beispiel einer Java-Methode für ein Login . . . . . . . . . . . . . . . . 203.2 Beispiel für Select-Anweisungen für SQL-Injektion . . . . . . . . . . . 213.3 Beispiel für Update-Anweisungen für SQL-Injektion . . . . . . . . . . 213.4 SQL-Injektion zum Lesen der passwd-Datei . . . . . . . . . . . . . . . 223.5 Beispielcode für Cross-Site Scripting . . . . . . . . . . . . . . . . . . 23

4.1 Verwendete SQL-Befehle um Daten zu anzuzeigen . . . . . . . . . . . 274.2 Verwendete SQL-Befehle um Daten zu ändern . . . . . . . . . . . . . 28

5.1 Beispiel für eine Prepared Statement-Anweisung . . . . . . . . . . . . 34

6.1 XML-Mapping-Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . 416.2 Getter- und Setter-Klasse . . . . . . . . . . . . . . . . . . . . . . . . 416.3 Mapping-Klasse mit Annotations . . . . . . . . . . . . . . . . . . . . 426.4 Codebeispiel für eine HQL-Anweisung . . . . . . . . . . . . . . . . . . 446.5 Codebeispiel für eine Abfrage mit Criteria . . . . . . . . . . . . . . . 45

7.1 Die Konfigurationsdatei von Hibernate (Hibernate.cfg.xml) . . . . . . 497.2 Aufbau der Datei Hibernateutil . . . . . . . . . . . . . . . . . . . . . 507.3 Auszug aus der Mapping-Datei mit Annotations . . . . . . . . . . . . 517.4 Beispiel für HQL-Anweisungen in den Mapping-Dateien . . . . . . . . 537.5 Änderungen an der CKFactory . . . . . . . . . . . . . . . . . . . . . 547.6 Umwandlung des Hibernate-Objektes . . . . . . . . . . . . . . . . . . 547.7 Auszug aus dem Quellcode der updateKampa()-Methode . . . . . . . 557.8 Änderungen in der Dialog-Schicht . . . . . . . . . . . . . . . . . . . . 577.9 Beispiel für eine Prepared Statement-Anweisung . . . . . . . . . . . . 597.10 Beispiel für eine Prepared Statement-Anweisung mit benannten Pa-

rametern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.11 Quellcode der NamedParameterStatement-Methode 76 . . . . . . . . . 607.12 Auszug aus der parse()-Methode 77 . . . . . . . . . . . . . . . . . . . 617.13 Beispiel für eine Methode zum Setzen von Parametern 78 . . . . . . . 61

Martin Schüler83

Page 89: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

Listings Fachhochschule Schmalkalden 2012

7.14 Auszug aus der Methode getResultsetBestandUebersicht() . . . . . . 637.15 Auszug aus der Methode getWhereKlauselSuchbegriff . . . . . . . . . 647.16 Auszug aus der Methode setNamedMap . . . . . . . . . . . . . . . . . 647.17 Auszug aus dem Quellcode zum Updaten von Datenbankeinträgen . . 657.18 Quellcode zum Erzeugen eines Update-Strings . . . . . . . . . . . . . 667.19 Quellcode zum Setzen von Parametern mit Hilfe einer CKMap . . . . 66

8.1 Auszug aus einem Selenium-Testfall für das Setzen eines Versanddatums 73

Martin Schüler84

Page 90: Konzept zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion am Beispiel einerWeb-Anwendung

Eidesstattliche Erklärung

Ich versichere an Eides Statt durch meine eigenhändige Unterschrift, dass ich dievorliegende Arbeit selbstständig und ohne fremde Hilfe angefertigt habe. Alle Stel-len, die wörtlich oder dem Sinn nach auf Publikationen oder Vorträgen andererAutoren beruhen, sind als solche kenntlich gemacht. Ich versichere außerdem, dassich keine andere als die angegebene Literatur verwendet habe. Diese Versicherungbezieht sich auch auf alle in der Arbeit enthaltenen Zeichnungen, Skizzen, bildlichenDarstellungen und dergleichen.

Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch nochnicht veröffentlicht.

Gorsleben,den 30.04.2012

Ort, Datum Martin Schüler

Martin Schüler85