1. Das World Wide Web 1.1 Einführung. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit

Transkript

1 XML- und Webservice- Sicherheit 1. Das World Wide Web 1.1 Einführung

2 Gliederung 1. Geschichte des WWW 2. Zahlen zum WWW 3. Überblick WWW 1. Architektur 2. Der Browser 3. Der Server 4. URLs 4. Cookies Literatur: A. S. Tanenbaum, Computer Networks, 4th. Ed., Pearson Education Int., 2003 W. Dehnhardt, Scriptsprachen für dynamische Webauftritte, Hanser-Verlag, 2001

3 1. Geschichte des WWW Links: de/alge/museum/ 1945 Vannevar Bush schreibt einen Artikel in Atlantic Monthly über eine photo-elektrisch-mechanisches Gerät namens Memex (für memory extension ), das Links zwischen Dokumenten auf Microfiche erstellen und folgen konnte. 1960s Doug Engelbart entwirft ein "online System" (NLS) zum Hypertextbrowsen und -editieren, für , und so weiter. Zu diesem Zweck erfindet er die Maus. Ted Nelson prägt das Wort 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 und Andere bauen 1967 das Hypertext Editing System und FRESS.

4 1. Geschichte des WWW 1980 Während er das CERN berät (Juni-Dezember 1980), schreibt Tim Berners-Lee ein Notizbuch-Program, "Enquire-Within-Upon- Everything", das es erlaubt, Links zwischen beliebigen Knoten zu erstellen. Jeder Knoten hat einen Titel, einen Typ, und eine Liste von bidirektionalen Links. "ENQUIRE" lief auf Norsk Data-Computern unter SINTRAN-III. III März 1989 "Information Management: A Proposal" von Tim BL zirkuliert zur Kommentierung am CERN. Der Artikel "HyperText and CERN" wurde als Hintergrundinformation dazu geschrieben.

5 1. Geschichte des WWW 1990 October: Tim Berners- Lee: Hypertext GUI Browser+Editor mit der NeXTStep- Entwicklungsumgebung. "World Wide Web" als Name des Projekts. November: Erster Webserver: nxoc01.cern.ch, später info.cern.ch genannt. Erste Webseite: ertext/www/theproject. html

6 1. Geschichte des WWW Juni: CERN-Computerseminar zu WWW Dezember: Präsentation auf der Hypertext'91 in San Antonio, Texas (US) Snapshot des WWW-Projekts vom

7 1. Geschichte des WWW 1993 Februar: NCSA veröffentlicht Marc Andreessen's "Mosaic for X". März: WWW-Verkehr: 0.1% auf dem NSF-Backbone. 30. April: Deklaration durch CERN-Direktoren, dass die WWW-Technologie frei verfügbar ist. September: WWW-Verkehr 1% auf dem NSF-Backbone. Mosaic für alle Plattformen: X, PC/Windows und Macintosh. Oktober: 200 bekannte HTTP-Servers Servers. EU-Projekt WISE. December: Bericht über WWW und Mosaic in "The New York Times" (US) und "The Economist" (UK). "The Guardian" (UK) publiziert eine Seite im WWW.

