Que sont les attaques de falsification de requêtes intersites (CSRF) ?

Les attaques de falsification de requêtes intersites (CSRF) peuvent être difficiles à comprendre. Il peut y avoir de nombreuses variations dans ces attaques, il peut donc être difficile de voir ce qui se cache réellement derrière elles.

En bref, les falsifications de requêtes intersites impliquent les attaquants incitent votre navigateur Web à envoyer leurs fausses requêtes au serveur . Parce que ces demandes semblent provenir de votre navigateur et inclure vos données d’authentification, le site Web pense qu’elles sont légitimes.

Le serveur accède à la requête, qui pourrait être de changez votre mot de passe, changez l'email associé à votre compte, ou même volez de l'argent sur votre compte bancaire . Tout cela peut se produire sans que vous cliquiez sur quoi que ce soit, et même à votre insu. En fin de compte, les attaques CSRF peuvent avoir des conséquences dévastatrices, car elles peuvent donner aux attaquants le contrôle total des comptes.

Attaques de falsification de requêtes intersites sont également connus sous le nom de liens hostiles ou de session riding. Le sigle CSRF est souvent prononcésurf en mer, et le C est parfois remplacé par un X pour former XSRF.

Si vous êtes complètement perplexe face à ces attaques, ou si vous avez une idée approximative, mais ne comprenez pas complètement comment elles fonctionnent, ne vous inquiétez pas. Nous allons présenter chacun des concepts clés lentement et en détail, de sorte qu'à la fin de l'article, vous ayez une solide compréhension de ce que sont réellement les attaques de falsification de requêtes intersites.

N'hésitez pas à sauter les parties que vous connaissez déjà : tout le monde n'a pas les mêmes connaissances de base, et il est préférable d'en couvrir plus que ce qui est nécessaire pour certaines personnes, plutôt que de sous-expliquer les concepts clés, puis de vous obliger à chercher frénétiquement sur le Web. pour répondre à tes questions.

Que sont les attaques de falsification de requêtes intersites ?

Commençons par décomposer le nom. Dans ce cas, cela illustre assez bien l’essence même de ces attaques. D’un côté, nous avons le « cross-site », qui fait allusion au fait que l’attaque provient d’un site mais agit sur un autre.

L’autre élément est la « demande de contrefaçon ». C’est assez évident : ces attaques impliquent d’une manière ou d’une autre que quelqu’un falsifie des requêtes. Ainsi, lorsque nous réunissons ces deux concepts, nous avons des attaquants qui forgent des requêtes qui proviennent d'un site, mais agissent sur un autre.

Contrefaçons de requêtes intersites (CSRF) et changements d’état

L'une des premières choses que vous devez comprendre est que les falsifications de requêtes intersites impliquent changer l’état des données sur le serveur d’un site Web . Cela signifie simplement que l’attaquant envoie une demande de modification des données sur le serveur au nom de la victime. Si la demande est acceptée, les données sont modifiées.

Ceci est dû au fait Les attaques CSRF ne donnent aux pirates aucune visibilité sur la réponse du serveur à la victime . Forger des requêtes demandant des données sensibles serait inutile, car les données sensibles seraient envoyées à la victime et non à l'attaquant.

Même si les attaques CSRF ne permettent pas aux pirates de voler directement des données, la modification de l’état des données sur un serveur peut néanmoins constituer une mesure puissante qui cause un préjudice important à la victime. Un attaquant pourrait falsifier une requête envoyée via le navigateur de la victime, demandant au serveur d’envoyer des fonds du compte de la victime vers un compte contrôlé par l’attaquant.

Dans ce cas, la demande consiste à modifier l’état du solde bancaire de la victime. S’il est accepté par le serveur, l’attaquant peut s’enfuir avec l’argent de la victime. Même si le serveur n’envoie jamais d’informations à l’ordinateur de l’attaquant, la requête incite la banque à envoyer de l’argent sur le compte de l’attaquant. .

De même, les attaquants peuvent envoyer de fausses requêtes via le navigateur de la victime qui demander de changer le mot de passe de la victime pour quelque chose que l'attaquant connaît . Si le serveur accepte la demande, l’attaquant pourra facilement s’emparer du compte de la victime une fois le mot de passe modifié.

Les attaquants peuvent obtenir le même résultat s’ils forgent une demande visant à remplacer l’adresse e-mail du compte de la victime par une adresse appartenant à l’attaquant. Ils peuvent alors demander au site de réinitialiser le mot de passe, et l'e-mail d'authentification sera directement envoyé à l'attaquant plutôt qu'au propriétaire du compte. À partir de ce point, ils changent le mot de passe et le compte est entre leurs mains .

Bien que les falsifications de requêtes intersites dans ces attaques n’impliquent pas directement que le site Web envoie des données utilisateur à l’attaquant, ces deux derniers exemples permettent à l’attaquant de voler facilement des données une fois qu’il contrôle le compte. Ils montrent à quel point la modification de l’état des données sur le serveur peut être dévastatrice.

Les conditions nécessaires aux attaques de falsification de requêtes intersites (CSRF)

Les falsifications de requêtes intersites nécessitent qu'une série de conditions soient remplies pour que ces attaques soient des options viables. Ceux-ci inclus:

Ils doivent cibler sites Web sur lesquels les utilisateurs peuvent demander des modifications à l'état des données sur le serveur

Les attaques CSRF sont utilisées pour contourner les processus d'autorisation et d'authentification normalement en place. Cela signifie que ces attaques sont inutiles sur les sites Web statiques et les sites sur lesquels il n’existe aucun compte d’utilisateur pouvant demander de modifier l’état des données sur le serveur.

Les attaquants ne s’intéresseront aux attaques CSRF que si ces changements d’état du serveur peuvent réellement leur être bénéfiques, par exemple s’ils peuvent effectuer des transferts de fonds ou s’emparer de comptes disposant d’accès ou d’informations précieux.

Victimes doit être connecté au moment de l'attaque

De nombreux sites Web utilisent la session biscuits avec des identifiants uniques pour accorder aux utilisateurs l’accès aux pages autorisées. Ceux-ci sont générés lorsque les victimes se connectent pour la première fois et ne durent que pendant la session, ce qui signifie que les victimes doivent être connectées au moment où la fausse demande est envoyée pour que les attaques CSRF réussissent.

Lorsqu'ils sont connectés, les attaquants peuvent tromper les navigateurs de leurs victimes et leur envoyer des requêtes que l'utilisateur n'avait pas l'intention de faire. Ces requêtes malveillantes sont acceptées par le serveur car elles incluent le cookie de session de la victime, ce qui les fait paraître légitimes au serveur.

