« Je me connecte comme toujours à mon blog, je décide d’écrire un nouveau post génial sur Harry Potter. Entre temps, je me balade sur d’autres sites et dès lors que je retourne sur mon blog, horreur, plus aucun post. Tous les articles écrits auparavant sont effacés et je ne comprends absolument pas ce qu’il s’est passé. Je n’ai touché à rien ! »

Cette histoire pourrait bien être le résultat d’une exploitation réussie de la faille CSRF, très facile à mettre en place et très redoutable.

Qu’est ce que la faille CSRF ?

Le nom CSRF vient de Cross-Site Request Forgery qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. On n’est pas plus avancé, je sais.

En fait, il s’agit d’effectuer une action visant un site ou une page précise en utilisant l’utilisateur comme déclencheur, sans qu’il en ait conscience.

On va deviner un lien qu’un utilisateur obtient habituellement, et tout simplement faire en sorte qu’il clique lui-même sur ce lien.

Un exemple ?

faille csrf

En reprenant l’histoire ci-dessus, on peut imaginer que sur un blog donné, le lien de suppression d’un article soit le suivant :

http://www.monblog.fr/del.php?id=1

Ici, id=1 signifie qu’on souhaite supprimer l’article dont l’identifiant est 1, typiquement il s’agit du premier article.

Si maintenant un visiteur non connecté à la page d’administration clique sur un tel lien, il aura un message du type :

Vous n’avez pas les droits pour supprimer cet article, veuillez vous connecter et réessayer.

Normal, un visiteur quelconque n’a pas le droit d’éditer ou supprimer les articles d’un blog qui ne lui appartient pas.

Mais si maintenant le visiteur quelconque connait ce lien, il lui suffit d’envoyer le lien à l’administrateur en faisant en sorte que ce dernier clique.

Que se passe-t-il une fois que l’administrateur clique ?

Le lien de suppression s’exécute avec succès car l’administrateur est bien connecté et son article se retrouve ainsi supprimé.

Si vous voulez voir un exemple réel, dirigez vous dans la partie Mise en situation de la faille CSRF.

Comment se protéger contre la faille CSRF ?

Habituellement, si vous utilisez un système de gestion de contenu (CMS) du type WordPress ou Joomla, qui est un minimum protégé, vous n’avez pas grand chose à faire. Enfin…presque.

Si, à l’inverse, vous utilisez un système vieux ou que vous avez programmé vous-même, ce risque est bien présent.

Pour se protéger contre la faille CSRF, on utilise habituellement 2 principes complémentaires :

L’authentification par jeton

Un jeton (aussi appelé token en anglais) est un nombre ou une chaîne de caractère aléatoire qui va être testée avant toute modification ou édition d’un article.

Il se présente habituellement sous forme de hash md5 comme celui-ci :

b6cf20590a57f4685c9bdc6c53d12ff8

Ce token doit être crée dans un fichier PHP qui sera appelé sur toutes les pages. Typiquement, il s’agit d’un fichier du type config.php ou functions.php.

On génère souvent un nombre « aléatoire » avec des fonctions utilisant le temps en PHP. Par exemple on peut générer un jeton avec :

md5(uniqid(mt_rand(), true));

La fonction uniqid() génère un identifiant unique basé sur le temps en microsecondes. Cependant PHP ne recommande pas cette fonction car elle ne génère pas des chaînes impossible à deviner à l’avance.

Du coup, on va plutôt utiliser :

md5(bin2hex(openssl_random_pseudo_bytes(6)));

qui est cette fois hautement sécurisé.

La fonction openssl_random_pseudo_bytes() génère une chaîne pseudo-aléatoire d’octets de taille 6 bits * 2 qu’on convertit ensuite en hexadécimal, 6 étant le nombre donné en paramètre de la fonction (on peut le changer).

Ainsi, dans un fichier PHP global on va écrire le code suivant :

<?php
if (!isset($_SESSION['jeton'])) {
   $_SESSION['jeton'] = bin2hex(openssl_random_pseudo_bytes(6));
}
?>

Ce code signifie : Si le jeton de session n’est pas encore défini, on le génère aléatoirement et on l’enregistre pour la session courante.

Ensuite, à chaque connexion d’un utilisateur, on va devoir générer un jeton qui lui est propre.

Pour cela, on peut avant chaque connexion régénérer le jeton, en supprimant le jeton de la session précédente :

unset($_SESSION['jeton']);

Il reste ensuite à modifier dynamiquement les liens de suppression, admettons que le lien précédent était écrit de la forme :

<a href="http://www.monblog.fr/del.php?id=<? echo get_article_id(); 
?>>Supprimer l'article</a>

On le remplace par :

<a href="http://www.monblog.fr/del.php?id=<? echo get_article_id() . 
"&jeton=". $_SESSION['jeton']; ?>>Supprimer l'article</a>

