Diplomarbeit. Technischen Universität Dresden. Fakultät Informatik Institut Systemarchitektur Professur Rechnernetze.

Transkript

1 Erarbeitung und programmtechnische Umsetzung einer Testmethodik für Sicherheit der Webkommunikation und -anwendungen Diplomarbeit zur Erlangung des akademischen Grades Diplom-Informatiker an der Technischen Universität Dresden Fakultät Informatik Institut Systemarchitektur Professur Rechnernetze eingereicht von: Alexander Mroß Betreuender HSL: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill Externer Betreuer: Dipl.-Inf. Thomas Haase (T-Systems MMS GmbH) Betreuer: Dr.-Ing. Andriy Luntovskyy (TU-Dresden), Dr. rer. nat. Dietbert Gütter (TU-Dresden) Beginn am: 06. August 2007 Eingereicht am: 05. Februar 2008

2 Inhaltsverzeichnis Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Listingverzeichnis I V VII IX 1 Einleitung 1 2 Beschreibung von Webanwendungen Grundlagen Definition Architekturen Schichten-Architektur N-Schichten-Architektur Anforderungen an Webanwendungen Sicherheit von Webanwendungen Bedrohungen für Webanwendungen Was ist zu schützen? Vor wem ist zu schützen? Auf welchen Ebenen ist zu schützen? Sicherheitslücken in Webanwendungen Authentifizierung Autorisierung Überprüfung der Eingabedaten Bereichsprüfung API-Missbrauch Offene Sicherheitsmerkmale I

3 INHALTSVERZEICHNIS Ausnutzung von Zeit- und Zustandsverhalten Qualität des Quelltextes Logische Angriffe Methoden zur Unterstützung von Sicherheitstests Beschreibung des Penetrationstests Durchführung des Penetrationstests Vorbereitung Informationsbeschaffung Bewertung der Informationen/Risikoanalyse Aktive Eindringversuche Abschlussanalyse Passive vs. aktive Penetrationstest Einschätzung des Penetrationstests Vorteile Nachteile Zusammenfassung der Vor- und Nachteile Source Code Scanner Einsatzmöglichkeiten von Source Code Scannern Qualitätsanalyse Sicherheitsanalyse Durchführung des Source Code Scanning Klassifikation von Source Code Scannern Praktische Source Code Scans Praktische Source Code Scans für PHP Überblick, Planung und Vorbereitung Testskript ProjectP Durchführung der Source Code Scans SWAAT RATS Pixy Abschlussbericht der Source Code Scans II

4 INHALTSVERZEICHNIS Zusammenfassung der Source Code Scans von PHP Praktische Source Code Scans für Java Überblick, Planung und Vorbereitung Testdateien in Java OWASP Insecure Web App Project ProjectJ Durchführung der Source Code Scans Klocwork Developer for Java (K7) Parasoft JTest Fortify SCA Abschlussbericht der Source Code Scans von Java Zusammenfassung der Source Code Scans von Java Praktische Source Code Scans für.net Überblick, Planung und Vorbereitung Testdatei in C# ProjectDN Durchführung der Source Code Scans DevPartner SecurityChecker Fortify SCA Microsoft FxCop Abschlussbericht der Source Code Scans von.net Zusammenfassung der Source Code Scans Bewertung der praktischen Source Code Scans Bewertung für PHP Bewertung für Java Bewertung für.net Freie vs. kommerzielle Source Code Scanner Zusammenfassung und Ausblick Zusammenfassung Ausblick Literaturverzeichnis XI A Quelltexte A.1 III

5 INHALTSVERZEICHNIS B I-Module für das Source Code Scanning B.7 C Auswertung Source Code Scans für PHP C.11 C.1 Auswertung SWAAT C.12 C.2 Auswertung RATS C.21 C.3 Auswertung Pixy C.25 D Auswertung Source Code Scans für Java D.31 D.1 Auswertung Klocwork Developer for Java D.31 D.2 Auswertung Parasoft JTest D.37 D.3 Auswertung Fortify SCA D.42 E Auswertung Source Code Scans für.net E.47 E.1 Auswertung DevPartner SecurityChecker E.48 E.2 Auswertung SCA E.50 E.3 Auswertung Microsoft FxCop E.51 F CD-Rom F.53 IV

