Skip to content

Commit 4ed2811

Browse files
committed
docs: tra half section
1 parent 19b6597 commit 4ed2811

File tree

1 file changed

+23
-1
lines changed

1 file changed

+23
-1
lines changed

6-data-storage/01-cookie/article-fr.md

Lines changed: 23 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -203,4 +203,26 @@ C'est ce qu'on appelle une attaque "Cross-Site Request Forgery" (XSRF en plus co
203203

204204
Les vraies banques en sont évidemment protégées. Tous les formulaires générés par `bank.com` ont un champ spécial, un certain "XSRF protection token", qu'une page malveillante ne peut pas générer ou extraire de la page distante. Elle peut y soumettre un formulaire, mais pas récupérer les données. Le site `bank.com` vérifie ce genre de token dans tous les formulaires qu'il reçoit.
205205

206-
Une telle protection prend du temps à implémenter cependant. Nous avons besoin de nous assurer que tous les formulaires ont le champ de token requis, et nous devons aussi vérifier toutes les requêtes.
206+
Une telle protection prend du temps à implémenter cependant. Nous avons besoin de nous assurer que tous les formulaires ont le champ de token requis, et nous devons aussi vérifier toutes les requêtes.
207+
208+
### Entrer un cookie avec l'option samesite
209+
210+
L'option `samesite` de cookie fournit un autre moyen de se protéger de telles attaques, ça (en théorie) ne devrait pas nécessiter de "tokens de protections xsrf".
211+
212+
Elle a deux valeurs possible :
213+
214+
- **`samesite=strict` (pareil que `samesite` sans valeur)**
215+
216+
Un cookie avec `samesite=strict` n'est jamais envoyé si un utilisateur vient d'en dehors du même site.
217+
218+
En d'autres termes, qu'importe que l'utilise suive un lien de ses mails ou soumette un formulaire provenant d'`evil.com`, ou qu'il fasse des opérations originaires d'un autre domaine, le cookie n'est pas envoyé.
219+
220+
Si le cookie d'authentification a l'option `samesite`, alors l'attaque XSRF n'a aucun chance d'être un succés, car une soumission depuis `evil.com` ne vient pas avec les cookies. Donc `bank.com` ne reconnaitra pas l'utilisateur et ne procédera pas au paiement.
221+
222+
La protection est plutôt fiable. Seules les opérations provenants de `bank.com` vont envoyés le cookie `samesite`, e.g. une soumission de formulaire depuis une autre page à `bank.com`.
223+
224+
Bien que, il y a un petit inconvénient.
225+
226+
Quand un utilisateur suit un lien légitime vers `bank.com`, comme depuis ses propres notes, il sera surpris que `bank.com` ne le reconnaisse pas. En effet, les cookies `samesite=strict` ne sont pas envoyés dans ce cas.
227+
228+
Nous pouvons travailler autour de ça avec deux cookies : une pour la "reconnaissance générale", uniquement dans le but de dire : "Salut, John", et un autre pour les opérations de changements de données avec `samesite=strict`. Alors, une personne venant de l'extérieur du site verra un message de bienvenue, mais les paiements doivent être initié depuis le site de la banque, pour que le second cookie soit envoyé.

0 commit comments

Comments
 (0)