XML- und Webservice- Sicherheit

Transkript

1 Gliederung XML- und Webservice- Sicherheit 1. Das World Wide Web 1.1 Einführung 2. Zahlen zum WWW 3. Überblick WWW 1. Architektur 2. Der Browser 3. Der Server 4. URLs Literatur: A. S. Tanenbaum, Computer Networks, 4th. Ed., Pearson Education Int., 2003 W. Dehnhardt, Scriptsprachen für dynamische Webauftritte, Hanser-Verlag, 2001 Links 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 1 Doug Engelbart prototypes an "online System" (NLS) which does hypertext browsing editing, , and so on. He invents the mouse for this purpose. 1 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, Andy van Dam and others build the Hypertext Editing System and FRESS in 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 rsk Data machines under SINTRAN-III March: "Information Management: A Proposal" written by Tim BL and circulated for comments at CERN (TBL). Paper "HyperText and CERN" produced as background October: Tim Berners- Lee: Hypertext GUI Browser+Editor mit der NeXTStep- Entwicklungsumgebung. "World Wide Web" als Name des Projekts. 1 vember: Erster Webserver: nxoc01.cern.ch, später info.cern.ch genannt. Erste Webseite: ertextwwwtheproject. html Juni: CERN-Computerseminar zu WWW 1 Dezember: Präsentation auf der Hypertext'91 in San Antonio, Texas (US) Snapshot des WWW-Projekts vom

2 Februar: NCSA veröffentlicht Marc Andreessen's "Mosaic for X". 1 März: WWW (Port 80 HTTP) Verkehr: 0.1% auf dem NSF-Backbone April: Deklaration durch CERN-Direktoren, dass die WWW-Technologie frei verfügbar ist. 1 September: WWW-Verkehr 1% auf dem NSF-Backbone. Mosaic für alle Plattformen: X, PCWindows und Macintosh. 1 Oktober: 200 bekannte HTTP-Servers. EU-Projekt WISE. 1 December: Bericht über WWW und Mosaic in "The New York Times" (US) und "The Economist" (UK). "The Guardian" (UK) publiziert eine Seite im WWW März:: Marc Andreessen verläßt NCSA, um die "Mosaic Communications Corp" (später Netscape) zu gründen Mai: Erste Internationale WWW-Konferenz, CERN, Genf (800 Anmeldungen, nur 400 Teilnehmer zugelassen 1 Juni: Über 1500 registrierte Server. Last auf dem ersten Webserver (info.cern.ch) 1000 mal größer als vor 3 Jahren Oktober: World Wide Web Consortium gegründet. 1 October: Zweite Internationale WWW-Konferenz : "Mosaic and the Web", Chicago 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 Total Sites Across All s August April 2005 Quelle: Architektur des WWW 1 Client-Server-Architektur 1 Statische Webseiten: Market Share for Top Servers Across All s August April 2005 Quelle: Browser HTTP-Anfrage (mit URL) HTTP-Anwort (Header+Datei) Web- Server Dateisystem: *.html 2

3 1 Client (Browser) ist für die Darstellung verantwortlich 1 Das gleiche *.html-dokument kann auf verschiedenen Browsern unterschiedlich aussehen. 1 Darstellung verschiedener Dateitypen durch Browser, Plug-In oder Helper 1 Server sendet im HTTP-Header den MIME-Typ der Datei, die übertragen wird 1 Anhand dieses MIME-Typs kann der Browser entscheiden, wie die Datei dargestellt werden soll: 1 textplain, texthtml: Browser 1 imagejpeg, videompeg: Plug-In. Plug-Ins laufen innerhalb des Browsers ab, und haben daher Zugriff auf das aktuelle Fenster. Sie werden nur bei Bedarf geladen. 1 applicationpdf, applicationmsword: Helper-Anwendung. Sie laufen außerhalb des Browsers ab. Kommunikation aus Sicht des Browsers 1. User tippt 2. Browser sucht auf einem Name Server (DNS) die IP-Adresse zu Browser baut eine TCP-Verbindung zu Port 80 auf 4. Browser sendet ein http-kommando über diese TCP-Verbindung: Get schwenkindex.html HTTP1.0 User-agent: Netscape 4.7 Accept: textplain Accept: texthtml Accept: imagegif 5. Server antwortet über die TCP-Verbindung mit: 1 Einer Statuszeile (Erfolgsmeldung oder Fehler) 1 Metainfomation (Beschreibung der nachfolgenden Information) 1 Einer Leerzeile 1 Der Information selbst HTTP1.0 Status 200 Document follows Server: Apache1.8 Date: Mon, 14 Mai, :23:22 GMT -type: texthtml -length: 5280 Last-modified: Fri, 11 Mai, :12:12 GMT 1 Schritt 1-5 wird für jede HTTP-Anfrage wiederholt. 1 Insbesondere muß für jede HTTP-Anfrage eine neue TCP-Verbindung aufgebaut werden 1 Verbesserte Performance durch Persistenz der TCP-Verbindung in HTTP 1.1 <html>... <html> Konkretes Beispiel für 1 Einstellungen des Client -> 1 Weiter mit ethereal und der Datei jpc.de 3.3 Der Server 1 Arbeitszyklus eines Webservers für statische Webseiten: 1. Warte auf eine TCP-Verbindung auf Port Akzeptiere eine TCP-Verbindung auf diesem Port 3. Empfange den Namen des gewünschten Files (z.b. index.htm) 4. Hole das File (von der Festplatte) 5. Sende das File zum Client 6. Beende die TCP-Verbindung 1 Problem: Performance 1 Festplattenzugriffe limitieren die Performance am stärksten 1 Lösung 1: Interner Cache 1 Lösung 2 : Multithreading 1 Lösung 3: Server-Farm mit Frontend 3

