Nous avions vu cela au devcamp… as tu plusieurs onglet ouvert sur des formulaire car le token reprend celui d avant donc il pas bon sur ton autre onglet.
Si c’est vraiment bloquant, tu peux le passer à 0 (pas top car c’est quand même une bonne addition au niveau sécurité) mais le mieux je pense serait de signaler les différentes actions qui posent problème sur GitHub pour que ça soit corrigé
En bonus, pour les personnes intéressées par les attaques de type « Cross-Site Request Forgery » (savoir ce que c’est et comment ça marche), le CERT-FR (Computer Emergency Response Team France), coordonné en France par l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information) a publié une note d’information CERTA-2008-INF-003.
N’est-il pas possible de gérer un tableau de tokens pour une certaine durée tant qu’ils n’ont pas été consommés/validés (au moins pour un certain temps).
la liste des tokens avec un réglage de leurs expirations me semble une bonne approche.
Si on supprime de la liste au fur et à mesure ceux qui ont été utilisé, ça ne devrait pas trop gêner pour une session de 24h. donc pas forcément besoin de délai d’expiration.
la seule limite de la taille de session, c’est le memory limit de PHP.
En fait, tel que je le comprend, le CSRF est principalement utilisé via un lien (donc plus souvent utilisable en GET mais possible aussi en POST avec du Javascript).
Pour sécuriser cela, d’un côté les formulaires comportent un champ caché avec un token en plus (qui ne pourra pas être connu de l’attaquant).
Côté serveur (la session de l’utilisateur comporte le token généré dans le formulaire) et l’action ne peut être effectuée que s’il y a correspondance entre le token en session et celui envoyé par le formulaire.
Donc, il n’y a pas à proprement parler de « vol » de session mais plutôt exécution d’une action illégitime par un utilisateur légitime sans qu’il n’en ait forcément conscience.
Mon idée était donc de conserver les différents tokens côté session utilisateur tant qu’ils n’ont pas été validés (formulaire envoyé) et que la session de l’utilisateur n’est pas expirée pour qu’ils puissent être validés (tel que je le comprends, actuellement, à chaque fois qu’un token est généré il écrase le précédent en session ; mais c’est juste ce que j’ai assumé en lisant le fil de discussion, je n’ai pas regardé le code).
oui, ça écrase le token à chaque génération d’un nouveau et tu as bien compris la mécanique.
c’est moi qui pensait au vol de session pour rien en effet, ce n’est pas le meme probleme
(mais on pourrait avoir un controle d’ip dans la session si ce n’est pas déjà fait, sauf ceux qui ont plusieurs IP publiques)
Ça peut fonctionner même pour les IP publiques qui ne sont pas fixes parce que je ne pense pas que l’IP puisse changer en cours de session (l’IP tournante est en général ré-attribuée par le FAI lors de la connexion modem).
Le contrôle via IP peut être un plus mais à mon sens n’offre pas la même sécurité qu’un token.
Par exemple, dans une société, les différents postes connectés au réseau auront tous la même adresse IP publique (et la comparaison IP sera OK même dans le cas où une attaque CSRF est perpétrée par un employé : cela permet donc une attaque interne).
C’est effectivement une des idées qui avaient été abordés. Mais je crois que nous n’avons pas avancé sur la question. On cherche une solution « plus jolie » car on sera toujours limité à un nombre. J’ai pas regardé la develop.
Ah bah oui, c’est vrai, j’avais pas pensé à l’agrégation de lien (et c’est vrai que c’est courant sur les moyenne grosses entreprises), pour avoir un lien backup ou juste en répartition de charge/bande passante
Bonjour,
J’ai aussi signalé un problème, qui ne se manifeste pas de la même manière, mais qui pourrait y être lié, puisque j’obtiens le message « Unset POST by CSRF protection » quand je réussis à m’en sortir en modifiant l’URL dans la barre du navigateur.
Je le trouve très gênant et je suis étonné qu’il n’y ait pas d’autres personnes qui le rapportent.
Je précise que ma v11 est une version de test et qu’en général, je l’ouvre dans un nouvel onglet. Je n’ai pas ce souci dans la v8, même si j’utilise plusieurs onglets.
Bonjour
Je teste la v12.0.4 (j’étais sur la v10) et je rencontre exactement le même problème.
Je suis sur la page d’un utilisateur (je n’ai qu’un seul onglet Dolibarr d’ouvert - j’ai vidé mon cache) et quand je valide le formulaire j’ai cette même erreur.
Pour l’instant j’ai ajouté MAIN_SECURITY_CSRF_WITH_TOKEN à 0 afin de pouvoir valider mes formulaires.
Bonjour à tous,
J’étais sur Debian avec la version 12.02 et dès le passage à la 12.04 j’ai le même message d’alerte.
J’ai fais comme @dolibarr95 pour ne plus avoir le message à chaque validation de facture.