Material zum Praktikumsversuch

Transkript

1 Material zum Praktikumsversuch Stand: Jul. 2005, zusammengestellt von: Sebastian Gajek (Lehrstuhl NDS) Version 1.1 ACHTUNG! Upgedatete Version Grundpraktikum der IT-Sicherheit Web Services Security Lehrstuhl für Netz- und Datensicherheit ruhr-universität bochum Bitte beachten Sie, dass dieser Versuch im Raum IC4/58 stattfindet.

2 Inhaltsverzeichnis Material zum Praktikumsversuch... 1 Grundpraktikum der IT-Sicherheit... 1 Web Services Security... 1 Inhaltsverzeichnis... 2 Vorwort... 3 Hinweise... 3 Grundlagen... 4 Was sind Web-Services?... 4 Wozu Sicherheit?... 6 Simple Object Access Protocol (SOAP)... 7 Hilfsfragen... 8 Referenzen... 8 Aufgabe... 9 Aufgabe Aufgabe Aufgabe 2a... 9 Aufgabe 2b... 9 Aufgabe 2c... 9 Aufgabe 2d... 9 Aufgabe Aufgabe Optional: Aufgabe Auswertung Praktikumsversuch Web Service Security Lehrstuhl Netz- und Datensicherheit 2

3 Vorwort Ziel des Praktikums ist ihnen grundlegendes Wissen der Netz- und Datensicherheit praktisch darzustellen. Neben dem didaktischen Erfolg soll auch der Spaß an Kryptographie, Internetsicherheit oder Programmierung im Vordergrund stehen. Nichtsdestotrotz sollten sie den Aufwand dieser Veranstaltung nicht unterschätzen! Sie werden in diesem Praktikum einer Großauswahl an Themen begegnen, die in solch einem Umfang den Rahmen einer einzigen Vorlesung überschreiten würden. Vielmehr wird ihnen Wissen vermittelt, das Bestandteil einiger Grundlagenvorlesungen ist oder Basis für vertiefende Vorlesungen sein wird. Aus diesem Grund ist ihre Vorbereitung entscheidend für den Erfolg des Praktikums. Das Studium der angegebenen Literaturreferenzen ist Voraussetzung für einen Praktikumsversuch. Durch das Studium der Referenzen eignen sie sich theoretisches Wissen an, das Grundlage für die Durchführung eines Versuchs ist, welches anschließend in einem Versuch praktisch untermauert und gefestigt werden soll. Die Aufgabe eines Betreuers ist somit nicht die Vermittlung des Grundlagenwissens, sondern die Unterstützung der Durchführung ihres Versuchs. Vor Beginn eines Versuchs wird in einem Vortestat überprüft, ob sie die Referenzen ausreichend studiert haben. Damit wird sichergestellt, dass sie in der vorgegeben Zeit die gestellten Aufgaben lösen können. Sollte vom Betreuer festgestellt werden, dass sie nachweislich nicht vorbereitet sind, werden sie von dem Versuch ausgeschlossen und müssen zu einem Nachholtermin erscheinen. Ihr Ziel sollte dennoch sein, das Testat auf dem direkten Weg zu erhalten. Hinweise Lesen sie sich zuerst das Grundlagenkapitel durch. Recherchieren sie bei Unklarheiten im Internet, diskutieren sie mit Kommilitonen oder kontaktieren sie bei schwerwiegenden Problemen ihren Betreuer. Nehmen sie bei ihrer Recherche folgende Quellen zur [REF], und versuchen sie sich an den Hilfsfragen zu orientieren. Sie sollten unter allen Umständen auch versuchen die Aufgaben so weit wie möglich zu bearbeiten. Es ist ebenfalls möglich die Aufgaben vollständig Zuhause zu lösen. Ihre Lösungen werden vom Betreuer während des Praktikums kontrolliert und bei nachweislich selbstständiger Erarbeitung erhalten sie vorab das Testat. Nach einem Versuch muss jede Gruppe ein Protokoll anfertigen, in dem die Herleitung, die Lösung der Aufgaben, und vor allem deren Begründung unter Ausnutzung des gesammelten Wissens erörtert werden. Bei der Begründung können Zeichnungen helfen! Das Protokoll kann wahlweise in deutscher oder englischer Sprache erstellt werden. Es sollte nur den orthographischen und grammatischen Anforderungen der Sprache genügen. Sie haben bis zu einer Woche Zeit, um ihr computergefertigtes Protokoll in ausgedruckter Form beim Betreuer abzugeben, ansonsten erhalten sie ihr Endtestat nicht. Bei offenen Fragen wenden sie sich immer an den jeweiligen Betreuer! Viel Spaß Praktikumsversuch Web Service Security Lehrstuhl Netz- und Datensicherheit 3

