Les codeurs conquièrent la sécurité : série Share & Learn - Falsification de requêtes intersites
Contrairement aux attaques visant directement les opérateurs de sites Web ou d'applications, l'objectif de nombreuses attaques CSRF (Cross-Site Request Forgery) 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 la responsabilité du site d'hébergement par le code non sécurisé. Et si l'utilisateur ciblé perd ses informations d'identification ou voit son mot de passe modifié sans le savoir, 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 reposent sur plusieurs couches pour réussir. En d'autres termes, beaucoup de choses doivent se passer en faveur de l'attaquant pour que cela fonctionne. Malgré cela, ils constituent un vecteur d'attaque extrêmement populaire car une attaque réussie peut transférer de l'argent directement à un pirate informatique, ou le configurer pour qu'il puisse se déplacer sur un site en toute impunité. Si tout se passe comme prévu, l'utilisateur ciblé ne saura peut-être même jamais qu'il a été victime d'une attaque.
La bonne nouvelle, c'est qu'étant donné qu'il reste encore beaucoup à faire pour qu'une attaque de la CSRF fonctionne, il existe de nombreuses techniques défensives efficaces qui peuvent les arrêter.
À cette fin, nous aborderons trois aspects clés des attaques CSRF :
- Comment ils fonctionnent
- Pourquoi sont-ils si dangereux
- Comment mettre en place des défenses pour les empêcher de refroidir.
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 à des utilisateurs ciblés, elles sont populaires malgré le travail considérable nécessaire pour les créer. Et comme ils sont souvent essayés sur différentes plateformes, ils ont acquis au fil des ans une variété de noms et de surnoms. Vous pouvez entendre des attaques CSRF appelées XSRF, Sea Surf, Session Riding, Cross-Site Reference Falgery ou Hostile Linking. Microsoft aime les qualifier d'attaques en un clic dans la plupart de sa documentation. Mais ce sont toutes des attaques CSRF, et les techniques pour les vaincre sont identiques.
Une attaque CSRF peut se produire si un utilisateur est connecté à un site faisant des affaires ou effectuant son travail. L'essentiel est que l'utilisateur soit connecté et authentifié activement sur un site Web ou une application. L'attaque est normalement lancée à partir d'un site Web secondaire ou d'un e-mail. Les attaquants utilisent souvent des techniques d'ingénierie sociale pour inciter les utilisateurs à cliquer sur un lien contenu dans un e-mail qui les redirige vers un site Web compromis contenant le script d'attaque.
Le site Web compromis contient un script qui demande au navigateur actif d'exécuter des commandes, généralement malveillantes, 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 pensera 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 les mots de passe nécessaires pour accéder au site. Ils peuvent même être situés à l'intérieur d'une zone géographique, assis correctement à leur terminal de bureau. S'ils souhaitent modifier leur mot de passe ou transférer des fonds, il n'y a aucune raison de ne pas croire que c'est eux qui en font la demande.
Si l'on analyse les éléments de l'attaque, on comprend pourquoi celle-ci est si difficile à réaliser pour l'attaquant. Pour commencer, l'utilisateur doit s'authentifier activement auprès du site sur lequel l'attaque a lieu. Si un e-mail contenant un script d'attaque arrive alors qu'un utilisateur a mis fin à sa session de navigation ou s'est déconnecté, l'attaque échoue.
L'attaquant est également obligé d'effectuer de nombreuses reconnaissances sur le site ciblé afin de savoir quels scripts ce site acceptera. Les attaquants ne peuvent pas voir l'écran de la victime, et tous les commentaires provenant du site Web seront adressés à la victime, et non à l'attaquant. À moins que l'attaquant ne soit en mesure de voir des preuves de l'efficacité de son attaque, comme l'apparition soudaine d'argent sur son compte, il ne saura même pas immédiatement si l'attaque a été couronnée de succès.
Dans la limite des paramètres difficiles, mais pas impossibles, liés à la connexion de l'utilisateur au moment de l'attaque et à la connaissance des scripts acceptés par le site ciblé, 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 application bancaire ou financière utilise des requêtes GET pour transférer de l'argent, comme ceci :
ACCÉDEZ À http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1
Ce code enverrait une demande de transfert de 100$ à un utilisateur nommé NancySmith12.
Mais si l'utilisateur ciblé reçoit un e-mail, peut-être déguisé en celui d'un collègue, un script d'attaque CSRF peut être intégré au clic :
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Pouvez-vous lire rapidement ce rapport trimestriel ? <a></a></a>
Si l'utilisateur ciblé tombait dans le piège du lien d'ingénierie sociale et cliquait dessus alors que la session du navigateur avec l'application financière était toujours ouverte, son navigateur demanderait à l'application d'envoyer 100 000$ 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 à effectuer la demande, comme suit :
<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 reçoit 100 000$ sans que personne ne détecte l'attaque.
Pourquoi le CSRF est-il si dangereux ?
Les attaques CSRF sont populaires aujourd'hui pour la même raison que les attaques de rançongiciels continuent de se multiplier. Cela permet de faire très peu de compromis entre les agresseurs et l'argent de la victime. Lors d'une attaque par rançongiciel, les systèmes sont cryptés et les utilisateurs sont extorqués de l'argent pour déchiffrer ces données. Avec une attaque CSRF, le nombre d'étapes est encore plus court. Lorsqu'elles travaillent, les victimes envoient simplement de l'argent aux agresseurs 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 si un attaquant pouvait utiliser un exploit CSRF pour modifier le mot de passe d'un administrateur. Ils pouvaient immédiatement utiliser ce mot de passe pour commencer à voler des données, percer des failles 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 chance, une attaque CSRF réussie peut être comme gagner à la loterie pour les pirates, quel que soit leur objectif ultime. Lors de l'attaque d'un réseau, presque tous les autres types d'attaques nécessiteraient des mois de reconnaissance lente et lente, en essayant de rester hors du radar du personnel SIEM et de cybersécurité. En revanche, une seule attaque CSRF peut permettre de sauter plusieurs étapes de la chaîne des cyberattaques, ce qui leur permet de démarrer très près de leur objectif ultime.
Comment arrêter les attaques CSRF ?
Contrairement à la plupart des vulnérabilités, dans le cas des attaques CSRF, la faute ne vient pas vraiment du code, mais d'un exploit créé par les attaquants pour forcer un navigateur à effectuer des requêtes que l'utilisateur ne souhaite pas et dont il n'a peut-être même pas connaissance. Mais ils peuvent être vaincus.
L'une des meilleures méthodes consiste à demander aux développeurs d'ajouter un jeton CSRF à l'identité d'un utilisateur chaque fois qu'une nouvelle session est générée. Il doit être composé d'une chaîne de caractères uniques et aléatoires et être invisible pour les utilisateurs. Ajoutez ensuite la demande de jeton CSRF en tant que champ masqué aux formulaires qui sont vérifiés par le serveur chaque fois qu'une nouvelle demande est soumise. Les attaquants qui soumettent des demandes via le navigateur d'un utilisateur ne seront même pas au courant de l'existence du champ de jeton caché, et encore moins de quoi il s'agit, de sorte que toutes leurs demandes échoueront.
Une méthode encore plus simple, 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. Cela peut être aussi simple que de demander à un utilisateur de cliquer sur un bouton pour confirmer que le demandeur n'est pas un robot ou, dans ce cas, un script CSRF. Les attaquants ne seront pas en mesure de rédiger une réponse au défi, et les utilisateurs qui rencontrent soudainement un défi CAPTCHA sans avoir fait au préalable une demande de transfert d'argent sauront qu'il y a un problème. Il est également possible de générer un mot de passe à usage unique à l'aide d'un jeton tiers, tel qu'un smartphone, en fonction de la mesure dans laquelle l'organisation souhaite ralentir ses travaux au nom de la sécurité.
Enfin, bien que cela ne soit pas infaillible, de nombreux navigateurs comme Microsoft Edge ou Google Chrome disposent désormais de politique en matière de même origine restrictions mises en place pour bloquer les demandes provenant de n'importe qui sauf de l'utilisateur local. Forcer les utilisateurs à interagir avec votre site en utilisant les versions les plus récentes de ces navigateurs peut contribuer à intégrer une autre couche de sécurité CSRF sans aucune charge pour les équipes de développement.
Claquer la porte sur la CSRF
Avec un potentiel de paiement aussi élevé, 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 définitivement de votre réseau.
Pour en savoir plus, vous pouvez consulter l'aide-mémoire de l'OWASP Cross-Site Request Forgery Prevention, qui sert de document évolutif retraçant cette vulnérabilité au fur et à mesure de son évolution. Si vous souhaitez vraiment approfondir vos connaissances en matière de sécurité, vous pouvez apprendre à vaincre cette menace et bien d'autres encore en consultant le Secure Code Warrior bloguer.
Vous pensez être prêt à mettre vos nouvelles connaissances en matière de défense à l'épreuve ? Jouez avec le démo gratuite de la plateforme Secure Code Warrior aujourd'hui.
Les attaques CSRF sont assez complexes et reposent sur plusieurs couches pour réussir. En d'autres termes, beaucoup de choses doivent se passer en faveur de l'attaquant pour que cela fonctionne. Malgré cela, ils constituent 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 Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchen
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 CSRF (Cross-Site Request Forgery) 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 la responsabilité du site d'hébergement par le code non sécurisé. Et si l'utilisateur ciblé perd ses informations d'identification ou voit son mot de passe modifié sans le savoir, 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 reposent sur plusieurs couches pour réussir. En d'autres termes, beaucoup de choses doivent se passer en faveur de l'attaquant pour que cela fonctionne. Malgré cela, ils constituent un vecteur d'attaque extrêmement populaire car une attaque réussie peut transférer de l'argent directement à un pirate informatique, ou le configurer pour qu'il puisse se déplacer sur un site en toute impunité. Si tout se passe comme prévu, l'utilisateur ciblé ne saura peut-être même jamais qu'il a été victime d'une attaque.
La bonne nouvelle, c'est qu'étant donné qu'il reste encore beaucoup à faire pour qu'une attaque de la CSRF fonctionne, il existe de nombreuses techniques défensives efficaces qui peuvent les arrêter.
À cette fin, nous aborderons trois aspects clés des attaques CSRF :
- Comment ils fonctionnent
- Pourquoi sont-ils si dangereux
- Comment mettre en place des défenses pour les empêcher de refroidir.
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 à des utilisateurs ciblés, elles sont populaires malgré le travail considérable nécessaire pour les créer. Et comme ils sont souvent essayés sur différentes plateformes, ils ont acquis au fil des ans une variété de noms et de surnoms. Vous pouvez entendre des attaques CSRF appelées XSRF, Sea Surf, Session Riding, Cross-Site Reference Falgery ou Hostile Linking. Microsoft aime les qualifier d'attaques en un clic dans la plupart de sa documentation. Mais ce sont toutes des attaques CSRF, et les techniques pour les vaincre sont identiques.
Une attaque CSRF peut se produire si un utilisateur est connecté à un site faisant des affaires ou effectuant son travail. L'essentiel est que l'utilisateur soit connecté et authentifié activement sur un site Web ou une application. L'attaque est normalement lancée à partir d'un site Web secondaire ou d'un e-mail. Les attaquants utilisent souvent des techniques d'ingénierie sociale pour inciter les utilisateurs à cliquer sur un lien contenu dans un e-mail qui les redirige vers un site Web compromis contenant le script d'attaque.
Le site Web compromis contient un script qui demande au navigateur actif d'exécuter des commandes, généralement malveillantes, 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 pensera 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 les mots de passe nécessaires pour accéder au site. Ils peuvent même être situés à l'intérieur d'une zone géographique, assis correctement à leur terminal de bureau. S'ils souhaitent modifier leur mot de passe ou transférer des fonds, il n'y a aucune raison de ne pas croire que c'est eux qui en font la demande.
Si l'on analyse les éléments de l'attaque, on comprend pourquoi celle-ci est si difficile à réaliser pour l'attaquant. Pour commencer, l'utilisateur doit s'authentifier activement auprès du site sur lequel l'attaque a lieu. Si un e-mail contenant un script d'attaque arrive alors qu'un utilisateur a mis fin à sa session de navigation ou s'est déconnecté, l'attaque échoue.
L'attaquant est également obligé d'effectuer de nombreuses reconnaissances sur le site ciblé afin de savoir quels scripts ce site acceptera. Les attaquants ne peuvent pas voir l'écran de la victime, et tous les commentaires provenant du site Web seront adressés à la victime, et non à l'attaquant. À moins que l'attaquant ne soit en mesure de voir des preuves de l'efficacité de son attaque, comme l'apparition soudaine d'argent sur son compte, il ne saura même pas immédiatement si l'attaque a été couronnée de succès.
Dans la limite des paramètres difficiles, mais pas impossibles, liés à la connexion de l'utilisateur au moment de l'attaque et à la connaissance des scripts acceptés par le site ciblé, 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 application bancaire ou financière utilise des requêtes GET pour transférer de l'argent, comme ceci :
ACCÉDEZ À http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1
Ce code enverrait une demande de transfert de 100$ à un utilisateur nommé NancySmith12.
Mais si l'utilisateur ciblé reçoit un e-mail, peut-être déguisé en celui d'un collègue, un script d'attaque CSRF peut être intégré au clic :
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Pouvez-vous lire rapidement ce rapport trimestriel ? <a></a></a>
Si l'utilisateur ciblé tombait dans le piège du lien d'ingénierie sociale et cliquait dessus alors que la session du navigateur avec l'application financière était toujours ouverte, son navigateur demanderait à l'application d'envoyer 100 000$ 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 à effectuer la demande, comme suit :
<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 reçoit 100 000$ sans que personne ne détecte l'attaque.
Pourquoi le CSRF est-il si dangereux ?
Les attaques CSRF sont populaires aujourd'hui pour la même raison que les attaques de rançongiciels continuent de se multiplier. Cela permet de faire très peu de compromis entre les agresseurs et l'argent de la victime. Lors d'une attaque par rançongiciel, les systèmes sont cryptés et les utilisateurs sont extorqués de l'argent pour déchiffrer ces données. Avec une attaque CSRF, le nombre d'étapes est encore plus court. Lorsqu'elles travaillent, les victimes envoient simplement de l'argent aux agresseurs 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 si un attaquant pouvait utiliser un exploit CSRF pour modifier le mot de passe d'un administrateur. Ils pouvaient immédiatement utiliser ce mot de passe pour commencer à voler des données, percer des failles 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 chance, une attaque CSRF réussie peut être comme gagner à la loterie pour les pirates, quel que soit leur objectif ultime. Lors de l'attaque d'un réseau, presque tous les autres types d'attaques nécessiteraient des mois de reconnaissance lente et lente, en essayant de rester hors du radar du personnel SIEM et de cybersécurité. En revanche, une seule attaque CSRF peut permettre de sauter plusieurs étapes de la chaîne des cyberattaques, ce qui leur permet de démarrer très près de leur objectif ultime.
Comment arrêter les attaques CSRF ?
Contrairement à la plupart des vulnérabilités, dans le cas des attaques CSRF, la faute ne vient pas vraiment du code, mais d'un exploit créé par les attaquants pour forcer un navigateur à effectuer des requêtes que l'utilisateur ne souhaite pas et dont il n'a peut-être même pas connaissance. Mais ils peuvent être vaincus.
L'une des meilleures méthodes consiste à demander aux développeurs d'ajouter un jeton CSRF à l'identité d'un utilisateur chaque fois qu'une nouvelle session est générée. Il doit être composé d'une chaîne de caractères uniques et aléatoires et être invisible pour les utilisateurs. Ajoutez ensuite la demande de jeton CSRF en tant que champ masqué aux formulaires qui sont vérifiés par le serveur chaque fois qu'une nouvelle demande est soumise. Les attaquants qui soumettent des demandes via le navigateur d'un utilisateur ne seront même pas au courant de l'existence du champ de jeton caché, et encore moins de quoi il s'agit, de sorte que toutes leurs demandes échoueront.
Une méthode encore plus simple, 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. Cela peut être aussi simple que de demander à un utilisateur de cliquer sur un bouton pour confirmer que le demandeur n'est pas un robot ou, dans ce cas, un script CSRF. Les attaquants ne seront pas en mesure de rédiger une réponse au défi, et les utilisateurs qui rencontrent soudainement un défi CAPTCHA sans avoir fait au préalable une demande de transfert d'argent sauront qu'il y a un problème. Il est également possible de générer un mot de passe à usage unique à l'aide d'un jeton tiers, tel qu'un smartphone, en fonction de la mesure dans laquelle l'organisation souhaite ralentir ses travaux au nom de la sécurité.
Enfin, bien que cela ne soit pas infaillible, de nombreux navigateurs comme Microsoft Edge ou Google Chrome disposent désormais de politique en matière de même origine restrictions mises en place pour bloquer les demandes provenant de n'importe qui sauf de l'utilisateur local. Forcer les utilisateurs à interagir avec votre site en utilisant les versions les plus récentes de ces navigateurs peut contribuer à intégrer une autre couche de sécurité CSRF sans aucune charge pour les équipes de développement.
Claquer la porte sur la CSRF
Avec un potentiel de paiement aussi élevé, 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 définitivement de votre réseau.
Pour en savoir plus, vous pouvez consulter l'aide-mémoire de l'OWASP Cross-Site Request Forgery Prevention, qui sert de document évolutif retraçant cette vulnérabilité au fur et à mesure de son évolution. Si vous souhaitez vraiment approfondir vos connaissances en matière de sécurité, vous pouvez apprendre à vaincre cette menace et bien d'autres encore en consultant le Secure Code Warrior bloguer.
Vous pensez être prêt à mettre vos nouvelles connaissances en matière de défense à l'épreuve ? Jouez avec le démo gratuite de la plateforme Secure Code Warrior aujourd'hui.
Contrairement aux attaques visant directement les opérateurs de sites Web ou d'applications, l'objectif de nombreuses attaques CSRF (Cross-Site Request Forgery) 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 la responsabilité du site d'hébergement par le code non sécurisé. Et si l'utilisateur ciblé perd ses informations d'identification ou voit son mot de passe modifié sans le savoir, 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 reposent sur plusieurs couches pour réussir. En d'autres termes, beaucoup de choses doivent se passer en faveur de l'attaquant pour que cela fonctionne. Malgré cela, ils constituent un vecteur d'attaque extrêmement populaire car une attaque réussie peut transférer de l'argent directement à un pirate informatique, ou le configurer pour qu'il puisse se déplacer sur un site en toute impunité. Si tout se passe comme prévu, l'utilisateur ciblé ne saura peut-être même jamais qu'il a été victime d'une attaque.
La bonne nouvelle, c'est qu'étant donné qu'il reste encore beaucoup à faire pour qu'une attaque de la CSRF fonctionne, il existe de nombreuses techniques défensives efficaces qui peuvent les arrêter.
À cette fin, nous aborderons trois aspects clés des attaques CSRF :
- Comment ils fonctionnent
- Pourquoi sont-ils si dangereux
- Comment mettre en place des défenses pour les empêcher de refroidir.
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 à des utilisateurs ciblés, elles sont populaires malgré le travail considérable nécessaire pour les créer. Et comme ils sont souvent essayés sur différentes plateformes, ils ont acquis au fil des ans une variété de noms et de surnoms. Vous pouvez entendre des attaques CSRF appelées XSRF, Sea Surf, Session Riding, Cross-Site Reference Falgery ou Hostile Linking. Microsoft aime les qualifier d'attaques en un clic dans la plupart de sa documentation. Mais ce sont toutes des attaques CSRF, et les techniques pour les vaincre sont identiques.
Une attaque CSRF peut se produire si un utilisateur est connecté à un site faisant des affaires ou effectuant son travail. L'essentiel est que l'utilisateur soit connecté et authentifié activement sur un site Web ou une application. L'attaque est normalement lancée à partir d'un site Web secondaire ou d'un e-mail. Les attaquants utilisent souvent des techniques d'ingénierie sociale pour inciter les utilisateurs à cliquer sur un lien contenu dans un e-mail qui les redirige vers un site Web compromis contenant le script d'attaque.
Le site Web compromis contient un script qui demande au navigateur actif d'exécuter des commandes, généralement malveillantes, 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 pensera 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 les mots de passe nécessaires pour accéder au site. Ils peuvent même être situés à l'intérieur d'une zone géographique, assis correctement à leur terminal de bureau. S'ils souhaitent modifier leur mot de passe ou transférer des fonds, il n'y a aucune raison de ne pas croire que c'est eux qui en font la demande.
Si l'on analyse les éléments de l'attaque, on comprend pourquoi celle-ci est si difficile à réaliser pour l'attaquant. Pour commencer, l'utilisateur doit s'authentifier activement auprès du site sur lequel l'attaque a lieu. Si un e-mail contenant un script d'attaque arrive alors qu'un utilisateur a mis fin à sa session de navigation ou s'est déconnecté, l'attaque échoue.
L'attaquant est également obligé d'effectuer de nombreuses reconnaissances sur le site ciblé afin de savoir quels scripts ce site acceptera. Les attaquants ne peuvent pas voir l'écran de la victime, et tous les commentaires provenant du site Web seront adressés à la victime, et non à l'attaquant. À moins que l'attaquant ne soit en mesure de voir des preuves de l'efficacité de son attaque, comme l'apparition soudaine d'argent sur son compte, il ne saura même pas immédiatement si l'attaque a été couronnée de succès.
Dans la limite des paramètres difficiles, mais pas impossibles, liés à la connexion de l'utilisateur au moment de l'attaque et à la connaissance des scripts acceptés par le site ciblé, 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 application bancaire ou financière utilise des requêtes GET pour transférer de l'argent, comme ceci :
ACCÉDEZ À http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1
Ce code enverrait une demande de transfert de 100$ à un utilisateur nommé NancySmith12.
Mais si l'utilisateur ciblé reçoit un e-mail, peut-être déguisé en celui d'un collègue, un script d'attaque CSRF peut être intégré au clic :
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Pouvez-vous lire rapidement ce rapport trimestriel ? <a></a></a>
Si l'utilisateur ciblé tombait dans le piège du lien d'ingénierie sociale et cliquait dessus alors que la session du navigateur avec l'application financière était toujours ouverte, son navigateur demanderait à l'application d'envoyer 100 000$ 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 à effectuer la demande, comme suit :
<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 reçoit 100 000$ sans que personne ne détecte l'attaque.
Pourquoi le CSRF est-il si dangereux ?
Les attaques CSRF sont populaires aujourd'hui pour la même raison que les attaques de rançongiciels continuent de se multiplier. Cela permet de faire très peu de compromis entre les agresseurs et l'argent de la victime. Lors d'une attaque par rançongiciel, les systèmes sont cryptés et les utilisateurs sont extorqués de l'argent pour déchiffrer ces données. Avec une attaque CSRF, le nombre d'étapes est encore plus court. Lorsqu'elles travaillent, les victimes envoient simplement de l'argent aux agresseurs 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 si un attaquant pouvait utiliser un exploit CSRF pour modifier le mot de passe d'un administrateur. Ils pouvaient immédiatement utiliser ce mot de passe pour commencer à voler des données, percer des failles 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 chance, une attaque CSRF réussie peut être comme gagner à la loterie pour les pirates, quel que soit leur objectif ultime. Lors de l'attaque d'un réseau, presque tous les autres types d'attaques nécessiteraient des mois de reconnaissance lente et lente, en essayant de rester hors du radar du personnel SIEM et de cybersécurité. En revanche, une seule attaque CSRF peut permettre de sauter plusieurs étapes de la chaîne des cyberattaques, ce qui leur permet de démarrer très près de leur objectif ultime.
Comment arrêter les attaques CSRF ?
Contrairement à la plupart des vulnérabilités, dans le cas des attaques CSRF, la faute ne vient pas vraiment du code, mais d'un exploit créé par les attaquants pour forcer un navigateur à effectuer des requêtes que l'utilisateur ne souhaite pas et dont il n'a peut-être même pas connaissance. Mais ils peuvent être vaincus.
L'une des meilleures méthodes consiste à demander aux développeurs d'ajouter un jeton CSRF à l'identité d'un utilisateur chaque fois qu'une nouvelle session est générée. Il doit être composé d'une chaîne de caractères uniques et aléatoires et être invisible pour les utilisateurs. Ajoutez ensuite la demande de jeton CSRF en tant que champ masqué aux formulaires qui sont vérifiés par le serveur chaque fois qu'une nouvelle demande est soumise. Les attaquants qui soumettent des demandes via le navigateur d'un utilisateur ne seront même pas au courant de l'existence du champ de jeton caché, et encore moins de quoi il s'agit, de sorte que toutes leurs demandes échoueront.
Une méthode encore plus simple, 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. Cela peut être aussi simple que de demander à un utilisateur de cliquer sur un bouton pour confirmer que le demandeur n'est pas un robot ou, dans ce cas, un script CSRF. Les attaquants ne seront pas en mesure de rédiger une réponse au défi, et les utilisateurs qui rencontrent soudainement un défi CAPTCHA sans avoir fait au préalable une demande de transfert d'argent sauront qu'il y a un problème. Il est également possible de générer un mot de passe à usage unique à l'aide d'un jeton tiers, tel qu'un smartphone, en fonction de la mesure dans laquelle l'organisation souhaite ralentir ses travaux au nom de la sécurité.
Enfin, bien que cela ne soit pas infaillible, de nombreux navigateurs comme Microsoft Edge ou Google Chrome disposent désormais de politique en matière de même origine restrictions mises en place pour bloquer les demandes provenant de n'importe qui sauf de l'utilisateur local. Forcer les utilisateurs à interagir avec votre site en utilisant les versions les plus récentes de ces navigateurs peut contribuer à intégrer une autre couche de sécurité CSRF sans aucune charge pour les équipes de développement.
Claquer la porte sur la CSRF
Avec un potentiel de paiement aussi élevé, 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 définitivement de votre réseau.
Pour en savoir plus, vous pouvez consulter l'aide-mémoire de l'OWASP Cross-Site Request Forgery Prevention, qui sert de document évolutif retraçant cette vulnérabilité au fur et à mesure de son évolution. Si vous souhaitez vraiment approfondir vos connaissances en matière de sécurité, vous pouvez apprendre à vaincre cette menace et bien d'autres encore en consultant le Secure Code Warrior bloguer.
Vous pensez être prêt à mettre vos nouvelles connaissances en matière de défense à l'épreuve ? Jouez avec le démo gratuite de la plateforme Secure Code Warrior aujourd'hui.
Klicken Sie auf den untenstehenden Link und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht anzeigenDemo buchen
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 CSRF (Cross-Site Request Forgery) 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 la responsabilité du site d'hébergement par le code non sécurisé. Et si l'utilisateur ciblé perd ses informations d'identification ou voit son mot de passe modifié sans le savoir, 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 reposent sur plusieurs couches pour réussir. En d'autres termes, beaucoup de choses doivent se passer en faveur de l'attaquant pour que cela fonctionne. Malgré cela, ils constituent un vecteur d'attaque extrêmement populaire car une attaque réussie peut transférer de l'argent directement à un pirate informatique, ou le configurer pour qu'il puisse se déplacer sur un site en toute impunité. Si tout se passe comme prévu, l'utilisateur ciblé ne saura peut-être même jamais qu'il a été victime d'une attaque.
La bonne nouvelle, c'est qu'étant donné qu'il reste encore beaucoup à faire pour qu'une attaque de la CSRF fonctionne, il existe de nombreuses techniques défensives efficaces qui peuvent les arrêter.
À cette fin, nous aborderons trois aspects clés des attaques CSRF :
- Comment ils fonctionnent
- Pourquoi sont-ils si dangereux
- Comment mettre en place des défenses pour les empêcher de refroidir.
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 à des utilisateurs ciblés, elles sont populaires malgré le travail considérable nécessaire pour les créer. Et comme ils sont souvent essayés sur différentes plateformes, ils ont acquis au fil des ans une variété de noms et de surnoms. Vous pouvez entendre des attaques CSRF appelées XSRF, Sea Surf, Session Riding, Cross-Site Reference Falgery ou Hostile Linking. Microsoft aime les qualifier d'attaques en un clic dans la plupart de sa documentation. Mais ce sont toutes des attaques CSRF, et les techniques pour les vaincre sont identiques.
Une attaque CSRF peut se produire si un utilisateur est connecté à un site faisant des affaires ou effectuant son travail. L'essentiel est que l'utilisateur soit connecté et authentifié activement sur un site Web ou une application. L'attaque est normalement lancée à partir d'un site Web secondaire ou d'un e-mail. Les attaquants utilisent souvent des techniques d'ingénierie sociale pour inciter les utilisateurs à cliquer sur un lien contenu dans un e-mail qui les redirige vers un site Web compromis contenant le script d'attaque.
Le site Web compromis contient un script qui demande au navigateur actif d'exécuter des commandes, généralement malveillantes, 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 pensera 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 les mots de passe nécessaires pour accéder au site. Ils peuvent même être situés à l'intérieur d'une zone géographique, assis correctement à leur terminal de bureau. S'ils souhaitent modifier leur mot de passe ou transférer des fonds, il n'y a aucune raison de ne pas croire que c'est eux qui en font la demande.
Si l'on analyse les éléments de l'attaque, on comprend pourquoi celle-ci est si difficile à réaliser pour l'attaquant. Pour commencer, l'utilisateur doit s'authentifier activement auprès du site sur lequel l'attaque a lieu. Si un e-mail contenant un script d'attaque arrive alors qu'un utilisateur a mis fin à sa session de navigation ou s'est déconnecté, l'attaque échoue.
L'attaquant est également obligé d'effectuer de nombreuses reconnaissances sur le site ciblé afin de savoir quels scripts ce site acceptera. Les attaquants ne peuvent pas voir l'écran de la victime, et tous les commentaires provenant du site Web seront adressés à la victime, et non à l'attaquant. À moins que l'attaquant ne soit en mesure de voir des preuves de l'efficacité de son attaque, comme l'apparition soudaine d'argent sur son compte, il ne saura même pas immédiatement si l'attaque a été couronnée de succès.
Dans la limite des paramètres difficiles, mais pas impossibles, liés à la connexion de l'utilisateur au moment de l'attaque et à la connaissance des scripts acceptés par le site ciblé, 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 application bancaire ou financière utilise des requêtes GET pour transférer de l'argent, comme ceci :
ACCÉDEZ À http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1
Ce code enverrait une demande de transfert de 100$ à un utilisateur nommé NancySmith12.
Mais si l'utilisateur ciblé reçoit un e-mail, peut-être déguisé en celui d'un collègue, un script d'attaque CSRF peut être intégré au clic :
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Pouvez-vous lire rapidement ce rapport trimestriel ? <a></a></a>
Si l'utilisateur ciblé tombait dans le piège du lien d'ingénierie sociale et cliquait dessus alors que la session du navigateur avec l'application financière était toujours ouverte, son navigateur demanderait à l'application d'envoyer 100 000$ 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 à effectuer la demande, comme suit :
<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 reçoit 100 000$ sans que personne ne détecte l'attaque.
Pourquoi le CSRF est-il si dangereux ?
Les attaques CSRF sont populaires aujourd'hui pour la même raison que les attaques de rançongiciels continuent de se multiplier. Cela permet de faire très peu de compromis entre les agresseurs et l'argent de la victime. Lors d'une attaque par rançongiciel, les systèmes sont cryptés et les utilisateurs sont extorqués de l'argent pour déchiffrer ces données. Avec une attaque CSRF, le nombre d'étapes est encore plus court. Lorsqu'elles travaillent, les victimes envoient simplement de l'argent aux agresseurs 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 si un attaquant pouvait utiliser un exploit CSRF pour modifier le mot de passe d'un administrateur. Ils pouvaient immédiatement utiliser ce mot de passe pour commencer à voler des données, percer des failles 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 chance, une attaque CSRF réussie peut être comme gagner à la loterie pour les pirates, quel que soit leur objectif ultime. Lors de l'attaque d'un réseau, presque tous les autres types d'attaques nécessiteraient des mois de reconnaissance lente et lente, en essayant de rester hors du radar du personnel SIEM et de cybersécurité. En revanche, une seule attaque CSRF peut permettre de sauter plusieurs étapes de la chaîne des cyberattaques, ce qui leur permet de démarrer très près de leur objectif ultime.
Comment arrêter les attaques CSRF ?
Contrairement à la plupart des vulnérabilités, dans le cas des attaques CSRF, la faute ne vient pas vraiment du code, mais d'un exploit créé par les attaquants pour forcer un navigateur à effectuer des requêtes que l'utilisateur ne souhaite pas et dont il n'a peut-être même pas connaissance. Mais ils peuvent être vaincus.
L'une des meilleures méthodes consiste à demander aux développeurs d'ajouter un jeton CSRF à l'identité d'un utilisateur chaque fois qu'une nouvelle session est générée. Il doit être composé d'une chaîne de caractères uniques et aléatoires et être invisible pour les utilisateurs. Ajoutez ensuite la demande de jeton CSRF en tant que champ masqué aux formulaires qui sont vérifiés par le serveur chaque fois qu'une nouvelle demande est soumise. Les attaquants qui soumettent des demandes via le navigateur d'un utilisateur ne seront même pas au courant de l'existence du champ de jeton caché, et encore moins de quoi il s'agit, de sorte que toutes leurs demandes échoueront.
Une méthode encore plus simple, 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. Cela peut être aussi simple que de demander à un utilisateur de cliquer sur un bouton pour confirmer que le demandeur n'est pas un robot ou, dans ce cas, un script CSRF. Les attaquants ne seront pas en mesure de rédiger une réponse au défi, et les utilisateurs qui rencontrent soudainement un défi CAPTCHA sans avoir fait au préalable une demande de transfert d'argent sauront qu'il y a un problème. Il est également possible de générer un mot de passe à usage unique à l'aide d'un jeton tiers, tel qu'un smartphone, en fonction de la mesure dans laquelle l'organisation souhaite ralentir ses travaux au nom de la sécurité.
Enfin, bien que cela ne soit pas infaillible, de nombreux navigateurs comme Microsoft Edge ou Google Chrome disposent désormais de politique en matière de même origine restrictions mises en place pour bloquer les demandes provenant de n'importe qui sauf de l'utilisateur local. Forcer les utilisateurs à interagir avec votre site en utilisant les versions les plus récentes de ces navigateurs peut contribuer à intégrer une autre couche de sécurité CSRF sans aucune charge pour les équipes de développement.
Claquer la porte sur la CSRF
Avec un potentiel de paiement aussi élevé, 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 définitivement de votre réseau.
Pour en savoir plus, vous pouvez consulter l'aide-mémoire de l'OWASP Cross-Site Request Forgery Prevention, qui sert de document évolutif retraçant cette vulnérabilité au fur et à mesure de son évolution. Si vous souhaitez vraiment approfondir vos connaissances en matière de sécurité, vous pouvez apprendre à vaincre cette menace et bien d'autres encore en consultant le Secure Code Warrior bloguer.
Vous pensez être prêt à mettre vos nouvelles connaissances en matière de défense à l'épreuve ? Jouez avec le démo gratuite de la plateforme Secure Code Warrior aujourd'hui.
Inhaltsverzeichnis
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen, die Ihnen den Einstieg erleichtern
Themen und Inhalte der Schulung zum sicheren Code
Unsere hochmodernen Inhalte werden ständig weiterentwickelt, um mit den ständigen Veränderungen in der Softwareentwicklungslandschaft Schritt zu halten und gleichzeitig Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis hin zu XQuery-Injection und sind für eine Vielzahl von Positionen konzipiert, von Architekten über Ingenieure bis hin zu Produktmanagern und Qualitätssicherungsmitarbeitern. Verschaffen Sie sich einen Überblick über die Inhalte unseres Katalogs, sortiert nach Themen und Rollen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen, die Ihnen den Einstieg erleichtern
Cybermon ist zurück: Die missions „Beat the Boss“ sind jetzt auf Abruf verfügbar.
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über in SCW verfügbar. Setzen Sie fortschrittliche Sicherheitsherausforderungen im Zusammenhang mit KI und LLM ein, um die sichere Entwicklung von KI in großem Maßstab zu stärken.
Erläuterung des Gesetzes zur Cyberresilienz: Was bedeutet das für die Entwicklung sicherer Software bereits ab der Konzeption?
Entdecken Sie, was das europäische Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams durch Sicherheitsmaßnahmen bereits in der Entwurfsphase, durch die Vermeidung von Schwachstellen und durch die Stärkung der Fähigkeiten der Entwickler darauf vorbereiten können.
Moderator 1: Definierte und messbare Erfolgskriterien
Enabler 1 gibt den Startschuss für unsere 10-teilige Serie mit dem Titel „Enablers of Success“ und zeigt, wie sichere Codierung mit geschäftlichen Ergebnissen wie Risikominderung und Schnelligkeit kombiniert werden kann, um die langfristige Reife von Programmen sicherzustellen.