L’url de suppression s’affichera donc comme ceci :

http://www.monblog.fr/del.php?id=1&jeton=b6cf20590a57f4685c9bdc6c53d12ff8

Au lieu de s’afficher comme cela :

http://www.monblog.fr/del.php?id=1

Et enfin, dans notre fichier de suppression del.php, on va s’assurer qu’il existe un jeton et que ce jeton soit valide. Le fichier, avant toute modification se présentait comme cela :

<?php
if(isset($_GET['id'])) {
   supprimer_article($_GET['id']);
} else {
   die("Aucun ID d'article sélectionné.");
}
?>

Il devient donc :

<?php
if(isset($_GET['id']) && isset($_GET['jeton']) && 
($_GET['jeton'] == $_SESSION['jeton'])) {
   supprimer_article($_GET['id']);
} else {
   die("ID ou jeton de session invalide.");
}
?>

Ce qui  signifie : Si l’id de l’article est défini mais aussi le jeton et que ce jeton correspond au jeton de la session actuelle, alors on peut supprimer.

Dernière note, on utilise $_GET qui récupère les paramètres depuis une URL, il aurait été préférable est encore plus sécurisé d’utiliser $_POST avec un formulaire pour ne pas afficher de jeton dans les URLs.

La demande de confirmation

Que ce soit pour éviter les suppression par erreur ou les tentatives d’exploitation de la faille CSRF, il est indispensable de demander confirmation de suppression d’un article.

Ici, si je clique sur supprimer mon article et qu’il est immédiatement et définitivement supprimé, il faut réfléchir à trois fois avant de cliquer.

Cette méthode est beaucoup utilisée pour redéfinir un mot de passe : On demande d’abord l’ancien.

Attention aux techniques de sécurisation de la faille CSRF qui ne fonctionnent en fait pas vraiment.

On entend souvent dire que pour se prémunir contre la faille CSRF, il faut vérifier la variable PHP HTTP_REFERER qui indique de quel site provient l’utilisateur. Si il provient d’un site différent, il ne sera alors pas autorisé à éditer l’article.

Oui c’est une bonne idée à la base (et c’est toujours une protection complémentaire), sauf que le lien référent (HTTP_REFERER) peut être modifié (on dit spoofé).

Cette variable est définie par le navigateur, donc du côté client. C’est-à-dire que je peux très bien poster le lien http://www.monblog.fr/del.php?id=1 depuis un autre site, tout en faisant croire qu’il provient bien du même site, exemple avec cURL :

curl_setopt($ch, CURLOPT_HTTPHEADER, array(
        'Host: www.monblog.fr',
        'Referer: www.monblog.fr', 'FauxHEADER: FauxHeaderQuiSeraEnvoye')); 

Dernière remarque

Ajax (Asynchronous JavaScript and XML) permet d’effectuer des actions sans recharger la page. Typiquement c’est ce qu’il se passe lorsque vous cliquez sur le bouton J’aime de Facebook. La requête est envoyée en arrière plan et le bouton devient enfoncé lorsque la réponse du serveur est arrivée.

Du coup la question de la faille CSRF se pose, que se passe-t-il si l’on essaie de supprimer un post en utilisant Ajax ?

La réponse est simple, Ajax utilise la Same-origin policy (politique de la même origine) qui empêche l’exécution de code à travers sites. Le terme « origine » est défini à propos du protocole, du nom de domaine et du port : deux pages ont la même origine si et seulement si ces 3 valeurs sont les mêmes.

Envie d’en apprendre plus sur les failles web ?

Cette faille et bien d’autres est vue en détail dans mon cours vidéo sur les tests d’intrusion web.

Nous allons parler des fondamentaux : fonctionnement d’HTTP, d’HTTPs, de DNS et de l’architecture web de manière générale.

Nous allons également mettre en place un laboratoire de test avec des machines virtuelles pour héberger et scanner nos sites vulnérables afin d’apprendre sans rien casser.

Nous allons bien sûr parler de toutes les failles web (XSS, CSRF, SQL, LFI, RFI, …etc) en suivant le Top 10 OWASP mais aussi de tout ce qui gravite autour de la sécurité web : dénis de service, mauvaises configurations, données personnelles, reconnaissance, etc…
Impatient de commencer avec vous, je vous propose un code de réduction pour pouvoir rejoindre le cours dès maintenant : https://cyberini.com/cours/hacking-ethique-tests-intrusion-web/

Articles similaires

