Maintenant que nous savons découvrir et exploiter Oui nos vulnérabilités.
Parlons de la façon de protéger les sites Web contre eux.
Donc, si nous revenons à GVW 8 et que nous disons que la sécurité est trop élevée, vous constaterez qu’ils disposent d’un moyen très simple de
se protéger, mais que cette méthode fonctionne réellement.
Et ce qu'ils font, c'est qu'ils vous demandent le mot de passe actuel.
Donc, même si nous obtenons ce formulaire et que nous procédons à toutes les opérations de forgeage et à tout ce que nous
faisions, puis que nous l'envoyons à la personne ciblée, nous ne pouvons pas réellement cacher cela et le soumettre automatiquement, car nous ne
connaissons pas la mot de passe.
Donc, il demande le mot de passe actuel, puis vous permet d'ajouter un nouveau mot de passe.
C'est donc une très bonne solution pour ce cas.
Bien que parce que si le formulaire ne change pas réellement votre mot de passe.
Et si nous envoyions des messages prétendant être cette personne?
Et si nous devions poster des choses sur le mur de cette personne?
Et si nous allons poster des choses sur le blog de cette personne.
Donc, depuis Aref peut être exploité pour faire beaucoup de choses.
Comme je l'ai dit dans les vidéos précédentes, cette méthode ne protégera que contre le changement de mot de passe.
Vous ne pouvez pas vraiment demander à la personne son mot de passe chaque fois qu'elle souhaite publier ou modifier
quelque chose avec son profil.
Maintenant, les nouvelles versions de DVD lorsque vous avez besoin du protocole de test qui ne vient pas avec moi sont en fait
une option plus sécurisée qui implémentera la méthode que je vais vous en parler.
Maintenant, cela s'appelle en fait impossible au lieu de élevé, mais peu importe, il n'est pas exploitable,
nous n'avons donc pas besoin de l'installer.
Discutons donc de la manière dont vous pourriez réellement empêcher ces vulnérabilités sans demander à
l'utilisateur de ressaisir les informations ou de ressaisir le mot de passe.
Si vous y réfléchissez de la manière dont nous avons pu l'exploiter, nous n'avons pu
que copier le formulaire utilisé par le site Web, l'envoyer à la personne cible et le faire exécuter ou s'exécuter
automatiquement sur son ordinateur.
Donc, une fois que la demande est envoyée au serveur ou que le serveur n’effectue
aucune validation, l’utilisateur souhaite réellement changer son mot de passe.
Par conséquent, le meilleur moyen d’empêcher toute faille est de s’assurer que l’utilisateur soumet des données via une page
qui lui a été fournie par l’application Web et non par une autre personne.
Un bon moyen d'implémenter cela consiste à utiliser des jetons de synchronisation.
Maintenant, je sais que le nom a l'air compliqué, mais l'idée est très simple.
Fondamentalement, nous voulons générer un jeton unique et aléatoire du côté serveur.
Ensuite, lorsque la page est chargée lorsque le formulaire est chargé, nous allons incorporer ce jeton déjà
généré dans cette page en tant que formulaire masqué.
Ensuite, lorsque le formulaire est soumis, nous allons nous assurer qu'il a bien été envoyé avec le jeton
que nous avons envoyé à cet utilisateur spécifique.
Donc, fondamentalement, nous donnons un jeton à l'utilisateur et nous attendons qu'il soumette le formulaire avec le jeton que nous lui
avons donné.
Ainsi, le jeton obtenu par le pirate informatique ne fonctionnera que pour lui.
Ainsi, même s’il génère une page et l’envoie à la cible et que la cible lève la
page, le formulaire sera soumis mais le serveur le refusera car il n’a pas donné ce jeton à cet
utilisateur, il a donné ce jeton au pirate, Par exemple, nous avons cet utilisateur ici et ici, il en coûte BHB, le
mot de passe Facebook dot com.
Cela va au serveur.
Le serveur va générer une réponse pour cette demande.
Donc, il va retourner la page de courrier électronique qui représente les mots de passe ph être dans cette page.
Il va inclure un jeton unique.
Ainsi, lorsque la page est chargée côté client, le formulaire recherché par l'utilisateur
est déjà ajouté, ainsi qu'un jeton unique généré par le serveur.
Ensuite, lorsque l'utilisateur soumet ce qu'il souhaite, le serveur n'accepte que le formulaire et répondra
ou répondra à la demande de l'utilisateur.
Si l'utilisateur retourne le même jeton.
Maintenant, si cela n'est pas implémenté correctement, il peut toujours être exploité.
Donc, si le jeton était prévisible ou si le même jeton était utilisé, le pirate informatique peut découvrir ce que
le jeton est incorporé dans le code HDMI et l'envoyer à l'utilisateur.
Le jeton doit donc avoir certaines caractéristiques pour être sécurisé.
Et fondamentalement, l’essentiel est de garder à l’esprit que le jeton doit être imprévisible et qu’il ne
peut être utilisé quelle que soit la façon dont vous allez le mettre en œuvre.
Ce sont les deux choses principales que vous voulez garder à l'esprit car si elles
étaient prévisibles, les pirates informatiques pourront créer leurs propres jetons, puis les intégrer au code et lancer l'attaque.
Le même jeton peut être utilisé.
Ensuite, les pirates peuvent simplement utiliser leur jeton ou celui de quelqu'un d'autre pour cibler leur cible.
Donc, afin de rendre le jeton imprévisible et de le rendre utilisable, le jeton doit être une
valeur importante pour que le pirate informatique ne puisse pas attaquer par la force brutale et découvrir à quoi sert le jeton.
afin que le pirate informatique ne puisse pas créer ses propres jetons et qu'il soit unique pour chaque utilisateur,
car si les utilisateurs reçoivent le même jeton ou des jetons similaires, ils peuvent les faire circuler et
le jeton qui fonctionne pour le pirate fonctionne les autres gens.
Donc, ça va définir le point entier.
Vous pouvez également augmenter la sécurité du jeton en incluant d'autres facteurs et l'algorithme de génération
de jeton.
Ainsi, vous pouvez inclure par exemple la date et l'heure.
Ensuite, combinez-le avec un générateur aléatoire sécurisé, puis chiffrez-le.
Tout cela se passe évidemment du côté serveur.
Ainsi, le pirate informatique ne pourra pas savoir quel algorithme vous utilisez car le code sera
exécuté côté serveur.
Vous n'êtes pas obligé de le faire en utilisant un nombre aléatoire sécurisé important et unique, cela suffit.
Mais si vous souhaitez augmenter la sécurité, vous pouvez simplement ajouter d'autres facteurs et chiffrer le jeton avant
de l'envoyer à l'utilisateur.
Ceci est effectivement mis en œuvre dans Matile Day.
Alors permettez-moi de vous le montrer en action.
Donc, je vais juste aller à Matile jour ici.
Je vais aller sur une guêpe alors oui ou comme un ajout au blog.
Cela vous permet donc d’ajouter un article de blog afin de ne pas modifier votre mot de passe ou
quoi que ce soit d’autoriser les personnes anonymes à nos articles de blog.
Donc, vous ne pouvez pas vraiment demander aux gens un mot de passe.
En fait, je vais faire basculer la sécurité de manière à ce que ce soit la plus élevée, car elle est à zéro pour le moment.
Alors maintenant, c'est le plus sécurisé.
Et si vous cliquez avec le bouton droit de la souris sur ceci et continuez, c’est élément d’inspection.
Maintenant, je vais faire défiler vers le haut et comme vous pouvez le constater, nous avons le forum ici et nous avons une entrée cachée avec
une très longue valeur.
Et c'est le jeton.
Donc, cela a déjà été généré par le serveur et le serveur refusera toutes les demandes
que nous lui enverrons sauf s'il possède ce jeton spécifique.
Et si j'utilise ce formulaire et l'envoie à quelqu'un d'autre.
Ensuite, les demandes qu’ils enverront seront refusées car ils recevront un jeton différent. Ce jeton a
été généré pour moi et pour moi uniquement.
Alors permettez-moi de vous montrer que si je rafraîchis actuellement, je vais obtenir un autre jeton.
Et encore une fois si j'actualise à nouveau, j'obtiendrai un jeton différent si je le modifie.
Supposons donc que je mette un petit I au lieu de la capitale, si je soumets ceci maintenant,
cela me donne une erreur.
Mais laissez-moi ne pas changer cela si encore une fois, j’ai reçu un jeton différent maintenant et si je soumettais simplement le
message ainsi, cela fonctionnerait et nous avons maintenant une entrée de blog appelée test.
Alors c'est tout.
C'est en fait très très simple.
Je ne voulais pas entrer trop dans les détails sur la façon de créer un jeton aléatoire et tout
ça parce que cela dépendra du langage de programmation.
C'est l'application Web est programmée dans.
Mais j’ai voulu vous montrer le concept ou l’idée de la sécurisation des applications Web contre ce
type de vulnérabilité.
L'idée principale est de vous assurer que l'utilisateur envoie ses données via une page que vous lui présentez et non
par une page qui lui a été fournie par une autre personne.
Donc, pour ce faire, nous générons un jeton côté serveur, ce jeton doit être long et unique, envoyer
ce jeton avec la page avec le formulaire et incorporé en tant que formulaire masqué.
Et puis chaque fois qu'un utilisateur soumet la réponse, assurez-vous qu'il soumet le même jeton que celui qui lui a
été donné.