Diese Arbeit geht vor allem auf Probleme ein, welche bei Webapplikationen durch die Verwendung des zustandslosen HTTP-Protokolls entstehen. Das Grundkonzept ist es eine so genannte Webtransaktion zu schaffen, mit der man die Möglichkeit hat SQL-Requests über Sessionmanagement zu bündeln und in einer Transaktion auszuführen. Diese Arbeit gibt einen Überblick über allgemeine Transaktionskonzepte und Lösungen zum sicheren Sessionmanagement. Es wird besprochen, welche Voraussetzungen Systeme und Applikationen erfüllen müssen um diese Techniken erfolgreich implementieren zu können. Diese beiden Konzepte bilden dann die Grundlage für die Möglichkeit SQL-Transaktionen über mehrere HTTP-Requests zu bilden.

This paper deals with the problems of web-applications, which come up with the usage of the stateless HTTP protocol. The basic conecept is to design a so called “web transaction”, which provides the functionality to group SQL-Requests and commit them with a transaction. The basic transaction concepts and different techniques of session management are discussed in this paper. It is marked, which requirements systems or applications need to provide a save implementation of these techniques. The concepts of transactions and session management are then used to build a simple “webtransaction”, which allows users to use transactions even when getting the data from different HTTP requests.

-2-

& ' +' , % - . , "/ # 0' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 1 & ' +' & ' % # * % * 2 % 3 ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 1 & ' +' ' # 2 - 3 ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 1

& ' +' +' . ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 1 & ' +' +' & ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 4 & ' +' +' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 4 & ' +' +' +' 0 ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 4 & ' +' +' ' # ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 4 & ' +' ' , , * 2 , 3 ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 4

& ' ' . , 5 "% ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 6

& ' ' / * ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 6 & ' 1' , ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 7 & ' 1' & ' ! ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 7 & ' 1' ' 8 9 : ! ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 7

& ' 4' ' $ < # ; * ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' & &

