Konzept Zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion Am Beispiel einerWeb-Anwendung

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 -
Fakultt Informatik Referent: Prof. Dr. Oliver Braun Korreferent: Dipl.-Inf.(FH) Ren Brothuhn Eingereicht von: Martin Schler Matr.-Nr. 260257 Dorfstrae 28 06577 Gorsleben Schmalkalden, den 30.04.2012
Danksagung An dieser Stelle mchte ich mich bei meinen Eltern Silvia und Dieter Schler sowie meiner Schwester Anika Schler und meiner Lebenspartnerin Mandy Schrickel bedanken. Sie haben mich whrend der ganzen Zeit untersttzt, mir den Rcken freigehalten und mich selbst bei Rckschlgen wieder aufgebaut. Ein besonderer Dank gilt hierbei meinen Eltern, ohne die dieses Studium nicht mglich gewesen wre. Des Weiteren mchte ich mich bei der Firma Inverso GmbH bedanken, welche es erst ermglichte, dieses Thema zu bearbeiten, und mir dabei ber den gesamten Zeitraum untersttzend 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 bereit war, sich als Betreuer dieser Arbeit zur Verfgung zu stellen, und mich whrend des gesamten Zeitraums sehr gut untersttzt hat. Zum Schluss mchte ich mich bei Ren Brothuhn bedanken, der sofort bereit war, mich als Korreferent zu betreuen.
Inhaltsverzeichnis
1 Einleitung 1.1 Motivation . . . . . 1.2 Problemstellung . . 1.3 Zielsetzung . . . . 1.4 Abgrenzung . . . . 1.5 Aufbau der Arbeit 1 1 2 2 3 3 5 5 6 6 7 9 10 10 10 10 11 11 12 12 14 16 18 18 18 23
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
2 Grundlagen 2.1 Das Unternehmen Inverso GmbH . . . . 2.2 Die Web-Anwendung . . . . . . . . . . . 2.2.1 Zweck der Web-Anwendung . . . 2.2.2 Architektur der Web-Anwendung 2.3 OpenCMS . . . . . . . . . . . . . . . . . 2.4 Structured Query Language . . . . . . . 2.5 Java Database Connectivity . . . . . . . 2.6 Java Reection . . . . . . . . . . . . . . 2.7 Rational Application Developer . . . . . 2.8 ACID-Prinzip . . . . . . . . . . . . . . . 2.9 Selenium . . . . . . . . . . . . . . . . . . 3 Die 3.1 3.2 3.3 3.4 3.5
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
Informationssicherheit Denition und Zielsetzung . . . . . . . . . . . . . . . . . Kern-Schutzziele der Informationssicherheit . . . . . . . . Sicherheitskonzept fr eine Softwareanwendung . . . . . Ermittlung von Sicherheitslcken durch Penetrationstest Sicherheitslcken in Web-Anwendungen . . . . . . . . . . 3.5.1 SQL-Injektion . . . . . . . . . . . . . . . . . . . . 3.5.2 Cross-Site Scripting . . . . . . . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Martin Schler
II
Inhaltsverzeichnis 4 Aktueller Stand der Anwendung 4.1 Vorhandene Sicherheitsmechanismen 4.1.1 Request-Validator . . . . . . . 4.1.2 Authentizierung . . . . . . . 4.1.3 Autorisierung . . . . . . . . . 4.2 Bedrohungsszenarien . . . . . . . . . 4.2.1 SQL-Injektion . . . . . . . . . 4.2.2 Cross-Site Scripting . . . . . . 4.2.3 Analyse der Ergebnisse . . . . 5 Konzepte zur Absicherung 5.1 Web Application Firewall . . . . 5.2 Object-Relational Mapping-Tools 5.3 Prepared Statements . . . . . . . 5.4 Neuentwicklung . . . . . . . . . . 5.5 Bewertung . . . . . . . . . . . . .
Fachhochschule Schmalkalden 2012 24 24 24 25 25 26 26 29 30 32 32 33 34 35 36 39 39 40 41 42 44 44 44 45 45 46 46 48 48 48 51 52 58 59 62
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
6 Das OR-Mapper Tool Hibernate 6.1 Objektzustnde in Hibernate . . . . . . 6.2 Mapping-Dateien . . . . . . . . . . . . 6.2.1 Mapping mit XML-Dokumenten 6.2.2 Mapping mit Annotations . . . 6.3 Datenbankabfragen . . . . . . . . . . . 6.3.1 Hibernate Query Language . . . 6.3.2 Abfragen mit Criteria . . . . . . 6.4 Cache-Methoden in Hibernate . . . . . 6.4.1 First-Level-Cache . . . . . . . . 6.4.2 Second-Level-Cache . . . . . . . 6.5 Connection-Pool . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
7 Prototypische Umsetzung 7.1 Umsetzung mit Hibernate . . . . . . . . . . . 7.1.1 Konguration von Hibernate . . . . . . 7.1.2 Datenbankmapping mit Annotations . 7.1.3 nderung des bestehenden Java-Codes 7.2 Einsatz von Prepared Statements . . . . . . . 7.2.1 NamedParameterStatement-Klasse . . 7.2.2 Setzen von Werten . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Martin Schler
III
Inhaltsverzeichnis
Fachhochschule Schmalkalden 2012
7.3
7.2.3 nderungen bei Select-Anweisungen . . . . . . . . . . . . . . 62 7.2.4 nderungen bei Update-Befehlen . . . . . . . . . . . . . . . . 65 Bewertung der beiden Varianten . . . . . . . . . . . . . . . . . . . . . 67 69 69 69 71 71 72 75 75 76 76 78 85
8 Test der prototypischen Umsetzung 8.1 Sicherheitstest . . . . . . . . . . . . 8.1.1 SQL-Injektion . . . . . . . . 8.1.2 Cross-Site Scripting . . . . . 8.1.3 Bewertung . . . . . . . . . . 8.2 Automatisierter Test mit Selenium
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
9 Abschlieende Betrachtungen 9.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literaturverzeichnis Eidesstattliche Erklrung
Martin Schler
IV
1 Einleitung
1.1 Motivation
Diese Masterarbeit entsteht in Zusammenarbeit mit der Firma Inverso GmbH, dessen Sitz sich in Ilmenau bendet. Dieses stellt individuelle IT-Lsungen fr verschiedene Finanzdienstleister her. Die einzelnen Anwendungen werden auf die spezischen Bedrfnisse der jeweiligen Kunden abgestimmt. Eines der wichtigsten Anforderungen ist dabei die Sicherheit der Programme und vor allem der Schutz von sensiblen Kundendaten. Diese Prmisse ist generell im laufe der geschichtlichen Entwicklung des Internets immer wichtiger geworden. Durch die zunehmende Digitalisierung, welche vor allem durch die strkere Vernetzung von IT-Systemen, sowie die immer leistungsfhigeren Netze gefrdert wird, hat das Internet sowohl im privaten Haushalten als auch fr Unternehmen eine zentrale Rolle eingenommen. So werden immer mehr Geschftsprozesse als Web-Anwendung in das Internet verlagert, welche lngst ber die reine Suche von Informationen hinausgehen. So knnen Beispielsweise Vertrge ber das Internet abgeschlossen, Kunden verwaltet oder berweisungen gettigt werden. Dieser Trend der Digitalisierung wird auch in Zukunft weiter anhalten, da durch den stndigen und immer strkeren Wandel der Technologien, neue Funktionen und Dienste entstehen. Dies wiederum fhrt schon heute zu einer starken Abhngigkeit von diesem Medien. Wie stark diese ist, wird jedoch erst bei einem Ausfall des jeweiligen Systems bemerkt. Im privaten Umfeld ist der daraus resultierende Schaden in den meisten Fllen verschwindend gering. Dagegen kann der Ausfall eines Systems fr ein Unternehmen einen nanziellen Verlust darstellen, da zum Beispiel Mitarbeiter ihre Arbeit nicht verrichten knnen. Neben den Schutz der IT-Systeme vor Ausfllen, spielt auch der Schutz der verarbeiten Informationen eine wichtige Rolle. Denn die zunehmende Digitalisierung bringt nicht nur Konsumenten zum Vorschein, welche eine Anwendung gem ih-
Martin Schler
Seite 1 von 85
1. Einleitung
res Zwecks verwendet, sondern auch solche Nutzer mit kriminellen Gedanken. Diese versuchen durch Sicherheitslcken von IT-Systemen oder von Web-Anwendungen an sensible Daten zu gelangen. Gerade fr Unternehmen kann dies zu einem enormen nanziellen Schaden fhren. Wie wichtig das Thema IT-Sicherheit in unserer heutigen Gesellschaft ist, kann man auch an der Einrichtung des Bundesamt fr Sicherheit in der Informationstechnik erkennen (kurz BSI). Diese stellt Methoden und Vorgehensweisen fr zur Verfgung, welche ausschlielich den Schutz von IT-Systemen, sowie der dabei verwendeten Informationen dienen. Dabei hat sich die BSI als Ziel gesetzt, schnell und exibel auf vernderte Rahmenbedingungen zu reagieren. Aus diesen vorhergehenden Grnden, ist die Firma Inverso GmbH daran Interessiert, dass ihre Anwendung ein hohes Ma an Sicherheit haben und eventuelle Schwachstellen so schnell wie mglich geschlossen werden.
1.2 Problemstellung
Bei der Erstellung des Konzeptes sowie bei der prototypischen Umsetzung muss ein Weg gefunden werden, die Benutzerfreundlichkeit und die Sicherheit der Anwendung gleichermaen zu erhhen. Um dies zu gewhrleisten muss im Rahmen dieser Arbeit ein Konzept erstellt werden, dass die Eingabe aller Sonderzeichen zulsst und gleichzeitig SQL-Injektion verhindert. Derzeit werden Sonderzeichen konsequent herausgeltert, was zu einer Steigerung der IT-Sicherheit fhrt, aber den Anwender bei der Verwendung der Web-Anwendung stark einschrnkt.
1.3 Zielsetzung
Ziel dieser Arbeit ist es, die Web-Anwendung auf Sicherheitslcken zu berprfen. Dabei sollen verschiedene Bedrohungsszenarien, mit besonderem Schwerpunkt auf SQL-Injektion, entwickelt und entsprechend ihres Risikos analysiert werden. Hierfr ist ein Konzept zu erstellen, welches die gefundenen Lcken schliet, aber gleichzeitig die Benutzerfreundlichkeit der Anwendung erhht. Anschlieend soll dieses Konzept prototypisch umgesetzt und erneut auf Schwachstellen anhand des Bedrohungsszenarios getestet werden.
Martin Schler
Seite 2 von 85
1. Einleitung
1.4 Abgrenzung
Diese Arbeit beschftigt sich ausschlielich mit der Sicherheitslcke SQL-Injektion. Zustzlich wird geprft, ob innerhalb der Anwendung die Mglichkeit von XSSAttacken besteht. Sind diese mglich, wird innerhalb dieser Arbeit jedoch kein Konzept zur Vermeidung von Cross-Site Scripting entwickelt. Die prototypische Implementierung des erarbeiteten Konzeptes beschrnkt sich in dieser Arbeit auf den Abschnitt Kampagnen. Die restliche Umstellung geschieht auerhalb dieser Arbeit. Aus Grnden des Datenschutzes werden alle Graken innerhalb dieser Arbeit anonymisiert dargestellt. Zudem werden in den dargestellten Listings alle Informationen zu Datenbanken, Tabellen und Benutzern verfremdet. Auerdem mchte das Unternehmen, dass aus Sicherheitsgrnden nicht der Name der Web-Anwendung genannt wird.
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 WebAnwendung vorgestellt. Des Weiteren werden bentigte Grundlagen der Arbeit kurz vorgestellt. Der dritten Absatz beschftigt sich mit dem Begri der Informationssicherheit sowie dessen Bedeutung; dazu gehrt die Vorstellung der drei Kernschutzziele. Anschlieend wird errtert, welche Schritte zu einem Sicherheitskonzept gehren. Im weiteren Verlauf werden Sicherheitslcken von Web-Anwendungen beschrieben. Im Kapitel vier wird der Ist-Zustand der Web-Anwendung bezglich der Sicherheit analysiert. Zu Beginn wird geprft, welche Manahmen zur Vermeidung von Sicherheitslcken bereits in der Web-Anwendung vorhanden sind. Anschlieend wird die Web-Anwendung nach weiteren Schwachstellen untersucht, welche nachfolgend nher analysiert werden sollen. Im fnften Abschnitt werden verschiedene Konzepte vorgestellt, welche die Sicherheit der Web-Anwendung erhhen und somit die aus dem vierten Kapitel entdeckten Schwachstellen schlieen sollen. Im Anschluss daran werden die einzelnen Varian-
Martin Schler
Seite 3 von 85
1. Einleitung
ten miteinander verglichen. Dadurch soll festgestellt werden, ob die Umstellung auf einen Persistenz Leyer die bessere Variante ist. Von dem Unternehmen wird die Umstellung auf Hibernate favorisiert. Aus diesem Grund wird in dem sechsten Abschnitt Hibernate als Persistenz Leyer nher vorgestellt. Im siebten Absatz wird die eigentliche prototypische Implementierung der optimalen Varianten nher erlutert. In Kapitel acht wird die prototypische Implementierung bezglich ihrer Sicherheit getestet. Anschlieend prft ein automatisierter Test die Funktionsfhigkeit aller Kampagnen. Im letzten Abschnitt dieser Masterarbeit folgt eine abschlieende Betrachtung, welche eine Zusammenfassung, eine Bewertung sowie einen Ausblick enthlt.
Martin Schler
Seite 4 von 85
2 Grundlagen
In diesem Abschnitt werden das Unternehmen Inverso GmbH sowie die verwendete Web-Anwendung nher vorgestellt. Anschlieend werden die bentigten Grundlagen der Arbeit dargestellt.
2.1 Das Unternehmen Inverso GmbH

Die Inverso GmbH wurde 1997 mit Hauptsitz in Ilmenau und einer Niederlassung in Mnchen von Professor Doktor Reinhold Schnfeld und Heinz Prokop gegrndet. Im Jahr 2002 wurde mit dem Ausscheiden von Herrn Schnfeld der Hauptsitz nach Mnchen verlegt. Eine weitere Geschftsstelle wurde im Jahr 2001 in Jena ernet. Insgesamt arbeiten zur Zeit etwa 79 Mitarbeiter in dem mittelstndischen Unternehmen. Das Unternehmen hat sich auf IT-Lsungen fr Finanzdienstleister spezialisiert. Dabei liegen die Kernkompetenzen in der Entwicklung von mageschneiderten, innovativen und professionellen Anwendungslsungen fr Versicherungsunternehmen, welche auf die spezischen Bedrfnisse der einzelnen Anwender abgestimmt werden. Zudem analysiert, untersttzt und bert Inverso seine Kunden beim Einsatz von IT- und CRM-Anwendungen. Bei Inverso hat das Wort Innovation eine sehr groe Bedeutung. So werden innovative Lsungsanstze mit langjhriger Erfahrung, technischem Know-How und fachlichem Hintergrundwissen kombiniert, wodurch optimale Ergebnisse garantiert werden. Dadurch ist es mglich, dass neue, hochwertige und individuelle Lsungen fr Finanzdienstleister entstehen. Das Ziel von Inverso ist es, dass seine Kunden durch den Einsatz der auf sie zugeschnittenen Software eine Spitzenposition im Wettbewerb erlangen. Seit der Grndung konnte sich Inverso GmbH am Markt etablieren und wuchs stetig. Die Geschftsfhrung besteht heute aus Diplom-Informatiker Roland Schachtschabel
Martin Schler
Seite 5 von 85
2. Grundlagen und Diplom-Kaufmann Harry Maack.

1
2.2 Die Web-Anwendung

In diesem Abschnitt wird zunchst ber den Zweck der Web-Anwendung gesprochen und anschlieen die eingesetzte Architektur nher beschrieben.
2.2.1 Zweck der Web-Anwendung

Bei der Web-Anwendung handelt es sich um ein Serviceportal fr Individualkunden sowie fr Geschfts- und Vertriebspartner von Versicherungsunternehmen. Daraus ergeben sich folgende Benutzergruppen, welche innerhalb der Anwendung unterschiedliche Berechtigungen und Funktionen besitzen: Agentur Makler Kommunen Kirchen Krankenhuser Sparkassen Banken Innerhalb der Anwendung knnen Tarifberechnungen durchgefhrt, entsprechende Antrge gestellt sowie allgemeine produkt- und vertriebsspezische Informationen abgerufen werden. Zudem erhlt der Nutzer die Mglichkeit, seinen Ansprechpartner direkt ber die Web-Anwendung zu kontaktieren. Vertriebspartner knnen ber das Portal Bestellungen fr Vertriebsmaterialien oder Werbemittel aufgeben. Darber hinaus knnen nderungs-, Schadens- und Jahresmeldungen ber die WebAnwendung versendet werden. Zustzlich beinhaltet das System ein zentrales sowie dezentrales Kampagnenmanagementsystem mit Anbindung an Lettershops fr individuelle Anschreiben. Laufende Kampagnen knnen so gezielt durchgefhrt und ausgewertet werden.
Vgl. [Invb]
Martin Schler
Seite 6 von 85
2. Grundlagen
Bei der Web-Anwendung handelt es sich um eine mandantenfhige J2EE-Lsung. Das heit, verschiedene Kunden oder Auftraggeber nutzen das gleiche physische System. Die Unterschiede zwischen den einzelnen Mandanten liegen vor allem im Design, in der Navigationsstruktur, den einzelnen Modulen sowie in den verwendeten Formularen. Dies gewhrleistet, dass ein neuer Mandant mit relativ wenig Anpassungen hinzugefgt werden kann.2
2.2.2 Architektur der Web-Anwendung