8 1. Geschichte des WWW 1994 März: Marc Andreessen verläßt NCSA, um die "Mosaic Communications Corp" (später Netscape) zu gründen Mai: 27.Mai: Erste Internationale WWW-Konferenz, CERN, Genf (800 Anmeldungen, nur 400 Teilnehmer zugelassen Juni: Über 1500 registrierte Server. Last auf dem ersten Webserver (info.cern.ch) 1000 mal größer als vor 3 Jahren. 1. Oktober: World Wide Web Consortium gegründet. October: Zweite Internationale WWW-Konferenz : "Mosaic and the Web", Chicago. 16 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

9 2. Statistik des WWW

10 2. Statistik des WWW Total Sites Across All Domains August April 2009 Quelle: netcraft com/archives/web server survey html

11 2. Statistik des WWW Market Share for Top Servers Across All Domains August April 2009 Quelle: netcraft com/archives/web server survey html

12 2. Statistik des WWW Market Share for the Million busiest sites - March 2009 Quelle: netcraft com/archives/web server survey html

13 2. Statistik des WWW SSL Certificates on the web - February 2009 Quelle: netcraft com/archives/web server survey html

14 3 Überblick WWW 3.1 Client-Server-Architektur Webbrowser sind Clients, die Befehle an den Webserver senden. Webserver reagieren nur auf Befehle und werden selbst nicht aktiv. Gemeinsame Sprache: Hypertext Transfer Protocol (http). 32D 3.2 Der Browser Aufgaben: Darstellung der empfangenen Daten (z.b. HTML) Kommunikation mit dem Nutzer 3.3 Der Server Optimiert zur gleichzeitigen Verarbeitung vieler Anfragen. 3.4 URLs Ortsangabe für Dateien im Internet.

15 3.1 Architektur des WWW Statische Webseiten: Webserver überträgt die durch die URL bezeichnete Datei aus seinem Dateisystem unverändert. Browser PC HTTP-Anfrage (mit URL) HTTP-Anwort (Header+Datei) Server Web- Server (z.b. Apache) Datei- system Dynamische Webseiten: Webserver modifiziert i eine Datei aus seinem Dateisystem, oder generiert sie neu (z.b. Suchergebnisse).

16 3.2 Der Client (Browser) Client (Browser) ist für die Darstellung verantwortlich Das gleiche *.html-dokument kann auf verschiedenen Browsern unterschiedlich aussehen. Darstellung verschiedener Dateitypen durch Browser, Plug-In oder Helper Server sendet im HTTP-Header den MIME-Typ der Datei, die übertragen wird id Anhand dieses MIME-Typs kann der Browser entscheiden, wie die Datei dargestellt werden soll: text/plain, text/html: Browser image/jpeg, video/mpeg: Plug-In. Plug-Ins laufen innerhalb des Browsers ab, und haben daher Zugriff auf das aktuelle Fenster. Sie werden nur bei Bedarf geladen. application/pdf, application/msword: Helper-Anwendung. Sie laufen außerhalb des Browsers ab.

17 3.2 Der Client (Browser) Kommunikation aus Sicht des Browsers 1. User tippt 2. Browser sucht auf einem Domain 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 schwenk/index.html HTTP/1.0 User-agent: Netscape 4.7 Accept: text/plain Accept: text/html Accept: image/gif

18 3.2 Der Client (Browser) 5. Server antwortet über die TCP-Verbindung mit: Einer Statuszeile (Erfolgsmeldung oder Fehler) Metainfomation (Beschreibung der nachfolgenden Information) Einer Leerzeile Der Information selbst HTTP/1.0 Status 200 Document follows Server: Apache/1.8 Date: Mon, 14 Mai, :23:22 GMT Content-type: text/html Content-length: 5280 Last-modified: Fri, 11 Mai, :12:12 GMT <html>... </html>

19 3.2 Der Client (Browser) Schritt 1-5 wird für jede HTTP-Anfrage wiederholt. Insbesondere muss für jede HTTP-Anfrage eine neue TCP- Verbindung aufgebaut werden. Zur Performanzsteigerung bauen Browser diese Verbindungen oft gleichzeitig g auf. Verbesserte Performance durch Persistenz der TCP-Verbindung in HTTP 1.1

20 3.2 Der Client (Browser) Konkretes Beispiel für Einstellungen des Client -> Weiter mit ethereal und der Datei jpc.de de

21 33DerServer 3.3 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 Problem: Performance Festplattenzugriffe limitieren die Performance am stärksten Lösung 1: Interner Cache Lösung 2: Multithreading Lösung 3: Server-Farm mit Frontend

22 33DerServer 3.3 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 wwwroot/nds/index.html) 5. Authentisiere den Client (Username/Password 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 tt 9. Bestimme den MIME-Typ des Files und füge ihn in den HTTP-Header ein 10. Sonstiges (z.b. Nutzerprofil/Statistiken erstellen) 11. Sende das File zum Client 12. Mache einen Eintrag ins Logfile 13. Beende die TCP-Verbindung

23 3.4 Uniform Ressource Locators (URLs) URLs bestehen (normalerweise) aus drei Teilen: Protokoll (z.b. http, ftp, telnet, mailto,...) DNS-Name des Servers (z.b. Filename mit Pfadangabe (z.b. /lehre/vorlesungen/xml/index.html) html) Beispiele: ftp://ftp.daco.org/scripte/vorlesung.pdf file:///c /FTP/Java_Tutorial/book.html telnet://

24 3.4 Uniform Ressource Locators (URLs) Username/Password-URLs URLs Standard Format: Beispiel: Benutzername: mybank.com Passwort: ebanking Domäne: evilsite.com it Pfad: /phishing/fakepage.htm

25 4. Cookies (RFC 2109) HTTP ist ein verbindungsloses Protokoll Verschiedene WWW-Anfragen vom gleichen Client stehen für den Server in keinem Zusammenhang Perfekt geeignet für das ursprüngliche Hypertext-Internet Problematisch für Webshops: Wie merke ich mir, welche Produkte der Kunde beim letzten Besuch in seinen Einkaufswagen gelegt hat? Lösungsansätze: HTML-Lösung 1: Versteckte vordefinierte Formularfelder (vgl. HTML- Kapitel) HTML-Lösung 2: Dynamisch generierte HTML-Seiten mit Hyperlinks, die Session-IDs enthalten Netscape-Lösung: Cookies (

26 4. 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] HTTP/1.0 Status 200 Document follows Date: Fri, 29 Apr, :23:22 GMT Content-type: text/html Content-length: 5280 Last-modified: Fri, 11 Mai, :12:12 GMT Set-Cookie: SessionID= ; expires=mon, 02-May :59:59 GMT; path=/shop <html>... </html>

27 4. Cookies Die Parameter in der Set-Cookie-Zeile haben folgende Bedeutung (optionale Parameter in eckigen Klammern): 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= ). [;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. [;DOMAIN=domainName]: Cookies werden nur an den Server zurückgeschickt, der sie auch gesetzt hat. Als Kriterium dient hier der Domainname; ist dieser Wert nicht angegeben, so wird der Domainname des Servers genommen, der das Cookie gesetzt hat (in unserem Beispiel also DOMAIN=

28 4. Cookies Die Parameter in der Set-Cookie-Zeile haben folgende Bedeutung (optionale Parameter in eckigen Klammern): [;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. [;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.

29 4. Cookies 3. Ruft der Kunde nun eine weitere Seite des Webshops auf, z.b. html so wird das Cookie im GET-Reqest mit übertragen: Get shop/books.html HTTP/1.0 User-agent: Netscape 4.7 Accept: text/plain Accept: text/html Accept: image/gif 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.

30 4. Cookies: Weitere Beispiele Domain Path Content Expires Secure joes-store.com / Cart= ; :00 No 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. No Browser darf das Cookie an jeden Server zurücksenden

31 4. Cookies: Weitere Beispiele Domain Path Content Expires Secure aportal.com / Prefs=Stk:SUNW;Spt:1860M :00 No 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.

32 4. Cookies: Weitere Beispiele Domain Path Content Expires Secure sneaky.com / UserID= :59 No 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 Domain 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 f wurde, und so ein Nutzerprofil erstellen. (Im Extremfall reicht dazu eine Banner, das 1*1 Pixel groß ist!)