& ' 6' ( / - ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' & &

+' +' & ' ? @ "? 0 5 ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' & 1 +' +' ' ? @ "5 ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' & 4

+' ' - ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' & 7

-3-

+' 1' & ' = ? ! " ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 1 +' 1' ' A ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 4 +' 1' +' - ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 6

+' 1' ' , . ,' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' + +' 4' % ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' +& +' 4' & ' B ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' +& +' 4' ' A 9 ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ++ +' 4' +' 0 ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' +

% : # ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' +4 ! : # C ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' +6

-4-

1. Transaktionsmanagement

1.1. Konsistente Abwicklung eines Geschäfts

In der Regel werden für das Festhalten von Geschäftsdaten Einträge in relationale Datenbanken benötigt. Diese Art der Datenbank-Management-Systeme haben meist die Daten in einer Vielzahl von unterschiedlichen Tabellen gespeichert um keine Redundanzen und daraus mögliche Widersprüche zuzulassen. Ein konsistentes Datenmodell wird durch das Anwenden der drei Normalisierungsformen gewährleistet.

Geschäftstransaktionen, wie zum Beispiel der Kauf eines Produkts in einem Webshop, bewirken aber, dass

1. der Lagerbestand des Produkts um X reduziert wird. 2. die Daten des Käufers erfasst werden

3. die Auslieferungs- und Rechnungsdaten erfasst und festgehalten werden Was passiert nun wenn, aus welchem Grund auch immer, die Änderungen auf der Datenbank nicht vollkommen erfasst werden können. So könnte es vorkommen, dass ein Kunde ein Produkt erhält, ohne eine Rechnung zahlen zu müssen. Oder es kann vorkommen, dass die Interaktion mit dem Kunden problemlos funktioniert, jedoch der Lagerbestand nicht korrigiert wurde.

Solche Fälle sind zwar sehr selten, jedoch wenn sie auftreten extrem problematisch. Um diesem Problem entgegenzuwirken gibt es so genannte Transaktionen.

1.2. Transaktionen

„Als Transaktion bezeichnet man in EDV-Systemen eine Folge von Verarbeitungsschritten, die nur gemeinsam oder gar nicht durchgeführt werden dürfen und die Datenbank von einem konsistenten Zustand in einen anderen ebenfalls konsistenten Zustand überführen sollen“ 1

Die Änderungen der Transaktion dürften demnach erst übernommen werden, wenn die Transaktion vollständig abgearbeitet ist. Wird aus irgendeinem Grund die Transaktion vor der Beendigung abgebrochen, zum Beispiel durch einen Programmfehler oder einen Stromausfall, so müssen die Daten auf den Zustand vor Beginn der Transaktion zurückgesetzt werden. Man nennt diesen Schritt rollback. Wird das Ende der Transaktion erwartungsgemäß erreicht so wird die Veränderung der Daten durch einen commit-Befehl bestätigt und permanent gespeichert.

Transaktionen müssen folgenden vier Kriterien entsprechen: Atomarität, Konsistenz, Isolation und Dauerhaftigkeit (englisch ACID). Aufgrund der letzten Bedingung lassen sich ACID-Transaktionen nicht schachteln. 2

¹ http://de.wikipedia.org/wiki/Transaktion_%28Informatik%29, 7.5.2005, 23:04

² vgl. ebda, 7.5.2005, 23:05

-5-

1.3. Das ACID-Prinzip

Das Akronym ACID beschreibt erwünschte und erforderliche Eigenschaften bei Transaktionen von Datenbanken oder verteilten Systemen. Ohne diese Eigenschaften kann die Integrität der Daten in einem DBMS bei Transaktionen nicht gewährleistet werden.

1.3.1. Atomizität/Atomarität (Atomicity)

Im Allgemeinen wird eine Transaktion als eine „Logical Unit of Work“ (LUW) bezeichnet. Das beschreibt im Grunde eine der wesentlichsten Eigenschaften einer Transaktion: Sie ist die kleinste, nicht mehr zerlegbare Einheit aus Verarbeitungsschritten - Sie ist atomar. Ein Kunde einer Bank will zum Beispiel einen bestimmten Betrag von seinem Konto auf das Konto eines Anderen transferieren. Diese Transaktion beinhaltet nun im Grunde zwei Schritte. Es muss der Betrag vom Konto des Auftraggebers abgebucht und der gleiche Betrag auf dem Konto des Empfängers eingezahlt werden. Um diese Transaktion erfolgreich abzuschließen müssen beide Aktionen erfolgreich ausgeführt werden. Kann eine Aktion nicht ausgeführt werden so muss die komplette Transaktion fehlschlagen. Das Prinzip der Atomarität besagt, dass alle Aktionen einer Transaktion erfolgreich abgearbeitet werden müssen um die Transaktion erfolgreich zu beenden. Und umgekehrt, schlägt die Transaktion fehl wenn nur ein einziger Schritt nicht ordnungsgemäß abgearbeitet werden konnte. 3

1.3.2. Konsistenz (Consistency)

In einer Datenbank, hat man zur Aufrechterhaltung der Konsistenz, die Möglichkeit referentielle und entitäre Integritätsregeln zu definieren. Eine Transaktion, welche Daten verändert muss gewährleisten, dass die Datenbestände in der Datenbank sowohl nach einer erfolgreichen als auch nach einer fehlgeschlagenen Transaktion konsistent sind. Das bedeutet dass keine Integritätsregeln verletzt sind. Der Datenbestand kann während der Ausführung der Transaktion unkonsistent sein, dieser Zustand ist aber für andere Abfragen nicht sichtbar. Nach Beendigung der Transaktion muss jedoch wieder ein konsistenter Zustand hergestellt werden, natürlich nur unter der Bedingung dass der Datenbestand der Datenbank vorher konsistent war. 4

1.3.3. Isolation

Wenn mehrere Transaktionen gleichzeitig laufen kann sich das Problem ergeben, dass eine Transaktion Daten abfragen will, welche eine andere Transaktion gerade ändert aber noch nicht freigegeben (committed) hat. Das Isolationslevel sagt aus in welchem Maß eine Transaktion in eine andere Transaktion „eingreifen“ darf. Grundsätzlich gilt: je niedriger das Isolationslevel, desto höher ist die Möglichkeit des gleichzeitigen Zugriffs von Transaktionen und desto größer ist die Fehleranfälligkeit. Ein Mehr an gleichzeitigen Zugriffen jedoch beschleunigt den Datenbankzugriff enorm. Diese Eigenschaft hat enorme Auswirkungen auf die Performance der Datenbank, deshalb gilt es den richtigen Weg zwischen Isolation und Performance zu finden. 5

³ vgl. http://www.developer.com/java/data/article.php/10932_2246481_1, 7.5.2005, 23:07

⁴ vgl. ebda

⁵ vgl. ebda

-6-

Auf dem niedrigsten Isolationslevel haben Transaktionen und Abfragen die Möglichkeit Werte zu lesen welche von anderen Transaktionen gerade bearbeitet werden und noch nicht committed wurden. Wenn die erste Transaktion fehlschlägt und die Daten wiederhergestellt werden hat die Abfrage einen ungültigen Wert zurückgegeben. Dieser Level der Isolation, auch als „dirty read“ bezeichnet, kann fehlerhafte Ergebnisse zurückliefern, hat aber die höchste Möglichkeit an gleichzeitigen Zugriffen.

1.3.3.2. read committed

Dieser Isolationslevel erlaubt Abfragen nur auf Daten zuzugreifen, welche von Transaktionen committed wurden. Es ist im Gegensatz zum dirty read stärker eingeschränkt und bietet deshalb weniger Möglichkeiten zu Nebenläufigkeiten von Transaktionen. Jedoch hilft es auch Probleme des vorangegangenen Levels zu beheben.

1.3.3.3. repeatable read

Bei diesem Level wird einer Transaktion gewährleistet, dass die Daten gesperrt werden welche sie liest bis die Transaktion beendet wird. Der Name „repeatable read“ kommt davon, dass die Transaktion denselben Datensatz immer wieder lesen kann und es garantiert ist, dass dieser bis zur Beendigung der Transaktion unverändert bleibt.

1.3.3.4. serializable

Dieser Level hat den höchsten Isolationslevel. Er kombiniert die Eigenschaften des repeatable read und des read committed. Es gewährleistet, dass Transaktionen welche lesend oder schreibend auf einen Datensatz zugreifen, welcher von der Transaktion verwendet wurde, egal ob lesend oder schreibend, in eine Warteschleife versetzt werden. Die Transaktionen werden dann seriell abgearbeitet.

1.3.4. Dauerhaftigkeit/Durabilität (Durability)

Diese Eigenschaft von Transaktionen bezieht sich darauf, dass die Effekte der Transaktion auch nach der Beendigung der Transaktion und/oder der Applikation verfügbar sind. Das bedeutet Zustandsänderungen innerhalb einer Transaktion müssen auf einem persistenten Speichermedium gespeichert werden.

Transaktionen sind auch wiederherstellbar (recoverable). Sollten die Daten auf dem persistenten Speichermedium verloren gehen, so kann man die Daten wiederherstellen. Vorausgesetzt natürlich die notwendigen administrativen Schritte wurden ausgeführt. Jede Veränderung durch eine Transaktion muss dauerhaft festgehalten werden bis eine andere valide Transaktion diese Daten verändert. 6

⁶ vgl. http://www.developer.com/java/data/article.php/10932_2246481_1, 7.5.2005, 23:07

-7-

1.4.

1.5. Parallelität

Parallelität ist die Fähigkeit eines Datenbankservers mehrere Transaktionen gleichzeitig abzuarbeiten ohne, dass diese sich gegenseitig behindern. Hier kommen Sperrprotokolle und Isolationslevel zum tragen.

Ein Angestellter einer Bank, welcher gerade einen Kunden betreut muss zum Beispiel jederzeit Zugriff auf das Konto des Kunden haben. Die Transaktionen, welche er in Auftrag gibt müssen im Grunde parallel zu den anderen Transaktionen abgearbeitet werden, da er nicht warten kann bis die Datenbank gerade von keinem anderen Benutzer verwendet wird.

-8-

Eine besondere Auswirkung auf die Parallelität hat die Größe der Transaktionen. Enthält eine Transaktion keine logische Arbeitseinheit so können Inkonsistenzen beim Datenbestand auftreten. Beinhalten Transaktionen Aktionen, welche nicht zu der Logical Unit of Work gehören, so kann der Rollback-Befehl unnötige Arbeit löschen.

Es gibt viele Faktoren, die sich auf die richtige Länge einer Transaktion auswirken, je nach Art der Anwendung und der Umgebung.

1.6. Deadlock

Ein Deadlock ist eine Situation, in welche sich zwei Transaktionen durch das Sperren von Datensätzen gegenseitig behindern. So sperrt zum Beispiel die Transaktion1 den Datensatz X und die Transaktion2 den Datensatz Y. Transaktion benötigt aber den Datensatz Y und T2 benötigt den Datensatz Y um weiterzuarbeiten. Dadurch werden beide Transaktionen beim weiterarbeiten gehindert. Um zumindest eine der beiden Transaktionen erfolgreich abschließen zu können muss die andere Transaktion den gesperrten Datensatz wieder freigeben. Dies erfolgt durch ein Timeout des Transaktionsmonitors (siehe Abbildung 10).

Es gibt zwei unterschiedliche Arten von Deadlocks:

1.6.1. Shared Lock

Man hat nur lesenden Zugriff auf die Zeile einer Datenbanktabelle. Man kann also keine Änderungen an diesem Datensatz vornehmen bis der Shared Lock gelöst wurde. Andere Transaktionen und Benutzer können zur gleichen Zeit ebenfalls mit einem Shared Lock auf diese Tabellenzeile zugreifen.

1.6.2. Exklusive Lock

Es kann immer nur ein Benutzer, beziehungsweise eine Transaktion, einen Exklusive Lock auf eine Zeile einer Tabelle ausführen. Andere Transaktionen können weder mit einem Shared Lock noch mit einem Exklusive Lock auf diese Zeile zugreifen.

Der Exklusive Lock hat immer das Ziel die Tabellenzeile mit einem Update zu aktualisieren.

-9-

1.7. Logging Konzepte

Datenbanken erzielen ihre ACID Eigenschaften anhand des so genannten „Undo-Redo Loggings“. Veränderungen auf der Datenbank durch Transaktionen werden in den so genannten Transaction Logs gespeichert. Wenn während der Transaktion ein Fehler auftritt werden diese Transaction Logs benutzt um die Aktionen dieser Transaktion rückgängig zu machen. Das bedeutet es werden alle Effekte welche eine fehlerhafte Transaktion auf eine Datenbank hatte zurückgesetzt. Diese Logfiles werden auch zur Crash-Recovery benutzt. So können Datenbanken anhand dieser Files den letzten konsistenten Zustand nach einem Datenbankabsturz wiederherstellen. 7

Das Undo-Redo Log wird auch oft als „Before Image File“ oder „BI-File“ bezeichnet. Es speichert den Zustand der Tupel, welche die Transaktion verändern will. Das Before-Image kann entweder in einem BI-File gespeichert werden, es kann aber auch, abhängig vom verwendeten Datenbanksystem, in so genannten before image extents abgelegt sein.

1.7.1. Wiederholen einer Veränderungen

Man kann lediglich mit der alten Version der Datenbank und dem After Image Log eine Veränderung wiederherstellen.

⁷ vgl. http://www.peg.com/techpapers/monographs/logging/logging.html, 7.5.2005, 23:11

-10-

1.7.2. Zurücksetzen einer Veränderung

Mit dem neuen Datenbankblock und dem Before-Image Log kann man den alten (konsitenten) Zustand der Datenbank wieder herstellen.

1.8. Two Phase Commit

Two Phase Commits werden verwendet wenn Änderungen auf zwei Datenbanksystemen innerhalb einer Transaktion gemacht werde müssen. Zu diesem Zweck benötigt man einen Transaktionsmanager, welcher die Aktivitäten zwischen den beiden Datenbanksystemen überwacht und steuert. 8

• Beispiel eines erfolgreichen TPCs

⁸ vgl. Arno Schmidhauser: Two Phase Commit, 6.2004, S.2

-11-

• Beispiel eines fehlgeschlagenen TPCs

1.9. Beispiel einer Transaktion

Ein Kunde will in einem Webshop ein Buch über Transaktionsmanagement kaufen. Auf der Ebene der Datenbank besteht dieser Task aber aus mehreren Aktionen:

• Es muss eine Rechnung in die Rechnungstabelle geschrieben werden.

• Es müssen die Kundendaten des Käufers erfasst werden.

• Es muss der Lagerbestand um eine 1 verringert werden. Der generierte SQL-Code sollte wie folgt aussehen:

Code

Der equivalente Java-Code, der den Zugriff auf eine Oracle Datenbank mittels JDBC veranschaulicht, sieht wie folgt aus.

Code

-13-

2. Transaktionen im Web

Wie kann man nun Transaktionen auf Datenbanken anwenden, wenn man die Daten, welche man benötigt aus mehreren HTTP-Requests, sprich von mehreren Webseiten, erhält.

2.1. Single-User Umfeld

Im Single-User Umfeld ist dies einfach. Man kann die Datenbank bei jeder Transaktion sperren.

2.2. Multi-User Umfeld

Im Multi-User Umfeld ist es schon deutlich komplizierter. Man muss nun versuchen die SQL-Befehle zu bündeln. Um dies zu erreichen, muss man wieder auf das Sessionmanagement zurückgreifen.

Man muss nun ein System konzipieren, welche die SQL-Befehle in der Session speichert, und dann, in eine Transaktion bündelt und ausführt.

3. Sessions

3.1. Was sind Sessions?

Die Definition für eine Session laut Wikipedia:

„Eine Sitzung bezeichnet in der EDV eine stehende Verbindung eines Clients mit einem Server. (…) Sitzungsdaten werden serverseitig gespeichert und werden oft für komplexere Transaktionen benötigt.“ 9

Typischerweise ist eine Session (dt. Sitzung) eine Verbindung zwischen einem einzelnen Client und einem Server. 10

3.2. Warum Sessions?

Im Vergleich zu regulären Client-Server-Applikationen haben Web-Applikationen einen entscheidenden Nachteil, der sich aus dem zustandslosen HTTP-Protokoll ergibt: Es werden serverseitig keine Informationen über den Zustand des jeweiligen Clients gespeichert. Bei eCommerce-Applikationen ist es aber unverzichtbar, dass ein Nutzer zum Beispiel seinen eigenen virtuellen Warenkorb besitzt. Deshalb muss zwangsweise ein Sitzungsmanagement zum Austausch von Informationen zwischen mehreren Seiten eingesetzt werden.

3.3. HTTP

Um sich der Herausforderung der HTTP-Sessions stellen zu können ist es wichtig mit dem grundlegenden Aufbau des Webs vertraut zu sein: dem HTTP.

HTTP steht für Hypertext Transfer Protokoll und ist damit laut Bezeichnung ein Protokoll zum Übertragen von Hypertext-Dokumenten. Es ist wie zum Beispiel FTP oder SMTP ein Protokoll, welche der TCP-Protokollstapel bereitstellt. Im ursprünglichen Sinne wurde das HTTP zum Übertragen von Webseiten im WorldWideWeb entwickelt. Durch Erweiterungen wie Headerinformationen und Fehlercodes wird es jedoch zunehmend auch zum Austausch von beliebigen Daten benützt. Zurzeit wird nach HTTP/0.9 und HTTP/1.0 die dritte Version, HTTP/1.1, verwendet.

Aller Voraussicht nach wird in Zukunft das Protokoll selbst an Bedeutung verlieren. Spezielle Erweiterungen oder Nebenprotokolle wie der Webservice SOAP oder HTTP-Query werden früher oder später das HTTP-Protokoll entscheidend erweitern. 11

⁹ http://de.wikipedia.org/wiki/Sitzung_%28Informatik%29. 2005.08.02, 21:15

¹⁰ vgl. ebda

¹¹ vgl. http://de.wikipedia.org/wiki/Http, 7.5.2005, 23:19

-15-

Abbildung 10 - TCP/IP Referenzmodell

3.3.1. Request-Response Modell

„Beim HTTP dreht sich alles um Fragen und Antworten“ ¹² . Im Grunde funktioniert eine Transaktion beim HTTP immer nach demselben Prinzip. Zuerst wird vom Client eine Verbindung angefordert, welche dann vom Server bestätigt wird. Der Austausch der Daten beginnt, wenn die Verbindung zustande gekommen ist. Dazu schickt der Client eine Anfrage zum Server, in welcher er um die entsprechende Datei bittet. Die Antwort kann entweder eine HTTP-Fehlermeldung oder die entsprechende Datei sein.

Falls die Verbindung zwischenzeitlich abgebrochen wird so bietet HTTP, im Gegensatz zu FTP, keinerlei Wiederherstellungsmöglichkeiten. Die Verbindung muss erneut aufgebaut werden und „das Spiel beginnt von vorn“ ¹³ .

3.3.1.1. Request-Syntax

So könnte zum Beispiel eine HTTP-Anfrage aussehen.

Code:

Anhand dieses Beispiels kann man die Struktur eines HTTP-Requests einfach erkennen. In der ersten Zeile wird die Datei angeben, welche angefordert wird. Auf der ersten Stelle des HTTP-Requests wird immer die Abrufmethode angegeben, welche für diese spezielle Anfrage verwendet wurde (z.B.: GET). Die unterschiedlichen Abfragemethoden werden später noch genauer erläutert. Auf der zweiten Position befindet sich das File, welches angefordert wird (z.B.: /index.jsp). Der Ausdruck HTTP/1.1 gibt die Version des verwendeten Protokolls an.

¹² http://www.html-world.de/program/http_2.php, 09.02.2005, 18:23

¹³ ebda, 09.02.2005, 18:30

-16-

Nach dieser Zeile folgt der so genannte HTTP-Header. Die Informationen, welche in diesem enthalten sind, sind mehr oder weniger optional. Der Standardheader liefert zum Beispiel Informationen über den verwendeten Browser, gewünschte Dateiformate oder die Art der Verbindung.

Beim HTTP werden alle Zeilen mit einem (Zeilenvorschub und Zeilenumbruch beendet.

3.3.1.2. Response-Syntax

Am besten lassen sich HTTP-Responses wieder anhand eines Beispiels erklären.

Code:

Wie bei der Anfrage wird auch bei der HTTP-Antwort zuerst eine allgemeine Nachricht übermittelt (1. Zeile). Sie schreibt damit dem Client vor welche HTTP-Version zu verwenden sei (z.B.: HTTP/1.1). Als nächstes wird ein so genannter HTTP-Responsecode gesendet. Der Responsecode 200 zeigt dem Client zum Beispiel, dass das File gefunden wurde und nun gesendet wird. Im Gegensatz dazu würde der Code HTTP 404: Nicht gefunden zeigen, dass die angeforderte Ressource nicht gefunden wurde.

3.3.2. Request-Methoden

Die RFC-2616 ¹⁴ definiert mehrere Methoden um Informationen von einem Server über das HTTP anzufordern. Im folgenden Abschnitt werden die drei, für unsere Problemstellung wichtigsten, Methoden und deren Vor- und Nachteile etwas genauer erklärt.

3.3.2.1. GET-Methode

Die GET-Methode war im HTTP/0.9 die einzige Möglichkeit Daten von einem Server über HTTP anzufordern. Man hat bei einem GET-Request auch die Möglichkeit Parameter an eine bestimmte Seite zu übergeben.

Wenn man zum Beispiel die Seite http://www.example.de/index.jsp?id=1 aufruft wird diese URL wie folgt aufgelöst

Code:

¹⁴ http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc2616.html

-17-

Der Client verbindet sich dann zum Host www.example.de und fordert die Seite index.jsp an.

Des Weiteren übergibt der Client noch das Argument ID mit dem Wert 1. Man hat danach die Möglichkeiten mit Programmiersprachen wie PHP oder Java diese Argumente abzufragen und die Seite dementsprechend zu gestalten.

Wichtig ist auch noch die Codierung der Adressen. Möchte ein User ein Zeichen senden, welches in diesem Kontext eine bestimmte Bedeutung hat wird es in das URL-codierte Format umgewandelt. Man spricht hier von URL-encoding.

Alle Sonderzeichen und Buchstaben, welche nicht im englischen Sprachgebrauch enthalten sind, werden dabei durch ein Prozentzeichen gefolgt von dem ASCII-Wert des Zeichens in Hexdezimal ersetzt. So wird zum Beispiel ein Leerzeichen durch %20 (ASCII-Wert) ersetzt. So wird die URL

http://www.example.de/search.jsp?Suchbegriff=Heizölrückstoß in diese URL umgewandelt

http://www.example.de/search.jsp?Suchbegriff= Heiz%C3%B6lr%C3%BCcksto%C3%9F

3.3.2.2. POST-Methode

Die POST-Methode kommt im Grunde aus der Formulartechnik und dient dazu Formulardaten an einen Server zu übertragen. HTTP hat jedoch keinen Einfluss darauf wie der Server die übertragenen Daten verarbeitet.

Als Beispiel nehmen wir ein Formular, welches zu einer Personensuche dient, an. Man hat drei Eingabefelder für den Vornamen, den Nachnamen und die Email-Adresse der gesuchten Person. Der daraus entstandene Datensatz sieht dann wie folgt aus:

Code

Im Gegensatz zur GET-Methode werden bei einem POST-Request die Argumente im Body und nicht im Head der Anfrage übertragen. Ansonsten sind POST-Anfragen und GET-Requests identisch.

Code

Die Daten, die mit POST übertragen werden müssen aber nicht zwangsweise aus reinem Text bestehen. Man kann mit POST auch ganze Dateien übertragen und danach auch am Server speichern, wie zum Beispiel Dateianhänge bei Emails.

3.3.2.3. HEAD-Methode

Die Head-Methode wurde im HTTP/1.0 eingeführt und ermöglicht es einem Client die Headerinformationen eines Files abzufragen ohne es komplett übertragen zu müssen. Richtet ein Client eine HEAD-Anfrage an einen Server so werden zuerst die Verbindungsdaten übermittelt. Die HEAD-Methode entspricht im Grunde einer GET-Anfrage wobei jedoch nur der Header des GET-Requests übertragen wird.

Code

Die Antwort des Servers könnte zum Beispiel so aussehen:

Code

3.4. Cookies

Man kann nun mit HTTP zwar Requests absetzen und daraus resultierende Responses auswerten, doch man kann mit POST und GET keine Informationen auf der Clientseite abspeichern. Hier kommen nun die so genannten HTTP-Cookies ins Spiel. Was sind nun eigentlich Cookies genau:

„Ein HTTP-Cookie, auch Browser-Cookie oder einfach Cookie genannt (Cookie: aus dem amerikanischen Englisch für Plätzchen, Keks), bezeichnet Informationen, die ein Webserver zu einem Browser sendet, um dem zustandslosen HTTP-Protokoll die Möglichkeit zu geben, Information zwischen Aufrufen zu speichern.“ 15

¹⁵ http://de.wikipedia.org/wiki/HTTP-Cookie, 16.2.2005, 19:08

-19-

Wie oben schon erwähnt werden Cookies in den Headerteilen der HTTP-Requests und Responses übertragen.

Im Grunde kann man Cookies in zwei Arten unterscheiden:

• persistente Cookies:

Diese werden dauerhaft auf der Festplatte des Users gespeichert und beinhalten zum Beispiel Logindaten wie Usernamen und Passwort. Dadurch hat man die Möglichkeit automatisch einloggen zu lassen. Das heißt, die Webapplikation verwendet die Logindaten aus dem Cookie und man muss sich nicht manuell authentisieren.

• Sessioncookies:

Wie der Name schon sagt werden Sessioncookies nur für die Länge einer HTTP-Session am Leben gelassen. Danach laufen sie ab („expire“). Typischerweise wird in Sessioncookies die SessionID gespeichert.

Wie schon oben erläutert werden Cookies auf dem Endgerät, meist als Textdatei gespeichert. Der Browser sucht bei jedem Aufruf einer Webseite nach Cookies, welche von dieser Domain stammen. Falls er Cookies dieser Domain gefunden hat sendet er alle diese Cookies in seinem Request mit. Zwangsweise unterliegen Cookies den Limitierungen von 4kb Größe und 20 Cookies pro Domain.

Das Konzept der Cookies wurde ursprünglich von Netscape entwickelt und ist jetzt in der RFC-2109 definiert.

Gerade in den letzten Jahren geht der Trend immer mehr in die Richtung Cookies wegen der Sicherheitsprobleme zu deaktivieren. Das einzige Problem welches bei Cookies besteht ist, dass sie dazu verwendet werden können um Profile über das Surfverhalten zu erzeugen. So können zum Beispiel Webshop-Anbieter anhand dieser Informationen zielgruppenorientierte Werbemails schicken („targeted advertisement“). Man sollte sich jedoch vor Augen halten, dass Cookies keinerlei Informationen enthalten, welche der Anbieter nicht zuvor schon erhalten hat.

Trotzdem ein Beispiel von Cookietheft:

-20-

Filtern wir uns die interessanten HTTP-Requests heraus:

2) Es wird ein Cookie erstellt, der darauf hinweist dass sich der User für Snowboarding interessiert.

Code

3) Der Client erkennt, dass sich im übermittelten HTML-Code ein Bild befindet, welches er von einem anderen Server (adserver.example.de) anfordern muss.

