title - Ruhr-Universität Bochum

XML- und WebserviceSicherheit
1. Das World Wide Web
1.1 Einführung
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Gliederung
1.
2.
3.
Geschichte des WWW
Zahlen zum WWW
Überblick WWW
1.
2.
3.
4.
4.
Architektur
Der Browser
Der Server
URLs
Cookies
Literatur:
A. S. Tanenbaum, Computer Networks, 4th. Ed., Pearson Education Int.,
2003
W. Dehnhardt, Scriptsprachen für dynamische Webauftritte, Hanser-Verlag,
2001
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Geschichte des WWW
Links
http://www.w3.org/History.html
http://spot.fho-emden.de/alge/museum/
1945
Vannevar Bush writes an article in Atlantic Monthly about a photoelectrical-mechanical device called a Memex, for memory extension,
which could make and follow links between documents on microfiche
1960s
Doug Engelbart prototypes an "oNLine System" (NLS) which does
hypertext browsing editing, email, and so on. He invents the mouse
for this purpose.
Ted Nelson coins the word Hypertext in A File Structure for the
Complex, the Changing, and the Indeterminate. 20th National
Conference, New York, Association for Computing Machinery, 1965.
Andy van Dam and others build the Hypertext Editing System and
FRESS in 1967.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Geschichte des WWW
1980
While consulting for CERN June-December of 1980, Tim Berners-Lee
writes a notebook program, "Enquire-Within-Upon-Everything", which
allows links to be made between arbitrary nodes. Each node had a
title, a type, and a list of bidirectional typed links. "ENQUIRE" ran on
Norsk Data machines under SINTRAN-III.
1989
March: "Information Management: A Proposal" written by Tim BL and
circulated for comments at CERN (TBL). Paper "HyperText and
CERN" produced as background.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Geschichte des WWW
1990
October: Tim BernersLee: Hypertext GUI
Browser+Editor mit der
NeXTStepEntwicklungsumgebung.
"World Wide Web" als
Name des Projekts.
November: Erster
Webserver:
nxoc01.cern.ch, später
info.cern.ch genannt.
Erste Webseite:
http://nxoc01.cern.ch/hyp
ertext/WWW/TheProject.
html
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Geschichte des WWW
1991

12. Juni: CERN-Computerseminar zu WWW

Dezember: Präsentation auf der Hypertext'91 in
San Antonio, Texas (US).
1992