Die Web-Anwendung besteht aus einer Drei-Schicht-Architektur. Dies hat den Vorteil, dass die Anwendung gut skalierbar ist, da die einzelnen Schichten logisch voneinander abgegrenzt sind. Dabei drfen Objekte nur auf die eigene oder die nchst tiefere Ebene zugreifen. Die Abbildung 2.1 stellt die logischen Komponenten der Web-Anwendung dar. Sie beschreibt die drei Ebenen der Architektur, welche auf einen WebSphere-Server beziehungsweise auf den Browser des Clients betrieben werden. Die erste Schicht ist die sogenannte Prsentationsschicht, welche auf dem Browser des Users luft. Sie dient dabei als Schnittstelle zwischen dem User und dem entsprechenden Anwendungskern des Systems. Dies besteht aus der Dialogsteuerung und generierten JSPs. Die zweite Schicht beinhaltet den Anwendungskern, welcher aus allen Anwendungsobjekten und Geschftsprozessen besteht. Die Dateien, welche zu dieser Ebene gehren, sind als Agent gekennzeichnet. Die letzte Ebene besteht aus der Datenverwaltung und den Backend-Adaptern, welche die Backend-Systeme vom Rest der Anwendung trennen. Die zu der Persistenz-Schicht gehrenden Daten, sind als Factory gekennzeichnet. Als Datenverwaltung wird in der Web-Anwendung eine DB2-Datenbank eingesetzt, welche auf einem separaten Server luft. Zustzlich werden der Web-Anwendung Schnittstellen zu anderen Systemen bereitgestellt. So liegen zum Beispiel die Daten fr Vertriebsmaterialien und Werbemittel in einem Lotus Notes-System und knnen dort zentral verwaltet werden. Zustzlich wird in der dritten Schicht eine Verbindung zu anderen Backend-Systemen bereitgestellt. Die Informationen fr die einzelnen Bereiche der Web-Anwendung, wie zum Beispiel Benutzerinformationen oder Kampagnendaten, benden sich in fnf unterschiedlichen Datenbanken. Dies ermglicht eine logische Trennung der Inhalte und vereinfacht die Pege der Daten.
2 3
Vgl. [Invc] Vgl. [Inva] 4 Vgl. [Inva]
Martin Schler
Seite 7 von 85
2. Grundlagen
Abbildung 2.1: Logische Komponenten der Web-Anwendung
Martin Schler
Seite 8 von 85
2. Grundlagen
Abbildung 2.2: Schematische Darstellung der Kopplung von OpenCMS und der WebAnwendung 4
Die Abbildung 2.2 stellt die Kopplung von OpenCMS und der Web-Anwendung dar. Das Content-Management-System enthlt sowohl die statischen Inhalte als auch die Menstruktur der Applikation. Die Menstruktur enthlt die Adressierung der statischen Inhalte aus dem CMS sowie die dynamischen Inhalte aus der Web-Anwendung. Durch die Verwendung verschiedener Eigenschaften wird die Sichtbarkeit der einzelnen Menpunkte gesteuert, so dass jeder Anwender seine individuelle Navigationsstruktur erhlt. Die statischen Inhalte werden vom Fachbereich der jeweiligen Mandanten selbststndig verwaltet und gepegt. Im Gegensatz dazu werden die dynamischen Inhalte von der Anwendung generiert. 5
2.3 OpenCMS
OpenCMS ist ein Content-Management-System, welches als freie Software unter der LGPL verentlicht wird und auf Java sowie JSP basiert. Es besitzt ein ausgereiftes Redaktionssystem in Form eines Dateiexplorers. Alle Ressourcen werden in Ordnern organisiert und dort als Dokumente verwaltet. Dies hat den Vorteil, dass der Zugri
5
Vgl. [Inva]
Martin Schler
Seite 9 von 85
2. Grundlagen

6
auf alle Inhalte ber eine einheitliche Oberche gesteuert wird.
2.4 Structured Query Language

Structured Query Language (SQL) wurde in den 70er Jahren im Rahmen eines Forschungsauftrages von der Firma IBM entwickelt. Aufgrund der Standardisierung durch das ANSI (American National Standards Institute) wird es von den meist verwendeten Datenbanksystemen genutzt. Dadurch ist es mglich, Anwendungen unabhngig von der verwendeten Datenbank zu erstellen. Mit SQL hat man die Mglichkeit zur Denition, Manipulation sowie zur Integrittskontrolle von Datenstzen. 7
2.5 Java Database Connectivity

Java Database Connectivity (JDBC) stellt die Verbindung zwischen Datenbanken und in Java programmierten Anwendungen her. Die Applikation kann unabhngig zu dem verwendeten Datenbanksystem programmiert werden, denn der JDBCTreiber bernimmt die Kommunikation mit der Datenbank. Ihm muss lediglich mitgeteilt werden, welche Datenbank verwendet wird und wie diese konguriert ist. 8
2.6 Java Reection

Durch den Einsatz von Reection ist es mglich, auf Informationen von Klassen und Objekten zur Laufzeit zuzugreifen sowie diese zu modizieren. Dies wird dann notwendig, wenn die entsprechende Klasse nicht bereits beim Kompilieren deniert ist oder Informationen ber diese abgefragt werden mssen. 9
2.7 Rational Application Developer

Der Rational Application Developer (kurz RAD) wird als Entwicklungsumgebung bei der Firma Inverso verwendet. Der RAD wurde von der Firma IBM entwickelt
6 7
Vgl. Vgl. 8 Vgl. 9 Vgl.
[ConoA] Seite 26-30 [AB01] Seite 432 [Hor] [Ull]
Martin Schler
Seite 10 von 85
2. Grundlagen
und lste das Produkt WebSphere Studio Application Developer ab. Dabei basiert es auf dem Open-Source-Tool Eclipse, wodurch die Entwicklungsumgebung individuell angepasst und erweitert werden kann. Der RAD ist besonders fr den Einsatz mit einem WebSphere-Server optimiert. Es beinhaltet verschiedene Tools, welche den Programmierer whrend der Entwicklung untersttzen. 10
2.8 ACID-Prinzip
Das ACID-Prinzip beschreibt die Eigenschaften von Verarbeitungsschritten in Datenbanken sowie von verteilten Systemen. Im Deutschen werden sie auch AKIDEigenschaften genannt und stehen fr Atomaritt, Konsistenz, Isoliertheit sowie Dauerhaftigkeit. Diese Funktionen sind die Anforderungen fr Verlsslichkeit von Systemen. Atomaritt bedeutet, dass eine Operation ganz ausgefhrt werden muss. Tritt bei der Ausfhrung ein Fehler auf, mssen alle nderungen, welche bis zu diesem Zeitpunkt gettigt wurden, rckgngig gemacht werden. Der Begri Konsistenz beschreibt, dass Daten nach der Beendigung einer Transaktion weiterhin widerspruchsfrei sein mssen, sofern sie es davor bereits waren. Bei der Isolation drfen sich nebenluge Operationen nicht gegenseitig beeinussen. Wurde eine Transaktion erfolgreich abgeschlossen, mssen die Daten permanent gespeichert werden; dies sagt der Begri Dauerhaftigkeit aus. Nach einem Systemfehler darf es zu keinem Datenverlust oder zu einer Verflschung der Daten kommen. 11
2.9 Selenium
Mit Hilfe von Selenium knnen Funktionstests fr Webseiten erstellt werden. Es handelt sich dabei um ein Testframework, welches unter der Apache-2.0-Lizenz verentlicht wird. Mittels eines Firefox-Add-Ons knnen Interaktionen mit WebAnwendungen aufgezeichnet und anschlieend beliebig oft ausgefhrt werden. Mit Hilfe von JUnit kann der Entwickler einen Testfall in Java schreiben. Dies ermglicht den Einsatz von komplexen Oberchentests verbunden mit der berprfung auf bestimmte Bedingungen. 12
10 11
Vgl. [IBM] Vgl. [WEK] 12 Vgl. [Har]
Martin Schler
Seite 11 von 85
3 Die Informationssicherheit
In diesem Kapitel geht es um die Informationssicherheit im Allgemeinen. Zudem wird im letzten Abschnitt ber Sicherheitslcken in Web-Anwendungen gesprochen.
3.1 Denition und Zielsetzung

Unter dem Begri Informationssicherheit versteht man alle Manahmen zum Schutz von Informationen und IT-Systemen vor Gefahren und Bedrohungen. Dadurch soll das Risiko von Schden minimiert werden. Die Hauptschutzziele (Vertraulichkeit, Verfgbarkeit und Integritt) bilden dabei die Grundlage der Informationssicherheit. Die Bedrohungen knnen laut dem Bundesamt fr Sicherheit in der Informationssicherheit (kurz BSI) in folgende Kategorien eingeordnet werden: 13 Elementare Gefhrdung Hhere Gewalt Organisatorische Mngel Menschliche Fehlhandlungen Technisches Versagen Vorstzliche Handlungen
14
Der Informationssicherheit kommt eine hohe Bedeutung zu, da das Thema Sicherheit ein grundlegendes Bedrfnis der Gesellschaft darstellt. Dies wird gerade in der heutigen Zeit weiter verstrkt, da durch die zunehmende Globalisierung die Abhngigkeit von IT-Systemen immer strker zunimmt. 15 So wren heutige Geschftsprozesse oder Aufgaben ohne die Untersttzung durch Computer nicht mehr vorstellbeziehungsweise durchfhrbar, da eine groe Menge an Daten durch diese erzeugt,
13 14
Vgl. [Bre] Seite 3 Vgl. [Bunb] Seite 16 15 Vgl. [Bund] Seite 10
Martin Schler
Seite 12 von 85
3. Die Informationssicherheit
abgelegt, weitergeleitet oder gendert werden. Aus diesem Grund ist der Schutz dieser Systeme fr alle Beteiligten von groer Bedeutung. 16 Die nachfolgende Abbildung 3.1 stellt verschiedene Gefahrenbereiche dar, von denen Schden fr die Informationssicherheit ausgehen knnen. Die Reihenfolge der einzelnen Bedrohungen richtet sich nach der Bedeutung fr die befragten Unternehmen. Die jeweiligen Prozentwerte geben an, wie hug dadurch ein Schaden verursacht wurde. Man kann deutlich erkennen, dass der Mensch die grte Gefhrdung fr ein Unternehmen darstellt. Die Grnde hierfr liegen zum einen an fehlenden Schulungen in dem Bereich IT-Sicherheit und zum anderen in der Nachlssigkeit oder dem Vorsatz der eigenen Mitarbeiter.17
Abbildung 3.1: Bedeutung der verschiedenen Gefahrenbereiche
18
Wurde ein Unternehmen Opfer eines erfolgreichen Angries auf die IT-Sicherheit, ergeben sich daraus verschiedene Konsequenzen. Diese werden in der Abbildung 3.2 aufgelistet. Anhand dieser Grak ist erkennbar, dass jede zweite Firma, welche angegrien wurde, einen Ausfall von IT-Systemen hatte und dies zu Produktivittsverlusten fhrte. Die bedrohlichste Folge ist dabei der Imageschaden des betroenen Unternehmens. Dieser Schaden wirkt sich langfristig auf die betroene Firma aus.19
16 17
Vgl. Vgl. 18 Vgl. 19 Vgl. 20 Vgl.
[Bunb] Seite 11 [Bunc] Seite 10 [Bunc] Seite 10 [Wol] [Wol]
Martin Schler
Seite 13 von 85
Abbildung 3.2: Konsequenzen aus Angrien auf die IT-Sicherheit von Firmen
20
Trotz aller Vorkehrungen und Vorsichtsmanahmen kann niemals eine hundertprozentige Sicherheit erreicht werden. Dennoch ist es wichtig, das Risiko eines Angris oder das eines Ausfalls des IT-Systems auf ein Minimum zu reduzieren. Als Faustregel gilt hierfr: Eine Anwendung beziehungsweise ein System gilt dann als sicher, wenn der Aufwand fr einen erfolgreichen Angri grer ist als der Nutzen fr die angreifende Person. 21
3.2 Kern-Schutzziele der Informationssicherheit

In diesem Abschnitt werden die drei klassischen Schutzziele (Vertraulichkeit, Verfgbarkeit und Integritt) der Informationssicherheit kurz erlutert. Je nach Anwendungsbereich knnen diese noch weiter zerlegt werden, wodurch beispielsweise folgende Ziele hinzukommen knnen: Abrechenbarkeitg Anonymisierung Authentizitt Verbindlichkeit
21 22
22
Vgl. [Tl] Vgl. [Sch]
Martin Schler
Seite 14 von 85
3. Die Informationssicherheit Vertraulichkeit
Unter dem Begri Vertraulichkeit versteht man, dass Informationen vertraulich behandelt und gegen Missbrauch geschtzt werden mssen. Dies bedeutet, dass Daten nur von einem autorisierten Nutzer gelesen und gendert werden drfen, was sowohl fr den Zugri auf lokale Daten als auch fr die Datenbertragung gilt. 23
Verfgbarkeit Als verfgbar gelten IT-Systeme dann, wenn sie immer oder innerhalb einer vorgegebenen Zeitspanne erreichbar sind und somit genutzt werden knnen. Es darf whrend der Nutzung zu keinen Ausfllen oder Einschrnkungen kommen. Die Verfgbarkeit bezieht sich auf alle Teile eines Systems angefangen von der Anwendung des Benutzers bis hin zur zugrundeliegenden Infrastruktur. Auch Daten oder Informationen fallen unter dieses Schutzziel. 24
Integritt Integritt bedeutet, dass keine Daten unbemerkt oder unerlaubt verndert werden drfen. Dies stellt somit eine der schwierigsten Bereiche in der Informationssicherheit dar, denn wurden zu Beginn keine Manahmen getroen, um den Ursprung einer Information nachvollziehen zu knnen, ist dies im Nachhinein kaum noch mglich. Der Schaden, welcher bei der Verletzung der Integritt entsteht, kann in zwei Bereiche unterteilt werden. Ein Gebiet stellt die Verletzung der Systemintegritt dar. Dabei erhlt ein Angreifer Administratorzugang ber eine Sicherheitslcke und erzeugt sich weitere Accounts. Wird die Lcke geschlossen, kann ein Hacker das Rechnersystem weiterhin ber seine Accounts manipulieren. Der zweite Bereich ist der Verlust der Datenintegritt, wobei Daten oder Informationen manipuliert werden. Dies kann durch einen Virus, einen fehlerhaften Datentrger oder durch eigenes Verschulden geschehen. 25
23 24
Vgl. [Sch] Vgl. [Sch] 25 Vgl. [Sch]
Martin Schler
Seite 15 von 85
3.3 Sicherheitskonzept fr eine Softwareanwendung

Wie bereits festgestellt wurde, kann keine allgemeingltige Aussage darber getroffen werden, welche Manahmen ntig sind, um die Informationssicherheit innerhalb einer Anwendung zu erhhen. Diese richten sich nach dem Wert der zu schtzenden Information. Ein Hauptproblem ist dabei die Gradwanderung zwischen zu hohen Sicherheitsmechanismen, welche zu Kosten- und Akzeptanzproblemen fhren, und zu niedrigen Sicherheitsmanahmen, wodurch Sicherheitslcken innerhalb eines Systems vorhanden sein knnen. Aus diesen genannten Grnden muss ein individuelles Sicherheitskonzept erstellt werden. Nachfolgend wird die von dem Bundesamt fr Sicherheit (BSI) empfohlene Vorgehensweise zur Erstellung eines Sicherheitskonzeptes kurz erlutert. Da kein langfristiger Schutz damit gewhrleistet werden kann, muss die Wirksamkeit sowie die Ezienz der verwendeten Schutzmechanismen regelmig berprft werden.
Abbildung 3.3: Erstellung des Sicherheitskonzeptes

26
26
Vgl. [Buna] Seite 36
Martin Schler
Seite 16 von 85
Die Abbildung 3.3 zeigt die notwendigen Schritte, welche zur Erstellung eines Sicherheitskonzeptes erforderlich sind. Zu Beginn steht die Strukturanalyse, welche die Grundlagen fr die nachfolgenden Ablufe schat. Dazu mssen Fragen ber die Beschaenheit der Anwendung, die verwendete Infrastruktur oder die eingesetzten Computersysteme geklrt werden. Als nchstes ist der daraus resultierende Schutzbedarf zu ermitteln. Diese erfolgt fr alle Objekte aus der Strukturanalyse. Dabei konzentriert sich der Schutzbedarf auf mglichen Schden, welche aus der Verletzung der drei Kernziele fr das jeweilige Unternehmen entstehen knnen. Im IT-Grundschutz des Bundesamts fr Sicherheit wird sich auf die Einteilung des Schutzbedarfes in drei Kategorien beschrnkt (siehe Tabelle 3.1). Schutzbedarfskategorie Die Schadensauswirkungen sind begrenzt und berschaubar. Die Schadensauswirkungen knnen betrchtlich sein. Die Schadensauswirkungen knnen ein existentiell bedrohliches, katastrophales Ausma erreichen.
normal hoch sehr hoch
Tabelle 3.1: Einteilung des Schutzbedarfs
Nachdem der Schritt der Schutzbedarfsfeststellung abgeschlossen ist, werden entsprechende Manahmen zum Schutz des Systems ermittelt. Dazu kann der ITGrundschutzkatalog der BSI herangezogen werden. Dieser enthlt einzelne Bausteine mit empfohlenen Manahmen, welche auf die verschiedenen Komponenten und IT-Systeme zugeschnitten sind. Diese Handlungsanweisungen richten sich zudem nach der Wahrscheinlichkeit eines Angries. Als nchster Schritt erfolgt der Basis-Sicherheitscheck, in dem ein Soll-Ist-Vergleich durchgefhrt wird. Dieser ist in drei weitere Schritte unterteilt. Zunchst ndet die organisatorische Vorbereitung statt. Anschlieend wird der eigentliche Vergleich durchgefhrt, welcher mit Hilfe von Kontrollen sowie Interviews realisiert wird. Im letzten Schritt werden die Ergebnisse dokumentiert. Mit Hilfe einer Risikoanalyse knnen die Manahmen aus dem IT-Grundschutz durch weitere Bestimmungen ergnzt werden. Nach einer weiteren berprfung der Manahmen ndet die eigentliche Umsetzung dieser statt. 27
27
Vgl. [Buna] Seite 36-70
Martin Schler
Seite 17 von 85
3.4 Ermittlung von Sicherheitslcken durch Penetrationstest

Bei einem Penetrationstest werden Angrie auf ein IT-System unter kontrollierten Bedingungen durchgefhrt. Dadurch ist es mglich, Schwachstellen eines IT-Systems zu ermitteln beziehungsweise herauszunden, ob die eingesetzten Sicherheitsmanahmen den Angrien standhalten. Dabei kommen die gleichen Methoden zum Einsatz, welche auch von einem realen Angreifer verwendet werden. Dieses Verfahren fhrt zu einer realittsnahen Einschtzung der Sicherheitslage eines IT-Systems, aufgrund derer geeignete Schritte schon vor einer Attacke eingeleitet werden knnen. Gerade die schnelle Entwicklung im IT-Bereich macht es jedoch nicht mglich, nach einem Penetrationstest verlssliche Aussagen bezglich der Sicherheit treen zu knnen. So kann eine bislang unentdeckte Schwachstelle zu einem erfolgreichen Angri fhren. Des Weiteren knnen durch die Weiterentwicklung der Anwendung neue Sicherheitslcken entstehen. Aus diesem Grund ist der Schutzbedarf der Infrastruktur zu ermitteln. Je hher dieser ist, desto huger mssen die Tests wiederholt werden. Damit wird gewhrleistet, dass die Informationssicherheit auf einem hohem Niveau bleibt. 28
3.5 Sicherheitslcken in Web-Anwendungen