4) Er fordert das Bild des adservers an und überträgt dabei den Cookie:

Code

Der Werbungserver kann nun diesen Cookie auswerten und in diesem Fall ein Werbungsbild eines Snowboarders schicken.

Für unsere Zwecke ist es auch interessant den Aufbau von Cookies etwas genauer unter die Lupe zu nehmen.

• Der Hostname des Servers. Wird hier nur der Domainname gesetzt (z.B.: example.de) so können alle Server der Subdomains auf diesen Cookie zugreifen (zB.: ad.example.de)

• Hier kann ein genauerer Pfad zur Webapplikation spezifiziert werden. Standardmäßig ist der Pfad aber auf „/“, was soviel bedeutet wie der gesamte Document-Root des Webservers.

• Wird die secure-variable auf YES gesetzt so werden Cookies nur übertragen wenn das Übertragungsprotokoll gesichert ist (HTTPS, SSL)

• Das expires Feld ist besonders für Sessioncookies wichtig. Hier wird die Lebensdauer des Cookies angegeben. Läuft dieses „Haltbarkeitsdatum“ des Cookies aus so wird dieser bei Responses nicht mehr mitgesendet.

• Hier wird der Name des Cookies, meist ein Kürzel, angegeben (z.B.: SESSIONID, username)

• Im value-Feld wird der Wert des Cookies, wie die SessionID oder der Username gespeichert.

