Ajax und Web 2.0 Sicherheit

Werbung
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
Herunterladen