4 Grundlagen Was sind Web-Services? Das Zwiebelschalenmodell (anschauliche Darstellung der Entwicklungsstufen ähnlich der Schalen einer Zwiebel, siehe Abbildung 1) definiert einen Web-Service zunächst als Dienstleistung im klassischen Sinne, die über das World Wide Web erbracht wird. Die einzigen hierbei verbindlich benötigten Standards sind die namensgebenden Web-Techniken. Hierunter fallen neben der physischen Hardwareinfrastruktur auch die benötigten Internet- Protokolle wie TCP/IP. Die darauf aufsetzenden Stufen erhöhen sukzessive die Interoperabilität der durch Web-Mittel erbrachten Dienstleistungen und daher in der Konsequenz auch die Austauschbarkeit des Dienstes durch den Konsumenten. Abbildung 1: Zwiebelschalenmodell Werden Web-Dienste zunächst nur auf Basis der im Internet gebräuchlichen Vermittlungsstandards erbracht, so fügt die Verwendung der Extensible Markup Language (XML) zur Darstellung des Dienstleistungsinhaltes eine weitere Stufe der Vereinheitlichung hinzu. Durch sie werden sowohl die Dienstanforderung selbst als auch die Rückübermittlung des Dienstergebnisses im selben Metaformat dargestellt. Hierin zeigt sich nochmals die diskutierte neue Rolle der Standards. XML legt dabei nicht ein konkretes Nachrichtenformat fest, sondern eröffnet dem Dienstanbieter die Möglichkeit, sein Format auf Basis der Metasprache selbst zu definieren. Offenkundig ließe sich dieses Ziel auch durch andere Inhaltsdarstellungen - wie die in der Abbildung 1 beispielhaft erwähnten ASN.1 oder EDI - erreichen. Der XML-Einsatz stellt hierbei keineswegs einen revolutionären Ansatz dar, sondern liegt vielmehr schon allein wegen des Verbreitungsgrades und den damit einhergehenden Auswirkungen wie Werkzeugunterstützung und Ähnlichem nahe. Ausgehend von normiert ausgedrückten Inhalten drängt sich die Betrachtung des Kommunikationsprozesses auf. Gelingt es, den Interaktionsablauf ebenfalls standardisiert abzuwickeln, so würde damit das Einsatzfeld der angebotenen Dienstleistung nochmals erweitert. Einen Ansatz hierzu stellen die bekannten Mechanismen zur Abwicklung entfernter Methodenaufrufe sog. Remote Procedure Calls (RPC) dar. Unter Berücksichtung der Auswahl von XML als Inhaltsformat liegen Ansätze wie XML-RPC und dessen Weiterentwicklung, das Simple Object Access Protocol (SOAP), auf der Hand, da sie die Idee neutraler Funktionsaufrufe mit XML-codierten Inhalten kombinieren. Auf dieser Praktikumsversuch Web Service Security Lehrstuhl Netz- und Datensicherheit 4