3.5. Web-Applications

Im Allgemeinen sind Web-Applications Programme, welche auf Grundlage von HTTP die Interaktion zwischen Clients und Servern, oder anderen Systemen möglich machen. In den meisten Fällen ist der Client ein gewöhnlicher Internet-Browser wie Microsofts Internet Explorer oder Mozillas FireFox. Der Enduser sieht die Ausgabe der Webapplikation und hat die Möglichkeit über die Auswahl oder Eingabe von Daten mit dem System zu kommunizieren. Die Aufgaben, welche solche Anwendungen erfüllen können reichen von einfachen Funktionen, wie dem Durchsuchen von Datenbanken nach einem bestimmten Eintrag, bis hin zu kompliziertesten Echtzeitverkaufs-und

Inventarisierungsmanagementsystemen über mehrere Anbieter und Zwischenhändler. Diese Systeme können sowohl Geschäftstransaktionen, als auch Workflow- und Beschaffungsmanagementteile beinhalten.

Die Technologie, welche hinter Webapplikationen steckt hat sich mit unglaublicher Geschwindigkeit entwickelt. Früher wurden solche Anwendungen mit dem Common Gateway Interface (CGI) entwickelt, welche oft auf eine, auf demselben Rechner befindliche

-22-

Datenbank, zugriffen. Bei CGI wurde auch für jeden Aufruf das Programm auf dem Server erneut gestartet ohne Wissen über frühere Stati.

