Source originale : Edgecast
La sécurité des applications Web reste un vecteur de menace majeur pour les entreprises, grandes et petites. Selon le rapport d’enquête sur les violations de données (DBIR) de Verizon 2020, 43 % de toutes les violations de données impliquaient une application Web,¹ et 80 % de tous les vecteurs de piratage ciblaient les applications Web.²
Au quatrième trimestre 2020, Verizon Media a enregistré une augmentation marquée du trafic de script inter-site (XSS) sur notre réseau de diffusion de contenu (CDN) par rapport aux trimestres précédents. Ce blog explore certains points de données de trafic et dissèque l’une des charges utiles XSS les plus tentées. Nous partageons également comment utiliser ces données pour appliquer des mesures de protection.
Utilisez ce contenu comme un guide axé sur l’action sur la gestion du trafic XSS potentiellement malveillant qui frappe à la porte d’entrée de votre organisation. Cela peut également vous aider à avoir une conversation nécessaire sur la sécurité avec votre équipe de direction et vos homologues opérationnels/commerciaux.
We ayez les données — explorons-les
The Verizon Media WAF a atténué 1,5 milliard de demandes au quatrième trimestre 2020. Nous définissons « atténuer » comme tout événement WAF qui a déclenché un blocage, une réponse personnalisée ou une redirection d’URL. Ces 1,5 milliards de blocs représentent des requêtes HTTP qui, autrement, auraient atteint les serveurs d’origine de nos clients. Ces données nous indiquent :
- La quantité d’analyses de vulnérabilité en arrière-plan est immense. Vous vous trompez si vous pensez être en sécurité parce que votre cible ne vaut pas la peine d’être attaquée ou parce que vous n’êtes pas bien connu. Selon le Verizon DBIR, « si vous nous autorisez une métaphore mixte, il n’y a pas d’emporter sur l’ours dans ce cas, car les ours sont tous imprimés en 3D en vrac et automatisés pour vous chasser. »³
- Si vos applications Web sont sécurisées, une telle analyse peut ne pas sembler plus nuisible qu’un cambrioleur qui jiggling des poignées de porte, et permettre à un tel trafic d’atteindre vos serveurs est inoffensif autre que d’encourir une charge supplémentaire sur votre serveur. Mais dans la guerre asymétrique de cybersécurité, l’attaquant n’a besoin d’avoir raison qu’une seule fois, ce qui lui permet d’avoir plus facilement raison à l’avenir. Alors pourquoi laisser le cambrioleur secouer la poignée de porte si vous pouvez l’empêcher?
Pour pousser cette maison un peu plus loin, examinons de plus près certains des embouteillages bloqués à partir du quatrième trimestre 2020.
Au cours des trois derniers trimestres, le trafic bloqué de script inter-site (XSS) est passé de la première place au deuxième trimestre 2020 à la quatrième place au quatrième trimestre 2020, doublant presque en volume au cours de cette période, représentant 10 % du trafic bloqué.
Figure 1. En seulement six mois, nous avons vu le trafic XSS plus que doubler.
Getting pour connaître votre trafic XSS
According pour Open Web application Security Project (OWASP), des failles XSS se produisent lorsqu’une application inclut des données non fiables dans une nouvelle page Web sans validation ou échappement approprié ou lorsqu’une application met à jour une page Web existante avec des données fournies par l’utilisateur à l’aide d’une API de navigateur pouvant créer du HTML ou du JavaScript. XSS permet aux attaquants d’exécuter des scripts dans le navigateur de la victime, ce qui peut pirater des sessions utilisateur, dégrader des sites Web ou rediriger l’utilisateur vers des sites malveillants.
Cette exposition menace votre infrastructure, la confidentialité et l’intégrité des données, ainsi que la disponibilité des données fournies sur Internet. Ces attaques peuvent entraîner un accès non autorisé au contenu, la perte d’informations personnelles identifiables (PII) et la diffusion d’informations privées/protégées par des droits d’auteur.
C’est un problème car rien n’est caché une fois qu’il est connecté et exposé à Internet : si vous le levez, il sera scanné. Une fois qu’une nouvelle application Web sera mise en ligne et exposée à Internet, elle sera testée pour voir comment elle réagit aux différentes actions ou demandes. Les résultats de ces découvertes peuvent créer une tournure intéressante de l’intrigue, que nous discuterons sous peu.
Tout d’abord, continuons d’explorer la portée de l’exposition potentielle. De nombreux sites Web, applications Web et serveurs reçoivent et traitent des demandes en dehors du réseau interne protégé d’une entreprise. Par conséquent, ils sont vulnérables à diverses menaces malveillantes regroupées par OWASP, y compris les injections SQL, les XSS et les attaques par déni de service distribué (DDoS) au niveau de la couche application.
Compte tenu de l’augmentation des attaques XSS détectées par le WAF de Verizon, il n’est pas surprenant que XSS soit également en tête de liste pour MITRE CWE Top 25 pour 2020 :⁴
Figure 2. Une brève liste des faiblesses dans le Top 25 2020 de l’ECF, y compris la note globale de chacun.
Tout comme nous avons vu une augmentation du trafic XSS bloqué, le nombre de vulnérabilités réelles documentées dans la base de données nationale des vulnérabilités (NVD) qui sont également connectées à des exploits XSS est également le suivant :
- 513 vulnérabilités XSS documentées au cours des trois derniers mois (171 par mois)
- 5,507 vulnérabilités XSS documentées au cours des trois dernières années (153 par mois)
- 16,936 vulnérabilités XSS documentées à tout moment
Oui, les défenseurs utilisent les mêmes outils que les attaquants pour rechercher des vulnérabilités. Par conséquent, il est important de reconnaître le potentiel que l’existence d’un trafic d’apparence malveillante ne signifie pas nécessairement qu’il y a une mauvaise intention derrière le trafic. Mais il pourrait y en avoir.
Au minimum, si un mauvais acteur curieux scanne avec succès un système, il pourrait tenter un exploit XSS – tout cela dans l’esprit de la reconnaissance. Pire encore, l’activité de reconstruction et les résultats obtenus pourraient être utilisés pour supprimer une charge utile compromettante ou destructrice via XSS ou servir de tremplin vers quelque chose de plus néfaste, comme une falsification de requête côté serveur (SSRF).
Is qu’est-ce qu’un « excellent tremplin », je vois ?
Remember le scénario de poignée de porte que nous avons mentionné plus tôt? Il est temps de ramener cette métaphore.
La plupart des embouteillages et des événements XSS ne sont peut-être pas critiques pour eux-mêmes, mais ils peuvent entraîner des défis et des problèmes importants sur la route, un tremplin vers un compromis réussi, si vous voulez.
Des attaques XSS réussies pourraient permettre à des attaquants d’exécuter du HTML et du JavaScript arbitraires dans le navigateur d’une victime. En général, l’utilisateur doit interagir avec un lien malveillant pointant vers une page contrôlée par un attaquant, comme des sites Web ou des publicités en point d’eau.
Examinons la principale violation de règle pour le quatrième trimestre 2020, désignée en interne comme ID de règle 941100, qui correspondait à l’une des principales charges utiles, démontrant la capacité à utiliser XSS comme une attaque de tremplin:
“><Script >Alert(String.fromCharCode(88,83,83))</script>”
Il s’agit d’une chaîne de test XSS très courante dans de nombreux dépôts de code, tels que htmlpurifier.org.⁵. Tout en cherchant à valider si cette charge utile particulière fonctionnera, une boîte d’alerte contextuelle avec la chaîne « XSS » s’affiche, vérifiant immédiatement à l’attaquant qu’un site Web spécifique est vulnérable aux XSS reflétés.
Une fois qu’un attaquant vérifie l’existence d’un XSS réfléchi, les « attaques réfléchies sont livrées via une autre route, comme dans un message électronique ou un autre site Web. Lorsqu’un utilisateur est amené à cliquer sur un lien malveillant, à soumettre un formulaire spécialement conçu, ou même simplement à naviguer sur un site malveillant, le code injecté se dirige vers le site Web vulnérable, ce qui reflète l’attaque vers le navigateur de l’utilisateur. »⁶
Figure 3. Comment les cyberattaquants exploitent les vulnérabilités XSS.
Cette attaque peut effectuer tout ce que l’utilisateur attaqué peut effectuer sur le site Web, y compris la « divulgation du cookie de session de l’utilisateur, permettant à un attaquant de pirater la session de l’utilisateur et de prendre le contrôle du compte ».⁷ par exemple, un script modifiant le mot de passe d’un utilisateur soumis pour le compte de l’utilisateur peut entraîner une prise de contrôle du compte.
Il y a d’autres exemples de tremplin sur lesquels s’appuyer. Dans un autre cas documenté publiquement, une attaque SSRF a été initialement lancée via un exploit XSS, et le chercheur en sécurité « a pu escalader de XSS à l’intérieur d’une image jusqu’à une lecture arbitraire de fichier local sur le serveur ».⁸
Tous les chercheurs (ni les cybercriminels) ne seront pas assez patients pour lier leur exploit XSS à quelque chose de plus significatif. Cependant, tenir un XSS pour des choses plus grandes et meilleures semble être une méthode courante pour certains chercheurs qui cherchent à marquer le gros prix dans leurs programmes de bugs Bounty.
Mitigation et defense
En l’absence de données, il est difficile de prendre une décision. Cependant, il devient plus facile d’identifier un chemin qui vous mène au résultat souhaité une fois que vous avez une visibilité dans une situation. Voici un ensemble de conseils et de ressources pour vous aider à atténuer le risque que le trafic XSS représente pour votre réseau et votre entreprise.
- Assurez-vous de connaître tous les périphériques connectés à Internet et que les systèmes hérités et de test sont envisagés pour être renforcés ou mis hors ligne. Ceci est particulièrement important à l’ère de l’infrastructure cloud, où les équipes de développement peuvent faire tourner les machines en quelques clics ou en soumettant un formulaire.
- Configurez et renforcez correctement les serveurs Web. Envisagez d’utiliser des outils comme Center for Internet Securities Benchmarks pour comprendre comment configurer les contrôles de votre serveur. Configurez correctement vos configurations TLS pour vous protéger contre les attaques MITM.
- Appliquez régulièrement des correctifs à tous les serveurs connectés à Internet. Parfois, les frameworks couramment utilisés sont vulnérables à XSS. En février 2021, la base de données ATT&CK de MITRE répertorie près de 17 000 vulnérabilités et faiblesses avec une certaine connexion à XSS.
- Vérifiez régulièrement l’efficacité de votre renforcement de la sécurité. Utilisez les mêmes outils DAST (Dynamic application Security Testing) que les attaquants, tels que OWASP ZAP ou des outils d’analyse de vulnérabilité similaires dans Kali Linux. Vous pouvez également utiliser un DAST ou un service de test de pénétration pour découvrir et analyser les serveurs vulnérables face à Internet.
- Activez un pare-feu d’application Web (WAF) pour bloquer les attaques courantes.
- Gardez le WAF à jour pour bloquer immédiatement toute vulnérabilité découverte, permettant à l’équipe chargée de l’application de déployer un correctif. Mettez à jour le WAF au fur et à mesure que de nouvelles règles sont disponibles pour vous protéger contre les vulnérabilités nouvellement découvertes.
- Activez la journalisation et inspectez ces journaux.
- Protégez vos sites Web et votre infrastructure réseau critique contre les attaques volumétriques à l’aide d’un service DNS faisant autorité hautement redondant et de services de protection DDoS et d’accélération Web hautement distribués, c’est-à-dire le CDN.
Commencez par votre data
Vous pouvez avoir vos applications finement réglées pour fournir du contenu et un ensemble robuste de contrôles de sécurité pour aider à atténuer les risques et peut-être même bloquer les attaques qui se produisent à l’intérieur. Pourtant, pourquoi laisser le trafic potentiellement dangereux entrer dans votre réseau en premier lieu? Pourquoi prendre le risque qu’une police soit manquée ou qu’un contrôle soit contourné ?
Les clients de Verizon Media Security disposent de deux fonctionnalités à portée de main pour les protéger contre les menaces :
- Nous voyons le trafic réseau potentiellement dangereux (ou du moins inutile) qui frappe votre site.
- Le WAF Verizon Media intégré peut être activé pour bloquer le trafic malveillant avant qu’il ne devienne automatiquement un problème.
Prenez une mesure importante pour améliorer la sécurité de vos applications Web, contactez-nous dès aujourd’hui pour en savoir plus.
Références
- Verizon, «2020 Data Breach investigations Report », Verizon.com/business.com, enterprise.verizon.com/resources/reports/dbir/. Page 7.
- Ibid., page 88.
- Ibid., page 23.
- CWE, «2020 CWE Top 25 Most Dangerous Software faiblesses », CWE.mitre.org, cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html.
- HTMLpurifier, «HTML purifier XSS Attacks Smoketest », HTMLpurifier.org, htmlpurifier.org/live/smoketests/xssAttacks.php.
- OWASP, «Cross site scripting (XSS) », owasp.org, owasp.org/www-community/attacks/xss/
- Ibid
- Buerhaus, Brett, “escalade de XSS dans le rendu d’image PhantomJS à SSRF/local-file read, buer.haus. 29 juin 2020.
