Documentations

Protection CSRF

le cross-site request forgery, abrégé CSRF. L'objet de cette attaque est de transmettre à un utilisateur authentifié une requête HTTP falsifiée qui pointe vers une action interne au site, afin qu'il l'exécute à son insu et en utilisant ses propres droits. L'utilisateur devient donc complice d'une attaque sans même s'en rendre compte. L'attaque étant menée par l'utilisateur, un grand nombre de systèmes d'authentification sont contournés.

exemple:

• Supposons qu'Alice soit l'administratrice d'un forum et qu'elle y soit connectée par un système de sessions. Malorie est membre de ce même forum, elle veut supprimer un des messages du forum. N'ayant pas les droits nécessaires avec son compte, elle utilise le compte d'Alice grâce à une attaque de type CSRF.
• 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 doit avoir une session ouverte dans son navigateur pour le site ciblé par Malorie. Cette condition est nécessaire pour que l'attaque réussisse silencieusement sans nécessiter de demande d'authentification qui alerterait Alice. Cette session doit disposer des droits nécessaires pour exécuter la requête destructrice de Malorie. Il n'est pas nécessaire qu'un onglet du navigateur soit ouvert sur le site cible, ni même que le navigateur soit démarré. Il suffit que la session soit active.
• Alice lit le message de Malorie, son navigateur utilise la session ouverte d'Alice et ne demande pas d'authentification interactive. Il tente de récupérer le contenu de l'image. Ce faisant, le navigateur active le lien et supprime le message, il récupère une page web textuelle comme contenu de l'image. Ne reconnaissant pas le type d'image associé, il n'affiche pas d'image et Alice ne sait pas que Malorie vient de lui faire effacer un message contre son gré.

La stratégie est simple : il suffit d'ajouter une clé secrète dans le formulaire (connue uniquement par le site et non par l'attaquant) et de vérifier l'exactitude de cette clé lors de la réception du formulaire.

côté formulaire première action

Pour ajouter une clé et la stocker dans la session, une fonction twig existe pour générer l'entrée cachée nécessaire, puis il suffit d'empêcher twig de la neutraliser avec le filtre brut, comme ceci:

{{ getToken()|raw }}

Actions suivantes du côté du poste

Maintenant qu'une clé a été ajoutée au formulaire, il faut vérifier que cette clé existe et qu'elle est valide.

Si elle est valide, nous pouvons traiter le formulaire, sinon, nous devons ... faire autre chose.

pour vérifier si le jeton est valide, il existe une fonction de validation, comme suit:

$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