6 Abbildungsverzeichnis Abbildung 2-1 : Allgemeine Darstellung einer Client/Server-Architektur... 5 Abbildung 2-2 : Allgemeine Darstellung einer N-Schichten Architektur Abbildung 2-3 : Aufbau des JSP-Model Abbildung 2-4 : Konzeptioneller Aufbau von Struts Abbildung 2-5 : Modell von OOHDM-Java Abbildung 2-6 : Allgemeines Gefährdungsmodell für Webanwendungen Abbildung 4-1 : Lebenszyklus von Software-Anwendungen Abbildung 5-1 : Screenshot: Filter in K Abbildung 5-2 : Screenshot: Gefährdungsskala in K Abbildung 5-3 : Screenshot: Sicherheitslücken in Test1.java mit K Abbildung 5-4 : Screenshot: Sicherheitslücken in Test2.java mit K Abbildung 5-5 : Screenshot: Sicherheitslücken in OWASP Insecure Web App Project mit K Abbildung 5-6 : Screenshot: Konfiguration des Source Code Scans in JTest.. 65 Abbildung 5-7 : Screenshot: Sicherheitslücken in Test1.java mit JTest Abbildung 5-8 : Screenshot: Sicherheitslücken in Test2.java mit JTest Abbildung 5-9 : Screenshot: Sicherheitslücken in OWASP Insecure Web App Project mit JTest Abbildung 5-10 : Screenshot: Protokoll von ProjectJ1 mit JTest Abbildung 5-11 : Screenshot: Bewertung der Sicherheitslücken in SCA Abbildung 5-12 : Screenshot: Zusammenfassung für Test2.java Abbildung 5-13 : Screenshot: Ausgabe von XSS in SCA Abbildung 5-14 : Screenshot: Analysis Trace in SCA Abbildung 5-15 : Screenshot: Zusammenfassung für OWASP Insecure Web App Project Abbildung 5-16 : Screenshot: Auswahl in DevPartner SecurityChecker Abbildung 5-17 : Screenshot: Gefährdungsskala in DevPartner SecurityChecker 86 Abbildung 5-18 : Screenshot: Kritische Sicherheitslücken im ProjectDN V

7 ABBILDUNGSVERZEICHNIS Abbildung 5-19 : Screenshot: Moderate Sicherheitslücken im ProjectDN Abbildung 5-20 : Screenshot: Informative Sicherheitslücken im ProjectDN1. 88 Abbildung 5-21 : Screenshot: Zusammenfassung für Test1.cs Abbildung 5-22 : Screenshot: SQL-Injektion in Test1.cs mit FxCop Abbildung C-1 : Screenshot: Abhängigkeitsgraph xss1 von Pixy C.26 Abbildung C-2 : Screenshot: Abhängigkeitsgraph sql1 von Pixy C.27 Abbildung C-3 : XSS(1) in adodb.inc.php von Pixy C.28 Abbildung C-4 : XSS(2) in copy_field.php von Pixy C.29 Abbildung C-5 : XSS(3) in copy_field.php von Pixy C.29 Abbildung D-1 : Screenshot: Schwachstellenfunde in ProjectJ1 mit K7... D.36 Abbildung D-2 : Screenshot: Schwachstellenfunde in Test1.java mit JTest... D.37 Abbildung D-3 : Screenshot: Schwachstellenfunde in Test2.java mit JTest... D.38 Abbildung D-4 : Screenshot: Schwachstellenfunde in OWASP Insecure Web App Project mit JTest D.39 Abbildung D-5 : Screenshot1: Schwachstellenfunde in ProjectJ1 von JTest. D.40 Abbildung D-6 : Screenshot2: Schwachstellenfunde in ProjectJ1 von JTest. D.41 Abbildung D-7 : Screenshot: Bericht für Test2.java von SCA D.42 Abbildung D-8 : Screenshot: Bewertete Sicherheitslücken für Test2.java in SCA D.43 Abbildung D-9 : Screenshot: Zusammenfassung für ProjectJ1 von SCA... D.45 Abbildung E-1 : Screenshot: Berichtsausschnitt von Test1.cs in DevPartner SecurityChecker E.48 Abbildung E-2 : Screenshot: Kurzer Bericht von ProjectDN1 in DevPartner SecurityChecker E.49 Abbildung E-3 : Screenshot: Zusammenfassung für ProjectDN E.50 Abbildung E-4 : Screenshot: Protokoll in Test1.cs mit FxCop E.51 VI

