XML- und Webservice- Sicherheit

Transkript

1 XML- und Webservice- Sicherheit 1. Das World Wide Web 1.3 Das Hypertext Transfer Protocol Gliederung Gliederung 1. HTTP 1.0 vs Verbindungen Literatur: A. S. Tanenbaum, Computer Networks, 4th. Ed., Pearson Education Int., 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 Persistente Verbindungen Virtuelle Hosts Fehlerhafte Implementierungen von HTTP 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 host- - mit senden, der den DNS-Namen noch einmal angibt. Unterstützung absoluter URI (für Proxies). Beispiel: HTTP/1.1 -URI (Beispiel): GET /pub/www/theproject.html HTTP/1.1 Host: 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- feld waren fehlerhaft HTTP 1.1: Persistente Verbindungen Spart o.g. Kosten Pipelining von HTTP-s wird möglich Versteht ein Server ein neues Feature nicht, so kann er eine Fehlermeldung zurück senden (anstatt die TCP-Verbindung zu beenden) 2. Verbindungen HTTP 1.1: Persistente Verbindungen Sind jetzt Default-Wert! Abbau einer TCP-Verbindung muss mit dem connection-feld signalisiert werden: connection: close Pipelining: s werden nicht nummeriert Server muss Antworten in der Reihefolge zurücksenden, in der die s eingegangen sind

2 Methoden wurden mit Hinblick auf spätere Erweiterbarkeit spezifiziert Sichere Methoden GET, HEAD sind sicher, da sie nur Daten abrufen (Buffer verflow- Angriffe ausgenommen) PST, PUT, DELETE sind unsicher Idempotente Methoden Auch mehrmaliger Aufruf dieser Methoden mit der gleichen URI bewirkt das Gleiche wie einmaliger Aufruf mit dieser URI GET filename HTTP/1.1 Veranlasst den Server, das spezifizierte File an den Client zu senden. Bei einer -URI MUSS noch der host- mit angegeben sein, um die Angabe eindeutig zu machen. HEAD filename HTTP/1.1 Nur der 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. PTINS hne URI: Abfrage der Fähigkeiten des Servers Mit URI: Abfrage der Eigenschaften der Datei TRACE Debugging Anfrage wird im Body der Antwort zurückgesendet CNNECT (reserviert für zukünftige Nutzung mit einem Proxy.) PST -URI HTTP/1.1 Server soll den Body des PST-s an die in -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-peration Die genaue Bedeutung von anfügen wird vom Server meist anhand der -URI ermittelt. PUT -URI HTTP/1.1 Gegenteil von GET Angefügte Datei wird unter der genannten URI gespeichert, alte Version überschrieben. DELETE -URI HTTP/1.1 Daten unter der genannten URI sollen gelöscht werden. PUT, PST und DELETE verlangen ggf. nach einer Autorisierung des Clients Basic Authentication RFC 2617 Digest Authentication RFC 2617 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 HST: HTTP/ Authorization Required WWW-Authenticate: Basic realm="name" GET /root/secret.html HTTP/1.0 HST: Authorization: Basic QWRtaW46Zm9vYmFy HTTP/ K secret.html Digest Authentication RFC 2617 Challenge( opaque )-and-( response )-Verfahren nonce gegen Denial-of-Service-Angriffe GET /root/secret.html HTTP/1.0 HST: 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", opaque="5ccc069c403ebaf9f0171e9517f40e41" HTTP/ K secret.html