Die Abbildung 3.4 zeigt die Einstufung von verschiedenen Sicherheitslcken in WebAnwendungen. Die Einordung erfolgt dabei nicht nach der Hugkeit von Angrien, sondern nach dem daraus resultierenden Risiko fr ein Unternehmen. In diesem Abschnitt werden die zwei grten und somit gefhrdetsten Schwachstellen nher erlutert.
3.5.1 SQL-Injektion
Zu den gefhrlichsten Bedrohungen fr Web-Anwendung zhlen SQL-Injektionen (siehe Abbildung 3.4). Dies ist dem anhaltenden Trend der Digitalisierung geschuldet. Im Rahmen dessen werden Web-Anwendungen immer komplexer und speichern ihre bentigten Informationen zunehmend in Datenbanken, wodurch das Anzeigen von dynamischen Inhalten untersttzt wird. In diesen Datenbanken benden
28 29
Vgl. [Rey05] Seite 1 -10 Vgl. [OWA]
Martin Schler
Seite 18 von 85
Abbildung 3.4: Top zehn Risiken fr die Anwendungssicherheit aus dem Jahr 2010
29
Martin Schler
Seite 19 von 85
sich nicht nur statische Inhalte, sondern es werden immer huger auch sensible oder personenbezogene Daten in ihnen gespeichert. Durch die wachsende Zahl der Anwendungen, steigt auch dass Interesse, an die in ihnen gespeicherten Informationen zu gelangen. Die besonderen Angrisziele sind dabei die Anmeldung ohne Benutzername und Kennwort, sowie einen Angri auf den Web-Server selbst. Um SQL-Injektion auszufhren, bentigt es relativ wenige Kenntnisse, wodurch Webseite nicht nur durch erfahrene Angreifer attackiert werden, sondern auch von Nutzern, welche es aus reinem Interesse versuchen. Aus diesen Grnden bendet sich diese Art der Angrismethode schon seit langem auf der Liste der Top zehn Risiken fr die Anwendungssicherheit. Hug werden zum Ausnutzen dieser Schwachstelle sogenannte HTML-Formulare verwendet. Mit Hilfe der Request-Methode werden die dahinterstehenden SQL-Anweisungen manipuliert. Dies kann durch die Eingabe spezieller Zeichen, wie zum Beispiel die Eingabe eines Hochkommas, eines Semikolons oder durch Kommentarzeichen, geschehen. Um solche Angrie erfolgreich durchfhren zu knnen, muss ein Fehler innerhalb des Programmcodes vorliegen. Dies ist speziell dann der Fall, wenn Benutzereingaben ohne berprfung direkt in den SQL-String eingesetzt werden. Das nachfolgende Listing 3.1 zeigt ein Beispiel fr eine Anmeldung mit Benutzername und Passwort.
Listing 3.1: Beispiel einer Java-Methode fr ein Login
1
private ResultSet getBenutzer ( Statement pStatement , String strBenutzername , String strPasswort ) { String lQuery = " SELECT * FROM USER WHERE BENUTZERNAME = " + strBenutzername + " AND Passwort = " + strPasswort + " " ; ResultSet pRS = null ; try { pRs = pStatement . executeQuery ( lQuery ) ; } catch ( SQLException e ) { throw e ; } return pRs ; } Die erste Zeile des Listings 3.2 zeigt, wie der SQL-Befehl ohne Manipulation innerhalb der Datenbank ausgefhrt wird. Stimmen diese Werte (Benutzername und Passwort) mit einem Benutzer in der Datenbank berein, erhlt man alle dazugehrenden Attribute und die Anmeldung ist erfolgreich. Ist dagegen das ResultSet leer, wird der Login verweigert. Die zweite Zeile zeigt eine Attacke mit einem Hoch-
2 3
4 5 6 7 8 9 10 11
Martin Schler
Seite 20 von 85
komma. Durch diese Anweisung kommt es zu einem Datenbankfehler, da diese nicht mehr dem Syntax entspricht. In der dritten Zeile wird eine Hochkomma mit einem Kommentarzeichen verwendet. Stimmt der eingegebene Benutzername mit einem in der Datenbank berein, wird die Anmeldung auch ohne die Eingabe eines Passwortes erfolgreich ausgefhrt, da die Anweisung dem Syntax entspricht.
Listing 3.2: Beispiel fr Select-Anweisungen fr SQL-Injektion
1
SELECT * FROM USER WHERE BENUTZERNAME = benutzername AND PASSWORT = passwort SELECT * FROM USER WHERE BENUTZERNAME = benutzer name AND PASSWORT = passwort SELECT * FROM USER WHERE BENUTZERNAME = benutzername -- AND PASSWORT = passwort Im Gegensatz zu den lesenden SQL-Befehle (Select) sind die Anweisungen zum ndern oder zum Hinzufgen (UPDATE oder INSERT) neuer Informationen viel gefhrlicher. Durch diese knnen Datenstze neu angelegen oder bestehende verndert werden, ohne dass dies bemerkt werden wrde. In Zeile eins des Listings 3.3 ist ein Update-Befehl zu sehen, welcher ein neues Passwort setzt. Durch die Manipulation der Anweisung in Zeile zwei kann das Passwort statt fr den Benutzer mit der Kennung benutzername fr den Administrator gendert werden. Die eigentliche WHERE-Bedingung wird mit dem Kommentarzeichen auer Kraft gesetzt. In der dritten Zeile wird in das Passwortfeld passwortneu ingesetzt. Dadurch werden alle Passwrter innerhalb einer Tabelle verndert, da die Where-Bedingung auskommentiert wird.
Listing 3.3: Beispiel fr Update-Anweisungen fr SQL-Injektion
2 3
4 5
UPDATE USER SET PASSWORT = passwortneu WHERE BENUTZERNAME = benutzername UPDATE USER SET PASSWORT = passwortneu WHERE BENUTZERNAME = administrator -- WHERE BENUTZERNAME = benutzername UPDATE USER SET PASSWORT = passwortneu -- WHERE BENUTZERNAME = benutzername Dem Anwender wird es durch manche Datenbanksysteme erlaubt, Ergebnisse von SQL-Anweisungen in Dateien auf dem Datenbankserver zu speichern. Im Gegenzug
2 3
4 5
Martin Schler
Seite 21 von 85
knnen diese Dateien auch eingelesen werden, sodass diese Informationen auf der Web-Oberche dargestellt werden knnen. Mit Hilfe von SQL-Injektion kann diese Funktion so ausgenutzt werden, dass die im Unix-System vorhandene PasswortDatei ausgegeben werden wrde. Das Listing 3.4 zeigt die dafr manipulierte Anweisung. Bei dieser Variante knnte der Angreifer sogar Zugangsdaten zum kompletten Web-Server erhalten und somit einen noch greren Schaden verursachen.
Listing 3.4: SQL-Injektion zum Lesen der passwd-Datei
1
SELECT * FROM information WHERE id = 1 UNION ALL SELECT 1 ,2 ,3 , LOAD FILE ( / etc / passwd ) Bei der SQL-Injektion kann zwischen zwei Arten von Angrien unterschieden werden. Zum einen wird von einem blinden-Angri, wenn keine Kenntnisse ber die verwendete Infrastruktur vorhanden sind, gesprochen. Bei diesem wird zu Beginn versucht, alle bentigten Informationen zu erhalten, bevor der eigentliche Angri erfolgen kann. Die zweite Art der Angrie ist diese, wo die Kenntnisse bereits vorhanden sind. Fr diese Gruppe ist ein Angri leichter, da sie wissen, welches IT-System verwendet wird und wie die Datenbank aufgebaut ist. In diesem Abschnitt wurde davon 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 SQLAnweisung zu manipulieren, hat er ein breites Spektrum an Mglichkeiten, mit denen er einen Schaden verursachen kann: Er kann unberechtigten Zugri auf sensible Daten erhalten. Er kann Daten manipulieren, ohne dass man diese nderungen nachvollziehen knnte. Ist die Datenbank schlecht gesichert, kann er Befehle auch auf Betriebssystemebene ausfhren, wodurch er die Kontrolle ber den Datenbankserver erlangen knnte.32
30 31
Vgl. [Bet] Vgl. [Bunb] Seite 978 32 Vgl. [Bunb] Seite 978
Martin Schler
Seite 22 von 85
3.5.2 Cross-Site Scripting

Beim Cross-Site Scripting, oder auch XSS genannt, schleust der Hacker ScriptCodes in die Anwendung ein, damit diese anschlieend auf dem Rechner eines anderen Clients ausgefhrt werden. Als Sprache wird hierfr berwiegend JavaScript verwendet, da diese in den meisten Browsern aktiviert ist. Jedoch sind auch Sprachen wie HTML, VBScript, ActiveX oder Flash mglich. hnlich wie bei SQL-Injektion knnen auch beim XSS-Angrien Eingabefelder ausgenutzt werden. Eine einfache Cross-Site Scripting-Anweisung wird im Listing 3.5 dargestellt.
Listing 3.5: Beispielcode fr Cross-Site Scripting
1
< script type = " text / javascript " > Alert ( XSS Test ) </ script > Dabei wird eine einfache Fehlermeldung mit dem Text XSS Test genet. Wird diese Meldung nicht angezeigt, kann an dieser Stelle kein XSS-Angri durchgefhrt werden. Beim Cross-Site Scripting gibt es verschiedene Mglichkeiten eines Angris. So wird bei einem persistenten Angri der Schadcode dauerhaft auf einer Seite integriert und wird dadurch bei jedem Aufruf ausgefhrt. Dabei wird mit Hilfe eines Eingabefeldes der Befehl zum Beispiel in einer Datenbank gespeichert. Bei jeder Abfrage dieses Datensatzes wird der Code an den Browser bergeben und anschlieend ausgefhrt. Um einen nicht persistenten Angri handelt es sich dagegen, wenn der Schadcode durch eine manipulierte URL ausgefhrt wird. Dieser wird meistens in einer E-Mail als normaler Link getarnt. Das Ausfhren des Codes geht meist in Sekundenschnelle, ohne dass dies bemerkt wird. Das Risiko eines persistenten Angris ist wesentlich hher, da dieser kaum Benutzerinteraktion bentigt. 33 Die mglichen Folgen eines XSS-Angris: Umsetzung einer primitiven Denial of Service Aussphen eines Cookies Einblendung von fremden Inhalten
33
Vgl. [Vul]
Martin Schler
Seite 23 von 85
4 Aktueller Stand der Anwendung

In diesem Kapitel werden zunchst die bereits eingesetzten Sicherheitsmanahmen dargestellt. Im Anschluss daran werden in dem Bedrohungsszenario Schwachstellen oen gelegt.
4.1 Vorhandene Sicherheitsmechanismen

In diesem Abschnitt werden einige vorhandene Sicherheitsmanahmen der WebAnwendung vorgestellt. Dabei werden die Sicherheitseinstellungen der Server, der Datenbanken sowie der Infrastruktur vernachlssigt.
4.1.1 Request-Validator
Der Request-Validator ist ein von Inverso entwickelter Schutzmechanismus. Er dient dazu, alle Anfragen, welche vom Client an den Server geschickt werden, auf bestimmte Sonderzeichen zu berprfen. Dabei arbeitet dieser nach dem Blacklist-Prinzip. Das heit, es sind alle Zeichen erlaubt, solange sie nicht als zu blockierendes Zeichen deniert wurden. Die dafr notwendigen Regeln werden in einer XML-Datei gespeichert. Zudem kann fr jede Seite separat festgelegt werden, ob die Parameter berprft werden beziehungsweise welche Sonderzeichen an einer Stelle nicht erlaubt sind. Sendet der Client eine Anfrage an den Server, wird zuerst der Request-Validator aufgerufen. An diesen werden alle eingegebenen Parameter sowie die entsprechenden Dialogpfade bergeben. Anhand der Pfadangabe wird die zugehrige Regel auf alle bermittelten Informationen angewendet. Tritt dabei ein nicht erlaubtes Zeichen auf, beispielsweise ein Hochkommata oder ein Semikolon, wird dieses durch ein Sternsymbol (*) ersetzt und der Benutzer wird durch eine Fehlermeldung darber informiert (siehe Abbildung 4.1). Sind alle Eingaben gltig, so werden diese innerhalb der Web-Anwendung weiterverarbeitet. Dadurch soll die Anflligkeit
Martin Schler
Seite 24 von 85
4. Aktueller Stand der Anwendung
der Intranet-Anwendung gegenber SQL-Injektion und Cross-Site Scripting gesenkt werden.
Abbildung 4.1: Fehlermeldung vom Request-Validator
34
In manchen Bereichen der Web-Anwendung, speziell in Notizfeldern, mchte der Nutzer jedoch keine Einschrnkungen haben. Fr diese Situation kann die berprfung fr eine komplette Seite abgeschaltet werden, so dass der User alle zur Verfgung stehenden Sonderzeichen nutzen kann. Dies knnte jedoch zur Folge haben, dass durch die Deaktivierung Sicherheitslcken entstehen. 35
4.1.2 Authentizierung
Unter Authentizierung versteht man ein Verfahren zum Nachweis einer Identitt. Dies geschieht in der Regel durch die bermittlung einer Kennung und eines Passwortes an einen Server. Ein unberechtigter Zugri auf geschtzte Daten soll dadurch verhindert werden. Um in den geschlossenen Bereich der Web-Anwendung zu gelangen, muss der Anwender seine Zugangskennung eingeben. Der Benutzername sowie das Kennwort mssen bestimmte Vorgaben erfllen. Sobald eine Eingabe nicht diesen Anforderungen entspricht, wird die Anmeldung abgebrochen und der User wird darber informiert. Dies stellt einen wirkungsvollen Schutz gegen SQL-Injektion dar, denn Eingaben wie 1=1 sind an dieser Stelle nicht mglich. Zustzlich wird bei einer Anmeldung die Sicherheit des Passwortes berprft. Entspricht dieses nicht den Sicherheitsanforderungen, wird der Benutzer aufgefordert, dieses zu ndern. 36
4.1.3 Autorisierung
Bei der Autorisierung wird der Zugri von bestimmten Benutzergruppen auf Systemressourcen beschrnkt. Dies soll die Vertraulichkeit der jeweiligen Anwendungen
34 35
Eigene Darstellung Vgl. [Inva] 36 Vgl. [Inva]
Martin Schler
Seite 25 von 85
erhhen. Setzt ein Dialog im in der Web-Anwendung gewisse Zugrisrechte voraus, werden diese beim Aufruf vom DialogMgr. berprft. Besitzt ein User nicht die bentigten Rechte, wird die Anfrage abgebrochen und der Benutzer erhlt eine Fehlermeldung. Bei mandantenfhigen Web-Anwendungen mssen weitere Sicherungsmanahmen getroen werden. So gibt es zum Beispiel verschiedene Administratoren aus unterschiedlichen Organisationen. Jeder einzelne darf aber nur auf die Daten und Benutzer seiner Organisation zugreifen und diese ndern. Dies wird durch die verwendeten Agents gewhrleistet. 37
4.2 Bedrohungsszenarien
Zu Beginn dieses Bedrohungsszenarios werden Schwachstellen fr SQL-Injektion gesucht und die daraus resultierenden Konsequenzen dargestellt. Zudem wird auf die bestehende Mglichkeit von Cross Site-Scripting eingegangen.
4.2.1 SQL-Injektion
Nachfolgend werden die verschiedenen Bedrohungsszenarien von SQL-Injektion aufgelistet und nher beschrieben.
Anzeigen von SQL-Fehlermeldungen Damit eine SQL-Injektion mglich ist, muss zunchst eine geeignete Schwachstelle innerhalb der Web-Anwendung gefunden werden. Dies kann mit Hilfe geeigneter Programme geschehen oder durch manuelles Probieren. Bei beiden Varianten wird auf die Reaktion der jeweiligen Anwendung geachtet. Die Abbildung 4.2 zeigt eine SQL-Fehlermeldung der Web-Applikation. Anhand dieser Ausgabe kann man erkennen, dass an dieser Stelle ein Angri mglich ist. In diesem Fall handelt es sich um das Eingabefeld Suche. Der Request-Validator ist fr diesen Teil der Kampagne abgeschaltet, was die Eingabe von Sonderzeichen ermglicht. Diese werden ungeprft in den SQL-String eingesetzt.
37 38
Vgl. [Inva] Eigene Darstellung
Martin Schler
Seite 26 von 85
Abbildung 4.2: SQL-Fehlermeldung der Datenbank
38
Anzeigen aller Datenstzen einer Tabelle Damit die Vertraulichkeit der Informationen gewhrleistet ist, darf ein Nutzer nur auf die fr ihn bestimmten Daten zugreifen. Gerade bei einer mandantenfhigen Web-Anwendung ist dies besonders wichtig, da zum Beispiel verschiedene Firmen auf einem System arbeiten. Die Firma Inverso lst dieses Problem mit Hilfe einer entsprechenden Vermittlernummer, anhand dieser die Zuordnung der Datenstze erfolgt. Wird nun eine Kampagne aufgerufen, bekommt der Benutzer nur die fr ihn bestimmten Informationen zu sehen. Die Abbildung 4.3 zeigt ein Beispiel mit zwlf Datenstzen.
Abbildung 4.3: Zwlf Datenstze ohne SQL-Injektion
39
Wie bereits ermittelt, besteht fr das Eingabefeld Suchen die Mglichkeit einer Manipulation der entsprechenden SQL-Anweisung. Das Listing 4.2 zeigt beispielhaft den Standartbefehl, welcher bei einer regulren Suche ausgefhrt wird. Die zweite Zeile zeigt die manipulierte Eingabe fr das entsprechende Feld Suche. Anschlieend wird die manipulierte SQL-Anweisung angegeben. Durch diese erhlt der Anwender den kompletten Zugri auf die Datenstze der Tabelle Kampagne. Diese nderung wird in der Abbildung 4.4 dargestellt. An dieser ist deutlich zu erkennen, dass 3124 statt zwlf Datenstze vorhanden sind.
Listing 4.1: Verwendete SQL-Befehle um Daten zu anzuzeigen
1 2
// implementierte SQL - Anweisung Select * from Kampagne where HV in ( hv_nummer ) and ( Name like % suche % )
39
Eigene Darstellung
Martin Schler
Seite 27 von 85
3 4 5 6 7 8
// Manipulation des Eingabefeldes % ) or ( HV in ( select HV from Kampagne ) ) -// Manipulierte SQL - Anweisung Select * from Kampagne where HV in ( hv_nummer ) and ( Name like %% ) or ( HV in ( select HV from Kampagne ) ) -- % )
Abbildung 4.4: Datenstze mit SQL-Injektion
40
Verndern von Werten einer Tabelle Eine weitere Sicherheitslcke besteht auf der Detailseite einer Kampagne mit abgeschalteten Request-Validator, wo bei allen Eingabefeldern eine SQL-Injektion mglich ist. An dieser Stelle ist ein Angri besonders gefhrlich, weil es sich bei der implementierten SQL-Anweisung um einen UPDATE-Befehl handelt. Dadurch knnen Informationen einer ganzen Tabelle manipuliert werden. Die Abbildung 4.5 zeigt einen Datensatz ohne jegliche Vernderung an. Das Bild 4.6 dagegen weist eine Manipulation des Strae-Wertes von Test auf Masterarbeit auf. Das Listing 4.2 zeigt die verwendeten SQL-Befehle. Der Anwender hat normalerweise an dieser Stelle keine Mglichkeit, diesen Wert zu ndern. Die Manipulation wurde mit Hilfe des Notizfeldes durchgefhrt.
Listing 4.2: Verwendete SQL-Befehle um Daten zu ndern
1 2
// normale UPDATE - Anweisung UPDATE KAMPAGNE set Termin = 01.05.2012 , Beschreibung = Beschreibung Notiz = Notiz where Versnr = 47 ; // SQL - Injektion Notizfeld , Strasse = Masterarbeit // Manipulierte UPDATE - Anweisung
40
3 4 5 6 7
Eigene Darstellung
Martin Schler
Seite 28 von 85
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 Angri knnten alle Datenstze der Tabelle mit denselben Werten berschrieben werden. Dazu wrde es reichen, ein Hochkomma und zwei Bindestriche einzugeben. Dies htte zur Folge, dass die where-Bedingung als Kommentar gilt und von der Datenbank nicht mehr ausgefhrt wird, wodurch alle Datenstze innerhalb der Tabelle berschrieben wrden.

