Achtung! / Attention!

Diese Seite ist Teil unser alten Internetpräsenz, die nicht weiter gepflegt wird. Besuchen Sie auch unsere neue Präsenz unter http://ig.cs.tu-berlin.de.
This page is part of our former website that is not being maintained anymore. You may want to visit our new website at http://ig.cs.tu-berlin.de.

1 Einleitung *

2 Customer Profiling und eCommerce *

3 Techniken der Datenerfassung *

3.1 WWW-Server Logs *

3.2 Cookies *

3.3 Java und JavaScript *

3.4 ActiveX *

3.5 Session Identity *

3.6 Hidden fields *

3.7 Session Files *

3.8 Plug-ins *

3.9 Common Gateway Interface — Serverseitiges skripten mit CGI *

4 Der Browser — Fenster zur Welt mit Bruchgefahr *

4.1 Java / Javascript *

4.2 ActiveX *

4.3 Browserfehler *

4.4 Browsereinstellungen *

5 Ausblick *

1. Einleitung

Primäres Ziel unternehmerischer Marketingaktivitäten ist, das Portfolio an Marketingmassnahmen möglichst zielgruppengerecht einzusetzen.

Neue Möglichkeiten im Rahmen der Informationstechnologie versetzen Unternehmen heute in die Lage, Marketing auf der Basis kundenindividueller in einer Kundendatenbank gespeicherter Informationen zu betreiben. Database Marketing, Data Warehousing und Data Mining als die wesentlichen Bestandteile des Customer Profiling sind in diesem Bezug die am meisten genannten Schlüsselbegriffe. Sie beschreiben im weitesten Sinne die Erfassung, Speicherung, Aus- und Verwertung kundenspezifischer Daten, um Aufbau und Management langjähriger, profitabler Geschäftsbeziehungen zu realisieren und zu sichern.

Die wesentliche Aufgabe im Rahmen des Customer Profiling besteht also darin, die für das jeweils fokussierte Problem relevanten Kundenprofile herauszufiltern. Customer Profiling kann als das Management einer Datenbank mit möglichst umfassenden, relevanten und aktuellen Daten über Kunden und Interessenten verstanden werden.

Die in den letzten Jahren rasch vorangeschrittene Entwicklung der Techniken zur Akquisition der Datenspur die ein Benutzer im Internet hinterläßt, nutzen kommerzielle Anbieter, um immer umfassendere und genauer auswertbare Datensammlungen anzulegen.

Schwerpunkt dieser Studienarbeit ist die deskriptive Darstellung verschiedener Techniken der nutzerspezifischen Datenerfassung.

Hierbei sollen den Datenschutz betreffende Problematiken dieser Thematik vernachlässigt.



Abbildung 1: Client-Server-Interaktion

2. Customer Profiling und eCommerce

2. Techniken der Datenerfassung

 

 

1. WWW-Server Logs

 

Bei jedem HTTP-Zugriff eines Clients (Browser) auf einen WWW-Server (Website) werden, da es sich bei HTTP um ein verbindungsloses Protokoll handelt, umfangreiche Informationen übertragen und je nach Typ des HTTP-Servers in eine oder mehreren log-Dateien geschrieben. Welche Informationen genau auf Serverseite erfaßt werden, hängt dabei stark von Art und Konfiguration des HTTP-Daemons ab.

Die Daten im einzelnen, auf die der Server durch Anfragen des Clients (HTTP-Request) Zugriff erlangen kann und die später zum Zwecke des Customer Profilings ausgewertet werden können, sind:

 

1. Hits

 

Die Anzahl der Anfragen werden für jedes Element einer Site protokolliert.

Hierbei ist auch ersichtlich, auf welchem Wege ein Besucher während einer Session die Site durchschreitet, welche Angebote und links wahrgenommen und verfolgt werden.

 

2. Die IP-Adresse

 

ist der eindeutige Identifizierer eines Rechners (Hosts) im Internet. Auf dieser Einmaligkeit einer Netzadresse basiert das Internet Protokoll (IP) und der Austausch von Datenpaketen. Eine solche IP-Adresse muß nicht zwangsläufig auf Dauer immer dem selben Host zugeordnet sein, Internet-Zugangsprovider beispielsweise vergeben an die Rechner Ihrer meist privaten Kunden nach deren Einwahl in ihr Netz dynamische IP-Adressen, so daß es durchaus üblich ist, daß der Rechner eines Internet Nutzers heute eine andere IP-Adresse als morgen besitzt. Unternehmensnetze mit festen Verbindungen ins Internet hingegen vergeben an ihre Hosts in der Regel feste IP-Adressen.

Eine IP-Adresse besteht aus vier mit einem Punkt getrennten Zahlen im Bereich von 0 bis 255. In den Paketen, die ein Client über das Internet versendet um zum Beispiel mail abzuholen, eine Website zu besuchen oder Newsgroups zu lesen, ist diese IP-Adresse des Client-Rechners immer enthalten.

Namen wurden im Internet für den Menschen und dessen besserem Verständnis geschaffen, der Domain Name Service weist im Regelfall einer IP-Adresse immer eindeutig einem Namen zu und umgekehrt.

Ruft nun beispielsweise ein WWW-Client eine beliebige Website auf, so wird die IP-Adresse des Client-Rechners durch den HTTP-Dienst auf dem Server im Zugriffslogbuch (acces_log) vermerkt. Wird von Clientseite aus aber ein Proxy oder ein Masqueraded Network (z. B. mittels Router) zum Internetzugang verwandt, erscheinen von außen alle Rechner hinter diesen Hilfsmechanismen mit der selben IP-Nummer.

Eine IP-Adresse kann vielfältige Informationen über den Client-Rechner enthalten. Es gibt verschiedene Techniken, diese Informationen zu beschaffen:

 

1. Namensauflösung

 