4 3.3 Der Server Arbeitszyklus eines modernen Webservers für statische Webseiten: 1. Warte auf eine TCP-Verbindung auf Port Akzeptiere eine TCP-Verbindung auf diesem Port 3. Empfange den Namen des gewünschten Files 4. Löse den Namen des Files auf (z.b. zu wwwrootndsindex.html) 5. Authentisiere den Client (UsernamePassword für BASIC) 6. Überprüfe die Zugriffsrechte dieses Nutzers 7. Überprüfe die Zugriffsbedingungen für das gewünschte File 8. Ist das File im Cache? Wenn nicht, hole es von der Festplatte 9. Bestimme den MIME-Typ des Files und füge ihn in den HTTP-Header ein 10. Sonstiges (z.b. NutzerprofilStatistiken erstellen) 11. Sende das File zum Client 12. Mache einen Eintrag ins Logfile 13. Beende die TCP-Verbindung 3.4 Uniform Ressource Locators (URLs) 1 URLs bestehen aus drei Teilen 1 Protokoll (z.b. http, ftp, telnet, mailto,...) 1 DNS-Name des Servers (z.b. 1 Filename (z.b. lehrevorlesungenxmlindex.html) 1 Beispiele: ftp:ftp.daco.orgscriptevorlesung.pdf 1 file:c FTPJava_Tutorialbook.html 1 mailto:joerg.schwenk@rub.de 1 telnet: HTTP ist ein verbindungsloses Protokoll 1 Verschiedene WWW-Anfragen vom gleichen Client stehen für den Server in keinem Zusammenhang 1 Perfekt geeignet für das ursprüngliche Hypertext-Internet 1 Problematisch für Webshops: Wie merke ich mir, welche Produkte der Kunde beim letzten Besuch in seinen Einkaufswagen gelegt hat? Lösungsansätze: 1 HTML-Lösung 1: Versteckte vordefinierte Formularfelder (vgl. HTML- Kapitel) 1 HTML-Lösung 2: Dynamisch generierte HTML-Seiten mit Hyperlinks, die Session-IDs enthalten 1 Netscape-Lösung: Cookies ( 1. Ein Kunde besucht mit seinem Netscape-Browser (andere Browser verhalten sich analog) die Seite 2. Der Server fügt in seine Antwort eine weitere Kopfzeile der Form Set-Cookie: name=value [;EXPIRES=dateValue] [;DOMAIN=domainName] [;PATH=pathName] [;SECURE] HTTP1.0 Status 200 Document follows Date: Fri, 29 Apr, :23:22 GMT -type: texthtml -length: 5280 Last-modified: Fri, 11 Mai, :12:12 GMT Set-Cookie: SessionID= ; expires=mon, 02-May :59:59 GMT; path=shop <html>... <html> Die Parameter in der Set-Cookie-Zeile haben folgende Bedeutung (optionale Parameter in eckigen Klammern): 1 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= ). 1 [;EXPIRES=dateValue]: Das Cookie bleibt längstens bis zum angegeben Datum gültig und kann danach vom Browser gelöscht werden (expires=mon, 02- May :59:59 GMT). Ist kein Datum angegeben, so wird das Cookie beim Schließen des Browserprogramms gelöscht. 1 [;DOMAIN=domainName]: Cookies werden nur an den Server zurückgeschickt, der sie auch gesetzt hat. Als Kriterium dient hier der name; ist dieser Wert nicht angegeben, so wird der name des Servers genommen, der das Cookie gesetzt hat (in unserem Beispiel also DOMAIN= Die Parameter in der Set-Cookie-Zeile haben folgende Bedeutung (optionale Parameter in eckigen Klammern): 1 [;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. 1 [;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. 4

5 3. Ruft der Kunde nun eine weitere Seite des Webshops auf, z.b. so wird das Cookie im GET-Reqest mit übertragen: Get shopbooks.html HTTP1.0 User-agent: Netscape 4.7 Accept: textplain Accept: texthtml Accept: imagegif Cookie: SessionID= 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. : Weitere Beispiele joes-store.com Cart= ; 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. Cart= ; :00 Browser darf das Cookie an jeden Server zurücksenden : Weitere Beispiele aportal.com Prefs=Stk:SUNW;Spt:1860M :00 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. : Weitere Beispiele sneaky.com UserID= :59 UserID= 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 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!) 5