CSS von Drittanbietern ist nicht sicher

Gepostet am 27. Februar 2018

Vor ein paar Tagen wurde viel über einen in CSS eingebauten 'Keylogger' geredet .

Einige Leute riefen nach Browsern, um das Problem zu „reparieren“. Einige Leute gruben etwas tiefer und sahen, dass es nur Websites betraf, die in React-ähnlichen Frameworks gebaut wurden, und zeigten mit dem Finger auf React. Aber das eigentliche Problem ist zu denken, dass Inhalte von Drittanbietern „sicher“ sind.

Bilder von Drittanbietern

<img src="https://example.com/kitten.jpg">

Wenn ich das Obige hinzufüge, vertraue ich example.com. Sie können dieses Vertrauen missbrauchen, indem sie die Ressource löschen, mir einen 404 geben und meine Website kaputt aussehen lassen. Oder sie ersetzen die Kätzchendaten durch etwas viel weniger Angenehmes.

Die Wirkung eines Bildes ist jedoch auf die Inhaltsbox des Elements selbst beschränkt. Ich kann versuchen, den Benutzern zu erklären: "Hier ist etwas Inhalt von example.com, wenn es eklig wird, ist es ihre Schuld, nicht meine", und hoffe, dass sie mir glauben. Aber es kann sicherlich keine Auswirkungen auf Dinge wie Passwortfelder haben.

Skript von Drittanbietern

<script src="https://example.com/script.js"></script>

Im Vergleich zu Bildern haben Skripte von Drittanbietern viel mehr Kontrolle. Wenn ich das Obige einfüge, übergebe ich die example.comvolle Kontrolle über meine Website. Sie können:

Seiteninhalt lesen/ändern.
Überwachen Sie jede einzelne Benutzerinteraktion.
Führen Sie rechenintensiven Code aus (z. B. Cryptocoin Miner).
Stellen Sie mit den Cookies des Benutzers Anfragen an meinen Ursprung und leiten Sie die Antwort weiter.
Ursprungsspeicher lesen/ändern.
… sie können so ziemlich machen, was sie wollen.

Das 'Ursprungsspeicher'-Bit ist wichtig. Wenn das Skript IndexedDB oder die Cache-Speicher-API stört, kann der Angriff über den gesamten Ursprung fortgesetzt werden, selbst nachdem Sie das Skript entfernt haben.

Wenn Sie Skripte von einem anderen Ursprung einbinden, müssen Sie ihnen und ihrer Sicherheit absolut vertrauen.

Wenn Sie von einem fehlerhaften Skript getroffen werden, sollten Sie alle Websitedaten mit dem Clear-Site-Data-Header löschen .

CSS von Drittanbietern

<link rel="stylesheet" href="https://example.com/style.css">

CSS ist in seiner Macht viel näher an einem Skript als an einem Bild. Wie ein Skript gilt es für die gesamte Seite. Es kann:

Seiteninhalte entfernen/hinzufügen/ändern.
Stellen Sie Anfragen basierend auf dem Seiteninhalt.
Reagieren Sie auf viele Benutzerinteraktionen.

CSS kann den Ursprungsspeicher nicht ändern, und Sie können keinen Kryptocoin-Miner in CSS erstellen (wahrscheinlich, vielleicht, ich weiß es nicht), aber böswilliges CSS kann immer noch viel Schaden anrichten.

Der Keylogger

Beginnen wir mit dem, der viel Aufmerksamkeit erhält:

input[type="password"][value$="p"] {
  background: url('/password?p');
}

Das Obige löst eine Anfrage an aus, /password?pwenn das Attribut der Eingabe mit valueendet p. Tun Sie dies mit jedem Charakter, und Sie erfassen eine Menge Daten.

Browser speichern den vom Benutzer eingegebenen Wert valuestandardmäßig nicht im Attribut, daher hängt der Angriff von etwas ab, das diese Werte synchronisiert, z. B. React.

Um dies abzumildern, könnte React nach einer anderen Möglichkeit suchen, Passwortfelder zu synchronisieren, oder Browser könnten Selektoren einschränken, die mit dem Wertattribut von Passwortfeldern übereinstimmen. Dies würde jedoch ein falsches Sicherheitsgefühl erzeugen. Sie würden die Dinge für einen bestimmten Fall lösen, aber alles andere offen lassen.

Wenn React auf die Verwendung des data-valueAttributs umgestellt hat, schlägt die Schadensbegrenzung fehl. Wenn die Website die Eingabe in ändert type="text", damit der Benutzer sehen kann, was er eingibt, schlägt die Risikominderung fehl. Wenn die Website <better-password-input>den Wert dort als Attribut erstellt und verfügbar macht, schlägt die Risikominderung fehl.

Außerdem gibt es viele andere CSS-basierte Angriffe:

