Ajax und Web 2.0 Sicherheit Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de Einige Ei i generelle ll F Fragen zu Web-Sicherheit Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 2 Angriffsziele Ausspähen von Zugangsdaten O PIN, TAN von Online Bankverbindungen O Passwörter beliebiger Zugänge Finanzielle Ziele Verhaltens-Ziele Überwachungs-Ziele Schädigungs-Ziele Modifikation von Transaktionsdaten O Anderer Betrag bei einer Überweisung O Anderes Konto bei einer Überweisung Installation von Mal- und Spyware O Ausspionieren von Daten O Gewinnen von Benutzer Benutzer-Profilen Profilen O Kontrolle von Benutzer-Verhalten O Überwachung nach lokalen Gepflogenheiten als illegal angesehener Inhalte Bsp: China: Deutschland: US & EU: Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de Systemkritische Äußerungen NS Gedankengut Copyrighted Material 3 Abgrenzung Viele Sicherheitsthemen im Web haben nicht direkt mit Ajax zu tun haben O Pakete mitschneiden O Pakete P k t fälschen fäl h O TCP Spoofing O DNS Spoofing O Social Engineering O Replay Attacken O ... Probleme tauchen bei Ajax Anwendungen auf haben aber nichts mit Ajax zu tun Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de Ajax Probleme betreffen neue Technologie(anwendung) Generell: Javascript – CSS – DOM – Browser – HTML – Server Probleme O Cross Site XHR O Cross Site CSS O Cross Site Scripting und dynamic Javascript O Bookmarklet Problematik Web 2.0 Probleme sind meist soziale Probleme des "Mitmach" Modells O Multiple Identitäten O Identitäts-Diebstahl O Fake Reputation O Content Protection / Screen Scraping 4 Beispiel Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 5 Beispiel Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 6 Capabilities des Angreifers g ((1)) Den Surfer eine Webseite des Angreifers laden lassen Effekt 1: Javascript des Angreifers kommt zur Ausführung O Frage: Was kann das schlimmstenfalls anstellen? O Thema: Zugriff auf Client Ressourcen Cookies und damit Session-Codes, Passwörter etc. Formularinhalte und damit PINs, TANs etc. Andere offene Seiten oder Frames Bsp: Die andere Seite ist die Amazon Credit Card Number Eingabe Effekt 2: Surfer glaubt sich auf anderer Seite O Bsp: B PIN angegeben, b d da jja auff B Bankseite k it bi bin Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 7 Capabilities des Angreifers g ((2)) Den Content Provider zu einem Einbinden eigener Scripte verleiten O Durchaus realistisches Szenario angesichts des Chaos bei Ajax Toolkits O Problem: Scripte haben maximale Rechte auf der Seite Den Content Provider zu einem Setzen von Links verleiten O Dadurch gleichzeitig geladene Seiten / Frames des Angreifers O Kein Problem: Da Same-Origin Sandbox Eingabe spezielle formatierten Inputs O Dadurch Input als Code ausgeführt, sog. Injection Attacke Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 8 Sicherheit Si h h it bei b i mobilem Code Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 9 Sicherheitsmodelle für mobilen Code Mobiler Code O Ausführbare Datei, die vom Server geladen wird O Bsp: Java, ActiveX, Javascript, VBScript O Problem besteht seit längerem 3 Modelle, die sich bei Java und ActiveX etabliert haben 1. Sandbox 2. Signierter Code 3 Policy Files 3. Modell von Javascript: Same Origin Sandbox Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 10 1. Sandbox Security Manager Mobiler Code läuft innerhalb einer Sandbox Class Loader Sandbox verhindert Zugriffe auf lokale Ressourcen Byte Code Verifier O Bsp: Kein Plattenzugriff O Bsp: Kein Zugriff auf Rechner außerhalb der Domäne, von der Code bezogen Probleme O Zu weitgehend Bsp: Keine clientseitige Persistenz Bsp: Kein sinnvoller Zugriff auf Dritt-Ressourcen O Kein kontrolliertes Durchbrechen möglich Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 11 2. Signierter Code Code kann signiert werden Signierter Code erhält weitergehende Rechte Probleme O Weiß dann, wer mich geschädigt hat, kann Schaden aber nicht verhindern O Steht und fällt mit Identitätsprüfung durch die PKI-Institutionen Damit: Vertrauen in (viele) Drittinstitutionen O Unklar, was die weitergehenden Rechte genau sein dürfen Bsp: M$ darf Platte lesen, lesen Sun sogar formatieren ?!? O Nicht sinnvoll praktikabel Bsp: Powerdown ActiveX Control eines Hobbyprogrammierers Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 12 3. Policy Files User kann feingranular steuern, steuern welche Files welche Rechte erhalten Freigabe nach individueller Einschätzung und Anforderung möglich Sehr flexibel Probleme O Ist nicht zero install O User ist mit kompetenter Entscheidung meist überfordert O Policy Files nicht einfach zu editieren Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 13 Javascript: Same Origin Sandbox Same Origin Sandbox Javascript auf einer Seite von Site X hat Lese / Schreib-Rechte nur auf Seiten die selber wieder von Site X stammen Kontrolliertes Durchbrechen der Sandbox O Firefox: Benutzerkontrollierte Erweiterung mit Mehrfachbestätigung "Remember Decision" - Feature Signierter Code Registry Eigenschaften O Explorer: Benutzerkontrollierte Erweiterung mit Einmalbestätigung Z Zonenmodell d ll Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 14 Javascript: Same Origin Sandbox Kein Zugriff auf lokale Ressourcen Scripts, die von unterschiedlichen Domänen geladen wurden können nicht aufeinander zugreifen Bsp: Auslesen des Formularinputs einer Seite von Fremddomäne nicht möglich Unterschiedliche Domänen bedeutet O Protokoll ist verschieden (http != https) O Port ist verschieden O Ein Script von Rechnername, Rechnername ein anderes von IP Adresse geladen Dh: Browser wertet DNS nicht aus O Unterschiedliche Subdomänen O Redirections R di ti Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 15 Javascript: Same Origin Sandbox ISP-Anomalität ISP Anomalität O www.myisp.com/dave/script1.js und www.myisp.com/john/script1.js können aufeinander zugreifen O Keine Sandbox zwischen verschiedenen Usern bei ISP-Lösungen auf 1 Maschine document.domain Property O Problem: www.bsp.com und wiki.bsp.com können nicht interagieren O Lösung: Beide Skripts setzen document.domain = "bsp.com" O Aber: Nur eine Verkürzung der bereits vorhandenen eigenen Domäne möglich Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 16 Javascript: Same Origin Sandbox Aber: Javascript hat volle Rechte, Rechte auch wenn das Script selber von einer anderen Domäne geladen wurde (sog. Cross Domain Script) Fazit: O Achtung beim Einbinden von Javascript von fremden Domänen ! Beispiel: Google Maps Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 17 Sicherheitsprobleme Si h h it bl bei Mashup / Remixing Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 18 Mashup / Remix Architekturen Remix by y Client Server Secundary Server Client Remix erfolgt im Client Client selber mixed vor Darstellung Erfordert Cross Domain Scripting Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 19 Mashup / Remix Architekturen Remix by y Server Secundary Server Server Remix erfolgt im Server Server liefert Remix Inhalt an Client aus Erfordert Zugang von Server zu Secund. Server Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de Client 20 Explorer Zonenmodell Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de Benutzergesteuerte Erweiterung 21 Explorer Zonenmodell O Nicht gegen DNS Spoofing gefeit O Entscheidung für End User problematisch Bsp: www.deutschebankinchina.ag zulassen ? Benutzergesteuerte Erweiterung O Analoge Kritik O Explorer speichert einmal durchgeführte Entscheidung unklar für welche Wiederholungsfälle genau unklar wie rückgängig machen der Entscheidung Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 22 Firefox Privilege g Manager g Anfordern weiterer Rechte über den PrivilegeManager Wichtig: Nach Gebrauch das Recht sofort wieder entziehen ! Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 23 Firefox Privilege g Manager g Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 24 Firefox Privilege g Manager g Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 25 Firefox Privilege g Manager g Bei signierten Skripten keine Nutzer-Anfrage Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 26 Web Spoofing Angriff g Benutzer ist auf anderem Server als er glaubt Einfache Variante O Angewählte URL ist nicht angezeigte URL O Mehrere simple Tricks zum Einstieg O Anschließend Angriff auf den einen, kompromittierten Server Komplexe Variante O Ab der ersten Kompromittierung bewegt sich User in kompletter Parallelwelt O Location Zeile ist Teil der Webseite statt des Browsers (und falsch) O Page Source ist Teil der Webseite statt des Browsers (und falsch) O https htt Anzeige A i und d "Schloß" "S hl ß" ist i t Teil T il der d Webseite W b it statt t tt des d Browsers B (und ( d falsch) f l h) O Alle Schritte des Users (Klicks, Anwahl neuer Location, jede Interaktion) wir mitgeloggt Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 27 Web Spoofing Fehlen von Trusted I / O Probleme des Web-Spoofing Web Spoofing waren O Angezeigte Location-Zeile ist nicht tatsächliche Location-Zeile O Angezeigte Page Source ist nicht tatsächliche Page-Source O Eingegebene URL Daten sind nicht umgesetzte URL Daten Prinzipielles Problem O Wir haben auf einem Computer kein Trusted I / O O Jedes Bildschirmausgabe kann simuliert sein Gedankenexperiment des duplizierten PDA O Schlafe ein O Am A morgen liegen li 2 PDA PDAs am N Nachttisch htti h O Welchem gebe ich mein Passwort ein ? Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 28 Covert Channel Website A O Synchronisiert Zeit auf ein Raster O Bsp: Warten, bis Zeit auf volle Sekunde steht O Dann entweder 100 ms busy wait oder nichts Website B O Synchronisiert Zeit bis (ganz kurz) nach volle Sekunde O Dann Zeitmessung und Überprüfung der Rasterung Ergebnis O Zeit steht auf 105 ms oder auf 5 ms O Hardware-Abhängigkeit H d Abhä i k it (Hyperthreaded (H th d d versus Dual D l Core) C ) O Ergibt einen Covert Channel zwischen Frames – sogar zwischen Browsern unterschiedlichen Fabrikats Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 29 Covert Channel Voraussetzung für Angriff O Website des Angegriffenen nutzt Skript-Library des Angreifers O Ist aber bei Ajax Toolkits doch denkbar O Zeilen tarnen als Rate Throtteling Effekt O Langsamer Informationskanal zwischen Sites O Reicht aus, um Kreditkartennummer zu kommunizieren O Empfangende Seite codiert diese in URL und stellt neue Anfrage an Server Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 30 Covert Channel Informationskanal O zwischen zwei abgeschotteten Bereichen eines OS O bei minimaler Kooperation beider Bereiche ist Kommunikation möglich O trotz Beobachtung durch Dritte (OS) Weitere Beispiele O Steganographie O Port Knocking O Modulation von Ressourcen Ressourcen-Verbrauch Verbrauch Bsp hier: CPU Last Bsp auch: Outgoing Ports offen halten oder schließen je nach Port mod 2 Covert Channel können prinzipiell nicht vermieden werden ! Setzen aber minimale Kooperation der kommunizierenden Bereiche voraus Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 31 XHR Unterliegt analogen Restriktionen wie Variablenzugriff Von einem Skript, das von Server X stammt kann nur ein XHR auf Server X durchgeführt werden Logische Fortsetzung der entsprechenden Restriktion auf Skripte Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 32 XPC Native Wrapper (1) Firefox hat 2 Privilegien Privilegien-Stufen Stufen O HTML: Unterliegt Sandbox Restriktion O Chrome: Keine Restriktionen Zusätzlich: XPCOM Zugriff Chrome Privileg-Stufe von Browser-Erweiterungen genutzt Problem: O Code unter Chrome Chrome-Privilegien Privilegien greift auf Dokument Dokument-Eigenschaften Eigenschaften zu O Dokument hat Eigenschaft (und die Setter / Getter davon) modifiziert O Code kann nicht vertrauen, daß document.title Setter noch andere S it Seiteneffekte ff kt hat h t O Dokument zwingt Extension zu Ausführung von Code unter Chrome Privileg Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 33 XPC Native Wrapper (2) Seit FFox 1.5: 1 5: XPC Native Wrapper O Garantiert Zugriff auf unmodifizierte Properties, Getter, Setter (next slide!) Methoden sofern solche zur Grunddefinition des Objekts gehören O Verhindert direkten Zugriff auf neu hinzugefügte Properties O Zugriff auf modifizierte / neue Properties erfolgt über doc.wrappedJSObject.prop statt doc.prop Daher: Unsicherer Zugriff wird im Code explizit gemacht Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 34 Setter und Getter Seit Javascript 1 1.5: 5: var Eigenschaft; Eigenschaft = getter function(Werte){ /*.*/ return(Wert); } Eigenschaft = setter function(Werte){ /*.*/ Eigenschaft = Werte; return(true | false); } window.onload setter = function(x) { alert(x); } window.onload getter = function() { return true; } Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 35 XPC Native Wrapper (3) Deep: Return Wert einer Funktion eines wrapped Objekts ist wieder wrapped und damit safe Shallow: Return Wert einer Funktion eines wrapped Objekts ist nicht mehr wrapped und damit potentiell unsafe Implizit: Von System automatisch gewrapped, wenn Chrome Skript auf User Level Objekt zugreift Bsp: Kein xpcnativewrappers=no gesetzt in Installation der Extension Explizit: Programmierer bewirkt einen expliziten XPC Native Wrapper Deep und shallow kann angefordert werden Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 36 XPC Native Wrapper (4) Explizit - shallow new XPCNativeWrapper(content, "document"); Explizit Deep var winWrapper = new XPCNativeWrapper(content, "document", "getSelection()"); var docWrapper = new XPCNativeWrapper(winWrapper.document, "title"); return docWrapper.title == winWrapper.getSelection(); Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 37 Injection Attacken (1) Techniken zur Generierung dynamischer Seiten erhalten Daten vom Client Diese werden eingebaut in O SQL Queries O HTML Seiten O PHP Seiten O Javascript Programme Problem O Programmierer macht implizite Annahmen über Semantik und Syntax O Wenn diese verletzt, dann unerwünschte Effekte O Bsp B 1: 1 U Unerwartete t t Eingabe Ei b iin ein i F Formular l O Bsp 2: Erzeugen von URL-Teilen, Query-Anteilen oder http Headern durch Angriffsprogramme statt durch Formulare und Webseiten Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 38 Injection Attacken (2) Bsp 1: HTML Injection O Angriff: Username Hal</br>lo </table></body></html> O Effekt: Username bewirkt einen Zeilenumbruch oder gar kompletten Layoutabbruch Bsp 2: SQL Injection O Php-basierte Query: SELECT * FROM USERS WHERE user = '$uname'; O Username: '; DROP TABLE USERS - O Resultat: SELECT * FROM USERS WHERE user=''; DROP TABLE USERS - - ' Vermeidung: O Typ-Prüfung O Eingabe-Validierung Ei b V lidi O Escapen von Quotes (DB-abhängig) Auch: Eingeschleuster Code läuft auf dem Server Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 39 Zugriffs-Sicherung von Ajax Zugriffs-Beschränkung und Authentisierung Vertraulichkeit Techniken O SSL Wenn Basisseite SSL, dann auch XHR SSL Serverseitig aufwendig O Tochter-Techniken Mit anderer Technik eine Sessionid besorgen p nutzen Diese dann entsprechend O Architektur Firewall <-> Application-Server <-> Firewall <-> DB Restriktionen bei DB-User O Netzbasierte Sicherheit Firewall mit MAC / IP Filtering Geht nicht immer Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 40 Cross Site Scripting Definition: O Webseite stammt aus einer Domain und O lädt Skript von einer anderen Domain Wichtig: O Cross Domain XHR: O Cross Domain Scripting: Wird durch Sandbox verhindert Wird durch Sandbox nicht verhindert Grund: O Möchte von einer fremden Site ein Skript beziehen können F Frage: Ist I t das d ein i guter t Grund G d? Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 41 Kritik an Cross Site Scripting Es gibt keinen guten Grund für Cross Site Scripting Ausnahme: Durchbrechen der bei XHR zu eng gesetzten Sandbox Cross Site Scripting hat viele Gefahren O Bsp: Fremdes Script zerstört Aussehen meiner Web Site völlig O Bsp: Fremdes Script liest Werte aus Formularen aus O Bsp: Fremdes Script füllt Werte in Formulare ein oder modifiziert sie O Keine Kontrolle über die Auswirkungen Beachte: O Einbau eines Cross Site Scripts entspricht Preisgabe der Rechte üb die über di betroffene b t ff Seite S it ! Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 42 Durchbrechen von Cross Site Schranken Universal Browser Read Permissions Signierter Code Geringe Sicherheitsanforderungen Covert Channel bereits besprochen Server Proxy Architektur siehe Server-side Remixing Script Tag Hack (Javascript on demand) Fragment Identifier Hack neu ! Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 43 Script Tag Hack Beziehe von einem fremden Server ein Script Dieser liefert Javacode, den ich vor Ausführung nicht prüfen kann (zumindest ohne Browser Modifikation) Annahmen: O Server liefert JSON Daten O Diese wurden von Server noch verpackt in eine Funktion, die der Client in der URL dem Server gesandt hat (als eine Art Callback) O Damit führt der Client sein Client-seitige g Callback Funktion auf die Daten des Servers aus O und bindet damit Inhalte einer fremden Seite bei sich ein Erfordert aber Kooperation des Servers (JSON, Callback Packaging) A Anwendung: d Yahoo Y h Maps M Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 44 Fragment Identifier Hack Seitenaufbau: Hauptseite plus IFRAME IFRAME kann von unterschiedlicher Domäne geladen werden Erhalte somit zwei Komponenten Diese können wechselseitig nicht aufeinander zugreifen Aber: Fragment Identifier in der URL kann wechselseitig modifiziert werden Idee: O Hauptseite von eigenem Server, IFRAME von externem Server laden O IFRAME kann auf externen Server voll zugreifen und O seinen eigenen Fragment Identifier modifizieren (ohne page reload) O Hauptseite kann auf diesen zugreifen O Dadurch D d h üb über F Fragmentt Id Identifier tifi ein i Kommunikationsprotokoll K ik ti t k ll realisierbar li i b Erfordert aber Kooperation der beiden Partner Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 45 Bookmarklet - Trick Bookmarklets sind javascript: <CODE> URLs in einer Bookmark Laufen unter der Berechtigung der aktuell angezeigten Seite Können remote Code zur Seite hinzufügen Dieser könnte Cookies stehlen Aber: Bookmarklet kann vorher die Cookies löschen (und nachher wieder erzeugen) Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 46 Cross Site CSS CSS das von anderer Site kommt CSS, Probleme O Unsichtbarkeit von Elementen O Verdeckung von Elementen O Content Elemente Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 47 Cross Site Request Forgery Angreifer setzt einen IMG IMG-Link Link auf eine Seite, Seite zu der der Client autorisiert ist Link enthält vollständige Parameter für eine illegale Transaktion <img src="http://bank.example/withdraw?account=bob&amount=1000000&for=mallory"> Abwehr dagegen: O O O O O O Logoff Feature anbieten und nutzen Geringe Gültigkeitsdauer für Authentisierungs-Cookies vorsehen Serverseitig den Referer-Header prüfen Neben Cookie noch einen weiteren FORM-abhängigen Code als Hidden Field versenden Cookie auch im Hidden Field erwarten (cookie double submission) Statt GET nur ein POST als Service verfügbar machen Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 48 Module Tag Problem: O Javascript kann alle DOM Elemente überschreiben Vorschlag von Douglas Crawford: Module Tag O Neues HTML Element <module src="url"> O Inhalte von separater URL geladen O Kein Überschreiben von Modulen möglich O Kommunikation nach außen über wohldefinierte API gesichert Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 49 Json Request Problem: O XHR unterliegt der Sandbox-Restriktion (sinnvoll, da sonst Cookies stehlbar) Vorschlag von Douglas Crawford: JSONRequest O Unterliegt nicht der Sandbox O Sendet keine Cookies mit O Prüft, ob Antwort serialisierte Daten enthält (JSON Format) Derzeit erste Implementierungen (u (u. a a. Diplomarbeit bei Prof Prof. Cap) O Da Sicherheitsmodell geändert, nur als Browser-Erweiterung möglich Clemens H. Cap http://wwwiuk.informatik.uni-rostock.de http://www.internet-prof.de 50