5 Interoperabilitätsstufe umfasst die Definition bereits über das Web erbrachte Dienstleistungen, die mittels standardisierter Kommunikationsmechanismen abgestimmte Inhalte in einem ebenfalls abgestimmten Format transportieren. Immer noch bleibt jedoch die Natur der angebotenen Leistung für den Interessenten im Dunkeln. Diesem Manko abzuhelfen schicken sich Beschreibungssprachen wie die Web Service Description Language (WSDL) an. Ihre Konzeption orientiert sich an Darstellungsformen zur Beschreibung technischer Schnittstellen wie die bekannte CORBA Interface Definition Language (IDL). In jüngerer Zeit wurden einige XML-Vokabulare wie die Network Accessible Service Specification Language (NASSL) oder die Service Definition Language (SDL) vorgeschlagen, die allerdings keine übergreifende Unterstützung fanden. Diese wird jedoch der durch Microsoft und IBM gemeinsam entwickelten Web Service Description Language zuteil. Ihr Ansatz findet breite Zustimmung in der Anwendergemeinde und wird inzwischen auch durch eine W3C-Arbeitsgruppe als Grundlage eines Beschreibungsstandards für Web-Dienste diskutiert. Die durch WSDL bereitgestellten deskriptiven Inhalte erlauben es potentiellen Nutzern, sich über Dienste hinsichtlich ihres Angebots und der Abwicklungsmodalitäten wie etwa Aufrufkonventionen oder zu übergebende Parameter zu informieren. Offen bleibt in diesem Zusammenhang die Frage nach der Ermittlung der für den potentiellen Nutzer interessanten Dienste aus dem Angebot im Web. Die Erreichung dieser letzten Interoperabilitäsebene setzt sich der Ansatz Universal Service Description, Discovery, and Integration (UDDI) zum Ziel. Die grundlegende Organisation des Verzeichnisdienstes orientiert sich dabei an den bekannten Gelben Seiten. Ähnlich der dort anzutreffenden Mimik werden mit UDDI Dienst-Angebote klassifiziert und durch eine Reihe vordefinierter Zugriffsroutinen angeboten. Auch an dieser Stelle greifen die Web- Service-Architekten auf bewährte Ideen wie die CORBA Services naming und property zurück. Sie bildeten einen der Ausgangspunkte der inzwischen nicht mehr weiterentwickelten UDDI-Vorläuferprotokolle DISCO und ADS. Zusammenfassend lässt sich daher ein Web-Service als Komponente auffassen, die ihre Funktionalität über eine veröffentlichte Schnittstelle anbietet und über ein offenes, im Internet verwendetes Protokoll zugreifbar ist. UDDI XML WSDL SOAP Application (HTTP, FTP, SMTP) Transport (TCP/IP) Abbildung 2: Web Service Architektur Praktikumsversuch Web Service Security Lehrstuhl Netz- und Datensicherheit 5

6 Wozu Sicherheit? Weil Web Services eigenständige, selbst beschreibende Anwendungen sind, ist ihre Stärke an Hand der Interoperabilität und Modularität zu messen. Ein Web Service kann man sich als eine atomare, allgegenwärtige Anwendung (Funktion) vorstellen, die die Infrastruktur des Internets ausnutzt. Diese Eigenschaften implizieren auch Nachteile: sie sind gängigen Angriffen des Internets ausgesetzt. Aus der Perspektive der IT-Security muss in erster Linie gewährleistet werden, dass die Interkommunikation authentisch und integer erfolgt. Dies ist auf den ersten Blick kein einfaches Unterfangen. Es muss ein Vertrauensmodell (trust relationship) zwischen den interoperierenden Diensten bestehen, um einen Geschäftsprozess (z.b. Kauf eines Buches bei Amazon) sicher auszuführen. Darüber hinaus verlangen gewisse Situationen, dass die Interkommunikation vertraulich ist oder der Zugang auf einen Dienst zu begrenzen ist. Im Endeffekt sind die Ansprüche an Web Services und ihre Sicherheit die gleichen, wie sie auch von klassischen Web-Anwendungen erfüllt werden. Aber im Gegensatz zu Web- Anwendungen besteht keine Client/Server-Kommunikation, sondern eine fein-granulare Interaktionen von Funktionen, die über mehrere Dienste hinweg ausgeführt werden können. Deshalb reicht die konventionelle Absicherung auf Transportebene (z.b. SSL oder IPSec) nicht aus, weil dadurch eine Punk-zu-Punkt Verbindung abgesichert werden kann. Es werden neue Methoden, und Protokolle gebraucht, die diese Anforderungen erfüllen. High Level Security Frameworks XML Encryption XML Signature SAML XACML XrML XKMS WS-Security SOAP Transport Layer Transport Security Layer Abbildung 3: Web Service Security Um dieses Ziel zu erreichen, werden verschiedene, neue Standards eingesetzt, wie z.b.: XML Encryption Verschlüsselung von XML Dokumenten zur Geheimhaltung von Daten XML Signature Signierung von XML Dokumenten zur Wahrung der Datenintegrität und -authentifikation WS-Security SOAP-Erweiterung um Sicherheitsfunktionen (z.b. Einbindung von XML Sig/Enc) SAML Standard Assertion Markup Language Autorisation und Authentifikation XKMS XML Key Management Standard XML-Service zur Anbindung an eine existierende PKI In diesem Praktikum lernen sie den Umgang mit den ersten drei Standards kennen. Praktikumsversuch Web Service Security Lehrstuhl Netz- und Datensicherheit 6