Heutzutage werden komplexe Webanwendungen in Programmiersprachen wie Java, Python, Perl oder Ähnlichen entwickelt und laufen oft auf verteilen Applikationsservern. Von diesen wird dann auf unterschiedliche Datenquellen wie Datenbankserver oder öffentliche Quellen zugegriffen.

• Presentation Tier

-23-

Die Präsentationsschicht ist für die Darstellung der Daten beim Enduser verantwortlich. Der Webserver stellt die Daten zur Verfügung und die Software des Clients, meist ein Browser, rendert diese Daten in ein lesbares Format. Das Darstellungsformat muss aber nicht zwingend HTML sein. Es können auch Webservices wie SOAP, UDDI oder WSDL sein. Der User kann auch bestimmte Parameter an den Webserver schicken und somit andere Daten anfordern. Zur Präsentationsschicht gehören sowohl Webserver als auch Anwendungen für den Endbenutzer wie Browser.

• Application Tier

Die Applikationsschicht ist das „Herz“ einer jeder Webapplikation. Sie beinhaltet die gesamte Geschäftslogik, bearbeitet die Usereingaben, bezieht Daten aus der Datenschicht und schickt

-24-

die bearbeiteten Daten an die Präsentationsschicht. Die Applikationsschicht beinhaltet eine Vielzahl von Technologien, wie zum Beispiel Java, PHP, CGI, .NET services, PHP oder ColdFusion welche in Applikationsservern wie Zope, JBoss oder WebSphere abgelegt sind. Eine strenge Trennung von Applikation und User Interface ermöglicht auch einen einfachen Wechsel der UI-Technologie.