Wie beschrieben kann so IP-Nummer nach Name aufgelöst werden. Namen können offenkundige Informationen über die geographische Herkunft der Client-Anfrage an den HTTP-Server ebenso enthalten wie persönliche oder andere Daten, die durch gewisse Schemata bei der Administration der Hostnamen Verwendung finden:

 

n11-rew.compaq.com Ein Host aus dem Compaq-Netzwerk

pD4B88C5A.dip.t-online.de Eine dynamische IP-Adresse aus dem t-Online Netzwerk

ns.eu.microsoft.com Ein Host aus dem europäischem Microsoft-Netzwerk

ppp196-96.rz.hu-berlin.de Ein Host über einen PPP-Einwahlzugang der Humboldt Uni in Berlin, möglicherweise die 196. Beantragung eines accounts im Jahre 1996

pinback.isdn.cs.tu-berlin.de Der Rechner des users pinback am Fachbereich Computer Science der TU in Berlin, Einwahl via ISDN. Vermutliche e-mail Adresse: pinback@cs.tu-berlin.de .

 

2. Traceroute

1. Cookies

 

1. Motivation

 

Da das im Internet verwendete HTTP (Hypertext-Transport-Protokoll) ein nicht-persistentes Protokoll ist, d.h. eine mittels HTTP entstandene Verbindung ist nicht anhaltend, ist es für den Web-Server nicht möglich, ohne Einsatz bestimmter Techniken, zwischen "Besuchern" einer Web-Seite zu unterscheiden, außer er kann diese irgendwie "markieren". Das wird erst durch das Speichern von Information im Browser bzw. Festspeicher (persistent cookies) des Clients ermöglicht.

 

2. Was sind Cookies?

 

Cookies sind ein Werkzeug zur Gewährleistung der o.g. Statusinformationen im WWW. Sie werden in die HTML-Information eingebettet, die zwischen Server und Client-Rechner ausgetauscht wird.

Ein Cookie ist ein Datensatz im ASCII-Format, der vom Web-Server generiert (z.B. durch cgi oder Java-Script) und dem Client-Rechner zum Speichern übergeben wird, sofern der Browser des Clients dies zuläßt. Dies erfolgt bei den beiden meist genutzten Browsern unter Windows in der Datei cookies.txt (Netscape Navigator) im Netscape-Verzeichnis bzw. im Verzeichnis \windows\cookies (Microsoft Internet Explorer).

In Cookies werden verschiedene Informationen, die während einer Online-Session gesammelt wurden, abgelegt.

Die meisten Cookies verweilen lediglich bis zum Beenden des Browsers auf der Clientseite und werden dann vernichtet. Eine zweite Art von Cookies, bekannt als persistent cookies, besitzt ein Ablaufdatum als Attribut und wird auf der Festplatte bis zu diesem gespeichert. Sie kann genutzt werden, um die Surfgewohnheiten des Users, durch Identifizierung bei Rückkehr auf eine Site, zu verfolgen.

Informationen über Herkunft der Verbindung, welche Web-Seiten man besucht existieren bereits im Web-Server log file und können ebenfalls zur Ermittlung von Surfgewohnheiten des Users dienen, Cookies machen es nur einfacher.

Ein Web-Server kann als Attribut den zugehörigen Domainnamen für den Cookie mitliefern, so daß jeder Server der selben Internet-Subdomain des sendenden Rechners während einer Seitenanfrage den Cookie übermittelt bekommt. Diese Möglichkeit nutzen größere Sites, welche mehrere Server betreiben, um ihre Cookies zu koordinieren. Der Domainpfad kann also nicht an Subdomains versendet werden, die außerhalb der Subdomain des erstellenden Servers liegen.

 

3. Einsatzgebiete

 

Der Zweck des Einsatzes von Cookies ist die Identifizierung eines Clients, um möglicherweise individuell angepasste Web-Seiten zu erstellen und zu übermitteln.

 

1. Online-Shopping

 

Onlineshopping-Anbieter benutzen Cookies um den Warenkorb eines Clients zu realisieren. Beim ersten Besuch einer Shopping-Site wird mittels eines Cookies eine ID-Nummer für den Warenkorb angelegt. Mit Auswahl eines jeden gewünschten Artikels, wird dieser dem Warenkorb zugefügt. Nach Beenden des Shoppings listet die Kontrollseite alle Artikel im Warenkorb, welcher mit dem Cookie verknüpft ist, auf. Ohne Cookies müßte sich der Käufer alle Artikel merken und diese in die Kontrollseite (z.B. Bestellformular) eingeben, oder einen Artikel nach dem anderen bestellen.

Eine andere Methode ist das Versenden eines mit Artikelnummer versehenen Cookies für jeden bestellten Artikel. Der Browser sendet die für alle gewünschten Artikel betreffenden Cookies mit der Anfrage der Kontrollseite, welche diese zum Erstellen der Einkaufsliste verwendet.

 

2. Angepaßte Homepages

 

Ein weiteres Gebiet ist das Erzeugen von maßgeschneiderten Homepages. Ein Cookie wird für jedes Objekt, welches auf der Homepage erwartet wird, gesendet. Mit jeder Anforderung der angepaßten Homepage schickt der Browser die Cookies mit, um dem Server mitzuteilen welche Objekte er anzeigen soll. Ohne Cookies würde der Server bei jedem Besuch eine Identifizierung des Users fordern müssen. Außerdem wäre das Speichern der benutzerspezifischen Einstellungen für jeden Besucher auf dem Server unumgänglich.

 

 

4. Customer Profiling

 

Cookies werden auch als Hilfsmittel zum Verfolgen von Surf- und Kaufgewohnheiten von individuellen Web-Usern eingesetzt. Diese Möglichkeit ist Hauptursache für das Enstehen heftiger Kontroversen weltweit.

Auf einer oder auf einer Gruppe von Webseiten innerhalb einer Subdomain können Cookies verwendet werden, um nachzuvollziehen, welche und wie oft Webseiten besucht werden.