7 Simple Object Access Protocol (SOAP) Das SOAP-Protokoll ist die Sprache der Web-Services. SOAP ist ein auf XML basierendes Protokoll, das auf allen gängigen Application-Layer-Protokollen aufsetzt. In der Regel setzt aber SOAP auf HTTP auf. Der Einfachheit halber kann man sich vorstellen, SOAP ermöglicht es Web-Services via Nachrichten miteinander zu kommunizieren, wobei es auch erlaubt ist die Nachricht über Zwischendienste (intermediaries) zu schicken. Abbildung 4: Processing model of SOAP messages In der unteren Grafik sieht man die vorgeschriebenen und optionalen Elemente einer SOAP- Nachricht. Eine Nachricht wird durch einen SOAP-ENVELOPE Tag gekennzeichnet. Der SOAP-HEADER, falls verwendet, kann Angaben zur Transaktionssteuerung oder zum Kontext enthalten, aber auch Verarbeitungsregeln. Der SOAP-BODY, also Hauptteil der Nachricht, enthält die Nutzdaten der Nachricht. Tabelle 1: SOAP-Aufbau Beispiel: <SOAP-ENV:Envelope xmlns:soap-env=" envelope/ xmlns:xsi=" xmlns:xsd=" <SOAP-ENV:Body> <ns1:getaccount xmlns:ns1="account:banksystem"> <number xsi:type="xsd:int"> </number> </ns1:getaccount> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Praktikumsversuch Web Service Security Lehrstuhl Netz- und Datensicherheit 7

8 Hilfsfragen Was ist ein Dienst? Was ist ein Geschäftsprozess? Was sind Web Services? Was ist der konzeptionelle Unterschied zu CORBA? Welche Vor-/Nachteile haben Web-Services? Welche Komponenten sind notwendig für Web Services? Welche Rolle spielen UDDI, WSDL und SOAP? Evaluieren sie die Notwendig dieser (drei) Komponenten. Was ist SOAP und wie funktioniert es? Was sind die Vor-/Nachteile einer Kommunikation durch SOAP? Welche Internet-Protokolle kennen sie? Welche Sicherheitsaspekte werden berücksichtig? Eignen sich diese Protokolle auch für Web-Services? Ist es sinnvoll, jede SOAP-Nachricht vollständig zu signieren oder zu verschlüsseln? Referenzen [1] SOAP, UDDI und WSDL SDL.mspx [2] Grundlegendes zu WS-Security ty.mspx [3] Apache Axis [4] Lavadora Plug-In [5] Java Documentation Praktikumsversuch Web Service Security Lehrstuhl Netz- und Datensicherheit 8