8 Tabellenverzeichnis Tabelle 2-1 : Ebenenmodell zur Sicherheitskonzeption von Webanwendungen. 12 Tabelle 3-1 : Allgemeiner Aufbau von Modulen Tabelle 3-2 : Einschätzung des Penetrationstests Tabelle 4-1 : Klassifikation für PHP Tabelle 4-2 : Klassifikation für Java Tabelle 4-3 : Klassifikation für.net Tabelle 5-1 : Projektübersicht für PHP Tabelle 5-2 : Auswertung des PHP-Testskript Tabelle 5-3 : Auswertung von ProjectP Tabelle 5-4 : Projektübersicht für Java Tabelle 5-5 : Auswertung für Java-Testdateien Tabelle 5-6 : Auswertung für OWASP Insecure Web App Project Tabelle 5-7 : Auswertung für ProjectJ Tabelle 5-8 : Projektübersicht für.net Tabelle 5-9 : Auswertung für Test1.cs Tabelle 5-10 : Auswertung für ProjectDN Tabelle 6-1 : Bewertung für PHP Tabelle 6-2 : Bewertung für Java Tabelle 6-3 : Bewertung für.net Tabelle 7-1 : Einschätzung des erweiterten Penetrationstests Tabelle B-1 : I-Modul für PHP B.8 Tabelle B-2 : I-Modul für Java B.9 Tabelle B-3 : I-Modul für.net B.10 Tabelle C-1 : Anzahl der Sicherheitslücken im Testskript von SWAAT..... C.12 Tabelle C-2 : Kommando-Injektion im Testskript von SWAAT C.13 VII

9 TABELLENVERZEICHNIS Tabelle C-4 : SQL-Injektion im Testskript von SWAAT C.14 Tabelle C-5 : Offenes Passwort und Nutzerinformation im Testskript von SWAATC.15 Tabelle C-6 : Anzahl gefundener Sicherheitslücken im ProjectP C.16 Tabelle C-7 : Kommando-Injektion(1) im ProjectP1 von SWAAT C.16 Tabelle C-8 : Kommando-Injektion(2) im ProjectP1 von SWAAT C.17 Tabelle C-9 : Kommando-Injektion(3) im ProjectP1 von SWAAT C.17 Tabelle C-10 : SQL-Injektion im ProjectP1 von SWAAT C.18 Tabelle C-11 : Offene Passwörter und Nutzerinformationen im ProjectP1... C.19 Tabelle C-12 : Gleichzeitige Zugriffe im ProjectP1 mit SWAAT C.20 VIII