• Data Tier

Die Datenschicht speichert alle Daten, welche die Applikationsschicht benötigt. Zwar bieten Applikationsserver schon die Möglichkeit temporäre Daten zu speichern, jedoch ist besonders das Aufbewahren von großen persistenten Datenmengen auf den Webservern unperformant bis unmöglich.

3.6. Maintaining State

Wie schon erwähnt ist das so genannte „User-Tracking“ besonders bei eCommerce Anwendungen unverzichtbar geworden.

Typischerweise wird die „Aufrechterhaltung des Zustandes“ über eine so genannte SessionID gewährleistet. Diese IDs werden von Webapplikationen für die eindeutige Identifizierung eines Users verwendet.

Hat sich ein User einmal erfolgreich auf einer Webseite eingeloggt wird die Information zu dieser Session serverseitig gespeichert. Die Identifikationsdaten, meist die SessionID, werden dann vom Browser bei jedem Request übertragen. Dies verhindert, dass sich User auf jeder Webseite einloggen müssen.

Zurzeit stehen drei Möglichkeiten die SessionID zu Speichern und zu Senden zur Verfügung:

• Die SessionID wird in einem Cookie gespeichert, welcher bei jedem Request

Jede dieser Techniken hat bestimmte Vor- und Nachteile. Die Auswahl der Technik, welche man für sein Sessionmanagement verwendet hängt großteils davon ab, welche Art von Service diese Webapplikation bieten sollte. Deshalb ist es unerlässlich, dass man sich mit allen drei Arten vertraut macht und deren technische Grenzen und sicherheitstechnische Limitationen kennt.

-25-

3.6.1. URL-basierendes Sessionmanagement

Wie schon oben erwähnt wird die SessionID bei dieser Technik oft in Links eingebaut ¹⁶ :

Abbildung 17 - URL-based Sessionmanagement

Code

Vorteile:

Diese Managementmethode kann sogar verwendet werden wenn die Sicherheitseinstellungen des Webbrowsers enorm hoch sind und dieser keine Cookies zulässt.

Wenn die Session keine Beschränkung der Lebenszeit auferlegt bekommen hat, ist es möglich den Link unter den Favoriten zu speichern

Man kann anderen Personen ermöglichen auf dieselben Informationen zuzugreifen, indem man Sie einfach auf die selbe URL zugreifen lässt. Nachteile:

Personen, welche den gleichen Computer benützen, haben die Möglichkeit durch die Favoriten oder den gespeicherten Verlauf Zugang zu denselben Informationen zu erhalten.

URLs werden von dazwischengeschalteten Systemen wie Proxies und Firewalls mitgeloggt. Dadurch hat jeder, der Zugang zu diesen Systemen hat auch Informationen über die benutzten SessionIDs.

Falls der Client eine neue Webseite besucht kann diese die SessionID mittels des HTTP REFERER herausfinden und im schlimmsten Fall auf die noch geöffnete Session zugreifen und Daten einsehen und verändern.

¹⁶ vgl. http://www.cgisecurity.com/owasp/html/guide.html, 7.5.2005, 23:26

-26-

3.6.2. Sessionmanagement mit Hidden Fields

Bei dieser Technik wird die SessionID in ein verstecktes Formularfeld (= hidden field) gespeichert. Wird das Formular abgeschickt wird die SessionID mit übertragen ¹⁷ .

Code

Abbildung 18 - Beispiel eines HTTP-Post Requests

Code

Vorteile:

Diese Technik kann, wie das URL-basierte Sessionmanagement, selbst bei Browsern eingesetzt werden deren Sicherheitsstufe zu hoch ist um Cookies zu erlauben.

¹⁷ vgl. http://www.cgisecurity.com/owasp/html/guide.html, 7.5.2005, 23:28

-27-

Die SessionID ist nicht im Verlauf sichtbar. Deshalb können Personen, welche den gleichen PC benutzen nicht einfach dieselbe Session nutzen. Die SessionID wird nicht im HTTP_REFERER Feld gespeichert. Deshalb können später besuchte Seiten die SessionID nicht ausfindig machen. Nachteile:

„Hidden fields“ sind nicht wirklich versteckt sondern werden nur im HTML-Inferface nicht dargestellt. Lässt man sich jedoch den source-code anzeigen kann man die SessionID einfach herauslesen.

Die Webseiten werden komplexer. Man kann nun nicht mehr einfach die SessionID in einen Link einbinden sondern benötigt Formulare um Daten abzuschicken. Diese Formulare benötigen oft eine clientseitige Pflege per JavaScript oder anderen clientseitigen Scriptsprachen. Dadurch werden die Webseiten größer, schwerer wartbar und fehleranfälliger.

Seiten, welche diese Sessionmanagementtechnik verwenden, können im Allgemeinen nicht „gebookmarked“ werden.

3.6.3. Sessionmanagement mit Cookies

