Instrumentierung

Proof of Work beweist, dass Aufwand aufgewendet wurde. Es beweist nicht, was ihn aufwendete. Ein entschlossener Angreifer mit einer Farm echter Browser kann sich billig durch Rätsel mahlen. Instrumentierung ist die zweite Schicht, die diese Lücke schließt: sie beweist, dass die Arbeit in einem echten Browser geschah.

Wie es funktioniert

Bei jeder Anfrage generiert Caputchin ein frisches, einmaliges JavaScript-Programm und führt es im Browser des Besuchers aus. Das Programm beansprucht Maschinerie, die nur ein echter Browser hat, und meldet zurück, was es beobachtet hat:

• Browser-API-Sonden, die prüfen, dass echte Browser-Funktionalität vorhanden ist und sich korrekt verhält.
• Berechnungsketten bitweiser Integer-Operationen.
• DOM-Arithmetik, die Bäume von Elementen baut, die Werte liest, die die Layout-Engine für sie berechnet, und sie wieder abbaut.

Der Trick ist eine Asymmetrie: eine echte Rendering-Engine produziert die richtigen Antworten fast umsonst, während eine Headless- oder skriptgesteuerte Laufzeit diese Operationen stubst, sie falsch implementiert oder sie für Tempo überspringt. Die Diskrepanz verrät den Besucher.

Content-Security-Policy

Weil das Programm eval im Browser des Besuchers ausführt, muss die Seite, die dein Widget einbettet, 'unsafe-eval' in ihrer script-src-Content-Security-Policy erlauben. Dafür gibt es keinen Fallback: ist 'unsafe-eval' blockiert, kann das Programm nicht laufen und die Verifizierung schlägt fehl. Kann deine Policy es nicht erlauben, schalt die Instrumentierung für den Key auf seiner Sicherheit-Seite aus, was die Anforderung auf Kosten der Automatisierte-Browser-Erkennung fallen lässt (Proof of Work und jedes verlangte Spiel laufen weiter). Sieh dir Spiel-Sandboxing für die vollständige Host-Seiten-Policy an.

Warum es sich mit Proof of Work paart

Die zwei Schichten decken die blinden Flecken der jeweils anderen ab. Proof of Work allein kann von echten Browsern billig gemined werden; Instrumentierung allein könnte von einem Skript gefälscht werden, das die Arbeit nie tut. Zusammen erhöhen sie die Kosten auf zwei unabhängigen Achsen: Proof of Work beweist Aufwand, Instrumentierung beweist Umgebung.

Verschleierung

Weil das Programm zum Besucher ausgeliefert wird, könnte ein motivierter Angreifer es studieren und versuchen, die Antworten vorzuberechnen. Um das schwerer zu machen, ist das Programm verschleiert. Die Sicherheit-Seite eines Keys stellt eine Verschleierungsstufe bereit: sie hochzudrehen macht das Programm schwerer zu reverse-engineeren, auf Kosten von mehr serverseitiger CPU. Dieselben Signale stützen die Option Automatisierte Browser blockieren, die erkannte Headless- und WebDriver-Clients rundheraus ablehnt.

Eine ehrliche Grenze

Instrumentierung ist nicht narrensicher. Stealth-Browser patchen die Verräter, nach denen sie sucht, und die Prüfungen selbst vermerken, dass sie geschlagen werden können. Sie ist eine Schicht unter mehreren, am stärksten, wenn sie mit Proof of Work und dem Rest der Sicherheits-Einstellungen eines Keys gestapelt ist.