Formulare gegen CSRF und automatisierten Missbrauch schützen
Einen geprüften PHP-Baustein einordnen und Schutzregeln vor der tatsächlichen Verarbeitung platzieren.
Zwei unterschiedliche Angriffe brauchen unterschiedliche Antworten
CSRF-Schutz soll verhindern, dass eine fremde Seite den Browser eines angemeldeten Menschen zu einer unerwünschten zustandsändernden Anfrage veranlasst. Automatisierter Missbrauch ist eine andere Frage: Ein Programm kann den vorgesehenen Weg selbst aufrufen und dabei sehr viele oder schädliche Anfragen erzeugen. Ein Token im Formular beantwortet deshalb nicht automatisch die Frage, ob eine Anfrage nützlich, berechtigt oder wirtschaftlich tragbar ist.
Wir betrachten zwei eigene fiktive Abläufe. In einer angemeldeten Serviceanwendung kann ein Kunde seine Mitteilungseinstellungen ändern. Daneben gibt es ein öffentliches Reparaturanfrageformular. Die Kontoeinstellung benötigt eine klare Bindung an die Sitzung und die erlaubte Aktion. Das öffentliche Formular braucht vor allem einen belastbaren Umgang mit Eingaben, Mengen und Bearbeitungsaufwand. Beide Abläufe dürfen dieselbe sorgfältige Oberfläche besitzen, haben aber unterschiedliche Schutzverträge.
Vor der ersten technischen Entscheidung schreiben wir auf, was ein Angreifer erreichen könnte. Bei der Einstellung wäre das eine unerwünschte Änderung im Namen eines Kunden. Bei der Anfrage wären es beispielsweise überfüllte Bearbeitungslisten oder viele kostenpflichtige Versandvorgänge. Diese Folgen bestimmen, an welcher Stelle die Anwendung stoppen muss. Ein hübsches Sicherheitssymbol im Formular ist kein Ersatz für diese fachliche Betrachtung.
Den geschützten Vorgang genau benennen
Unser Kontobeispiel ändert nur die Entscheidung, ob eine wöchentliche Zusammenfassung gewünscht ist. Auch diese kleine Änderung gehört ausschließlich zum angemeldeten Konto. Der Server muss die Sitzung kennen und die Berechtigung für genau dieses Konto prüfen. Eine vom Formular gelieferte Kundennummer darf nicht einfach bestimmen, wessen Einstellung geändert wird. CSRF-Prüfung und Zugriffsberechtigung bleiben eigenständige Entscheidungen.
Für unsere interne Ablaufskizze nennen wir die Schritte Anmeldung, Anfrageprüfung, Mengenprüfung, fachliche Validierung und Änderung. Ein negatives Ergebnis beendet den Vorgang vor der Änderung. Diese Reihenfolge ist ein eigener Entwurf für das Beispiel. Eine reale Anwendung muss zusätzlich berücksichtigen, welche Vorarbeiten teuer sind und welche Daten schon vor einer Anmeldung verarbeitet werden. Besonders aufwendige Arbeit sollte nicht unkontrolliert vor den passenden Grenzen stattfinden.
Das öffentliche Reparaturformular erhält dagegen keine künstliche Kundenberechtigung. Eine neue Person darf eine Anfrage stellen. Würden wir allein daraus ableiten, dass jede formal korrekte Anfrage akzeptiert werden muss, fehlte weiterhin der Schutz vor einer automatisierten Serie. Wir definieren daher getrennt, wie viel Arbeit der Dienst annehmen kann und welchen Weg ein berechtigter Mensch bei einer vorübergehenden Ablehnung erhält.
Ein sitzungsgebundenes Token verständlich aufbauen
Für das kleine PHP-Beispiel erzeugen wir mit random_bytes 32 zufällige Bytes und kodieren sie als 64 kleine Hexadezimalzeichen. Das Token bleibt im serverseitigen Sitzungszustand. Das gerenderte Formular trägt den zugehörigen Wert in einem versteckten Feld. Bei einer Anfrage vergleichen wir den gelieferten Wert mit dem erwarteten Sitzungswert. Der Vergleich erfolgt mit hash_equals und nicht mit einem selbst gebauten Zeichenvergleich.
Der eigene Baustein prüft die Datentypen und das erwartete Format ausdrücklich vor dem Vergleich. Dadurch wird ein als Array gesendeter Parameter kontrolliert abgewiesen. Das ist ein sinnvoller Randfall für PHP-Formulardaten: Ein Angreifer muss nicht dieselbe Eingabestruktur verwenden wie die sichtbare Oberfläche. Die 64 Zeichen sind der konkrete Formatvertrag dieses Beispiels. Eine andere etablierte Implementierung darf einen anderen gut begründeten Vertrag besitzen.
Wir behalten ein gültiges Token innerhalb derselben Sitzung bei. Das erleichtert mehrere gleichzeitig geöffnete Formularansichten. Ein Token pro Anfrage könnte ebenfalls Teil eines Entwurfs sein, würde aber zusätzliche Entscheidungen über alte Tabs, Rückwärtsnavigation und Wiederholungen benötigen. Wichtig ist eine ausdrückliche Lebensdauer. Nach einem Wechsel des Anmeldestatus muss die Integration den zugehörigen Sitzungszustand und die Tokenpolitik passend erneuern.
Herkunft und Browserkontext ausdrücklich prüfen
Unsere kontrollierte Browseranwendung besitzt genau den konfigurierten Origin https://app.example.test. Die Prüffunktion verlangt eine exakte Übereinstimmung mit diesem Wert. Sie leitet die erlaubte Herkunft nicht aus einem beliebig eingehenden Host-Header ab. Eine ähnlich aussehende Domain oder ein angehängter fremder Domainteil ist daher kein Treffer. Auch das Schema und die Portdarstellung gehören zur bewusst engen Beispielregel.
Fehlt der Origin oder lautet er null, lehnt dieser Baustein die Anfrage ab. Das ist eine strenge Einsatzentscheidung für die betrachtete Browseranwendung. Es ist keine universelle Behauptung, dass jeder legitime Client immer denselben Header liefert. Vor einer Übernahme müssen die unterstützten Browserwege und vorgeschalteten Systeme geprüft werden. Für andere Clients braucht es einen gesonderten ausdrücklichen Vertrag, nicht eine unbemerkte Lockerung nach dem ersten Supportfall.
Wenn Sec-Fetch-Site vorhanden ist, verlangt die Funktion außerdem same-origin. same-site wird nicht gleichgesetzt. Fehlt diese zusätzliche Metadatenangabe, bleiben Origin und Token weiterhin erforderlich. Diese Kombination ist eine nachvollziehbare Entscheidung des Beispiels. Die Header ersetzen keine Anmeldung und können außerhalb des Browsers von einem direkten Client selbst gesetzt werden. Gerade deshalb dürfen sie nicht als umfassende Bot-Erkennung verkauft werden.
Der geprüfte PHP-Baustein
Der folgende Code ist absichtlich als isolierte Prüffunktion gestaltet. Er ändert keine Kontoeinstellung, verschickt keine Nachricht und entscheidet nicht über eine Kundenberechtigung. Dadurch lassen sich seine positiven und negativen Fälle unabhängig prüfen. Für den produktiven Ablauf muss ein vorhandenes Anwendungsgerüst die Sitzung, Berechtigung, Verarbeitung und Rückmeldung korrekt verbinden. Eine etablierte Frameworkfunktion sollte zuerst geprüft werden, bevor eigener Schutzcode ergänzt wird.
Die Funktion erlaubt ausschließlich POST. Ein zustandsändernder GET-Aufruf ist in unserem Ablauf nicht vorgesehen. POST allein ist allerdings kein CSRF-Schutz. Erst die zusätzlichen Prüfungen beantworten die hier vereinbarten Fragen. Der Name formRequestAllowed bedeutet deshalb nur, dass dieser konkrete Prüfvertrag erfüllt ist. Eine spätere fachliche oder mengenbezogene Prüfung kann die Anfrage weiterhin ablehnen.
<?php
declare(strict_types=1);
// Baustein für eine kontrollierte Browseranwendung.
// Der feste Origin ist Konfiguration, kein eingehender Host-Header.
function formRequestAllowed(
string $method,
mixed $origin,
mixed $fetchSite,
mixed $submittedToken,
mixed $sessionToken,
string $trustedOrigin
): bool {
if ($method !== 'POST') return false;
if (!is_string($origin) || $origin !== $trustedOrigin) return false;
if ($fetchSite !== null && $fetchSite !== 'same-origin') return false;
if (!is_string($submittedToken) || !is_string($sessionToken)) return false;
if (preg_match('/\A[a-f0-9]{64}\z/D', $sessionToken) !== 1) return false;
if (preg_match('/\A[a-f0-9]{64}\z/D', $submittedToken) !== 1) return false;
return hash_equals($sessionToken, $submittedToken);
}
function ensureFormToken(array &$session): string {
$current = $session['form_token'] ?? null;
if (!is_string($current)
|| preg_match('/\A[a-f0-9]{64}\z/D', $current) !== 1) {
$session['form_token'] = bin2hex(random_bytes(32));
}
return $session['form_token'];
}
Sitzung und Ausgabe passend integrieren
Die Sitzung wird vor der Ausgabe eingerichtet. Für eine ausschließlich über HTTPS betriebene Anwendung werden Secure, HttpOnly und ein bewusst gewähltes SameSite-Verhalten des Sitzungscookies konfiguriert. PHP-Einstellungen zur ausschließlichen Cookienutzung und zum strengen Sitzungsmodus gehören ebenfalls in die Prüfung. Diese Einstellungen müssen zum tatsächlichen Login und zu eventuell vorhandenen zentralen Sitzungsdiensten passen. Nicht jedes Projekt startet eine unabhängige zweite PHP-Sitzung.
Der Tokenwert wird beim Einsetzen in das versteckte HTML-Feld passend für den Attributkontext ausgegeben. Im Beispiel verwenden wir htmlspecialchars mit ENT_QUOTES und UTF-8. Das Token gehört nicht in eine URL, die anschließend in Verlauf, Verweisen oder Protokollen auftaucht. Antworten mit sitzungsbezogenen Formularwerten dürfen nicht unkontrolliert gemeinsam für andere Benutzer zwischengespeichert werden. Die konkrete Cachekonfiguration muss deshalb Teil der Integration sein.
Ein verlorener Sitzungszustand ist ein normal zu gestaltender Fehlerfall. Das Formular sollte keine erfundene erfolgreiche Änderung melden. Ein Mensch benötigt einen verständlichen Weg zu einer frischen Formularansicht und seine nicht sensiblen Eingaben sollten soweit vertretbar erhalten bleiben. Ob eine erneute Anmeldung erforderlich ist, ergibt sich aus dem tatsächlichen Zustand. Die Schutzregel darf nicht aus Bequemlichkeit durch einen stillen Wiederholungsversuch ohne Token umgangen werden.
<input type="hidden" name="csrf_token"
value="<?= htmlspecialchars(ensureFormToken($_SESSION),
ENT_QUOTES, 'UTF-8') ?>">SameSite und CORS richtig einordnen
Ein SameSite-Cookie kann zusätzliche Grenzen für browserseitig mitgesendete Cookies schaffen. Welche Konfiguration passt, hängt auch von benötigten Anmelde- und Integrationswegen ab. Es ist deshalb eine weitere Schicht und kein Anlass, die konkrete Anfrageprüfung zu entfernen. Besonders eine andere Origin innerhalb derselben Site verdient eine eigene Betrachtung. Unser strenger Vergleich behandelt Herkunft genauer als eine pauschale Gleichsetzung aller Unterdomains.
CORS regelt browserseitige Zugriffe auf Antworten und darf nicht pauschal als Verhinderung jeder fremd ausgelösten Anfrage verstanden werden. Ein Formular kann auf Arten gesendet werden, bei denen eine Anwendung ihre zustandsändernde Arbeit trotzdem selbst schützen muss. Für unser Beispiel bedeutet das eine einfache Planungsregel: Die Verarbeitung prüft ihren eigenen Vertrag unabhängig davon, ob die fremde Seite die Antwort anschließend lesen dürfte.
Diese Trennung macht eine Abstimmung mit Schnittstellenentwicklern leichter. Wenn eine mobile App oder ein externer Dienst dieselbe fachliche Änderung benötigt, wird ihr Authentifizierungs- und Berechtigungsweg ausdrücklich festgelegt. Ein Browser-Sitzungstoken wird nicht gedankenlos zum allgemeinen API-Schlüssel umfunktioniert. Unterschiedliche Clientverträge können dieselbe fachliche Prüfung nutzen, ohne ihre Sicherheitsannahmen zu vermischen.
Automatisierung als eigene Mengenfrage behandeln
Ein Skript kann ein öffentliches Formular abrufen, Cookies behalten und ein korrektes Token wieder mitsenden. Diese Möglichkeit ist kein Fehler des Tokenvergleichs. Sie zeigt, dass der Angreifer einen anderen Weg nutzt als beim klassischen fremd ausgelösten Browservorgang. Für den Reparaturbetrieb zählen nun die angenommenen Nachrichten, die verursachten Versandkosten und die verfügbare Bearbeitung. Diese Größen werden gesondert begrenzt und beobachtet.
Wir wählen für eine fiktive Planungsübung drei Eingangsgrößen: Versuche pro Quelle, bestätigte Vorgänge pro Konto und eine globale Grenze vor einem teuren Folgeschritt. Konkrete Zahlen müssen aus der tatsächlichen Kapazität und legitimen Spitzen abgeleitet werden. Eine gemeinsam genutzte Firmenadresse kann viele echte Menschen vertreten. Eine alleinige starre Grenze pro IP wäre deshalb weder eine verlässliche Identität noch automatisch ein fairer Zugang.
Die Begrenzung muss ihren gemeinsamen Zustand atomar verändern. Wenn mehrere Prozesse gleichzeitig dieselbe freie Kapazität lesen und erst später zählen, kann die geplante Grenze überschritten werden. Eine Variable im einzelnen PHP-Prozess löst das Problem nicht für mehrere Worker oder Server. Für die reale Umsetzung wählen wir einen geeigneten gemeinsamen Speicher und prüfen konkurrierende Anfragen. Der kleine Tokenbaustein behauptet ausdrücklich keine solche verteilte Mengensteuerung.
Teure Arbeit und Wiederholungen begrenzen
Bei unserem öffentlichen Formular könnte schon die Nachricht an das interne Team ein kostenpflichtiger oder mengenbegrenzter Folgeschritt sein. Die Annahmeprüfung gehört davor. Aufwendige Anhänge, externe Dienste und umfangreiche Protokollierungen können ebenfalls Kosten auslösen. Zeichnen Sie den tatsächlichen Weg einer Anfrage einschließlich Fehlern auf. Eine Grenze, die erst nach der teuren Arbeit greift, schützt möglicherweise nur die sichtbare Bearbeitungsliste.
Doppelte Übertragungen entstehen auch ohne Angriff. Jemand klickt nach einer verzögerten Antwort erneut oder der Browser wiederholt einen Vorgang nach einer Unterbrechung. Für eine kostenträchtige Aktion braucht die Anwendung deshalb eine ausdrückliche Wiederholungsentscheidung. Ein CSRF-Token ist nicht automatisch ein einmaliger Geschäftsvorgangsschlüssel. Die Anwendung muss definieren, wann zwei Übertragungen denselben Auftrag meinen und wie sie dessen Ergebnis wiederfinden kann.
Bei einer vorübergehenden Mengenablehnung kann HTTP 429 passend sein. Die Oberfläche erklärt dann den nächsten sinnvollen Schritt, ohne die Schutzlogik oder persönliche Informationen offenzulegen. Ein Retry-After-Wert muss zur tatsächlichen Wiederholungsmöglichkeit passen. Unser fiktiver Betrieb könnte eine spätere erneute Anfrage und einen unabhängig gepflegten Kontaktweg anbieten. Ein angeblicher Versand trotz Ablehnung wäre keine nutzerfreundliche Lösung.
Honeypots und zusätzliche Prüfungen mit Augenmaß nutzen
Ein verstecktes Köderfeld kann einfache automatisierte Füllversuche sichtbar machen. Es ist jedoch eine zusätzliche Heuristik und kein Beweis, dass jede andere Anfrage von einem Menschen stammt. Für unseren Entwurf prüfen wir außerdem, ob echte Autovervollständigung oder assistive Nutzung versehentlich hineinläuft. Eine zusätzliche Schutzmaßnahme darf den Zugang nicht gerade für Menschen erschweren, die Unterstützung bei der Eingabe benötigen.
Eine Mindestbearbeitungszeit ist ebenso wenig ein verlässlicher Menschennachweis. Eine echte Person kann vorbereiteten Text einfügen, während ein Skript problemlos wartet. Solche Signale können eine abgestufte Bewertung ergänzen, sollten aber nicht ungeprüft zur alleinigen endgültigen Ablehnung führen. Wir betrachten die Fehlentscheidungen ausdrücklich: Welche echte Anfrage verlieren wir und welchen Aufwand sparen wir tatsächlich ein?
Wenn ein zusätzlicher interaktiver Prüfschritt nötig wird, gehört sein Ausweichweg zum Entwurf. Ein Team sollte die wirksame Entlastung und die Belastung echter Besucher gemeinsam messen. Für das kleine Reparaturformular beginnen wir mit klaren Feldern, serverseitigen Regeln und sinnvoller Begrenzung. Weitere Maßnahmen ergänzen einen nachgewiesenen Bedarf statt nur ein sichtbares Gefühl von Sicherheit zu erzeugen.
Eingaben und Ausgaben weiterhin prüfen
Ein korrektes Token macht den Inhalt einer Nachricht nicht vertrauenswürdig. Der Server prüft Datentypen, vereinbarte Längen und fachliche Werte. Ein im HTML begrenztes Textfeld kann direkt mit anderen Werten angesprochen werden. Für unsere Mitteilungseinstellung gibt es nur die ausdrücklich vereinbarten Auswahlwerte. Unbekannte Werte werden nicht still in eine zufällige Wahrheit umgewandelt. Diese Regeln gehören zur fachlichen Verarbeitung nach der Anfrageprüfung.
Wenn die Nachricht später im Verwaltungsbereich angezeigt wird, benötigt die Ausgabe den zum Kontext passenden Umgang mit nicht vertrauenswürdigem Text. Eine Eingaberegel ist kein allgemeiner Ersatz für sichere Ausgabe. Ebenso wenig repariert ein CSRF-Token eine vorhandene Skripteinschleusung in derselben Anwendung. Sicherheitsmaßnahmen müssen ihre eigenen Zuständigkeiten behalten, damit ein Team keine Lücke mit einer fachfremden Prüfung für geschlossen hält.
Für die Übergabe trennen wir deshalb die Nachweise. Eine Gruppe zeigt die Anfrageprüfung, eine weitere die Mengenbegrenzung und eine dritte die fachliche Verarbeitung. Ergänzend prüfen wir die sichtbare Rückmeldung. Das schafft klare Verantwortlichkeiten: Eine bestandene Tokentestreihe sagt nichts darüber, ob beispielsweise eine überlange Nachricht oder eine unberechtigte Konto-ID korrekt behandelt wird.
Die tatsächlich ausgeführten Prüffälle einordnen
Der veröffentlichte reine PHP-Baustein wurde mit 43 isolierten Prüfungen ausgeführt. Dazu gehören die passende Sitzungskombination, falsche Methoden, fehlende Herkunft, ähnlich aussehende Domains, abweichende Ports, verschiedene Metadaten und falsch strukturierte Tokenparameter. Ein neues Token besitzt das vereinbarte Format. Ein gültiges vorhandenes Token bleibt erhalten, während ungültiger gespeicherter Zustand ersetzt wird. Die konkreten positiven und negativen Ergebnisse fließen in die erklärende Grafik ein.
Bewusst streng ist der Fall einer ausdrücklich angehängten Standardportangabe. Die Konfiguration erwartet die exakt festgelegte Origin-Zeichenfolge. Auch ein nachgestellter Schrägstrich wird nicht normalisiert. Das ist eine dokumentierte Eigenschaft dieses kleinen Bausteins. Wer mehrere zulässige Darstellungen unterstützen muss, definiert und prüft eine enge kanonische Herkunftsliste statt mit Teilstringvergleichen beliebige Ähnlichkeiten zu akzeptieren.
Diese Prüfungen sind keine Lastprüfung, kein echter Browserangriff und keine Abnahme des produktiven Loginablaufs. Für eine reale Integration ergänzen wir HTTP-Prüfungen mit der tatsächlichen Sitzung, dem Proxyweg und den Cachebedingungen. Die Ratenbegrenzung wird gesondert unter Konkurrenz geprüft. Ein konkreter Nachweis ist wertvoller als die ungenaue Behauptung, ein einzelnes grünes Testergebnis mache jedes Formular sicher.
Einen Betrieb mit klaren Entscheidungen vorbereiten
Unser Reparaturbetrieb benötigt eine zuständige Person für auffällige Annahmeraten und fehlgeschlagene Folgeschritte. Protokolle sollen dafür die nötigen Ereignisse liefern, ohne Token, vollständige Nachrichten und unnötige persönliche Daten ungeprüft zu sammeln. Eine Ablehnung lässt sich anhand einer technischen Vorgangsreferenz untersuchen. Welche Daten wie lange benötigt werden, entscheidet der reale Betrieb mit seinen zuständigen Fachpersonen.
Bei einem plötzlichen Anstieg unterscheiden wir zunächst zwischen echten Nachfragen und unerwünschter Last. Eine veröffentlichte Aktion oder ein gemeinsamer Firmenzugang kann ein anderes Muster erzeugen als ein Angriff. Die Notfallentscheidung braucht einen Rückweg: vorübergehende Limits, kontrollierte Entlastung und anschließende Prüfung legitimer Ablehnungen. Eine hektische Abschaltung aller Regeln löst die akute Störung möglicherweise nur durch eine neue Schwachstelle ab.
Die Abnahme endet deshalb mit klaren Antworten. Wer darf welche Aktion ausführen? Wie wird eine fremde Browseranfrage erkannt? Was begrenzt automatisierte Menge vor teuren Schritten? Welche Daten werden geprüft? Was sieht ein Mensch nach einer Ablehnung oder Wiederholung? Wenn diese Fragen gemeinsam beantwortet und tatsächlich getestet sind, entsteht ein belastbarer Formularprozess statt einer Sammlung unverbundener Sicherheitsattribute.
Schutzaufgaben im Vergleich
| Frage | Zuständige Entscheidung |
|---|---|
| Wer ist angemeldet? | Authentifizierung und Sitzung |
| Darf dieses Konto geändert werden? | Konkrete Zugriffsberechtigung |
| Erfüllt die Anfrage den Browservertrag? | Origin, Sitzungs-Token und ergänzende Metadaten |
| Ist die Menge tragbar? | Atomare gemeinsame Begrenzung vor teurer Arbeit |
| Sind die Angaben zulässig? | Serverseitige fachliche Validierung |
| Ist der Vorgang schon ausgeführt? | Geschäftliche Wiederholungsregel |
Checkliste vor der Freigabe
- Zustandsändernde Aktionen und konkrete Berechtigungen dokumentieren.
- Vorhandenen Frameworkschutz zuerst prüfen.
- Tokenquelle, Ausgabe, Lebensdauer und Vergleich nachvollziehen.
- Erlaubte Herkunft konfigurieren und Proxyweg prüfen.
- Sitzungscookie und Cacheverhalten im tatsächlichen Ablauf prüfen.
- Mengen vor teuren Schritten atomar begrenzen.
- Wiederholung und Fehler ohne falsche Erfolgsmeldung gestalten.
- Positive und negative Fälle einschließlich konkurrierender Last getrennt belegen.
Quellen und Prüfstand
Primärquellen am 09.11.2026 geprüft. Serviceanwendung, Reparaturbetrieb und Ablaufmodell sind eigene fiktive Beispiele. Die 43 isolierten PHP-Prüfungen belegen ausschließlich den gezeigten Anfragebaustein und die Tokenerzeugung.