10 Listingverzeichnis 5-1 XSS in tests.php SQL-Injektion in tests.php Kommando-Injektion in tests.php Datei-Injektion in tests.php Pfad-Manipulation in tests.php HTTP-Response-Splitting in tests.php Offene Passwörter und Nutzerinformationen in tests.php Schwachstellenmuster für PHP in SWAAT Schwachstellenmuster für PHP in RATS Repository in RATS Scan-Parameter für tests.php in RATS Scan-Parameter für ProjectP1 in RATS SQL-Injektion in tests.php mit Pixy XSS(1) im ProjectP1 mit Pixy XSS(2) im ProjectP1 mit Pixy Gleichzeitige Zugriffe in Test1.java XSS in Test2.java Unsichere Pseudozufallszahlengeneratoren in Test2.java Pfad-Manipulation in Test2.java Eingabe an Ressourcen in Test2.java Offene Passwörter und Nutzerinformationen in Test2.java Festhalten der Kommunikationssitzung in Test2.java SQL-Injektion im OWASP Insecure Web App Project Offene Passwörter und Nutzerinformationen im OWASP Insecure Web App Project sendmail() in ExportDialog.java SQL-Injektion in TestPlaylists.java mit JTest XSS in ReportServlet.java (1) mit SCA SQL-Injektion in Search.java mit SCA IX

11 LISTINGVERZEICHNIS 5-30 Kommando-Injektion in SymlinkUnix.java mit SCA Festhalten der Kommunikationssitzung in Login.java mit SCA Pfad-Manipulation(1) in CMSConnector.java mit SCA Pfad-Manipulation(2) in CreateDemoAuftraege.java mit SCA Pseudozufallszahlengenerator in ScreenGenerator.java mit SCA XSS in Test1.cs SQL-Injektion in Test1.cs Pseudozufallszahlengenerator in Test1.cs Pfad-Manipulation in Test1.cs Eingaben an Ressourcen in Test1.cs Offene Passwörter und Nutzerinformationen in Test1.cs XSS in cmsbewertungen.aspx.cs mit SCA Offene Passwörter und Nutzerinformationen im ProjectDN1 mit SCA XSS in Test1.cs mit SCA SQL-Injektion in ProjectDN1 mit SCA A-1 SQL-Injektion in Test2.java A.2 A-2 DoS und SQL-Injektion in ResetDatabaseServlet.java von K A.2 A-3 Sensible Informationen in ResetDatabaseServlet.java von JTest A.3 A-4 False-positive in DbImport.java A.4 C-1 Protokoll für den Scan des Testskriptes mit RATS C.21 C-2 Protokoll(1) für den Scan von ProjectP1 mit RATS C.21 C-10 XSS in tests.php mit Pixy C.25 C-11 Fehlerausgabe von Pixy für ProjectP C.28 D-1 Protokoll für Test1.java von K D.31 D-2 Protokoll für Test2.java von K D.32 D-3 Protokoll für OWASP Insecure Web App Project von K D.34 D-4 Dateiausgabe der Sicherheitslücken von SCA D.43 X

12 Kapitel 1 Einleitung In Folge von Daten-Diebstahl, Daten-Verlust und bösartigen Programmen können Unternehmensinformationen bekannt werden bzw. verloren gehen, wodurch Unternehmen erheblicher finanzieller Schaden entstehen kann. Deshalb wird in vielen Unternehmen der Sicherheit der Webkommunikation und insbesondere der Sicherheit von Webanwendungen ein zunehmend signifikanter Stellenwert zugeordnet. Potentielle Angreifer nutzen bei initiierten Angriffen vermehrt Sicherheitslücken bzw. Schwachstellen in Webanwendungen aus, um Informationen zu erhalten bzw. die einzelne Webanwendung zu unterminieren. So sind nach [Sym07] 61% aller im Zeitraum Januar - Juni 2007 ermittelten Sicherheitslücken in Webanwendungen gefunden worden. 72% der in diesem Zeitrahmen insgesamt bestimmten Sicherheitslücken hätten von Angreifern leicht ausgenutzt werden können. Um Webanwendungen auf vorhandene Sicherheitslücken zu überprüfen, können Sicherheitstests, beispielsweise Penetrationstests, durchgeführt werden. Damit Sicherheitstests koordiniert erfolgen und ggf. wiederholt werden können, wird eine standardisierte Vorgehensweise angestrebt. Um bei der Durchführung des Sicherheitstests den Aufwand zu reduzieren, können Werkzeuge eingesetzt werden, wodurch eine teilweise automatisierte Testdurchführung erreicht werden kann. Zur Koordination und automatisierten Testdurchführung können sogenannte Prüfschemas eingesetzt werden, mit deren Hilfe Angriffsszenarien für die entsprechende Webanwendung spezifiziert werden. Im Rahmen dieser Diplomarbeit wird untersucht, inwieweit Source Code Scanner eingesetzt werden können, um ein vom Unternehmen T-Systems Multimedia Solutions GmbH eingesetztes Prüfschema für Penetrationstests praktikabel zu erweitern. 1