An der gleichen Stelle wie in Kapitel 4.2.1 (Verndern von Werten einer Tabelle) ist eine dauerhafte Cross-Site Scripting-Attacke mglich. Als dauerhaft gilt diese, da der Schadcode fest in die Datenbank geschrieben wird. Wie in Abbildung 4.7 dargestellt,
41 42
Eigene Darstellung Eigene Darstellung
Martin Schler
Seite 29 von 85
wird der Code bei jedem nen des manipulierten Datensatzes ausgefhrt. In diesem Beispiel wird eine Alert-Box aufgerufen, was zu keinem nennenswerten Schaden fhrt.
Abbildung 4.7: XSS-Attacke
43
4.2.3 Analyse der Ergebnisse

Zusammenfassend kann man sagen, dass die Anwendung bereits sehr gute Manahmen zur Gewhrleistung der Sicherheit enthlt. Alle in dieser Arbeit gefundenen Lcken knnen nur als angemeldeter User ausgenutzt werden, da zum aktuellen Zeitpunkt keine Schwachstellen im entlichen Bereich der Web-Anwendung gefunden wurden. Jede ermittelte Sicherheitslcke ist nur an Stellen entstanden, an denen der Request-Validator abgeschaltet wurde. Die Grnde fr diese Abschaltung wurden im Kapitel 4.1.1 bereits vorgestellt. Nachfolgend wird der Vorteil der DB2-Datenbank und das aus den Schwachstellen resultierende Gefahrenpotential nher beschrieben. Ein wichtiger Vorteil des verwendeten Datenbanksystems DB2 ist es, dass es an keiner Stelle mglich ist, zwei SQL-Anweisungen gleichzeitig auszufhren. Das bedeutet, dass der implementierte Befehl nicht mit Hilfe eines Semikolons beendet werden kann, um anschlieend einen weiteren Befehl auszufhren. Sobald dies versucht wird, erscheint die in Abbildung 4.8 dargestellte Fehlermeldung.
Abbildung 4.8: Fehlermeldung von der DB2-Datenbank
44
43 44
Martin Schler
Seite 30 von 85
Die entdeckten Sicherheitslcken innerhalb der Web-Anwendung haben ein unterschiedliches Gefahrenpotenzial. Als weniger kritisch ist die Schwachstelle bei Suchfeldern (Anzeigen aller Datenstze einer Tabelle) einzustufen. Die Lcke verletzt das Kernschutzziel Vertraulichkeit, da ein User sich alle Datenstze einer Tabelle anzeigen lassen kann. Jedoch knnen keine Daten an dieser Stelle manipuliert werden, sodass das Kernschutzziel Integritt nicht verletzt wird. Dennoch sollte dies bei einer mandantenfhigen Web-Anwendung vermieden werden, da jeder Mandant nur auf die fr ihn bestimmten Daten zugreifen darf. Fr einen Laien ist es sehr schwierig, diese Schwachstelle erfolgreich auszunutzen, da der Benutzer Kenntnisse ber den in der Anwendung implementierten SQL-Befehl bentigt. Die Sicherheitslcken auf den Detailseiten haben ein hheres Gefahrenpotenzial. Hier kann die Integritt der Daten verletzt werden, ohne dass nachvollzogen werden kann, wer welche Daten wie verndert hat. Mit Hilfe der Fehlermeldung, welche vom System angezeigt wird, kann der Nutzer die Eingabe erfolgreich manipulieren. Viel dramatischer ist es, dass alle Datenstze mit identischen Werten berschrieben werden knnen. Hierzu fgt ein Angreifer zwei Bindestriche ein, welche in SQLAnweisungen als Kommentar zhlen. Dadurch wird die Where-Bedingung der Anweisung nicht mehr bercksichtigt. Dies kann sogar unbeabsichtigt geschehen, da hierfr nur die Zeichenfolge % eingegeben werden muss. Deshalb ist es notwendig, dass die Schwachstellen geschlossen werden. Um dies zu realisieren, wird in dem nachfolgenden Abschnitt ein geeignetes Konzept erarbeitet.
Martin Schler
Seite 31 von 85
5 Konzepte zur Absicherung

In diesem Kapitel werden Konzepte aufgezeigt, wie SQL-Injektionen vermieden werden knnen. Abschlieend wird anhand der Auswertung das fr die Inverso GmbH am besten geeignete Konzept dargelegt.
5.1 Web Application Firewall

Web Application Firewalls (WAF), auch Web Shields genannt, sollen die WebAnwendung vor Angrien aus dem Internet schtzen. Im Gegensatz zu normalen Firewalls wird hierbei nicht die Kommunikation auf Netzwerkebene berwacht, sondern das Hypertext Transfer Protokoll. Das Verfahren wird serverseitig eingesetzt und berwacht den gesamten Datenverkehr zwischen der Web-Anwendung und dem Browser des Clients. Wird dabei ein schadhafter Inhalt identiziert, wird der Transfer abgebrochen oder es wird eine vorher festgelegte Aktion ausgefhrt. Dies hat den Vorteil, dass ein Angri bereits blockiert wird, bevor er die Web-Anwendung beziehungsweise den User erreicht. Die fr die Filterung bentigten Kriterien kann man entweder manuell oder durch eine vorgeschaltete Lernphase festlegen. Manche Web Application Firewalls berwachen nicht nur die eingehenden Daten, sondern auch diese, die zum Client gesendet werden. Die Abbildung 5.1 zeigt den Aufbau einer WAF. Gerade bei lteren Anwendungen ist der Einsatz von Web Shields oft die gnstigere Variante. Denn wird eine Sicherheitslcke entdeckt, muss der Quellcode entsprechend gendert werden, um die Schwachstelle zu schlieen. Diese nderungen knnen jedoch zu unerwnschten Fehlern in anderen Teilen der Applikation fhren, welche man nur durch aufwendige und somit kostspielige Tests ausschlieen kann. Zudem ist es oftmals nicht mglich, die Lcken selbst zu schlieen, da die Anwendung durch ein anderes Unternehmen erstellt wurde. Hier ist man darauf angewiesen, dass dieses die Sicherheitslcke schliet. Bis dahin kann man durch den Einsatz einer Web Application Firewall das Risiko eines Angris minimieren.
Martin Schler
Seite 32 von 85
5. Konzepte zur Absicherung
Der Einsatz einer WAF hat aber auch einige Nachteile. So sollte diese nicht als Ersatz fr eine sichere Web-Anwendung dienen, denn die Mglichkeit eines erfolgreichen Angris besteht weiterhin, da die Firewall umgangen werden kann. Jedoch kann man die WAF als zustzlichen Schutz integrieren, wodurch eine weitere Sicherheitsebene hinzugefgt wird. Eine falsch kongurierte Firewall kann zu Strungen bei der Benutzung oder zur Unachtsamkeit whrend der Entwicklung fhren. 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 hheren Programmiersprache mit Hilfe von verschiedenen Attributen auf Objekte der Speicherschicht von relationalen Datenbanken abgebildet. Durch den Einsatz eines ORM soll der sogenannte Strukturbruch verhindert werden. Dieser entsteht, wenn Objekte einer objektorientierten Programmiersprache, wie zum Beispiel Java, in relationalen Datenbankstrukturen gespeichert werden sollen. Durch den Einsatz eines MappingTools werden beim Auslesen aus der Datenbank automatisch Informationen zu komplexen Objekten zusammengefasst. Im Gegenzug werden diese beim Speichern entsprechend ihrer Eigenschaften in die Datenbank geschrieben. 48 Der Einsatz eines OR-Mappers fhrt zu einer Steigerung der IT-Sicherheit. Dies liegt zum einen daran, dass diese in der Regel Prepared Statements fr Datenbankabfragen verwenden. Zum anderen werden innerhalb des Quellcodes kaum noch
45 46
[Bune] Seite 98 [Hl] [Tec] [Bee06] Seite 9
Martin Schler
Seite 33 von 85
SQL-Anweisungen eingesetzt, was die bersichtlichkeit sowie die Wartbarkeit der Anwendung erhht. Des Weiteren bentigt der Programmierer keinerlei Kenntnisse ber den Aufbau der verwendeten Datenbank, da er nur auf die Objekte des OR-Mappers zugreifen muss. Dadurch wird eine komplette Abstraktion der verwendeten Datenbank erreicht. Durch ausgereifte Caching-Mechanismen kann zudem die Performance der Anwendung gesteigert werden. 49
5.3 Prepared Statements

Prepared Statements sind SQL-Anweisungen, welche noch keine Parameterwerte besitzen. Anstelle dieser Werte werden dem Datenbankmanagementsystem Platzhalter bergeben, welche zur Laufzeit mit den entsprechenden Werten gefllt werden. Dies stellt einen wirkungsvollen Schutz gegen SQL-Injektion dar, da die Gltigkeit der Konstanten vom Datenbanksystem berprft wird, bevor diese verarbeitet werden. Nachfolgend wird der Unterschied zwischen herkmmlichen SQL-Anweisungen und Prepared Statements im Java Code dargestellt. Wie man im zweiten Beispiel des Listings 5.1 erkennen kann, wird der Platzhalter ber das Fragezeichen (?) deniert. Um diesen mit Parameterwerten fllen zu knnen, 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 innerhalb der SQL-Anweisung. Bei dem direkten Vergleich der beiden Beispiele fllt auf, dass man mit wenig Aufwand eine hhere Sicherheit der Anwendung erreichen kann. 50
Listing 5.1: Beispiel fr eine Prepared Statement-Anweisung
1 2 3 4 5
// Prepared Statement lQuery = " Select * From USER where LOWER ( NAME ) like ?; lStatement = lConnection . prepareStatement ( lQuery ) ; lStatement . setString (1 , " Martin " ) ;
49 50
Vgl. [Bune] Vgl. [The]
Martin Schler
Seite 34 von 85
5.4 Neuentwicklung
Mit der Entwicklung der Anwendung wurde im Jahr 2000 begonnen und seit dem ist diese stetig gewachsen. Hinzu kommt, dass im Laufe der Jahre verschiedene Programmierer daran gearbeitet haben. Des Weiteren wurde gerade in der Anfangszeit wenig Wert auf die Sicherheit gelegt, da die bestehenden Risiken zu dem Zeitpunkt noch nicht bekannt waren. Durch eine Neuentwicklung htte man die Mglichkeit, die Programmierung dahingehend auszurichten, dass die Sicherheit der Anwendung steigt. Dazu muss im Vorfeld ein genaues Sicherheitskonzept erarbeitet werden. Ein weiterer Vorteil der Neuentwicklung ist es, dass man dadurch die Mglichkeit htte, neue Technologien zu verwenden. Denn gerade in diesem Bereich ist in den letzten Jahren einiges geschehen. So wurde zum Beispiel im Jahr 2004 die neue Programmiersprache Scala vorgestellt. Diese hat den Vorteil, dass sie Java untersttzt und als Laufzeitumgebung die Java Virtual Machine bentigt. Dadurch knnen bereits bestehende Java-Bibliotheken weiterhin eingesetzt werden. Ein weiterer Grund, welcher fr den Einsatz der neuen Programmiersprache spricht, ist die Reduzierung des Quellcodes. Mit ihr knnen im Vergleich zur herkmmlichen Programmierung in Java 50-80 % des Codes eingespart werden, was wiederum zu einer Reduzierung von Fehlern in der Anwendung fhrt, da mit zunehmenden Code diese steigen. Lift ist ein Web-Framework, welches in der Programmiersprache Scala geschrieben wurde. Dieses erleichtert die Arbeit gerade in Hinblick auf die Programmierung von Web-Anwendungen. In Lift wurden einige wichtige Schutzfunktionen integriert, welche viele Sicherheitslcken der Grak 3.4 schlieen. So werden zum Beispiel SQLInjektion durch den integrierten Mapper verhindert. Dieser escaped den kompletten Query, bevor dieser an die Datenbank bertragen wird. Eine weitere Schutzfunktion soll Cross-Site Scripting verhindern, indem alle Strings vor der bermittlung zum Browser umgewandelt werden. Diese Manahmen sind automatisch integriert und mssen von dem Programmierer nicht weiter beachtet werden. 51 52 Allerdings wre der Kosten- und Zeitaufwand fr eine Neuentwicklung enorm, damit die neue Web-Anwendung dem Stand der jetzigen entspricht. Zudem kme ein unkalkulierbarer Aufwand fr das Testen und die anschlieende Fehlerbeseitigung hinzu. Durch die hohe Komplexitt und Funktionsvielfalt der Anwendung bezglich einer Neuentwicklung lsst sich keine aussagefhige Kosten-Nutzen-Betrachtung erstellen.
51 52
Vgl. [Lif] Vgl. [o.A]
Martin Schler
Seite 35 von 85
5.5 Bewertung
Nachfolgend werden die fr die Prferenzmatrix entscheidenden Kriterien aufgefhrt: a) Kosten b) Sicherheit c) Ressourcen d) Verwendung des Know-Hows In der nachfolgenden Tabelle werden die Entscheidungskriterien mit Hilfe einer Prferenzmatrix gegenbergestellt. Je huger ein bestimmtes Kriterium in der Tabelle vorhanden ist, desto strker ist die sptere Gewichtung. a) b) c) d)
Tabelle 5.1: Prferenzmatrix
a) b) a) a)
b) b) b)
c) c)
d) -
Das ergibt eine Verteilung von: Kosten = 33 % Sicherheit = 50 % Ressourcen = 17 % Know-How = 0 % Die grte Gewichtung bei der Entscheidung, welche Variante umgesetzt wird, hat die Sicherheit der Anwendung und die dazugehrenden Daten. Dies liegt vor allem daran, dass die Anwendung sensible Kundendaten beinhaltet und dadurch ein enormer Imageschaden entstehen kann, sofern diese durch einen erfolgreichen Angri entwendet werden. Betrachtet man die entscheidenden Kriterien aus betriebswirtschaftlicher Sicht, drfen die im Zuge der Umsetzung entstehenden Kosten nicht vernachlssigt werden. Aus diesem Grund kommt ihnen eine Gewichtung von 33 % zu.
Martin Schler
Seite 36 von 85
Das Kerngeschft der Inverso ist die Softwareentwicklung fr Versicherungsunternehmen. Aus diesem Grund wird dem Kriterium Know-How keine Beachtung geschenkt. Die nachfolgende Nutzwertanalyse soll klren, welche der vorgestellten Varianten am besten ist und somit zur Erhhung der Sicherheit beitrgt. Es werden Punkte von null bis zehn fr die Abdeckung der Kriterien vergeben. Diese werden anschlieend mit der Gewichtung multipliziert und in das Ergebnis eingetragen. Die einzelnen Resultate werden addiert und die Variante mit der grten Gesamtpunktzahl ist folglich am besten fr die Umsetzung geeignet.
Tabelle 5.2: Nutzwertanalyse
Anhand der Prferenzmatrix wurde ermittelt, dass die Sicherheit der Anwendung eine groe Rolle spielt. Die hchste Sicherheit wird durch den Einsatz eines ORMappers erreicht. Dies liegt vor allem daran, dass dieser zum einen Prepared Statements fr Datenbankabfragen verwendet und zum anderen die bersichtlichkeit des Quelltextes erhht. Den geringsten Schutz vor Sicherheitslcken bietet der Einsatz einer Web Application Firewall. Sie sollte, wie bereits erwhnt, nur kurzfristig dazu verwendet werden, um Sicherheitslcken vorbergehend zu schtzen. Die eigentliche Schwachstelle innerhalb der Anwendung bleibt jedoch bestehen, sodass die Firewall mit gengend Know-How umgangen werden kann. Eine weitere wichtige Rolle fr die Entscheidungsndung spielen die Kosten. Diese sind bei der Umstellung auf Prepared Statements am geringsten, da lediglich die vorhandenen SQL-Abfragen umgestellt werden mssten. Dadurch braucht man die Logik der Anwendung nicht zu verndern. Im Gegensatz dazu ist der Einsatz eines OR-Mappers mit wesentlich mehr Aufwand verbunden. Hierfr muss zunchst fr jede Tabelle in der Datenbank eine eigene Mapping-Datei erstellt werden und anschlieend muss die Zugrisschicht der Anwendung auf die Verwendung des ORMappers angepasst werden. Die hchsten Kosten wrden bei der Neuentwicklung entstehen, da die Anwendung im Laufe der Jahre enorm angewachsen ist. Dies wirkt sich auch auf die Auslastung der Ressourcen aus, da ein Groteil der Mitarbeiter mit der Erstellung beschftigt wre und nderungswnsche des Kunden nicht mehr so schnell umsetzbar sind.
Martin Schler
Seite 37 von 85
Anhand der Nutzwertanalyse wrde die Entscheidung zugunsten der Umstellung auf Prepared Statements ausfallen. Wie jedoch bereits in der Einleitung beschrieben, lag die Preferenz des Unternehmens beim Einsatz eines OR-Mappers. Aus diesem Grund wird bei der prototypischen Implementierung sowohl der Einsatz eines Persistenz Layers als auch die Umstellung auf Prepared Statements realisiert.
Martin Schler
Seite 38 von 85
6 Das OR-Mapper Tool Hibernate

Das von der Inverso favorisierte OR-Mapping Tool ist Hibernate. Es ist einer der bekanntesten Persistenz Layer und hat somit einen hohen Reifegrad. Es handelt sich dabei um ein Open-Source Produkt, welches von JBoss Inc. weiterentwickelt wird. Aus diesem Grund wird in diesem Kapitel Hibernate vorgestellt und die Verwendung nher erlutert.
6.1 Objektzustnde in Hibernate

