Vous êtes sur la page 1sur 6

Scénario de l’attaque :

Koutheir transmets de l’argent à Malek via l’url http://localhost/covid19/transfer.php

Le transfert est réussi , et dans ce cas un simple message est affiché à l’utilisateur. En effet , la
page PHP transfer.php représente une faille de sécurité très connue. Imaginons qu’arrive t’il
quand un pirate connait cet url ainsi que les paramètres du formulaire que Koutheir a subit.

Le formulaire rempli par Koutheir redirige Koutheir vers transfer.php pour afficher un message
de confirmation. Le champ amount représente la somme à transférer , tandis que le champ
receiver consiste le destinataire. Quant à l’expéditeur ‘Koutheir ‘ il est déjà authentifié et
connecté.

L’image ci-dessous décrit la page transfer.php

Maintenant le pirate effectue l’attaque CSRF en saisissant transfer.php comme étant l’action du
formulaire ainsi que les paramètres ‘receiver’ et ‘amount’

CSRF ne fonctionnera que si la victime potentielle est authentifiée. À l'aide d'une attaque CSRF,
un pirate peut contourner le processus d'authentification pour entrer dans une application Web.
Lorsqu'une victime avec des privilèges effectue des actions qui ne sont pas accessibles à tout le
monde, c'est lorsque des attaques CSRF sont utilisées. Tels que les scénarios bancaires en ligne.

Dans ce cas , le pirate trompe Koutheir .Il prétend la possession d’un blog similaire à Malek
( une connaissance de Koutheir).Le pirate modifie les inputs et l’action du formulaire sans que la
victime sache. Il demander Koutheir qui est déjà authentifié à l’application bancaire de saisir son
commentaire à propos cette image.

Il existe deux parties principales pour exécuter une attaque CSRF (Cross-Site Request Forgery)

1) La première partie consiste à inciter la victime à cliquer sur un lien ou à charger une page.
Cela se fait normalement par l'ingénierie sociale(social engineering). En utilisant des méthodes
d'ingénierie sociale, l'attaquant incitera l'utilisateur à cliquer sur le lien.

2) La deuxième partie consiste à envoyer une demande «falsifiée» ou forged au navigateur de la


victime. Ce lien enverra une demande d'apparence légitime à l'application Web. La demande sera
envoyée avec les valeurs souhaitées par l'attaquant. En dehors d'eux, cette demande inclura tous
les cookies que la victime a associés à ce site Web.
Par conséquent un transfert d’argent vers l’attaquant aura lieu. Notez bien que nous avons gardé
l’identité du pirate pour clarifier le processus de l’attaque.

Mitigation : CSRF token

L'implémentation la plus populaire pour empêcher (CSRF) consiste à utiliser un jeton associé à
un utilisateur particulier et qui peut être trouvé comme valeur masquée dans chaque formulaire
de changement d'état présent sur l'application Web. Ce jeton, appelé jeton CSRF ou jeton de
synchronisation, fonctionne comme suit:

1. Le client demande une page HTML contenant un formulaire.


2. Le serveur inclut un jeton dans la réponse. Un jeton est envoyé sous forme de cookie. Et
il est placé dans un champ de formulaire masqué. Les jetons sont générés de manière
aléatoire afin qu'un adversaire ne puisse pas deviner les valeurs.
3. Lorsque le client soumet le formulaire, il doit renvoyer le jeton au serveur.

Le script gentoken.php généré un jeton pour chaque session utilisateur avec l’algorithme sha1
Le script veriftoken.php assure que le jeton masqué qui est inclut dans le formulaire est
exactement égal à celui généré dans la session ouverte. Si c’est le cas , l’opération de transfert
d’argent sera effectuée.

Nous implémentons gentoken.php lors de démarrage de la session. Afin de lutter contre les
attaques CSRF
Ensuite , nous ajoutons un champ masqué en input qui aura comme valeur le token géneré lors de
la session active.

Si le jeton est valide , le transfert est possible.

Sinon le transfert échoue.