Comment puis-je protéger mon site Web contre le bitquatting?
Je viens de lire un article sur bitsquatting (qui fait référence à l'enregistrement d'un nom de domaine un peu différent d'un domaine populaire) et je me demande comment cela pourrait permettre à un attaquant de charger le sien actifs sur mon site Web.
Par exemple, si mon site Web se trouve à https://www.example.org/ charge un fichier de script situé dans https://www.example.org/script.js, un attaquant pourrait alors enregistrer dxample.org et héberger un fichier JS malveillant, qui serait téléchargé et exécuté par certains utilisateurs de mon site Web.
Existe-t-il une technique de défense standard contre cela?
Existe-t-il une technique de défense standard contre cela?
Comme indiqué dans les autres réponses, les erreurs de bits lors de la requête de noms de domaine peuvent ne pas constituer une menace réaliste pour votre application Web. Mais en supposant qu'ils le soient, alors Intégrité des sous-ressources (SRI) aide.
Avec SRI, vous spécifiez un hachage de la ressource que vous chargez dans un attribut integrity, comme ceci:
<script src="http://www.example.org/script.js"
integrity="sha256-DEC+zvj7g7TQNHduXs2G7b0IyOcJCTTBhRRzjoGi4Y4="
crossorigin="anonymous">
</script>
À partir de maintenant, peu importe si le script est récupéré à partir d'un domaine différent en raison d'une erreur de bit (ou modifié par un MITM) car votre navigateur refusera d'exécuter le script si le hachage de son contenu ne correspond pas à la valeur d'intégrité. Donc, lorsqu'une petite erreur, ou toute autre chose, a rendu l'URL résolue au dxample.org Contrôlé par l'attaquant, le seul script qu'ils pourraient injecter avec succès serait celui correspondant au hachage (c'est-à-dire le script que vous aviez l'intention de charger en tous cas).
Le principal cas d'utilisation de SRI est la récupération de scripts et de feuilles de style à partir de CDN potentiellement non fiables, mais il fonctionne dans tous les scénarios où vous souhaitez vous assurer que la ressource demandée n'est pas modifiée.
Notez que SRI est limité à script et link pour l'instant, mais la prise en charge d'autres balises peut venir plus tard:
Remarque: Une future révision de cette spécification inclura probablement la prise en charge de l'intégrité pour toutes les sous-ressources possibles, c'est-à-dire
a,audio,embed,iframe,img,link,object,script,source,tracketvideoéléments.
Votre préoccupation est très probablement infondée.
Tout d'abord, vous devez comprendre à quel point ces dysfonctionnements de la mémoire sont improbables. La personne qui a écrit l'article ci-dessus a enregistré des demandes auprès de 32 clones de certains des domaines les plus visités sur Internet au cours des 7 derniers mois. Ces 52 317 visites devaient figurer parmi des centaines de milliards de demandes. À moins que vous exploitiez un site Web à l'échelle de Facebook, un attaquant devrait être extrêmement chanceux pour ne même avoir qu'une seule victime malchanceuse sur son domaine de bitsquatting.
Ensuite, vous devez noter que les erreurs de mémoire provoquent plusieurs dysfonctionnements. L'auteur écrit:
Ces requêtes [...] montrent des signes d'erreurs de plusieurs bits.
Si le système de la victime est tellement cassé qu'elle ne peut même pas envoyer de requête HTTP sans plusieurs erreurs binaires, alors tout logiciel malveillant qu'ils téléchargent depuis ne s'exécutera probablement pas sans erreurs non plus. C'est un miracle qu'il ait même réussi à démarrer dans cet état.
Et en ce qui concerne les cas où des erreurs de bits ont été trouvées dans des "caches d'applications Web, des résolveurs DNS et un serveur proxy" et affectant ainsi plusieurs utilisateurs (certains d'entre eux peuvent être assez malchanceux pour obtenir suffisamment de malwares dans un état exécutable): Dans ces situations , la réponse HTTP proviendrait d'un serveur différent de celui demandé par le client. Donc, lorsque vous utilisez uniquement HTTPS (ce que je suppose que vous faites, ou vous auriez des attaques bien plus graves à craindre), leur signature ne sera pas vérifiée et le navigateur ne téléchargera pas cette ressource.
Et en plus, HTTPS rendra également beaucoup moins probable une connexion réussie quand il y a un système avec cassé RAM sur la route. Un simple bit-flip dans un message crypté TLS empêchera la le hachage de la vérification, donc le récepteur le rejettera.
tl; dr: arrêtez de vous inquiéter et configurez HTTPS uniquement.
Je doute de la fiabilité de l'article. Bien que discuté au DEFCON et publié en tant que livre blanc, j'ai de sérieuses préoccupations concernant les résultats expérimentaux.
Selon le commentaire de @mootmoot, l'auteur n'a pas réussi à déterminer les erreurs de programmation déterministes à partir des fluctuations aléatoires des bits.
Ma déclaration concernant est
Pendant la période d'abattage [sept. 2010/mai 2011, ndr] il y a eu un total de 52 317 requêtes de bitquat provenant de 12 949 adresses IP uniques
Non, l'auteur a seulement prouvé que ses domaines accroupis avaient été contactés, mais n'a probablement pas fourni d'informations supplémentaires
- Quel pourcentage du réseau CDN d'origine ce trafic représente-t-il (c'est vérifiable en théorie, mais je n'ai pas ces chiffres)
- Occurrence des domaines de référence source
Le second est très important car il permet d'isoler les échecs de programmation déterministes de la fluctuation aléatoire des bits.
Prenons l'exemple suivant: si vous trouvez une entrée dans gbcdn.net (facebook squat) avec référent https://facebook.com vous avez probablement trouvé un bitquat.
Si au contraire vous trouvez plusieurs entrées d'un site Web mal connu que vous pouvez inspecter pour trouver avec un bouton comme cassé, alors le problème est probablement dû à un programmeur qui ne copie pas/ne colle pas le code correctement, ou même un petit retournement s'est produit dans l'IDE du programmeur. Qui sait...
Avertissement : Je suis un employé d'Emaze Networks S.p.A.
Une façon de se défendre contre ce type d'attaques consiste à ne pas autoriser les attaquants à enregistrer des noms de domaine similaires.
Pour ce faire, vous pouvez enregistrer de nombreux domaines bitquattés/typosquattés avec votre nom de domaine principal, mais cela est impossible à faire avec tous les cas de bitquatting/typosquatting, car ils peuvent être des milliards (pensez également à unicode, etc.!).
Une alternative consiste à surveiller périodiquement les domaines enregistrés, et si vous trouvez un domaine suspect, vous pouvez vérifier ce qu'il fait et, s'il semble être un site malveillant, vous pouvez le signaler au registraire et lui demander de transmettre la propriété dudit domaine. domaine pour vous.
Nous avons un petit service, appelé Precog qui fait cela, en agrégeant les informations du bureau d'enregistrement de différentes sources et en exécutant différents types de requêtes pour détecter les domaines de bitsquatting/typosquatting/punycode-squatting: vous pouvez enregistrer votre marque, mettre quelques mots-clés et nous vous contacterons si un domaine suspect est enregistré.
Notre outil prend en considération les domaines de 2e niveau, bien sûr, mais est également capable de détecter l'enregistrement de nombreux domaines de 3e niveau (ou plus), donc nous peut-être pouvoir détecter que quelqu'un va utiliser app1e.account.com pour essayer de voler vos informations d'identification Apple.
Je dois ajouter: je crois que le plus grand cas d'utilisation pour des attaques de ce type n'est pas de "avoir de la chance" de recevoir une demande parce que quelqu'un a mal tapé le domaine, mais d'utiliser le domaine comme domaine de phishing. Les gens vont donc enregistrer le site àpple.com et envoyer des tonnes de courriels qui ressemblent aux courriels d'Apple et essayer d'amener certaines personnes à insérer leurs informations d'identification/informations de carte de crédit sur leur page.
Parmi toutes les réponses, je suis surpris de ne pas avoir vu de référence à Content Security Policy .
Il s'agit essentiellement d'une solution unique pour la liste blanche des sources de contenu autorisées. Une solution simple serait d'autoriser uniquement JavaScript de votre domaine actuel (www.example.com) et de bloquer tout le reste.
La réponse d'Arminius est excellente. Vous pouvez également utiliser une forte Politique de sécurité du conten comme autre ligne de défense contre le squattage de bits.
CSP est un en-tête HTTP qui vous permet de créer une liste blanche affinée d'URI avec lesquels votre site Web peut communiquer. Par exemple, vous pouvez dire au navigateur que vous autoriserez uniquement JavaScript à venir de example.org/js/file1.js, seulement des images de example.com/imgs et des polices de example.net.
Pour qu'une attaque de squattage de bits soit réussie, ils doivent retourner un peu dans l'en-tête HTTP ET dans la demande. Si un attaquant ne peut retourner qu'un bit, votre site Web générera de nombreuses erreurs, quel que soit le bit retourné.