13 KAPITEL 1. EINLEITUNG Ein wichtiger Ansatz dazu ist der Einsatz von Source Code Scannern in einer geeigneten Testmethodik, womit bereits im Quelltext 1 enthaltene Sicherheitslücken gefunden und die Programmierer bei der Entwicklung von Webanwendungen unterstützt werden können. Entscheidend ist hierbei, dass viele Ursachen von Sicherheitslücken in Folge von unzureichenden bzw. unsicheren Implementationen zur Erstellung des Quelltextes von Webanwendungen entstehen, die im Anschluss nur mit hohem Aufwand und unter Verwendung einer Vielzahl verschiedener Werkzeuge mit unterschiedlichen Testmethoden aufgedeckt und korrigiert werden können (vgl. [Che07]). Dazu wird zunächst im Kapitel 2 definiert, was unter einer Webanwendung im Allgemeinen verstanden wird und welche Anforderungen unter Berücksichtigung der zugrunde liegenden Architektur entstehen. Weiterhin sollen in diesem Kapitel mögliche Bedrohungen und Präventivmaßnahmen vorgestellt werden. Eine Maßnahme bzw. unterstützende Testmethode ist der Penetrationstest. Dafür wurde im Rahmen einer Diplomarbeit (siehe [Hel06]) ein Prüfschema entwickelt, dass sich an dem Durchführungskonzept für Penetrationstests nach [BSI03] orientiert und im Kapitel 3 vertiefend betrachtet wird. Im Kapitel 4 wird zur Erweiterung des vorgestellten Prüfschemas für Penetrationstests insbesondere eine Vorgehensweise und Klassifikation für den praktischen Einsatz von Source Code Scannern erarbeitet. Dazu werden im Vorfeld mögliche Einsatzszenarien von Source Code Scannern im Einzelnen betrachtet. Aufbauend auf den beschriebenen Szenarien werden die Source Code Scanner systematisch klassifiziert, um eine Differenzierung der Scanner für den praktischen Einsatz vornehmen zu können. Der praktische Einsatz wird im folgenden Kapitel 5 ausführlich erläutert. Im Anschluss werden die Ergebnisse aus den praktischen Source Code Scans im Kapitel 6 bewertet, womit Aussagen zur Werkzeugunterstützung formuliert werden können. Abschließend werden im Kapitel 7 die wesentlichen Erkenntnisse zusammengefasst und ein Ausblick auf weiterführende Arbeiten gegeben. 1 Der Quelltext einer Webanwendung ist eine Repräsentation einer Komposition von Anweisungen, die in Menschen lesbarer Form vorliegt. 2

