Salut,
oui, il y a aussi l’expiration du token qui semble courte et l’utilisation de l’historique des pages qui pose problème
Je trouve ça assez pénalisant, par ce qu’on perd toute la donnée saisie dans ce cas.
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.
1 « J'aime »
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).
j’ai signalé le bug
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.
@eldy que penses tu de cette approches?
1 « J'aime »
Si on te vole ta session, on te vole aussi ton tableau de tokens, en quoi ça sécurise dans ce cas là ?
Avoir une liste est contre productif, non ?
je regardais comment on avait géré ça dans oscss :
https://sourceforge.net/p/oscss/svn/HEAD/tree/trunk/catalog/includes/application_top.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.
beaucoup d’entreprises font de l’agregation de réseau et parfois elles ont plusieurs ip publiques
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 
1 « J'aime »
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.
Bon, on oublie ma râlerie, qui semble être résolue par un vidage de cache 
Merci Norbert.
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.
1 « J'aime »
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.
Bonjour
@Paco33 merci pour ce retour.
Du coup je trouve cela étrange comme comportement, si certains/es ont une idée je suis preneur.
Merci
Bonjour,
en V12.0.4 j’ai exactement le même problème qui n’existait pas en V12.0.3.
Il semble s’agir d’un problème de préremplissage des valeurs du select (prix fournisseur) dont l’ID est fournprice_predef.
- Si on positionne MAIN_SECURITY_CSRF_WITH_TOKEN à 0 le préremplissage du select (prix fournisseur) se fait bien et il n’y a pas de message d’erreur.
- Si ce positionnement n’est pas fait, ce select n’est pas prérempli et le message d’erreur apparait pour chaque produit ajouté. Par contre l’ajout se fait bien pour moi dans la commande malgré tout.
Mais je pense qu’il n’y avait pas de tentative de remplissage de ce select en V12.0.3.
Pour mémoire, le message exact sur mon installation V12.0.4 est :
Unset POST by CSRF protection in main.inc.php (POST for this token was already done or was done by a not allowed web page with a wrong token). $_SERVER[REQUEST_URI] = /fourn/ajax/getSupplierPrices.php?bestpricefirst=1 $_SERVER[REQUEST_METHOD] = POST GETPOST(token) = 6cd59ff7ab42843f15d5299eea8cdfe8 $_SESSION[token] = d46371f47e5cb32c007ff6d51e331301
Bug #15834 décrit sur Github
Bonjour
@Zuiko merci pour ce partage. De mon coté cette erreur s’affiche sur toutes les pages dont je valide le formulaire.
Merci pour l’astuce, j’ai fait pareil et plus de soucis maintenant
1 « J'aime »
