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
Le mouvement "Secure-by-Design" (conception sécurisée) est l'avenir du développement de logiciels sécurisés. Découvrez les éléments clés que les entreprises doivent garder à l'esprit lorsqu'elles envisagent une initiative de conception sécurisée.
DigitalOcean réduit sa dette de sécurité avec Secure Code Warrior
L'utilisation par DigitalOcean de la formation Secure Code Warrior a considérablement réduit la dette de sécurité, permettant aux équipes de se concentrer davantage sur l'innovation et la productivité. L'amélioration de la sécurité a renforcé la qualité des produits et l'avantage concurrentiel de l'entreprise. À l'avenir, le score de confiance SCW les aidera à améliorer leurs pratiques de sécurité et à continuer à stimuler l'innovation.
Ressources pour vous aider à démarrer
La note de confiance révèle la valeur des initiatives d'amélioration de la sécurité par la conception
Nos recherches ont montré que la formation au code sécurisé fonctionne. Le Trust Score, qui utilise un algorithme s'appuyant sur plus de 20 millions de points de données d'apprentissage issus du travail de plus de 250 000 apprenants dans plus de 600 organisations, révèle son efficacité à réduire les vulnérabilités et la manière de rendre l'initiative encore plus efficace.
.png)
Sécurité réactive contre sécurité préventive : La prévention est un meilleur remède
L'idée d'apporter une sécurité préventive aux codes et systèmes existants en même temps qu'aux applications plus récentes peut sembler décourageante, mais une approche "Secure-by-Design", mise en œuvre en améliorant les compétences des développeurs, permet d'appliquer les meilleures pratiques de sécurité à ces systèmes. C'est la meilleure chance qu'ont de nombreuses organisations d'améliorer leur sécurité.
Les avantages de l'évaluation des compétences des développeurs en matière de sécurité
L'importance croissante accordée au code sécurisé et aux principes de conception sécurisée exige que les développeurs soient formés à la cybersécurité dès le début du cycle de développement durable, et que des outils tels que le Trust Score de Secure Code Warriorles aident à mesurer et à améliorer leurs progrès.
Assurer le succès des initiatives de conception sécurisée de l'entreprise
Notre dernier document de recherche, Benchmarking Security Skills : Streamlining Secure-by-Design in the Enterprise est le résultat d'une analyse approfondie d'initiatives réelles de conception sécurisée au niveau de l'entreprise, et de l'élaboration d'approches de meilleures pratiques basées sur des conclusions fondées sur des données.
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.