14 Kapitel 2 Beschreibung von Webanwendungen Mit der Entstehung und Entwicklung des WWW (World Wide Web) haben sich immer anspruchsvollere Aufgabenfelder für Unternehmen ergeben. Angefangen mit einfachen statischen Web-Seiten, mit denen einzelne Informationen verfügbar gemacht wurden, haben sich immer umfangreichere Anwendungen entwickelt, mit denen z.b. Transaktionen beim Online-Banking durchgeführt werden können. Diese Anwendungen werden auch als Webanwendungen bezeichnet, wobei eine konkrete Definition im Kapitel gegeben wird. Darüber hinaus werden Architekturen vorgestellt, die die konzeptionelle Basis für die einzelnen Webanwendungen bilden. Unter Berücksichtigung der vorgestellten Architekturen haben sich spezielle Anforderungen bzgl. der Funktionalität, des Zeitverhaltens und der Qualität von Webanwendungen ergeben, die im Kapitel genauer erläutert werden. Da in dieser Arbeit der Fokus auf der Sicherheit von Webanwendungen liegt, soll auf den Begriff Sicherheit im Allgemeinen und mit Bezug auf Webkommunikation und Webanwendungen im Speziellen in Kapitel 2.2 eingegangen werden. 2.1 Grundlagen Definition Entsprechend [Kap04] kann eine Webanwendung wie folgt definiert werden: Eine Webanwendung ist ein Softwaresystem, das auf Spezifikationen des World Wide Web Consortium (W3C) beruht und Web-spezifische Ressourcen (Inhalte, Dienste) bereitstellt, die über eine Benutzerschnittstelle (Web Browser) verwendet werden können. 3

15 KAPITEL 2. BESCHREIBUNG VON WEBANWENDUNGEN Kennzeichnend für den Zugriff auf Ressourcen über das World Wide Web (WWW) ist, dass zumeist sehr viele Nutzer gleichzeitig versuchen auf Ressourcen der Webanwendung zuzugreifen. Deshalb werden in [Wöh04] Webanwendungen auch als verteilte Mehr- Benutzeranwendungen bezeichnet, wobei Probleme resultierend aus nebenläufigen Prozessen und damit verbundenen gleichzeitigen Zugriffen auf Ressourcen (Race Conditions) entstehen können. Zur Koordination der gemeinsamen Zugriffe auf die Ressourcen und zur Vermeidung von Race Conditions muss eine Synchronisation der Zugriffe erfolgen. Somit können Webanwendungen relativ komplexe Softwaresysteme darstellen, die aus mehreren Softwarekomponenten aufgebaut sind, die untereinander in Beziehung stehen. Die durch Softwarekomponenten bereitgestellten Funktionen, Prozesse und Dienste der Webanwendung können mehrheitlich auf einem oder mehreren Servern ausgeführt werden, wobei die Darstellung der gelieferten Ergebnisse auf den Clients erfolgt. Wie Clients und Server logisch verknüpft werden, kann mit Hilfe verschiedener Architekturen beschrieben werden, die im folgenden Kapitel vertiefend betrachtet werden Architekturen Architekturen sind die Basis für Webanwendungen und können unter anderem hinsichtlich der Anzahl der vorkommenden Schichten unterschieden werden. Mit zusätzlichen Servern werden dabei umfangreiche Funktionen umgesetzt, die durch die Komplexität der Anwendung bestimmt sind. Die einfachste Architektur ist die 2-Schichten-Architektur, die im Kapitel beschrieben wird. Prinzipiell werden Architekturen, die in Folge der Komplexität von Anwendungen eine weitere Schichteneinteilung erfordern, als N-Schichten- Architekturen bezeichnet. Auf N-Schichten-Architekturen wird in Kapitel eingegangen Schichten-Architektur 2-Schichten-Architekturen bezeichnen Client/Server-Architekturen, wobei Clients via HTTP-Protokoll mit einem Server kommunizieren. Die Clients fragen dazu Inhalte vom Server ab, die von diesem in geeigneter Form für die Clients bereitgestellt werden. Auf den Clients sind entsprechende Web Browser zur Darstellung der bereitgestellten Inhalte vorhanden. Die Inhalte können auf dem Server im einfachsten Fall als statische HTML-Seiten vorliegen. Der Server nimmt die Anfragen der Clients entgegen und führt ggf. angesprochene Anwendungen aus. 4

