Merci beaucoup, ca me touche ! :) Oui, avec le recul que j'ai, je parviens quelques fois à faire des parallèles avec la vie de tous les jours pour expliquer les mécanismes. J'ai toujours pensé que le plus important n'était pas de "recopier" du code, mais de comprendre les mécanismes derrière :)
Très pédagogique 👏 Je rajouterai qu'il est encore mieux de générer un token CSRF aléatoire à chaque génération de formulaire, plutôt que d'avoir un token fixe pour chaque utilisateur (à l'instar de ce fait Symfony, par exemple) 🙂
Hey, super belle vidéo bien expliqué grossièrement c'est une attaque par fishing la seul différence c'est qu'enfaite on peux faire exécuter une requête a l'utilisateur implicitement et ce que j'aime bien c'est que tu fait la prévention qui va avec c'est super !
Hello, merci pour ton commentaire, ca me fait plaisir ! Oui, tu as tout bien compris ! :) J'essaie de faire la prévention en meme temps car finalement, ca compte aussi :D
Probleme cest que tu as un identifiant et password et sa, sa minteresserai de savoir comment tu les recuperes. Cest pas chiffré avec une clé specifique ? En spring boot le csrf bloque tout sauf les appelles GET nn ?
Hello super question ! :) Alors, c'est un bon début, mais un hacker peut malheureusement changer le referer, donc on ne devrait pas s'appuyer dessus en termes de sécurité. D'ailleurs, certains navigateurs essayent de combattre ca (par exemple Safari ou Chrome), mais il existe énormément de navigateurs dans lequel on peut changer le referer :) Un hacker va souvent choisir ces navigateurs là :)
Yes, tu as tout bien compris du coup ! J'en suis heureux ! Alors en particulier, y'a pas de méthodes qu'on peut utiliser pour générer ce token CSRF, mais clairement, un uuid est une de ces méthodes, bien joué ! :)
@@certifacademy je me suis appuyé sur tes vidéo sur les failles de sécurités pour présenter mon projet de fin d'année, et j'ai obtenu ma certification donc merci a toi !!
Hello, alors si j’ai bien compris, je crois voir une faille, donne moi ton avis. Je vais chez José et j’effectue une requête depuis chez lui. Son token-CSRF est consultable via F12, je n’ai qu’à recopier cette chaîne de caractère en variable, non ?
Bien sûr, néanmoins ça vaut pour la plupart des sécurités ça : Si l'attaquant a un accès à la machine (soit via code malveillant soit physique comme dans ton exemple) faut partir du principe qu'aucune mesure de sécurité ne peut l'arrêter, c'est mort. Dans ton exemple tu peux aussi recopier le cookie de connexion de José pour pouvoir l'utiliser chez toi et te connecter sur son compte (session hijacking). Le token CSRF c'est efficace uniquement pour empêcher un site d'en attaquer un autre depuis ton navigateur, sans accès physique à ta machine et sans vulnérabilité lui permettant d'y exécuter du code en dehors de sa propre page.
Comme tu l'as dit, pas dingue le token CSRF basé sur l'ID de l'utilisateur, car en réalité José étant l'admin du site il est probablement le premier compte et a donc l'ID 1. Mieux vaut utiliser un secret aléatoire. On peut même faire encore mieux en stockant le secret dans la session de l'utilisateur et donc en en changeant à chaque fois qu'il se connecte. Il y a aussi l'attribut SameSite qui permet de dire au navigateur de ne pas envoyer un cookie (en l'espèce probablement un cookie de session) en cas de requête cross site, donc pas de CSRF possible. Une bonne chose est que le CSRF est en progressive disparition avec l'attribut SameSite des cookies qui passe à Lax par défaut sur les navigateurs. Mais bon c'est pas encore ça, pour l'instant c'est pas par défaut sur Safari et Firefox par ex.
Merci beaucoup pour ton commentaire, ca me fait chaud au coeur ! J'essaie d'aider les personnes avec ce que je sais et voir ton commentaire m'encourage, merci à toi ! :)
Haha !! Merci pour ton commentaire et ca se voit que tu es une personne qui a vu mes autres vidéos haha ! Je te remercie pour ton message, c'est tellement gentil et ca me fait tellement plaisir ! :) Ce qui est top, c'est que Symfony vient déjà protégé ! En effet, à chaque fois que Symfony doit générer un formulaire, il place automatiquement un token CSRF :)
@@certifacademy plaisir partagé ! Oui j'ai suivi le blog book en intégralité et depuis lors mon niveau est passé de 2 à 7. Merci encore 🤠. J'attends avec impatience une autre playlist
@@certifacademy Un truc contre lequel Symfony ne protège pas nativement et qu'on voit malheureusement souvent c'est les opérations d'écriture déclenchées non pas par un formulaire (POST) mais par un clic sur un lien (GET). Par exemple suppression d'une donnée, voire suppression d'un compte entier. Par exemple si le site de José passe par GET pour supprimer des gâteaux et n'ajoute pas de token CSRF, tu peux tenter de faire cliquer José sur un lien bidon par email ou sur le site de voitures, lien qui en réalité déclenche la suppression de tel gâteau que tu n'aimes pas. Tu dois aussi pouvoir maquiller ça au cas où José a la présence d'esprit de regarder l'URL qui s'affiche en bas de son écran quand il passe la souris sur le lien : Tu fais un lien vers le site de voitures qui lorsqu'il est visité redirige vers l'URL de suppression.
J'ai beaucoup aimé la vidéo, très simple et explicite, en plus votre humour m'a donné le sourire. Merci beaucoup
Super bien expliqué, les exemples non-tech (pâtissier) aident énormément
Merci beaucoup, ca me touche ! :) Oui, avec le recul que j'ai, je parviens quelques fois à faire des parallèles avec la vie de tous les jours pour expliquer les mécanismes. J'ai toujours pensé que le plus important n'était pas de "recopier" du code, mais de comprendre les mécanismes derrière :)
Merci beaucoup pour cette vidéo très explicative ! J'ai trop hâte d'être adulte pour faire de la sécurité informatique comme travail
Hello, ravi que la vidéo t'ait plu ! Bonne chance pour ton futur dans la sécurité informatique, c'est un choix passionnant !
Ravi de te retrouver sur cette chaine . Toujours aussi bon pédagogue !
Merci beaucoup pour l' explication hyper compréhensible...
Très pédagogique 👏
Je rajouterai qu'il est encore mieux de générer un token CSRF aléatoire à chaque génération de formulaire, plutôt que d'avoir un token fixe pour chaque utilisateur (à l'instar de ce fait Symfony, par exemple) 🙂
Merci pour ton retour et ta suggestion avisée ! 👏
merci certif academy grace a toi j'ai réélment compri de ce que sais la faille csrf vraiment gg tes le boss est je m'abonne ps:déso pour les fautes :)
Merci, j'ai lu plusieurs articles et ensuite vidéos et toujours un peu plus confuse, puis j'arrive ici et c'est très clair, enfin! Merci
Ravie que la clarté ait prévalu ici ! Si tu as d'autres questions, n'hésite pas. Merci pour tes encouragements !
Hey, super belle vidéo bien expliqué grossièrement c'est une attaque par fishing la seul différence c'est qu'enfaite on peux faire exécuter une requête a l'utilisateur implicitement et ce que j'aime bien c'est que tu fait la prévention qui va avec c'est super !
Hello, merci pour ton commentaire, ca me fait plaisir ! Oui, tu as tout bien compris ! :) J'essaie de faire la prévention en meme temps car finalement, ca compte aussi :D
Super pédagogique ! J'adore le contenu ❤
Probleme cest que tu as un identifiant et password et sa, sa minteresserai de savoir comment tu les recuperes. Cest pas chiffré avec une clé specifique ?
En spring boot le csrf bloque tout sauf les appelles GET nn ?
Si on vérifie les entête http genre le referer ça peut le faire aussi non ?
Hello super question ! :) Alors, c'est un bon début, mais un hacker peut malheureusement changer le referer, donc on ne devrait pas s'appuyer dessus en termes de sécurité. D'ailleurs, certains navigateurs essayent de combattre ca (par exemple Safari ou Chrome), mais il existe énormément de navigateurs dans lequel on peut changer le referer :) Un hacker va souvent choisir ces navigateurs là :)
@@certifacademy top merci pour ta réponse !
Le mieux serait de mettre un uuid non?
Yes, tu as tout bien compris du coup ! J'en suis heureux ! Alors en particulier, y'a pas de méthodes qu'on peut utiliser pour générer ce token CSRF, mais clairement, un uuid est une de ces méthodes, bien joué ! :)
Super vidéo 🎉
Merci beaucoup ! J'essaie vraiment d'expliquer ces concepts pas très évidents en termes simples et je suis vraiment heureux que ca t'ait aidé ! :)
Bravo pour ta vidéo !
Merci beaucoup pour tes encouragements ! 🌟
super bien expliqué merci à toi !!
Merci beaucoup pour ton message, ca me fait sourire lorsque j'arrive à aider des personnes !
@@certifacademy je me suis appuyé sur tes vidéo sur les failles de sécurités pour présenter mon projet de fin d'année, et j'ai obtenu ma certification donc merci a toi !!
❤❤❤je vous propose de faire une vidéo pour le téléchargement de fichiers ou images en symfony avec la possibilité de l'afficher dans la page twig
c'est pas du phishing tout simplement ?
Et là, on remercie Symfony qui met en place automatiquement a vérification d'un token CSRF dans ses forms ^^
Merci pour ton message et oui, grave ! Symfony fait pas mal de choses tout seul et en effet on le remercie x)
Hello, alors si j’ai bien compris, je crois voir une faille, donne moi ton avis.
Je vais chez José et j’effectue une requête depuis chez lui. Son token-CSRF est consultable via F12, je n’ai qu’à recopier cette chaîne de caractère en variable, non ?
Bien sûr, néanmoins ça vaut pour la plupart des sécurités ça : Si l'attaquant a un accès à la machine (soit via code malveillant soit physique comme dans ton exemple) faut partir du principe qu'aucune mesure de sécurité ne peut l'arrêter, c'est mort.
Dans ton exemple tu peux aussi recopier le cookie de connexion de José pour pouvoir l'utiliser chez toi et te connecter sur son compte (session hijacking).
Le token CSRF c'est efficace uniquement pour empêcher un site d'en attaquer un autre depuis ton navigateur, sans accès physique à ta machine et sans vulnérabilité lui permettant d'y exécuter du code en dehors de sa propre page.
très intéressant pour moi qui suis front
Comme tu l'as dit, pas dingue le token CSRF basé sur l'ID de l'utilisateur, car en réalité José étant l'admin du site il est probablement le premier compte et a donc l'ID 1. Mieux vaut utiliser un secret aléatoire. On peut même faire encore mieux en stockant le secret dans la session de l'utilisateur et donc en en changeant à chaque fois qu'il se connecte.
Il y a aussi l'attribut SameSite qui permet de dire au navigateur de ne pas envoyer un cookie (en l'espèce probablement un cookie de session) en cas de requête cross site, donc pas de CSRF possible.
Une bonne chose est que le CSRF est en progressive disparition avec l'attribut SameSite des cookies qui passe à Lax par défaut sur les navigateurs. Mais bon c'est pas encore ça, pour l'instant c'est pas par défaut sur Safari et Firefox par ex.
c'est plus que cool
Merci beaucoup pour ton commentaire, ca me fait chaud au coeur ! J'essaie d'aider les personnes avec ce que je sais et voir ton commentaire m'encourage, merci à toi ! :)
ohlala jai compris ton explication alors que celle de mon prof je ne l'avais pas compris
mais mais mais c tres genial youpiiiiiiiiiiiiiiiiiiiiiiiii. Juste fallait appliquer sur le blog book. Oui Ouiiiii applique
Haha !! Merci pour ton commentaire et ca se voit que tu es une personne qui a vu mes autres vidéos haha ! Je te remercie pour ton message, c'est tellement gentil et ca me fait tellement plaisir ! :) Ce qui est top, c'est que Symfony vient déjà protégé ! En effet, à chaque fois que Symfony doit générer un formulaire, il place automatiquement un token CSRF :)
@@certifacademy plaisir partagé ! Oui j'ai suivi le blog book en intégralité et depuis lors mon niveau est passé de 2 à 7. Merci encore 🤠. J'attends avec impatience une autre playlist
@@certifacademy Un truc contre lequel Symfony ne protège pas nativement et qu'on voit malheureusement souvent c'est les opérations d'écriture déclenchées non pas par un formulaire (POST) mais par un clic sur un lien (GET). Par exemple suppression d'une donnée, voire suppression d'un compte entier.
Par exemple si le site de José passe par GET pour supprimer des gâteaux et n'ajoute pas de token CSRF, tu peux tenter de faire cliquer José sur un lien bidon par email ou sur le site de voitures, lien qui en réalité déclenche la suppression de tel gâteau que tu n'aimes pas.
Tu dois aussi pouvoir maquiller ça au cas où José a la présence d'esprit de regarder l'URL qui s'affiche en bas de son écran quand il passe la souris sur le lien : Tu fais un lien vers le site de voitures qui lorsqu'il est visité redirige vers l'URL de suppression.