Verschwindender Inhalt

body {
  display: none;
}

html::after {
  content: 'HTTP 500 Server Error';
}

Das Obige ist ein extremes Beispiel, aber stellen Sie sich vor, der Drittanbieter würde dies für einen kleinen Prozentsatz Ihrer Benutzer tun. Es wäre schwierig für Sie zu debuggen und das Vertrauen der Benutzer zu untergraben.

Subtilere Hacks könnten nur gelegentlich die Schaltfläche „Kaufen“ entfernen oder die Absätze in Ihrem Inhalt neu anordnen.

Inhalte hinzufügen

.price-value::before {
  content: '1';
}

Oh Scheiße, deine Preise sind gerade gestiegen.

Bewegte Inhalte

.delete-everything-button {
  opacity: 0;
  position: absolute;
  top: 500px;
  left: 300px;
}

Nehmen Sie diese Schaltfläche, die etwas Schweres bewirkt, machen Sie sie unsichtbar und platzieren Sie sie über etwas, auf das der Benutzer wahrscheinlich klicken wird.

Zum Glück zeigt die Seite wahrscheinlich zuerst einen Bestätigungsdialog, wenn die Schaltfläche etwas wirklich Schweres tut. Das ist in Ordnung, verwenden Sie einfach mehr CSS, um den Benutzer dazu zu bringen, auf die Schaltfläche "Ja, ich bin sicher" zu klicken, anstatt auf die Schaltfläche "Oh Gott, nein".

Stellen Sie sich vor, Browser hätten versucht, den „Keylogger“-Trick abzuschwächen. Angreifer könnten einfach eine Nicht-Passwort-Texteingabe auf der Seite nehmen (vielleicht ein Suchfeld) und sie über die Passworteingabe platzieren. Jetzt sind sie wieder im Geschäft.

Lesen von Attributen

Es sind nicht nur Passwörter, um die Sie sich Sorgen machen müssen. Sie haben wahrscheinlich andere private Inhalte in Attributen:

<input type="hidden" name="csrf" value="1687594325">
<img src="/avatars/samanthasmith83.jpg">
<iframe src="//cool-maps-service/show?st-pancras-london"></iframe>
<img src="/gender-icons/female.png">
<div class="banner users-birthday-today"></div>

All diese können von CSS-Selektoren anvisiert werden und als Ergebnis kann eine Anfrage gestellt werden.

Interaktionen überwachen

.login-button:hover {
  background: url('/login-button-hover');
}

.login-button:active {
  background: url('/login-button-active');
}

Hover und Aktivierungen können an einen Server zurückgesendet werden. Mit einer moderaten Menge an CSS können Sie sich ein ziemlich gutes Bild davon machen, was der Benutzer vorhat.

Text lesen

@font-face {
  font-family: blah;
  src: url('/page-contains-q') format('woff');
  unicode-range: U+71;
}

html {
  font-family: blah, sans-serif;
}

In diesem Fall wird eine Anfrage gesendet, wenn die Seite enthält q. Sie können viele davon für verschiedene Buchstaben erstellen und auf bestimmte Elemente abzielen. Schriftarten können auch Ligaturen enthalten, sodass Sie damit beginnen können, Zeichenfolgen zu erkennen. Sie können sogar Schrifttricks mit Bildlaufleistenerkennung kombinieren , um noch mehr über den Inhalt zu erfahren.

Inhalte von Drittanbietern sind nicht sicher

Dies sind nur ein paar Tricks, die mir bekannt sind, ich bin mir sicher, dass es noch viele mehr gibt.

Inhalte von Drittanbietern haben in ihrer Sandbox einen großen Einfluss. Ein Bild oder ein Sandbox-Iframe hat eine ziemlich kleine Sandbox, aber Skript und Stil sind auf Ihre Seite oder sogar den gesamten Ursprung beschränkt.

Wenn Sie befürchten, dass Benutzer Ihre Website dazu verleiten, Ressourcen von Drittanbietern zu laden, können Sie CSP als Sicherheitsnetz verwenden, um einzuschränken, woher Bilder, Skripte und Stile abgerufen werden können.

Sie können auch Subresource Integrity verwenden , um sicherzustellen, dass der Inhalt eines Skripts/Stils mit einem bestimmten Hash übereinstimmt, da er sonst nicht ausgeführt wird. Danke an Piskvorrr auf Hacker News für die Erinnerung!

Wenn Sie an weiteren Hacks wie diesem interessiert sind, einschließlich weiterer Details zu den Scrollbar-Tricks, lesen Sie den Vortrag von Mathias Bynens aus dem Jahr 2014 , den Vortrag von Mike West aus dem Jahr 2013 oder den Artikel von Mario Heiderich et al. aus dem Jahr 2012 (PDF). Ja, das Zeug ist nicht neu.