In Hibernate gibt es drei verschiedene Objektzustnde, welche in der Abbildung 6.1 dargestellt sind. Als Transient gilt ein Objekt, welches neu erstellt wurde, aber noch nicht mit einer Session verbunden ist und noch keinen Datenbankeintrag besitzt. Im Gegensatz dazu spricht man von einem Persistent, wenn ein Objekt aktuell mit einer Session verbunden ist und einen Eintrag in der Datenbank enthlt. Um Detached Objekte handelt es sich dann, wenn diese nicht mehr mit einer Session verbunden sind, aber dennoch ein entsprechender Datenbankeintrag existiert. Hibernate verwendet beim Laden von Objekten das sogenannte Lazy-Loding. Dabei werden referenzierte Objekte des zu ladenden Datensatzes nicht sofort geholt, sondern erst dann, wenn diese bentigt werden. Dies soll die Geschwindigkeit bei Abfragen erhhen und zustzlich den Arbeitsspeicherverbrauch senken. Dies ist vor allem dann von Vorteil, wenn nicht das gesamte Objekt innerhalb eines Arbeitsschrittes bentigt wird. Dieses Verfahren kann sich dennoch negativ auf die Performance auswirken. Vor allem dann, wenn das komplette Objekt mit allen Referenzen bentigt wird. In dieser Situation ldt Hibernate zunchst das Wurzelobjekt, um anschlieend die referenzierten Datenstze schrittweise nachzuladen. Es entsteht das sogenannte 1+n-Problem.
53
Vgl. [dou] Seite 11
Martin Schler
Seite 39 von 85
6. Das OR-Mapper Tool Hibernate
Abbildung 6.1: Objektzustnde von Hibernate
53
6.2 Mapping-Dateien
Mit Hilfe der Mapping-Dateien kann Hibernate mit relationalen Datenbanken kommunizieren. Es beinhaltet dabei die wesentlichen Informationen ber die Architektur, wie Primr- und Fremdschlssel, Spalten oder Tabellen. Dadurch knnen Objekte in einer Datenbank gespeichert oder aus dieser geladen werden. In dem nachfolgenden Abschnitt werden verschiedene Arten von Mapping-Methoden vorgestellt. Alle aufgefhrten Beispiele beruhen auf der in Abbildung 6.2 dargestellten Tabelle User und dienen ausschlielich zum Erklren der jeweiligen Funktion. 54
Abbildung 6.2: Beispiel einer User-Tabelle
55
54 55
Vgl. [Bee06] Seite 57 Eigene Darstellung
Martin Schler
Seite 40 von 85
6.2.1 Mapping mit XML-Dokumenten

Bei dieser Variante wird ein XML-Dokument fr eine jeweilige Klasse erzeugt. In dieser Datei wird beschrieben, auf welche Tabelle zugegrien werden soll. Zudem werden die jeweiligen Attribute den entsprechenden Feldern zugeordnet. Nachfolgend wird in dem Listing 6.1 eine Mapping-Datei fr die Beispieltabelle User (Abbildung 6.2) erstellt.
Listing 6.1: XML-Mapping-Klasse

1 2 3
4 5 6 7 8 9
10
11 12
<? xml version = " 1.0 " ? > <! DOCTYPE hibernate - mapping PUBLIC " -// Hibernate / Hibernate Mapping DTD 3.0// EN " http :// hibernate . sourceforge . net / hibernate - mapping -3.0. dtd " > < hibernate - mapping > < class name = " mypackage . User " table = " USER " > < id name = " id " column = " ID " type = " integer " > < generator class = " native " / > </ id > < property name = " name " column = " NAME " type = " string " not - null = " true " / > < property name = " passwort " column = " PASSWORT " type = " string " / > </ class > </ hibernate - mapping > Dieses Beispiel zeigt die Datei user.hbm.xml und dient als Grundlage fr das Mapping. In dem class-Element wird unter dem Attribut name die entsprechende Java-Klasse ausgewhlt, welche nachfolgend dargestellt ist. Das Attribut table gibt die entsprechende Tabelle in der Datenbank an. Der Primrschlssel wird durch das id-Element festgelegt. Unter dem Attribut name wird die jeweilige Variable angegeben und mit Hilfe des Attributs column einer Spalte in der Tabelle zugeordnet. Mit type wird der Datentyp der Spalte angegeben. Des Weiteren kann man mit not-null festlegen, ob in der Datenbank Null-Werte erlaubt sind oder nicht.
Listing 6.2: Getter- und Setter-Klasse
1 2 3 4 5
package mypackage ; import java . util .*; public class User {
Martin Schler
Seite 41 von 85
6. Das OR-Mapper Tool Hibernate private int id ; private String name ; private String passwort public int getId () { return id ; } public String getName () { return name ; } public String getPasswort () { return passwort ; }
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
public void setId ( int id ) { this . id = id ; } public void setName ( String name ) { this . name = name ; } public void setPasswort ( String passwort ) { this . passowrt = passwort ; } } Diese in Listing 6.2 dargestellte Java-Klasse liefert die get- und set-Methoden fr die Attribute der Datei user.hbm.xml. Mit Hilfe dieser Variablen kann man Objekte aus der Datenbank lesen oder in diese schreiben. 56
6.2.2 Mapping mit Annotations

Durch die Einfhrung von EJB3 wird die Trennung der Denition des Mappings in einer XML-Datei und die Beschreibung des Geschftsobjekts in einer Klasse aufgehoben. Das nachfolgende Listing 6.3 zeigt das Mapping unter Verwendung von Annotations.
Listing 6.3: Mapping-Klasse mit Annotations
1 2 3 4
package mypackage ; import java . util .*;

56
Vgl. [Bee06] Seite 57 - 59
Martin Schler
Seite 42 von 85
6. Das OR-Mapper Tool Hibernate @Entity @Table ( name = " USER " ) public class User { public User () { } @ID @Column ( name = " ID " ) Integer ID ; @Column ( name = " NAME " ) String NAME ; @Column ( name = " PASSWORT " ) String PASSWORT ; public int getId () { return ID ; } public String getName () { return NAME ; } public String getPasswort () { return PASSWORT ; }
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
public void setId ( int id ) { ID = id ; } public void setName ( String name ) { NAME = name ; } public void setPasswort ( String passwort ) { PASSWORT = passwort ; } } Durch die @Entity-Annotation wird festgelegt, welche Java-Klasse persistent ist. Mit @Table wird die zugehrige Tabelle in der Datenbank angegeben. Die Zuordnung der Spalten zu den Attributen wir durch @Column realisiert. Der Vorteil dieser Variante des Mappings ist die Beschrnkung auf eine Java-Klasse. Das reduziert die Gesamtanzahl von Dateien innerhalb eines Programmes, was wie-
Martin Schler
Seite 43 von 85

57
derum die Wartbarkeit sowie die bersichtlichkeit erhhen.
6.3 Datenbankabfragen
In diesem Abschnitt werden verschiedene Methoden fr die Datenbankkommunikation 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 von SQL. Ein wichtiger Unterschied ist jedoch, dass die Gro- und Kleinschreibung bei HQL nicht von Bedeutung ist. Im nachfolgenden Codebeispiel 6.4 werden alle Datenstze der Tabelle User geholt und an eine Liste bergeben:
Listing 6.4: Codebeispiel fr eine HQL-Anweisung
1 2
Query q = session . createQuery ( " from User " ) ; List < user > alleUser = q . list () ; Um diese Anfrage ausfhren zu knnen, muss vorher eine Session erzeugt werden und ber die gesamte Dauer der Abfrage aktiv sein. Solang diese mit der Datenbank verbunden ist, enthlt die Liste alleUser persistente Objekte. Dadurch ist es mglich, 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 Session gebunden. Dazu muss die entsprechende Mapping-Datei als Ergebnistyp angegeben werden. Die nachfolgende Zeile zeigt eine einfache Abfrage, um den kompletten Inhalt einer Tabelle abzufragen. Mit Hilfe von Kriterien knnen die Ergebnismengen eingeschrnkt werden. Als Ergebnis werden alle Benutzer mit dem Namen Mller ausgegeben. Diese Kriterien knnen beliebig erweitert werden. Dabei beherrscht Criteria alle bekannten Abfrageoperationen.
57 58
Vgl. [Bee06] Seite 310 - 311 Vgl. [Bee06] Seite 149 - 159
Martin Schler
Seite 44 von 85
Listing 6.5: Codebeispiel fr eine Abfrage mit Criteria

1 2 3
List user = session . createCriteria ( user . class ) . add ( Restrictions . like ( " name " , " % Martin % " ) ) . list () ; Im Gegensatz zu HQL-Anweisungen ist es nicht mglich, Abfragen mit Joins zu erstellen. Ein weiterer Nachteil von Criteria ist die schlechtere bersicht im Vergleich zu HQL-Anweisungen. 59
6.4 Cache-Methoden in Hibernate