Auf einer Vielzahl von Anbieterseiten, die von einer Marketing-Site versorgt werden, können Surfgewohnheiten auf allen Anbieterseiten verfolgt werden. Hierbei schließen sich Marketingunternehmen mit einer Vielzahl von Anbietern zusammen, um ihre Anzeigen zu präsentieren. Die Anbieter-Sites setzen lediglich ein <IMG>-TAG auf ihren Webseiten, um Images (Werbebanner) anzuzeigen, die Werbung des Marketingunternehmen enthalten. Das TAG zeigt nicht auf eine Image-Datei des Anbieters der Seite, sondern enthält die Server-URL (Uniform Resource Locator) des Marketingunternehmens und bezieht die URL des Anbieters mit ein. So wird beim Öffnen der Webseite des Anbieters, das eingeblendete Werbebanner tatsächlich vom Server des werbenden Unternehmens angefragt. Dieses sendet einen Cookie mit der Werbung und jener wird beim Besuch einer jeden Webseite zurückgeliefert, die irgend ein Werbebanner des Unternehmens enthält.

So ist es werbenden Unternehmen, die auf einer großen Anzahl von Webseiten ihre Banner setzen lassen möglich, die Surfgewohnheiten eines Users von Seite zu Seite innerhalb aller Anbieterseiten nachzuvollziehen. Es ist nicht möglich festzustellen, was ein User auf den Seiten der Anbieter macht, jedoch welche und wie oft er sie besucht. Diese Informationen lassen auf Interessen des Nutzers schließen und werden verwertet, um gezielt Werbung auf dieser Basis zu machen.

4. Ablauf

DOMAIN_NAME ist ein Attribut, das die Adresse des Servers enthält, welcher den Cookie verschickt hat und eine Kopie desselben empfängt, wenn der Browser des Clients eine erneute Anfrage stellt. Sein vorgegebener Wert (Default-Wert) entspricht dem Server, falls er nicht explizit in der Set-Cookie-Zeile gesetzt wird. DOMAIN NAME kann auch auf eine Subdomäne, die den Web-Server beinhaltet, verweisen, so daß mehrere Web-Server innerhalb der selben Subdomäne den Cookie empfangen können. Dies ermöglicht größeren Websites mehrere Server zu koordinieren, z.B. angenommen DOMAIN NAME ist definiert als www.meinedomain.com, dann könnten alle Server eins.www.meinedomain.com, zwei.www.meinedomain.com o.ä. den entsprechenden Cookie empfangen. Das Attribut DOMAIN NAME ist begrenzt, d.h. nur Hosts innerhalb der bestimmten Subdomäne können dafür einen Cookie für diese generieren und der Subdomänenname muß mindestens zwei oder drei dots enthalten. Zwei dots sind nötig falls die top-level-domain mit .COM, .EDU, .NET, .ORG, .GOV, .MIL, oder .INT endet. Drei dots sind für jede andere Domäne nötig.

2. Java und JavaScript
1. Java

 

Java ist eine 1990 von Sun entwickelte objektorienterte Programmiersprache mit C++ - änlichen Strukturen.

Die hervorragende Eigenschaft von Java ist es, plattformunabhängig eingesetzt werden zu können.

Das zweite Hauptargument für den Einsatz der Java-Technik ist das später erläuterte Sicherheitskonzept. Ein weiterer Vorteil ist die einfache Nutzung von Java- oder JavaScript-Programmen — es entfällt jegliche Installations- oder Wartungstätigkeit.



Abbildung 2

1. Java-Applets

Motivation für die Verwendung von JAVA-Applets im Internet ist der Gedanke, das Netz mit möglichst wenig Datentransfer zu belasten, da die Bandbreite der Datenleitungen vor allem für den privaten Endanwender derzeit noch den Flaschenhals der Informationübertragung darstellt. Statt große Datenblöcke vom Server zum Client zu übertragen, besteht für viele Anwendungen die Möglichkeit ein Programm zum Client zu übermitteln, der diese Daten auf der Client Maschine errechnet; als Beispiel sollen hier grafische Daten genannt sein, die herkömmlich als sperriges Image-Format übermittelt werden.

Für Internetanwendungen werden kleine Java-Programme (Applets) vom Server zum Client übertragen und laufen dort auf der sogenannten Virtual Machine (VM) des Browsers ebenfalls plattformunabhängig ab, um Websites dynamischer, benutzerfreundlicher und interaktiver gestalten zu können.

Java-Applets werden direkt im HTML-Dokument mit dem <Applet> - TAG referenziert.

Ein ByteCode wird von einer sogenannten Virtual Machine (VM) unabhängig vom Betriebssystem zur Laufzeit auf der Client Maschine interpretiert.

3. Java-Applications

Java-Applikationen hingegen sind vom Browser unabhängig laufende Programme, die die VM des jeweiligen Betriebssystems nutzen und auch vollen Zugriff auf dieses genießen können.

 

2. JavaScript

1995 wurde aus der Sprache LiveScript von Netscape JavaScript entwickelt.

JavaScript als leistungsfähige Scriptsprache ist darauf ausgerichtet, WWW-Seiten flexibler zu gestalten. Funktionen und Objekte können vom Programmierer direkt in den HTML-Code eingebunden werden. So kann auf Eingaben des Benutzers unterschiedlich reagiert werden.

Da JavaScript sehr eng mit HTML verknüpft ist benötigt man einen Browser, der JavaScript unterstützt.

JavaScript dient als eine Art Bindeglied zwischen verschiedenen Techniken wie Java-Applets, Plug-In-Objekten, HTML etc. .

JavaScript zeichnet ein sehr geringer Entwicklungsaufwand aus, als Entwicklungsumgebung genügt im einfachsten Fall ein Texteditor.

 



Abbildung 3

 

