XML und Webservice XML- und Webservice
Transcrição
XML und Webservice XML- und Webservice
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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 5 Ein Beispiel 5. 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 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 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 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 6 Performance 6. 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 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit 6 Performance 6. Content Delivery Networks: Grafik (aus Tanenbaum) Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit 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 Lehrstuhl für Netz- und Datensicherheit