Projet

Général

Profil

Actions

CSRF

Vous recevez par mail une alerte CSRF du type:

==========================

La variable csrf_alea ne coincide pas avec le gepi_alea en SESSION.
La personne victime de l'attaque était XXXXXXXX.
La page cible était /gepi/saisie/ajax_appreciations.php avec les variables suivantes:
Variables en $_POST:
Variables en $_GET:

==========================

Voilà ce que j'avais répondu à un gepi-user:

==========================

Est-ce que le module gepi est bien à jour?
Quelle révision affichée en rouge dans le bandeau d'entête en admin?

Il y avait un défaut dans le dispositif de sauvegarde des appréciations
temporaires:
A chaque changement de champ TEXTAREA, on provoquait l'enregistrement du
contenu du champ dans une table temporaire pour permettre une restauration
par la suite en cas de pépin.
Cet enregistrement se faisait dès qu'on quittait le champ sans se préoccuper
de savoir si le contenu du champ avait changé.
Conséquence:
Si on se reconnectait dans gepi (d'où génération d'un nouveau token de session
dans gepi) en ayant conservé un onglet sur la page de saisie d'appréciations,
qu'on y revenait et s'y promenait de champ en champ sans même chercher à
modifier d'appréciations, on provoquait ces alertes qui ne sont pas de vraies
attaques parce que le token dans la page de saisie était resté celui de
l'ancienne session.

Je pense donc qu'il s'agit d'une fausse alerte, mais qu'avec un gepi à jour
elle devrait moins souvent pouvoir se produire.

Cependant:
Revenir dans un onglet de saisie d'appréciations après s'être
déconnecté/reconnecté n'est pas prudent:
Il faut rafraichir la page avant de tenter des modifs parce qu'elles ne seront
ni sauvegardées en table temporaire, ni sauvegardées à l'enregistrement de la
page.

Note:
Les attaques CSRF consistent à faire en sorte qu'un utilisateur provoque
lui-même les dégats sur ses propres données s'il a une session ouverte.
http://fr.wikipedia.org/wiki/Cross-site_request_forgery

L'utilisation de token (une chaine aléatoire changeant au moins à chaque
session) est un moyen de contrer des attaques CSRF.

==========================

Mis à jour par Stéphane Boireau il y a presque 11 ans · 1 révisions