4. Java und JavaScript — Zwillinge die keine sind

 

Java und JavaScript können sich nicht ersetzen. Nur an wenigen Stellen gibt es Überschneidungen, die dem Entwickler dann die Wahl zwischen beiden Techniken lassen.

 

JavaScript ist eine klassische Interpretersprache. Der Code wird menschenlesbar direkt in die HTML-Seite geschrieben und dann vom Browser interpretiert.

Java-Sourcecode muß im Gegensatz dazu vor Gebrauch kompiliert werden. Dazu wird eine Entwicklungsumegbung benötigt, die einen Compiler zur Verfügung stellt.

Im Falle eines Java-Applets wird der vom Compiler erzeugte Byte-Code via TCP/IP und Internet vom Server zum Client übertragen und dann im Browser durch die VM interpretiert werden.

Java-Applets werden durch ein eigenes TAG (<APPLET>) aufgerufen. Das kompilierte Programm befindet sich auf Serverseite in einer separaten Datei und endet mit .class .

 

5. Die Sicherheit

Sowohl bei Java-Applets als auch bei JavaScript gibt es restriktive, der Sicherheit dienende Beschränkungen. Java-Applets dürfen von der Grundidee her nicht auf Systemresourcen zugreifen. Somit sollen beispielsweise ungewollte oder nicht nachvollziehbare Schreib/Lesetätigkeiten ausgeschlossen werden.

In diesem Zusammenhang wurde der Begriff "sandbox" geprägt, der aussagt, daß sich Java ausschließlich in Ihrem "Sandkasten", dem durch die VM vom Rest des Systems abgetrennten Bereich, aufhalten, agieren und diesem auch nicht entfliehen können. Für JavaScript gilt dies uneingeschränkt.

Java-Applets können diese Beschränkungen allerdings in Abhängigkeit von einem ausgeklügelten Zertifizierungskonzept, daß es dem Nutzer, analog zu den im Abschnitt ActiveX beschriebenen Verfahren, überläßt, ob er einem signierten Applet bzw. dessen Absender vertraut und es vollem Zugriff auf Systemresourcen erlaubt, umgehen.

 

Mit der Umsetzung des Java Delevopment Kits (JDK) in der Version 1.2. sollen verschiedene Sicherheitsstufen eingeführt werden, in denen eine differenzierte Freigabe von Systemresourcen ermöglicht wird. Derzeit ist dies nur mit einem Plug-In für Netscape 4.x bzw. mit einem ActiveX-Control für MSIE ab 4.x realisierbar.

Allerdings ermöglichen auch schon die vorangegangenen JDK-Versionen dedizierten Zugriff auf einige Betriebssystemdienste, beispielsweise können Druckjobs ausgeführt werden.

 

7. ..und Ihre Lücken

Da mit Java und JavaScript Programme erstellt werden, die auf dem Rechner des Benutzers ausgeführt werden, gab es immer wieder Bedenken in Hinsicht auf die Sicherheit dieser beiden Techniken. Häufig werden die Programme ausgeführt, ohne daß der Benutzer dies zur Kenntnis nimmt. Java und JavaScript besitzen aber wie erwähnt auf Grund Ihrer Konstruktion gute Mechanismen, die den Anwender vor Mißbrauch schützen sollen.

 

In der Vergangenheit erwies sich allerdings des öfteren ein Mangel in der Qualität der Virtual Machines, die von Browser- und Betriebssystemherstellern in mehr oder minder genauer Anlehnung an die von Sun veröffentlichten JDK-Sourcen entwickelt wurden und werden. Aber auch die VM Suns wies nachweislich Schwächen auf.

 

JavaScript bietet zwei Möglichkeiten mit Hilfe des Browsers als "Interface" auf systeminterne Daten Zugriff zu erlangen:

 

1. Cookies

2. ActiveX

 

ActiveX ist die Antwort Microsofts auf Java. Im Gegensatz zu Java ist ActiveX kein klar abgegrenztes System, sondern eine Sammlung bereits existierender Microsoft Technologien.
ActiveX sind Objekte des Microsoft Component Object Models (COM).
Das bereits kompilierte Programm, das sogenannte ActiveX-Control wird im Internet vom Server zum Client übertragen und wird dort, schneller als Java aber nicht plattformunabhängig, sondern nur auf Microsoft-Betriebssystemen ausgeführt.

Ansonsten ist die Motivation ähnlich wie bei Java zu verstehen, die Datenlast soll dem Netz entnommen werden und soweit möglich als Rechenleistung auf die Client Maschine verlagert werden; Websites können dynamischer, benutzerfreundlicher und interaktiver gestaltet werden, weit über die Möglichkeiten eines Java-Applets hinaus.

Diese fast uneingeschränkten Möglichkeiten eines ActiveX Controls werden allerdings mit einem schwächeren Sicherheitskonzept erkauft.

Faktisch ist ein ActiveX Control beispielsweise ein VisualBasic - oder C++ - Executable, das als .ocx vom Server geladen wird, sich auf dem Client in der registry einträgt und die Möglichkeit hat, durch OLE auf alle Betriebssystemresourcen zugreifen zu können.

Als Schnittstelle zum Betriebssystem verwenden ActiveX-Controls die Windows API, somit ist nicht wie bei Java ein Experte vonnöten, um Anwendungen zu entwickeln.

 

1. Sicherheit durch Vertrauen

 

In Bezug auf die Sicherheit werden keine technischen Konzepte wie zum Beispiel das Sandbox-System Javas eingesetzt, stattdessen setzt Microsoft auf die Nachvollziehbarkeit der Herkunft des heruntergeladenen Codes durch Code-Signierung.

