Zustandsändernde GET-Endpunkte sind die Hauptquelle ungewollter Aktionen automatisierter Clients

Hypothese

RFC 9110 definiert GET, HEAD, OPTIONS und TRACE als sicher, also im Wesentlichen lesend, und besagt, dass der Zweck dieser Unterscheidung darin liegt, automatisierten Abrufprozessen und Pre-Fetching zu erlauben, ohne Sorge vor Schaden zu arbeiten. Als Beispiel dient page?do=delete, und die Besitzerin oder der Besitzer der Ressource wird verpflichtet, solche Aktionen zu unterbinden, wenn sie über eine sichere Methode eintreffen; gewarnt wird vor Nebenwirkungen, wenn automatisierte Prozesse ein GET auf jede gefundene URI ausführen. Der Abschnitt zur Idempotenz fügt hinzu, dass idempotente Anfragen nach einem Kommunikationsfehler automatisch wiederholt werden können. Jeder Client, der sich spezifikationskonform verhält, vom Browser-Prefetch bis zum Mail-Gateway, das Links zur Prüfung verfolgt, führt daher aus, was ein GET auslöst.

Die Hypothese: In einer Anwendung mit über GET ausgelösten Aktionen wird der Anteil an "Geisteraktionen" – definiert als Audit-Einträge ohne zugehörige interaktive Sitzung – von solchen automatisierten Clients dominiert und sinkt gegen null, sobald dieselben Aktionen POST erfordern (eine GET-Landingpage mit einem POST-Formular oder ein Einmal-Token, das nur per POST eingelöst wird).

Vorhersage

Ausführungen über GET ausgelöster Aktionen zeigen, in einer Rate weit über jener von POST-ausgelösten Aktionen auf derselben Site: User-Agents von Scannern und Prefetchern, Anfragen innerhalb von Sekunden nach Zustellung einer E-Mail sowie Anfragen ohne das Session-Cookie der Anwendung. Nach der Umstellung auf POST sinkt die Geisterrate für diese Aktionen; verbleibende Duplikate an POST-Endpunkten lassen sich auf Wiederholungsversuche von Clients ohne Idempotenzschlüssel zurückführen, nicht auf Prefetcher.

Vorgeschlagener Test

1. Jede über GET erreichbare Aktion inventarisieren: Routing-Tabellen, E-Mail-Vorlagen mit Aktionslinks, Admin-Shortcuts.
2. Für einen festen Zeitraum pro Ausführung protokollieren: Methode, User-Agent, Vorhandensein eines Session-Cookies, Referrer sowie Zeit seit dem Versand der E-Mail mit dem Link.
3. Ausführungen anhand dieser Signale als interaktiv oder automatisiert einstufen; die Geisterrate je Aktion berechnen.
4. Die Hälfte der Aktionen (zufällig ausgewählt) auf POST mit einem Bestätigungsschritt umstellen; den Rest für denselben Zeitraum unverändert lassen.
5. Geisterraten je Aktion vor und nach der Umstellung sowie zwischen den beiden Gruppen vergleichen; Anzahlen berichten, nicht nur Raten, und die identifizierten Client-Typen auflisten.

Status

Es wird kein Ergebnis behauptet. Zu den Störfaktoren zählen gleichzeitig eingeführte Bot-Sperren oder Ratenbegrenzungen, Änderungen an der Token-Gültigkeitsdauer sowie automatisierte Clients, die JavaScript ausführen und Formulare absenden, welche die Umstellung nicht aufhalten würde.