Durch das Zwischenspeichern von Daten wird der Lesezugri erhht, denn diese werden von einem langsamen Speichermedium, wie zum Beispiel der Festplatte, in den schnelleren Arbeitsspeicher geladen. Wird eine Abfrage von Hibernate gestartet, wird zunchst berprft, ob diese Daten bereits im Cache vorhanden sind. Ist dies der Fall, werden diese von dort geholt und weiterverarbeitet. Existieren fr die Abfrage keine Eintrge im Speicher, wird eine Datenbankabfrage gestartet und das zurckgelieferte Ergebnis in den Cache abgelegt. Dies ermglicht eine enorme Performancesteigerung, gerade bei sich wiederholenden Anfragen, was wiederrum zu verringerten Datenbankzugrien fhrt. In Hibernate gibt es zwei Arten von CacheMethoden(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 vorhanden ist, denn jede Session besitzt ihren eigenen Speicher. Dieser wird beim Erzeugen einer Session an diese gebunden und ist bis zum Ende der Session vorhanden. Jede enthlt dabei ihren eigenen First-Level-Cache. Um diesen verwenden zu knnen, bedarf es keiner weiteren Einstellung, da dies in Hibernate von Anfang an aktiviert ist. 62
59 60
[Bee06] Seite 159 - 161 [Bee06] Seite 139 - 141 [ORD] [Bee06] Seite 139 - 141
Martin Schler
Seite 45 von 85
Abbildung 6.3: Darstellung des Hibernate-Caches
61
6.4.2 Second-Level-Cache
Zustzlich zum First-Level-Cache kann in Hibernate der Second-Level-Cache konguriert werden. Hierbei handelt es sich um einen optionalen Cache, welchen man nur sehr vorsichtig einsetzen sollte, denn es kann leicht zu inkonsistenten Datenstzen kommen. Bei einer falschen Konguration kann es zudem zu einer Performanceverschlechterung fhren. Der Cache ist ein langlebiger Speicher, da er zusammen mit der Session-Factory initialisiert wird. Im Gegensatz zu dem First-Level-Cache existiert dieser nur einmal in jeder Anwendung. 63
6.5 Connection-Pool
Das Erzeugen einer Datenbankverbindung ist sehr teuer, da es viel Zeit in Anspruch nimmt. Aus diesem Grund wird beim Start ein gewisser Vorrat solcher Verbindungen erzeugt und im zentralen Connection-Pool abgelegt. Bei jeder Abfrage holt sich Hibernate eine Verbindung aus dem Pool, welche am Ende der Transaktion wieder in dem Pool abgelegt werden und fr eine andere Abfrage genutzt werden knnen.64 Hibernate untersttzt drei verschiedene Arten von Connection-Pools:
63 64
Vgl. [Bee06] Seite 139 - 141 Vgl. [Bee06] Seite 91 - 93
Martin Schler
Seite 46 von 85
1. Hibernate verwaltet den Connection-Pool selbststndig. Diese Variante ist fr den Einsatz auerhalb eines Web-Servers gedacht. 2. Fr den Einsatz in einem Web-Server wird empfohlen, dass Hibernate sich die DataSource ber JNDI holt, welche wiederum eine Connection zurckliefert. Hierbei werden die Einstellungen des Pools im Application-Server vorgenommen. 3. Bei dieser Variante bekommt die Session eine Connection von der Anwendung zugewiesen, so dass Hibernate sich diese nicht mehr selbststndig holen muss. Dieser Fall ist besonders dann geeignet, wenn Datenbankzugrie auch innerhalb der Anwendung ohne Hibernate stattnden. 65
65
Vgl. [Bee06] Seite 93
Martin Schler
Seite 47 von 85
7 Prototypische Umsetzung
In diesem Kapitel werden zwei verschiedene Varianten vorgestellt. Zu Beginn wird die Implementierung von Hibernate errtert und anschlieend die Umsetzung mit Prepared Statements. Dies soll den Umfang der Vernderungen im Vergleich verdeutlichen, da beide Varianten einen hnlichen Nutzen bezglich der Sicherheit darstellen.
7.1 Umsetzung mit Hibernate

In diesem Abschnitt werden der Ablauf und die Umsetzung der Variante mit Hibernate aufgelistet und nher erlutert.
7.1.1 Konguration von Hibernate

Fr die Konguration von Hibernate werden zwei Dateien bentigt. Dabei enthlt die Hibernate.cfg.xml, welche im Listing 7.1 dargestellt ist, alle wesentlichen Informationen. Diese gilt nur fr die Verbindung zu einer Datenbank. Deshalb muss fr die Web-Anwendung der Firma Inverso GmbH fr alle fnf Datenbanken eine eigene Kongurationsdatei erstellt werden. Das verwendete Datenbanksystem wird in Hibernate ber einen Datenbanktreiber eingebunden. Fr die Web-Anwendung entspricht dies einem DB2-Treiber, welcher unter "connection.driver-classingebunden wird. Mit Hilfe der nachfolgenden property-Tags werden die Adresse der Datenbank sowie die dazugehrigen Zugangsdaten angegeben. Fr die prototypische Implementierung wurden bei Hibernate eigene Connection-Pools mit der Gre 2 verwendet. Im produktiven Einsatz sollte der Connection-Pool durch einen anderen ersetzt werden. Eine sehr wichtige Konguration ist der SQL-Dialekt. Dieser steuert die Zugrie von Hibernate auf die Datenbank und gleicht die Eigenheiten eines DBMS aus. Der Second-Level-Cache kann unter cache.provider-class konguriert werden, worauf in dieser prototypi-
Martin Schler
Seite 48 von 85
7. Prototypische Umsetzung
schen Implementierung verzichtet wurde. Alle innerhalb der Web-Anwendung bentigten Mapping-Klassen mssen in der Kongurationsdatei unter dem Mapping-Tag eingetragen sein, sonst kann Hibernate nicht auf diese zugreifen.
Listing 7.1: Die Kongurationsdatei von Hibernate (Hibernate.cfg.xml)
1 2
<! DOCTYPE hibernate - configuration PUBLIC " -// Hibernate / Hibernate Configuration DTD 3.0// EN " " http :// www . hibernate . org / dtd / hibernate configuration -3.0. dtd " > < hibernate - configuration > < session - factory > <! - - Database connection settings --> < property name = " connection . driver_class " > com . ibm . db2 . jcc . DB2Driver </ property > < property name = " connection . url " > jdbc : db2 : // IP_Datenbank : Port / Datenbank_Name </ property > < property name = " connection . username " > username </ property > < property name = " connection . password " > passwort </ property > <! - - JDBC connection pool ( use the built - in ) --> < property name = " connection . pool_size " >2 </ property > <! - - SQL dialect --> < property name = " dialect " > org . hibernate . dialect . DB2Dialect </ property > <! - - Disable the second - level cache --> < property name = " cache . provider_class " > org . hibernate . cache . NoCacheProvider </ property > <! - - Echo all executed SQL to stdout --> < property name = " show_sql " >true </ property > <! - - Drop and re - create the database schema on startup > < property name = " hbm2ddl . auto " > update </ property - - > <! - - Names the annotated entity class --> < mapping class = " backend . hibernate_mapping . Kampa1_mapping " / >
4 5 6 7 8
10
11
12 13 14
15 16 17
18 19 20
21 22 23 24 25
26 27 28 29
Martin Schler
Seite 49 von 85
30
31
32
33 34
< mapping class = " backend . hibernate_mapping . Kampa1Update_mapping " / > < mapping class = " backend . hibernate_mapping . Kampa2 "/> < mapping class = " backend . hibernate_mapping . Kampa2Update " / > </ session - factory > </ hibernate - configuration > Das nachfolgende Listing 7.2 zeigt den Aufbau der Klasse Hibernateutil. Mit Hilfe dieser Datei wird eine Session in Hibernate erstellt. Dazu wird die entsprechende Kongurationsdatei eingebunden. In diesem Listing werden zwei Sessions fr zwei Datenbanken erstellt.
Listing 7.2: Aufbau der Datei Hibernateutil
1 2
3 4
5 6
7 8 9 10
public class HibernateUtil { private static final SessionFactory sessionFactoryRisiTest ; static { sessionFactoryRisiTest = new AnnotationConfiguration () . configure ( " / hibernate . cfg . xml " ) . buildSessionFactory () ; } public static SessionFactory getSessionFactoryRisiTest () throws HibernateException { return sessionFactoryRisiTest ; } private static final SessionFactory sessionFactoryKampa2 ; static { sessionFactoryKampa2 = new AnnotationConfiguration () . configure ( " / hibernateKampa2 . cfg . xml " ) . buildSessionFactory () ; } public static SessionFactory getSessionFactoryKampa2 () throws HibernateException { return sessionFactoryKampa2 ; } }
11 12
13 14
15 16 17
Martin Schler
Seite 50 von 85
7.1.2 Datenbankmapping mit Annotations

Das nachfolgende Listing 7.3 zeigt das Datenbankmapping von Hibernate innerhalb der Web-Anwendung. Whrend der prototypischen Implementierung wurden alle Mapping-Klassen mit Annotations realisiert.
Listing 7.3: Auszug aus der Mapping-Datei mit Annotations
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
@Entity @Table ( name = " Kampa2 " , schema = " dbms " ) public class Kampa2 { @Id @Column ( name = " VERSNR " ) private String VERSNR ; @Column ( name = " TITEL " ) private String TITEL ; @Column ( name = " NAME " ) private String NAME ; public String getVERSNR () { return VERSNR ; } public void setVERSNR ( String versnr ) { VERSNR = versnr ; } public String getTITEL () { return TITEL ; } public void setTITEL ( String titel ) { TITEL = titel ; } public String getNAME () { return NAME ; } public void setNAME ( String name ) { NAME = name ; } } Durch die Verwendung von @Entity wird die Klasse Kampa2 als Entity deniert und kennzeichnet diese als Mapping-Klasse. Die Annotation @Table legt fest, dass auf die Tabelle Kampa2 in dem Schema DBMS zugegrien wird. Als Primrschlssel
Martin Schler
Seite 51 von 85
wird die Spalte VERSNR verwendet. Die Namen der Attribute entsprechen den Namen der Spalten, wie man an der Zuordnung erkennen kann.
7.1.3 nderung des bestehenden Java-Codes

Bei der prototypischen Implementierung beschrnkt sich die Umsetzung auf den Kampagnen-Bereich der Web-Anwendung. Fr diese Umsetzung sind im Laufe der Arbeit zwei verschiedene Konzepte entstanden, welche nachfolgend vorgestellt werden. Die beiden Varianten unterscheiden sich im Umfang der durchzufhrenden nderungen und darin, wie stark das Hibernate-Konzept umgesetzt wird. Die Abbildung 7.1 verdeutlicht die Verwendung der CKMap.
Abbildung 7.1: Sequenzdiagramm der CKMap

66
66
Eigene Darstellung
Martin Schler
Seite 52 von 85
7. Prototypische Umsetzung Konzept 1
Bei dieser Variante wird versucht, die nderungen lediglich auf die PersistenzSchicht zu beschrnken. Dabei wird die bestehende CKMap mit ihrem eigenen Datentypen weiterverwendet. Das Listing 7.4 zeigt einen Teil der HQL-Anweisungen, welche in den jeweiligen Mappingklassen ausgelagert werden. Diese sind nicht allgemeingltig, sondern mssen fr jede Tabelle neu implementiert werden, da sich die Spalten unterscheiden knnen.
Listing 7.4: Beispiel fr HQL-Anweisungen in den Mapping-Dateien
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15
16 17 18 19 20
21 22 23
@NamedQueries ({ @NamedQuery ( name = " KAMPA1getBestand " , query = " from backend . hibernate_mapping . Kampa1_mapping Kampa1 where " + " Kampa1 . HV in (: hv ) " + " and ( lower ( Kampa1 . VERSNR ) like (: suche ) " + " or lower ( Kampa1 . NAME1 ) like (: suche ) " + " or lower ( Kampa1 . VORNAME1 ) like (: suche ) " + " or lower ( Kampa1 . PLZ ) like (: suche ) " + " or lower ( Kampa1 . ORT ) like (: suche ) " + " or lower ( Kampa1 . STATUS_BESCHREIBUNG ) like (: suche ) )" ), @NamedQuery ( name = " Kampa1getCount " , query = " select count (*) from backend . hibernate_mapping . Kampa1 _mapping Kampa1 where " + Kampa1 . HV in (: hv ) " ), @NamedQuery ( name = " Kampa1details " , query = " from backend . hibernate_mapping . Kampa1 _mapping Kampa1 where " + " Kampa1 . VERSNR = : versnr " ) }) Das Listing 7.5 zeigt exemplarisch die nderungen an der CKFactory fr die Bestandsbersicht der Kampagnen. Zu Beginn wird die Session fr die Datenbank geholt. Anschlieend wird der ausgelagerte HQL-Befehl an die Variable StringQuery
Martin Schler
Seite 53 von 85
bergeben. In der darauolgenden Zeile wird ein neuer HQL-Befehl erzeugt, welcher aus dem StringQuery, der Sortierbedingung und der Anzahl der zu holenden Datenstze besteht. Dieser Zwischenschritt ist notwendig, da der User auf der Oberche festlegen kann, wie er die Daten sortiert haben mchte und Hibernate keine Platzhalter innerhalb von Sortierbedingungen untersttzt. In den nchsten Schritten werden die Platzhalter der HQL-Anweisungen mit Werten gefllt. Durch den Befehl q.list() ndet die eigentliche Datenbankabfrage statt und die Informationen aus der Datenbank werden dem Hibernate-Objekt bergeben. Die nchste Zeile ruft eine Methode auf, welche die Umwandlung in eine CKMap realisiert. Dafr bentigt die Methode das Hibernate-Objekt sowie den Pfad der Mapping-Klasse.
Listing 7.5: nderungen an der CKFactory
1 2
Session session = HibernateFactory . getSession ( pConfig ) ; String StringQuery = session . getNamedQuery ( pConfig . getCsvView () + " getBestand " ) . getQueryString () ; Query q = session . createQuery ( StringQuery + lSortierKlausel + lAnzahlKlausel ) ; q . setParameterList ( " hv " , intArray ) ; q . setString ( " suche " ," % " + pSuchbegriff . toLowerCase () + "%"); List hibernateList = q . list () ; int lAnzahl = hibernateList . size () ; lReturn = HibernateFactory . createCKMapUebersicht ( hibernateList , pConfig ) ; Das Listing 7.6 zeigt, wie die Umwandlung des Hibernate-Objektes in eine CKMap implementiert wurde. Hierfr werden mit Hilfe von Java Reection alle Attribute mit dem dazugehrenden Namen aus dem Objekt in die CKMap geschrieben.
Listing 7.6: Umwandlung des Hibernate-Objektes
3 4
5 6 7 8
9 10 11 12 13 14
public static Object createCKMapUebersicht ( List hibernateList , ICKConfig pConfig ) throws Exception { Map lFachlObjektDetail ; CKUebersicht lFachlObjekt = pConfig . getUebersichtObjekt () ;
2 3 4
Martin Schler
Seite 54 von 85
5 6 7 8 9 10 11 12 13 14
List spaltenListe = pConfig . getUebersichtsSpalten () ; for ( int i =0; i < hibernateList . size () ; i ++) { lFachlObjektDetail = new CKMap () ; for ( int x =0; x < spaltenListe . size () ; x ++) { String SpaltenName = ( String ) spaltenListe . get ( x ) ; String getSpalte = " get " + SpaltenName ; Object HibernateObject = hibernateList . get ( i ) ; Method method = HibernateObject . getClass () . getMethod ( getSpalte ) ; Object wert = method . invoke ( HibernateObject ) ; lFachlObjektDetail . put ( SpaltenListe , wert ) ; } lFachlObjekt . getListe () . add ( lFachlObjektDetail ) ; } return lFachlObjekt ; } Die Verarbeitung in den hheren Schichten wird weiterhin mit Hilfe der CKMap realisiert, wodurch keine weiteren nderungen in diesen Bereichen anfallen. Beim Speichern der neuen Werte wird ein umgekehrter Weg vollzogen. Fr das Updaten eines Datensatzes wird eine neue Mapping-Datei bentigt. Der Grund hierfr wurde bereits in der Ausgangssituation beschrieben. An diesem Punkt stellen die eigenen Datentypen ein weiteres Problem dar. Diese mssen vor dem Schreiben umgewandelt werden. Das Listing 7.7 zeigt die fr das Updaten eines Datensatzes bentigten Schritte. Diese Methode ist allgemeingltig gestaltet und schreibt alle Werte einer CKMap per Hibernate in die entsprechende Datenbank. Zu Beginn dieser Methode muss der aktuelle Datensatz, welcher verndert werden soll, aus der Datenbank geholt werden. Dies ist notwendig, da das vorhergehende Hibernate-Objekt auf der entsprechenden View beruht und das Updaten auf der Tabelle geschieht. Anschlieend werden die Daten der CKMap umgewandelt. Dazu durchluft die Schleife alle Attribute des Hibernate-Objektes und ersetzt die Werte, welche gendert werden sollen durch die der CKMap. Da diese zum Teil eigene Datentypen sind, werden diese entsprechend umgewandelt. Die letzten vier Zeilen dienen zur Speicherung des Hibernate-Objektes. Dies zeigt deutlich, dass das Speichern innerhalb von Hibernate sehr einfach realisierbar wre, wenn nicht die CKMap verwendet werden wrde.
Listing 7.7: Auszug aus dem Quellcode der updateKampa()-Methode
15 16 17 18 19 20 21
public static void updateKampa ( CKMap CKMap , String HibernateClass ) {
Martin Schler
Seite 55 von 85
3 4 5
Session session = HibernateUtil . getSessionFactoryKampa2 () . openSession () ; session . beginTransaction () ; List HibernateList = session . createCriteria ( HibernateClass ) . add ( Restrictions . ilike ( " VERSNR " , CKMap . get ( " VERSNR " ) . toString () ) ) . list () ; Object HibernateObject = HibernateList . get (0) ; MessageMgr lMessageManager = MessageMgr . getInstance () ; Field [] field = HibernateObject . getClass () . getDeclaredFields () ; for ( int i =0; i < field . length ; i ++) { String setString = field [ i ]. getName () ; Object tmp = CKMap . get ( setString ) ; Object wert = null ; try { if ( tmp instanceof Text ) { wert = TextToString ( tmp ) ; } else if ( tmp instanceof Zahl ) { wert = ZahlToDouble ( tmp ) ; } // /.... if ( wert != null ) { if (! field [ i ]. getName () . equals ( " Z_USERKEY " ) ) { field [ i ]. setAccessible ( true ) ; System . out . println ( setString ) ; field [ i ]. set ( HibernateObject , wert ) ; } else { field [ i ]. setAccessible ( true ) ; field [ i ]. set ( HibernateObject , Integer . parseInt ( tmp . toString () ) ) ; } } } // catch - Block ..... } org . hibernate . Transaction tx = session . beginTransaction
6 7 8 9 10 11 12
13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
Martin Schler
Seite 56 von 85
45 46 47 48
() ; session . update ( HibernateObject ) ; tx . commit () ; session . close () ; } Durch das vorgestellte Konzept sind wesentlich weniger Anpassungen am Quelltext vorzunehmen. Es mssen lediglich die entsprechenden Mapping-Dateien erstellt sowie die kampagnenspezischen Factorys angepasst werden. Fr die nderungen an Datenstzen kann die in diesem Konzept erarbeitete Methode verwendet werden. Dazu muss lediglich der Aufruf in dem entsprechenden Agent gendert werden. Dennoch wird bei dieser Variante das Hibernate-Konzept nicht umgesetzt. So werden die Daten aus der Datenbank mehrfach umgewandelt, wodurch auch die Vorteile der Objektzustnde von Hibernate verloren gehen. Des Weiteren ist bei der Aktualisierung eines Datensatzes ein doppelter Zugri auf die Datenbank ntig, was wiederum die Geschwindigkeit beeintrchtigt.
Konzept 2 Bei dieser Variante wurde nach einem Weg gesucht, der das Hibernate-Konzept besser umsetzt. Die Mapping-Klassen mit den dazugehrenden HQL-Anweisungen aus dem ersten Konzept kommen in diesem ebenfalls zum Einsatz. Der einzige Unterschied innerhalb der Persistenz-Schicht besteht bei dem Rckgabetyp. Es wird nicht mehr die CKMap zurckgegeben, sondern das Hibernate-Objekt, in dem die Daten enthalten sind. Daraus ergeben sich jedoch massive nderungen innerhalb der Dialog-Schicht. Diese muss so angepasst werden, dass sie die Daten aus dem Hibernate-Objekt verwendet und nicht wie bisher aus der CKMap. Das Listing 7.8 zeigt die nderungen fr das Feld Name, welche beim Lesen und beim Speichern der Werte notwendig sind. Diese Anpassungen mssen fr jedes Feld in den einzelnen Kampagnen durchgefhrt werden.
Listing 7.8: nderungen in der Dialog-Schicht
1 2 3
4 5
// Lesen // alt : pDialogModel . setDetailKundeName ( lMapfachlObjekt . stringToText ( " NAME " ," " ) ) ; // neu : pDialogModel . setDetailKundeName ( new Text ( map . getNAME () ) ) ;
Martin Schler
Seite 57 von 85
6 7 8 9
10 11
// Speichern // alt : lMapfachlObjekt . put ( Kampa1 . SPALTE_NAME , pDialogModel . getDetailKundeName () . toJDBC () ) ; // neu : Kampa1 . setNAME ( pDialogModel . getDetailKundeName () . toJDBC () ) ; Um diese Variante in der gesamten Anwendung zu implementieren, sind sehr viele Anpassungen notwendig. So muss fr jede Tabelle in der Datenbank eine passende Mapping-Datei erstellt werden; dieser Schritt wird generell fr Hibernate bentigt. Im Anschluss daran mssen die bestehenden SQL-Anweisungen in einen HQL-Befehl umgendert werden, damit ein Sicherheitsvorteil berhaupt entsteht. Die aufwendigsten Anpassungen mssen in der Dialog-Schicht vorgenommen werden, damit diese mit dem Hibernate-Objekt umgehen kann. Hierbei tritt jedoch ein weiteres Problem auf, denn beim Speichern der Daten werden eigene Datentypen wie Geld oder E-Mail verwendet. Diese mssen, bevor sie an das Hibernate-Objekt bergeben werden, in einfache Datentypen umgewandelt werden.
7.2 Einsatz von Prepared Statements

Wie im Kapitel 5.3 beschrieben, werden bei Prepared Statements keine Parameterwerte an die Datenbank bergeben. Stattdessen werden Fragezeichen als Platzhalter genutzt. Bevor die Anweisung ausgefhrt werden kann, mssen jedoch alle Parameter mit Werten gefllt werden, ansonsten fhrt dies automatisch zu einer Fehlermeldung. Bei der Belegung der Platzhalter berprft das Datenbanksystem die Variablen auf ihre Gltigkeit. Aus diesem Grund steht fr jeden Datentyp eine eigene set()-Methode zur Verfgung. Die Zuordnung erfolgt dabei mit einer eindeutigen ID, welche jedes Fragezeichen besitzt. Diese beginnt bei eins und wird mit jedem weiteren Platzhalter um eins erhht. Ein groer Vorteil von Hibernate ist die Untersttzung von benannten Parametern. Aus diesem Grund wurde nach einer Mglichkeit gesucht, diese auch bei Prepared Statements verwenden zu knnen. Die erarbeitete Lsung wird in diesem Abschnitt beschrieben.
Martin Schler
Seite 58 von 85
7.2.1 NamedParameterStatement-Klasse
Die neue Java-Klasse NamedParamterStatement ermglicht die Nutzung von benannten Platzhaltern bei der Verwendung von Prepared Statements. Dadurch wird die Erstellung von Datenbankabfragen einfacher, da der Quellcode bersichtlicher ist. Die Listings 7.9 und 7.10 zeigen dabei im Vergleich die Unterschiede der beiden Varianten.
Listing 7.9: Beispiel fr eine Prepared Statement-Anweisung
1 2 3 4 5 6 7 8 9 10 11 12 13 14
// Prepared Statement lQuery = " Select * From Kampa1 where LOWER ( NAME ) like ? " + " OR LOWER ( VORNAME ) like ? " + " OR PLZ = ? " + " OR LOWER ( VERSNR ) like ? " + " OR LOWER ( ORT ) like ? " ; lStatement = lConnection . prepareStatement ( lQuery ) ; lStatement . setString (1 , searchstring . toLowerCase () ) ; lStatement . setString (2 , searchstring . toLowerCase () ) ; lStatement . setInt (3 , plzInt ) ; lStatement . setString (4 , searchstring . toLowerCase () ) ; lStatement . setString (5 , searchstring . toLowerCase () ) ; lRs = lStatement . executeQuery () ;
Listing 7.10: Beispiel fr eine Prepared Statement-Anweisung mit benannten Parametern

1 2
3 4 5 6 7 8
// NamedParameterStatement lQuery = " Select * From Kampa1 where LOWER ( NAME ) like : search " + " OR LOWER ( VORNAME ) like : search " + " OR PLZ = : searchPLZ " + " OR LOWER ( VERSNR ) like : search " + " OR LOWER ( ORT ) like : search " ; NamedParameterStatement p = new NamedParameterStatement ( con , lQuery ) ; p . setString ( " search " , " % " + searchstring . toLowerCase () + "%"); p . setInt ( " searchPLZ " , plzInt ) ; lRs = p . executeQuery () ; Die neue Java-Klasse ist ein sogenannter Wrapper, welcher den SQL-String mit benannten Parametern entgegennimmt und diesen anschlieend in eine regulre Pre-
10 11
Martin Schler
Seite 59 von 85
pared Statement-Anweisung mit Fragezeichen umwandelt. Beim Erzeugen des Objekts NamedParameterStatement muss die Connection sowie die SQL-Anweisung mit bezeichneten Parametern bergeben werden. Das Listing 7.11 zeigt, was dabei geschieht. Fr die Umwandlung des Strings sorgt die pars()-Methode. Da jeder benannte Platzhalter mit einem Doppelpunkt eingelutet werden muss, untersucht diese den String nach genau diesem Zeichen. Wird dieses Symbol innerhalb der Anweisung entdeckt, werden alle Buchstaben oder Ziern, welche bis zum nchsten Leerzeichen vorkommen, als Name des Platzhalters deniert und innerhalb des SQLStrings durch ein Fragezeichen ersetzt. Der ermittelte Name wird als Key in einer Hashmap gespeichert, sofern dieser noch nicht in ihr enthalten ist. Des Weiteren wird in einer Liste die entsprechende ID abgelegt, welche in der Map zu dem passenden Schlssel angehangen wird. Enthlt diese bereits den Platzhalter, wird die Liste um die weitere Identikationsnummer erweitert. Der Quelltext dazu bendet sich im Listing 7.12. Die pars()-Methode liefert anschlieend den umgewandelten String zurck, welcher danach per Prepared Statement-Befehl an die Datenbank bermittelt wird.
Listing 7.11: Quellcode der NamedParameterStatement-Methode
1
67
2 3 4 5
public NamedParameterStatement ( Connection connection , String query ) throws SQLException { indexMap = new HashMap () ; String parsedQuery = parse ( query , indexMap ) ; statement = connection . prepareStatement ( parsedQuery ) ; } Wie bei der herkmmlichen Variante von Prepared Statements mssen auch hier alle Platzhalter vor dem Ausfhren des Datenbankbefehls gefllt sein, da ansonsten von der Datenbank eine Fehlermeldung zurckgegeben wird. Das Listing 7.13 zeigt, wie die einzelnen Parameter mit Werten gefllt werden knnen. Es gibt auch hier fr jeden Datentyp eine entsprechende set()-Methode. Der Unterschied zur herkmmlichen Variante besteht jedoch darin, dass die Zuordnung der Werte nicht mit einer ID, sondern mit dem Namen des Platzhalters, erfolgt. Dazu sucht die Java-Klasse in ihrer Map nach dem entsprechenden Parameter. Ist dieser vorhanden, wird die Liste mit den dazugehrigen Identikationsnummern zurckgegeben. Anschlieend wird fr jeden Eintrag in der Liste ein Prepared Statement-Befehl mit der ID und dem Wert ausgefhrt. 68
67 68
Vgl. [Cru] Vgl. [Cru]
Martin Schler
Seite 60 von 85
Listing 7.12: Auszug aus der parse()-Methode
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

69
20 21 22 23 24 25 26 27 28 29 30 31 32
for ( int i =0; i < length ; i ++) { char c = query . charAt ( i ) ; if ( inSingleQuote ) { if ( c == \ ) { inSingleQuote = false ; } } else if ( inDoubleQuote ) { if ( c == " ) { inDoubleQuote = false ; } } else { if ( c == \ ) { inSingleQuote = true ; } else if ( c == " ) { inDoubleQuote = true ; } else if ( c == : && i +1 < length && Character . isJavaIdentifierStart ( query . charAt ( i +1) ) ) { int j = i +2; while (j < length && Character . isJavaIdentifierPart ( query . charAt ( j ) ) ) { j ++; } String name = query . substring ( i +1 , j ) ; c = ? ; // replace the parameter with a question mark i += name . length () ; // skip past the end if the parameter List indexList =( List ) paramMap . get ( name ) ; if ( indexList == null ) { indexList = new LinkedList () ; paramMap . put ( name , indexList ) ; } indexList . add ( new Integer ( index ) ) ; index ++; }
Listing 7.13: Beispiel fr eine Methode zum Setzen von Parametern

1
70
2 3 4 5 6
public void setString ( String name , String value ) throws SQLException { int [] indexes = getIndexes ( name ) ; for ( int i =0; i < indexes . length ; i ++) { statement . setString ( indexes [ i ] , value ) ; } }
69
Vgl. [Cru]
Martin Schler
Seite 61 von 85
7.2.2 Setzen von Werten

Wie bei einer normalen Prepared Statement-Anweisung mssen vor dem executeBefehl alle Platzhalter mit Werten belegt sein. Ist dies nicht der Fall, wird von dem Datenbanksystem eine Fehlermeldung zurckgegeben. Fr jeden Datentyp steht eine geeignete set()-Methode zur Verfgung. Der einzige Unterschied besteht darin, dass die Zuordnung nicht mit Hilfe der ID geschieht, sondern der Name des entsprechenden Platzhalters verwendet wird. Sind mehrere Platzhalter mit dem gleichen Namen vorhanden, wird der angegebene Wert automatisch allen zugewiesen. Zum Setzen der Werte stehen folgende Methoden zur Verfgung: 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 mglich, eigene Methoden zu implementieren, welche die Logik fr eine entsprechende Zuweisung enthalten.
7.2.3 nderungen bei Select-Anweisungen

Die nderungen bei Select-Anweisungen werden exemplarisch fr die Methoden getResultsetBestandUebersicht() (siehe Listing 7.14) und getWhereKlauselSuchbegri() dargestellt. Jede Kampagne hat ihre eigene spezische Where-Bedingung mit unterschiedlichen Parametern, welche von der CKFactory aufgerufen wird. Damit die Datenbankabfrage weiterhin allgemeingltig bleibt, wurde die NamedParameterMap eingefhrt. In dieser werden die Namen des Platzhalters sowie der
70
Vgl. [Cru]
Martin Schler
Seite 62 von 85
dazugehrenden Werte gespeichert. Vor dem Ausfhren des SQL-Strings wird diese Hilfsmap an die Klasse NamedParameterStatement bergeben, welche das Setzen per Prepared Statements an der entsprechenden Stelle der SQL-Anweisung bernimmt. Das Listing 7.16 mit der Methode setNamedMap() stellt diese Funktion dar. Die Methode prft, ob der benannte Platzhalter aus der SQL-Anweisung in der Hilfsmap enthalten ist. Ist dies der Fall, wird anhand des Datentyps die entsprechende set()-Methode aufgerufen, wo die Belegung der Platzhalter mit dem gleichen Namen geschieht. Das Listing 7.15 zeigt ein Beispiel der Methode getWhereKlauselSuchbegri(). In ihr wird die Suchbedingung der jeweiligen Kampagne zusammengesetzt. Als benannte Platzhalter werden dabei searchstring, searchdouble und searchdate verwendet, welche mit einem Doppelpunkt versehen innerhalb der SQL-Anweisung stehen. Anschlieend wird in der Hilfsmap der Name des Platzhalters mit dem dazugehrenden Wert gespeichert.
Listing 7.14: Auszug aus der Methode getResultsetBestandUebersicht()
1
2 3 4 5 6 7 8
Map < String , Object > NamedParameterMap = new HashMap < String , Object >() ; String lSchema = super . mSchemaKampa2 ; if ( pConfig . getNameDB () . equals ( ICKConfig . DB_KAMPAGNE ) ) lSchema = super . mSchemaKampagne ; String lTabelle = pConfig . getUebersichtstabelle () ; String lSpalten = " * " ; if ( pConfig . getUebersichtsSpalten () != null ) lSpalten = listToString ( pConfig . getUebersichtsSpalten () , , ) ; String lQuery = " select " + lSpalten + " from " + lSchema + " . " + lTabelle + " where " + getWhereKlauselVNr ( pZielgruppe , pHVNrn , pContrNrn , CKAgent . HIERARCHIE_BESTAND , NamedParameterMap ) + getWhereKlauselSuchbegriff ( pSuchbegriff , NamedParameterMap ) + lSortierKlausel + lAnzahlKlausel ; try { Connection con = pStatement . getConnection () ; NamedParameterStatement p = new NamedParameterStatement ( con , lQuery ) ; p . setNamedMap ( NamedParameterMap ) ; pRs = p . executeQuery () ; p . close () ;
9 10 11 12 13 14
15 16 17 18 19
20 21 22
Martin Schler
Seite 63 von 85
23 24 25 26 27 28 29 30
log . debug ( " \ n Query : " + lQuery + " :\ n " ) ; } catch ( SQLException e ) { .... } log . debug ( " end " ) ; return pRs ; }
Listing 7.15: Auszug aus der Methode getWhereKlauselSuchbegri

1 2
3 4 5 6
7 8
10
11 12
13 14 15
if ( pSuchbegriff != null && ! pSuchbegriff . equals ( " " ) ) { lWhereKlausel = " AND ( LOWER ( " + SPALTE_NAME + " ) like : searchstring " + " OR LOWER ( " + SPALTE_VORNAME + " ) like : searchstring " + " OR LOWER ( " + SPALTE_PLZ + " ) like : searchstring " + " OR LOWER ( " + SPALTE_ORT + " ) like : searchstring " + " OR LOWER ( " + SPALTE_STATUS_BESCHREIBUNG + " ) like : searchstring " + " "; NamedParameterMap . put ( " searchstring " , " % " + pSuchbegriff . toLowerCase () + " % " ) ; if (( Datum . parseDatum ( pSuchbegriff ) ) instanceof Datum ) { lWhereKlausel += " OR " + SPALTE_VERSANDDATUM + " = : searchdate OR " + SPALTE_GEBURTSDATUM + " = : searchdate " ; NamedParameterMap . put ( " searchdate " , Datum . parseDatum ( pSuchbegriff ) ) ; } lWhereKlausel += " ) " ; }
Listing 7.16: Auszug aus der Methode setNamedMap

1 2
3 4 5 6 7 8 9
if (! valueMap . isEmpty () ) { for ( Iterator itr = indexMap . entrySet () . iterator () ; itr . hasNext () ;) { Map . Entry entry =( Map . Entry ) itr . next () ; String name = ( String ) entry . getKey () ; if ( valueMap . containsKey ( name ) ) { Object value = valueMap . get ( name ) ; if ( value instanceof String ) { setString ( name , value . toString () ) ; }
Martin Schler
Seite 64 von 85
7. Prototypische Umsetzung else if (....) { ...... } } } }
10 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 von benannten Platzhaltern. Zu Beginn der Methode wird eine Verbindung zu einer Datenbank aufgebaut und an die getUPDATEName()-Methode bergeben. Diese erzeugt einen passenden SQL-String mit benannten Platzhaltern, welche sie aus den bermittelten Parametern erzeugt. Als Rckgabewert wird ein Objekt der Klasse NamedParameterStatement erzeugt (siehe Listing 7.18). Im Anschluss daran mssen nur noch alle Platzhalter in der Datenbank mit Werten gefllt werden. Dazu wird die CKMap bergeben. Diese enthlt bereits als Schlssel den Namen der Spalte sowie den passenden Wert. Das Listing 7.19 zeigt, wie die Werte aus der CKMap geholt und per Prepared Statement an die Datenbank gesendet werden. Dazu wird geprft, ob der Name eines Platzhalters in der Map vorhanden ist oder nicht. Ist dies der Fall, wird der dazugehrende Wert ausgelesen und anhand des Datentyps wird ermittelt, welche set()-Methode verwendet werden muss. Zum Schluss wird mit Hilfe von executeUpdate() der Update-Befehl ausgefhrt.
Listing 7.17: Auszug aus dem Quellcode zum Updaten von Datenbankeintrgen
1 2 3 4 5 6 7 8 9 10 11 12 13
14
try { lNamedParameterStatement = getUPDATEName ( lConnection , mSchemaKampa2 , TABELLE_PHVVHVCS , " versnr = : " + SPALTE_VERSNR , SPALTE_STATUS , SPALTE_BEARBEITUNGSDATUM , SPALTE_TERMIN , SPALTE_STATUS_BESCHREIBUNG , SPALTE_NOTIZ , SPALTE_Z_NAME , SPALTE_Z_VORNAME , SPALTE_Z_USERID , SPALTE_Z_USERKEY ) ; lNamedParameterStatement . setCKMap ( pfachlObjekt ) ; lNamedParameterStatement . executeUpdate () ; } catch ( SQLException e ) { } finally { c leanUpNamedParameterStatement ( lConnection , lNamedParameterStatement ) ; }
Martin Schler
Seite 65 von 85
Die getUPDATEName()-Methode erzeugt aus den bergebenen Parametern zunchst einen Update-String. Seit Java fnf knnen sogenannte Varargs verwendet werden. Diese ermglichen es, eine variable Anzahl von Objekten zu bergeben. In dieser Methode wird es fr die bergabe der Spalten, welche einen neuen Wert zugewiesen bekommen, genutzt. Die for-Schleife durchluft diese Objekte und erzeugt einen Teil der SQL-Anweisung. Dieser entspricht der Form Spaltenname = :Spaltenname und erzeugt somit einen benannten Platzhalter. Zum Schluss wird der SQL-String mit Hilfe der restlichen Parameter zusammengesetzt und ein neues Objekt der Klasse NamedParameterStatement zurckgegeben.
Listing 7.18: Quellcode zum Erzeugen eines Update-Strings
1 2 3 4 5 6 7 8 9 10
11
12
StringBuilder values = new StringBuilder () ; for ( String columnName : pColumnNames ) { if ( values . length () != 0) { values . append ( " ," ) ; } values . append ( columnName ) ; values . append ( " = : " ) ; values . append ( columnName ) ; } return new NamedParameterStatement ( pConn ,( " UPDATE " + pSchema + " . " + pTableName + " SET " + values . toString () + ( pAuswahlkriterien != null ? " WHERE " + pAuswahlkriterien : " " ) ) ) ;
Listing 7.19: Quellcode zum Setzen von Parametern mit Hilfe einer CKMap
1
2 3 4 5 6 7 8 9 10 11 12 13 14
for ( Iterator itr = indexMap . entrySet () . iterator () ; itr . hasNext () ;) { Map . Entry entry =( Map . Entry ) itr . next () ; String name = ( String ) entry . getKey () ; if ( map . containsKey ( name ) ) { int [] indexes = getIndexes ( name ) ; Object value = map . get ( name ) ; if ( value == null ) { for ( int i =0; i < indexes . length ; i ++) { statement . setString ( indexes [ i ] , null ) ; } } else if ( value instanceof Text ) { Text valueText = ( Text ) value ; if ( valueText . equals ( Text . EMPTY_TEXT ) ) { for ( int i =0; i < indexes . length ; i ++) {
Martin Schler
Seite 66 von 85
15 16 17 18 19
20 21 22 23 24 25 26
statement . setString ( indexes [ i ] , null ) ; } } else for ( int i =0; i < indexes . length ; i ++) { statement . setString ( indexes [ i ] , valueText . toString () ) ; } } else if ( value instanceof Zahl ) { } } } }
7.3 Bewertung der beiden Varianten

Zusammenfassend knnen beide Alternativen wie folgt bewertet werden: Fr die Umstellung der Web-Anwendung auf Hibernate mssen bei beiden Varianten sehr viele nderungen vorgenommen werden, damit das Hibernate-Konzept optimal umgesetzt wird. Des Weiteren mssen Mapping-Klassen fr alle Tabellen und Views erstellt werden, damit Daten aus der Datenbank gelesen oder in diese geschrieben werden knnen. Die zustzliche Mapping-Datei fr die Views knnte dadurch vermieden werden, indem sie innerhalb der Mapping-Klasse der jeweiligen Tabellen abgebildet wird. Hierfr mssen jedoch zustzliche nderungen vorgenommen werden. Ein weiteres Problem stellen die eigenen Datentypen innerhalb der Web-Anwendung dar. Um dieses zu lsen, gibt es ebenfalls zwei Varianten. Die Konvertierung zwischen den jeweiligen Datentypen msste innerhalb von Hibernate in den jeweiligen Setter- und Getter-Klassen implementiert werden, was wiederum den Implementierungs- und den Testaufwand erhhen wrde. Bei der zweiten Alternative wird auf die Verwendung der eigenen Datentypen verzichten. Dafr mssen jedoch sehr viele Bereiche der Anwendung gendert werden, da diese nicht nur in der Dialogschicht, sondern auch in vielen Bereichen der Logik, verwendet werden. Fr die Umstellung auf Prepared Statements sind dagegen wesentlich weniger nderungen ntig, da sich die Anpassungen lediglich auf die Persistentz-Schicht beschrnken. Zudem stellen die eigenen Datentypen bei dieser Variante kein greres Problem dar, da im Gegensatz zu der Umstellung auf Hibernate die Konvertierung an einer zentralen Stelle vorgenommen wird.
Martin Schler
Seite 67 von 85
Dadurch wird deutlich, dass die Umstellung auf Prepared Statements die bessere Alternative ist, da weniger nderungen vorgenommen werden mssen. Um eine abschlieende Aussage darber treen zu knnen, wird nachfolgen der Test auf SQLInjektion und Cross-Site-Scripting wiederholt.
Martin Schler
Seite 68 von 85
8 Test der prototypischen Umsetzung

In diesem Kapitel wird die prototypische Implementierung mit Hibernate und Prepared Statements auf Schwachstellen berprft. Anschlieend wird mit Hilfe von Selenium ein allgemeiner Funktionstest durchgefhrt.
8.1 Sicherheitstest
In diesem Abschnitt werden die Tests aus dem Kapitel 4.3 wiederholt. Hierbei soll geprft werden, ob die Manipulationen weiterhin mglich sind. Da bei beiden prototypischen Implementierungen (Hibernate und Prepared Statements) die gleichen Resultate bezglich der Sicherheit erzielt wurden, wird an dieser Stelle nur der Testablauf mit Prepared Statements dargestellt.
8.1.1 SQL-Injektion
Anzeigen von SQL-Fehlermeldungen Die Grak 8.1 zeigt, dass an keiner Stelle der Web-Anwendung eine Fehlermeldungen zurckgegeben wird. Stattdessen wird nach einem Datensatz gesucht, welcher ein Semikolon enthlt. Da kein passender Eintrag mit diesem Suchkriterium in der Datenbank existiert, werden demzufolge auch keine Daten auf der bersichtsseite angezeigt. An dieser Stelle kann man eigentlich schon schlussfolgern, dass auf diesem Weg keine SQL-Injektion mehr mglich ist. Um sicherzugehen, werden die Tests fr das Anzeigen aller Datenstze sowie fr das Verndern von Werten wiederholt.
71
Eigene Darstellung
Martin Schler
Seite 69 von 85
8. Test der prototypischen Umsetzung
Abbildung 8.1: Test zum Anzeigen der Fehlermeldung
71
Anzeigen aller Datenstze einer Tabelle Anhand der Grak 8.2 kann man erkennen, dass auch an dieser Stelle nach einem Datensatz gesucht wird, welcher den eingegebenen Suchbegri enthlt. Als Nutzer hat man also keine Mglichkeit mehr, dass auch Daten anderer User angezeigt werden. Dadurch wird der Schutz der Vertraulichkeit gewhrleistet.
Abbildung 8.2: Test zur Manipulation der Suchanfrage
72
Verndern von Werten einer Tabelle Die Grak 8.3 wurde nach dem Abspeichern der Werte aufgenommen. Vor der Umstellung auf Prepared Statements wurde der Wert des Feldes Strasse berschrieben. Nun wird die Eingabe als Notiz gespeichert und verndert kein anderes Feld in der Datenbank. Dies zeigt, dass auch an dieser Stelle keine SQL-Injektion mehr mglich ist.
72 73
Martin Schler
Seite 70 von 85
Abbildung 8.3: Notizfeld der Web-Anwendung nach dem Abspeichern
73

Im Gegensatz zu dem erfolgreich verlaufenen Test fr SQL-Injektion, ist Cross-Site Scripting weiterhin mglich. Die Vorgehensweise dafr ist nach der Umstellung auf Prepared Statements jedoch eine andere. In dem Test aus Kapitel 4.3 wurde das Feld Strasse mit einem Schadcode versehen. Da dies nicht mehr manipuliert werden kann, 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 nderung des Eingabetextes kann die XSS-Attacke dennoch ausgefhrt werden. Dazu wird dem Code ein schlieendes Textareas-Tag vorangestellt. Dadurch interpretiert der Browser die es nicht mehr als Text des Notizfeldes, sondern fhrt den nachfolgenden Code aus, wie man aus der Grak 8.4 erkennen kann.
Abbildung 8.4: XSS-Attacke mit Prepared Statements
74
8.1.3 Bewertung
Anhand des durchgefhrten Tests kann festgestellt werden, dass die Umstellung auf Prepared Statements oder auf Hibernate zu einer Steigerung der IT-Sicherheit beitragen. Die Ergebnisse der beiden Varianten unterscheidet sich dabei nicht. Aus
74
Eigene Darstellung
Martin Schler
Seite 71 von 85
diesem Grund wurde in diesem Abschnitt nur das Ergebnis fr Prepared Statements dargestellt. Zusammenfassend kann gesagt werden, dass beide Varianten SQL-Injektion verhindern, jedoch fr Cross-Site Scripting ein weiterer Schutz notwendig wird. Aus diesem Grund ist fr die Web-Anwendung die Umstellung auf Prepared Statements die bessere Variante, da bei gleicher Sicherheit weniger nderungen vorgenommen werden.
8.2 Automatisierter Test mit Selenium

Das Unternehmen Inverso GmbH suchte nach einer Mglichkeit, alle umgestellten Kampagnen automatisiert zu testen. Dadurch soll zum einen sichergestellt werden, dass durch die Implementierung keine Fehler in den umgestellten Kampagnen vorhanden sind. Zudem soll der Entwickler dieses Testverfahren auch in Zukunft einsetzen knnen, um sicherzustellen, dass nderungen am Quellcode keine Auswirkungen auf die anderen Kampagnen haben. Hierfr ist ein automatisierter Test besonders von Vorteil, da die Programmierer keine Zeit haben, um alle Funktionen der Kampagnen zu testen.
Abbildung 8.5: Testflle mit Selenium
75
Fr das automatisierte Testverfahren wird das Oberchentool Selenium verwendet, welches die Mglichkeit bietet, Tests direkt auf der Oberche durchzufhren. Es gibt zwei verschiedene Arten, Selenium einzusetzen. Zum einen kann es als Browser75
Eigene Darstellung
Martin Schler
Seite 72 von 85
Plugin eingesetzt werden, wo man im Vorfeld den Test manuell aufzeichnen muss. Dieses Verfahren bietet jedoch keine Mglichkeiten, logische Auswertung der Inhalte oder andere Operationen auszufhren. Dies wird jedoch von der anderen Variante untersttzt, da Selenium innerhalb eines JUnit-Test verwendet wird. Die Schwierigkeit bei der Erstellung eines allgemeingltigen Tests, war vor allem der unterschiedliche Aufbau der einzelnen Kampagnen. In der Web-Anwendung gibt es momentan noch zwei Arten von Kampagnen-Frameworks (alt und neu), welche von dem Testfall abgedeckt werden mssen. In dem nachfolgenden Listing 8.1 werden die Grundfunktionen einer Kampagne mit neuem Framework getestet. Dies betrit das Setzen eines Versanddatums fr Kampagnen. Die Abbildung 8.5 zeigt einen laufenden Selenium-Test.
Listing 8.1: Auszug aus einem Selenium-Testfall fr das Setzen eines Versanddatums
1
2 3 4 5
6 7 8 9 10 11 12 13 14 15 16 17 18
String [] strPath = { " Kampagnen " , " alle oeffnen " ," // a [ @id = " + id + " ] " }; try { NavigateTo ( strPath ) ; } catch ( Exception e ) { strErgebnis = KampaName + " konnte nicht geoeffnet werden ! " + e ; } if ( strErgebnis . length () >0) { fail ( strErgebnis ) ; } selenium . click ( " // IMG [ @id = 3000 ] " ) ; selenium . waitForPageToLoad ( " 90000 " ) ; int i = 1; List < String > versandDatum = new ArrayList < String >() ; String tmpSpalte ; String tmpValue ; try { while ( selenium . isElementPresent ( " // table / tbody / tr [9]/ td [2]/ table / tbody / tr [2]/ td [ " + i + " ] " ) ) { if ( i ==1) { tmpSpalte = selenium . getText ( " // table / tbody / tr [9]/ td [2]/ table / tbody / tr / td / a / b " ) . trim () ; tmpValue = selenium . getText ( " // table / tbody / tr [9]/ td [2]/ table / tbody / tr [2]/ td " ) . trim () ; } if ( tmpSpalte . equals ( " Versand -\ n datum " ) | tmpSpalte . equals ( " Versand -\ ndatum " ) ) {
19 20
21
22 23
Martin Schler
Seite 73 von 85
24 25
26
27 28 29 30 31 32 33
for ( int x = 0; x <25; x ++) { if ( selenium . isElementPresent ( " // table / tbody / tr [9]/ td [2]/ table / tbody / tr [ " +( x +2) + " ]/ td [ " + i + " ] " ) ) { tmpValue = selenium . getText ( " // table / tbody / tr [9]/ td [2]/ table / tbody / tr [ " +( x +2) + " ]/ td [ " + i + " ] " ) . trim () ; versandDatum . add ( tmpValue ) ; } } break ; } i ++;
Martin Schler
Seite 74 von 85
9 Abschlieende Betrachtungen
In diesem Abschnitt ndet die Zusammenfassung der Resultate, eine Bewertung dieser Ergebnisse sowie einen Ausblick der Arbeit statt.
9.1 Zusammenfassung
Ziel dieser Arbeit war es, fr die Web-Anwendung der Firma Inverso GmbH ein Konzept gegen SQL-Injektion zu entwickeln. Dafr wurde zu Beginn dieser Arbeit die Bedeutung der IT-Sicherheit, die mglichen Folgen aus einem erfolgreichen Angri, sowie die zwei gefhrlichsten Sicherheitslcken dargestellt. Um ein Konzept gegen SQL-Injektion erstellen zu knnen, musste zunchst die Web-Anwendung diesbezglich untersucht werden. Dabei lag ein besonderes Augenmerk darauf, welche Vorkehrungen bereits getroen wurden, sowie wo mgliche Schwachstellen noch existieren knnten. Die daraus resultierenden Ergebnisse wurden in dem Bedrohungsszenario verwendet, um Schwachstellen innerhalb der Anwendung aufzudecken. Anschlieend wurden verschiedene Konzepte vorgestellt, wie diese Sicherheitslcken geschlossen werden knnten. Aufgrund der Randbedingungen (Sicherheit, Kosten) el die Entscheidung zugunsten der Prepared Statements aus. Da die Inverso GmbH jedoch die Arbeit mit dem Ziel der Umstellung auf Hibernate in Auftrag gegeben hatte, wurde dies zustzlich in der prototypischen Umsetzung bercksichtigt. Damit sollte herausgefunden werden, welche der beiden Konzepte besser geeignet ist. Zum besseren Verstndnis wurde Hibernate im sechsten Kapitel genauer beschrieben. Die prototypische Umsetzung von Hibernate und Prepared Statements wurde im siebten Abschnitt dargestellt. Aus der Umsetzung der beiden Varianten resultiert die Feststellung, dass Prepared Statements aufgrund geringeren Implementierungsaufwand bei gleichen Sicherheitsniveau besser geeignet sind. Um die Aussage mit dem Sicherheitsniveau bekrftigen zu knnen, wurde anschlieend geprft, ob SQL-Injektion weiterhin mglich ist. Da bei beiden Umsetzungsmglichkeiten die selben Resultate erzielt wurden, konnte dies besttigt werden.
Martin Schler
Seite 75 von 85
9. Abschlieende Betrachtungen
9.2 Bewertung
Abschlieend kann gesagt werden, dass mit Hilfe dieser Arbeit SQL-Injektion vermieden werden knnen. Dafr wurde die Variante mit der Umstellung auf Hibernate mit der auf Prepared Statements verglichen. Der auschlaggebende Grund fr die verwendete Variante war der geringere Implementierungsaufwand bei gleichem Nutzen. Im Rahmen dieser Arbeit wurde die Umstellung fr den gesamten KampagnenBereich vollzogen. Die restlichen bestehenden Teile der Web-Anwendung werden nach und nach umgestellt und neue Funktionen werden mit Prepared Statements implementiert. Sobald die Web-Anwendung komplett auf Prepared Statements umgestellt wurde, knnte der Request Validator so angepasst werden, dass Cross-Site Scripting weiterhin verhindert wird, jedoch zu einer Steigerung der Usibility fhrt. Dafr mssten nicht mehr alle Sonderzeichen blockiert werden, sondern es wrde reichen bestimmte Kombinationen an Zeichen, welche typisch fr Cross-Site Scripting-Attacken sind, zu verbieten. Ein anderer Ansatz wird kurz im nachfolgenden Abschnitt erlutert.
9.3 Ausblick
Mit Hilfe dieser Arbeit konnte ein Konzept entwickelt werden, welches, wenn es in der kompletten Anwendung implementiert wird, zur Steigerung der IT-Sicherheit beitrgt. Im Laufe der prototypischen Implementierung wurde die Umstellung von Prepared 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 durchfhrt. Bei Neuentwicklungen werden Prepared Statements direkt fr Datenbankabfragen eingesetzt. Wie bereits durch den Test der prototypischen Umsetzung ermittelt wurde, ist CrossSite Scripting weiterhin mglich. Hierfr muss in naher Zukunft ein Konzept zur Vermeidung dieser Attacken erstellt werden. Ein sehr erfolgversprechender Ansatz knnte in diesem Zusammenhang das Escapen der Ein- und Ausgaben sein. Hierfr knnte ein Filter im WebSphere implementiert werden, welcher alle Requests vor dem Ausfhren der Anwendung entsprechend umwandelt. Ein anderer Ansatz hierfr wre ein Umbau des bereits bestehenden Request Validators. Da in einem Abschnitt der Anwendung weiterhin HTML-Elemente bermittelt werden mssen, knnte entweder die Umwandlung fr diesen Bereich abgeschaltet werden oder man verbietet solche HTML-Elemente, welche fr Cross-Site Scripting notwendig sind.
Martin Schler
Seite 76 von 85
9. Abschlieende Betrachtungen
Entscheidet man sich fr die Blacklist-Variante muss man regelmig berprfen, ob die Liste noch den aktuellen Sicherheitsmanahmen entspricht. Erst wenn gegen Cross-Site Scripting ein passendes Konzept erstellt und umgesetzt wurde, kann die Usibility fr den Anwender erhht werden.
Martin Schler
Seite 77 von 85
Literaturverzeichnis
[AB01] Andrea Back, Jorg Becker und Wolfgang K.: Lexikon der Wirtschaftsinformatik. Springer-Verlag, 2001 [Bee06] Beeger, Robert F.: Hibernate - Persistenz in Java-Systemen mit Hibernate 3. dpunkt-Verlag, 2006 [Bet] Betz, Johann: Sicherheitsaspekte in Kommunikationsnetzen Sicherheitsaspekte in Kommunikationsnetzen SQL Injection. www.ks.uni-freiburg. de, Abruf: 10.11.2011 [Bre] Breitner, Caroline Neufert; Michael H.: Mit Zertizierungen in eine sicherere Informationsgesellschaft. http://www.iwi.uni-hannover.de/ publikationen/IWIDP10k.pdf, Abruf: 07.11.2011 [Buna] Bundesamt fr Sicherheit in der Informationstechnik: BSIStandard 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 fr Sicherheit in der Informationstechnik: ITGrundschutz-Kataloge. https://gsb.download.bva.bund.de/BSI/ ITGSK12EL/IT-Grundschutz-Kataloge-12-EL.pdf, Abruf: 07.11.2011 [Bunc] Bundesamt fr Sicherheit in der Informationstechnik: Lagebericht 2007. https://www.bsi.bund.de/SharedDocs/Downloads/DE/ BSI/Publikationen/Lageberichte/lagebericht2007_pdf.pdf?__blob= publicationFile, Abruf: 09.02.2012 [Bund] Bundesamt fr Sicherheit in der Informationstechnik: Leitfaden der Informationssicherheit. https://www.bsi.bund.de/SharedDocs/ Downloads/DE/BSI/Grundschutz/Leitfaden/GS-Leitfaden_pdf.pdf?__ blob=publicationFile, Abruf: 07.11.2011
Martin Schler
78
[Bune] Bundesamt fr Sicherheit in der Informationstechnik: Sicherheit 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 Hibernate. 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 [Hl] Hlterhoff, 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 WebSphere 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 Schler
79
[ORD] ORDIX AG: Caching in Hibernate. http://www.ordix.de/ORDIXNews/ 3_2006/JavaXML/hibernate.html, Abruf: 23.02.2012 [OWA] OWASP: Die 10 hugsten Sicherheitsrisiken fr Webanwendungen. 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 ITSicherheit 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 Marktbersicht. 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 [Tl] Tllner, Christian: IT Sicherheit - Grundlagen Teil 2. 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 grten Gefahren Die grten Gefahren: 5 IDC-Ratschlge fr mehr IT-Sicherheit. http://www.cio.de/ knowledgecenter/security/2255199/index.html, Abruf: 09.02.2012
Martin Schler
80
Abbildungsverzeichnis
2.1 2.2 Logische Komponenten der Web-Anwendung . . . . . . . . . . . . . . Schematische Darstellung der Kopplung von OpenCMS und der WebAnwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bedeutung der verschiedenen Gefahrenbereiche . . . . . . . . . . . . Konsequenzen aus Angrien auf die IT-Sicherheit von Firmen . . . Erstellung des Sicherheitskonzeptes . . . . . . . . . . . . . . . . . . Top zehn Risiken fr die Anwendungssicherheit aus dem Jahr 2010 Fehlermeldung vom Request-Validator SQL-Fehlermeldung der Datenbank . . Zwlf Datenstze ohne SQL-Injektion . Datenstze mit SQL-Injektion . . . . . Datensatz ohne SQL-Injektion . . . . . Datensatz mit SQL-Injektion . . . . . . XSS-Attacke . . . . . . . . . . . . . . . Fehlermeldung von der DB2-Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9 13 14 16 19 25 27 27 28 29 29 30 30
3.1 3.2 3.3 3.4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 5.1 6.1 6.2 6.3 7.1 8.1 8.2 8.3 8.4 8.5
Aufbau einer Web Application Firewall . . . . . . . . . . . . . . . . . 33 Objektzustnde von Hibernate . . . . . . . . . . . . . . . . . . . . . . 40 Beispiel einer User-Tabelle . . . . . . . . . . . . . . . . . . . . . . . . 40 Darstellung des Hibernate-Caches . . . . . . . . . . . . . . . . . . . . 46 Sequenzdiagramm der CKMap . . . . . . . . . . . . . . . . . . . . . . 52 Test zum Anzeigen der Fehlermeldung . . . . . . . . Test zur Manipulation der Suchanfrage . . . . . . . . Notizfeld der Web-Anwendung nach dem Abspeichern XSS-Attacke mit Prepared Statements . . . . . . . . Testflle mit Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 70 71 71 72
Martin Schler
81
Tabellenverzeichnis
3.1 5.1 5.2 Einteilung des Schutzbedarfs . . . . . . . . . . . . . . . . . . . . . . . 17 Prferenzmatrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Nutzwertanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Martin Schler
82
Listings
3.1 3.2 3.3 3.4 3.5 4.1 4.2 5.1 6.1 6.2 6.3 6.4 6.5 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 Beispiel einer Java-Methode fr ein Login . . . . . . Beispiel fr Select-Anweisungen fr SQL-Injektion . Beispiel fr Update-Anweisungen fr SQL-Injektion SQL-Injektion zum Lesen der passwd-Datei . . . . . Beispielcode fr Cross-Site Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 21 21 22 23
Verwendete SQL-Befehle um Daten zu anzuzeigen . . . . . . . . . . . 27 Verwendete SQL-Befehle um Daten zu ndern . . . . . . . . . . . . . 28 Beispiel fr eine Prepared Statement-Anweisung . . . . . . . . . . . . 34 XML-Mapping-Klasse . . . . . . . . . . . Getter- und Setter-Klasse . . . . . . . . . Mapping-Klasse mit Annotations . . . . . Codebeispiel fr eine HQL-Anweisung . . . Codebeispiel fr eine Abfrage mit Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 41 42 44 45 49 50 51 53 54 54 55 57 59 59 60 61 61
Die Kongurationsdatei von Hibernate (Hibernate.cfg.xml) . . . . . Aufbau der Datei Hibernateutil . . . . . . . . . . . . . . . . . . . . Auszug aus der Mapping-Datei mit Annotations . . . . . . . . . . . Beispiel fr HQL-Anweisungen in den Mapping-Dateien . . . . . . . nderungen an der CKFactory . . . . . . . . . . . . . . . . . . . . Umwandlung des Hibernate-Objektes . . . . . . . . . . . . . . . . . Auszug aus dem Quellcode der updateKampa()-Methode . . . . . . nderungen in der Dialog-Schicht . . . . . . . . . . . . . . . . . . . Beispiel fr eine Prepared Statement-Anweisung . . . . . . . . . . . Beispiel fr eine Prepared Statement-Anweisung mit benannten Parametern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.11 Quellcode der NamedParameterStatement-Methode 76 . . . . . . . . 7.12 Auszug aus der parse()-Methode 77 . . . . . . . . . . . . . . . . . . 7.13 Beispiel fr eine Methode zum Setzen von Parametern 78 . . . . . .
Martin Schler
83
Listings 7.14 7.15 7.16 7.17 7.18 7.19 8.1
Fachhochschule Schmalkalden 2012 Auszug aus der Methode getResultsetBestandUebersicht() . . . . Auszug aus der Methode getWhereKlauselSuchbegri . . . . . . . Auszug aus der Methode setNamedMap . . . . . . . . . . . . . . . Auszug aus dem Quellcode zum Updaten von Datenbankeintrgen Quellcode zum Erzeugen eines Update-Strings . . . . . . . . . . . Quellcode zum Setzen von Parametern mit Hilfe einer CKMap . . . . . . . . . . . . . . 63 64 64 65 66 66
Auszug aus einem Selenium-Testfall fr das Setzen eines Versanddatums 73
Martin Schler
84
Eidesstattliche Erklrung
Ich versichere an Eides Statt durch meine eigenhndige Unterschrift, dass ich die vorliegende Arbeit selbststndig und ohne fremde Hilfe angefertigt habe. Alle Stellen, die wrtlich oder dem Sinn nach auf Publikationen oder Vortrgen anderer Autoren beruhen, sind als solche kenntlich gemacht. Ich versichere auerdem, dass ich keine andere als die angegebene Literatur verwendet habe. Diese Versicherung bezieht sich auch auf alle in der Arbeit enthaltenen Zeichnungen, Skizzen, bildlichen Darstellungen und dergleichen. Die Arbeit wurde bisher keiner anderen Prfungsbehrde vorgelegt und auch noch nicht verentlicht.
Gorsleben, den 30.04.2012

Ort, Datum Martin Schler
Martin Schler
85

Konzept Zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion Am Beispiel einerWeb-Anwendung

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Konzept Zur Absicherung einerJ2EE-Anwendung gegenSQL-Injektion Am Beispiel einerWeb-Anwendung

Загружено:

Авторское право:

Доступные форматы

Masterarbeit

Fachhochschule Schmalkalden 2012 24 24 24 25 25 26 26 29 30 32 32 33 34 35 36 39 39 40 41 42 44 44 44 45 45 46 46 48 48 48 51 52 58 59 62

Fachhochschule Schmalkalden 2012

Fachhochschule Schmalkalden 2012

Fachhochschule Schmalkalden 2012

1.5 Aufbau der Arbeit

Fachhochschule Schmalkalden 2012

2.1 Das Unternehmen Inverso GmbH

2. Grundlagen und Diplom-Kaufmann Harry Maack.

Fachhochschule Schmalkalden 2012

2.2 Die Web-Anwendung

2.2.1 Zweck der Web-Anwendung

Fachhochschule Schmalkalden 2012

2.2.2 Architektur der Web-Anwendung

Vgl. [Invc] Vgl. [Inva] 4 Vgl. [Inva]

Fachhochschule Schmalkalden 2012

Abbildung 2.1: Logische Komponenten der Web-Anwendung

Fachhochschule Schmalkalden 2012

Fachhochschule Schmalkalden 2012

auf alle Inhalte ber eine einheitliche Oberche gesteuert wird.

2.4 Structured Query Language

2.5 Java Database Connectivity

2.6 Java Reection

2.7 Rational Application Developer

Vgl. Vgl. 8 Vgl. 9 Vgl.

[ConoA] Seite 26-30 [AB01] Seite 432 [Hor] [Ull]

Fachhochschule Schmalkalden 2012

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

3.1 Denition und Zielsetzung

Vgl. [Bre] Seite 3 Vgl. [Bunb] Seite 16 15 Vgl. [Bund] Seite 10

Fachhochschule Schmalkalden 2012

Abbildung 3.1: Bedeutung der verschiedenen Gefahrenbereiche

Vgl. Vgl. 18 Vgl. 19 Vgl. 20 Vgl.

[Bunb] Seite 11 [Bunc] Seite 10 [Bunc] Seite 10 [Wol] [Wol]

Fachhochschule Schmalkalden 2012

3.2 Kern-Schutzziele der Informationssicherheit

Vgl. [Tl] Vgl. [Sch]

3. Die Informationssicherheit Vertraulichkeit

Fachhochschule Schmalkalden 2012

Vgl. [Sch] Vgl. [Sch] 25 Vgl. [Sch]

Fachhochschule Schmalkalden 2012

3.3 Sicherheitskonzept fr eine Softwareanwendung

Abbildung 3.3: Erstellung des Sicherheitskonzeptes

Vgl. [Buna] Seite 36

Fachhochschule Schmalkalden 2012

normal hoch sehr hoch

Tabelle 3.1: Einteilung des Schutzbedarfs

Vgl. [Buna] Seite 36-70

Fachhochschule Schmalkalden 2012

3.4 Ermittlung von Sicherheitslcken durch Penetrationstest

3.5 Sicherheitslcken in Web-Anwendungen

Vgl. [Rey05] Seite 1 -10 Vgl. [OWA]

Fachhochschule Schmalkalden 2012

Fachhochschule Schmalkalden 2012

Fachhochschule Schmalkalden 2012

Fachhochschule Schmalkalden 2012

Fachhochschule Schmalkalden 2012

3.5.2 Cross-Site Scripting

4 Aktueller Stand der Anwendung

4.1 Vorhandene Sicherheitsmechanismen

4. Aktueller Stand der Anwendung

Fachhochschule Schmalkalden 2012

der Intranet-Anwendung gegenber SQL-Injektion und Cross-Site Scripting gesenkt werden.