La majorité des attaques de falsification de requêtes intersites impliquent de tirer parti de l'authentification par cookie de session. Toutefois, certains systèmes d'authentification moins courants peuvent également être compromis par des attaques CSRF.

Les victimes doivent visiter la page qui héberge la fausse demande

L'attaquant doit trouver un moyen d'inciter les victimes à visiter une page spécifique qui héberge la fausse demande. Cela peut être relativement simple dans le cas de contrefaçons de requêtes intersites stockées, dont nous parlerons plus tard. Sinon, il faudra peut-être attirer les victimes vers un site Web distinct et les inciter à cliquer sur un lien ou à déclencher automatiquement la demande malveillante via des scripts.

Le site Web a besoin de paramètres prévisibles

Afin de forger une requête qui sera effectivement acceptée par le serveur, l'attaquant doit savoir à quoi ces requêtes sont censées ressembler . Expliquons pourquoi cela est important avec une analogie.

Si vous souhaitez falsifier un chèque et l’encaisser à la banque, vous devez d’abord savoir comment rédiger correctement un chèque. Si vous aviez écrit le nom dans la case pour la date, le numéro de compte comme montant, et fait tout un tas d'autres erreurs, la banque rejetterait tout simplement votre faux chèque et vous n'obtiendriez jamais l'argent que vous désirez.

C’est similaire si un attaquant veut pouvoir modifier l’état des données du serveur en sa faveur. Ils doivent savoir comment le site Web formate généralement les demandes si vous souhaitez pouvoir falsifier une demande qui sera réellement acceptée. Si un attaquant tentait de modifier le mot de passe d'un compte, mais que les valeurs étaient incorrectes ou dans le mauvais ordre, la demande serait rejetée et il perdrait son temps.

Cela signifie que pour que les attaques CSRF réussissent, le site Web doit avoir des paramètres prévisibles . Si chaque requête suit le même format prévisible, un attaquant peut examiner les requêtes précédentes et abuser de ces connaissances pour forger une requête dont le format est réellement correct. Si la requête nécessite des mots de passe, des identifiants ou des valeurs d'authentification secrètes que l'attaquant ne peut pas deviner, il ne pourra pas mener à bien une attaque de falsification de requête intersites. .

Retour aux sources : comprendre l'écosystème de sécurité contourné par les attaques CSRF

Maintenant que nous avons couvert les conditions de base nécessaires aux attaques de falsification de requêtes intersites, c’est une bonne occasion de prendre du recul et d’examiner les éléments importants du paysage de la sécurité que ces attaques tentent de contourner. Il peut être difficile de comprendre véritablement pourquoi les attaquants se tournent vers les attaques CSRF si vous n’êtes pas familier avec les systèmes déjà en place.

Comptes

Sauf si vous êtes Amish ou Luddite, vous disposez probablement de nombreux comptes différents pour les différents services Web que vous utilisez. Vous disposez probablement de comptes pour votre courrier électronique, vos réseaux sociaux, vos opérations bancaires et bien plus encore.

Mais pourquoi avez-vous ces comptes en premier lieu ?

Parce que vous faites souvent des choses importantes sur ces sites . Pour qu’un site Web de banque en ligne soit réellement utile, il doit vous permettre de vérifier votre solde, d’envoyer de nouveaux virements et d’effectuer toute une gamme d’autres actions. Vous devrez peut-être également changer votre mot de passe à certains moments et mettre à jour vos informations personnelles.

S’il est essentiel que les sites Web vous permettent d’effectuer chacune de ces tâches, il est essentiel que les sites vous autorisent uniquement à les faire . Si quelqu’un pouvait utiliser le site Web bancaire pour s’envoyer de l’argent ou changer votre mot de passe, le chaos qui en résulterait serait bien plus préjudiciable que les avantages offerts par le service.

Les comptes aident à contrôler les informations et les systèmes auxquels vous êtes autorisé à accéder. Si un fournisseur de messagerie disposait simplement d'un système d'honneur et stockait tous les e-mails dans une base de données accessible à tous, personne ne pourrait bénéficier d'une quelconque confidentialité dans ses communications.

Lorsque nous traitons d’informations importantes, il est souvent préférable d’avoir des comptes d’utilisateurs qui limitent ce à quoi chaque individu peut accéder. . Ceci est particulièrement important lorsque la confidentialité est cruciale ou si les modifications apportées par quelqu’un d’autre pourraient avoir des effets négatifs.

À titre d’exemple de cas où les comptes d’utilisateurs ont du sens, la plupart d’entre nous n’ont pas de compte Wikipédia, car la plupart des gens ne sont pas des éditeurs Wikipédia. Cependant, nous pouvons toujours visiter le site Web et découvrir tout ce qui nous intéresse. Vous ne pouvez pas faire trop de dégâts en visitant et en lisant simplement le site.

Cependant, si Wikipédia n’exigeait pas de comptes pour ses éditeurs, le site Web se détériorerait rapidement. Les éditeurs peuvent créer et modifier les informations, donc il faut des protections en place qui empêchent les gens de dégrader le site et d'écrire du charabia. Même si Wikipédia ne parvient pas toujours à empêcher ces résultats, la situation serait bien pire si aucun mécanisme de contrôle n’était en place.

Autorisation et authentification

Alors sachez que nous savons pourquoi nous avons besoin de comptes d'utilisateurs. Mais nous avons également besoin de systèmes en place qui contrôlent les informations et les ressources auxquelles chaque utilisateur est autorisé à accéder . Nous avons également besoin de moyens d'authentifier chaque utilisateur. Nous devons être capables de déterminer que les gens sont bien ceux qu’ils prétendent être et qu’ils ne sont pas simplement des imposteurs.

Encore une fois, vous ne seriez pas très satisfait si votre site Web de banque en ligne disposait simplement d’un système d’honneur. Qu’est-ce qui empêcherait les pirates de simplement dire qu’ils sont vous, puis de passer au crible vos données auxquelles ils ne sont pas censés accéder ? Qu’est-ce qui les empêcherait d’accéder à votre compte et de s’envoyer tout votre argent ?