16 KAPITEL 2. BESCHREIBUNG VON WEBANWENDUNGEN Außerdem verwaltet der Server die benötigten und erzeugten Daten. Erfolgt keine Ausführung von Anwendungslogik auf Client-Seite, werden die Clients als Thin Clients bezeichnet. Ein Teil der Logik kann aber auch auf den Clients ausgeführt werden, wobei diese dann über entsprechende Rechenleistung verfügen müssen. Solche Clients werden auch Rich Clients genannt [Hua04, Jab04]. In Abbildung 2-1 wird eine allgemeine Darstellung einer 2-Schichten-Architektur gezeigt [Ana01]. Abbildung 2-1: Allgemeine Darstellung einer Client/Server-Architektur (vgl. [Ana01]) Hierbei sind in der Server-Schicht Inhalte in Form von statischen oder dynamischen HTML- Seiten enthalten, die Clients über die Server-Logik abrufen können N-Schichten-Architektur Bei der N-Schichten-Architektur wird die Server-Schicht aus der 2-Schichten-Architektur im Wesentlichen aufgebrochen, um eine bessere Trennung von Datenhaltung, Anwendungslogik, Geschäftslogik und Präsentation zu erreichen. Damit entstehen weitere funktionsorientierte Server-Schichten mit genau beschriebenen Schnittstellen, so dass im Vergleich zur 2-Schichten-Architektur umfangreichere und komplexere Webanwendungen konzipiert werden können ([Sch07], [Jab04]). Speziell erfolgt eine Differenzierung in Application- Server, Datenbank-Server, Web-Server, Firewall und Backend. 5

17 KAPITEL 2. BESCHREIBUNG VON WEBANWENDUNGEN Zur Verdeutlichung wird in Abbildung 2-2 eine allgemeine Darstellung für eine N- Schichten-Architektur präsentiert [Ana01]. Abbildung 2-2: Allgemeine Darstellung einer N-Schichten Architektur (vgl. [Ana01]) Es existieren verschiedene Lösungen, wobei insbesondere auf die Lösungen JSP-Model-2, Struts und OOHDM-Java2 (Object-Oriented Hypermedia Design Model) vertiefend eingegangen werden soll JSP-Model-2 Das JSP-Model-2 ist ein Modell für eine N-Schichten-Architektur, bei dem die Darstellung (View), die Repräsentation der Daten (Modell als Java Bean) und die Steuerung der Anwendung getrennt erfolgen, da verschiedene Clients unterschiedliche Anforderungen an 6

18 KAPITEL 2. BESCHREIBUNG VON WEBANWENDUNGEN die Darstellung der Daten haben. Der Aufbau des JSP-Model-2 wird mit Hilfe der Abbildung 2-3 verdeutlicht [Kap04]. Abbildung 2-3: Aufbau des JSP-Model-2 (vgl. [Kap04]) Das Controller-Servlet wählt bzw. erzeugt zunächst auf Grundlage einer Client-Anfrage ein Modell basierend auf bereitgestellten Daten aus der Datenbank. Weiterhin wird die Darstellungsform durch den Controller festgelegt und mittels JSP erfolgt die Aufbereitung der Daten für die Clients Struts Struts ist eine Architektur, die das MVC (Model View Controller)-Modell umsetzt, so dass die Repräsentation der Daten in Form eines Modells, die Logik und die Präsentation logisch voneinander getrennt sind. In Abbildung 2-4 wird ein Überblick über den konzeptionellen Aufbau von Struts gegeben [Kap04]. Abbildung 2-4: Konzeptioneller Aufbau von Struts (vgl. [Kap04]) 7