Die von Microsoft selbst entwickelte Authenticode Technologie wird hierbei zur Code-Signierung eingesetzt. Diese Technologie beruht auf bekannten Verfahren der digitalen Signatur und erlaubt den Nachweis der Echtheit des übertragenen Codes, sowie die Identifikation des Absenders. Aus dem zu signierenden Code wird über einen Hash Algorithmus eine Art "Fingerabdruck" des Codes erstellt, der mit dem Schlüssel des Herstellers verschlüsselt wird und dann die Signatur des Codes bildet. Der Web-Client bildet den Fingerabruck des empfangenen Codes nach, entschlüsselt die mitgelieferte Signatur mit dem öffentlichen Schlüssel des Herstellers und vergleicht die Ergebnisse. Die notwendigen Identitäts- und Schlüsselinformationen werden in X.509 v3 konformen Zertifikaten gemeinsam mit dem Code und der Signatur an den Client übertragen, wobei die Echtheit des Herstellerzertifikates wiederum durch eine digitale Signatur der ausstellenden Zertifizierungsstelle nachgewiesen werden kann.

Im Endeffekt aber muß sich der Nutzer einfach entscheiden, ob er dem Anbieter eines ActiveX Controls trauen will oder nicht. Microsoft erlaubt auch unterschiedliche "Stufen des Vertrauens", die sich auf einzelne Funktionalitäten, Anbieter oder sogar Server beziehen können, und die je nach Wertigkeit einen mehr oder weniger vollständigen Zugriff des ActiveX-Controls auf die Betriebssystemresourcen erlauben.

 

Durch ActiveX hat der Entwickler alle Freiheitsgrade programmtechnischer Ausdrucksmöglichkeiten und volle Kontrolle über die Ressourcen der Zielumgebung.

Bei Ausführung eines mit allen Rechten ausgestatteten ActiveX-Controls besitzt dieses genau die Zugriffserlaubnis des gerade angemeldeten Benutzers auf das System.

Innerhalb von ActiveX wurde wie erwähnt auf restriktive Mechanismen von Sicherheitssystemen verzichtet.

 

3. Session Identity

 

Der einfachste Weg zur Gewährleistung von Statusinformationen ist das Anhängen an die URL. Angenommen es soll eine Identifizierungsnummer (ID) über mehrere unterschiedliche Seiten erhalten werden, dann wäre ein Anhängen dieser an die URL, entweder durch Voransetzen eines Fragezeichens (QUERY_STRING Variable) oder eines Slashs (PATH_INFO Variable) durchfürbar.

 

http://myserver.org/cgi-bin/form?12345

 

http://myserver.org/cgi-bin/form/12345

 

Ist das Speichern zwei unterschiedlicher Werte nötig, z.B. Name und ID, kann man beide Methoden verwenden.

 

http://myserver.org/cgi-bin/form/Bob?12345

 

In diesem Fall wird Bob in PATH_INFO und 12345 in QUERY_STRING gesichert.

 

Das Erhalten von Information durch URLs ist nützlich, da es keinen Einsatz von Formularen fordert. Zustände können durch Anhängen von Statusinformationen an alle URLs innerhalb eines Dokumentes aufrechterhalten werden.

Ist z.B. eine der vorher genannten URLs gegeben, so muß man die Seite lediglich folgendermaßen referenzieren, um den Status zur nächsten zu übergeben.

print "<a href=\"/cgi-bin/form?$ENV{'QUERY_STRING'}\">Next page</a>\n";

 

Der Einsatz von Umgebungsvariablen hat den Nachteil, daß es eine Obergrenze, sowohl für die Länge der URL, als auch für die Speichergröße der Umgebungsvariablen existiert. Für große Datenmengen ist der Einsatz von Umgebungsvariablen nicht zufriedenstellend.

5. Hidden fields

 

In der HTML-Programmierung werden Formulare verwendet, die vom Web-Surfer ausgefüllt werden können, um Informationen zur Serverseite zu übermitteln. Die meisten der erzeugten Felder dieser Formulare sind für den Client sichtbar, es kann jedoch auch eine separate Klasse von "unsichtbaren" Feldern vom HTML-Programmierer benutzt werden, um weitere Daten, wie z.B. die Identität des Users oder Session-Informationen zu halten und zu folgenden Formularen weiterzuleiten. Diese Art der Übermittlung von Informationen durch "hidden fields" kann als simpelste Methode des Statuserhaltes einer HTTP-Sitzung angesehen werden.

 

Der HTML Code für ein "hidden field" würde ungefähr so aussehen:

 

<INPUT TYPE="HIDDEN" NAME="customerid" VALUE="c245-345">

 

Durch den Wert (VALUE) eines HTML-Form-Input-Felds vom Type HIDDEN können

Statusinformationen zwischen Browser und Server ausgetauscht werden

 

Das Konzept ist ähnlich wie bei Umgebungsvariablen, welche Größenbeschränkungen unterliegen. Anstatt Umgebungsvariablen an die zur URL gehörigen Referenzen anzuhängen, wird die Statusinformation im Formular durch Nutzen der <input type=hidden> Information eingebettet.

 

Nehme man z.B. an, es existiert ein Abfrage mittels zwei Formularen. Wenn man den "Submit"-Button im zweiten Formular anklickt so wird die Übertragung von Informationen aus beiden gewünscht.

 

Der erste Teil könnte folgendermaßen aussehen:

 

<form method=POST>

<p>Enter your name: <input name="name"><br>

Enter your age: <input name="age"></p>

 

<p><input type=submit></p>

</form>

 

Wenn man "Submit" klickt werden die Werte für name und age zum CGI-Programm transferiert. Das CGI-Programm sollte das zweite Formular mit der durch das <input type=hidden> Tag eingebetteten Information zurücksenden.

 

 

<form method=POST>

<!–Statusinformation aus dem ersten Formular -->

<input type=hidden name="name" value="Corwyn">

<input type=hidden name="age" value="21">

 

<!–Zweites Formular -->

<p>What kind of cola do you like? <input name="cola"><br>

