FYI @codinghorror, das Chrome-Team hat immer noch nichts unternommen.
Die Situation für Chrome bleibt weiterhin gestört. Wir können das trivial beheben, indem wir unseren Spam-Schutz-Honeypot durch eine Art Proof of Work ersetzen.
Schließen für weitere 2 Monate
Das Chrome-Team scheint daran interessiert zu sein, das Problem zu beheben, benötigt jedoch hier Protokolle:
https://bugs.chromium.org/p/chromium/issues/detail?id=987293
Ich werde morgen versuchen, welche zu sammeln. Falls jemand schneller ist als ich, seid ihr meine Helden – markiert diesen Beitrag.
EDIT … habe ihnen die Protokolle gesendet.
@codinghorror Das läuft bei Google im Kreis. Sie sagen, das Verhalten sei beabsichtigt und sie hätten keine Möglichkeit, zuverlässig zu erkennen, ob ein Textfeld sichtbar ist oder nicht.
Die allgemeine Antwort lautet: „Es ist für einen Bot trivial, dies zu umgehen, also was ist der Sinn?
Ok, aber ich möchte, dass es ein ziemlich komplexer Proof of Work ist. Gibt es vorhandenen Code, den wir verwenden können?
Ja, ich kann da etwas zusammenstellen, das wird auf jeden Fall besser sein als unser aktuelles System. Unser aktuelles „Proof of Work“-System ist „einen String umdrehen“.
Ich habe viel zu viel Zeit damit verbracht, über dieses Problem nachzudenken, also habe ich beschlossen, es endlich abzuhaken:
Gemäß diesem Commit ist das Problem des Originalposters (OP) hier „behoben“:
Die Lösung ist etwas komplex und umfasst zwei Teile, über die ich froh bin, dass ich sie umgesetzt habe:
Ich habe die Logik für Honeypot und Challenge erheblich verschärft.
Ich habe eine nur auf Clientseite wirkende Workaround-Lösung für einen Chrome-Bug bei der Autocomplete-Funktion hinzugefügt. Ich bin damit einverstanden, da dies den Server-Protokollablauf nicht verändert.
Bisher haben wir unseren Honeypot und die zufällige Challenge-Zeichenkette für alle Kontoerstellungen auf der Seite wiederverwendet. Das machte das Skripting zur Erstellung von Konten ziemlich trivial, da man einfach einen Wert einmal hartcodieren musste.
Die neue Implementierung weist jedem einzelnen Benutzer eine eindeutige Zeichenkette zur Validierung zu, die an den Cookie-Speicher (in unserem sicheren Session-Speicher) gebunden ist. Diese Zeichenkette läuft nach einer Stunde ab.
Das bedeutet, dass Sie beim Skripten solcher Vorgänge regelmäßig neue Aufrufe tätigen müssen, um zwischen den Anfragen brandneue Challenges und Honeypots zu erhalten, und nicht einfach Konten im Sturmlauf erstellen können.
Der Workaround unter Punkt 2 besteht einfach darin, ein INPUT-Element, bei dem Chrome verwirrt ist, auszutauschen und durch ein INPUT-Element vom Typ „text“ zu ersetzen, bei dem Chrome keine Verwirrung zeigt.
Insgesamt habe ich nicht das Gefühl, dass Punkt (2) es einem „generisch“ programmierten Bot, der Konten auf unbekannten Seiten erstellt, erleichtert. Zum einen müsste der Bot den Chrome Webdriver verwenden, unseren gesamten Ember-Code analysieren und dann einem sehr spezifischen Ablauf folgen. Diese Hürde ist sehr niedrig und nichts im Vergleich zu den neuen, pro Benutzer rotierenden Challenges.
Was die Hinzufügung eines Proof-of-Work-Mechanismus angeht, möchte ich noch etwas warten. Nicht, weil es besonders schwer zu implementieren wäre, sondern eher, weil ich nicht auf der Suche nach dem schnellsten SHA1-Algorithmus sein möchte, um ihn bei Bedarf an den Client zu senden.
Ich lasse diesen Thread noch etwas offen, damit andere meine Lösung bestätigen können, dass sie das Problem behebt. Ich werde ihn in einer Woche schließen.