Au lieu de cette ridicule bagarre pour tous, nous disposons de systèmes d’authentification tels que les noms d’utilisateur, les mots de passe et l’authentification à deux facteurs qui restreignent les utilisateurs afin qu’ils ne puissent accéder qu’aux ressources auxquelles ils sont autorisés à accéder. Tant que vous disposez d'un mot de passe fort, vous gardez le mot de passe secret et vous protégez votre deuxième facteur d'authentification (idéalement une application d'authentification ou un jeton de sécurité, car L'authentification par SMS n'est pas si sûre ), il est assez difficile pour un attaquant de prétendre qu’il est vraiment vous.

Dans la plupart des cas (ces systèmes ne sont pas infaillibles, mais suffisent à la plupart des objectifs lorsqu’ils sont mis en œuvre et utilisés correctement), si un site Web a mis en place des mesures de protection appropriées et que vous prenez vos responsabilités en matière de sécurité au sérieux, vous pouvez être relativement sûr qu'il serait très difficile pour un attaquant de se faire passer pour vous. . Cette difficulté empêche le solde de votre compte de s'épuiser, vos e-mails d'être lus et des inconnus de publier des diatribes folles sur vos réseaux sociaux.

Dans un système simplifié conçu pour protéger vos données, vous devrez peut-être prouver votre identité et vous authentifier en vous connectant chaque fois que vous visitez une nouvelle page d'un site Web. Vous vous connecterez une fois pour accéder à la page de présentation de votre compte. Si vous souhaitez vérifier une transaction effectuée il y a deux mois, vous devrez probablement visiter une nouvelle page et vous reconnecter. Si vous souhaitez effectuer un nouveau transfert de fonds, vous devrez vous reconnecter.

Évidemment, cela deviendrait vite fastidieux et rendrait Internet bien moins utilisable. Heureusement, les développeurs ont mis au point des systèmes pour vous éviter d'avoir à faire cela pour chaque page. La technique la plus courante implique les cookies de session.

Cookies de session

Lorsque vous vous connectez avec succès à un compte en vous authentifiant avec le nom d'utilisateur et le mot de passe corrects, la plupart des serveurs de sites Web inséreront un cookie de session dans votre navigateur. Le cookie de session comprend un numéro d'identification de session unique et le serveur stocke sa propre copie de cet identifiant . Ces identifiants de session sont suffisamment compliqués pour qu’il soit impossible pour un attaquant de simplement les deviner. Ils expirent également à la fin de chaque session, donc lors de votre prochaine connexion, un nouvel identifiant de session sera inséré dans votre navigateur.

L'avantage des cookies de session est qu'au lieu d'être obligé de prouver votre identité en vous connectant à chaque fois que vous visitez une nouvelle page. Au lieu de cela, le serveur du site Web recherchera simplement l’ID de session dans le cookie qu’il a installé lors de votre connexion.

Chaque fois que vous cliquez pour visiter une nouvelle page du site Web, votre navigateur envoie une demande au serveur du site Web. Chacune de ces demandes inclut le cookie avec votre identifiant de session. Le serveur reçoit la demande avec le cookie et compare l'ID de session avec la valeur qu'il a stockée lors de la création de la session. Si les deux correspondent, il suppose qu'il s'agit du bon utilisateur et vous accorde l'accès aux ressources auxquelles vous êtes autorisé à accéder.

Grâce à l’identifiant de session stocké dans le cookie de votre navigateur, vous pouvez parcourir les pages du site Web et effectuer diverses actions. , comme changer votre mot de passe, mettre à jour votre adresse e-mail et configurer de nouveaux transferts de fonds. Avec ce système d'authentification basé sur les cookies en place, vous n'êtes pas obligé de vous connecter séparément pour chaque tâche .

Bien que ce système fonctionne généralement assez bien, c’est également ce dont les falsifications de requêtes intersites tentent de tirer parti si les précautions appropriées ne sont pas mises en place.

Dans les cas où l'identifiant de session unique est la seule chose nécessaire pour prouver votre identité une fois que vous êtes déjà connecté, il s'ensuit que si l'attaquant parvient à comprendre comment manipuler cet identifiant à votre insu, il pourrait l'utiliser pour effectuer certaines des opérations suivantes. actions que vous seul avez l’autorisation d’effectuer. Ils peuvent être en mesure de transférer votre argent, de modifier votre mot de passe ou l'adresse e-mail enregistrée sur votre compte, ou de commettre toute une série d'autres attaques.

Requêtes HTTP

Maintenant que nous avons couvert les bases absolues de la façon dont vos comptes et les informations qu'ils contiennent sont sécurisés, nous pouvons examiner comment les données sont réellement transférées entre les clients et les serveurs via HTTP.

HTTP est l’un des protocoles les plus importants du Web. Lorsque vous visitez un site Web, votre navigateur Web – le client – ​​envoie une requête HTTP au serveur du site Web . Le serveur reçoit la requête, puis vous renvoie généralement les ressources que vous avez demandées dans sa réponse, ou il apporte les modifications que vous avez demandées.

Dans le cas de la visite de Comparitech.com, votre navigateur commencerait par trouver le serveur du site. Ensuite, il enverrait au serveur une requête HTTP lui demandant d’envoyer une copie de la page d’accueil de Comparitech. Si le serveur approuvait la demande, il vous enverrait une copie de notre page d'accueil via une série de paquets de données. Votre navigateur collecterait ces paquets, puis les utiliserait pour vous montrer une copie de notre site Web. Vous pourrez alors parcourir notre contenu à votre guise.

Si vous cliquiez ensuite sur l'un de nos articles, comme celui que vous lisez actuellement, votre navigateur enverrait une autre requête HTTP au serveur. Le serveur l'approuve généralement, puis vous enverra la copie dans un grand nombre de paquets de données. Votre navigateur rassemblera ensuite les données dans cet article que vous pourrez lire.

Si vous naviguez sur Internet de manière relativement normale, les serveurs auxquels vous faites des demandes auront tendance à approuver la majorité de vos demandes . Cependant, il existe également un certain nombre de raisons pour lesquelles ils refusent les demandes. Les serveurs peuvent ne pas être en mesure de localiser la ressource à laquelle vous essayez d'accéder et renvoyer un message d'erreur en réponse à votre demande.

Dans un autre cas, une demande peut ne pas inclure les informations d'authentification nécessaires pour accéder à une ressource spécifique. Dans ce cas, le serveur refusera la demande. Un exemple de la façon dont cela pourrait se produire serait si un attaquant tentait d’accéder à votre compte bancaire, sans l’ID de session correct indiquant qu’il dispose réellement d’une autorisation.

Les attaques de falsification de requêtes intersites sont menées avec de fausses requêtes HTTP. Afin de réussir leurs attaques, les pirates doivent trouver des moyens pour que leurs fausses requêtes soient acceptées par le serveur.

Les différents types de requête HTTP

Il existe une variété de Requêtes HTTP qui remplissent des fonctions distinctes. Ils comprennent:

Requêtes GET

Ce type de requête est utilisé pour demander des ressources au serveur d’un site Web. Dans notre exemple précédent de visite du site Web Comparitech.com, la requête de votre navigateur à notre serveur était une requête GET. C'est parce que vous demandiez des données au serveur.

Lorsqu'elles sont correctement implémentées, les requêtes GETdevraitrécupérer uniquement les données. Malgré cela, des implémentations parfois médiocres leur permettront de modifier l’état des données. Comme vous le verrez dans notre Requêtes GET dans CSRF section, cela peut entraîner des problèmes de sécurité.

L'une des raisons à cela est que les requêtes GET sont enregistrées par les serveurs, stockées dans l'historique du navigateur, peuvent être mises en cache et peuvent également être mises en signet. Cela les rend impropres à l’envoi de données sensibles.

Requêtes POST

Les demandes de publication sont utilisées pour soumettre des données aux serveurs et peuvent modifier l'état des données qu'ils stockent. Le contenu de ces requêtes est envoyé dans le corps, ils ne sont jamais mis en cache, ne peuvent pas être mis en signet et ne restent pas dans l’historique du navigateur. Cela les rend plus appropriés pour envoyer des données sensibles ou précieuses.

Un bon exemple de requête POST que vous connaissez bien se produit lorsque vous remplissez les champs de soumission d'un site Web, tels que les formulaires de contact. Lorsque vous cliquez sur le bouton Soumettre, les données que vous avez saisies dans les champs de saisie sont envoyées sous forme de requête POST.

Autres types de requêtes HTTP

• Requêtes PUT – Ce type de requête remplace une ressource existante ou en crée une nouvelle si elle n’existait pas déjà.
• Requêtes DELETE – Une requête DELETE supprimera la ressource spécifiée.
• Requêtes HEAD – Ces requêtes demandent au serveur les métadonnées d'une ressource spécifique. Il est important de noter que ces requêtes ne recherchent pas également les données corporelles comme le font les requêtes GET. Les requêtes HEAD peuvent être utilisées pour des choses comme savoir quand une ressource a été mise à jour.

Il existe également des requêtes TRACE, PATCH, OPTIONS et CONNECT. Nous ne les aborderons pas ici, mais si vous êtes curieux, vous pouvez en apprendre davantage à leur sujet ici. article de Mozilla .

Les requêtes GET et POST sont les plus courantes dans les attaques CSRF, nous allons donc vous donner des exemples du fonctionnement de chacune de ces attaques.

Requêtes POST dans CSRF

Nous commencerons par un exemple de la façon dont les requêtes POST peuvent être manipulées pour compromettre le compte d’une victime. Comme nous l'avons mentionné, les requêtes POST sont utilisées pour soumettre des données dans des formulaires en ligne. Disons votresitewebfavori.com utilise un formulaire pour vous permettre de modifier votre mot de passe. Bien entendu, il s’agit d’une fonctionnalité nécessaire, car il est important que les utilisateurs puissent modifier leur mot de passe s’ils soupçonnent que leur compte pourrait être compromis.

Forger le formulaire de demande

Les champs de saisie pour le changement de mot de passe pourraient ressembler à ceci en HTML :

Notez où il est écrit méthode = « POST » ce qui nous indique qu'il s'agit d'une requête POST. Les requêtes POST sont importantes pour les données sensibles telles que les mots de passe, car elles envoient les données dans le cadre du corps, qui ne sont ni enregistrées ni enregistrées dans le navigateur. Cela permet de garder les nouveaux mots de passe confidentiels.

Si vous regardez à gauche, vous verrez qu'il comporte l'attribut action = '#' . Ceci précise la cible de la requête. Le symbole dièse est un espace réservé.

Vous remarquerez également que le formulaire indique fréquemment nom= . Cet attribut contient le nom du paramètre pour les données que vous soumettrez. Dans cet exemple, name='password_new' et name='password_conf' s'alignent sur l'endroit où le formulaire dirait Nouveau mot de passe et Confirmer le nouveau mot de passe , respectivement. Si vous entrez mot de passe123 dans les deux champs, elle sera définie comme la nouvelle valeur des paramètres name=”password_new” et name=”password_conf”.

Lorsque vous soumettez le formulaire, votre navigateur enverra une requête POST qui comprend, entre autres, les en-têtes suivants :

• HÔTE : votresitewebfavori.com
• Cookie : SESSION=872e98c2dab1974e75

Le deuxième en-tête est l'ID de session unique créé lorsque vous vous êtes connecté au site Web.

Tout ce que nous avons montré ci-dessus est relativement normal et nécessaire pour permettre aux utilisateurs de modifier leur mot de passe en cas de besoin.

Imaginons qu'un attaquant visite le site Web à partir de son propre compte, accède à la page pour modifier son mot de passe, fasse un clic droit n'importe où sur la page, puis clique sur Inspecter dans le menu qui apparaît. Cela fera apparaître le code sous-jacent de n’importe quelle page – vous pouvez l’essayer vous-même sur n’importe quelle page Web.

Faire cela sur la page de modification des mots de passe peut facilement accorder à l’attaquant l’accès au code du formulaire. Ils pourraient alors le copier et y apporter leurs propres modifications, afin de falsifier une requête modifiant le mot de passe de la victime.

L'attaquant ajouterait les éléments nécessaires au bon fonctionnement du formulaire, tels que les balises HTML, l'en-tête et le corps. Ils écriraient également du JavaScript pour que le formulaire soit automatiquement soumis afin que l'attaque puisse se poursuivre sans que l'utilisateur ait à envoyer volontairement via le formulaire. Cela rend l’attaque encore plus susceptible de réussir.

En plus de ce nouveau code, l’attaquant ajouterait l’adresse de la page comme cible du action attribut. Ils ajouteraient également de nouvelles valeurs pour nom = 'mot de passe_nouveau' et nom = 'mot de passe_conf' . L'attaquant définirait ces valeurs comme il souhaite que le nouveau mot de passe soit.

La seule chose qui compte, c’est que le mot de passe soit quelque chose qu’ils connaissent. Dans ce cas, ' csrattaque ' est saisi dans les deux champs de saisie comme nouveau mot de passe. Les éléments clés pourraient ressembler à ceci :

Avec le formulaire ci-dessus, l'attaquant a falsifié une requête POST pour changer le mot de passe de la victime . L'étape suivante consiste à trouver un moyen d'inciter l'utilisateur à l'envoyer. Si l’attaquant parvient à le faire, il pourra alors remplacer le mot de passe de la victime par un mot de passe qu’il connaît, lui permettant ainsi de reprendre le compte. À partir de ce moment, ils pourront faire tout ce que la victime est autorisée à faire avec le compte.

Mise en place de l'attaque

Cependant, comme nous l’avons évoqué précédemment, des mécanismes de sécurité sont en place pour protéger le compte de l’utilisateur. Le formulaire permettant de modifier le mot de passe d'un compte utilisateur n'est accessible que si l'utilisateur est connecté. Lorsque l'utilisateur se connecte, le serveur crée un identifiant utilisateur unique et difficile à deviner pour la session. Cet identifiant de session est utilisé pour accorder à l'utilisateur l'accès aux ressources autorisées lorsqu'il se déplace de page en page, effectuant différentes actions sur le site Web.

Le serveur conserve une copie de cet identifiant de session unique, tandis que le navigateur de l'utilisateur la stocke dans un cookie dans son navigateur. L’ID de session est requis pour réussir à modifier le mot de passe de l’utilisateur.

Si l'attaquant souhaite envoyer une demande qui modifie avec succès le mot de passe de la victime, l'utilisateur doit être connecté et, d'une manière ou d'une autre, l'attaquant doit envoyer le cookie de session au site Web avec sa demande malveillante. . À première vue, cela peut sembler être deux défis de taille.

En pratique, la première étape n’est souvent pas trop difficile. De nombreuses personnes sont presque toujours connectées à certains de leurs comptes. Si ce n’est pas le cas, l’attaquant pourrait simplement espérer que la victime est connectée au moment où elle rencontre la requête malveillante, ou trouver un moyen de la manipuler pour qu’elle accède à son compte.

En supposant que l'attaquant puisse effectuer l'attaque en même temps que la victime est connectée, l'étape suivante consiste à héberger le formulaire malveillant qu'il a créé quelque part. Disons qu'ils le placent à evilwebsite.com/attack.html , que l'attaquant contrôle. Désormais, tout ce que l’attaquant a à faire est d’inciter la victime à visiter ce site Web à l’aide du formulaire malveillant.

Comme nous l'avons dit plus haut, l'attaquant aura écrit du JavaScript pour que le formulaire soit automatiquement soumis. Cela signifie qu’une fois que la victime aura visité le site, elle n’aura même pas besoin de cliquer sur quoi que ce soit : la fausse demande de changement de mot de passe s’enverra d’elle-même.

Il existe de nombreuses façons d'inciter les gens à visiter un site Web qui lance une attaque CSRF, mais nous les aborderons plus en détail dans le Attirer les victimes section plus bas dans l’article. L'un des plus courants est le phishing, dans lequel les attaquants créent des e-mails contenant des arguments convaincants qui incitent les gens à cliquer sur un lien.

Dans ce cas, disons que l’attaquant a envoyé quelque chose comme :

Vous n’imaginez pas à quel point ce chien est mignon :

evilwebsite.com/attack.html

Vous n'êtes peut-être pas très enthousiaste à l'idée de cliquer sur un lien indiquant evilwebsite.com, mais dans la vraie vie, le site Web d'attaque pourrait avoir un nom beaucoup plus banal, ou être déguisé avec un raccourcisseur d'URL comme Bitly .

Les attaquants envoient souvent ces messages à un grand nombre de personnes pour augmenter leurs chances de succès. Disons qu'une personne est trompée par l'e-mail et visite evilwebsite.com/attack.html. Ils accèdent au site Web, où le formulaire malveillant de changement de mot de passe est automatiquement déclenché. Le formulaire contenant le nouveau mot de passe de l’attaquant est envoyé par le navigateur de la victime à yourfavoritewebsite.com.

La fausse requête semble réelle au serveur

Le formulaire malveillant est envoyé sous forme de requête POST depuis le navigateur de la victime , et il inclut le cookie de session de la victime. Lorsque la victime est à la fois connectée et que le cookie de session est joint à la demande, yourfavoritewebsite.com suppose que la demande provient légitimement de la victime et accepte la demande. Il remplace le mot de passe par la valeur spécifiée par l'attaquant : «  csrattaque ».

Yourfavoritewebsite.com n’envoie rien directement à l’attaquant – ce n’est pas le but des attaques CSRF. Au lieu de cela, il modifie l'état des données stockées sur son serveur à la demande de l'attaquant. Dans ce cas, le mot de passe a été remplacé par « attaque csfr », ce que l’agresseur connaît, mais pas la victime.

Cela verrouille la victime hors de son compte tout en donnant à l'attaquant un contrôle total pour faire ce qu'il veut. Ils pourraient alors voler des données, vider le compte bancaire ou commettre toute une série d’autres délits, selon le type de compte dont il s’agit.

Comme nous l’avons mentionné précédemment, l’attaquant ne peut pas voler directement des données via une attaque CSRF, car le serveur ne communique pas avec l’attaquant. Même si les attaquants se limitent à modifier l’état des données sur le serveur, les attaques CSRF leur donnent une excellente base pour lancer d’autres attaques.

Si l’objectif principal de l’attaquant était de voler des données, il pourrait y parvenir en utilisant d’abord une attaque CSRF pour remplacer le mot de passe ou l’adresse e-mail par une adresse qu’il connaît (ou contrôle, dans le cas d’une adresse e-mail). Une fois cela fait, ils peuvent reprendre le compte et voler ce qu’ils veulent.

Requêtes GET dans CSRF

Maintenant que nous avons expliqué comment les requêtes POST peuvent être utilisées dans les falsifications de requêtes intersites, nous allons examiner ce que les requêtes GET peuvent faire. Disons que vous disposez d’un compte en ligne auprès de votre banque sur vulnérablebank.com. Un attaquant découvre que vulnérablebank.com est vulnérable aux attaques de falsification de requêtes intersites et y voit une opportunité de gagner de l'argent.

Incorrect et mis en œuvre OBTENIR demandes

La banque a ignoré les normes HTTPS et utilise les requêtes GET pour traiter les transferts de fonds. Si vous vous souvenez de notre section sur les différents types de requêtes HTTP, Les requêtes GET sont censé être un type de requête sûr qui récupère uniquement les données . Ils ne sont pas censés modifier intentionnellement les données sur le serveur. Au lieu de cela, ils sont simplement censés le récupérer. Malheureusement, les développeurs ne prêtent pas toujours attention aux normes.

Même s’il est peu probable qu’une grande plateforme bancaire utilise les requêtes GET de cette manière aujourd’hui, nous constatons tellement de failles de sécurité incroyables que même cela ne serait pas trop choquant. Même s’il serait surprenant pour un site bancaire moderne d’utiliser les requêtes GET de cette manière, l’exemple que nous allons aborder donne tout de même une bonne démonstration du fonctionnement des requêtes GET.

Des chercheurs de Princeton découvert une version similaire mais plus complexe de la vulnérabilité dont nous parlerons. Cela a touché une société bancaire nommée ING Direct. L’attaque a utilisé une combinaison de requêtes GET et POST, mais cela remonte à plus de dix ans.

Paramètres prévisibles

Non seulement vulnérablesbank.com utilise les requêtes GET pour les changements d'état, mais il dispose également de paramètres prévisibles qui permettent à l'attaquant d'abuser facilement du système. Disons que les transferts de fonds prennent la forme suivante :

OBTENEZ http://vulnerablebank.com/transfer.do?acct=name&amount=$XXX HTTP/1.1

Si vous deviez effectuer un transfert de fonds à votre amie Jane, cela pourrait ressembler à ceci :

OBTENIR http://vulnerablebank.com/transfer.do?acct= Jeanne &montant= 100 $ HTTP/1.1

Il s’agirait probablement des détails du compte de Jane au lieu de « Jane », mais cela n’est pas particulièrement important pour les besoins de notre exemple.

Si l'attaquant possède son propre compte auprès de la banque ou découvre les paramètres d'URL pour les transferts de fonds par d'autres moyens, il lui est relativement simple de créer une URL qui lui permet de voler de l'argent. Ils pourraient envoyer 1 000 $ sur leur propre compte en créant la requête GET suivante :

OBTENIR http://vulnerablebank.com/transfer.do?acct= attaquant &montant= 1 000 $ HTTP/1.1

Bien que l’attaquant dispose désormais de l’URL dont il avait besoin pour transférer des fonds vers son propre compte, il ne peut pas simplement l’envoyer lui-même au site vulnérablebank.com. Le serveur n'acceptera pas cette demande GET pour le transfert de fonds à moins que la victime ne soit connectée et qu'il reçoive le cookie de session avec l'ID de session unique.

La bonne nouvelle pour l’attaquant est que vulnérabilitébank.com dispose également d’un vulnérabilité de script intersite (XSS) . Ceux-ci ne sont pas nécessaires pour les attaques CSRF, mais ils permettent à l'attaquant de lancer un attaque CSRF stockée , qui a une plus grande probabilité de succès.

Contrefaçons de demandes intersites stockées

Dans cet exemple, la requête malveillante sera stockée sur vulnérabilitébank.com, plutôt que sur un autre site Web, ce qui était le cas dans notre exemple de requête POST ci-dessus. Il s’agit de la principale distinction entre les attaques CSRF stockées et les autres attaques CSRF : dans une attaque stockée, le lien malveillant est hébergé sur le même site qui est également ciblé.

Nous démontrons un CSRF stocké simplement pour montrer une partie de la variance dans les méthodes d'attaque CSRF. Ce n’est pas une partie nécessaire de ces attaques par requête GET. L'attaque POST que nous avons montrée ci-dessus aurait également pu être un CSRF stocké et inclure le formulaire malveillant sur yourfavoritewebsite.com (si l'attaquant avait trouvé une vulnérabilité de script intersite sur yourfavoritewebsite.com).

L’avantage de ces attaques CSRF stockées est qu’elles augmentent la probabilité que la victime succombe à l’attaque. . En effet, ils sont généralement déjà connectés au site Web ciblé et sont plus susceptibles de tomber sur la page où se trouve la demande malveillante.

Avec cette approche, l’attaquant n’a pas besoin de rédiger un message de phishing soigneusement conçu pour attirer la victime vers un autre site Web sur lequel la demande malveillante est hébergée. Il leur suffit d’espérer que la victime tombe par hasard sur la page du même site Web, ce qui est une tâche beaucoup plus simple. L’attaque peut être déclenchée automatiquement à l’arrivée de la victime, ou l’attaquant peut avoir besoin de la tromper pour qu’elle clique, mais dans tous les cas, les attaques CSRF stockées suppriment toujours un obstacle majeur.

Bien que cela rende certainement avantageuses les attaques CSRF stockées, elles obligent l'attaquant à trouver un Vulnérabilité XSS . Ces vulnérabilités sont le résultat de sites Web dotés de mauvaises pratiques de validation et de nettoyage, qui peuvent permettre aux attaquants d'exécuter des scripts malveillants via les champs de saisie. Cependant, de nombreux sites Web disposent de mécanismes de sécurité qui rendent cela peu pratique.

Planter la requête malveillante

Avec la fausse requête en main, ainsi qu’une vulnérabilité XSS, l’étape suivante pour l’attaquant consiste à placer la requête malveillante sur l’une des pages vulnérablesbank.com que la victime est susceptible de visiter.

Supposons que la fonction de recherche de la page Historique des transactions présente une vulnérabilité de saisie, qui permet à l'attaquant de saisir son propre code, que le site Web exécutera ensuite. La page Historique des transactions constitue également un bon endroit pour stocker le script malveillant, car la plupart des utilisateurs la visitent relativement fréquemment.

L'attaquant pourrait insérer un lien attrayant sur la page qui encouragerait la victime à cliquer dessus. Peut-être quelque chose du genre « Participez à notre concours de 1 000 $ ! » Cela pourrait ressembler à quelque chose comme :

attaquant &montant= 1 000 $ '> Participez à notre concours de 1 000 $ !'

Une fois que l’attaquant dispose du lien sur vulnérabilitébank.com, il ne lui reste plus qu’à attendre que la victime se connecte. Dans ce cas, disons que c’est vous. Lorsque vous saisissez votre nom d'utilisateur et votre mot de passe, le serveur du site Internet de la banque installe un cookie de session dans votre navigateur avec l'identifiant unique.

Peut-être que vous vérifiez votre solde, puis parcourez l’historique de vos transactions pour voir à quoi vous avez dépensé votre argent. Pendant que vous parcourez le site, vous remarquez un lien vers un prix de 1 000 $. Vous cliquez sur le lien, pensant que cela ne peut pas faire de mal d’essayer.

Malheureusement, vous aviez tout à fait tort. En cliquant sur le lien, vous avez envoyé la requête GET depuis votre navigateur Web. Puisque vous êtes déjà connecté et que votre navigateur dispose du cookie de session, le serveur devulnérablebank.com pense qu'il s'agit d'une demande légitime de votre part. . Parce qu’il pense que vous avez fait la demande, il accepte la transaction et envoie 1 000 $ de votre compte vers celui de l’attaquant. Vous ne réalisez peut-être même pas que cela s'est produit.

Encore une fois, vous remarquerez peut-être que le serveur du site Web n’a envoyé aucune information directement à l’ordinateur ou au site Web de l’attaquant. Au lieu de cela, il a envoyé de l’argent de votre compte vers le compte de l’attaquant. Encore une fois, cela est dû au fait que les attaques CSRF se concentrent sur la modification de l’état des données sur le serveur. Malgré cette limitation, l’attaquant a quand même trouvé un moyen d’utiliser un changement d’état à son avantage : en modifiant l’état du solde de votre compte.

Les nombreuses variantes des attaques de scripts intersites

Nous avons discuté de deux attaques distinctes de falsification de requêtes intersites qui présentent des différences assez significatives. Maintenant que vous comprenez la structure de base de ces attaques, il peut être utile de passer en revue et d’énumérer toutes les manières dont elles peuvent varier. Il peut être difficile de comprendre les nombreuses pièces mobiles dans les contrefaçons de requêtes intersites, c'est pourquoi ce résumé devrait, espérons-le, vous donner une image plus claire.

Requêtes POST vs GET

Vous avez peut-être remarqué que notre exemple de requête POST exigeait que l'attaquant incite la victime à soumettre un formulaire, tandis que la requête GET n'avait besoin que d'une URL avec les paramètres pour que l'attaquant obtienne le résultat souhaité. Cela signifie que lorsque les requêtes GET sont utilisées de manière incorrecte pour modifier des données (ce qui va à l’encontre de la norme), il est généralement beaucoup plus facile pour les attaques de les exploiter.

Les autres requêtes HTTP que nous avons répertoriées dans le Requête HTTP La section peut également être utilisée dans les falsifications de requêtes intersites, mais cela est moins courant.

CSRF stocké ou hébergement de l'attaque ailleurs

Nous venons de discuter de la façon dont les attaques CSRF stockées sont avantageuses car :

• Ils augmentent la probabilité que la victime y soit exposée.
• Il y a plus de chances que la victime soit déjà connectée
• Ils éliminent le besoin d’héberger l’attaque ailleurs.

Ensemble, ces facteurs rendent les falsifications de requêtes intersites stockées beaucoup plus faciles, car les pirates n’ont pas besoin de trouver un moyen d’attirer la victime vers un autre site Web.

Les attaques CSRF stockées nécessitent une vulnérabilité de script intersite (XSS) qui permet aux pirates informatiques de saisir du code malveillant. Les pirates insèrent souvent des balises iFrame ou IMG dans les champs pour configurer leurs attaques.

Dans de nombreux cas, l'attaquant ne sera pas en mesure de trouver la vulnérabilité XSS nécessaire, donc héberger l'attaque sur un autre site puis inciter la victime à le visiter est la seule option.

Attirer les victimes

Si une attaque CSRF stockée n’est pas possible, les pirates disposent toujours d’une gamme d’options pour attirer les victimes potentielles vers le site Web sur lequel ils hébergent la demande malveillante. Une option courante consiste à Hameçonnage . Cela implique soit l’envoi d’e-mails en masse, soit, dans le cas du spearphishing, des e-mails très ciblés à des personnes spécifiques.

Dans tous les cas, l’objectif est de créer un message qui convainque les victimes potentielles de cliquer sur le lien, qui les dirige ensuite vers le site Internet où les attend la requête malveillante.

Une autre option consiste pour les attaquants à publier des liens vers leur site Web malveillant à divers endroits en ligne. Cela peut être sur leur propre blog, dans les messages du forum, dans leur profil, dans les commentaires et à bien d'autres endroits. Les réseaux sociaux sont une autre option pour partager ces liens. Les détails de l’endroit n’ont pas beaucoup d’importance. L’aspect le plus important est que cela incite les utilisateurs à cliquer.

Les attaquants peuvent également publier le lien avec des balises d'image. Cela se fait souvent sur des forums qui autorisent les images, mais pas JavaScript. Ils peuvent tenter des tactiques similaires sur le Web, partout où les attaquants peuvent saisir des balises HTML dans les champs de saisie.

L’utilisateur doit-il cliquer ou est-ce automatique ?

Que la requête malveillante soit stockée sur le site Internet ciblé, ou sur un autre site Internet sous le contrôle de l’attaquant, il est préférable de déclencher l'attaque automatiquement dès que la victime potentielle tombe sur la page . Cela supprime une étape supplémentaire, qui n’est en réalité qu’une opportunité supplémentaire pour la victime potentielle de s’échapper.

Les requêtes HTTP peuvent être automatiquement déclenchées par certaines balises JavaScript. Les requêtes AJAX utilisées pour la saisie semi-automatique des suggestions de recherche en sont un exemple. Un autre exemple courant estdes balises, qui génèrent des requêtes GET vers l'image liée, afin que l'image puisse être automatiquement chargée à partir de sa source.

Ces requêtes déclenchées automatiquement permettent aux attaquants de lancer leurs requêtes malveillantes sans aucune interaction de l’utilisateur, et elles peuvent avoir lieu sans même que l’utilisateur s’en rende compte.

Les résultats des attaques CSRF

Les attaques de falsification de requêtes intersites modifient l’état des données sur le serveur, plutôt que de les voler directement. Les attaquants ne prennent pas la peine de forcer la victime à récupérer les données du serveur, car ils ne recevront pas de réponse, seule la victime la recevra. C’est pourquoi les attaques CSRF impliquent des changements d’état qui seront bénéfiques à l’attaquant.

Notre exemple d'attaque CSRF par requête POST visait à remplacer le mot de passe par un mot de passe déjà connu de l'attaquant, c'est-à-dire à modifier l'état des données sur le serveur en quelque chose qui l'aide à progresser vers ses objectifs néfastes. L’attaquant peut obtenir un résultat final similaire en remplaçant l’adresse e-mail de récupération de la victime par celle qu’il contrôle, car cela lui permet de réinitialiser le mot de passe avec celui de son choix.

À partir de ce point, un attaquant peut essentiellement faire tout ce que l'utilisateur est autorisé à faire avec le compte . Évidemment, cela varie selon le type de compte, mais cela peut inclure des éléments tels que :

• Lire ou envoyer des e-mails comme s'ils étaient la victime.
• Faire des publications sur les réseaux sociaux.
• Abuser de la confiance que les autres accordent au compte de la victime et la tromper pour qu’elle devienne de nouvelles victimes.
• Voler les informations personnelles de la victime pour d’autres crimes.
• Faire des achats en ligne.

Il existe un large éventail d’autres attaques et crimes qu’un pirate informatique peut commettre une fois qu’il a pris le contrôle du compte de la victime, notamment l’extorsion et la fraude. Lorsque les attaques CSRF sont utilisées pour prendre le contrôle d’un compte, elles donnent essentiellement aux attaquants la position dont ils ont besoin pour lancer la campagne criminelle qu’ils ont imaginée.

Cela peut avoir des conséquences bien plus larges si le compte de la victime a un rôle privilégié au sein du site Web, comme un compte administrateur. Si un attaquant parvient à changer l'email ou le mot de passe d'un compte privilégié, ils pourraient avoir un contrôle total sur les fonctionnalités de l’application Web et ses données. Ce niveau d'accès pourrait être véritablement dévastateur pour les utilisateurs et entraîner des violations de données à grande échelle, des vols, etc.

En plus de ces attaques de grande envergure, les pirates peuvent également se concentrer sur les techniques de changement d'état plus spécifiques que nous avons vues dans notre exemple de requête GET CSRF. Même si l’attaquant n’a jamais pris le contrôle du compte de la victime, il a quand même pu initier des changements d’état qui lui ont été bénéfiques. Bien entendu, voler de grosses sommes d’argent serait toujours dévastateur pour l’utilisateur, même si son compte n’était jamais complètement repris.

Contrefaçon de requêtes intersites (CSRF) vs attaques de scripts intersites (XSS)

Non seulement les falsifications de requêtes intersites et les attaques par scripts intersites portent des noms similaires, mais il existe également des éléments qui se chevauchent entre ces deux types d'attaques. Bien que cela puisse prêter à confusion, il existe quelques différences majeures qui devraient vous aider à distinguer ces attaques :

• Les attaques XSS impliquent l'exploitation de vulnérabilités de validation d'entrée, tandis que les attaques CSRF exploitent des paramètres prévisibles.
• Les attaques XSS permettent aux attaquants de voler directement des données, car elles leur permettent de contourner la politique de même origine. Lors des attaques CSRF, les pirates ne reçoivent pas de réponse du serveur et ne peuvent donc pas voler directement les informations. Cependant, ils peuvent utiliser des attaques CSRF pour modifier le mot de passe ou l'e-mail associé à un compte, puis voler des données.

Comment empêcher les falsifications de demandes intersites

Il existe toute une série de mécanismes permettant d'empêcher les falsifications de requêtes intersites. Certains d'entre eux incluent :

je mettre en œuvre correctement les demandes

Il est important que votre site Web implémente les requêtes GET comme spécifié par les normes HTTP et ne leur permette pas de modifier les données d'état sur le serveur. Comme nous l'avons montré ci-dessus, cela peut conduire à des vulnérabilités CSRF. Bien que cela puisse empêcher certaines des attaques CSRF les plus simples et les plus flagrantes, vous devrez également mettre en œuvre d'autres tactiques pour protéger vos utilisateurs de manière appropriée.

Exiger des jetons uniques dans les paramètres de la demande

Comme nous l'avons mentionné tout au long, l'une des exigences pour une attaque CSRF réussie est d'avoir des paramètres de requête prévisibles. Si l’attaquant parvient à trouver toutes les informations dont il a besoin pour demander une action spécifique, il lui suffit de trouver un moyen de tromper le navigateur de la victime pour qu’il envoie cette demande.

Dans cette optique, un attaquant ne peut pas réussir son attaque CSRF s’il ne connaît pas tous les paramètres d’entrée corrects nécessaires à une action spécifique. Par conséquent, un site Web peut empêcher les attaques de falsification de requêtes intersites en exigeant des entrées qu'un attaquant n'a aucun moyen de comprendre.

Ceci est généralement réalisé avec un certain type de jeton anti-CSRF. Il existe différentes manières d’y parvenir, mais la même idée générale s’applique. Prenons la requête GET que nous avons utilisée dans notre exemple pour initier le transfert de fonds :

OBTENEZ http://vulnerablebank.com/transfer.do?acct=name&amount=$XXX HTTP/1.1

Dans notre exemple, l'attaquant pourrait réussir à transférer de l'argent sur son compte en ajoutant son propre nom et le montant souhaité, comme ceci :

OBTENEZ http://vulnerablebank.com/transfer.do?acct=attacker&amount=$1000 HTTP/1.1

Mais que se passerait-il si nous ajoutions un numéro unique suffisamment compliqué pour être impossible à deviner ?Si le serveur a créé un jeton différent comme celui-ci à chaque fois qu'il vous a servi le site Web, la demande GET pour un transfert de fonds peut maintenant ressembler à ceci :

OBTENIR http://vulnerablebank.com/transfer.do?acct=name&amount=$xxx&token=872ea94c9b8a9381bd09238bc92847e048733bae1 HTTP/1.1

Si ce jeton unique est différent à chaque fois que la page Web vous est présentée, l'attaquant ne pourra pas deviner les paramètres corrects de la requête, comme il le pourrait dans l'exemple précédent. S'il ne peut pas saisir de paramètres valides, le serveur n'acceptera pas la demande, empêchant l'attaquant de transférer des fonds ou de réussir avec d'autres demandes falsifiées. La même logique de base s'applique aux requêtes POST.

Mettre en œuvre un défi et une réponse

Une autre tactique consiste à exiger une implication accrue des utilisateurs via un mécanisme de défi et de réponse. Si l'un des principaux dangers des falsifications de requêtes cross-site vient du fait qu'elles sont initiées sans l'intervention de l'utilisateur, une solution consiste à lui demander d'agir avant que ces requêtes de changement d'état ne soient acceptées par le serveur.

Ceci peut être réalisé grâce à :

• CAPTCHA.
• Jetons uniques.
• Demander à l'utilisateur de saisir à nouveau son mot de passe.

Si ces mécanismes de sécurité supplémentaires sont mis en œuvre, une falsification de demande intersite inciterait l'utilisateur à saisir l'une des entrées ci-dessus avant que la demande ne soit approuvée. Dans la plupart des cas, l'utilisateur se rendra compte que quelque chose d'étrange se produit et mettra un terme à la fausse requête au lieu d'effectuer l'action souhaitée.

Limiter les falsifications de requêtes intersites

Les falsifications de requêtes intersites constituent une menace en ligne importante, mais il existe toute une série de mécanismes qui peuvent aider à les atténuer. Si vous exploitez un site Web, vous pouvez protéger vos utilisateurs en suivant les stratégies énumérées ci-dessus.

Même si cela peut sembler un problème supplémentaire, les protéger des attaques peut être utile pour le succès à long terme de votre site Web. Continueriez-vous à utiliser un site qui ne prendrait pas la peine de vous protéger des effets dévastateurs des falsifications de requêtes intersites ?