Obwohl diese Technik immer mehr in Verruf gerät ist sie dennoch für bestimmte Zwecke unverzichtbar. Im Allgemeinen werden Cookies für bestimmte Domänen definiert. Bei einem Aufruf einer bestimmten Domäne werden dann alle Cookies dieser Domäne im Request mitgesandt ¹⁸ .

Abbildung 19 - Sessionmanagement mit Cookies

1) Der Client schickt einen normalen GET-Request an den Webserver

Code

¹⁸ vgl. http://www.cgisecurity.com/owasp/html/guide.html, 7.5.2005, 23:28

-28-

2) Der Webserver schickt eine Antwort, welche eine Set-Cookie Direktive enthält: Ein neuer Cookie wird gesetzt.

Code

3) Beim diesen Request auf die Domäne www.example.de wird bereits der zuvor erstellte Cookie mitgeschickt.

Code

Vorteile von Sessionmanagement über Cookies:

Informationen über die Session wird von Intermediate-Devices wie Firewalls oder Proxies nicht aufgezeichnet.

Da Cookies heutzutage in fast allen Browsern integriert sind wird der Codingaufwand deutlich verringert.

Durch das Security-Feld der Cookies hat man die Möglichkeit die Übertragung nur über sichere Verbindungen (HTTPS, SSL) zuzulassen. Nachteile:

Immer mehr „sicherheitsbewusste“ Internetuser haben die Cookiefunktionalitäten deaktiviert. Dies impliziert auch, dass Webapplikationen, welche Cookies benötigen nicht mehr funktionieren.

-29-

Da die Größe von Cookies beschränkt ist (4kB) können oft komplexe Datentypen, wie virtuelle Warenkörbe, nicht mehr gespeichert werden.

Wie schon oben erwähnt besitzen Cookies ein Domain-Feld. Das bedeutet, dass bei jedem Aufruf einer Seite dieser Domain Kopien aller Cookies dieser Domain mitgesandt werden.

Persistente Cookies existieren als Textfiles (InternetExplorer) oder in Textfiles(Netscape) auf der Festplatte des Endbenutzers. Mit Leserechten auf diese Files können andere User auf demselben PC die Cookies kopieren und einsetzen.

3.6.4. Die SessionID

Die Sicherheit des Sessionmanagements hängt jedoch nicht nur von der Art der Übertragung, sondern zu einem großen Teil auch von der Sicherheit der SessionID. Man muss deshalb SessionIDs wählen welche „predictive“- und „brute-force“-attacks widerstehen können. Die beiden charakteristischen Kriterien für sichere SessionIDs sind die Zufälligkeit und die Länge derselben ¹⁹ .

3.6.4.1. Länge der SessionID

Man sollte die Länge der SessionID so wählen, dass diese durch „brute-force“ Angriffe in einem bestimmten Zeitrahmen nicht „erraten“ werden kann. Bei heutigen Prozessoren und Bandbreiten sollte man darauf achten, dass die SessionID zumindest 30 Zeichen lang ist. Hat man jedoch die Möglichkeit diese noch länger zu machen so sollte man das nützen. Die Länge der SessionID hängt noch von einigen anderen Faktoren ab.

• Die Geschwindigkeit des Übertragungsmediums. Während man im Internet von Geschwindigkeiten von ca. 512 kb/s ausgehen kann so liegt diese im Intranet um ein bis 200-faches höher (100 Mb/s). So kann ein Angreifer im Netzwerk SessionIDs über brute-force Angriffe 200-mal so schnell checken wie ein externer Angreifer.

• Die Komplexität der SessionID. Welche Werte und Zeichen werden verwendet um die SessionID zu erzeugen. Man benötigt zum Beispiel mit numerischen Zeichen einen wesentlich größeren Adressraum als wenn man alphanumerische Zeichen mit Beachtung von Groß- und Kleinschreibung hernimmt. Ein die Zahlen zwischen 000000-999999 können mit einem alphanumerischen Zeichenset 0000-5BH7 abgedeckt werden.

3.6.4.2. Zufälligkeit der SessionID

Genauso wichtig wie die Länge der SessionID ist die Zufälligkeit derselben. Die SessionID darf durch keinerlei statistische Methoden herausgefunden werden können. Idealerweise sollte die SessionID ein zufälliger Wert sein, der kein zweites Mal reproduziert werden kann. Daraus ergeben sich folgende Kriterien für eine zufällige SessionID:

• Die SessionID muss zufällig sein. Das bedeutet sie muss statistische Tests, welche ihre Zufälligkeit überprüfen bestehen.

¹⁹ vgl. http://www.cgisecurity.com/owasp/html/guide.html, 7.5.2005, 23:29

-30-

• Die ID kann nicht erfolgreich reproduziert werden. Wenn der ID-Generator zweimal mit exakt denselben Werten ausgeführt wird, dürfen die beiden daraus folgenden SessionIDs nicht gleich sein.

• Die SessionID darf nicht vorhersagbar sein. Selbst mit dem kompletten Wissen über die eingesetzten Algorithmen, die verwendete Hardware und alle zuvor verwendeten SessionIDs darf man die nächste ID nicht vorhersagen können.

3.7. Angriffsarten bei Sessions

Natürlich gibt es auch bei Sessions Angriffspunkte. Die nachfolgenden Punkte erklären die populärsten Angriffsarten gegen Sessions und die besten Möglichkeiten diese abzuwehren.

3.7.1. Session Hijacking

Im Allgemeinen wird unter dem Begriff Session Hijacking die Übernahme einer, bereits von einem User erstellte, Session verstanden. Das bedeutet dass der Angreifer eine gültige SessionID eines fremden Benutzers herausfindet und übernimmt. Um an eine solche zu gelangen gibt es unterschiedliche Möglichkeiten.

3.7.1.1. “Brute-Force” SessionIDs

Brute-Force Attacken sind Versuche von Programmen Passwörter oder SessionIDs durch das ausprobieren aller möglichen Kombinationen mit Zahlen und Buchstaben zu erraten. Diese Angriffsart hat besonders bei „kurzen“ SessionIDs eine hohe Erfolgschance.

3.7.1.2. „predicting“ SessionIDs

Oft werden zur Erstellung der SessionID lineare Algorithmen eingesetzt. Ein Angreifer hat nun die Möglichkeit sich die nächsten SessionIDs auszurechnen. Deshalb sollte eine Komponente der SessionID immer zufällig sein.

3.7.1.3. „intercepting“ SessionIDs

SessionIDs können auf viele unterschiedliche Arten gestohlen werden. Falls die SessionID in der URL übertragen wird, so wird sie in so genannten intermediate-devices wie Proxies mitgeloggt. Hat ein Angreifer Zugriff auf die Logdateien dieser Systeme so kann er einfach gültige SessionIDs herauslesen.

