Gestion des noms des tokens anti-csrf
Closed this issue · 8 comments
Je crée cette issue pour lancer une concertation sur le nom des tokens anti-csrf dans YesWiki.
Actuellement, il n'y a pas de nom très générique.
Qu'en penses-vous @mrflos, @acheype , @seballot ... ?
Quelle proposition de nom avez-vous ? Faut-il y inclure le nom de l'image (fiche/fichier) concerné ou non ?
Faut-il changer le moyen de transmission du token et passer par des cookies ? une variable js ? Ou rester sur une insertion brute dans les url dans le html ? (quelques idées en vrac à compléter)
hello,
Je serai pour ma part pour une route unique de type api/csrftokens (avec des appels rest standards) qui serait utilisée pour tous les usages de ces tokens (ajout/modification/suppressions de pages/fiches/utilisateurices/triples et ajout/modification/redimentionement/suppressions de fichiers/images).
En théorie, les tokens sont passés en entêtes des requêtes, cela permet de les passer discrètement, le serveur n'enregistrant que l'url et pas les entêtes.
Après si c'est compliqué d’imaginer passer toutes les requêtes en ajax, l'injecter dans un champs caché du formulaire, au moment du submit me parait bien.
Coucou !
je suis pas sûr qu'on parle de la meme chose, mais sur les framework que je connais ça marche comme ça :
- Lorsque le formulaire en rendu en html, un token est généré et inclus via un
<input type="hidden" name="_csrf" value="xxxxx"/> - lorsqu'on submit, le controller check que le csrf est dans $_POST['_csrf'] est le meme que celui créé plus tôt
oui, c'est bien cela!
Apres on peut le générer a la création du formulaire, ou plus tard par un appel ajax et une injection.
J'aime bien la deuxième option car on voies rien avant l'envoi, dans l'autre cas, ya une indication pour les robots qu'un csrf est nécessaire et on connait son nom. (Apres je sais que la sécurité par obstruction n'est pas la mieux, mais je me dis que ca détourne les script kiddies)
Je pense qu'il ne faut pas oublier qu'il y a plein d'endroit du wiki ou les requêtes se font en $_GET pour faciliter plein de choses, .. est-ce que vous seriez toujours OK pour conserver la possibilité de l'avoir dans l'url dans les cas un peu sioux où ça sera compliqué de passer la requête en $_POST sans réécrire plein de trucs.
@J9rem oui, il s'agit avant tout de renommer et standardiser l'api.
Apres si t'as une idée précise des cas ou il y a génération de requêtes avec GET ou POST, ca serait bien d'en faire une liste, pour voir les différents cas et comment les traiter.
Difficile de dire car il doit y avoir une trentaine de cas minimum qui font des requêtes anti-crsf.
je viens de regarder, cela concerne 24 fichiers, un peu plus en comptant les fichiers de langue, mais pas mal de trucs gérés soit par un contrôleur php, soit pour les twig un helper, et les routes pour le multidelete (donc a priori facile d'intervenir dessus).