1

L’utilisation des tokens dans les formulaires (Faille CSRF)

Aujourd’hui, on va faire un petit topo sur l’utilisation de Token ou Jeton pour la sécurité de vos formulaires HTML. On va prévenir des fameuses failles CSRF (Cross-site request forgery).

Le principe du Token

Je vous explique rapidement le pourquoi du comment. Sur votre backoffice vous allez avoir la possibilité de modifier vos données (ajout, édition, suppression) et chaque action dispose d’une URL associé avec des paramètres GET ou je l’espère pour vous POST.

Exemple : article.php?action=delete&id=2

Je supprime donc l’article avec un ID 2.

La première protection réside dans votre système de connexion. En effet, cette URL n’est accessible qu’à un groupe d’utilisateur. Cependant, il y a toujours des petits malins qui peuvent vous forcer, vous administrateur, à cliquer sur ce lien. Redirection automatique, lien caché etc. Il faut donc se protéger contre cela. On va donc introduire des TOKENS.

Le principe du TOKEN ou jeton est le suivant : Le formulaire qui me permet d’effectuer une action va me transmettre une chaine de caractères que je vais stocker auparavant en session. Avant d’effectuer l’action, je vérifie si les informations sont concordantes. Voyons cela en action.

Sécuriser les actions grâce au Token

Votre vue formulaire :

<?php
    session_start();
    $token = sha1(uniqid());
    $_SESSION['token'] = $token;
?>
<!-- FORMULAIRE -->
[...]
<input type="hidden" name="token" value="<?= echo $token; ?>" />
[...]

Votre traitement php :

<?php
    if(isset($_SESSION['token'])){
        if($_POST['token'] == $_SESSION['token']){
            /* OK - JE PEUX FAIRE MON TRAITEMENT */
        } else {
            /* TOKEN DIFFERENT DONC ERREUR */
        }
    } else {
        /* TOKEN INEXISTANT */
    }
?>

J’ai donc généré un TOKEN en encodant en sha1 un uniqid(). Il n’y a pas de technique particulière pour cette génération, vous pouvez faire ce que vous souhaitez du moment que ce soit imprévisible pour un internaute. Je stocke donc cette variable en SESSION et ensuite dans un input HIDDEN.

Le formulaire est envoyé et sur mon traitement je test l’existence de la SESSION. Cela me permet de contrôler que le formulaire a bien été envoyé et que je n’ai pas un accès direct. Si tout est ok, je test si le TOKEN est équivalent à celui de la SESSION. Et oui si le token est différent c’est bien que je ne suis pas passé par la page et qu’on me force à m’y diriger. Je peux avoir une SESSION avec un token si je viens d’effectuer une action mais il sera différent. C’est un peu le principe du 3D SECURE, je vous donne un code unique pour chaque paiement :) !

Voilà un petit test rapide mais efficace :) !

Vous pouvez ajouter une gestion du temps. Je stocke en SESSION le timestamp et au traitement je fais la différence avec le timestamp actuel. Vous savez c’est cette gestion qui vous donne parfois ce doux message sur les CMS : « Votre session a expiré ».

Maintenant à vous de vérifier la présence de cette faille sur vos sites et la corriger !!

A bientôt les amis.

A propos de Thibault

Thibault a écrit 17 articles sur le blog.

Les amis de nos amis sont nos amis, alors partageons !

Laissez un commentaire





Si vous êtes un vrai développeur, vous devez savoir compter.
Alors on vous met au défi !
Si vous réussissez cette épreuve, nous nous ferons une joie de lire votre commentaire.