Angreifer können aber auch das HTTP_REFERER-Feld benutzen um die SessionID der zuvor besuchten Seiten herauszulesen. Natürlich besteht auch die Möglichkeit über Trojaner an gültige SessionIDs zu gelangen.

-31-

2) Der Webserver der Bank schickt einen HTTP-Response, welcher wie folgt aussehen könnte.

Code

3) Betätigt der Client nun den Link auf http://evil.example.com/stealmysessionid.php so wird ein HTTP-Request geschickt, welcher wie folgt aussehen wird:

Code

Obwohl es bei dem Ausnützen des HTTP_REFERER Feldes einige technische Einschränkungen und Schwierigkeiten gibt ist dies immer noch eine sehr effektive Methode um an valide SessionIDs zu gelangen.

-32-

So wird zum Beispiel das HTTP_REFERER Feld nur gesetzt wenn man eine Seite über einen Link aufruft. Des Weiteren werden von manchen Anwendungen, wie zum Beispiel Norton Internet Security, das HTTP_REFERER Feld standardmäßig unterdrückt. Es kann auch nur auf die SessionID zugegriffen werden wenn die SessionID mittels der GET-Methode übertragen wird.

3.7.2. Session Fixation

Beim Session Hijacking wird im Grunde davon ausgegangen dass ein User schon eine Session angelegt hat und man durch unterschiedliche Angriffsarten versucht eine gültige SesssionID zu erhalten.

Dabei wird jedoch oft eine andere Art des Angriffs auf Sessions außer Acht gelassen: Was wenn der Angreifer dem Nutzer eine ihm bekannte SessionID suggeriert? Diese Angriffsart wird als Session Fixation bezeichnet, weil die SessionID bereits vor dem Login (oder dem Aufruf der Seite) erzeugt wird.

1) Der Angreifer, welcher ein regulärer User des Systems ist loggt sich ein. 2) Ihm wird eine SessionID zugeteilt, in diesem Fall 9312

3) Der Angreifer sendet einen Link (http://mail.example.com/login.jsp?sessionid=9312) an den Client.

-33-

4) Der, in unserem Fall einfältige, Client klickt auf den Link und gelangt zur Loginseite des Mailservers.

5) Der Client loggt sich durch die Eingabe von Username und Passwort ein. 6) Nun ist dem Angreifer der Weg in das System mit einem fremden Account geebnet.

Dieses Beispiel demonstriert die einfachste Möglichkeit des Session Fixations. Sie bringt natürlich auch etliche Nachteile mit sich. So muss der Angreifer ein legitimer Benutzer des Systems sein und der Angreifer muss den User dazu bringen auf den, ihm zugetragenen Link zu klicken. 20

3.7.3. Beispiel einer Webtransaction

Natürlich ist dieses simple Konstrukt keine wirkliche Implementation eines serverseitigen Transaktionskonzepts. Eher ist es eine Aneinanderreihung von SQL-Statements, welche über mehrere Webseitenaufrufe gesammelt wurden.

Code

²⁰ vgl. Session Fixation Vulneriabilitiy in Web-based Applications, Mitja Kolsek, 2002

-34-

-36-

Sessionmanagement  und Transaktionssicherheit  

im  Webumfeld  

Abbildungsverzeichnis   

Abbildung  1 - Interner Aufbau eines DBMS  

http  ://www.kreissl.info/diggs/db 07.php, 7.5.2005,  

Abbildung  2 - Ein Deadlock im Strassenverkehr.  

Abbildung  3 - Undo-Redo Logging  

Abbildung  4 - Wiederholen einer Veränderung  

Abbildung  5 - Zurücksetzen einer Veränderung  

Abbildung  6 - erfolgreicher Two Phase Commit  

Arno  Schmidhauser: Two Phase Commit, 6.2004,  

Abbildung  7 - Fehlgeschlagener Two Phase Commit.  

Arno  Schmidhauser: Two Phase Commit, 6.2004,  

Abbildung  8 - Single User Umfeld  

Abbildung  9 - Multi-User Umfeld  

Abbildung  10 - TCP/IP Referenzmodell  

http  ://de.wikipedia.org/wiki/Http, 7.5.2005,  

Abbildung  11 - Ablage und Zugriff von Cookies  

Abbildung  12 - Cookietheft.  

Abbildung  13 - Aufbau einer Webapplikation  

Abbildung  14 - Presentation Tier  

Abbildung  15 - Application Tier.  

Abbildung  16 - Data Tier  

Abbildung  17 - URL-based Sessionmanagement  

Abbildung  18 - Beispiel eines HTTP-Post Requests  

Abbildung  19 - Sessionmanagement mit Cookies  

Abbildung  20 - Ausnützen des HTTP REFERER Feldes  

Abbildung  21 - Simple Session Fixation.  

-37-

Literaturverzeichnis:

[1] Mitja Kolšek. “Session Fixation Vulnerability in Web-based Applications.” December 2002. http://www.acros.si/papers/session_fixation.pdf

[2] “Tracking without Cookies” http://www.arctic.org/~dean/tracking-withoutcookies. html

[3] “Mitigating Cross-site Scripting With HTTP-only Cookies.” Microsoft Developer Network. http://msdn.microsoft.com/workshop/author/dhtml/httponly_cookies.asp [4] Charles Miller. “Saving HTTP Authentication?” 30 Dec 2003. http://fishbowl.pastiche.org/2003/12/30/saving_http_authentication [5] “Session Handling Functions.” PHP Users' Manual. http://uk.php.net/manual/en/ref.session.php [6] Gunter Ollmann. “Custom HTML Authentication.” http://www.technicalinfo.net/papers/CustomHTMLAUthentication.html [7] “A Guide to Building Secure Web Applications” http://www.cgisecurity.com/owasp/html/guide.html

[8] Chris Shiflett. “HTTP Developer's Handbook” http://shiflett.org/books/http-developers-handbook/chapters/11

[9] Chris Shiflett. “The Truth about Sessions” http://shiflett.org/articles/the-truth-aboutsessions

[10] Oliver Masutti „Distributed Web Session Management” [11] “Transaction Management“

http://www.developer.com/java/data/article.php/10932_2246481_3 [12] „Integrität und Transaktionskonzept“ http://www.kreissl.info/diggs/db_07.php [13] „Transaction Logging Concepts“

http://www.peg.com/techpapers/monographs/logging/logging.html [14] Jan Winkler. „HTTP: Einführung“ http://www.html-world.de/program/http_1.php

-38-