Les codeurs conquièrent la sécurité : Série "Partageons et apprenons" - Falsification des requêtes intersites
Contrairement aux attaques visant directement les opérateurs de sites web ou d'applications, l'objectif de nombreuses attaques de type Cross-Site Request Forgery (CSRF) est de voler de l'argent, des biens ou des informations d'identification directement à un utilisateur. Cela ne signifie pas que les opérateurs de sites doivent ignorer les vulnérabilités du code CSRF, car en fin de compte, le remplacement des fonds volés, dans le cas d'une attaque purement monétaire, peut être de la responsabilité du site d'hébergement dont le code n'est pas sécurisé. Et si l'utilisateur ciblé perd ses informations d'identification ou si son mot de passe est modifié à son insu, un criminel pourrait être en mesure de faire des ravages en utilisant cette identité volée, en particulier si la victime dispose d'un accès privilégié.
Les attaques CSRF sont assez complexes et s'appuient sur plusieurs couches pour réussir. En d'autres termes, de nombreux éléments doivent se briser en faveur de l'attaquant pour que l'attaque fonctionne. Malgré cela, il s'agit d'un vecteur d'attaque extrêmement populaire, car une attaque réussie peut transférer de l'argent directement à un pirate, ou lui permettre de se déplacer sur un site en toute impunité. Si tout se passe bien pour le pirate, l'utilisateur ciblé peut ne jamais savoir qu'il a été victime d'une attaque.
La bonne nouvelle, c'est qu'il y a beaucoup de choses à faire pour qu'une attaque CSRF fonctionne, et qu'il existe un grand nombre de techniques défensives qui peuvent l'arrêter dans son élan.
À cette fin, nous allons examiner trois aspects clés des attaques CSRF :
- Comment ils fonctionnent
- Pourquoi ils sont si dangereux
- Comment vous pouvez mettre en place des défenses pour les stopper net.
Comment fonctionnent les attaques CSRF ?
Parce que les attaques CSRF réussies ont la capacité de voler directement de l'argent, des biens ou des informations d'identification aux utilisateurs ciblés, elles sont populaires en dépit de la quantité de travail nécessaire pour les créer. Et comme elles sont souvent tentées sur différentes plateformes, elles ont pris au fil des ans toute une série de noms et de surnoms. Vous pouvez entendre parler des attaques CSRF comme XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery ou Hostile Linking. Microsoft aime les qualifier d'attaques en un clic dans la plupart de ses documents. Mais il s'agit toujours d'attaques CSRF, et les techniques pour les déjouer sont identiques.
Une attaque CSRF peut se produire si un utilisateur est connecté à un site dans le cadre de ses activités professionnelles ou de son travail. L'essentiel est que l'utilisateur soit connecté et activement authentifié sur un site web ou une application. L'attaque est normalement lancée à partir d'un site web secondaire ou d'un e-mail. Souvent, les attaquants utilisent des techniques d'ingénierie sociale pour inciter les utilisateurs à cliquer sur un lien dans un courrier électronique qui les conduit à un site web compromis contenant le script de l'attaque.
Le site web compromis contient un script qui ordonne au navigateur actif d'exécuter des commandes, généralement quelque chose de malveillant comme la modification du mot de passe d'un utilisateur ou le transfert d'argent sur un compte contrôlé par l'attaquant. Tant que l'utilisateur est authentifié, le site pense que les commandes sont émises par l'utilisateur autorisé. Pourquoi ne le ferait-il pas ? L'utilisateur s'est déjà authentifié et a fourni tous les mots de passe nécessaires pour accéder au site. Il peut même se trouver à l'intérieur d'un périmètre géographique, correctement assis à son terminal de bureau. S'il souhaite modifier son mot de passe ou transférer des fonds, il n'y a aucune raison de ne pas croire que c'est lui qui fait la demande.
En décomposant les éléments de l'attaque, on comprend pourquoi celle-ci est si difficile à réaliser pour l'attaquant. Tout d'abord, l'utilisateur doit être activement authentifié sur le site où l'attaque a lieu. Si un courriel contenant un script d'attaque arrive après que l'utilisateur a terminé sa session de navigation ou s'est déconnecté, l'attaque échoue.
L'attaquant est également obligé de faire beaucoup de reconnaissance sur le site ciblé afin de savoir quels scripts ce site acceptera. Les attaquants ne peuvent pas voir l'écran de la victime et tout retour d'information de la part du site web ira à la victime, pas à l'attaquant. À moins que l'attaquant ne soit en mesure de voir la preuve que son attaque a fonctionné, comme de l'argent apparaissant soudainement sur son compte, il ne saura même pas immédiatement si son attaque a réussi.
Si l'on tient compte des paramètres difficiles, mais pas impossibles, selon lesquels l'utilisateur doit être connecté au moment de l'attaque et savoir quels scripts le site ciblé accepte, le code permettant d'exécuter une attaque CSRF peut être extrêmement simple, bien qu'il varie en fonction du site lui-même.
Supposons qu'une banque ou une application financière utilise des requêtes GET pour transférer de l'argent, comme ceci :
GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1
Ce code enverrait une demande de transfert de 100 dollars à un utilisateur nommé NancySmith12.
Mais si l'utilisateur ciblé reçoit un courrier électronique, peut-être déguisé comme provenant d'un collègue, un script d'attaque CSRF pourrait être intégré dans l'action de clic :
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>
Si l'utilisateur ciblé se laisse séduire par le lien d'ingénierie sociale et clique dessus alors que la session de navigation avec l'application financière est toujours ouverte, son navigateur demande à l'application d'envoyer 100 000 dollars sur le compte de ShadyLady15.
Le script pourrait même être caché dans une image invisible que l'utilisateur ne verrait pas, mais qui pourrait tout de même inciter le navigateur à faire la demande, comme ceci :
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
Le résultat est le même. ShadyLady15 obtient 100 000 $ sans que personne ne détecte l'attaque.
Pourquoi le CSRF est-il si dangereux ?
Les attaques CSRF sont aujourd'hui populaires pour la même raison que les attaques par ransomware. Il y a très peu d'étapes entre les attaquants et l'argent de la victime. Dans une attaque par ransomware, les systèmes sont cryptés et les utilisateurs sont extorqués pour obtenir de l'argent afin de décrypter les données. Avec une attaque CSRF, il y a encore moins d'étapes. Lorsqu'elles fonctionnent, les victimes envoient simplement de l'argent aux attaquants sans le savoir.
Au-delà des attaques directes contre l'argent d'une victime ou les finances d'une entreprise, les attaques CSRF réussies peuvent être utilisées pour compromettre un réseau utilisant des utilisateurs valides. Imaginez qu'un attaquant puisse utiliser un exploit CSRF pour changer le mot de passe d'un administrateur. Il pourrait immédiatement utiliser ce mot de passe pour commencer à voler des données, ouvrir des brèches dans les défenses du réseau ou installer des portes dérobées.
Bien que cela demande beaucoup de travail, et dans une certaine mesure de la chance, une attaque CSRF réussie peut être comme gagner à la loterie pour les pirates, quel que soit leur objectif final. Lors de l'attaque d'un réseau, presque tout autre type d'attaque nécessiterait des mois de reconnaissance lente, en essayant de rester sous le radar du SIEM et du personnel de cybersécurité. En revanche, une seule attaque CSRF permet de sauter un certain nombre d'étapes de la chaîne de la mort cybernétique, ce qui permet aux pirates de commencer très près de leur objectif final.
Comment arrêter les attaques CSRF ?
Contrairement à la plupart des vulnérabilités, dans le cas des attaques CSRF, ce n'est pas vraiment le code qui est en cause, mais un exploit que les attaquants ont créé pour forcer un navigateur à effectuer des requêtes que l'utilisateur ne souhaite pas, et dont il n'est peut-être même pas au courant. Mais il est possible de les déjouer.
L'une des meilleures méthodes consiste à demander aux développeurs d'ajouter un jeton CSRF à l'identité de l'utilisateur chaque fois qu'une nouvelle session est générée. Ce jeton doit consister en une chaîne de caractères uniques et aléatoires et être invisible pour les utilisateurs. Ensuite, ajoutez la demande de jeton CSRF en tant que champ caché dans les formulaires qui sont vérifiés par le serveur chaque fois qu'une nouvelle demande est soumise. Les attaquants qui soumettent des requêtes par l'intermédiaire du navigateur d'un utilisateur ne seront même pas au courant de l'existence du champ de jeton caché, et seront encore moins en mesure de le découvrir, de sorte que toutes leurs requêtes échoueront.
Une méthode encore plus simple, et qui ne nécessite pas beaucoup de programmation, consiste à ajouter un défi Captcha à tout ce qui est sensible, comme les demandes de changement de mot de passe ou les ordres de transfert d'argent. Il peut s'agir simplement de demander à l'utilisateur de cliquer sur un bouton confirmant que le demandeur n'est pas un robot ou, dans le cas présent, un script CSRF. Les attaquants ne seront pas en mesure de rédiger une réponse au défi, et les utilisateurs qui reçoivent soudainement un défi CAPTCHA sans d'abord faire quelque chose comme une demande de transfert d'argent sauront qu'il y a quelque chose d'anormal. Une autre solution consiste à générer un mot de passe à usage unique à l'aide d'un jeton tiers, comme un smartphone, en fonction de la volonté de l'organisation de ralentir le travail au nom de la sécurité.
Enfin, bien qu'il ne s'agisse pas d'une garantie absolue, de nombreux navigateurs tels que Microsoft Edge ou Google Chrome ont désormais mis en place des restrictions de politique d'origine identique afin de bloquer les requêtes provenant de toute personne autre que l'utilisateur local. En obligeant les utilisateurs à interagir avec votre site en utilisant les versions les plus récentes de ces navigateurs, vous pouvez intégrer une couche supplémentaire de sécurité CSRF sans solliciter les équipes de développement.
Fermer la porte au CSRF
Avec un tel potentiel de gain, les attaques CSRF ne disparaîtront probablement jamais complètement, mais nous espérons que vous avez appris pourquoi elles sont si persistantes et comment les bloquer de votre réseau pour de bon.
Pour en savoir plus, vous pouvez consulter l'OWASP Cross-Site Request Forgery Prevention Cheat Sheet, qui constitue un document évolutif décrivant cette vulnérabilité au fur et à mesure de son évolution. Si vous souhaitez vraiment renforcer vos connaissances en matière de sécurité, vous pouvez apprendre à déjouer cette menace et bien d'autres encore en visitant le Secure Code Warrior blog.
Vous pensez être prêt à mettre à l'épreuve vos nouvelles connaissances en matière de défense ? Essayez dès aujourd'hui la démo gratuite de la plateforme Secure Code Warrior .
Les attaques CSRF sont assez complexes et s'appuient sur plusieurs couches pour réussir. En d'autres termes, de nombreux éléments doivent se briser en faveur de l'attaquant pour que l'attaque fonctionne. Malgré cela, il s'agit d'un vecteur d'attaque extrêmement populaire et lucratif.
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstration
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Contrairement aux attaques visant directement les opérateurs de sites web ou d'applications, l'objectif de nombreuses attaques de type Cross-Site Request Forgery (CSRF) est de voler de l'argent, des biens ou des informations d'identification directement à un utilisateur. Cela ne signifie pas que les opérateurs de sites doivent ignorer les vulnérabilités du code CSRF, car en fin de compte, le remplacement des fonds volés, dans le cas d'une attaque purement monétaire, peut être de la responsabilité du site d'hébergement dont le code n'est pas sécurisé. Et si l'utilisateur ciblé perd ses informations d'identification ou si son mot de passe est modifié à son insu, un criminel pourrait être en mesure de faire des ravages en utilisant cette identité volée, en particulier si la victime dispose d'un accès privilégié.
Les attaques CSRF sont assez complexes et s'appuient sur plusieurs couches pour réussir. En d'autres termes, de nombreux éléments doivent se briser en faveur de l'attaquant pour que l'attaque fonctionne. Malgré cela, il s'agit d'un vecteur d'attaque extrêmement populaire, car une attaque réussie peut transférer de l'argent directement à un pirate, ou lui permettre de se déplacer sur un site en toute impunité. Si tout se passe bien pour le pirate, l'utilisateur ciblé peut ne jamais savoir qu'il a été victime d'une attaque.
La bonne nouvelle, c'est qu'il y a beaucoup de choses à faire pour qu'une attaque CSRF fonctionne, et qu'il existe un grand nombre de techniques défensives qui peuvent l'arrêter dans son élan.
À cette fin, nous allons examiner trois aspects clés des attaques CSRF :
- Comment ils fonctionnent
- Pourquoi ils sont si dangereux
- Comment vous pouvez mettre en place des défenses pour les stopper net.
Comment fonctionnent les attaques CSRF ?
Parce que les attaques CSRF réussies ont la capacité de voler directement de l'argent, des biens ou des informations d'identification aux utilisateurs ciblés, elles sont populaires en dépit de la quantité de travail nécessaire pour les créer. Et comme elles sont souvent tentées sur différentes plateformes, elles ont pris au fil des ans toute une série de noms et de surnoms. Vous pouvez entendre parler des attaques CSRF comme XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery ou Hostile Linking. Microsoft aime les qualifier d'attaques en un clic dans la plupart de ses documents. Mais il s'agit toujours d'attaques CSRF, et les techniques pour les déjouer sont identiques.
Une attaque CSRF peut se produire si un utilisateur est connecté à un site dans le cadre de ses activités professionnelles ou de son travail. L'essentiel est que l'utilisateur soit connecté et activement authentifié sur un site web ou une application. L'attaque est normalement lancée à partir d'un site web secondaire ou d'un e-mail. Souvent, les attaquants utilisent des techniques d'ingénierie sociale pour inciter les utilisateurs à cliquer sur un lien dans un courrier électronique qui les conduit à un site web compromis contenant le script de l'attaque.
Le site web compromis contient un script qui ordonne au navigateur actif d'exécuter des commandes, généralement quelque chose de malveillant comme la modification du mot de passe d'un utilisateur ou le transfert d'argent sur un compte contrôlé par l'attaquant. Tant que l'utilisateur est authentifié, le site pense que les commandes sont émises par l'utilisateur autorisé. Pourquoi ne le ferait-il pas ? L'utilisateur s'est déjà authentifié et a fourni tous les mots de passe nécessaires pour accéder au site. Il peut même se trouver à l'intérieur d'un périmètre géographique, correctement assis à son terminal de bureau. S'il souhaite modifier son mot de passe ou transférer des fonds, il n'y a aucune raison de ne pas croire que c'est lui qui fait la demande.
En décomposant les éléments de l'attaque, on comprend pourquoi celle-ci est si difficile à réaliser pour l'attaquant. Tout d'abord, l'utilisateur doit être activement authentifié sur le site où l'attaque a lieu. Si un courriel contenant un script d'attaque arrive après que l'utilisateur a terminé sa session de navigation ou s'est déconnecté, l'attaque échoue.
L'attaquant est également obligé de faire beaucoup de reconnaissance sur le site ciblé afin de savoir quels scripts ce site acceptera. Les attaquants ne peuvent pas voir l'écran de la victime et tout retour d'information de la part du site web ira à la victime, pas à l'attaquant. À moins que l'attaquant ne soit en mesure de voir la preuve que son attaque a fonctionné, comme de l'argent apparaissant soudainement sur son compte, il ne saura même pas immédiatement si son attaque a réussi.
Si l'on tient compte des paramètres difficiles, mais pas impossibles, selon lesquels l'utilisateur doit être connecté au moment de l'attaque et savoir quels scripts le site ciblé accepte, le code permettant d'exécuter une attaque CSRF peut être extrêmement simple, bien qu'il varie en fonction du site lui-même.
Supposons qu'une banque ou une application financière utilise des requêtes GET pour transférer de l'argent, comme ceci :
GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1
Ce code enverrait une demande de transfert de 100 dollars à un utilisateur nommé NancySmith12.
Mais si l'utilisateur ciblé reçoit un courrier électronique, peut-être déguisé comme provenant d'un collègue, un script d'attaque CSRF pourrait être intégré dans l'action de clic :
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>
Si l'utilisateur ciblé se laisse séduire par le lien d'ingénierie sociale et clique dessus alors que la session de navigation avec l'application financière est toujours ouverte, son navigateur demande à l'application d'envoyer 100 000 dollars sur le compte de ShadyLady15.
Le script pourrait même être caché dans une image invisible que l'utilisateur ne verrait pas, mais qui pourrait tout de même inciter le navigateur à faire la demande, comme ceci :
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
Le résultat est le même. ShadyLady15 obtient 100 000 $ sans que personne ne détecte l'attaque.
Pourquoi le CSRF est-il si dangereux ?
Les attaques CSRF sont aujourd'hui populaires pour la même raison que les attaques par ransomware. Il y a très peu d'étapes entre les attaquants et l'argent de la victime. Dans une attaque par ransomware, les systèmes sont cryptés et les utilisateurs sont extorqués pour obtenir de l'argent afin de décrypter les données. Avec une attaque CSRF, il y a encore moins d'étapes. Lorsqu'elles fonctionnent, les victimes envoient simplement de l'argent aux attaquants sans le savoir.
Au-delà des attaques directes contre l'argent d'une victime ou les finances d'une entreprise, les attaques CSRF réussies peuvent être utilisées pour compromettre un réseau utilisant des utilisateurs valides. Imaginez qu'un attaquant puisse utiliser un exploit CSRF pour changer le mot de passe d'un administrateur. Il pourrait immédiatement utiliser ce mot de passe pour commencer à voler des données, ouvrir des brèches dans les défenses du réseau ou installer des portes dérobées.
Bien que cela demande beaucoup de travail, et dans une certaine mesure de la chance, une attaque CSRF réussie peut être comme gagner à la loterie pour les pirates, quel que soit leur objectif final. Lors de l'attaque d'un réseau, presque tout autre type d'attaque nécessiterait des mois de reconnaissance lente, en essayant de rester sous le radar du SIEM et du personnel de cybersécurité. En revanche, une seule attaque CSRF permet de sauter un certain nombre d'étapes de la chaîne de la mort cybernétique, ce qui permet aux pirates de commencer très près de leur objectif final.
Comment arrêter les attaques CSRF ?
Contrairement à la plupart des vulnérabilités, dans le cas des attaques CSRF, ce n'est pas vraiment le code qui est en cause, mais un exploit que les attaquants ont créé pour forcer un navigateur à effectuer des requêtes que l'utilisateur ne souhaite pas, et dont il n'est peut-être même pas au courant. Mais il est possible de les déjouer.
L'une des meilleures méthodes consiste à demander aux développeurs d'ajouter un jeton CSRF à l'identité de l'utilisateur chaque fois qu'une nouvelle session est générée. Ce jeton doit consister en une chaîne de caractères uniques et aléatoires et être invisible pour les utilisateurs. Ensuite, ajoutez la demande de jeton CSRF en tant que champ caché dans les formulaires qui sont vérifiés par le serveur chaque fois qu'une nouvelle demande est soumise. Les attaquants qui soumettent des requêtes par l'intermédiaire du navigateur d'un utilisateur ne seront même pas au courant de l'existence du champ de jeton caché, et seront encore moins en mesure de le découvrir, de sorte que toutes leurs requêtes échoueront.
Une méthode encore plus simple, et qui ne nécessite pas beaucoup de programmation, consiste à ajouter un défi Captcha à tout ce qui est sensible, comme les demandes de changement de mot de passe ou les ordres de transfert d'argent. Il peut s'agir simplement de demander à l'utilisateur de cliquer sur un bouton confirmant que le demandeur n'est pas un robot ou, dans le cas présent, un script CSRF. Les attaquants ne seront pas en mesure de rédiger une réponse au défi, et les utilisateurs qui reçoivent soudainement un défi CAPTCHA sans d'abord faire quelque chose comme une demande de transfert d'argent sauront qu'il y a quelque chose d'anormal. Une autre solution consiste à générer un mot de passe à usage unique à l'aide d'un jeton tiers, comme un smartphone, en fonction de la volonté de l'organisation de ralentir le travail au nom de la sécurité.
Enfin, bien qu'il ne s'agisse pas d'une garantie absolue, de nombreux navigateurs tels que Microsoft Edge ou Google Chrome ont désormais mis en place des restrictions de politique d'origine identique afin de bloquer les requêtes provenant de toute personne autre que l'utilisateur local. En obligeant les utilisateurs à interagir avec votre site en utilisant les versions les plus récentes de ces navigateurs, vous pouvez intégrer une couche supplémentaire de sécurité CSRF sans solliciter les équipes de développement.
Fermer la porte au CSRF
Avec un tel potentiel de gain, les attaques CSRF ne disparaîtront probablement jamais complètement, mais nous espérons que vous avez appris pourquoi elles sont si persistantes et comment les bloquer de votre réseau pour de bon.
Pour en savoir plus, vous pouvez consulter l'OWASP Cross-Site Request Forgery Prevention Cheat Sheet, qui constitue un document évolutif décrivant cette vulnérabilité au fur et à mesure de son évolution. Si vous souhaitez vraiment renforcer vos connaissances en matière de sécurité, vous pouvez apprendre à déjouer cette menace et bien d'autres encore en visitant le Secure Code Warrior blog.
Vous pensez être prêt à mettre à l'épreuve vos nouvelles connaissances en matière de défense ? Essayez dès aujourd'hui la démo gratuite de la plateforme Secure Code Warrior .
Contrairement aux attaques visant directement les opérateurs de sites web ou d'applications, l'objectif de nombreuses attaques de type Cross-Site Request Forgery (CSRF) est de voler de l'argent, des biens ou des informations d'identification directement à un utilisateur. Cela ne signifie pas que les opérateurs de sites doivent ignorer les vulnérabilités du code CSRF, car en fin de compte, le remplacement des fonds volés, dans le cas d'une attaque purement monétaire, peut être de la responsabilité du site d'hébergement dont le code n'est pas sécurisé. Et si l'utilisateur ciblé perd ses informations d'identification ou si son mot de passe est modifié à son insu, un criminel pourrait être en mesure de faire des ravages en utilisant cette identité volée, en particulier si la victime dispose d'un accès privilégié.
Les attaques CSRF sont assez complexes et s'appuient sur plusieurs couches pour réussir. En d'autres termes, de nombreux éléments doivent se briser en faveur de l'attaquant pour que l'attaque fonctionne. Malgré cela, il s'agit d'un vecteur d'attaque extrêmement populaire, car une attaque réussie peut transférer de l'argent directement à un pirate, ou lui permettre de se déplacer sur un site en toute impunité. Si tout se passe bien pour le pirate, l'utilisateur ciblé peut ne jamais savoir qu'il a été victime d'une attaque.
La bonne nouvelle, c'est qu'il y a beaucoup de choses à faire pour qu'une attaque CSRF fonctionne, et qu'il existe un grand nombre de techniques défensives qui peuvent l'arrêter dans son élan.
À cette fin, nous allons examiner trois aspects clés des attaques CSRF :
- Comment ils fonctionnent
- Pourquoi ils sont si dangereux
- Comment vous pouvez mettre en place des défenses pour les stopper net.
Comment fonctionnent les attaques CSRF ?
Parce que les attaques CSRF réussies ont la capacité de voler directement de l'argent, des biens ou des informations d'identification aux utilisateurs ciblés, elles sont populaires en dépit de la quantité de travail nécessaire pour les créer. Et comme elles sont souvent tentées sur différentes plateformes, elles ont pris au fil des ans toute une série de noms et de surnoms. Vous pouvez entendre parler des attaques CSRF comme XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery ou Hostile Linking. Microsoft aime les qualifier d'attaques en un clic dans la plupart de ses documents. Mais il s'agit toujours d'attaques CSRF, et les techniques pour les déjouer sont identiques.
Une attaque CSRF peut se produire si un utilisateur est connecté à un site dans le cadre de ses activités professionnelles ou de son travail. L'essentiel est que l'utilisateur soit connecté et activement authentifié sur un site web ou une application. L'attaque est normalement lancée à partir d'un site web secondaire ou d'un e-mail. Souvent, les attaquants utilisent des techniques d'ingénierie sociale pour inciter les utilisateurs à cliquer sur un lien dans un courrier électronique qui les conduit à un site web compromis contenant le script de l'attaque.
Le site web compromis contient un script qui ordonne au navigateur actif d'exécuter des commandes, généralement quelque chose de malveillant comme la modification du mot de passe d'un utilisateur ou le transfert d'argent sur un compte contrôlé par l'attaquant. Tant que l'utilisateur est authentifié, le site pense que les commandes sont émises par l'utilisateur autorisé. Pourquoi ne le ferait-il pas ? L'utilisateur s'est déjà authentifié et a fourni tous les mots de passe nécessaires pour accéder au site. Il peut même se trouver à l'intérieur d'un périmètre géographique, correctement assis à son terminal de bureau. S'il souhaite modifier son mot de passe ou transférer des fonds, il n'y a aucune raison de ne pas croire que c'est lui qui fait la demande.
En décomposant les éléments de l'attaque, on comprend pourquoi celle-ci est si difficile à réaliser pour l'attaquant. Tout d'abord, l'utilisateur doit être activement authentifié sur le site où l'attaque a lieu. Si un courriel contenant un script d'attaque arrive après que l'utilisateur a terminé sa session de navigation ou s'est déconnecté, l'attaque échoue.
L'attaquant est également obligé de faire beaucoup de reconnaissance sur le site ciblé afin de savoir quels scripts ce site acceptera. Les attaquants ne peuvent pas voir l'écran de la victime et tout retour d'information de la part du site web ira à la victime, pas à l'attaquant. À moins que l'attaquant ne soit en mesure de voir la preuve que son attaque a fonctionné, comme de l'argent apparaissant soudainement sur son compte, il ne saura même pas immédiatement si son attaque a réussi.
Si l'on tient compte des paramètres difficiles, mais pas impossibles, selon lesquels l'utilisateur doit être connecté au moment de l'attaque et savoir quels scripts le site ciblé accepte, le code permettant d'exécuter une attaque CSRF peut être extrêmement simple, bien qu'il varie en fonction du site lui-même.
Supposons qu'une banque ou une application financière utilise des requêtes GET pour transférer de l'argent, comme ceci :
GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1
Ce code enverrait une demande de transfert de 100 dollars à un utilisateur nommé NancySmith12.
Mais si l'utilisateur ciblé reçoit un courrier électronique, peut-être déguisé comme provenant d'un collègue, un script d'attaque CSRF pourrait être intégré dans l'action de clic :
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>
Si l'utilisateur ciblé se laisse séduire par le lien d'ingénierie sociale et clique dessus alors que la session de navigation avec l'application financière est toujours ouverte, son navigateur demande à l'application d'envoyer 100 000 dollars sur le compte de ShadyLady15.
Le script pourrait même être caché dans une image invisible que l'utilisateur ne verrait pas, mais qui pourrait tout de même inciter le navigateur à faire la demande, comme ceci :
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
Le résultat est le même. ShadyLady15 obtient 100 000 $ sans que personne ne détecte l'attaque.
Pourquoi le CSRF est-il si dangereux ?
Les attaques CSRF sont aujourd'hui populaires pour la même raison que les attaques par ransomware. Il y a très peu d'étapes entre les attaquants et l'argent de la victime. Dans une attaque par ransomware, les systèmes sont cryptés et les utilisateurs sont extorqués pour obtenir de l'argent afin de décrypter les données. Avec une attaque CSRF, il y a encore moins d'étapes. Lorsqu'elles fonctionnent, les victimes envoient simplement de l'argent aux attaquants sans le savoir.
Au-delà des attaques directes contre l'argent d'une victime ou les finances d'une entreprise, les attaques CSRF réussies peuvent être utilisées pour compromettre un réseau utilisant des utilisateurs valides. Imaginez qu'un attaquant puisse utiliser un exploit CSRF pour changer le mot de passe d'un administrateur. Il pourrait immédiatement utiliser ce mot de passe pour commencer à voler des données, ouvrir des brèches dans les défenses du réseau ou installer des portes dérobées.
Bien que cela demande beaucoup de travail, et dans une certaine mesure de la chance, une attaque CSRF réussie peut être comme gagner à la loterie pour les pirates, quel que soit leur objectif final. Lors de l'attaque d'un réseau, presque tout autre type d'attaque nécessiterait des mois de reconnaissance lente, en essayant de rester sous le radar du SIEM et du personnel de cybersécurité. En revanche, une seule attaque CSRF permet de sauter un certain nombre d'étapes de la chaîne de la mort cybernétique, ce qui permet aux pirates de commencer très près de leur objectif final.
Comment arrêter les attaques CSRF ?
Contrairement à la plupart des vulnérabilités, dans le cas des attaques CSRF, ce n'est pas vraiment le code qui est en cause, mais un exploit que les attaquants ont créé pour forcer un navigateur à effectuer des requêtes que l'utilisateur ne souhaite pas, et dont il n'est peut-être même pas au courant. Mais il est possible de les déjouer.
L'une des meilleures méthodes consiste à demander aux développeurs d'ajouter un jeton CSRF à l'identité de l'utilisateur chaque fois qu'une nouvelle session est générée. Ce jeton doit consister en une chaîne de caractères uniques et aléatoires et être invisible pour les utilisateurs. Ensuite, ajoutez la demande de jeton CSRF en tant que champ caché dans les formulaires qui sont vérifiés par le serveur chaque fois qu'une nouvelle demande est soumise. Les attaquants qui soumettent des requêtes par l'intermédiaire du navigateur d'un utilisateur ne seront même pas au courant de l'existence du champ de jeton caché, et seront encore moins en mesure de le découvrir, de sorte que toutes leurs requêtes échoueront.
Une méthode encore plus simple, et qui ne nécessite pas beaucoup de programmation, consiste à ajouter un défi Captcha à tout ce qui est sensible, comme les demandes de changement de mot de passe ou les ordres de transfert d'argent. Il peut s'agir simplement de demander à l'utilisateur de cliquer sur un bouton confirmant que le demandeur n'est pas un robot ou, dans le cas présent, un script CSRF. Les attaquants ne seront pas en mesure de rédiger une réponse au défi, et les utilisateurs qui reçoivent soudainement un défi CAPTCHA sans d'abord faire quelque chose comme une demande de transfert d'argent sauront qu'il y a quelque chose d'anormal. Une autre solution consiste à générer un mot de passe à usage unique à l'aide d'un jeton tiers, comme un smartphone, en fonction de la volonté de l'organisation de ralentir le travail au nom de la sécurité.
Enfin, bien qu'il ne s'agisse pas d'une garantie absolue, de nombreux navigateurs tels que Microsoft Edge ou Google Chrome ont désormais mis en place des restrictions de politique d'origine identique afin de bloquer les requêtes provenant de toute personne autre que l'utilisateur local. En obligeant les utilisateurs à interagir avec votre site en utilisant les versions les plus récentes de ces navigateurs, vous pouvez intégrer une couche supplémentaire de sécurité CSRF sans solliciter les équipes de développement.
Fermer la porte au CSRF
Avec un tel potentiel de gain, les attaques CSRF ne disparaîtront probablement jamais complètement, mais nous espérons que vous avez appris pourquoi elles sont si persistantes et comment les bloquer de votre réseau pour de bon.
Pour en savoir plus, vous pouvez consulter l'OWASP Cross-Site Request Forgery Prevention Cheat Sheet, qui constitue un document évolutif décrivant cette vulnérabilité au fur et à mesure de son évolution. Si vous souhaitez vraiment renforcer vos connaissances en matière de sécurité, vous pouvez apprendre à déjouer cette menace et bien d'autres encore en visitant le Secure Code Warrior blog.
Vous pensez être prêt à mettre à l'épreuve vos nouvelles connaissances en matière de défense ? Essayez dès aujourd'hui la démo gratuite de la plateforme Secure Code Warrior .
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Voir le rapportRéservez une démonstration
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Contrairement aux attaques visant directement les opérateurs de sites web ou d'applications, l'objectif de nombreuses attaques de type Cross-Site Request Forgery (CSRF) est de voler de l'argent, des biens ou des informations d'identification directement à un utilisateur. Cela ne signifie pas que les opérateurs de sites doivent ignorer les vulnérabilités du code CSRF, car en fin de compte, le remplacement des fonds volés, dans le cas d'une attaque purement monétaire, peut être de la responsabilité du site d'hébergement dont le code n'est pas sécurisé. Et si l'utilisateur ciblé perd ses informations d'identification ou si son mot de passe est modifié à son insu, un criminel pourrait être en mesure de faire des ravages en utilisant cette identité volée, en particulier si la victime dispose d'un accès privilégié.
Les attaques CSRF sont assez complexes et s'appuient sur plusieurs couches pour réussir. En d'autres termes, de nombreux éléments doivent se briser en faveur de l'attaquant pour que l'attaque fonctionne. Malgré cela, il s'agit d'un vecteur d'attaque extrêmement populaire, car une attaque réussie peut transférer de l'argent directement à un pirate, ou lui permettre de se déplacer sur un site en toute impunité. Si tout se passe bien pour le pirate, l'utilisateur ciblé peut ne jamais savoir qu'il a été victime d'une attaque.
La bonne nouvelle, c'est qu'il y a beaucoup de choses à faire pour qu'une attaque CSRF fonctionne, et qu'il existe un grand nombre de techniques défensives qui peuvent l'arrêter dans son élan.
À cette fin, nous allons examiner trois aspects clés des attaques CSRF :
- Comment ils fonctionnent
- Pourquoi ils sont si dangereux
- Comment vous pouvez mettre en place des défenses pour les stopper net.
Comment fonctionnent les attaques CSRF ?
Parce que les attaques CSRF réussies ont la capacité de voler directement de l'argent, des biens ou des informations d'identification aux utilisateurs ciblés, elles sont populaires en dépit de la quantité de travail nécessaire pour les créer. Et comme elles sont souvent tentées sur différentes plateformes, elles ont pris au fil des ans toute une série de noms et de surnoms. Vous pouvez entendre parler des attaques CSRF comme XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery ou Hostile Linking. Microsoft aime les qualifier d'attaques en un clic dans la plupart de ses documents. Mais il s'agit toujours d'attaques CSRF, et les techniques pour les déjouer sont identiques.
Une attaque CSRF peut se produire si un utilisateur est connecté à un site dans le cadre de ses activités professionnelles ou de son travail. L'essentiel est que l'utilisateur soit connecté et activement authentifié sur un site web ou une application. L'attaque est normalement lancée à partir d'un site web secondaire ou d'un e-mail. Souvent, les attaquants utilisent des techniques d'ingénierie sociale pour inciter les utilisateurs à cliquer sur un lien dans un courrier électronique qui les conduit à un site web compromis contenant le script de l'attaque.
Le site web compromis contient un script qui ordonne au navigateur actif d'exécuter des commandes, généralement quelque chose de malveillant comme la modification du mot de passe d'un utilisateur ou le transfert d'argent sur un compte contrôlé par l'attaquant. Tant que l'utilisateur est authentifié, le site pense que les commandes sont émises par l'utilisateur autorisé. Pourquoi ne le ferait-il pas ? L'utilisateur s'est déjà authentifié et a fourni tous les mots de passe nécessaires pour accéder au site. Il peut même se trouver à l'intérieur d'un périmètre géographique, correctement assis à son terminal de bureau. S'il souhaite modifier son mot de passe ou transférer des fonds, il n'y a aucune raison de ne pas croire que c'est lui qui fait la demande.
En décomposant les éléments de l'attaque, on comprend pourquoi celle-ci est si difficile à réaliser pour l'attaquant. Tout d'abord, l'utilisateur doit être activement authentifié sur le site où l'attaque a lieu. Si un courriel contenant un script d'attaque arrive après que l'utilisateur a terminé sa session de navigation ou s'est déconnecté, l'attaque échoue.
L'attaquant est également obligé de faire beaucoup de reconnaissance sur le site ciblé afin de savoir quels scripts ce site acceptera. Les attaquants ne peuvent pas voir l'écran de la victime et tout retour d'information de la part du site web ira à la victime, pas à l'attaquant. À moins que l'attaquant ne soit en mesure de voir la preuve que son attaque a fonctionné, comme de l'argent apparaissant soudainement sur son compte, il ne saura même pas immédiatement si son attaque a réussi.
Si l'on tient compte des paramètres difficiles, mais pas impossibles, selon lesquels l'utilisateur doit être connecté au moment de l'attaque et savoir quels scripts le site ciblé accepte, le code permettant d'exécuter une attaque CSRF peut être extrêmement simple, bien qu'il varie en fonction du site lui-même.
Supposons qu'une banque ou une application financière utilise des requêtes GET pour transférer de l'argent, comme ceci :
GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1
Ce code enverrait une demande de transfert de 100 dollars à un utilisateur nommé NancySmith12.
Mais si l'utilisateur ciblé reçoit un courrier électronique, peut-être déguisé comme provenant d'un collègue, un script d'attaque CSRF pourrait être intégré dans l'action de clic :
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>
Si l'utilisateur ciblé se laisse séduire par le lien d'ingénierie sociale et clique dessus alors que la session de navigation avec l'application financière est toujours ouverte, son navigateur demande à l'application d'envoyer 100 000 dollars sur le compte de ShadyLady15.
Le script pourrait même être caché dans une image invisible que l'utilisateur ne verrait pas, mais qui pourrait tout de même inciter le navigateur à faire la demande, comme ceci :
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
Le résultat est le même. ShadyLady15 obtient 100 000 $ sans que personne ne détecte l'attaque.
Pourquoi le CSRF est-il si dangereux ?
Les attaques CSRF sont aujourd'hui populaires pour la même raison que les attaques par ransomware. Il y a très peu d'étapes entre les attaquants et l'argent de la victime. Dans une attaque par ransomware, les systèmes sont cryptés et les utilisateurs sont extorqués pour obtenir de l'argent afin de décrypter les données. Avec une attaque CSRF, il y a encore moins d'étapes. Lorsqu'elles fonctionnent, les victimes envoient simplement de l'argent aux attaquants sans le savoir.
Au-delà des attaques directes contre l'argent d'une victime ou les finances d'une entreprise, les attaques CSRF réussies peuvent être utilisées pour compromettre un réseau utilisant des utilisateurs valides. Imaginez qu'un attaquant puisse utiliser un exploit CSRF pour changer le mot de passe d'un administrateur. Il pourrait immédiatement utiliser ce mot de passe pour commencer à voler des données, ouvrir des brèches dans les défenses du réseau ou installer des portes dérobées.
Bien que cela demande beaucoup de travail, et dans une certaine mesure de la chance, une attaque CSRF réussie peut être comme gagner à la loterie pour les pirates, quel que soit leur objectif final. Lors de l'attaque d'un réseau, presque tout autre type d'attaque nécessiterait des mois de reconnaissance lente, en essayant de rester sous le radar du SIEM et du personnel de cybersécurité. En revanche, une seule attaque CSRF permet de sauter un certain nombre d'étapes de la chaîne de la mort cybernétique, ce qui permet aux pirates de commencer très près de leur objectif final.
Comment arrêter les attaques CSRF ?
Contrairement à la plupart des vulnérabilités, dans le cas des attaques CSRF, ce n'est pas vraiment le code qui est en cause, mais un exploit que les attaquants ont créé pour forcer un navigateur à effectuer des requêtes que l'utilisateur ne souhaite pas, et dont il n'est peut-être même pas au courant. Mais il est possible de les déjouer.
L'une des meilleures méthodes consiste à demander aux développeurs d'ajouter un jeton CSRF à l'identité de l'utilisateur chaque fois qu'une nouvelle session est générée. Ce jeton doit consister en une chaîne de caractères uniques et aléatoires et être invisible pour les utilisateurs. Ensuite, ajoutez la demande de jeton CSRF en tant que champ caché dans les formulaires qui sont vérifiés par le serveur chaque fois qu'une nouvelle demande est soumise. Les attaquants qui soumettent des requêtes par l'intermédiaire du navigateur d'un utilisateur ne seront même pas au courant de l'existence du champ de jeton caché, et seront encore moins en mesure de le découvrir, de sorte que toutes leurs requêtes échoueront.
Une méthode encore plus simple, et qui ne nécessite pas beaucoup de programmation, consiste à ajouter un défi Captcha à tout ce qui est sensible, comme les demandes de changement de mot de passe ou les ordres de transfert d'argent. Il peut s'agir simplement de demander à l'utilisateur de cliquer sur un bouton confirmant que le demandeur n'est pas un robot ou, dans le cas présent, un script CSRF. Les attaquants ne seront pas en mesure de rédiger une réponse au défi, et les utilisateurs qui reçoivent soudainement un défi CAPTCHA sans d'abord faire quelque chose comme une demande de transfert d'argent sauront qu'il y a quelque chose d'anormal. Une autre solution consiste à générer un mot de passe à usage unique à l'aide d'un jeton tiers, comme un smartphone, en fonction de la volonté de l'organisation de ralentir le travail au nom de la sécurité.
Enfin, bien qu'il ne s'agisse pas d'une garantie absolue, de nombreux navigateurs tels que Microsoft Edge ou Google Chrome ont désormais mis en place des restrictions de politique d'origine identique afin de bloquer les requêtes provenant de toute personne autre que l'utilisateur local. En obligeant les utilisateurs à interagir avec votre site en utilisant les versions les plus récentes de ces navigateurs, vous pouvez intégrer une couche supplémentaire de sécurité CSRF sans solliciter les équipes de développement.
Fermer la porte au CSRF
Avec un tel potentiel de gain, les attaques CSRF ne disparaîtront probablement jamais complètement, mais nous espérons que vous avez appris pourquoi elles sont si persistantes et comment les bloquer de votre réseau pour de bon.
Pour en savoir plus, vous pouvez consulter l'OWASP Cross-Site Request Forgery Prevention Cheat Sheet, qui constitue un document évolutif décrivant cette vulnérabilité au fur et à mesure de son évolution. Si vous souhaitez vraiment renforcer vos connaissances en matière de sécurité, vous pouvez apprendre à déjouer cette menace et bien d'autres encore en visitant le Secure Code Warrior blog.
Vous pensez être prêt à mettre à l'épreuve vos nouvelles connaissances en matière de défense ? Essayez dès aujourd'hui la démo gratuite de la plateforme Secure Code Warrior .
Table des matières
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationTéléchargerRessources pour vous aider à démarrer
Évaluation comparative des compétences en matière de sécurité : Rationalisation de la conception sécurisée dans l'entreprise
Il est notoirement difficile de trouver des données significatives sur le succès des initiatives Secure-by-Design. Les RSSI sont souvent confrontés à des difficultés lorsqu'ils tentent de prouver le retour sur investissement (ROI) et la valeur commerciale des activités du programme de sécurité, tant au niveau des personnes que de l'entreprise. De plus, il est particulièrement difficile pour les entreprises d'obtenir des informations sur la façon dont leurs organisations sont comparées aux normes actuelles du secteur. La stratégie nationale de cybersécurité du président a mis les parties prenantes au défi d'"adopter la sécurité et la résilience dès la conception". Pour que les initiatives de conception sécurisée fonctionnent, il faut non seulement donner aux développeurs les compétences nécessaires pour assurer la sécurité du code, mais aussi garantir aux régulateurs que ces compétences sont en place. Dans cette présentation, nous partageons une myriade de données qualitatives et quantitatives, dérivées de sources primaires multiples, y compris des points de données internes collectés auprès de plus de 250 000 développeurs, des informations sur les clients basées sur des données, et des études publiques. En nous appuyant sur cette agrégation de points de données, nous visons à communiquer une vision de l'état actuel des initiatives Secure-by-Design dans de multiples secteurs verticaux. Le rapport explique en détail pourquoi cet espace est actuellement sous-utilisé, l'impact significatif qu'un programme de perfectionnement réussi peut avoir sur l'atténuation des risques de cybersécurité, et le potentiel d'élimination des catégories de vulnérabilités d'une base de code.
Passez de la sensibilisation à l'action en ce mois de la cyber-sensibilisation
En octobre, passez de la sensibilisation à l'action. Rendez le Mois de la sensibilisation à la cybernétique mémorable pour vos développeurs grâce à une expérience à fort impact et à forte participation, dirigée par l'équipe des services professionnels de Secure Code Warrior.
Services professionnels - Accélérer grâce à l'expertise
L'équipe des services de stratégie de programme (PSS) de Secure Code Warriorvous aide à construire, améliorer et optimiser votre programme de codage sécurisé. Que vous partiez de zéro ou que vous affiniez votre approche, nos experts vous fournissent des conseils sur mesure.
Thèmes et contenu de la formation sur le code sécurisé
Notre contenu, à la pointe de l'industrie, évolue constamment pour s'adapter au paysage du développement logiciel en constante évolution, tout en gardant votre rôle à l'esprit. Les sujets abordés vont de l'IA à l'injection XQuery, et sont proposés pour une variété de rôles, des architectes et ingénieurs aux gestionnaires de produits et à l'assurance qualité. Découvrez en avant-première ce que notre catalogue de contenu a à offrir par sujet et par rôle.
Ressources pour vous aider à démarrer
Vibe Coding va-t-il transformer votre base de code en une fête de fraternité ?
Le codage vibratoire est comme une fête de fraternité universitaire, et l'IA est la pièce maîtresse de toutes les festivités, le tonneau. C'est très amusant de se laisser aller, d'être créatif et de voir où votre imagination peut vous mener, mais après quelques barils, boire (ou utiliser l'IA) avec modération est sans aucun doute la solution la plus sûre à long terme.
La décennie des défenseurs : Secure Code Warrior Dixième anniversaire
Secure Code WarriorL'équipe fondatrice de SCW est restée soudée, dirigeant le navire à travers chaque leçon, chaque triomphe et chaque revers pendant une décennie entière. Nous nous développons et sommes prêts à affronter notre prochain chapitre, SCW 2.0, en tant que leaders de la gestion des risques pour les développeurs.
Codage axé sur le développeur.
En toute sécurité.
Contactez-nous dès aujourd'hui et faites de la sécurité des logiciels une partie intrinsèque de votre processus de développement.
