Sichere Kommunikation verteilter Applikationen über XML Web Services mit WS-Security
©2003
Diplomarbeit
116 Seiten
Zusammenfassung
Inhaltsangabe:Einleitung:
Nachdem die Sicherheit rund um Web Services nach wie vor ein Forschungsgebiet ist, das noch keine endgültigen Standards hervorgebracht hat, baut diese Arbeit zum Teil auf State-Of-The-Art Wissen und Erfahrungen aus der Forschung mit Technologien aus diesem Bereich auf.
Problemstellung:
Web Services stellen eine Möglichkeit der Kommunikation verteilter Systeme über Plattformgrenzen und verschiedene Programmiersprachen hinaus dar. Verglichen mit bisherigen Technologien, die diese Idee verfolgten, ist das Ziel der Web Service Bewegung, die dafür notwendigen Implementierungen so einfach und effizient wie möglich zu machen. Dies wird durch den Einsatz bereits standardisierter und etablierter Techniken und Protokolle wie XML, WSDL und SOAP, sowie die Nutzung der großteils bereits vorhandenen Infrastruktur für Webserver erreicht und soll auf diese Weise eine große Akzeptanz und weite Verbreitung dieser Technologie ermöglichen. Bei der Kommunikation über ungesicherte Protokolle, wie SOAP über HTTP, können Informationen leicht von Dritten abgefangen, gelesen oder verändert werden. Das Senden von öffentlichen Daten, wie aktuelle Weltnachrichten oder eine regionale Wettervorhersage über solche unsicheren Kanäle stellt keine große Gefahr dar. Sensible Informationen, wie Passworte oder Zahlungsinformationen, bergen jedoch die Gefahr des Missbrauches, wenn sie in falsche Hände geraten und sollten deshalb nur über gesicherte Kanäle übertragen werden. Um die Vorteile von Web Services nutzen zu können und Daten dennoch sicher zu übertragen, werden neue Sicherheitsstandards für die Kommunikation mit Web Services entwickelt, wovon die WS-Security Spezifikation in dieser Arbeit theoretisch betrachtet und praktisch angewandt wird.
Zusammenfassung:
Web Services stellen eine neue Möglichkeit der Kommunikation verteilter Applikationen über Plattformgrenzen hinaus dar und dominieren seit mehr als einem Jahr die einschlägige Presse. Das Interesse an Web Services eilt wie bei anderen Technologien der
Fertigstellung der Spezifikationen voraus, da noch nicht alle Aspekte der Kommunikation mit Web Services entwickelt oder standardisiert sind. Einer dieser Aspekte ist die Sicherheit. Marktführende Softwarehersteller wie IBM, BEA und Microsoft haben sich zusammengeschlossen, um die Spezifikation WS-Security zu entwickeln, die Standard-Sicherheitsbedürfnisse, wie Identifikation und Verschlüsselung, im Kontext von Web Services abdecken soll. Im Rahmen […]
Nachdem die Sicherheit rund um Web Services nach wie vor ein Forschungsgebiet ist, das noch keine endgültigen Standards hervorgebracht hat, baut diese Arbeit zum Teil auf State-Of-The-Art Wissen und Erfahrungen aus der Forschung mit Technologien aus diesem Bereich auf.
Problemstellung:
Web Services stellen eine Möglichkeit der Kommunikation verteilter Systeme über Plattformgrenzen und verschiedene Programmiersprachen hinaus dar. Verglichen mit bisherigen Technologien, die diese Idee verfolgten, ist das Ziel der Web Service Bewegung, die dafür notwendigen Implementierungen so einfach und effizient wie möglich zu machen. Dies wird durch den Einsatz bereits standardisierter und etablierter Techniken und Protokolle wie XML, WSDL und SOAP, sowie die Nutzung der großteils bereits vorhandenen Infrastruktur für Webserver erreicht und soll auf diese Weise eine große Akzeptanz und weite Verbreitung dieser Technologie ermöglichen. Bei der Kommunikation über ungesicherte Protokolle, wie SOAP über HTTP, können Informationen leicht von Dritten abgefangen, gelesen oder verändert werden. Das Senden von öffentlichen Daten, wie aktuelle Weltnachrichten oder eine regionale Wettervorhersage über solche unsicheren Kanäle stellt keine große Gefahr dar. Sensible Informationen, wie Passworte oder Zahlungsinformationen, bergen jedoch die Gefahr des Missbrauches, wenn sie in falsche Hände geraten und sollten deshalb nur über gesicherte Kanäle übertragen werden. Um die Vorteile von Web Services nutzen zu können und Daten dennoch sicher zu übertragen, werden neue Sicherheitsstandards für die Kommunikation mit Web Services entwickelt, wovon die WS-Security Spezifikation in dieser Arbeit theoretisch betrachtet und praktisch angewandt wird.
Zusammenfassung:
Web Services stellen eine neue Möglichkeit der Kommunikation verteilter Applikationen über Plattformgrenzen hinaus dar und dominieren seit mehr als einem Jahr die einschlägige Presse. Das Interesse an Web Services eilt wie bei anderen Technologien der
Fertigstellung der Spezifikationen voraus, da noch nicht alle Aspekte der Kommunikation mit Web Services entwickelt oder standardisiert sind. Einer dieser Aspekte ist die Sicherheit. Marktführende Softwarehersteller wie IBM, BEA und Microsoft haben sich zusammengeschlossen, um die Spezifikation WS-Security zu entwickeln, die Standard-Sicherheitsbedürfnisse, wie Identifikation und Verschlüsselung, im Kontext von Web Services abdecken soll. Im Rahmen […]
Leseprobe
Inhaltsverzeichnis
ID 7622
Morrenth, Florian: Sichere Kommunikation verteilter Applikationen über XML Web
Services mit WS-Security
Hamburg: Diplomica GmbH, 2004
Zugl.: Fachhochschule Technikum Wien, Diplomarbeit, 2003
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2004
Printed in Germany
__________________________________________________________________________________________________
-5-
Inhalt
1.
EINLEITUNG 1
2.
THEORETISCHE GRUNDLAGEN
2
2.1
Web Services
2
2.1.1
Anwendungsgebiete von Web Services
4
2.1.2
Web Service Protokolle
7
2.2
Sicherheit 14
2.2.1 Sicherheitsfaktoren
15
2.2.2 Exkurs:
Angriffe
19
2.2.3 Sicherheitskonzepte
22
2.3
Sicherheitsmechanismen 25
2.3.1
Authentifizierung und Autorisierung
25
2.3.2 Exkurs:
Kryptographie
33
2.3.3
Secure Socket Layer (SSL)
37
2.3.4 XML
Signature
40
2.3.5 XML
Encryption
44
2.3.6 WS-Security
49
2.3.7
Public Key Infrastructure (PKI)
51
3.
PRAKTISCHE AUSFÜHRUNG
55
3.1
Umfeld 55
3.2
Systematische Analyse
57
3.2.1 Sicherheit
57
3.2.2 Performance
59
3.2.3 Verfügbarkeit
59
3.2.4 Plattformunabhängigkeit
60
3.2.5 Versionisierbarkeit
60
3.3
Funktionalität 60
3.3.1 Benutzerinterface
61
__________________________________________________________________________________________________
-6-
3.3.2 Maschineninterface
65
3.4
Umsetzung des Projektes
73
3.4.1 Architektur
74
3.4.2 Datenbank
75
3.4.3 Kommunikationsklassen
76
3.4.4
Web Service Enhancement Toolkit
77
3.4.5 Systemüberblick
81
3.4.6
Public Key Infrastructure
82
3.4.7 Authentifizierung
82
3.4.8 SSL
83
3.4.9
Performance des Shepherd Web Services
86
4.
DISKUSSION 89
4.1
Wirtschaflticher Aspekt von Web Services
89
4.1.1
Entwicklung und Standardisierung von Web Services
89
4.1.2
Total Cost of Ownership und Return on Investment
90
4.1.3
Allgemeine Total Cost of Ownership Analyse
92
4.1.4
Allgemeine Return on Investment Analyse
93
4.1.5
Total Cost of Ownership und Return on Investment von Shepherd
93
4.2
Schlussfolgerungen 95
5.
GLOSSAR 98
6.
LITERATUR 100
7.
ANNEX 104
__________________________________________________________________________________________________
-1-
1. EINLEITUNG
Web Services gewinnen durch ihre Vorteile gegenüber anderen Technologien für verteilte
Systeme zunehmend an Bedeutung. Neben einer hohen Interoperabilität versprechen Web
Services kürzere Entwicklungszeiten und reduzierte Investitionskosten durch
Wiederverwendung. Web Services eröffnen völlig neue Perspektiven bei der
firmenübergreifenden Integration von Geschäftprozessen oder der firmeninternen
Integration heterogener Systeme. Standardisierte Technologien wie XML, SOAP, WSDL
und UDDI bieten dazu leistungsfähige Bausteine.
Diese Arbeit soll die Grundlagen von Sicherheit in Bezug auf die Kommunikation mit
Web Services erläutern und mögliche Umsetzungen dieser Sicherheitsmechanismen
aufzeigen. Es soll anhand eines Beispiels gezeigt werden, wie diese Mechanismen
umgesetzt werden können, um den Einsatz von Web Services auf Transport- und
Applikationsebene durch Identifikation und Vertraulichkeit sicherer zu gestalten.
Im theoretischen Teil dieser Arbeit werden Web Services im Allgemeinen behandelt und
deren Einsatzmöglichkeiten sowie bisher standardisierte Technologien erläutert. In
weiterer Folge werden verschiedene Aspekte von Sicherheit bei elektronischer
Nachrichtenübermittlung erarbeitet und einige Arten von Bedrohungen eines Web Services
dargestellt. Kapitel 2.3 Sicherheitsmechanismen behandelt anschließend die Themen
Authentifizierung und Sicherung der Transportschicht am Beispiel von Secure Socket
Layer, die eine sichere Kommunikation mit Web Services unabhängig von der
Implementierung des Web Services ermöglichen. Die Themen XML Signature und XML
Encryption werden daraufhin als Beispiele für die Sicherung der Botschaft selbst erklärt
und im Rahmen der WS-Security Spezifikation in Bezug zu Web Services gestellt. Als
Voraussetzung für den reibungslosen Einsatz von X509 Zertifikaten für die Signatur und
Verschlüsselung wird danach das Prinzip einer Publik Key Infrastructure erklärt, das auch
in der praktischen Umsetzung Anwendung findet. In Kapitel 3 wird nach einer
systematischen Analyse des Umfeldes und der Anforderungen des Projektes, die praktische
Anwendung der zuvor erläuterten Sicherheitsmechanismen mit einer detaillierten
Funktions- und Umsetzungsbeschreibung erklärt. Abschließend wird eine wirtschaftliche
Betrachtung von Web Services und eine Diskussion der Schlussfolgerungen
vorgenommen.
__________________________________________________________________________________________________
-2-
2. THEORETISCHE GRUNDLAGEN
In diesem Kapitel werden die theoretischen Grundlagen für den Einsatz von
sicherheitsrelevanten Technologien im Umfeld von Web Services erläutert. Nach einer
allgemeinen Erklärung der Idee hinter Web Services wird auf deren Funktionsweise und
verschiedene Anwendungsmöglichkeiten sowie die Standards, auf denen Web Services
aufbauen, eingegangen. Danach werden Fragen der Sicherheit im Bezug auf Web Services,
mögliche Angriffsarten sowie Techniken zur Sicherung der Kommunikation näher
beschrieben. Ein Exkurs in die Kryptographie beschreibt dabei die Grundlagen von
Signatur und Verschlüsselung. Abschließend wird auf eine Spezifikation eingegangen,
welche die zuvor beschriebenen Techniken im Umfeld von Web Services umsetzt und
auch in der praktischen Ausführung Anwendung findet.
2.1 WEB SERVICES
Aktuelle Webapplikationen gehen davon aus, dass ihre Clients Webbrowser sind, die
direkt von Menschen benutzt werden, um Information zu sammeln oder sich
auszutauschen. Angenommen diese Applikationen generieren HTML und erzeugen eine
graphische Benutzeroberfläche, so funktioniert diese Art der Kommunikation einwandfrei,
was die breite Nutzung solcher Applikationen im Internet bestätigt. Das ist aber nicht die
einzige Möglichkeit Information über das Internet auszutauschen. Ebenso wie Browser
können Desktopprogramme als Clients einer Webapplikation agieren, um beispielsweise
online Flugtickets zu reservieren. Dies ist herkömmlichen Programmen durch Parsen und
Extrahieren der benötigten Information einer Webseite möglich, was einen erheblichen
Entwicklungsaufwand mit sich bringt. Eine einfachere Möglichkeit ist es, die
Funktionalitäten einer Webseite, wie etwa die Suche nach Flügen und die Reservierung der
Tickets, entfernt aufrufen zu können. Genau diese Möglichkeit bieten Web Services. Sie
stellen Webapplikationen dar, deren veröffentlichte Methoden mit entsprechenden
Parametern aufgerufen werden und ein Ergebnis zurückliefern. [W1]
Die einschlägige Presse [I4] diskutiert zurzeit die Vor- und Nachteile die Web Services mit
sich bringen, sowie die Technologie und die Standards, die Web Services so populär
machen. Wie bei anderen Technologien gelten das große Interesse und die
__________________________________________________________________________________________________
-3-
Erwartungshaltung der endgültigen Fertigstellung der Spezifikationen und immer wieder
tauchen Fragen nach dem wirklichen Nutzen von Web Services auf. [W2] Julian Bond
schreibt in einem Artikel über die Missverständnisse bezüglich Web Services: "Web
Services are systems that enable application to application communication across the
internet, in the same way that the early internet protocols focussed on application to user
communication across the internet." [W3] Er reduziert damit die Beschreibung von Web
Services auf die Essenz von entfernten Methodenaufrufen, die schon seit Jahren in
verschiedensten Formen bekannt sind. David Chapell schreibt in seinem Artikel "Lifting
the fog on Web services":
"The truth (about Web Services, Anm. d. Verf) is that the core idea of Web services --
invoking methods in remote systems -- has been around for decades. As most commonly
used today, SOAP is just another way to do RPC. Riding on HTTP is a useful idea, but
not much of an innovation. The difference between SOAP and its many antecedents,
including Microsoft DCOM, Java RMI and CORBA IIOP, is that every vendor has
bought into it." [W4]
Der Kern der Revolution von Web Services besteht demnach nicht so sehr in einer
neuartigen Technologie oder in den verwendeten Transportmechanismen und
Protokollen, sondern in der Art und Weise in der sich marktführende Softwarehersteller
und Standarisierungsorganisationen auf einen Weg geeinigt haben. Dieses Einverständnis
bedeutender Organisationen wie IBM, BEA, SUN und Microsoft stellt eine Grundlage für
die breite Akzeptanz von Web Services dar und soll helfen proprietäre Mechanismen zu
ersetzen.
Das Ziel von Web Services ist es, auf einfache Weise eine einheitliche Kommunikation
zwischen verteilten Applikationen zu ermöglichen, um dadurch herkömmliche Grenzen
wie Betriebssysteme, Programmiersprachen und Softwarearchitektur zu überwinden. Eine
mögliche Definition von Web Services beinhaltet die Kernaussagen verschiedener
Definitionen und umfasst folgende Punkte.
__________________________________________________________________________________________________
-4-
· Web Services stellen Webusern oder Applikationen nützliche Funktionalitäten für
entfernte Methodenaufrufe über Standard Webprotokolle zur Verfügung.
· Web Services bieten die Möglichkeit, ihr Interface und ihre Funktionalität
hinreichend genau zu beschreiben, um einem Client eine Kommunikation mit ihm
zu ermöglichen. Diese Beschreibung ist in einem XML Dokument in der ,,Web
Service Description Language" (WSDL) zusammengefasst. [W5]
Nachdem die Grundzüge und das Wesen von Web Services behandelt sind, werden im
Folgenden Kapitel einige exemplarische Einsatzmöglichkeiten von Web Services umrissen
und anhand eines konkreten Beispiels erläutert.
2.1.1 Anwendungsgebiete von Web Services
Web Services können in vielen Bereichen und auf verschiedene Weise firmenintern oder
über das Internet genutzt werden. Im Folgenden wird ein denkbarer Einsatz der Web
Service Technologie anhand der Dienste einer Fluggesellschaft vorgestellt.
Sicherheitsrelevante Aspekte werden hier im Sinne einer Symbolisierung außer Acht
gelassen und erst in Kapitel 2.2 Sicherheit detailliert betrachtet.
Web Services werden in den allermeisten fällen in eine Multitier Architektur eingebunden,
in der unterschiedliche Maschinen über ein Netzwerk miteinander kommunizieren. In einer
solchen Architektur können ein oder mehrere Web Services in unterschiedlichen logischen
Programmschichten involviert sein. In speziellen Fällen kann ein Benutzer direkt über
einen Browser die Dienste eines Web Services über HTTP GET oder HTTP POST in
Anspruch nehmen, wobei auf die meisten Sicherheitsmechanismen, ausgenommen
gewisser Authentifizierungsmaßnahmen über den Browser und leitungsnahen
Verschlüsselungsmechanismen wie SSL, verzichtet werden muss.
Zwei Möglichkeiten für direkte Zugriffsarten, bei denen ein Client, der in der Regel eine
Applikation und kein Mensch ist, auf die Funktionalitäten eines Web Services über LAN
oder das Internet zugreift und diese in seine eigene Logik einbindet, sind in Abbildung 1
symbolisiert. Eine Client involviert das Web Service einer Fluggesellschaft, um verfügbare
Flüge anzeigen zu können, um gewünschte Flüge zu reservieren und der Fluglinie
entsprechende Zahlungsinformationen zukommen zu lassen. Das Web Service kann, um
__________________________________________________________________________________________________
-5-
die Anfrage des Clients verarbeiten zu können, andere Netzwerke und Ressourcen wie
Datenbanken und sogar andere Web Services einbinden. Die Logik hinter dem Web
Service, sowie alle Ressourcen auf die das Web Service zugreifen muss, sind für den
Client jedoch nicht von Bedeutung.
Abbildung 1 - Web Service Architektur: Direkter Zugriff über LAN und Internet
Das zweite Architekturbeispiel bildet einen Client ab, der über einen Browser auf das
Angebot des Webservers zugreift. Der Webserver in Abbildung 2 bietet z.B. eine
herkömmliche Informationsseite im Internet an, deren graphisches Interface im Browser
angezeigt werden kann. Die Informationen, die auf dieser Webseite dargestellt werden,
können direkt von einem Web Service bereitgestellt werden, das wiederum eine logische
Verarbeitung anderer Ressourcen vornimmt. Am Beispiel der Fluggesellschaft könnte das
Web Service durch eine Methode aktuelle Abflugzeiten und Informatioenn über stornierte
Flüge bereitstellen, welche die Webseite verarbeitet und entsprechend ihrer
Designrichtlinien darstellt. Das gleiche Web Service kann durch eine andere Methode die
im vorigen Szenario beschriebenen Funktionen für einen Reservierungsclient bereitstellen,
sodass die Businesslogik der Fluggesellschaft für externe Benutzer nur in diesem einen
Web Service gepflegt werden muss. Die Datenspeicherung kann in einem hausinternen
System erfolgen, auf das auch alle anderen internen Applikationen zugreifen.
Abbildung 2 - Web Service Architektur: Indirekter Zugriff über eine Webseite
Das obere Szenario kann beispielhaft durch die Nutzung einer externen Quelle erweitert
oder verändert werden, sodass die Informationen die auf der Webseite nicht von einem
hausinternen Web Service, sondern von einem Drittanbieter über das Internet bezogen
__________________________________________________________________________________________________
-6-
werden. So kann dem Benutzer ein breites Angebot zur Verfügung gestellt werden, das mit
verschiedenen Reiseveranstaltern, Autovermietern und anderen Fluglinien abgestimmt ist
oder auf aktuelle Anfragen der Internetnutzer reagieren kann, indem es in Echtzeit die
Anzahl verfügbarer Plätze von Drittanbietern einfordert. Die Webseite der Fluggesellschaft
kann z.B. auch mit aktuellen Wetterdaten der angeflogenen Destinationen interessanter
gestaltet werden. Diese Daten können von dem Web Service einer meteorologischen
Einrichtung bereitgestellt werden. Abbildung 3 stellt dieses Szenario schematisch dar.
Abbildung 3 - Web Service Architektur: Indirekte Nutzung dritter Parteien
Abbildung 4 zeigt am Beispiel der Fluggesellschaft ein Gesamtbild der erarbeiteten
Architekturen. Der Smart Client (Applikation) kommuniziert über SOAP mit dem Web
Service der Fluggesellschaft und bereitet dem Anwender die Information über sein GUI
auf. Der Thin Client (Browser) hat lokal kein spezifisches Programm zur Flugreservierung
installiert und benutzt seinen Browser, um auf die Webseite der Fluggesellschaft
zuzugreifen, die Reservierungen auch über das hausinterne Web Service abwickelt.
Zusätzlich integriert die Webseite noch passende Informationen von Drittanbietern wie
Wetterdiensten, die einen erhöhten Kundennutzen bieten. Das Web Service der
Fluggesellschaft verarbeitet nun zentral alle externen Anfragen und speichert diese in eine
Datenbank, die auch von allen hausinternen Applikationen benutzt wird.
__________________________________________________________________________________________________
-7-
Abbildung 4 - Beispielhafte Vernetzung durch Web Services
Das entwickelte Szenario zeigt, dass Applikationen die Funktionen von verschiedenen
Web Services gleichzeitig implementieren können. Um eine solche verteilte
Kommunikation zu ermöglichen, bauen Web Services auf Standardprotokollen wie WSDL
zur Beschreibung, SOAP als Kommunikationssprache und UDDI zur Registrierung und
Suche von Web Services auf. Diese Standards werden im Folgenden kurz umrissen.
2.1.2 Web Service Protokolle
In dieser Sektion werden die Standards und Protokolle erklärt, die eine Interoperation von
Web Services mit entfernten Systemen ermöglichen.
2.1.2.1 Extensible Markup Language (XML)
XML ist aus SGML (Standard Generalized Markup Language) entstanden, die bereits in
den achtziger Jahren zum größten Teil von IBM entwickelt wurde. SGML gilt als
Muttersprache der Markupsprachen, wobei HTML nur eine kleine Teilmenge darstellt, die
__________________________________________________________________________________________________
-8-
aus dem SGML Standard entsprungen ist und einen sehr beschränkten Befehlssatz von
formatierenden Befehlen aufweist. ,,XML ist eine Metasprache zur Beschreibung
strukturierter Daten", [W6] die primär der Datenspeicherung und Datenbeschreibung auf
Metaebene dient. Eine allfällige Formatierung des Inhaltes wird durch Stylesheets und
andere Formatierungssprachen wie XSL und XSLT bestimmt. XML besteht aus
Elementen, Attributen, Processing Instructions und Inhalten. Die Inhalte können innerhalb
eines Elementes oder als Wert von Attributen übermittelt werden. Durch die Struktur des
XML Dokumentes werden die Daten auf einer Metaebene implizit beschrieben und
definiert. Eine vollständige Elementangabe besteht aus Start- und Endetag sowie dem
Inhalt des Elements:
<elementname>Inhalt</elementname>
Leere Elemente können verkürzt angegeben werden:
<elementname/>
Attribute beschreiben nähere Eigenschaften eines Elements:
<elementname wert="xy">Inhalt</elementname>
Eine Processing Instruction mit der Angabe der benutzten XML Version ist beispielsweise:
<?xml version="1.0" ?>
XML ist case sensitive und verlangt nach wohlgeformten Daten, die folgende
Bedingungen voraussetzen:
· Es ist eine XML-Deklaration wie <?xml version="1.0" ?> vorhanden
· Es ist genau ein Rootelement vorhanden. Dieses wiederum kann weitere Elemente,
Attribute oder Inhalte beherbergen.
· Die Elemente sind korrekt geschachtelt. Kindelemente müssen demnach
geschlossen werden, bevor das Elternelement geschlossen wird.
· spezielle Zeichenketten werden als Entities codiert und in Anführungsstrichen
angegeben.
Web Services benutzen Standards wie WSDL zur ihrer Beschreibung und SOAP zum
Aufruf ihrer Funktionen, die auf XML basieren.
__________________________________________________________________________________________________
-9-
2.1.2.2 Web Service Description Language (WSDL)
Durch die Web Service Description Language wird eine einheitliche Beschreibung von
Schnittstellen und deren Funktionalität eines Web Services erreicht, die aus dem Namen
des Web Services, den verfügbaren Interfaces, den angebotenen Methoden und deren
Parametern besteht, sowie die Serialisierungsvorschriften für die Werte der Parameter und
der Rückgabewerte beinhaltet. Eine solche Beschreibung wird als Vertrag bezeichnet, da
sich alle Kommunikationspartner an die darin festgelegten Bedingungen halten müssen um
eine funktionierende Einbindung von Web Services zu erreichen. Die Beschreibung des
Transportweges eines Web Services ist nicht an SOAP über HTTP gebunden, sondern
kann andere Kommunikationsprotokolle wie zu Beispiel SMTP oder FTP vorschreiben. In
den meisten Fällen wird ein Web Service jedoch mit einer SOAP message angesprochen,
die über HTTP gesendet wird. Durch die Flexibilität der WSDL können mit ihr neben Web
Services auch andere Netzwerkressourcen und vollkommen eigenständige
Kommunikationsanforderungen beschrieben werden. [I5]
Ein WSDL Dokument kann in zwei Sektionen unterteilt werden, wobei die erste Sektion
abstakte Definitionen in einer plattform- und sprachunabhängigen Weise beschreibt, die
keine maschinenspezifischen Elemente enthält. Auf diese Weise werden verschiedene
Services deklariert, die von unterschiedlichen Systemen mit unterschiedlichen
Anforderungen an konkrete Protokolle gebunden werden. Der zweite Teil eines WSDL
Dokuments besteht aus konkreten, spezifischen Bindungen auf Protokollebene und
Netzwerkadressen, unter denen das Web Service erreichbar ist. Abbildung 5 verdeutlicht
diese Trennung.
__________________________________________________________________________________________________
-10-
Abbildung 5 - Aufbau eines WSDL Dokumentes
Die abstrakten Definitionen umfassen folgende Elemente:
·
types Hier werden alle relevanten Datentypen wie serialisierte Objekte und Arrays
spezifiziert, die für die Kommunikation mit dem Web Service notwendig sind. In
weiterer Folge werden diese Typen nur mehr referenziert dargestellt. Dieser Teil
einer WSDL Beschreibung kann entfallen, wenn nur Datentypen Verwendung
finden, die von XML Schemas spezifiziert sind, die primitive XML Datenstrukturen
wie Integer und Float zentral beschreiben. Die XML Schema Spezifikation kann
unter [W25] eingesehen werden.
·
messages Dieses Element beinhaltet eine abstrakte Darstellung aller logischen
Nachrichtenformen, die ein Web Service empfangen und versenden kann.
·
portTypes Dieses Element umfasst eine Liste aller abstrakten Operationen und
definiert die akzeptierten Nachrichtenformen für jede Methode eines Web Services.
·
bindings Hier werden die Formate und Protokolle für jeden der zuvor definierten
portTypes spezifiziert.
·
services Dieser Bereich gibt verschiedene Ports an, die jeweils an physikalische
Adressen des Web Services gebunden sind.
__________________________________________________________________________________________________
-11-
Nachdem ein Client die Funktionen eines Web Services über das WSDL Dokument in
Erfahrung gebracht hat, kann er dessen Methoden z.B. über SOAP messages aufrufen.
2.1.2.3 SOAP
Die Definition Simple Object Access Protocol wurde in der SOAP Spezifikation 1.2
entfernt, wodurch SOAP nunmehr als eigenständiges Akronym existiert. [W18]
Das SOAP ist das Kernprotokoll für Web Services und ist ein XML Standard um entfernte
Methoden eines Web Services aufzurufen. Es stellt durch seinen simplen Aufbau und seine
Flexibilität das meistgenutzte Protokoll für den Aufruf von Web Services dar. [W19]
SOAP definiert sowohl das Format des Methodenaufrufes, als auch das Format der
übergebenen Parameter. SOAP definiert hingegen nicht, wie die Methoden selbst
implementiert werden müssen, sondern nur die Kommunikation mit ihnen. [A1]
SOAP ist eine XML Spezifikation wodurch alle SOAP messages in XML codiert werden.
Demnach haben SOAP messages genau ein Rootelement namens Envelope, das zumindest
das Element Body beinhalten muss. Abbildung 6 stellt die folgenden Begriffe grafisch dar.
<Envelope>:
Alle SOAP messages sind vom dem Element Envelope eingeschlossen. Innerhalb dieses
Elementes muss sich ein einzelnes Element Body befinden. Wird das optionale Element
Header verwendet, muss es als erstes Element im Envelope stehen und darf ebenfalls nur
einmal vorhanden sein. Zusätzlich können noch selbst definierte Elemente innerhalb des
Envelopes vorhanden sein, die nach dem Element Body stehen und durch einen
Namespace qualifiziert sein müssen.
<Header>:
In dem Element SOAP Header können Metainformationen mit der SOAP message
transportiert werden, die nicht notwendigerweise Teil des Methodenaufrufes sind, jedoch
zusätzliche Daten wie Benutzeridentität, transaktionsrelevante Daten oder
Routinginformationen beinhalten können.
__________________________________________________________________________________________________
-12-
Das Attribut mustUnderstand kann in jedes Element innerhalb des Headers eingebunden
werden. Kann der Server ein Element das mit mustUnderstand=1 ausgezeichnet ist nicht
bearbeiten, muss die gesamte SOAP message verworfen und stattdessen eine
entsprechende Fault message zurück geschickt werden. Dadurch wird gewährleistet, dass
sicherheitsrelevante Informationen nicht unberücksichtigt bleiben.
<Body>:
Dieses Element ist immer vorhanden. Es definiert durch seinen Inhalt den Typ der SOAP
message. Es gibt folgende Typen von SOAP messages:
·
method call - Dies ist ein Aufruf einer entfernten Methode und beinhaltet den Namen
der aufgerufenen Methode und die erwarteten Parameter in XML serialisiert.
·
response message Dies ist die Antwort eines Web Services und beinhaltet die
Ergebnisse des Methodenaufrufes.
·
fault message - ist eine spezielle Form der response message und wird vom Web
Service generiert, wenn das remote Object eine Exception wirft oder auf sonstige
Weise einen Fehler generiert. Eine fault message kann nur erzeugt werden, wenn das
Web Service erreicht und eingebunden wurde. Tritt bei der Kommunikation ein
Fehler auf, der auf das Transportprotokoll zurückzuführen ist, dann erhält der
Aufrufer eine transportspezifische Fehlermeldung.
__________________________________________________________________________________________________
-13-
Abbildung 6 - Aufbau einer SOAP message
2.1.2.4 Hypertext Transfer Protocol (HTTP)
HTTP ist das bevorzuge Transferprotokoll für SOAP messages und die Kommunikation
mit Web Services. HTTP bildet somit einen Quasi-Standard und ist ein einfaches
Protokoll, das in kurzer Zeit große Datenmengen transportieren kann, jedoch den gesamten
Verkehr in Klartext überträgt. Die Übertragung von Information ohne Verschlüsselung
oder andere Sicherheitsmechanismen kann ohne Bedenken für öffentliche Informationen
wie Wetterdaten oder die Aussendungen von Nachrichtendiensten verwendet werden.
Werden jedoch sensible oder wertvolle Daten übertragen, wie z.B. Versicherungsnummer,
Zahlungsinformationen, kryptographische Schlüssel oder Zugangsdaten zu einem
Bankkonto, so ist eine Übertragung über HTTP in Klartext tunlichst zu vermeiden. Andere
Personen können z.B. mit Sniffern die Kommunikationspakete abfangen und
zusammensetzen, um die gesendeten Informationen zu missbrauchen. Um die Sicherheit
der Kommunikation mit Web Services zu erhöhen, können auf verschiedenen
Netzwerkschichten unterschiedliche Verfahren angewendet werden die im Kapitel 2.2
Sicherheit näher beschrieben sind.
__________________________________________________________________________________________________
-14-
2.1.2.5 Universal Description, Discovery and Integration (UDDI)
Universal Description, Discovery and Integration ist ein Verfahren, das zur Registrierung
von Web Services angewandt wird und ähnlich wie ein elektronisches Telefonbuch
funktioniert, in dem potentielle Kunden nach Diensten, Unternehmen und Branchen
suchen können. Die meisten UDDI Dienste bieten ihren Service auch als Web Service an,
um Kunden die Abfrage über SOAP messages zu ermöglichen. Unter anderem stellen
Microsoft und IBM UDDI Services bereit. UDDI Dienste sind in drei unterschiedliche
Kataloge geteilt, die untereinander verbunden sind. In den white pages können allgemeine
Informationen wie die URL des Web Services und der Name des Anbieters abgerufen
werden. Die yellow pages sind vergleichbar mit den Gelben Seiten und beinhalten
Informationen nach Branchen sortiert an. Die green pages bieten spezifische Informationen
über die Dienste und die Interfaces eines Web Services an. Abbildungen 7 zeigt einen
kurzen Überblick über die Funktionsweise von UDDI Services.
Abbildung 7 - Veröffentlichung eines Web Service über UDDI
2.2 SICHERHEIT
Die bisher erläuterten Techniken ermöglichen den Einsatz von Web Services in
interoperablen Szenarien, gewährleisten jedoch keinerlei Art von Sicherheit. In diesem
Kapitel wird das Gebiet ,,Sicherheit" im Umfeld von Web Services erklärt und abgegrenzt,
sowie Angriffsmöglichkeiten gegen Web Services erläutert.
__________________________________________________________________________________________________
-15-
Bei der Übertragung über ungesicherte Netze, wie das Internet, ist das Thema Sicherheit
seit jeher eine Herausforderung und ist einem permanenten Wandel unterworfen, der aus
der ständigen Weiterentwicklung von Sicherungsmechanismen resultiert.
Speziell in einem wirtschaftlichen Umfeld, in dem vertrauliche und verbindliche
Informationen übertragen werden müssen, sind Sicherheitsvorkehrungen unerlässlich, um
die Daten vor der Einsicht Unbefugter, vor allem aber vor der Veränderung und dem
Verlust von Integrität zu schützen. [A2]
2.2.1 Sicherheitsfaktoren
Die Sicherheit von elektronischen Nachrichten baut im Wesentlichen auf drei Säulen auf,
die in kleinere Teilbereiche zerlegt werden können. Eine Säule der Sicherheit ist die
Authentizität, durch die ein Kommunikationspartner einerseits eindeutig identifiziert
werden kann, andererseits an den Inhalt der Nachricht gebunden wird, sodass keine
Zweifel an dem Ursprung einer Nachricht aufkommen können. Die zweite Säule ist die
Vertraulichkeit, die garantieren soll, dass die Nachricht nicht von unbefugten Personen
gelesen werden kann. Die dritte Säule ist die Integrität, die garantieren soll, dass die
Nachricht auf dem Transport vom Sender zum Empfänger nicht verändert wurde.
Das Fehlen einer der drei Säulen der Sicherheit führt zu einer kompromittierten Nachricht,
in der die anderen beiden Sicherheitsfaktoren nicht mehr gewährleistet werden können.
Ohne Vertraulichkeit kann jeder den Inhalt einer Nachricht erfassen und in Klartextform
lesen. Wenn die Integrität einer Nachricht nicht gewährleistet wird und der Empfänger
nicht die gleichen Daten erhält, die der Sender abgeschickt hat, muss die Verbindlichkeit
außer Kraft gesetzt werden, weil der Sender nicht mehr für den Inhalt der veränderten
Nachricht verantwortlich gemacht werden kann. Ohne genaue Kenntnis der Identität des
Kommunikationspartners kann eine gefälschte Nachricht nicht als solche erkannt werden.
__________________________________________________________________________________________________
-16-
Als illustratives Beispiel kann man sich die drei Säulen der Sicherheit als dreibeinigen
Sessel vorstellen (vgl. Abbildung 8).
Abbildung 8 - drei Säulen der Sicherheit
2.2.1.1 Identifikation
Abgesehen von der notwendigen Identifizierung der kommunizierenden Parteien bei
wirtschaftlichen Transaktionen bringt die Kenntnis über die Identität der Anwender eines
Web Services auch weitere Vorteile mit sich.
Durch die Notwendigkeit der Identifikation verliert der Nutzer eines Web Services seine
Anonymität, wodurch Manipulationsversuche des Systems leichter unterbunden werden
können, indem der betreffende User Rechte für die Nutzung des Web Services verliert oder
ihm der Zugriff ganz entzogen wird.
Das Nutzungsverhalten einzelner Kunden und ganzer Gruppen kann über statistische
Daten wie Zugriffszeit, häufigkeit und abgefragtes Datenvolumen hinaus analysiert
werden. So können z.B. das Alter, die Ausbildung oder die Berufe der Nutzer des Web
Services als Grundlage für einen anwenderorientierten Verbesserungsvorgang der
angebotenen Services dienen. Ein derartiger Verbesserungsprozess muss nicht explizit
durch Feedback der Kunden angestoßen werden, sondern kann im Sinne einer
kontinuierlichen Korrektur der angebotenen Dienste und deren Anpassung an implizite
Bedürfnisse der Kunden zu einer positiven Entwicklung des Angebots und zur vermehrten
Nutzung der Services führen.
Explizite Anpassungen an die Gewohnheiten und Vorlieben der User können in
persönlichen Profilen auf der Clientmaschine oder im eigenen System gespeichert werden,
__________________________________________________________________________________________________
-17-
um beispielsweise zahlungsrelevante Informationen, wie Kreditkartennummer und
Anschrift, bereitzustellen.
2.2.1.2 Authentifizierung und Autorisierung
Nach der vertrauenswürdigen Authentifizierung der Identität eines Clients und dem
Aufbau einer sicheren Übertragungsmöglichkeit, z.B. über den Austausch von X509
verschlüsselten Nachrichten, kann dem Gegenüber ein vorbestimmter Grad an Vertrauen
entgegengebracht werden. Aufgrund der Authentifizierungsinformationen kann das System
entscheiden, ob der Kommunikationspartner klassifizierte Informationen einsehen und
verändern oder ob er nur öffentlich zugängliche Informationsarten abrufen darf.
Mechanismen zur Authentifizierung werden im Kapitel 2.3.1 detailliert beschrieben.
2.2.1.3 Verbindlichkeit
Die Verbindlichkeit elektronischer Kommunikation, wie E-Mailverkehr und
Transaktionen, soll garantieren, dass sich niemand hinter dem Schutz der Anonymität des
Internetzes oder dem Verweis auf die Kompromittierung einer Nachricht von getätigten
Aussagen, Versprechen oder Geschäftsabschlüssen zurückziehen kann. Dies trägt einen
Grossteil zur Anerkennung elektronischer Unterschriften und dem Ersatz des
herkömmlichen Papierweges bei. Wenn alle beteiligten Parteien Vertrauen in das
eingesetzte System zur Sicherstellung der Verbindlichkeit und anschließenden
Speicherung unter garantiertem Ausschluss von unbefugten oder unverfolgten
Veränderungen haben, kann auf zusätzliche Mechanismen, wie händische Unterschriften,
verzichtet werden. Dadurch können Geschäfte und Transaktionsprozesse problemlos
weltweit ohne relevante Zeitverzögerung durch zeitkritische persönliche Treffen aller
Parteien bindend geschlossen werden.
Um die Verbindlichkeit einer internetbasierten Transaktion zu garantieren, ist es
erforderlich, den gesamten Inhalt jeder Transaktion glaubwürdig zu reproduzieren und
gegebenenfalls widerrufen zu können. Jeder verändernde Zugriff auf die Kommunikation
muss in seiner Art und seinem Ursprung erkennbar und nachweisbar sein. Um dies zu
erreichen, muss das Web Service entsprechende Verschlüsselungs- und Signaturmethoden,
__________________________________________________________________________________________________
-18-
sowie Mechanismen zur Nachverfolgung betreiben und den Inhalt der Transaktion eine
angemessene Zeit lang nach der Bearbeitung auf ebenso gesicherte Weise speichern.
2.2.1.4 Vertraulichkeit
Ein großer Bestandteil der Vertrauenswürdigkeit ist die Vertraulichkeit, mit der
persönliche Daten behandelt werden. Diese Vertraulichkeit dem Kunden gegenüber muss
glaubhaft versichert und auch tatsächlich umgesetzt werden.
2.2.1.5 Integrität
Integrität ist bei einem geschäftlichen, internetbasierten Vorgang unerlässlich, um seine
Nutzung attraktiv zu machen. Die Qualität einer Software, die als Produkt oder
Dienstleistung eines Unternehmens angeboten wird, gilt als Referenz für den
Qualitätsbegriff des Unternehmens allgemein. Speziell bei Web Services, die in
Transaktionen eingebunden werden, ist darauf zu achten, dass die Geschlossenheit einer
Transaktion, sowie die Zuverlässigkeit und Konsistenz der Ergebnisse einer solchen
Transaktion, in allen Fällen gesichert ist. Ein Nutzer eines geschäftlich orientieren Web
Services soll davon überzeugt sein, dass seine Transaktion komplett, privat und sicher war.
Um dies zu ermöglichen, muss das Web Service vor unvollständigen Transaktionen und
unsicheren Zugriffen geschützt werden. Ersteres kann durch ein ausgeprägtes Feedback an
entsprechenden Stellen sowie auch durch Empfangs- und Bearbeitungsbestätigungen und
eine solide Architektur des gesamten Tranksaktionsvorganges erreicht werden.
Möglichkeiten, ein Web Service vor unbefugten oder befugten aber unsicheren Zugriffen
zu schützen, werden in diesem Kapitel später ausführlich beschrieben.
Die Beziehungen der beschriebenen Sicherheitsfaktoren sind in Abbildung 9 grafisch
dargestellt und erklärt.
__________________________________________________________________________________________________
-19-
Abbildung 9 - Beziehung der Sicherheitsfaktoren
Die Faktoren Identität, Authentifizierung und Autorisierung betreffen direkt die
Kommunikationspartner und das Vertrauen sowie die Rechte, die ihnen entgegengebracht
werden, während die Vertraulichkeit und die Integrität sich auf die Nachricht und
involvierte Dritte beziehen. Verbindlichkeit stellt die Beziehung zwischen Sender und
Botschaft her, wobei Sicherheit nur in einem Gesamtkonzept gewährleistet werden kann,
das in Kapitel 2.3 Sicherheitsmechanismen aufgebaut wird. Davor werden jedoch noch
mögliche Angriffe gegen Web Services dargestellt, um einen Überblick über die
Bedrohung der Sicherheit bei Kommunikation mit Web Services zu bieten. [W11]
2.2.2 Exkurs: Angriffe
Verschiedene Klassen von Angriffen, die gegen Netzwerkapplikationen durchgeführt
werden können, bedrohen die Sicherheit, sowie die Verfügbarkeit von Web Services. Im
Folgenden werden einige relevante Varianten von Attacken auf Web Services umrissen,
um die Möglichkeiten böswilliger Individuen aufzuzeigen.
Einer der häufigsten Angriffe auf Web Services und Webseiten, die eine Authentifizierung
erfordern, ist das ausspionieren von Zugangsdaten legitimer User, die anschließend
verwendet werden, um die Daten dieser User einzusehen oder zu manipulieren. Ein
__________________________________________________________________________________________________
-20-
größerer Schaden kann angerichtet werden, falls Zugangsdaten von Benutzern höherer
Berechtigungsstufen, wie etwa Administratoren, abgefangen werden. In solchen Fällen
sind nicht nur die Daten eines Users, sonder die Integrität des gesamten Datenbestandes
gefährdet.
Eine der Möglichkeiten, das Passwort eines Benutzers zu erfahren, ist die plaintext attack,
bei der das Passwort geraten wird. Meist führt diese Attacke bei unsicher gewählten
Passworten, wie Vornamen aus dem Familienkreis oder den Namen der Haustiere, zum
Erfolg. Eine größere Anzahl an Passworten kann bei automatischen Anmeldeversuchen mit
Worten aus einem Wörterbuch, einer dictionary attack, ausprobiert werden. Diesem
Vorgehen kann leicht durch eine Beschränkung der misslungenen Anmeldeversuche
Einhalt geboten werden. Durch Netzwerkfilter, so genannte Sniffer, kann der
Netzwerkverkehr eingesehen werden, um im Klartext geschickte Zugangsdaten zu
erfahren. Eine nicht technische Variante an Passworte heranzukommen ist das social
hacking, bei dem z.B. ein Benutzer von einem Angreifer angerufen wird, der sich als
Administrator ausgibt und behauptet, dass er aufgrund von Wartungsarbeiten das
Benutzer-Passwort wissen müsse. Ein ungeschulter und leichtgläubiger Anwender wird
vielleicht die Information preisgeben. Eine verstärkte Form des social hacking ist das
social engineering, bei dem enger persönlicher Kontakt, z.B. durch Liebesaffären, zu
Benutzern hergestellt wird, um an Zugangsdaten zu kommen. [W8] Eine andere technische
Methode ist die Imitation eines legitimen Services oder einer Webseite, zu der Anfragen an
das eigentliche Service durch geäderte DNS-Einträge umgeleitet werden. Diese Imitation
wird als spoofing bezeichnet. Auf ähnliche Weise kann eine Verbindung auch nach der
legitimen Authentifizierung des Benutzers von böswilligen Programmen übernommen
werden, um Zugang zu einem System zu erlangen. Dabei wird abgewartet, bis sich ein
Benutzer bei einem System authentifiziert hat, um anschließend bei einer Umleitung der
Verbindung den angemeldeten Client zu imitieren und so Zugriff auf seinen Datenbestand
zu erhalten. Eine Gefahr für Systeme, die ein permanentes oder semipermanentes Login
auf Zeit gewähren, ist die Nachahmung von Cookies, die dem System eine legitime
Anmeldung vorspiegeln. Den meisten dieser Angriffe kann durch die Wahl von ,,starken"
Passworten und deren sichere Aufbewahrung begegnet werden. Die sozialen Attacken
finden außerhalb der technischen Sicherungsmöglichkeiten statt und können nur durch das
Sicherheitsbewusstsein der Benutzer unterbunden werden. In jedem Fall stellt neben der
__________________________________________________________________________________________________
-21-
Sicherheit der Systeme auch der Endbenutzer ein Gefahrenpotential für die
Kompromittierung von Systemen dar, das nur durch Aufklärung und Schulung aller
Betroffenen verringert werden kann.
Eine der Schlüsselfaktoren der Sicherheit eines Systems ist die Qualität der Software. Bugs
auf einem System können zu Systemzuständen führen, die es Hackern ermöglichen, ihren
eigenen Code auf der Maschine auszuführen, auf Ressourcen mit erhöhten Berechtigungen
zuzugreifen, oder die Performance des Systems herabzusetzen, beziehungsweise die
Erreichbarkeit zu unterbinden. Ein Beispiel für eine derartige Attacke ist der Code Red
Wurm, der durch einen Bug in der Index Server API auf Maschinen einen beliebigen Code
ausführen konnte um von dort aus nach weiteren verwundbaren Systemen zu suchen.
Bei Zugriffen auf Datenbanken über SQL, die Inputwerte direkt in den Querystring
schreiben, können nicht beabsichtige Folgen durch die Eingabe von ungeeigneten
Zeichenketten auftreten. So könnte ein SQL Querystring der Form
sqlQuery = "SELECT * FROM Users WHERE (Username='" & UsernameInput & "')
durch die Eingabe eines Usernamens wie
Bob') or not (Username='
zu einer Ausgabe aller Einträge der entsprechenden Tabelle führen. Solche Attacken
werden als SQL Insertion bezeichnet
Denial of Service Angriffe, kurz DOD, versuchen in erster Linie nicht Daten in einem
System zu lesen oder zu manipulieren, sondern die Erreichbarkeit des Systems durch eine
extrem hohe Anzahl von Anfragen zu reduzieren. Diese Angriffe können auch von sehr
vielen verschiedenen Systemen kommen, was eine Einschränkung der böswilligen IP-
Adressen sehr schwer macht. So eine Attacke wird distributed denial of service genannt
und wurde unter anderem von Code Red auf die Webseite des amerikanischen Weißen
Hauses durchgeführt. DOD Angriffe können auf verschiedenen Netzwerkschichten und
Protokollen durchgeführt werden und sind sehr schwer einzudämmen. Neben Ping und
SyncRequest Attacken können auch zu viele SOAP Anfragen, die eine gewisse Zeit der
Verarbeitung, wie z.B. den Zugriff auf eine Datenbank auf dem Host erfordern, ein Service
für reguläre Anfragen unerreichbar machen. Gewisse Querreferenzen für die Überprüfung
von Schlüsseln einer asymmetrischen Verschlüsselungsmethode können ein Web Service
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2003
- ISBN (eBook)
- 9783832476229
- ISBN (Paperback)
- 9783838676227
- Dateigröße
- 1.2 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Fachhochschule Technikum Wien – unbekannt
- Erscheinungsdatum
- 2014 (April)
- Note
- 1,0
- Schlagworte
- soap xml-encryption xml-signature wsdk authentifizierung