Snapshot des WWW-Projekts vom 3.11.1992
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Geschichte des WWW
1993
Februar: NCSA veröffentlicht
Marc Andreessen's "Mosaic
for X".
März: WWW (Port 80 HTTP)
Verkehr: 0.1% auf dem
NSF-Backbone
30. April: Deklaration durch
CERN-Direktoren, dass die
WWW-Technologie frei
verfügbar ist.
September: WWW-Verkehr
1% auf dem NSF-Backbone.
Mosaic für alle Plattformen: X, PC/Windows und Macintosh.
Oktober: 200 bekannte HTTP-Servers. EU-Projekt WISE.
December: Bericht über WWW und Mosaic in "The New York
Times" (US) und "The Economist" (UK). "The Guardian" (UK)
publiziert eine Seite im WWW.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Geschichte des WWW
1994
März:: Marc Andreessen verläßt NCSA, um die "Mosaic
Communications Corp" (später Netscape) zu gründen.
25.-27.Mai: Erste Internationale WWW-Konferenz, CERN, Genf (800
Anmeldungen, nur 400 Teilnehmer zugelassen
Juni: Über 1500 registrierte Server. Last auf dem ersten Webserver
(info.cern.ch) 1000 mal größer als vor 3 Jahren.
1. Oktober: World Wide Web Consortium gegründet.
October: Zweite Internationale WWW-Konferenz : "Mosaic and the
Web", Chicago.
16 December: CERN beschließt, den LHC (Large Hadron Collider) zu
bauen, und gibt daher die Weiterentwicklung des WWW an INRIA
(Institut National pour la Recherche en Informatique et Automatique,
FR) ab
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. Statistik des WWW
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. Statistik des WWW
Total Sites Across All Domains August 1995 - April 2005
Quelle: http://news.netcraft.com/archives/web_server_survey.html
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. Statistik des WWW
Market Share for Top Servers Across All Domains August 1995 - April 2005
Quelle: http://news.netcraft.com/archives/web_server_survey.html
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3.1 Architektur des WWW

Client-Server-Architektur
Statische Webseiten:
HTTP-Anfrage (mit URL)
Browser
HTTP-Anwort (Header+Datei)
WebServer
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Dateisystem:
*.html
3.2 Der Client (Browser)

Client (Browser) ist für die Darstellung verantwortlich

Das gleiche *.html-Dokument kann auf verschiedenen Browsern
unterschiedlich aussehen.
Darstellung verschiedener Dateitypen durch Browser, Plug-In oder
Helper

Server sendet im HTTP-Header den MIME-Typ der Datei, die übertragen
wird
Anhand dieses MIME-Typs kann der Browser entscheiden, wie die Datei
dargestellt werden soll:

text/plain, text/html: Browser
image/jpeg, video/mpeg: Plug-In. Plug-Ins laufen innerhalb des Browsers ab,
und haben daher Zugriff auf das aktuelle Fenster. Sie werden nur bei Bedarf
geladen.
application/pdf, application/msword: Helper-Anwendung. Sie laufen außerhalb
des Browsers ab.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3.2 Der Client (Browser)
Kommunikation aus Sicht des Browsers
1.
2.
3.
User tippt http://www.nds.rub.de/schwenk/index.html
Browser sucht auf einem Domain Name Server (DNS) die IP-Adresse
zu www.nds.rub.de: 134.147.101.34
Browser baut eine TCP-Verbindung zu 134.147.101.34 Port 80 auf
4.
Browser sendet ein http-Kommando über diese TCP-Verbindung:
Get schwenk/index.html HTTP/1.0
User-agent: Netscape 4.7
Accept: text/plain
Accept: text/html
Accept: image/gif
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3.2 Der Client (Browser)
5.
Server antwortet über die TCP-Verbindung mit:

Einer Statuszeile (Erfolgsmeldung oder Fehler)
Metainfomation (Beschreibung der nachfolgenden Information)
Einer Leerzeile
Der Information selbst
HTTP/1.0 Status 200 Document follows
Server: Apache/1.8
Date: Mon, 14 Mai, 2001 11:23:22 GMT
Content-type: text/html
Content-length: 5280
Last-modified: Fri, 11 Mai, 2001 03:12:12 GMT
<html>
...
</html>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3.2 Der Client (Browser)
Schritt 1-5 wird für jede HTTP-Anfrage wiederholt.
Insbesondere muß für jede HTTP-Anfrage eine neue TCP-Verbindung
aufgebaut werden
Verbesserte Performance durch Persistenz der TCP-Verbindung in
HTTP 1.1
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3.2 Der Client (Browser)
Konkretes Beispiel für www.jpc.de
Einstellungen des Client ->
Weiter mit ethereal und der
Datei „jpc.de“
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3.3 Der Server

Arbeitszyklus eines Webservers für statische Webseiten:
1.
2.
3.
4.
5.
6.

Warte auf eine TCP-Verbindung auf Port 80
Akzeptiere eine TCP-Verbindung auf diesem Port
Empfange den Namen des gewünschten Files (z.B. index.htm)
Hole das File (von der Festplatte)
Sende das File zum Client
Beende die TCP-Verbindung
Problem: Performance

Festplattenzugriffe limitieren die Performance am stärksten
Lösung 1: Interner Cache
Lösung 2 : Multithreading
Lösung 3: Server-Farm mit Frontend
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3.3 Der Server
Arbeitszyklus eines modernen Webservers für statische Webseiten:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Warte auf eine TCP-Verbindung auf Port 80
Akzeptiere eine TCP-Verbindung auf diesem Port
Empfange den Namen des gewünschten Files
Löse den Namen des Files auf (z.B. www.nds.rub.de zu
wwwroot/nds/index.html)
Authentisiere den Client (Username/Password für BASIC)
Überprüfe die Zugriffsrechte dieses Nutzers
Überprüfe die Zugriffsbedingungen für das gewünschte File
Ist das File im Cache? Wenn nicht, hole es von der Festplatte
Bestimme den MIME-Typ des Files und füge ihn in den HTTP-Header ein
Sonstiges (z.B. Nutzerprofil/Statistiken erstellen)
Sende das File zum Client
Mache einen Eintrag ins Logfile
Beende die TCP-Verbindung
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3.4 Uniform Ressource Locators (URLs)

URLs bestehen aus drei Teilen

Protokoll (z.B. http, ftp, telnet, mailto, ...)
DNS-Name des Servers (z.B. www.nds.rub.de)
Filename (z.B. /lehre/vorlesungen/xml/index.html)
Beispiele:

http://www.nds.rub.de/schwenk/index.html
ftp://ftp.daco.org/scripte/vorlesung.pdf
file:///C|/FTP/Java_Tutorial/book.html
mailto:[email protected]
telnet://www.w3.org:80
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Cookies
HTTP ist ein verbindungsloses Protokoll

Verschiedene WWW-Anfragen vom gleichen Client stehen für den
Server in keinem Zusammenhang
Perfekt geeignet für das ursprüngliche Hypertext-Internet
Problematisch für Webshops: Wie merke ich mir, welche Produkte der
Kunde beim letzten Besuch in seinen Einkaufswagen gelegt hat?
Lösungsansätze:

HTML-Lösung 1: Versteckte vordefinierte Formularfelder (vgl. HTMLKapitel)
HTML-Lösung 2: Dynamisch generierte HTML-Seiten mit Hyperlinks, die
Session-IDs enthalten
Netscape-Lösung: Cookies
(http://wp.netscape.com/newsref/std/cookie_spec.html)
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Cookies
1.
Ein Kunde besucht mit seinem Netscape-Browser (andere Browser verhalten
sich analog) die Seite www.example.com/shop/start.html
2.
Der Server fügt in seine Antwort eine weitere Kopfzeile der Form
Set-Cookie: name=value [;EXPIRES=dateValue] [;DOMAIN=domainName]
[;PATH=pathName] [;SECURE]
HTTP/1.0 Status 200 Document follows
Date: Fri, 29 Apr, 2005 11:23:22 GMT
Content-type: text/html
Content-length: 5280
Last-modified: Fri, 11 Mai, 2001 03:12:12 GMT
Set-Cookie: SessionID=7762342; expires=Mon, 02-May-2005 23:59:59
GMT; path=/shop
<html>
...
</html>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Cookies
Die Parameter in der Set-Cookie-Zeile haben folgende Bedeutung (optionale
Parameter in eckigen Klammern):

name=value: Hier steht die eigentliche Information, die vom Betreiber des
Webservers ausgewertet wird. Nur dieses Wertepaar wird an den Server
zurückgeschickt. In unserem Beispiel wird eine Session-ID gesendet, die in einer
Datenbank mit dem Warenkorb des Besuchers verknüpft werden kann
(SessionID=7762342).

[;EXPIRES=dateValue]: Das Cookie bleibt längstens bis zum angegeben Datum
gültig und kann danach vom Browser gelöscht werden (expires=Mon, 02May-2005 23:59:59 GMT). Ist kein Datum angegeben, so wird das Cookie
beim Schließen des Browserprogramms gelöscht.
[;DOMAIN=domainName]: Cookies werden nur an den Server zurückgeschickt,
der sie auch gesetzt hat. Als Kriterium dient hier der Domainname; ist dieser
Wert nicht angegeben, so wird der Domainname des Servers genommen, der
das Cookie gesetzt hat (in unserem Beispiel also DOMAIN=www.example.com).
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Cookies
Die Parameter in der Set-Cookie-Zeile haben folgende Bedeutung (optionale
Parameter in eckigen Klammern):

[;PATH=pathName]: Manche Cookies sind nicht für den ganzen Webserver
interessant, sondern nur für Teilfunktionen. In unserem Beispiel ist die der
Webshop, der unter dem Pfad path=/shop zu finden ist. Nur wenn eine Seite
des Webshops aufgerufen wird, muss das Cookie mit übertragen werden.

[;SECURE]: Ist dieser Parameter in der Set-Cookie-Zeile enthalten, so bedeutet
dies, dass das Cookie nur über eine sichere Verbindung zurückgeschickt werden
darf, also nur, wenn SSL-Verschlüsselung eingeschaltet ist.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Cookies
3.
Ruft der Kunde nun eine weitere Seite des Webshops auf, z.B.
www.example.com/shop/books.html, so wird das Cookie im GET-Reqest mit
übertragen:
Get shop/books.html HTTP/1.0
User-agent: Netscape 4.7
Accept: text/plain
Accept: text/html
Accept: image/gif
Cookie: SessionID=7762342
Mit Hilfe dieses Wertes kann der Shop-Betreiber in seiner Datenbank
nachsehen, welche Produkte der Kunde in den Warenkorb gelegt oder auch nur
angeschaut hat.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Cookies: Weitere Beispiele
Domain
Path Content
joes-store.com /
Cart=1-00501;2-13721
Expires
Secure
15-10-02 17:00
No
Cart=1-00501;2-13721 Die Variable Cart enthält hier den Inhalt des
Einkaufswagens, in Form von eindeutigen
Produktnummern. Diese Liste wird also im Browser
gespeichert, was den Server entlastet. Genug Platz
ist dafür da, da ein Cookie bis zu 4 KB groß werden
darf.
No
Browser darf das Cookie an jeden Server
zurücksenden
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Cookies: Weitere Beispiele
Domain
Path Content
aportal.com /
Prefs=Stk:SUNW;Spt:1860M
Expires
Secure
15-10-02 17:00 No
Prefs=Stk:SUNW;Spt:Jets Die Variable Prefs speichert die
Präferenzen eines Kunden für ein bestimmtes
Internet-Portal. Mit der genannten Festlegung werden
dem Kunden immer die Börsenwerte der Firma SUN
und die Ergebnisse der Fußballspiele von 1860
München angezeigt.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Cookies: Weitere Beispiele
Domain
Path Content
sneaky.com /
UserID=8934982374
Expires
Secure
31-12-10 23:59 No
UserID=8934982374 Die Variable UserID wird von der Firma Sneaky
dazu verwendet, Daten über den Kunden zu
sammeln. Dies kann z.B. dadurch geschehen, dass
ein Werbebanner (.doubleclick.net) auf vielen Seiten
im Internet platziert wird. Dieses Werbebanner muss
jeweils von einem Server aus der Domain
sneaky.com abgerufen werden, und so wird das
Cookie regelmäßig an die Firma gesendet. Diese
kann sehen, von welcher Webseite aus das Banner
aufgerufen wurde, und so ein Nutzerprofil erstellen.
(Im Extremfall reicht dazu eine Banner, das 1*1 Pixel
groß ist!)
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML- und WebserviceSicherheit
1. Das World Wide Web
1.2 Grundzüge von HTML und XML
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Gliederung
1.
2.
3.
4.
5.
6.
HTML-Versionen
Struktur eines HTML-Dokuments
Die wichtigsten Tags
Formulare
XML und XSL
XHTML
Literatur:
A. S. Tanenbaum, Computer Networks, 4th. Ed., Pearson Education Int.,
2003
W. Dehnhardt, Scriptsprachen für dynamische Webauftritte, Hanser-Verlag,
2001
Selfhtml 8.0, http://selfhtml.teamone.de/
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. HTML-Versionen

Übersicht zu dem HTML-Features (aus A. Tanenbaum, Computer Networks):
Was ist vorhanden?
HTML 1.0
HTML 2.0
HTML 3.0
HTML 4.0
Hyperlinks
X
X
X
X
Bilder/Grafiken
X
X
X
X
Listen
X
X
X
X
Aktive Karten und Bilder
X
X
X
„Forms“
X
X
X
Gleichungen
X
X
Toolbars
X
X
Tabellen
X
X
Accessibility features
X
Objekteinbettung
X
Scripting
X
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. HTML-Versionen

HTML 1.0

HTML 2.0

Ab Januar 1997 Standard
Viele Bestandteile sind als „deprecated“ gebrandmarkt
HTML 4.0

Ab 1995 offizieller Standard
Kleinster gemeinsamer Nenner, den alle Browser verstehen
Netscape war bei Verabschiedung schon viel weiter (Frames, Multimedia)
HTML 3.2

Spezifikation ist heute von w3.org nicht mehr verfügbar
CSS
Javascript
Unicode für Internationalisierung
XHTML 1.0 und 1.1

Einbindung in XML
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. Struktur eines HTML-Dokuments

(aus SELFHTML 8.0, selfhtml.teamone.de):
Eine gewöhnliche HTML-Datei besteht grundsätzlich aus folgenden Teilen:

Dokumenttyp-Angabe (Angabe zur verwendeten HTML-Version)
Header (Kopfdaten. z.B. Angaben zu Titel u.ä.)
Body (Körper - anzuzeigender Inhalt, also Text mit Überschriften, Verweisen,
Grafikreferenzen usw.)
Schema:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/transitional.dtd">
<html>
<head>
<title>Text des Titels</title>
</head>
<body>
....
</body>
</html>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. Struktur eines HTML-Dokuments

HTML ist eine Markup-Sprache, ähnlich wie TEX
Formatierungskommandos heißen Tags

Tags können Attribute haben

Beispiel: <img src="http://www.widget.com/images/logo.gif"
ALT="AWI Logo">
Sonderzeichen werden durch &zeichenfolge; dargestellt:

Struktur <etwas> text </etwas> oder <etwas blablabla>
Beispiel: <b> fett </b> ergibt „fett“
Ö
&
é
&Ouml;
&amp;
&eacute;
Tags können auch verschachtelt werden

Beispiel: <a href=„http://www.nasa.gov“> <img src=„shuttle.gif“ alt=„NASA“>
</a>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. Struktur eines HTML-Dokuments
<html>
<head> <title> AMALGAMATED WIDGET, INC. </title> </head>
<body> <h1> Welcome to AWI's Home Page </h1>
<img src="http://www.widget.com/images/logo.gif" ALT="AWI Logo"> <br>
We are so happy that you have chosen to visit <b> Amalgamated Widget's</b>
home page. We hope <i> you </i> will find all the information you need here.
<p>Below we have links to information about our many fine products.
You can order electronically (by WWW), by telephone, or by fax. </p>
<hr>
<h2> Product information </h2>
<ul>
<li> <a href="http://widget.com/products/big"> Big widgets </a>
<li> <a href="http://widget.com/products/little"> Little widgets </a>
</ul>
<h2> Telephone numbers </h2>
<ul>
<li> By telephone: 1-800-WIDGETS
<li> By fax: 1-415-765-4321
</ul>
</body>
</html>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. Struktur eines HTML-Dokuments
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. Struktur eines HTML-Dokuments
Frames
Frames können zur Strukturierung von Webseiten verwendet werden
Ähnliches Aussehen kann auch mit Tabellen erzeugt werden, aber

Jeder Frame enthält eigenes HTML-Dokument
Wird der Inhalt eines Frames geändert, muss nur dieses Dokument geladen
werden (bei Tabellen die ganze Tabelle)
Wegen „Framespoofing“-Angriff müssen alle Frames aus einer Domain bzw.
von einem Server stammen
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. Struktur eines HTML-Dokuments (nds.rub.de)
<html>
<head>...</head>
<frameset cols="240,*" framespacing="0" border="0" frameborder="0">
<frame name="Inhalt" scrolling="no" noresize target="Hauptframe"
src="indexl.html">
<frameset rows="100,*">
<frame name="Banner" scrolling="no" target="Hauptframe"
src="indexo.html">
<frame name="Hauptframe" src="indexm.html" scrolling="auto"
target="_top">
<noframes>
<body>
<p>Diese Seite verwendet Frames.</p>
</body>
</noframes>
</frameset>
</frameset>
</html>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. Struktur eines HTML-Dokuments (nds.rub.de):
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. Wichtige Tags
<html>
Umklammert die gesamte, in HTML geschriebene Webseite
<head>
Der Seitenheader
<body>
Der Hauptteil der HTML-Seite; wird im Fenster angezeigt
<title>
Titel der Seite im HEAD-Teil; wird nicht im Fenster angezeigt
<h[1-6]>
Überschriften der Stufen 1 bis 6
<b>
fett
<i>
kursiv
<center>
zentriert
<ul>
• ungeordnete Liste
<ol>
1. geordnete Liste
<li>
Ein Element einer (un-)geordneten Liste
<br>
Zeilenumbruch
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. Wichtige Tags
<p>
Neuer Absatz
<hr>
Horizontale Linie
<img src=„…“>
Einfügen eines Bildes
<a href=„…“> Text </a>
Hyperlink
<table>
Tabelle
<tr>
Tabellenzeile („table row“)
<th>, <td>
Zellen der Tabelle („table header, table data“)
<form action=„…“ method=„…“>
Formular
<input name=„…“
type=text|password|radio|checkbox|
button|file|submit value=„…“>
Eingabefeld, kann verschiedene Typen haben
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. Wichtige Tags
Cascading Style Sheets
HTML ist keine Designsprache, sondern eine Struktursprache
Um das Aussehen einer Webseite genau bestimmen zu können,
wurde HTML um Cascading Style Sheets erweitert
CSS gibt es in den Versionen 1 und 2
Mit CSS kann man das Aussehen der einzelnen HTML-Tags genau
festlegen.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. Wichtige Tags
<html>
<head>
<title>Titel der Datei</title>
<style type="text/css">
<!-body { background-color:#FFFFCC; margin-left:100px; }
h1 { font-size:48pt; color:#FF0000; font-style:italic;
border- bottom:solid thin black; }
p,li { font-size:12pt; line-height:14pt;
font-family:Helvetica,Arial,sans-serif;
letter-spacing:0.2mm; word-spacing:0.8mm; color:blue; }
-->
</style>
</head>
<body>
<h1>&Uuml;berschrift 1. Ordnung</h1>
<p>ein normaler Textabsatz</p>
<ul>
<li>Ein Listenpunkt</li>
<li>Ein anderer Listenpunkt</li>
</ul>
</body>
</html>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. Wichtige Tags
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Formulare

Eingeführt in HTML 2.0
Zur Interaktion des WWW-Nutzers mit dem Server
<form>… </form>
umschließt mehrere Eingabefelder und mindestens einen
„Submit“-Button
Einzeiliger Text, mehrzeiliger Text, Radio Buttons, Checkboxes,
Auswahllisten, Datei-Upload
Enthält als Attribute
die Ziel-URL, an die die Daten übergeben werden (meist …/cgibin/…, …php oder …asp)
Die Methode, mit der die Daten übergeben werden (POST oder
GET)
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Formulare (aus A. Tanenbaum)
<html>
<head> <title> AWI CUSTOMER ORDERING FORM </title> </head>
<body>
<h1> Widget Order Form </h1>
<form ACTION="http://widget.com/cgi-bin/widgetorder" method=POST>
<p> Name <input name="customer" size=46> </p>
<p> Street Address <input name="address" size=40> </p>
<p> City <input name="city" size=20> State <input name="state" size =4>
Country <input name="country" size=10> </p>
<p> Credit card # <input name="cardno" size=10>
Expires <input name="expires" size=4>
M/C <input name="cc" type=radio value="mastercard">
VISA <input name="cc" type=radio value="visacard"> </p>
<p> Widget size Big <input name="product" type=radio value="expensive">
Little <input name="product" type=radio value="cheap">
Ship by express courier <input name="express" type=checkbox> </p>
<p><input type=submit value="submit order"> </p>
Thank you for ordering an AWI widget, the best widget money can buy!
</form>
</body>
</html>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Formulare (aus A. Tanenbaum)
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Formulare

GET-Methode

Eingaben werden als Query-String an die URL angehängt
Beispiel (Google): GET /search?q=diploma+supplement&ie=ISO-88591&hl=de&btnG=Google+Suche&meta=cr%3DcountryDEPOST-Methode
Vorteil: Anfrage kann als Bookmark gespeichert werden
Problem: Bei Eingabe von Username/Passwort ist das Passwort in der
History des Browsers sichtbar
POST-Methode

Eingaben werden als lange Zeile an den Server übertragen
Beispiel (zu Tanenbaum):
customer=Joerg+Schwenk&address=Universitaetsstr+150&city=Bochum&
state=NRW&country=DE&cardno=1234567890&expires=7/07&
cc=mastercard&product=cheap&express=on
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Formulare
Datei-Upload (aus Dehnhard):
<form Method=POST Enctype=multipart/form-data
Action=/CGI/Perl/anwendungen/Checkhtml.pl>
<input Type=file Name=datei Size=40 Maxlength=100000>
<p>
<input Type=submit Value=„Upload!“>
</form>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
5. XML und XSL
Was ist XML?
http://www.w3.org/XML/1999/XML-in-10-points
1.
XML ist eine Methode, um strukturierte Daten in Textfiles (statt in
Binärfiles) abzulegen.

2.
Beispiel: Tabellenkalkulationen
XML sieht aus wie HTML, ist aber kein HTML

3.
HTML hat Tags mit fester Bedeutung (z.B. muss <p> nicht „paragraph“
bedeuten. Bei XML wird die Bedeutung der Tags durch eine
Beschreibung festgelegt.
XML ist Text, der aber nicht gelesen werden soll.

Textformat dient nur zum leichteren Debuggen und Reparieren von
Datenfiles.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
5. XML und XSL
4.
XML ist eine Familie von Technologien.

5.
XML-Files sind größer als Binärfiles, aber das ist kein Problem.

6.
Datenkompression von gespeicherten Files (z.B. WinZip) oder beu
Übertragung löst das Problem.
XML ist neu, aber nicht ganz neu.

10.
XML 1.0, Xlink (Hyperlinks), XSL (Style Sheets), XMLDSIG, ...
XML ist mächtiger als HTML (1990) und leichter zu bedienen als SGML
(ISO 1986).
XML ist lizenzfrei, Plattform-unabhängig und gut unterstützt.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML-Beispiel
<?xml version="1.0" standalone="yes"?>
<conversation>
<greeting>Hello, world!</greeting>
<response>
Stop the planet, I want to get off!
</response>
</conversation>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML-Beispiel (2) - Baumstruktur
<?xml version="1.0" standalone="yes"?>
<conversation>...</conversation>
<greeting>...</greeting>
Hello, world!
<response>...</response>
Stop the planet, I want to get off!
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML-Webseite (aus A. Tanenebaum)
<?xml version="1.0" ?>
<?xml-stylesheet type="text/xsl" href="book_list.xsl"?>
<book_list>
<book>
<title> Computer Networks, 4/e </title>
<author> Andrew S. Tanenbaum </author>
<year> 2003 </year>
</book>
<book>
<title> Modern Operating Systems, 2/e </title>
<author> Andrew S. Tanenbaum </author>
<year> 2001 </year>
</book>
<book>
<title> Structured Computer Organization, 4/e </title>
<author> Andrew S. Tanenbaum </author>
<year> 1999 </year>
</book>
</book_list>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML-Webseite (aus A. Tanenebaum)
<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="/">
<html>
<body>
<table border="2">
<tr>
<th> Title</th>
<th> Author</th>
<th> Year </th>
</tr>
<xsl:for-each select="book_list/book">
<tr>
<td> <xsl:value-of select="title"/> </td>
<td> <xsl:value-of select="author"/> </td>
<td> <xsl:value-of select="year"/> </td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML-Webseite (aus A. Tanenebaum)
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML-Signature Syntax and Processing
http://www.w3.org/2000/02/xmldsig
Gemeinsame Arbeitsgruppe von W3C und IETF
Dokument beschreibt:
Syntax einer digitalen Signatur in XML
Verarbeitung einer digitalen Signatur in XML
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML-Signature Syntax and Processing
Drei Typen von Signaturen:
Dokument
Enveloping Signature
Enveloped Signature
Signatur
Dokument
Content
Content
Signatur
Detached Signature
Dokument
Signatur mit
Referenz-URI
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Dokument
(ReferenzURI)
Content
XMLDSIG - Beispiel
<Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/02/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n20000119"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/02/xmldsig#dsa"/>
<Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126"/>
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/02/xmldsig#c14n"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/02/xmldsig#sha1"/>
<DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue><P>...</P><Q>...</Q><G>...</G><Y>...</Y></DSAKeyValue>
</KeyValue>
</KeyInfo>
Jörg Schwenk
</Signature>
Lehrstuhl für Netz- und Datensicherheit
XML Encryption
http://www.w3.org/Encryption/2001/
Ziel: Einbindung verschlüsselter Dateien und der dazu
gehörenden Schlüsselinformation in XML
Features:
Klare Trennung zwischen verschlüsselten Schlüsseln und Daten
(Warum?).
Kompatibilität mit dem XML Signature Standard.
Einschränkungen bei der Schachtelung von verschlüsselten Files,
die sich aus dem XML-Standard ergeben.
xmlns:enc='http://www.w3.org/2001/04/xmlenc#'
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML Encryption (5)
EncryptedData-Objekt:
<EncryptedData (Id='')? (Type='')?>
<EncryptionMethod/>?
<ds:KeyInfo>
<EncryptedKey/>?
<ds:*/>?
</ds:KeyInfo>?
<CipherData>
<CipherValue>(encrypted character data)</CipherValue>?
<CipherReference URI=''/>?
</CipherData>
</EncryptedData>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML Encryption – Beispiel
Übertragung einer Kreditkartennummer
<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<CreditCard Limit='5,000' Currency='USD'>
<Number>4019 2445 0277 5567</Number>
<Issuer>Bank of the Internet</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML Encryption – Beispiel (2)
Verschlüsselung des CreditCard-Elements
<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<EncryptedData
Type='http://www.w3.org/2001/04/xmlenc#Element'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</PaymentInfo>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML Encryption – Beispiel (3)
Kredit-Limit bleibt unverschlüsselt
<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<CreditCard Limit='5,000' Currency='USD'>
<EncryptedData
Type='http://www.w3.org/2001/04/xmlenc#Content'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</CreditCard>
</PaymentInfo>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML Encryption – Beispiel (4)
Nur die Kreditkarten-Nummer wird verschlüsselt
<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<CreditCard Limit='5,000' Currency='USD'>
<Number>
<EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Content'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</Number>
<Issuer>Bank of the Internet</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML- und WebserviceSicherheit
1. Das World Wide Web
1.3 Das Hypertext Transfer Protocol
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Gliederung
Gliederung
1.
2.
3.
4.
5.
6.
HTTP 1.0 vs. 1.1
Verbindungen
HTTP-Methoden
Header
Ein Beispiel
Performance
Literatur:
A. S. Tanenbaum, Computer Networks, 4th. Ed., Pearson Education Int.,
2003
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. HTTP 1.0 vs. 1.1

Erste Version (HTTP 0.9) holte nur „Raw data“ vom Server
Zweite Version HTTP 1.0

RFC 1945 (Mai 1996)
MIME-ähnliche Beschreibung der Inhalte
Metadaten, Modifier
Probleme mit Version 1.0

hierarchische Proxies
Caching
Persistente Verbindungen
Virtuelle Hosts
Fehlerhafte Implementierungen von HTTP 1.0
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. HTTP 1.0 vs. 1.1

Erweiterungen in HTTP 1.1

Persistenz ist Default-Wert
Multi-Homed Web Server:

Ältere HTTP 1.0-Implemetierungen nehmen an, es gäbe eine 1-zu-1
Zuordnung zwischen DNS-Hostname und IP-Adresse
Da dies heute nicht mehr so ist, MUSS ein HTTP/1.1-Client den hostRequest-Header mit senden, der den DNS-Namen noch einmal angibt.

Unterstützung absoluter URI (für Proxies). Beispiel:
http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

Request-URI (Beispiel):
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. Verbindungen

HTTP 1.0

Für jede GET-Anfrage wurde eine TCP-Verbindung aufgebaut, und
nach Erhalt der Datei wieder abgebaut (auch für eingefügte Bilder!)
Kosten: 2,5 RTT (5 Nachrichten), ggf. noch Wartezeit für Timeout,
Netwerküberlastung, und CPU-Zeit bei Client, Server und Proxies
Implementierung persistenter Verbindungen mit dem Keep-AliveHeaderfeld waren fehlerhaft
HTTP 1.1: Persistente Verbindungen

Spart o.g. Kosten
Pipelining von HTTP-Requests wird möglich
Versteht ein Server ein neues Feature nicht, so kann er eine
Fehlermeldung zurück senden (anstatt die TCP-Verbindung zu
beenden)
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. Verbindungen

HTTP 1.1: Persistente Verbindungen

Sind jetzt Default-Wert!
Abbau einer TCP-Verbindung muss mit dem connection-Headerfeld
signalisiert werden:

connection: close
Pipelining:

Requests werden nicht nummeriert
Server muss Antworten in der Reihefolge zurücksenden, in der die
Requests eingegangen sind
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. HTTP-Methoden

„Methoden“ wurden mit Hinblick auf spätere Erweiterbarkeit
spezifiziert
Sichere Methoden

GET, HEAD sind sicher, da sie nur Daten abrufen (Buffer OverflowAngriffe ausgenommen)
POST, PUT, DELETE sind unsicher
Idempotente Methoden

Auch mehrmaliger Aufruf dieser Methoden mit der gleichen URI bewirkt
das Gleiche wie einmaliger Aufruf mit dieser URI
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. HTTP-Methoden

GET filename HTTP/1.1

HEAD filename HTTP/1.1

Nur der Header für das genannte File wird angefordert, ohne die Datei
selbst. Mit diesem Befehl kann man z.B. feststellen, wann die Datei
zuletzt verändert wurde.
OPTIONS

Veranlasst den Server, das spezifizierte File an den Client zu senden.
Bei einer Request-URI MUSS noch der host-Header mit angegeben
sein, um die Angabe eindeutig zu machen.
Ohne URI: Abfrage der Fähigkeiten des Servers
Mit URI: Abfrage der Eigenschaften der Datei
TRACE

Debugging
Anfrage wird im Body der Antwort zurückgesendet
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. HTTP-Methoden

CONNECT (reserviert für zukünftige Nutzung mit einem Proxy.)
POST Request-URI HTTP/1.1

Server soll den Body des POST-Requests an die in Request-URI
genannte Ressource „anfügen“
Beispiele für „anfügen“ sind:

Annotation von existierenden Ressourcen
Senden einer Nachricht an ein „bulletin board“, eine „newsgroup“, eine
Mailingliste, oder Ähnliches
Übergabe eines Datenblocks, z.B. einer Eingabe aus einem Formular, an
einen datenverarbeitenden Prozess
Erweiterung einer Datenbank durch eine Anfüge-Operation
Die genaue Bedeutung von „anfügen“ wird vom Server meist anhand
der Request-URI ermittelt.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. HTTP-Methoden

PUT Request-URI HTTP/1.1

DELETE Request-URI HTTP/1.1

Gegenteil von GET
Angefügte Datei wird unter der genannten URI gespeichert, alte
Version überschrieben.
Daten unter der genannten URI sollen gelöscht werden.
PUT, POST und DELETE verlangen ggf. nach einer Autorisierung
des Clients

Basic Authentication RFC 2617
Digest Authentication RFC 2617
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. HTTP-Methoden

Basic Authentication RFC 2617

Einfaches Username/Passwort-Verfahren
Pop-Up-Fenster im Browser erscheint
Passwort ist NICHT verschlüsselt, sondern nur BASE64-codiert
GET /root/secret.html HTTP/1.0
HOST: www.bank.de
HTTP/1.0 401 Authorization Required
WWW-Authenticate: Basic realm="name"
GET /root/secret.html HTTP/1.0
HOST:www.bank.de
Authorization: Basic QWRtaW46Zm9vYmFy
HTTP/1.0 200 OK
secret.html
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. HTTP-Methoden

Digest Authentication RFC 2617

Challenge(„opaque“)-and-Response(„response“)-Verfahren
„nonce“ gegen Denial-of-Service-Angriffe
GET /root/secret.html HTTP/1.0
HOST: www.bank.de
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm=“[email protected]",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
Authorization: Digest username=“Hans.Mueller",
realm="[email protected]",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri=“/root/secret.html",
response="e966c932a9242554e42c8ee200cec7f6",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
HTTP/1.0 200 OK
secret.html
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. HTTP-Methoden

Status-Codes in der Server-Antwort
Code
Bedeutung
Beispiel
1xx
Informationen; kann Header-Zeilen
enthalten, aber keinen Body
100 Continue (Server ist bereit, die Anfrage
zu bearbeiten)
2xx
Erfolg; Anfrage wurde empfangen,
verstanden und akzeptiert
200 OK (Folgezeilen sind abhängig von der
Methode; bei GET wird z.B. das gewünschte
File im Body gesendet.)
3xx
Umleitung; Anfrage kann nur erfüllt werden,
wenn der Client weitere Aktionen tätigt (der
Nutzer muss darüber aber nicht informiert
werden)
303 See Other (gesuchter Content kann
unter einer anderen URI mit GET abgefragt
werden)
4xx
Client-Fehler; der Server liefert eine
mögliche Erklärung des Fehlers
400 Bad Request; 401 Unauthorized; 403
Forbidden; 404 Not Found; 405 Method Not
Allowed; ...
5xx
Server-Fehler
500 Internal Server Error; 501 Not
Implemented; ...
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Header

HTTP-Methoden sind bewusst einfach gehalten
Zusatzinformationen werden in ergänzenden Message-Headern
übermittelt

Client → Server: Request-Header
Server → Client : Response-Header
Komplexe Syntax.

Beispiel: Präferenz 1.0 für text/html und text/x-c, Präferenz 0.8 für
text/x-dvi, und Präferenz 0.5 für text/plain (1 beste, 0 schlechteste
Präferenz)
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Header
Header
Richtung R/O
Inhalt
Accept
Request
O
Angabe über bevorzugte Datenformate
Accept: image/jpeg
Accept-Charset
Request
O
Zeichensätze, die der Browser versteht
Accept-Encoding
Request
O
Unterstützte Codierungsverfahren (gzip, compress, deflate,
identity)
Accept-Language
Request
O
Präferierte Sprachen
Accept-Language: da, en-gb;q=0.8, en;q=0.7
Authorization
Request
O/R
Wird normalerweise nach einer 401-Antwort gesendet
(dann R); siehe Beispiele zu Basic und DigestAuthentication.
From
Request
O
RFC 822 E-Mail-Adresse
Host
Request
R
Angabe des DNS-Hostnamens für multihomed Hosts
User-Agent
Request
O
Infos zum Browser und seinem OS
Cookie
Request
O
Sendet ein ggf. vorhandenes Cookie zurück zum Server
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Header
Header
Richtung R/O
Inhalt
If-Modified-Since
Request
O
Datei nur senden, wenn sie seit dem angegebenen
Zeitpunkt modifiziert wurde
Cache-Control
beide
O
Verschiedene Direktiven zur Kontrolle des Caching; wird
unter Performance besprochen.
Connection
beide
O
Aushandlung von Parametern für eine bestimmte
Verbindung; spezielle Verwendung:
Connection: close
Date
beide
R/O
Datum und Uhrzeit im RFC 1123-Format
Keep-Alive
beide
O
Wenn „Connect: Keep-Alive“ gesendet wurde, kann dieser
Header mit hinzugefügt werden. Er ist allerdings nur in RFC
2068 etwas beschrieben.
Upgrade
beide
O
Möglichkeit, eine neuere Protokollversion auszuhandeln
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Header
Header
Richtung
R/O
Inhalt
Accept-Ranges
Response
O
Der Param. „bytes“ sagt, dass Bytes angef. werden dürf.
Content-Encoding
Response
O
Verwendetes Codierungsverfahren (gzip, compress,
deflate, identity)
Content-Language
Response
O
Die Sprache, in der die Webseite abgefasst ist
Content-Length
Response
O
Die Länge der Datei in Bytes
Content-Type
Response
O
Der MIME-ähnliche Typ der Datei
Content-Location
Response
O
Redirection (Umleitung) auf eine andere URI, von der der
Content geladen werden kann.
ETag
Response
O
„Entity Tag“
Last-Modified
Response
O
Angabe, wann das Dokument zum letzten Mal verändert
wurde; wichtig für das Caching
Location
Response
O
Redirection
Server
Response
O
Informationen zum WWW-Server und seinem OS
Set-Cookie
Response
O
Setzen eines Cookies im Browser
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
5. Ein Beispiel
GET / HTTP/1.0
If-Modified-Since: Tue, 18 Mar 2003 15:37:03 GMT;
length=2322
Connection: Keep-Alive
User-Agent: Mozilla/4.77C-CCK-MCD Caldera Systems
OpenLinux [en] (X11; U; Linux 2.4.13 i686)
Host: www.nds.rub.de
Accept: image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
5. Ein Beispiel
HTTP/1.1 304 Not Modified
Date: Fri, 11 Apr 2003 07:32:19 GMT
Server: Apache
Connection: Keep-Alive
Keep-Alive: timeout=15, max=100
ETag: "33403-912-3e773d1f"
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
5. Ein Beispiel
GET / HTTP/1.1
Connection: Keep-Alive
User-Agent: Mozilla/5.0 (compatible; Konqueror/2.2.1;
Linux)
Accept: text/*, image/jpeg, image/png, image/*, */*
Accept-Encoding: x-gzip, gzip, identity
Accept-Charset: iso-8859-1, utf-8, *
Accept-Language: en, en_US
Host: www.nds.rub.de
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
5. Ein Beispiel
HTTP/1.1 200 OK
Date: Fri, 11 Apr 2003 07:33:06 GMT
Server: Apache
Last-Modified: Tue, 18 Mar 2003 15:37:03 GMT
ETag: "33403-912-3e773d1f"
Accept-Ranges: bytes
Content-Length: 2322
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
<!doctype html public "-//w3c//dtd html 4.0
transitional//en"><html> ...
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
6. Performance

Lösungen für das „World Wide Wait“:
Caching
Mehrfache Server
Content Delivery Networks
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
6. Performance
Caching

Fragen zum Caching

Hierarchisches Caching:

Wer soll cachen?
Wie lange soll eine Webseite gecachet werden?
1. Cache im Client-Host selbst (bei Netscape: Ordner „cache“ im
Filesystem)
2. Cache auf dediziertem Rechner im Client-LAN
3. Cache beim ISP
Literatur: The Internet Protocol Journal, Volume 2, Number 3
(September 1999). www.cisco.com/ipj
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
6. Performance
Caching
Cache-Proxy
beim ISP
Lokaler
Cache
Internet
Cache-Proxy im
LAN
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Internet
Eigentlicher
Webserver
6. Performance
Caching

Wie lange soll eine Webseite gecachet werden?
Beispiel: Webseite mit Börsenkurse:

Solange mit Aktien gehandelt wird, ändern sich die Kurse jede
Sekunde
Wenn die Börse geschlossen hat, kann die Seite mehrere Stunden
oder das ganze Wochenende gecachet werden.
Beispiel: Suchanfrage bei Google nach „abelschen Quasigruppen“

Sollte nicht gecachet werden, da eine zweite Anfrage mit dem gleichen
Query-String äußerst unwahrscheinlich ist.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
6. Performance
Methoden zur Ermittlung der Speicherzeit im Cache

Last-Modified-Header (Heuristik):

If-Modified-Since-Header:

Wenn das Datum der letzten Modifikation lange zurück liegt, kann man
davon ausgehen, dass die Seite noch lange unverändert bleiben wird.
Proxy leitet die Anfrage des Client, um den genannten Header
erweitert, an den Webserver weiter.
Wurde die Seite nicht modifiziert, antwortet der Server mit „304 Not
Modified“, und der Proxy entnimmt die Seite aus seinem Cache.
Wurde die Seite modifiziert, so leitet der Proxy die neue Seite des
Servers weiter und speichert sie ins einem Cache.
Kombination der beiden Verfahren ist möglich.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
6. Performance
Caching

Cache-Control-Mechanismen

15 Seiten zum Thema Caching im Allgemeinen in RFC 2616
Cache-Control mit 17 verschiedenen Direktiven
Wichtig: no-cache-Direktive für dynamisch generierte Webseiten
Header
Richtung
R/O
Inhalt
Cache-Control
Response
O
Verschiedenste Direktiven, z.B. „no-cache“
Expires
Response
O
Gibt an, wann der Inhalt spätestens „stale“, d.h. veraltet
sein wird

Proaktives Caching

Zusammen mit der Webseite werden auch alle Links von dieser
Webseite gecachet.
Beim Anklicken eines dieser Links kann der Kunde sehr viel schneller
bedient werden.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
6. Performance
Mehrfache Server

„Flash Crowds“

www.dos.state.fl.us war die unbedeutende Webseite des
Bundesstaates Florida
Im Endspurt des vorletzten US-Wahlkampf brach der Server
zusammen
Gesucht: Replizierbarkeit von WWW-Servern „on Demand“,
möglichst an verschiedenen Standorten
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
6. Performance
Content Delivery Networks

Webseiten werden gegen Bezahlung auf möglichst vielen Servern
repliziert
Marktführer: Akamai
1. Firma bezahlt das CDN dafür, dass ihre Webseite weltweit gut
verfügbar sind.
2. CDN spricht mit ISPs, um Proxy-Server in ihren Netzwerken
aufzustellen. Die Kunden der ISPs erhalten dadurch eine
verbesserte Performance.
3. Anfragen an die Webseite der Firma werden durch spezielle HTTPTechniken auf einen der Proxy-Server umgeleitet. Dazu wird die
Startseite der Firma modifiziert.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
6. Performance
Content Delivery Networks: Beispiel (aus Tanenenbaum)

Original-Webseite von Furry Video
<html>
<head><title> Furry Video </title></head>
<body>
<h1> Furry Video‘s Product List </h1>
<p> Click below for free samples </p>
<a href=„bears.mpg“> Bears Today </a>
<a href=„mice.mpg“> Nice Mice </a>
</body>
</html>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
6. Performance
Content Delivery Networks: Beispiel (aus Tanenenbaum)

Modifizierte Webseite von Furry Video
<html>
<head><title> Furry Video </title></head>
<body>
<h1> Furry Video‘s Product List </h1>
<p> Click below for free samples </p>
<a href=„http://cdn-server.com/furry/bears.mpg“> Bears Today
</a>
<a href=„http://cdn-server.com/furry/mice.mpg“> Nice Mice </a>
</body>
</html>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
6. Performance
Content Delivery Networks: Grafik (aus Tanenbaum)
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
6. Performance
Content Delivery Networks: Grafik (aus Tanenenbaum)

Problem in Schritt 8: Wohin soll cdn-server.com den Request
umleiten?

cdn-server.com muss die IP-Adresse des Clients in einer Datenbank
suchen, um zu bestimmen wo (d.h. z.B. bei welchem ISP) er sich
aufhält.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML- und WebserviceSicherheit
1. Das World Wide Web
1.4 Client- vs. Server-basierte Techniken für
dynamische Webseiten
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Gliederung
Gliederung
1. Einführung
2. Server-basierte Techniken
3. Client-basierte Techniken
Literatur:
A. S. Tanenbaum, Computer Networks, 4th. Ed., Pearson
Education Int., 2003
http://hoohoo.ncsa.uiuc.edu/cgi/overview.html
http://www.htmlhelp.com/faq/cgifaq.1.html
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Einführung dynamische Webseiten
HTTP-Anfrage
Browser
HTTP-Anwort
HTTP-Anfrage
Browser
WebServer
CGIScript
DB
Web-Server
DB
HTTP-Anwort
PHP-Modul
Browser
JavaScript
WebServer
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
CGIScript
DB
1. Einführung dynamische Webseiten

Client-seitige Techniken nutzbar für

Animationen
Überprüfung von Formulareingaben
Navigationselemente
Server-seitige Techniken werden eingesetzt für

Datenbankzugriff
Webshops (z.B. Anzeige des Inhalts eines Warenkorbs)
Dokumentenverwaltung
Suchmaschinen
Personalisierte Startseiten (myIrgendwas.de)
Dynamische Seitenelemente (z.B. Zähler)
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Einführung dynamische Webseiten

3-Tier-Model (3-Schichten-Modell)
Browser
WebServer
JavaScript
Darstellung
InterfaceSteuerung
Geschäftslogik
Anwendung
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Datenzugriff
DBSystem
Daten
1. Einführung dynamische Webseiten
<html>
<body>
<form action="action.php" method="post">
<p> Bitte geben Sie Ihren Namen ein:
<input type="text" name="name"> </p>
<p> Bitte geben Sie ihr Alter ein:
<input type="text" name="age"> </p>
<input type="submit">
</form>
</body>
</html>
name=“Barbara”
&age=“24”
<html>
<body>
<h1> Antwort: </h1>
Hallo Barbara, nächstes Jahr sind Sie 25 Jahre alt.
</body>
</html>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
<html>
<body>
<h1> Antwort: </h1>
Hallo <?php echo $name; ?>,
nächstes Jahr sind Sie
<?php echo $age + 1; ?>
Jahre alt.
</body>
</html>
1. Einführung dynamische Webseiten
<html><head><script language="javascript" type="text/javascript">
function response(test_form) {
var person = test_form.name.value;
var years = eval(test_form.age.value) + 1;
document.open();
document.writeln("<html> <body>");
document.writeln("Hallo " + person + “,<br>");
document.writeln(“nächstes Jahr sind Sie " + years + “ Jahre alt.");
document.writeln("</body> </html>");
document.close();
}
</script></head>
<body><form>
Bitte geben Sie ihren Namen ein: <input type="text" name="name">
<p> Bitte geben Sie ihr Alter ein : <input type="text" name="age">
<p><input type="button" value="submit" onclick="response(this.form)">
</form></body>
</html>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. Server-basierte Techniken

CGI (Common Gateway Interface)

PERL (Practical Extraction and Reporting Language)

Einbettung in HTML!
Javascript (serverseitig): <%@Language=JScript%>

Scriptsprache, besonders gut geeignet zum Parsen von Strings
PHP (PHP Hypertext Processing)

Schnittstelle zur Datenübergabe vom Webserver an ein anderes
Programm (in C, C++, FORTRAN, PERL, TCL, …)
Einbettung in HTML!
VBScript (serverseitig): <%@Language=VBScript%>

Einbettung in HTML!
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. Server-basierte Techniken
Server-basierte Techniken: Alternativen zu Scriptsprachen

Java Server Pages, mit alle Java-Erweiterungen
Java Servlets
Active Server Pages (ASP) und DCOM
APIs
DB-Middleware
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. Client-basierte Techniken

Javascript (vgl. Beispiel)
VBScript

Java Applets

Microsoft‘s Alternative zu Javascript
Wird interpretiert
Java-Programme, die von der Java-Klasse „Applet“ abgeleitet sind, und
so alle ihre Fähigkeiten und Beschränkungen geerbt haben.
Java VM muss vorhanden sein
ActiveX

Kompilierte Programme für die Pentium/Windows-Plattform
Werden von Webseite geladen und auf dem Pentium/WindowsRechner ausgeführt
Sicherheitsproblematik!
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Zusammenfassung (aus Tanenbaum)
Zusammenfassung
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML- und WebserviceSicherheit
2. XML
2.1 XML 1.0 und XML Schema
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Gliederung
1. XML 1.0
2. XML Namespaces: URI, URL und URN
3. XML Schema
Literatur:
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML 1.0
Beispiel für ein wohlgeformtes XML-Dokument
Präambel
Unicode-Unterstützung
<?xml version="1.0" encoding=“UTF-8” standalone="yes"?>
<conversation>
Wurzelelement
<greeting>Hello, world!</greeting>
(nur eins!)
<response>
Stop the planet, I want to get off!
</response>
Problem: der <response>-Tag
</conversation>
könnte in einem anderen Dokument
eine andere Bedeutung haben
(z.B. der http Return Code)
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML 1.0 - Baumstruktur
<?xml version="1.0" standalone="yes"?>
<conversation>...</conversation>
<greeting>...</greeting>
Hello, world!
<response>...</response>
Stop the planet, I want to get off!
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML Namespaces
Lösung des Problem:
Verlängerung des Strings “response” durch eindeutigen
Präfix
Präfix ist ein Uniform Ressource Identifier (URI)
Abkürzungen sind erlaubt
<?xml version="1.0" standalone="yes"?>
<conv:conversation xmlns:conv=“http://conversation.org>
<conv:greeting>Hello, world!</conv:greeting>
<conv:response>
Stop the planet, I want to get off!
</conv:response>
</conv:conversation>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML Namespaces
URI, URN, URL:
URI: Uniform Ressource Identifier, kann URN oder URL sein
URN: Uniform Ressource Name
Weltweit eindeutiges Namensschema
Beispiel: ISBN-Nummern für Bücher: 0-672-32651-5
Beispiel: URLs
URL: Uniform Ressource Locator
WWW-weit eindeutiger Ort, an dem man eine Datei finden kann
stabile URLs können als URNs verwendet werden
Beispiel: http://www.w3.org/2000/09/xmldsig#
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML-Schema: Bücherliste Schwenk
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="book_list.xsl"?>
<book_list xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="F:\Lehre\xml\book_list.xsd">
<book>
<title> Moderne Verfahren der Kryptographie, 5. Aufl. </title>
<author> A.Beutelspacher, J.Schwenk, K.Wolfenstetter </author>
<year> 2003 </year>
</book>
<book>
<title> Sicherheit und Kryptographie im Internet, 2. Aufl.
</title>
<author> J. Schwenk </author>
<year> 2005 </year>
</book>
</book_list>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML Schema
Beschreibt die Struktur eines XML-Dokument
somit teilweise auch seine Bedeutung
XML-Dokumente, deren Struktur dem XML Schema
entspricht, heißen valid (“gültig”).
Veraltete Alternative: Document Type Definitions (DTD)
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML-Schema: Bücherliste Schwenk
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="book_list" type="bl"/>
<xsd:complexType name="bl">
<xsd:sequence>
<xsd:element name="book" type="b"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="b">
<xsd:sequence>
<xsd:element name="title" type="xsd:string"/>
<xsd:element name="author" type="xsd:string"/>
<xsd:element name="year" type="xsd:positiveInteger"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML-Webseite (aus A. Tanenebaum)
<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="/">
<html>
<body>
<table border="2">
<tr>
<th> Title</th>
<th> Author</th>
<th> Year </th>
</tr>
<xsl:for-each select="book_list/book">
<tr>
<td> <xsl:value-of select="title"/> </td>
<td> <xsl:value-of select="author"/> </td>
<td> <xsl:value-of select="year"/> </td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML-Webseite (aus A. Tanenebaum)
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. ??

LAMP ...
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML- und WebserviceSicherheit
2. XML
2.2 XML Co-Standards
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Gliederung
1. Auswahl: XPath, XPointer und XQuery
2. Formatierung: XSLT und XSL-FO
3. WWW: XHTML, XForms, XLink
Literatur:
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Standard-Beispiel: Bücherliste Schwenk
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="xpath_tester.xsl"?>
<book_list xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="F:\Lehre\xml\book_list.xsd">
<book id="mvdk">
<title> Moderne Verfahren der Kryptographie, 5. Aufl. </title>
<author> A. Beutelspacher, J. Schwenk, K.-D. Wolfenstetter </author>
<year> 2003 </year>
</book>
<book id="sukii">
<title> Sicherheit und Kryptographie im Internet, 2. Aufl. </title>
<author> J. Schwenk </author>
<year> 2005 </year>
</book>
</book_list>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. XPath

In der einfachsten Form: Pfadangabe im Dokumentenbaum

Erweitert um Wildcards ...

(In Analogie zur Pfadangabe im Dateibaum eines Betriebssystems)
Bspl: /book_list/book selektiert alle <book>-Elemente
Bspl: /book_list/book/* selektiert alle Elemente in diesem Pfad
und Funktionen.

Bspl: //*[contains(name(), 'oo')] selektiert alle Elemente, deren Namen
die Zeichenfolge „oo“ enthalten.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. XPath

XPath
definiert
folgende
„Achsen“
relativ zum
ausgewählt
en Element
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Testen von XPath
XSL-File zum Testen von XPath-Ausdrücken (hervorgehoben)
Ergebnisse werden von <nodelist> und </nodelist> eingeschlossen
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="urn:schiedermeier:xpath_tester" version="1.0">
<xsl:output method="xml" encoding="utf-8" indent="yes"/>
<xsl:template match="/">
<nodelist>
<xsl:copy-of select=“//book" />
</nodelist>
</xsl:template>
</xsl:stylesheet>
Quelle: Vorlesung XML, C. Schiedermeier, FH Nürnberg
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Testen von XPath: Beispiel 1
//book und /book_list/book und /descendant-or-self::node()/child::book
liefern
<book id="mvdk" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<title> Moderne Verfahren der Kryptographie, 5. Aufl. </title>
<author> A. Beutelspacher, J. Schwenk, K.-D. Wolfenstetter </author>
<year> 2003 </year>
</book>
<book id="sukii" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<title> Sicherheit und Kryptographie im Internet, 2. Aufl. </title>
<author> J. Schwenk </author>
<year> 2005 </year>
</book>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Testen von XPath: Beispiel 2
/book_list/book[1]/title
liefert
<title xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> Moderne
Verfahren der Kryptographie, 5. Aufl. </title>
//book[@id=‘sukii’]/title
liefert
<title xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
Sicherheit und Kryptographie im Internet, 2. Aufl. </title>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Testen von XPath: Beispiel 3
//*[contains(name(),'oo')]
liefert
<book_list xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="F:\Lehre\xml\book_list.xsd">
<book id="mvdk">
<title> Moderne Verfahren der Kryptographie, 5. Aufl. </title>
<author> A. Beutelspacher, J. Schwenk, K.-D. Wolfenstetter </author>
<year> 2003 </year>
</book>
<book id="sukii">
<title> Sicherheit und Kryptographie im Internet, 2. Aufl. </title>
<author> J. Schwenk </author>
<year> 2005 </year>
</book>
</book_list>
<book id="mvdk" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<title> Moderne Verfahren der Kryptographie, 5. Aufl. </title>
<author> A. Beutelspacher, J. Schwenk, K.-D. Wolfenstetter </author>
<year> 2003 </year>
</book>
<book id="sukii" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<title> Sicherheit und Kryptographie im Internet, 2. Aufl. </title>
<author> J. Schwenk </author>
<year> 2005 </year>
</book>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Testen von XPath: Beispiel 3
//*[contains(name(),'oo')]
liefert
<book_list xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="F:\Lehre\xml\book_list.xsd">
<book id="mvdk">
<title> Moderne Verfahren der Kryptographie, 5. Aufl. </title>
<author> A. Beutelspacher, J. Schwenk, K.-D. Wolfenstetter </author>
<year> 2003 </year>
</book>
<book id="sukii">
<title> Sicherheit und Kryptographie im Internet, 2. Aufl. </title>
<author> J. Schwenk </author>
<year> 2005 </year>
</book>
</book_list>
<book id="mvdk" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<title> Moderne Verfahren der Kryptographie, 5. Aufl. </title>
<author> A. Beutelspacher, J. Schwenk, K.-D. Wolfenstetter </author>
<year> 2003 </year>
</book>
<book id="sukii" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<title> Sicherheit und Kryptographie im Internet, 2. Aufl. </title>
<author> J. Schwenk </author>
<year> 2005 </year>
</book>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Testen von XPath: Beispiel 3
//book/descendant::*
liefert
<title xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> Moderne
Verfahren der Kryptographie, 5. Aufl. </title>
<author xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> A.
Beutelspacher, J. Schwenk, K.-D. Wolfenstetter </author>
<year xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 2003
</year>
<title xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
Sicherheit und Kryptographie im Internet, 2. Aufl. </title>
<author xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> J.
Schwenk </author>
<year xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 2005
</year>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Testen von XPath: Beispiel 3
/book_list/book[1]/following-sibling::*
liefert
<book id="sukii" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance">
<title> Sicherheit und Kryptographie im Internet, 2. Aufl.
</title>
<author> J. Schwenk </author>
<year> 2005 </year>
</book>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. XPointer
XML Linking Language (XLink)
This specification defines the XML Linking Language (XLink), which
allows elements to be inserted into XML documents in order to create and
describe links between resources. It uses XML syntax to create structures
that can describe the simple unidirectional hyperlinks of today's HTML, as
well as more sophisticated links.
XML Base
This specification proposes syntax for providing the equivalent of HTML
BASE functionality generically in XML documents by defining an XML
attribute named xml:base.
<head> <base href="http://aktuell.de.selfhtml.org">  </head>
XML Pointer Language (XPointer)
This work defines the XML Pointer Language (XPointer), the language to
be used as a fragment identifier for any URI-reference that locates a
resource of Internet media type text/xml or application/xml.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. XQuery
XML Query (XQuery)
XML Query provides flexible query facilities to extract data from real
and virtual documents and collections both locally and on the World
Wide Web, thereby finally providing the needed interaction between
the Web world and the database world. The ambitious task of the
XML Query (XQuery) Working Group is to develop the first world
standard for querying Web documents, following the incredibly
successful discussion started at the QL'98 event.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Gliederung
1. Auswahl: XPath, XPointer und XQuery
2. Formatierung: XSLT und XSL-FO
3. WWW: XHTML, XForms, XLink
Literatur:
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. XSL
XSL = XSLT + XSL-FO
Extensible Style Sheet Language Transformation (XSLT):
Transformation eines XML-Dokuments in ein Zieldokument

Ursprüngliches Zielformat: XSL-FO
heute: (X)HTML, PDF, Text, ...
Exstensible Style Sheet Language-Formatting Objects

ähnlich CSS, aber XML-basiert
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. XSL
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="book_list.xsl"?>
<book_list xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="F:\Lehre\xml\book_list.xsd">
<book>
<title> Moderne Verfahren der Kryptographie, 5. Aufl. </title>
<author> A.Beutelspacher, J.Schwenk, K.Wolfenstetter </author>
<year> 2003 </year>
</book>
<book>
<title> Sicherheit und Kryptographie im Internet, 2. Aufl.
</title>
<author> J. Schwenk </author>
<year> 2005 </year>
</book>
</book_list>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. XSL
<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="/">
<html>
<body>
<table border="2">
<tr>
<th> Title</th>
<th> Author</th>
<th> Year </th>
</tr>
<xsl:for-each select="book_list/book">
<tr>
<td> <xsl:value-of select="title"/> </td>
<td> <xsl:value-of select="author"/> </td>
<td> <xsl:value-of select="year"/> </td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. XSL
<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:template match="/">
<html>
<body>
<table border="2">
<tr>
<th> Title</th>
<th> Author</th>
<th> Year </th>
</tr>
<xsl:apply-templates select="//book"/>
</table>
</body>
</html>
</xsl:template>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. XSL
<xsl:template match="book">
<tr>
<td><xsl:apply-templates select="title"/></td>
<td><xsl:apply-templates select="author"/></td>
<td><xsl:apply-templates select="year"/></td>
</tr>
</xsl:template>
<xsl:template match="title"><xsl:value-of select="."/></xsl:template>
<xsl:template match="author"><xsl:value-of select="."/></xsl:template>
<xsl:template match="year"><xsl:value-of select="."/></xsl:template>
</xsl:stylesheet>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML-Webseite (aus A. Tanenebaum)
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. XSL
Mehr: ZVON XSLT-Tutorial
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Gliederung
1. Auswahl: XPath, XPointer und XQuery
2. Formatierung: XSLT und XSL-FO
3. WWW: XHTML, XForms, XLink
Literatur:
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. XHTML
XHTML = HTML + wohlgeformtes XML
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML- und WebserviceSicherheit
2. XML
2.3 XML Signature
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Gliederung
1.
2.
3.
4.
5.
Anforderungen
Syntax des <signature>-Elements
Enveloping, Enveloped, Detached Signatures
Erzeugung und Verifikation
Die Bestandteile des <signature>-Elements
Literatur: J. Rosenberg and D. Remy, Securing Web Services
with WS-Security. SAMS Publishing, Indianapolis, USA,
2004.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Anforderungen an die XML-Signatur

Gemeinsamer IETF/W3C-Standard
Ältere Signaturformate:

PKCS#7: Paar (Daten, Signatur)
OpenPGP: Paar (Daten, Signatur)
www.w3.org/TR/xmldsig-requirements:

XML-Signaturen müssen auf jeden Datensatz anwendbar sein, der
durch eine URI beschrieben werden kann (auch nicht-XML-Daten).
XML-Signaturen müssen auf Teile (das geht nicht mit PKCS#7,
OpenPGP) oder das ganze Dokument anwendbar sein.
Zu einem statischem Inhalt eines Webdokuments kann es mehrere
Signaturen geben.
Es muss möglich sein, neben digitalen Signaturen auch Message
Authentication Codes (symm. Schlüssel) und die dynamische
Vereinbarung von Schlüsselmaterial einzusetzen.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2. Syntax des <signature>-Elements
<Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm=“..."/>
<SignatureMethod Algorithm=“..."/>
<Reference URI=“.../">
<Transforms>
<Transform Algorithm=“..."/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P>...</P><Q>...</Q><G>...</G><Y>...</Y>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. Enveloping Signature
<Signature>
<SignedInfo>
<Reference URI=“#123“ />
</SignedInfo>
<Signature>
<Reference>
<SignatureValue>MC0C=...</SignatureValue>
<KeyInfo>...</KeyInfo>
<Object>
<SigndedItem id=“123”>TBS</SignedItem>
</Object>
</Signature>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
<SignedElement>
3. Enveloped Signature
<Order id=“123”>
<ArticleNo>656565</ArticleNo>
<Number>10</Number>
<EnvelopingElement>
<Signature>
<Reference>
<Signature>
<SignedInfo>
<Reference URI=“#123“ />
</SignedInfo>
<SignatureValue>MC0C=...</SignatureValue>
<KeyInfo>...</KeyInfo>
</Signature>
</Order>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. Detached Signature

Zu signierendes Element ist weder
Nachfolger noch Vorgänger von
<Signature> im DOM-Baum
Zu signierendes Element kann im
gleichen Dokument oder unter einer
beliebigen URI stehen.
<SignedElement>
<Signature>
<Reference>
cat.jpg
<Signature>
<Reference>
<Reference>
<Reference>
config.txt
authentic.xml
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Erzeugung einer XML-Signatur
1. Erzeugung der <Reference>-Elemente
a) Lade die Ressource, die durch die URI in dem <Reference>-Element
spezifiziert ist.
b) Wende auf jede Ressource die in <Transforms> spezifizierten
Transformationen an.
c) Berechne den Hashwert mit dem in <DigestMethod> angegebenen
Algorithmus.
d) Füge das Ergebnis als Wert des <DigestValue>-Elements ein.
2. Erzeugung der Signatur
a) Kanonisierte das gesamte <SignedInfo>-Element durch Anwendung
<CanonicalizationMethod>
b) Berechne den Hashwert des kanonisierten <SignedInfo>-Elements
mittels <DigestMethod>
c) Berechne die Signatur dieses Hashwertes mittels <SignatureMethod>
und lege ihn in <SignatureValue> ab.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
4. Verifikation einer XML-Signatur
1. Verifikation der <Reference>-Elemente
a) Lade die Ressource, die durch die URI in dem <Reference>-Element
spezifiziert ist.
b) Wende auf jede Ressource die in <Transforms> spezifizierten
Transformationen an.
c) Berechne den Hashwert mit dem in <DigestMethod> angegebenen
Algorithmus.
d) Vergleiche das Ergebnis mit dem Wert des <DigestValue>-Elements.
Wenn die Werte nicht übereinstimmen, ist die Signatur ungültig.
2. Verifikation der Signatur
a) Kanonisierte das gesamte <SignedInfo>-Element durch Anwendung
<CanonicalizationMethod>
b) Berechne den Hashwert des kanonisierten <SignedInfo>-Elements
mittels <DigestMethod>
c) Verifiziere die Signatur aus <SignatureValue> gegen diesen Hashwert.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
5. Das <Signature>-Element
Das <Signature>-Element hat zwei bis vier Nachfolger
Ein <SignedInfo>-Element (-> 5.1) mit Verweisen auf alle signierten
Daten
Die Signatur selbst im <SignatureValue>-Element (-> 5.2)
Optional: Den Schlüssel oder eine Beschreibung der Methode, wie
man an den Schlüssel gelangt, um die Signatur zu verifizieren, im
<KeyInfo>-Tag. (-> 5.3)
Optional: Ein <Object>-Element, das beliebige Daten enthalten darf
(z.B. für enveloping Signatures). (-> 5.4)
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
5.1 Das <SignedInfo>-Element
Das <SignedInfo>-Element hat zwei bis drei Nachfolger
Ein <CanonicalizationMethod>-Element (-> 5.1.1)
Ein <SignatureMethod>-Element, das Hash- und
Signaturalgorithmus spezifiziert (-> 5.1.2)
Optional: Null, ein oder mehrere <Reference>-Elemente, die auf die
zu signierenden Daten verweisen (-> 5.1.3)
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
5.1.1 Das <CanonicalizationMethod>-Element
Das <CanonicalizationMethod>-Element spezifiziert eine
Kanonisierungsmethode, damit XML-Dokumente mit gleicher
Semantik die gleiche Signatur liefern.
Beispiel:
<Liste>+sp++cr++lf+
+t+<Element1>+sp+Hallo+sp+</Element1>+cr++lf+
+t+<Element2>Welt</Element2>+cr++lf+
</LIste>+cr++lf+
wird zu
<Liste>+lf+
<Element1>+sp+Hallo+sp+</Element1>+lf+
<Element2>Welt</Element2>+lf+
</LIste>+lf+
(+t+ Tabulator, +sp+ Space, +cr+ Carriage Return, +lf+ Line Feed)
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
5.1.2 Das <SignatureMethod>-Element
Das <SignatureMethod>-Element spezifiziert den Signatur- oder MACAlgorithmus.
Mandatory:
DSAwithSHA1
HMAC-SHA1 (Message Authentication Code!)
Recommended
RSAwithSHA1
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
5.1.3 Das <Reference>-Element
Das <Reference>-Element spezifiziert die Ressourcen, die signiert
werden sollen, ihre Transformationen, den Hashalgorithmus und den
Hashwert.
Die URI, die die Ressource eindeutig bezeichnet, ist ein Attribut des
<Reference>-Elements (kein Unterelement).

Extern: URI="http://www.example.com/example.xml"
Das ganze eigene Dokument: URI=" ".
Teile des eigenen Dokuments: URI="#Teil1"

Teile extern:
URI="http://www.example.com/example.xml#Teil1"
Non-XML: URI="http://www.example.com/picture.jpg"
XPointer: URI="xpointer(/)"

Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
5.1.3 Das <Reference>-Element
Das <Reference>-Element spezifiziert die Ressourcen, die signiert
werden sollen, ihre Transformationen, den Hashalgorithmus und den
Hashwert.
Das <Transform>-Element kann folgende Typen von
Transformationen enthalten

Kanonisierung
Base-64-Umwandlung
XPath-Filterregeln
Enveloped Signature Transform (das <Signature>-Element darf nicht in
die Bildung/Verifikation der Signatur mit einfließen)
XSLT
Bei komplexen Transformation schwierig zu sagen, was eigentlich
signiert wurde.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
5.1.3 Das <Reference>-Element
Das <Reference>-Element spezifiziert die Ressourcen, die signiert
werden sollen, ihre Transformationen, den Hashalgorithmus und den
Hashwert.
Das <DigestMethod>-Element kann folgende Werte enthalten

Mandatory: SHA1
Das <DigestValue>-Element enthält den Hashwert.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
5.2 Das <SignatureValue>-Element
Das <SignatureValue>-Element enthält die Base64-Codierung der
eigentlichen Signatur
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
5.3 Das <KeyInfo>-Element
Das <KeyInfo>-Element kann den Schlüssel zur Überprüfung der
Signatur/des MAC auf folgende Arten referenzieren:
fehlt: keine Information zum Schlüssel.
enthält <KeyName>: eindeutiger Name des Schlüssels.
enthält <KeyValue>: enthält als Nachfolger entweder
<DSAKeyValue> oder <RSAKeyValue>, die unterschiedlich
strukturiert sind und den jeweiligen Schlüssel Base64-codiert
enthalten.
enthält <X509Data>: Hier kann eine Referenz auf ein X.509Zertifikat enthalten sein, oder in Base64-Codierung das Zertifikat
oder die Zertifikatskette selbst.
enthält <PGPData> oder <SPKIData>: Analog zu <X509Data>.
enthält <RetrievalMethod>: Eine URI, wo der Schlüssel zu finden ist,
plus eine optionale Angabe seines Typs.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
5.3 Das <Object>-Element
Das <Object>-Element kann beliebige Werte enthalten, üblich sind aber
nur:
Die zu signierenden Daten, entweder als XML-Element oder als
Base64-Codierung einer Binärdatei (nur für enveloping Signatures).
Ein <Manifest>-Element, das wie das <Reference>-Element
Referenzen auf die signierten Daten enthalten kann; beim
<Manifest>-Element müssen diese aber nicht überprüft werden.
Ein <SignatureProperties>-Element, das z.B. den Zeitpunkt der
Erzeugung der Signatur enthalten kann.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Beispiel
F:\Projekte\2005\XMLSignature\rechnung_multisigned.xml
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML- und WebserviceSicherheit
2. XML
2.4 XML Encryption
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Gliederung
1.
2.
3.
4.
Beispiel: Kreditkartendaten
Struktur von <EncryptedData>
Verschlüsselung und Entschlüsselung
XML Verschlüsselung und Signatur
Literatur:
www.w3.org
J. Rosenberg and D. Remy, Securing Web Services with WSSecurity. SAMS Publishing, Indianapolis, USA, 2004
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Beispiel: Kreditkartendaten

Hoch sensible Kreditkartendaten werden heute nur mit SSL
verschlüsselt übertragen und dann unverschlüsselt gespeichert
Lösungsansatz in den 1990ern: Secure Electronic Transactions
(SET)
Lösungsansatz heute: XML Encryption

Baut auf XML Signature auf
Verschlüsselt werden können

ganze XML-Elemente (Teilbäume)
Nur der Inhalt eines XML-Elements
externe Dokumente
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Beispiel: Kreditkartendaten
Zu übertragende Daten:
<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<CreditCard Limit='5,000' Currency='USD'>
<Number>4019 2445 0277 5567</Number>
<Issuer>Bank of the Internet</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Beispiel: Kreditkartendaten
Das gesamte <CreditCard>-Element ist verschlüsselt.
<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<EncryptedData
Type='http://www.w3.org/2001/04/xmlenc#Element'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<CipherData>
<CipherValue>A23B45C56...</CipherValue>
</CipherData>
</EncryptedData>
</PaymentInfo>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Beispiel: Kreditkartendaten
<Number>, <Issuer> und <Expiration> sind verschlüsselt.
<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<CreditCard Limit='5,000' Currency='USD'>
<EncryptedData
Type='http://www.w3.org/2001/04/xmlenc#Content'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</CreditCard>
</PaymentInfo>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. Beispiel: Kreditkartendaten
Nur der Wert von <Number> ist verschlüsselt.
<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<CreditCard Limit='5,000' Currency='USD'>
<Number>
<EncryptedData
xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Content'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</Number>
<Issuer>Bank of the Internet</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
Jörg Schwenk
</PaymentInfo>
Lehrstuhl für Netz- und Datensicherheit
2. Struktur von <EncryptedData>
<EncryptedData Id? Type? MimeType? Encoding?>
<EncryptionMethod/>
<ds:KeyInfo>
<EncryptedKey/>?
<AgreementMethod/>?
<ds:*/>?
</ds:KeyInfo>
<CipherData>
<CipherValue>?
<CipherReference URI?>?
</CipherData>
<EncryptionProperties/>?
</EncryptedData>
(„?“ bedeutet „optional“)
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2.1 <EncryptionMethod>
<EncryptionMethod/>

3DES: http://www.w3.org/2001/04/xmlenc#tripledes-cbc
AES:

http://www.w3.org/2001/04/xmlenc#aes128-cbc
http://www.w3.org/2001/04/xmlenc#aes256-cbc
http://www.w3.org/2001/04/xmlenc#aes192-cbc
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2.2 <CipherData>
<CipherData>
<CipherValue>?
<CipherReference URI?>?
</CipherData>

<CipherValue>: Base64-codiertes Ergebnis der
Verschlüsselungsoperation
<CipherReference>: Verschlüsselte Daten können über eine URI
adressiert werden; die URI ist Attribut.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2.3 <EncryptionProperties>
<EncryptionProperties>

Ähnlich wie <SignatureProperties> in XML Signature, nur anderer Ort.

z.B. Datum und Uhrzeit der Verschlüsselung
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2.4 <KeyInfo>
<ds:KeyInfo>
<EncryptedKey/>?
<AgreementMethod/>?
<ds:*/>?
</ds:KeyInfo>

Übernommen aus XML Signature, aber hier symmetrische Schlüssel
(anstelle von Public Key in XML Signature).
Neben den Methoden aus XML Signature noch

z.B. Datum und Uhrzeit der Verschlüsselung
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2.4.1 <EncryptedKey>
[t01] <EncryptedData Id='ED'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
[t02]
<EncryptionMethod
Algorithm='http://www.w3.org/2001/04/xmlenc#aes128-cbc'/>
[t03]
<ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
[t04]
<ds:RetrievalMethod URI='#EK'
Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
[t05]
<ds:KeyName>Sally Doe</ds:KeyName>
[t06]
</ds:KeyInfo>
[t07]
<CipherData><CipherValue>DEADBEEF</CipherValue></CipherData>
[t08] </EncryptedData>

In [t04] wird der verschlüsselte Schlüssel referenziert (unter der relative URI ‘#EK‘).
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2.4.1 <EncryptedKey>
[t09] <EncryptedKey Id='EK' xmlns='http://www.w3.org/2001/04/xmlenc#'>
[t10]
<EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
[t11]
<ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
[t12]
<ds:KeyName>John Smith</ds:KeyName>
[t13]
</ds:KeyInfo>
[t14]
<CipherData><CipherValue>xyzabc</CipherValue></CipherData>
[t15]
<ReferenceList>
[t16]
<DataReference URI='#ED'/>
[t17]
</ReferenceList>
[t18]
<CarriedKeyName>Sally Doe</CarriedKeyName>
[t19] </EncryptedKey>

Das <EncryptedKey>-Element hat den gleichen Aufbau wie das <EncryptedData>-Element,
aber es muss ein Schlüssel in <CipherValue> verschlüsselt sein.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
2.4.2 <AgreementMethod>

Prinzipiell Möglichkeit, Schlüssel wie mit SSL oder IKE auszuhandeln.
Aber: Asynchron!.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
XML- und WebserviceSicherheit
3. Web Service Security
3.1 WS-Security
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Gliederung
1.
2.
3.
4.
5.
SOAP
WS-Security: Der SOAP Security Header
Security Tokens in WS-Security
XML Signature in WS-Security
XML Encryption in WS-Security
Literatur: J. Rosenberg and D. Remy, Securing Web Services
with WS-Security. SAMS Publishing, Indianapolis, USA,
2004.
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. SOAP
Beispiel: Reisebuchung mit SOAP (aus
SOAP Version 1.2 Part 0: Primer)
Name: Åke Jógvan Øyvind
Hinflug: am 14.12.2001 von New
York nach Los Angeles
Rückflug: am 20.12.2001 (LA -> NY)
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. SOAP
Beispiel: Reisebuchung mit SOAP
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation
xmlns:m="http://travel.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-qba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:name>Åke Jógvan Øyvind</n:name>
</n:passenger>
</env:Header>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. SOAP
<env:Body>
<p:itinerary xmlns:p="http://travel.example.org/reservation/travel">
<p:departure>
<p:departing>New York</p:departing>
<p:arriving>Los Angeles</p:arriving>
<p:departureDate>2001-12-14</p:departureDate>
<p:departureTime>late afternoon</p:departureTime>
<p:seatPreference>aisle</p:seatPreference>
</p:departure>
<p:return>
<p:departing>Los Angeles</p:departing>
<p:arriving>New York</p:arriving>
<p:departureDate>2001-12-20</p:departureDate>
<p:departureTime>mid-morning</p:departureTime>
<p:seatPreference/>
</p:return>
</p:itinerary>
<q:lodging xmlns:q="http://travel.example.org/reservation/hotels">
<q:preference>none</q:preference>
</q:lodging>
</env:Body> </env:Envelope>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. SOAP
Beispiel: Reisebuchung mit SOAP
Buchungsservice von travel.example.org fragt nach fehlender
Information: Name des Flughafens!
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
1. SOAP
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation xmlns:m=“..." env:role=“..." env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-29T13:35:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger xmlns:n=“..." env:role=“..." env:mustUnderstand="true">
<n:name>Åke Jógvan Øyvind</n:name>
</n:passenger>
</env:Header>
<env:Body>
<p:itineraryClarification xmlns:p=“...">
<p:departure>
<p:departing><p:airportCh> JFK LGA EWR </p:airportCh></p:departing>
</p:departure>
<p:return>
<p:arriving> <p:airportCh> JFK LGA EWR </p:airportCh> </p:arriving>
</p:return>
</p:itineraryClarification>
</env:Body>
Jörg Schwenk
</env:Envelope>
Lehrstuhl für Netz- und Datensicherheit
2. SOAP Security Header
Neuer Header-Block <wsse:Security>
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="..." xmlns:wsse="..." xmlns:enc="..."
xmlns:ds="..." xmlns:wsu="...">
<soap:Header>
<wsse:Security xmlns:wsse="...">

<xxx:CustomToken wsu:Id="MyID" xmlns:xxx="...">
FHUIORv...
</xxx:CustomToken>

<ds:Signature>
...
</ds:Signature>

<enc:ReferenceList>
...
</enc: ReferenceList>
</wsse:Security>
</soap:Header>
<soap:Body wsu:Id="MsgBody">
...
</soap:Body>
Jörg Schwenk
</soap:Envelope>
Lehrstuhl für Netz- und Datensicherheit
3. Security Tokens in WS-Security
Username Token: Übertragung von Username/Password im Klartext (oder
ggf. mit XML Encryption verschlüsselt)
<soap:Envelope>
<soap:Header>
...
<wsse:Security xmlns:wsse="...">
<wsse:UsernameToken>
<wsse:Username> Jörg </wsse:Username>
<wsse:Password> geheim42 </wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
<soap:Body wsu:Id="MsgBody"> ... </soap:Body>
</soap:Envelope>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. Security Tokens in WS-Security
Username Token: Übertragung von Password als Hashwert von Password,
Nonce und Zeit
<soap:Envelope>
<soap:Header>
...
<wsse:Security xmlns:wsse="...">
<wsse:UsernameToken>
<wsse:Username> Jörg </wsse:Username>
<wsse:PasswordType=“wsse:PasswordDigest”>
AF6B469EEC73FFD4CA42
</wsse:PasswordType>
<wsse:Nonce> 6F34D7E87FA </wsse:Nonce>
<wsu:Created> 2001-12-13T08:00:00Z </wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
<soap:Body wsu:Id="MsgBody"> ... </soap:Body>
</soap:Envelope>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. Security Tokens in WS-Security
Binary Security Token: X.509-Zertifikat
<soap:Envelope>
<soap:Header>
...
<wsse:Security xmlns:wsse="...">
<wsse:BinarySecurityToken ValueType=“wsse:X509v3”
ID=“myCert” EncodingType=“wsse:Base64Binary”>
afFG45dgtehJRr76s5kkd83HR6hjs0d0eGks9fehrGFb7gx....
</wsse:BinarySecurityToken>
</wsse:Security>
</soap:Header>
<soap:Body wsu:Id="MsgBody"> ... </soap:Body>
</soap:Envelope>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. Security Tokens in WS-Security
Binary Security Token: X.509-Zertifikat kann als Referenz im <KeyInfo>Element einer digitalen Signatur verwendet werden.
...
<ds:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:Reference URI=“#myCert”/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
...
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. Security Tokens in WS-Security
Binary Security Token: Kerberos Token
<soap:Envelope>
<soap:Header>
...
<wsse:Security xmlns:wsse="...">
<wsse:BinarySecurityToken
ValueType=“wsse:Kerberosv5TGT”
ID=“myTGT”
EncodingType=“wsse:Base64Binary”>
afFG45dgtehJRr76s5kkd83HR6hjs0d0eGks9fehrGFb7gx....
</wsse:BinarySecurityToken>
</wsse:Security>
</soap:Header>
<soap:Body wsu:Id="MsgBody"> ... </soap:Body>
</soap:Envelope>
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
3. Security Tokens in WS-Security
XML Security Tokens:
SAML Token: Security Assertion Markup Language
XrML Token: Extensible Rights Markup Language
XCBF Token: XML Common Biometric Format
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit

title - Ruhr-Universität Bochum

Dieses Dokument Sammlung (en)

Dieses Dokument gespeichert

Schlagen Sie uns vor, wie wir StudyLib verbessern können