XML und Webservice XML- und Webservice

Transcrição

XML- und Webservice
XML
WebserviceSicherheit
1. Das World Wide Web
1.3 Das Hypertext Transfer
f Protocol
Jörg Schwenk
Lehrstuhl für Netz- und Datensicherheit
Gliederung
Gliederung
1.
2
2.
3.
4
4.
5.
6
6.
HTTP 1.0 vs. 1.1
V bi d
Verbindungen
HTTP-Methoden
Header
Ein Beispiel
Performance
Literatur:
A. S. Tanenbaum, Computer Networks, 4th. Ed., Pearson Education Int.,
2003
Jörg Schwenk
1 HTTP 1.0
1.
1 0 vs
vs. 1
1.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
MIME-ähnliche
Metadaten, Modifier
Probleme mit Version 1.0

hierarchische Proxies
Caching
Persistente Verbindungen
Virtuelle Hosts
Fehlerhafte Implementierungen von HTTP 1.0
Jörg Schwenk
1 HTTP 1.0
1.
1 0 vs
vs. 1
1.1
1

Erweiterungen in HTTP 1.1

Persistenz ist Default-Wert
Multi-Homed Web Server:

Ältere HTTP 1.0-Implemetierungen
1.0 Implemetierungen nehmen an, es gäbe eine 1-zu-1
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
2 Verbindungen
2.

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
HTTP-Requests
Requests wird möglich
Versteht ein Server ein neues Feature nicht, so kann er eine
Fehlermeldung zurück senden (anstatt die TCP-Verbindung zu
b
beenden)
d )
Jörg Schwenk
2 Verbindungen
2.

HTTP 1.1: Persistente Verbindungen

Sind jetzt Default-Wert!
Abbau einer TCP-Verbindung muss mit dem connection-Headerfeld
signalisiert
g
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
3 HTTP
3.
HTTP-Methoden
Methoden

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

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

Auch mehrmaliger Aufruf dieser Methoden mit der gleichen URI bewirkt
das Gleiche wie einmaliger
g Aufruf mit dieser URI
Jörg Schwenk
3 HTTP
3.
HTTP-Methoden
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 zz.B.
selbst.
B feststellen
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:
Oh
URI Abf
Abfrage d
der Fähi
Fähigkeiten
k it d
des S
Servers
Mit URI: Abfrage der Eigenschaften der Datei
TRACE

Debugging
Anfrage wird im Body der Antwort zurückgesendet
Jörg Schwenk
3 HTTP
3.
HTTP-Methoden
Methoden

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

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

Annotation von existierenden Ressourcen
S d einer
Senden
i
Nachricht
N h i h an ein
i „bulletin
b ll i board“,
b d“ eine
i „newsgroup“,
“ eine
i
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
Request-URI
URI ermittelt
ermittelt.
Jörg Schwenk
3 HTTP
3.
HTTP-Methoden
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
3 HTTP
3.
HTTP-Methoden
Methoden

Basic Authentication RFC 2617

Einfaches Username/Passwort-Verfahren
Pop-Up-Fenster im Browser erscheint
Passwort ist NICHT verschlüsselt
verschlüsselt, sondern nur BASE64-codiert
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
y
HTTP/1.0 200 OK
secret.html
Jörg Schwenk
3 HTTP
3.
HTTP-Methoden
Methoden

Digest Authentication RFC 2617

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

Status-Codes in der Server-Antwort
Code
Bedeutung
Beispiel
1xx
Informationen; kann Header-Zeilen
enthalten,
th lt
aber
b kkeinen
i
B
Body
d
100 Continue (Server ist bereit, die Anfrage
zu bearbeiten)
b b it )
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
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;
p e e ted; ...
Jörg Schwenk
4 Header
4.

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