19 KAPITEL 2. BESCHREIBUNG VON WEBANWENDUNGEN Die Anfragen der Clients werden durch Action Servlets entgegen genommen und an den Controller übermittelt. Der Controller wählt bzw. erstellt daraufhin ein Modell in Form einer Java Bean, die zur Darstellung verwendet wird, indem eine Präsentation durch das Action Servlet ausgewählt wird. Die erzeugte Präsentation wird schließlich an den Client übermittelt und mittels Web Browser zur Anzeige gebracht OOHDM-Java2 (Object-Oriented Hypermedia Design Model) Analog zu JSP und Struts werden auch bei OOHDM-Java2 die View, die Repräsentation der Daten und die Ablaufsteuerung der Anwendung getrennt modelliert. Das Modell von OOHDM-Java2 ist in Abbildung 2-5 dargestellt [Jac02]. Bei OOHDM-Java2 wird die Abbildung 2-5: Modell von OOHDM-Java2 (vgl. [Jac02]) Anfrage von Clients im Controller von einem HTTP-Request-Translator entgegengenommen, der der Anfrage relevante Informationen entnimmt und in aufbereiteter Form an den Dispatcher übergibt. Der Dispatcher kann damit die entsprechenden Anwendungen auswählen und ausführen. Zur Darstellung der ausgegebenen Daten, basierend auf dem Modellzustand, wird vom Controller ein geeignetes User Interface ausgewählt, das zur erweiterten Darstellung übermittelt wird. Das User Interface wird anschließend noch um eine Navigation erweitert, mittels JSP angeordnet und an den Client in Form einer Antwortnachricht zurückgegeben. 8

20 KAPITEL 2. BESCHREIBUNG VON WEBANWENDUNGEN Anforderungen an Webanwendungen Webanwendungen müssen im Gegensatz zu herkömmlichen Software-Anwendungen kontinuierlich an die Gegebenheiten im World Wide Web angepasst werden und sind somit einem ständigen Wandel unterzogen, der unter anderem durch Einführung neuer Technologien im Internet erfolgt [Mos06]. Damit über das WWW auf Webanwendungen zugegriffen werden kann, müssen diese flexibel, aber gleichzeitig auch zuverlässig sein. Mit den zuvor beschriebenen Architekturen wird ein Ansatz zur Erhöhung der Zuverlässigkeit und Flexibilität von Webanwendungen aufgezeigt, da strukturelle und funktionelle Einheiten gebildet werden, deren Schnittstellen eindeutig beschrieben sind [Sch07]. Bei der Entwicklung von Webanwendungen ergeben sich erhebliche Anforderungen, die im Detail nur sehr schwer und inkrementell evaluiert werden können. Analog zur Anforderungsanalyse für Softwareentwicklung sind bei der Entwicklung von Webanwendungen neben den funktionalen Anforderungen, nicht funktionale Anforderungen zu berücksichtigen. Zu den nicht funktionalen Anforderungen werden Zeit- und Qualitätsanforderungen gezählt. Zeitanforderungen umfassen dabei Forderungen hinsichtlich der Antwort- und Latenzzeiten der Webanwendung. Zu den Qualitätsanforderungen gehören Kriterien bzgl. Performanz, Verfügbarkeit, Benutzbarkeit (Usability), Effizienz, Änderbarkeit und Wartbarkeit von Webanwendungen. Neben den genannten Qualitätsanforderungen ist die Sicherheit von Webanwendungen, die im folgenden Kapitel 2.2) herausgestellt betrachtet wird, eine Qualitätsanforderung mit zunehmender Bedeutung. 2.2 Sicherheit von Webanwendungen Die Sicherheit in der Webkommunikation und insbesondere auch in Webanwendungen beschreibt keinen finalen Zustand, sondern kann als ganzheitlicher entwicklungsbegleitender Prozess verstanden werden. Ein Kernthema der vorliegenden Arbeit ist die IT-Sicherheit von Webanwendungen, wobei neben der Webanwendung selbst die zugehörenden Schnittstellen, genauer die Ein- und Ausgaben zu schützen sind. Bereits mit einer geeigneten Architektur entsprechend Kapitel 2.1.2, wird eine konzeptionelle Basis zur Unterstützung der Sicherheit von Webanwendungen gelegt. In den folgenden Kapiteln werden weitere Aspekte beschrieben, die im Kontext der Sicherheit von Webanwendungen zu berücksichtigen sind. Beginnend mit möglichen Gefährdungen, die im Kapitel beschrieben sind, wird fortführend im Kapitel ein Überblick über mögliche Sicherheitslücken in Webanwendungen gegeben. 9