1. Das World Wide Web 1.3 Das Hypertext Transfer Protocol. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit

Transkript

1 XML- und Webservice- Sicherheit 1. Das World Wide Web 1.3 Das Hypertext Transfer Protocol

2 Gliederung Gliederung 1. HTTP 1.0 vs Verbindungen 3. HTTP-Methoden 4. Header 5. Ein Beispiel 6. Performance Literatur: A. S. Tanenbaum, Computer Networks, 4th. Ed., Pearson Education Int., 2003

3 1. HTTP 1.0 vs 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

4 1. HTTP 1.0 vs 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 1 Zuordnung zwischen DNS-Hostname und IP-Adresse Da dies heute nicht mehr so ist, MUSS ein HTTP/1.1-Client den host- Request-Header mit senden, der den DNS-Namen noch einmal angibt. Unterstützung absoluter URI (für Proxies). Beispiel: HTTP/1.1 Request-URI (Beispiel): GET /pub/www/theproject.html HTTP/1.1 Host:

5 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-Alive- Headerfeld 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)

6 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

7 3. HTTP-Methoden Methoden wurden mit Hinblick auf spätere Erweiterbarkeit spezifiziert Sichere Methoden GET, HEAD sind sicher, da sie nur Daten abrufen (Buffer Overflow- Angriffe 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

8 3. HTTP-Methoden GET filename HTTP/1.1 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. 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 Ohne URI: Abfrage der Fähigkeiten it des Servers Mit URI: Abfrage der Eigenschaften der Datei TRACE Debugging Anfrage wird im Body der Antwort zurückgesendet

9 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 h 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.

10 3. HTTP-Methoden PUT Request-URI HTTP/1.1 Gegenteil von GET Angefügte Datei wird unter der genannten URI gespeichert, alte Version überschrieben. DELETE Request-URI HTTP/1.1 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

11 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: HTTP/ Authorization Required WWW-Authenticate: Basic realm="name" GET /root/secret.html HTTP/1.0 HOST: Authorization: Basic QWRtaW46Zm9vYmFy HTTP/ OK secret.html

12 3. HTTP-Methoden Digest Authentication RFC 2617 Challenge( opaque )-and-response( response )-Verfahren nonce gegen Denial-of-Service-Angriffe GET /root/secret.html t HTTP/1.0 HOST: HTTP/ Unauthorized WWW-Authenticate: Digest realm= mitarbeiter@bank.de", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Authorization: Digest username= Hans.Mueller", realm="mitarbeiter@bank.de", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri= /root/secret.html", response="e966c932a e42c8ee200cec7f6", e966c932a e42c8ee200cec7f6 opaque="5ccc069c403ebaf9f0171e9517f40e41" HTTP/ OK secret.html

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

14 4. Header 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 (1 beste, 0 schlechteste Präferenz) Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

15 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 Digest- Authentication. From Request O RFC 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

16 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

17 4. Header Header Richtung R/O Inhalt Accept-Ranges Response O Der Param. bytes 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

18 5. Ein Beispiel GET / HTTP/1.0 If-Modified-Since: Tue, 18 Mar :37:03 GMT; length=2322 Connection: Keep-Alive User-Agent: Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux i686) Host: Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso ,*,utf-8

19 5. Ein Beispiel HTTP/ Not Modified Date: Fri, 11 Apr :32:19 GMT Server: Apache Connection: Keep-Alive Keep-Alive: timeout=15, max=100 ETag: " e773d1f"

20 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 , utf-8, * Accept-Language: en, en_us Host:

21 5. Ein Beispiel HTTP/ OK Date: Fri, 11 Apr :33:06 GMT Server: Apache Last-Modified: d Tue, 18 Mar :37:03 GMT ETag: " e773d1f" 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>...

22 6. Performance Lösungen für das World Wide Wait : Caching Mehrfache Server Content t Delivery Networks

23 6. Performance Caching Fragen zum Caching Wer soll cachen? Wie lange soll eine Webseite gecachet werden? Hierarchisches Caching: 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).

24 6. Performance Caching Lokaler Cache Cache-Proxy beim ISP Internet Internet Cache-Proxy im LAN Eigentlicher Webserver

25 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.

26 6. Performance Methoden zur Ermittlung der Speicherzeit im Cache Last-Modified-Header (Heuristik): Wenn das Datum der letzten Modifikation lange zurück liegt, kann man davon ausgehen, dass die Seite noch lange unverändert bleiben wird. If-Modified-Since-Header: 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.

27 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.

28 6. Performance Mehrfache Server Flash Crowds 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

29 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 HTTP- Techniken auf einen der Proxy-Server umgeleitet. t Dazu wird die Startseite der Firma modifiziert.

30 6. Performance Content Delivery Networks: Beispiel (aus Tanenbaum) 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 > mpg > Nice Mice </a> </body> </html>

31 6. Performance 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= > Bears Today </a> <a href= > Nice Mice </a> </body> </html>

32 6. Performance Content Delivery Networks: Grafik (aus Tanenbaum)

33 6. Performance Content Delivery Networks: Grafik (aus Tanenbaum) 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.