Dokumentationen

CSRF-Schutz

die Cross-Site Request Forgery, abgekürzt CSRF. Ziel dieses Angriffs ist es, einem authentifizierten Benutzer eine gefälschte HTTP-Anfrage zu übermitteln, die auf eine Aktion innerhalb der Website verweist, so dass er diese ausführt, ohne sich dessen bewusst zu sein und seine eigenen Rechte zu nutzen. Der Benutzer wird somit zum Komplizen eines Angriffs, ohne es zu bemerken. Da der Angriff vom Benutzer ausgeht, wird eine große Anzahl von Authentifizierungssystemen umgangen.

Beispiel:

• Angenommen, Alice ist die Administratorin eines Forums und über ein System von Sitzungen mit diesem Forum verbunden. Malorie ist ein Mitglied desselben Forums und möchte einen der Forenbeiträge löschen. Da sie mit ihrem Konto nicht über die erforderlichen Rechte verfügt, verwendet sie dank eines CSRF-Angriffs das Konto von Alice.
• Malorie manages to know the link that allows you to delete the message in question. Malorie sends a message to Alice containing a pseudo-image to display (which is actually a script). The image URL is the link to the script to delete the desired message.
• Alice muss in ihrem Browser eine offene Sitzung für die von Malorie angegriffene Website haben. Dies ist eine Voraussetzung dafür, dass der Angriff ohne eine Authentifizierungsanfrage, die Alice alarmieren würde, erfolgreich sein kann. Diese Sitzung muss über die erforderlichen Rechte verfügen, um die destruktive Anfrage von Malorie auszuführen. Es ist nicht erforderlich, dass eine Browser-Registerkarte auf der Zielseite geöffnet ist oder dass der Browser überhaupt gestartet ist. Es reicht aus, dass die Sitzung aktiv ist.
• Alice liest die Nachricht von Malorie, ihr Browser verwendet die offene Sitzung von Alice und verlangt keine interaktive Authentifizierung. Er versucht, den Inhalt des Bildes abzurufen. Dabei aktiviert der Browser den Link und löscht die Nachricht, er ruft eine Text-Webseite als Inhalt für das Bild ab. Da er die Art des Bildes nicht erkennt, zeigt er kein Bild an, und Alice weiß nicht, dass Malorie ihn gerade dazu gebracht hat, eine Nachricht gegen seinen Willen zu löschen.

Die Strategie ist einfach: Fügen Sie einfach einen geheimen Schlüssel in das Formular ein (den nur die Website und nicht der Angreifer kennt) und überprüfen Sie die Richtigkeit dieses Schlüssels beim Empfang des Formulars.

Formularseite erste Aktion

Um einen Schlüssel hinzuzufügen und ihn in der Sitzung zu speichern, gibt es eine Twig-Funktion, die den notwendigen versteckten Input generiert und dann einfach verhindert, dass Twig ihn mit dem Rohfilter neutralisiert, etwa so:

{{ getToken()|raw }}

Buchungsseite nächste Aktionen

Nachdem dem Formular nun ein Schlüssel hinzugefügt wurde, müssen Sie überprüfen, ob dieser Schlüssel existiert und gültig ist.

Wenn es gültig ist, können wir das Formular verarbeiten, wenn nicht, müssen wir ... etwas anderes tun.

um zu prüfen, ob das Token gültig ist, gibt es eine Validator-Funktion, wie diese:

$tokenValid = $this->checkToken($_POST['token'] ?? "");
if ($_SERVER['REQUEST_METHOD'] === 'POST' && $tokenValid)

To complete this documentation there is always the example of the "item CRUD" provided by default in the mini-framework