9 Aufgabe Für die folgende Bearbeitung stehen ihnen der Jacarta Tomcat 5.6 im Verzeichnis C:\Apache\tomcat, der Axis Web-Container im Verzeichnis C:\Apache\axis-1_2_1 zur Verfügung. Als Entwicklungsumgebung wird JavaSDK 5 Update und Bouncy Castle 1.29 verwendet. Aufgabe 1 Rufen sie Axis unter auf. Überprüfen sie, welche Services installiert sind. Beschreiben sie Version?wsdl. Aufgabe 2 In dieser Aufgabe werden sie den Umgang mit Web Services kennen lernen. Sie werden einen Hello World Service programmieren. Im Folgenden ist ihr Arbeitsverzeichnis \Aufagen\a2. Aufgabe 2a Schreiben Sie eine Java-Klasse HelloWorldService, die eine Echo Funktion enthält, welche den Wert eines Strings ausgeben soll. Kompilieren sie die Klasse und kopieren sie die Datei in %Axis%\webapps\axis\Web-Inf\classes. Aufgabe 2b Deployen sie den Web Service aus Aufgabe 2a. Editieren sie hierzu die Datei deploy.wsdd. Kontrollieren sie, ob der Service erfolgreich eingebunden wurde. Analysieren sie die generierte WSDL-Datei. Anleitung: Tip: Beachten sie, dass AdminClient explizit Port 80 angegeben wird. Aufgabe 2c Schreiben sie nun ein Client-Programm EchoClient, das den Web Service HelloWorldService aufruft und einen Hello World, Darling! String sendet. Nutzen sie hierfür das JAX-RPC DII Dynamic Invocation Interface. Anleitung: Tip: Weitere Beispiele für Client-Applikationen finden sie über die Desktop-Verknüpfung. Aufgabe 2d Starten sie den bereits deployten SOAP-Monitor und sniffen sie die Kommunikation mit. Anleitung: Aufgabe 3 Der Service HelloWorldService soll nun über SSL abgerufen werden. Modifizieren sie dementsprechend Apache Tomcat. Schreiben sie eine neue Client-Applikation EchoClient2 im Verzeichnis Aufgaben\a3, die den HelloWorldService über den richtigen (SSL) Port aufruft. Wiederholen sie anschließend Aufgabe 2d. Praktikumsversuch Web Service Security Lehrstuhl Netz- und Datensicherheit 9

10 Aufgabe 4 Der Service aus Aufgabe 2 (kein Einsatz von SSL!) soll derartig modifiziert werden, dass er die Eingabe verschlüsselt ausgibt. Nutzen sie hierfür die Bouncy Castle Bibliothek. Schreiben sie in Aufgaben\a4 einen HelloWorldService2, deployen sie ihn, und kontrollieren, ob er erfolgreich eingebunden wurde. Schreiben sie eine Client-Applikation, die den HelloWorldService2 aufruft. Wiederholen sie Aufgabe 2d. Hinweis: Sie können auch die vorhandene Klasse DesEncryption.java benutzen. Tip: Ihr Classpath sollte stets auf alle notwendigen Bibliothenken zeigen. Optional: Aufgabe 5 Wiederholen sie Aufgabe 4, wobei nun SSL eingesetzt werden soll. Auswertung Fassen sie die Grundlagen von Web Services zusammen, und diskutieren sie die Notwendigkeit des Einsatzes von Sicherheitsmaßnahmen. Beschreiben sie die Versuchsdurchführung und fassen sie ihre Ergebnisse zusammen. Sie haben unterschiedliche Wege kennen gelernt, wie Web Services abgesichert werden können. Stellen sie die Unterschiede heraus, erläutern sie die Unterschiede, und zeigen sie typische Einsatz- Szenarien auf. Berücksichtigen sie hierbei (a) die Vorteile von Web Services (d.h. stellen sie sich die Frage, was Web Services im Vergleich zur klassischen Client-Server-Architektur besser können), und (b) die kryptographische Güte der benutzten Sicherheitsmechanismen (d.h. Fragen sie sich, gegen welche (kryptographischen) Attacken die einzelnen Sicherheitsvorkehrungen resistent sind. Berücksichtigen sie u.a. Aspekte wie Robustheit oder Freshness). Praktikumsversuch Web Service Security Lehrstuhl Netz- und Datensicherheit 10