Do you like soccer? <input type=radio name="soccer" value="yes"> Yes

<input type=radio name="soccer" value="no"> No<br>

Have you ever been to Highland Park, NJ?

<input type=radio name="NJ" value="yes"> Yes

<input type=radio name="NJ" value="no"> No</p>

 

<p><input type=submit></p>

</form>

 

Wenn dieses zweite Formular eingereicht wird, so erfolgt eine Übermittlung von Informationen aus dem ersten und zweiten Formular.

Auch wenn diese Methode die Einschränkung von Umgebungsvariablen umgeht, so verursacht sie wieder neue Einschränkungen: Man kann "hidden fields" nur verwenden, falls die Applikation Formulare verwendet. Jedoch benutzen nicht alle CGI-Applikationen, die Statusinformationen benötigen, Formulare. Eine Formularverwendung ist manchmal unerwünscht, da sie unnötige Komplikationen in der CGI-Programmierung verursachen können.

 

"Hidden fields" können durch die Option "View Source" im Browser ausfindig gemacht werden.

Diese versteckten Daten sind zugänglich und können manipuliert werden, bevor ein Formular an ein CGI-Skript weitergereicht wird.

 

Während der initialen Verbindung zum Server enthält die gesendete HTML-Seite den identifizierenden "hidden field"-Wert innerhalb der FORM-Seite. Eine nun folgende, vom Browser an diesen Server ausgehende HTTP-CGI-Anfrage wird so auch das "hidden field" enthalten. Das korrespondierende Common Gateway Interface beim Server kann dasselbe "hidden field" an den Browser zurückgeben. So dient es als "session identifier" zwischen einer Applikation (z.B. Warenkorb) und dem Browser.

7. Session Files

 

Die beiden vorher beschriebenen Methoden ermöglichen keine Erhaltung von Statusinformationen über mehrere Sitzungen (sessions). Angenommen, es wird während einer Sitzung der Browser beendet, so verliert man sämtliche Daten, die vorher in Formulare eingegeben wurden. Entsprechendes gilt für ungewollte Systemabstürze oder Sitzungsunterbrechungen, die das erneute Ausfüllen sämtlicher Formulare unumgänglich machen würde.

 

Das Anlegen von Dateien sog. session files ermöglicht das Umgehen dieser Schwierigkeiten und versetzt die Serverseite Statusinformationen über mehrere Sitzungen hinweg zu erhalten. Anstatt Informationen in Umgebungsvariablen oder Formularen zu speichern, werden sie in Dateien auf dem Server gespeichert. Eine Applikation hat Zugang zu bereits erhalten Informationen miitels Zugriff auf die entsprechenden session files. Bei diesen Dateien kann es sich um Textdateien, Verzeichnisse von solchen oder um Datenbanken handeln.

 

Der Gebrauch von session files erfordert dennoch das Weiterreichen von identifizierenden Attributen des session files von Zustand zu Zustand der Applikation durch Einsatz einer der vorher beschriebenen Methoden. Jedoch ist das Wiederherstellen von Statusinformationen durch das Erinnern an die Sitzungs-ID nach Verlassen einer vorangegangen Web-Sitzung möglich.

 

Beispiel: Eine vorteilhafte Methode zum Erstellen einer (fast) eindeutigen Sitzungs-ID ist der Gebrauch der Zeitfunktion. In Perl sähe der Code folgendermaßen aus:

 

$sessionID = time;

 

Durch Anfügen einer Prozeß-ID auf UNIX-Rechnern könnte Eindeutigkeit erreicht werden.

 

$sessionID = time."-".$$;

 

 

Der Einsatz von session files birgt ein gewisses Risiko, da theoretisch ein User eine Sitzungs-ID eines anderen schätzen könnte und so in der Lage wäre, dessen Statusinformationen zu ermitteln. Jedoch ist es möglich, durch mehrere Schritte zu sichern, daß lediglich der autorisierte User Zugang zu seinen eigenen Informationen hat. Es ist von Wichtigkeit, Sitzungsinformationen einzubeziehen, auch wenn sie nach Terminierung des CGI-Programmes gelöscht werden.

 

Angenommen die erste Seite einer Applikation ist einen Login-Applikation, welche nach dem Benutzernamen und einem Passwort fragt. Nach Eingabe und Bestätigung der der beiden Informationen durch den User fügt die Applikation diese dem session file hinzu und generiert eine assoziierte Sizungs-ID. Um Zugang zu dieser oder zum entsprechenden session file zu gewährleisten, ist eine Wiederbestätigung von Benutzername und Passwort nötig.

 

Einen anderer Nachteil des Einsatzes von session files ist das Hinterlassen von nicht zugeordneten Dateien auf dem Server. Nachdem ein User begonnen hat, ein Formular mit Daten zu füllen, kann eine CGI-Applikation nicht erkennen, ob der User die Eingabe unterbrochen bzw. beendet hat. So oder so wird die Datei auf dem Server gehalten. Auch dieser Nachteil läßt sich beheben, indem man z.B. ein Programm erzeugt, welches regelmäßig das Säubern von Dateien, die älter als ein Tag sind, veranlaßt.

 

8. Plug-ins

 

Plug-ins erweitern die Funktionen des Browsers, indem Sie beispielsweise den Browser als Interface für eine für ihn eigentlich nicht zu verarbeitende Datei nutzen und nach einmaliger Installation das entsprechende Format immer automatisch nach Abruf vom Server verarbeiten.

Eine andere Möglichkeit des Einsatzes ist der integrierte Einsatz, um zum Beispiel die Kommunikation zwischen einer C++ - Anwendung, dem Browser und HTML-integriertes JavaScript zum Zwecke einer Expertensystem gestützten Hilfsfunktion für den Anwender zu gewährleisten.

 