16 Commentaires
Cliquez ici pour ajouter un commentaire

  • Merci de l’article, j’ai appris ce qu’est une faille CSRF !

    Répondre
  • Merci de ce magnifique article 😉

    Répondre
  • Je ne conaissais pas non plus cette faille, merci Michel 🙂

    Répondre
  • […] enfin, on pourrait très bien appliquer le ClickJacking à la faille CSRF, résultat : On peut potentiellement pirater un site […]

    Répondre
  • […] Explications & Prévention sur la faille CSRF […]

    Répondre
  • Merci pour le tuto!………………trop cool!! votre site! surtout avec la mise en situation! bref au top!

    Répondre
  • Merci pour l’explication, claire.
    Un bon prof.

    Répondre
  • TEBANI Mohamed
    23 juin 2019 1 h 51 min

    Merci beaucoup

    Répondre
  • Je viens de lire tout tes articles concernant le hacking Ethique sur les Faille Web, d’après ce que j’en déduis tu es axé sur la prévention de ces attaques, tu expliques le principe de l’attaque (XSS, InjectionSQL, Include, CSRF), un exemple très basique sur l’utilisation, et après comment s’en prévenir.

    Ma question est la suivante, et tu réellement capable d’utiliser ce genre d’attque en situation réelle ? En utilisant des techniques et des connaissances plus avancé que ce tu présentes (je pense notament à des notions avancer en SQL, et en Javascript) , ou ces articles étaient juste à but d’informations et prévention, car d’après le nom de blog, on pourrait penser que tu es un Hacker Ethique.

    Et pour terminer, est ce que tu programmes réellement, ou tu utilises juste des CMS comme WordPress avec lequel tu as conçu ton site?

    Répondre
  • Suite à mon dernier commentaire, Pourquoi tu les soumets à vérification et validation ? Je trouve dommage de limité la liberté d’expression.

    Répondre
  • Merci beaucoup ! J’ai enfin compris ce qu’est une attaque CSRF. Vraiment bien expliqué. 🙂

    Répondre
  • salut michel pas mal ton truc sûr les sandbox très intéressant sujet sympa comme tout pour les gens qui font leur début
    avec cela très belle exemple de ta part un grand bravo pour le temps passer où tu donne quelque façon de protéger
    son blog comme j’ai vue dans les commentaire de certain . où les réponse que tu donne sont toujours très bonne

    ont te le dit pas assez michel un grand merci pour cela ici je répond pour tout les gens que tu aide comme tu le peut
    à ta façon. car il est vrai que pour les simple internaute que nous sonne. on imagine pas tout le travail
    qui à derrière tout cela pour répond à tousse en un temps plus sous moins long où court c’est selon. encore merci pour
    tout michel.

    donc ici pour na part je donne des détail en plus sur les sandbox et les malveillance. utiliser par les pirate.

    en observant les fichiers dans ces environnement virtuels les systèmes de sécurité peuvent repérer des comportements
    suspects. par exemple des modifications apportées au système d’exploitation ou des appels transmis aux serveurs

    de commande et de contrôle des cybercriminels.

    mais les pirates ont eux aussi affiné leurs techniques. sachant que leur code peut être exécuté dans un environnement
    sandbox avant qu’il atteigne sa cible. ils créent du code capable de reconnaître des machines virtuelles et de

    dissimuler tout signe de leur comportement malveillant avant d’avoir accès à leur véritable proie.
    comme aucune action suspecte n’est détectée dans l’environnement sandbox .

    l’analyse de sécurité considère le code comme étant inoffensif. pour les auteurs de logiciels malveillants.
    il est capital de déterminer si le code s’exécute dans un environnement virtuel ou sur un ordinateur cible réel.

    à cette fin ils ont développé toute une série de techniques.

    interactions humaines

    les environnement sandbox d’exécution de fichiers émulent les systèmes physiques mais sans utilisateur humain.
    les auteurs d’attaques exploitent cette différence essentielle à leur avantage en créant des logiciels malveillants

    qui restent inactifs jusqu’à ce qu’ils détectent des signes d’une manipulation humaine. un clic de souris.
    une réponse intelligente à des boîtes de dialogue etc. cette section décrit ces contrôles plus en détail.

    clics de souris . upclicker un cheval de troie analysé en décembre 2012 fut l’un des tout premiers logiciels
    malveillants à utiliser des clics de souris pour détecter des activités humaines. une technique similaire mais plus

    simple était apparue quelques mois plus tôt. pour tromper les environnements sandbox.upclicker n’établit la connexion
    avec les serveurs de commande et de contrôle qu’après avoir détecté un clic du bouton gauche de la souris.

    upclicker est un fichier conteneur. wrapper qui encapsule poison ivy un outil d’accès distant fréquemment
    associé aux attaques de menaces persistantes avancées.

    ce code surveille l’exécution d’un clic gauche de la souris et plus spécifiquement un relâchement de clic
    en anglais up-click terme qui a donné son nom au cheval de troie. lors du relâchement d’un clic.

    le code appelle la fonction unhookwindowshook ex() pour interrompre la surveillance de la souris avant d’appeler
    la fonction sub-40 1170 () pour exécuter le code malveillant. six mois après upclicker banechant un autre fichier

    associé aux menaces persistantes avancées a amélioré le concept puisqu’il ne s’active qu’après trois clics de souris.

    pour détecter une cible réelle une autre méthode consiste à afficher une boîte de dialogue qui demande une
    réponse de la part de l’utilisateur. pour ce faire les logiciels malveillants utilisent les fonctions d’api windows

    message box et message box ex pour créer des boîtes de dialogue dans des fichiers exe et dll.
    le logiciel malveillant s’active uniquement après que l’utilisateur clique sur un bouton.

    de la même façon les logiciels malveillants peuvent utiliser java script pour ouvrir une boîte de dialogue
    dans des fichier pdf adobe acrobat à l’aide de méthode app.alert () documentée dans l’api java script

    pour acrobat. lorsque l’utilisateur clique sur ok le code utilise la méthode app. launchurl pour ouvrir une url
    malveillante

    configuration

    même s’ils émule fidèlement les ordinateurs physiques qu’ils protège les environnements virtuels sandbox
    sont configurés selon un ensemble de paramètres définis. les cybercriminels familiers de ces configurations

    ont appris à les contourner. appels de mise en veille.

    compte tenu de la masse d’échantillons de fichiers à examiner. les environnements sandbox d’exécution de fichiers
    surveillent généralement un fichier pendant quelques minutes et en l’absence d’un comportement suspect.

    passent au fichier suivant. dés lors pour les contourner il suffit au auteurs de logiciels malveillants d’attendre la
    fin de la surveillance de l’environnement sandbox.

    en ajoutant des appels de mise en veille prolongée. le logiciel malveillant s’abstient de tout comportement
    suspect pendant la durée de la surveillance. pour exemple le cheval de troie nap découvert en février 2013

    adopte ce type de comportement. il est associé au réseau kelihos qui selon microsoft et kaspersky aurait été
    démantelé en 2011.

    lors de son exécution le logiciel malveillant envoie une demande http de téléchargement du fichier
    newbos2.exe depuis wowrizep.ru un domaine malveillant connu.
    le code appelle la méthode sleep ex () avec une valeur de paramètre d’expiration de 0x0927co
    600 000 millisecondes soit 10 minutes. par ailleurs l’attribut du champ alterable est défini avec la valeur

    false pour éviter que la fonction de programmation soit renvoyée avant 10minutes.
    ce qui représente un délai plus long que celui généralement consacré par la plupart des environnements

    sandbox à l’exécution d’un échantillon de fichier. le code appelle également la méthode d’api non documentée
    ntdelay-execution () pour bénéficier d’une mesure supplémentaire destinée à retarder tout action suspecte.

    les fichiers pdf malveillants peuvent utiliser une méthode similaire dans l’api java script pour acrobat.
    appelée app. set timeout (). le code d’un fichier pdf malveillant qui utilise cette méthode pour attendre

    100 000 000 millisecondes.. soit environ 16 minutes avant d’appeler une fonction malveillante appelée
    mystr ().

    déclencheurs temporels

    il arrive parfois que les appels d’api de mise en veille soient utilisés avec des déclencheurs temporels
    afin d’exécuter le logiciel malveillant seulement après une date et une heure données.

    les environnements sandbox qui surveillent le fichier avant cette date ne détectent rien d’inhabituel.

    à titre d’exemple citons le cheval de troie hastali utilisé dans le cadre d’une attaque de destruction massive
    de données menée en mars 2013 en corée du sud. hastali utilise la méthode d’api get localtime ()
    qui importe un pointeur vers la structure systemtime de windows pour déterminer la date et l’heure

    locale actuelles. si la machine virtuelle ne surveille pas le fichier à cette date le logiciel échappe à la détection.

    la structure systemtime renvoie les valeurs suivantes en mémoire les paires hexadécimales sont stockées dans
    l’ordre inverse

    07 dd wYEART- 2013 correspond à l’année
    00 06 wMONTH-JUIN correspond au mois
    00 O1 wDAYWEEK-LUNDI correspond au jour de la semaine

    00 11 wday-17 correspond à la date dans ce cas le code malveillant s’exécute car la date du jour lundi 17
    juin 2013 a dépassé la date de déclenchement 20 mars 2013 à 14 heures. mais si la date du jour

    n’a pas atteint la date de déclenchement le logiciel malveillant appelle une fonction sleep avec la valeur oea 60
    60 000 millisecondes passé ce délai le code vérifie à nouveau la date et l’heure.

    si la date de déclenchement n’est pas encore atteinte il rappelle la fonction de mise en veille
    et ainsi de suite.en répétant la boucle jusqu’à la date de déclenchement.

    Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous devez remplir ce champ
Vous devez remplir ce champ
Veuillez saisir une adresse e-mail valide.

Menu