3 Status-Codes in der Server-Antwort Code 1xx 2xx 3xx 4xx 5xx Bedeutung Informationen; kann -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 Server-Fehler Beispiel 100 Continue (Server ist bereit, die Anfrage zu bearbeiten) 200 K (Folgezeilen sind abhängig von der Methode; bei GET wird z.b. das gewünschte File im Body gesendet.) 303 See ther (gesuchter Content kann unter einer anderen URI mit GET abgefragt werden) 400 Bad ; 401 Unauthorized; 403 Forbidden; 404 Not Found; 405 Method Not Allowed; Internal Server Error; 501 Not Implemented;... HTTP-Methoden sind bewusst einfach gehalten Zusatzinformationen werden in ergänzenden Message-n übermittelt Client Server: - Server Client : - 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 Accept Accept-Charset Accept-Encoding Accept-Language Authorization From Host User-Agent R/ /R R Inhalt Angabe über bevorzugte Datenformate Accept: image/jpeg Zeichensätze, die der Browser versteht Unterstützte Codierungsverfahren (gzip, compress, deflate, identity) Präferierte Sprachen Accept-Language: da, en-gb;q=0.8, en;q=0.7 Wird normalerweise nach einer 401-Antwort gesendet (dann R); siehe Beispiele zu Basic und Digest- Authentication. RFC Adresse Angabe des DNS-Hostnamens für multihomed Hosts Infos zum Browser und seinem S If-Modified-Since Cache-Control Connection Date Keep-Alive Upgrade R/ R/ Inhalt Datei nur senden, wenn sie seit dem angegebenen Zeitpunkt modifiziert wurde Verschiedene Direktiven zur Kontrolle des ; wird unter Performance besprochen. Aushandlung von Parametern für eine bestimmte Verbindung; spezielle Verwendung: Connection: close Datum und Uhrzeit im RFC 1123-Format Wenn Connect: Keep-Alive gesendet wurde, kann dieser mit hinzugefügt werden. Er ist allerdings nur in RFC 2068 etwas beschrieben. Möglichkeit, eine neuere Protokollversion auszuhandeln Cookie Sendet ein ggf. vorhandenes Cookie zurück zum Server Accept-Ranges Content-Encoding Content-Language Content-Length Content-Type Content-Location ETag Last-Modified Location Server Set-Cookie R/ Inhalt Der Param. bytes sagt, dass Bytes angef. werden dürf. Verwendetes Codierungsverfahren (gzip, compress, deflate, identity) Die Sprache, in der die Webseite abgefasst ist Die Länge der Datei in Bytes Der MIME-ähnliche Typ der Datei Redirection (Umleitung) auf eine andere URI, von der der Content geladen werden kann. Entity Tag Angabe, wann das Dokument zum letzten Mal verändert wurde; wichtig für das Redirection Informationen zum WWW-Server und seinem S Setzen eines Cookies im Browser GET / HTTP/1.0 If-Modified-Since: Tue, 18 Mar :37:03 GMT; length=2322 User-Agent: Mozilla/4.77C-CCK-MCD Caldera Systems penlinux [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

4 HTTP/ Not Modified Date: Fri, 11 Apr :32:19 GMT Server: Apache Keep-Alive: timeout=15, max=100 ETag: " e773d1f" 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 , utf-8, * Accept-Language: en, en_us Host: HTTP/ K Date: Fri, 11 Apr :33:06 GMT Server: Apache Last-Modified: Tue, 18 Mar :37:03 GMT ETag: " e773d1f" Accept-Ranges: bytes Content-Length: 2322 Keep-Alive: timeout=15, max=100 Content-Type: text/html Lösungen für das World Wide Wait : Mehrfache Server Content Delivery Networks <!doctype html public "-//w3c//dtd html 4.0 transitional//en"><html>... Fragen zum Wer soll cachen? Wie lange soll eine Webseite gecachet werden? Lokaler Cache Cache-Proxy beim ISP Hierarchisches : 1. Cache im Client-Host selbst (bei Netscape: rdner 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). Internet Cache-Proxy im LAN Internet Eigentlicher Webserver

5 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. Methoden zur Ermittlung der Speicherzeit im Cache Last-Modified- (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-: Proxy leitet die Anfrage des Client, um den genannten 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 n Verfahren ist möglich. Cache-Control-Mechanismen 15 Seiten zum Thema im Allgemeinen in RFC 2616 Cache-Control mit 17 verschiedenen Direktiven Wichtig: no-cache-direktive für dynamisch generierte Webseiten Cache-Control Expires R/ Inhalt Verschiedenste Direktiven, z.b. no-cache Gibt an, wann der Inhalt spätestens stale, d.h. veraltet sein wird 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 Proaktives 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. 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. Dazu wird die Startseite der Firma modifiziert. Content Delivery Networks: Beispiel (aus Tanenenbaum) riginal-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>

6 Content Delivery Networks: Beispiel (aus Tanenenbaum) Modifizierte Webseite von Furry Video Content Delivery Networks: Grafik (aus Tanenbaum) <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> Content Delivery Networks: Grafik (aus Tanenenbaum) Problem in Schritt 8: Wohin soll cdn-server.com den 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.