Das Sicherheitskonzept, welches die Möglichkeiten zum Mißbrauch des Web-Browsers einschränkt, erstreckt sich nicht auf die Aktivitäten dieser Zusatzmodule, denen praktisch keinerlei Beschränkungen auferlegt sind.

 

9. Common Gateway Interface — Serverseitiges skripten mit CGI

Bereitstellen von HTML Formular Menüs für Bemerkungen des Nutzers über Ihren Server und der zugehörige CGI Dekoder.

1. Der Browser — Fenster zur Welt mit Bruchgefahr

 

Neben den genannten Möglichkeiten, auf herkommlichem Wege Daten über den Besucher einer Website zu sammeln, erlauben fehlerhaft programmierte Anwendungen das Ausspähen, Verändern oder Löschen hochsensibler Nutzerinformationen, im schlechtesten Fall den vollen Zugriff auf den gesamten Festplatten-Datenbestand und Kontrolle über das Betriebssystem. Dies geschieht im Regelfall durch Mißbrauch der Java, JavaScript oder ActiveX — Funktionalitäten der Browser.

Die Security Support Seiten von Netscape und Microsoft bezüglich Ihrer Browser-Produkte müssen beinahe täglich aktualisert und Patches zur Behebung der gröbsten Mängel bereitgestellt werden, ist jedoch ein Fehler bereinigt, tritt meistens schon der nächste auf.

Bis dato wies jede Browsergeneration erhebliche Sicherheitsmängel auf, der daraus für den individuellen Nutzer entstandene Schaden läßt sich in keiner Weise abschätzen. Es muß davon ausgegangen werden, daß dies auch in Zukunft weiter so der Fall sein wird.

Daher scheint eine Betrachtung der diesbezüglichen Möglichkeiten nicht vernachlässigbar und auch für spätere Schlußfolgerungen nicht ohne Bedeutung zu sein. Die im folgenden genannten Fallbeispiele geben an dieser Stelle nur einen kleinen und unvollständigen Einblick in die schnellebige Welt des Kreislaufs Sicherheitslücke finden ó Sicherheitslücke schließen.

Aber auch jenseits des Einsatzes genannter Technologien weisen Browser sicherheitsrelevante Fehler auf, die abschließend in zwei Beispielen Erwähnung finden.

 

 

2. Java / Javascript

 

1. Sohr Java Vulnerability
   

Betrifft: Netscape 4.0 und höher, die von Microsoft verwendete VM scheint nicht betroffen zu sein.

 

Problem: Ein Fehler in Suns Java Virtual Machine (VM). Java-Applets, die nicht digital signiert sind und vom Anwender spezielle Rechte zugebilligt bekommen haben, dürfen eigentlich nicht auf die Festplatte eines Computers zugreifen - sie sollen in einer abgeschotteten Umgebung laufen, in der sie keinen Schaden anrichten können. Sun hat dieses Konzept "Sandbox" getauft. Die Implementierung scheint aber einen Bug zu enthalten, der auch nicht-signierten Applets erlaubt, die Sandbox zu verlassen. Ein Demo-Applet soll in der Lage sein, ohne Warnhinweis Dateien auf der Festplatte zu löschen. Sun und Netscape haben nach Sohrs Angaben bereits bestätigt, daß es sich um einen schwerwiegenden Implementierungsfehler handelt, und arbeiten an Bugfixes.

 

Lösung: Deaktivieren von Java

 

2. The Injection Bug
   

Betrifft: Navigator 3.x und Communicator 4.0 — 4.7, des Communicator 4.5 Betaversionen

 

Problem: Verwalter von besuchten Sites können durch den Injection bug das Surfverhalten des Users nachvollziehen, Cookieinformationen und Verzeichnis- bzw. Dateinamen vom Rechner des Users ermitteln, auch wenn präzise Annahmen über das System des Nutzers gemacht werden müssen. Das Bestimmen des Inhaltes von Dateien sowie das Löschen dieser sind nicht möglich.

 

Lösung: Da der Bug auf JavaScript basiert, ist er durch Deaktivieren dieses Features zu vermeiden.

 

4. The Frame-Spoofing Vulnerability
   

Betrifft: alle Navigatorversionen, die Frames unterstützen, incl. Version 2.0 und später 3.x und Communicator 4.0 — 4.7, des Communicator 4.5 Betaversionen

 

Problem: Ein Frame eines angezeigten Framesets ist nicht Bestandteil der eigentlichen Webseite, sondern von Dritten dort plaziert und kann von diesen dazu mißbraucht werden, den User auf fremde Sites zu locken. Dies kann durch das Wählen eines Links in diesem Frame erfolgen. Weiterhin kann durch Versenden von Spam-Mail an einen JavaScript-aktivierten Mail-Client, wie dem Netscape Messenger, die selbe Absicht verfolgt werden.

 

Das Aktivieren der Frame-Spoofing-Attacke benötigt kein JavaScript, doch ist zum Erreichen des Ziels JavaScript notwendig (Die fremde Seite muß bereits geöffnet sein, um den User zum Klicken des Links zu verlocken).

 

Lösung: JavaScript deaktivieren

 

 

3. ActiveX

 

1. "DHTML Edit Control" Bug

 

Betrifft: Internet Explorer

 

Problem: Web-Site Administratoren könnten Informationen lesen, die ein User in das ActiveX-Control geladen hat. Außerdem ist es möglich, Dateien mit bekannten Namen von der Festplatte des Users kopiert werden.




5. Browserfehler

 

1. Microsoft

 

1. "MSHTML" Vulnerability

 

Betrifft: MS Internet Explorer 3.x, 4.01, 5 für Windows

 

Problem: Das "IMG SRC"-Tag (HTML-Befehl) kann benutzt werden, um Informationen über Dateien des Users zu erlangen, jedoch nicht zum Lesen oder Ändern dieser Dateien. Weiterhin besteht die Möglichkeit eines Web-Site Administrators Skripte zu starten und Rechte auf User-Rechnern zu erwerben, die normalerweise nur den vom User befugten Sites bewilligt werden. Auch Inhalte der Zwischenablage auf dem Rechner des Users können eingesehen werden.