Client → Server: Request-Header
Server → Client : Response-Header
Header können optional (O) oder required (R) sein
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
p
((1 beste, 0 schlechteste
Präferenz)
Accept: text/plain; q=0.5, text/html,
text/x dvi; q=0
text/x-dvi;
q=0.8,
8 text/x
text/x-c
c
Jörg Schwenk
4 Header
4.
Header
Richtung R/O
Inhalt
Accept
Request
O
Angabe über bevorzugte Datenformate
Accept: image/jpeg
Accept-Charset
p
Request
q
O
Zeichensätze, die der Browser versteht
Accept-Encoding
Request
O
Unterstützte Codierungsverfahren (gzip, compress, deflate,
identity)
Accept-Language
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
H t
Host
R
Request
t
R
A
Angabe
b d
des DNS
DNS-Hostnamens
H t
fü
für multihomed
ltih
dH
Hosts
t
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
4 Header
4.
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
1123-Format
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.
beschrieben
Upgrade
beide
O
Möglichkeit, eine neuere Protokollversion auszuhandeln
Jörg Schwenk
4 Header
4.
Header
Richtung
R/O
Inhalt
Accept Ranges
Accept-Ranges
Response
O
Der Param
Param. „bytes
bytes“ sagt,
sagt dass Bytes angef
angef. werden dürf
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
Content
Type
Response
O
Der MIME-ähnliche
MIME ähnliche Typ der Datei
Content-Location
Response
O
Redirection (Umleitung) auf eine andere URI, von der der
Content geladen werden kann.
ET
ETag
R
Response
O
„Entity
E i T
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
5 Ein Beispiel
5.
GET / HTTP/1.0
If-Modified-Since: Tue, 18 Mar 2003 15:37:03 GMT;
length=2322
Connection: Keep-Alive
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
image/pjpeg,
image/png, */*
/
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Jörg Schwenk
5 Ein Beispiel
5.
HTTP/1.1 304 Not Modified
Date: Fri, 11 Apr 2003 07:32:19 GMT
Server: Apache
C
Connection:
ti
K
Keep-Alive
Ali
Keep-Alive: timeout=15, max=100
ETag:
g "33403-912-3e773d1f"
Jörg Schwenk
5 Ein Beispiel
5.
GET / HTTP/1.1
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
5 Ein Beispiel
5.
HTTP/1.1 200 OK
Date: Fri, 11 Apr 2003 07:33:06 GMT
Server: Apache
L t M difi d T
Last-Modified:
Tue, 18 M
Mar 2003 15
15:37:03
37 03 GMT
ETag: "33403-912-3e773d1f"
Accept-Ranges:
p
g
bytes
y
Content-Length: 2322
Keep-Alive: timeout=15, max=100
Content-Type: text/html
<!doctype html public "-//w3c//dtd html 4.0
transitional//en"><html> ...
Jörg Schwenk
6 Performance
6.

Lösungen für das „World Wide Wait“:
Caching
Mehrfache Server
Content
C t t Delivery
D li
N
Networks
t
k
Jörg Schwenk
6 Performance
6.
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
p
1999).
) www.cisco.com/ipj
pj
Jörg Schwenk
6 Performance
6.
Caching
Cache-Proxy
beim ISP
Lokaler
Cache
Internet
Cache-Proxy im
LAN
Jörg Schwenk
Internet
Eigentlicher
Webserver
6 Performance
6.
Caching
g

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
abelschen Quasigruppen“
Quasigruppen

Sollte nicht gecachet werden, da eine zweite Anfrage mit dem gleichen
Query-String äußerst unwahrscheinlich ist.
Jörg Schwenk
6 Performance
6.
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
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
p
sie ins einem Cache.
Kombination der beiden Verfahren ist möglich.
Jörg Schwenk
6 Performance
6.
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
6 Performance
6.
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
6 Performance
6.
Content Delivery Networks

Webseiten werden gegen Bezahlung auf möglichst vielen Servern
p
repliziert
Marktführer: Akamai
1 Firma bezahlt das CDN dafür,
1.
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
aufzustellen.
verbesserte Performance.
3. Anfragen an die Webseite der Firma werden durch spezielle HTTPT h ik auff einen
Techniken
i
d
der P
Proxy-Server
S
umgeleitet.
l it t Dazu
D
wird
i d di
die
Startseite der Firma modifiziert.
Jörg Schwenk
6 Performance
6.
Content Delivery Networks: Beispiel (aus Tanenbaum)

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

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
6 Performance
6.
Content Delivery Networks: Grafik (aus Tanenbaum)
Jörg Schwenk
6 Performance
6.
Content Delivery
y Networks: Grafik ((aus Tanenbaum))

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

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