2. AutoVervollständigen

 

Betrifft: Internet Explorer 5 für Windows

 

Problem: Das AutoVervollständigen-Feature speichert die vorherigen Eingaben von Webadressen, Formularen und Kennwörtern. Wenn in eines dieser Felder Informationen eingegeben werden, schlägt AutoVervollständigen mögliche Übereinstimmungen vor.Diese Daten werden verschlüsselt auf dem Rechner gehalten. Die Möglichkeit einer ungewollten Dateneingabe und -übermittlung ist vorbehalten.

 

3. Registriernummer

 

Betrifft: Internet Explorer 5 für Windows

 

Problem: Läßt ein Nutzer seinen MSIE 5 bei Microsoft offiziell registrieren, so erhält er nach Angabe seiner persönlichen Daten und dem Vorteil spezieller Supportleistungen eine eindeutige Identifikationsnummer. Danach wird bei jedem Besuch auf einer Microsft-Site diese Nummer an den Server übertragen.

 

 

 

3. Netscape

1. Preferences Bug

Betrifft: Netscape Communicator 4.0 bis 4.04 auf allen Plattformen

 

Problem: Möglichkeit für Web-Site Administratoren die Datei "prefs.js" zu lesen (unter Annahme des Pfadnamens). In dieser Datei können sich E-Mail-Adressen, Domainnamen und Paßwörter befinden.

 

Lösung: Deaktivieren der Option "Remember Password" in der Dialogbox zum Mailserver.

 

 

 

2. Smart Browsing

 

Betrifft: Netscape ab Version 4.06

 

Problem: Bei Aktivierung des "What's related" button wird ein "Schatten" aktiviert. "Smart Browsing" meldet von da an die URL jedes abgerufenen WWW-Dokuments einem Rechner von Netscape weiter, wo sie abgespeichert wird. "Smart Browsing" unterscheidet nicht zwischen Inter- und Intranetdokumenten. Dies heisst, dass auch die Http-Adressen vertraulicher Dokumente, die etwa vom Intranet- Server einer Firma abgerufen werden, letztendlich an Netscape gehen. Wenn man bedenkt, dass die betreffende Intranet-Adresse sehr häufig den Titel des Dokuments in sich trägt, dann ist dies doppelt gefährlich. Zum einen sammeln sich auf einem Rechner der Firma Netscape peu a peu die Inhaltsverzeichnisse diverser Firmen-Intranets an. Zum anderen können die Netscape-"Schatten" durch Einsatz eines sogenannten "Network Sniffer" auch durch Dritte abgefangen werden.

 

 

 

7. Browsereinstellungen

 

Die Browsereinstellungen geben dem Web-User ein mächtiges Werkzeug in die Hand, selbst zu bestimmen, welche Funktionen sein Browser im Netz ausüben soll und welche nicht. Er besitzt damit die Möglichkeit, ganz spezifisch ihm aus bestimmten Gründen nicht erforderliche erscheinende oder suspekte Features die vom Client ausgeführt werden, zu beschneiden bzw. auszuschalten.

Eine Funktion allerdings, die auf der einen Website nicht vonnöten ist, kann auf einer anderen wiederum unerläßlich schon zur einfachen Ansicht sein, so daß sich ein nicht einfach zu bewältigender Zwiespalt zwischen Sicherheitsaspekten und komfortablem Informationszugriff eröffnet.

Zudem verwenden heute alle größeren Web-Sites zumindest JavaScript und Cookies, weniger gebräuchlich aber ebenfalls verbreitet sind Java-Applets, wohin gegen ActiveX-Controls durch den noch großen Marktanteil des Netscape Browsers für den WWW-Nutzer eine weniger große Bedeutung haben.

Die Konfigurationsmöglichkeiten der zwei gebräuchlichsten Browser sollen hier kurz reflektiert werden.

1. Netscape Navigator 4.08 (letzte Browser stand-alone Version)

 

Die wichtigsten Einstellmöglichkeiten sind in folgendem Fenster konzentriert:



Abbildung 5: Erweiterte Einstellungen bei Netscape

Dies sind die Default - Einstellungen nach einer Erstinstallation des Browsers.

Wie zu sehen, sind alle Funktionalitäten zugelassen, mit der Ausnahme, daß bei Anmeldung auf einer FTP-Site nicht die im Browser eingetragene e-mail Adresse zur Authentifizierung verwendet wird.

Das Fenster an sich widerum besticht durch seinen einfachen und übersichtlichen Aufbau.

 

2. Microsoft Internet Explorer 5.0

 

Im Gegensatz zu Netscape verfolgt Microsoft das Konzept verschiedener Sicherheitsstufen. Durch einen Schieberegler kann der Nutzer verschieden definierte Zustände konfigurieren, wie sich der Browser im Netz verhalten soll.

Das Niveau differiert hier zwischen Sehr niedrig, Niedrig, Mittel und Hoch, kurze Erklärungen werden dem Anwender neben der Levelanzeige zur Verfügung gestellt.

Diese Einstellungen können dediziert für Internet und Intranet oder für verschiedene Sites vorgenommen werden.

 

 



Abbildung 6: Sicherheits-Schieberegler beim IE 5

 

Ein eingestelltes Sicherheitsniveau kann durch die Funktion "Stufe anpassen" detailliert in einer umfangreichen Liste den Benutzerwünschen angepaßt werden.

 



Abbildung 7: Erweiterte Sicherheitseinstellungen beim IE 5

 

 

 

 

 

 

 

In den erweiterten Einstellungen läßt sich das Verschlüsselungs- und Signierungskonzept anpassen.

 

 

 



Abbildung 8: Verschlüsselungsoptionen

 

3. Ausblick