Sélectionner une page


Les attaques XSS enregistrées, également appelées attaques XSS persistantes, sont le type avec la plus longue portée et les dégâts potentiels les plus élevés.

Récemment, nous avons examiné de plus près l’un des articles du site Web Liste des 10 principales vulnérabilités OWASP – Scripting intersite (XSS). Dans ce post Nous avons couvert les bases des attaques XSS et fait un bref aperçu des différents types XSS. Aujourd’hui, nous allons poursuivre notre série sur XSS et approfondir l’un de ces types spécifiques d’attaques XSS – Stored XSS, également connu sous le nom de Persistent XSS.

Le XSS stocké peut être le type d’attaque XSS le plus dangereux en raison de la façon dont il est exécuté. Quel scénario cause le plus de dégâts globaux – a) Un méchant cible chaque personne qui visite un guichet automatique via un scanner de carte intégré à la machine, ou b) se faufile derrière une seule personne et la regarde entrer son code PIN. Le premier scénario aurait un impact plus large et plus grave puisque le dispositif de piratage (le scanner de cartes) est stocké dans le guichet automatique et que chaque personne accédée est donc potentiellement une victime.

Stored XSS fonctionne de la même manière. Le vecteur d’attaque est stocké en permanence sur le serveur du site (d’où le nom), et toute personne qui accède à la page est donc vulnérable aux effets du code malveillant qui s’y trouve. Les attaques XSS persistantes sont donc une menace importante car elles peuvent être très importantes et ne pas nécessiter de phase d’ingénierie sociale (comme c’est le cas avec les attaques XSS Reflected, que nous aborderons dans notre prochain épisode de cette série) pour attirer les utilisateurs vers effectuer une action spécifique telle que cliquer sur un lien.

Comment fonctionnent exactement les attaques XSS stockées? Quelles sont les conséquences d’une attaque réussie? À quoi ressemble un scénario d’attaque réel? Et surtout, comment pouvez-vous vous en protéger?

Sortons-le

Comment fonctionnent les attaques XSS enregistrées?

Des attaques de scripts intersites persistantes peuvent se produire lorsque des sites ou des applications Web autorisent les entrées de l’utilisateur mais ne parviennent pas à nettoyer ou à restreindre correctement le contenu. Cela permet à un code malveillant d’être entré en entrée, qui est ensuite stocké sur le serveur et montré aux visiteurs du site Web sans méfiance.

Par exemple, si un pirate informatique pouvait insérer un script malveillant lors de la publication d’un commentaire sur un blog populaire, toute personne lisant cet article de blog serait exposée au script malveillant. Le code de l’attaquant est traité à tort comme une entrée valide par le site en question et n’est donc pas correctement encodé.

Un exemple de champ de saisie de texte qui peut être vulnérable à une attaque XSS stockée.

Une fois le code malveillant persistant sur le site Web cible, il est exécuté chaque fois qu’un visiteur accède à la page. Le navigateur permet cela parce que la politique avec la même origine est contournée. Habituellement, le code est bloqué, mais dans ce cas, ce n’est pas parce qu’il semble provenir d’une page valide. Et pour aggraver les choses, la nature stockée du script signifie qu’il est ensuite mis à la disposition de chaque utilisateur qui déclenche l’exécution du script du côté vulnérable.

Les zones de saisie de texte sont l’endroit le plus courant pour l’injection, mais les endroits qui ne contiennent normalement pas de scripts (comme les balises d’image ou les attributs d’événement) sont également des cibles principales. Tout élément qui n’est pas soumis à la validation d’entrée, au codage ou au filtrage pourrait potentiellement être exploité par un attaquant.

Le XSS stocké est relativement facile à récupérer pour les pirates car une fois qu’ils ont trouvé un site vulnérable, tout ce qu’ils ont à faire est de coller leur code méchant et de s’asseoir jusqu’à ce que les victimes le visitent (les pirates font parfois la promotion active de leur création via des messages de spam ou des publications sur les réseaux sociaux. ). Trouver l’emplacement cible lui-même est la partie la plus difficile du processus. Les types de vulnérabilités nécessaires ne poussent pas exactement dans les arbres, et leur prévention est généralement une priorité absolue pour les administrateurs de site vulnérables.

Le processus de recherche d’une cible vulnérable se déroule généralement comme suit:

  1. Un attaquant trouve un site Web potentiellement vulnérable
  2. Ils le testent en essayant de sauvegarder un script sur le serveur et exploitent la vulnérabilité
  3. Vous accédez à la page qui livrerait le code malveillant
  4. Ils vérifient que le script est en cours d’exécution

Il s’agit principalement d’un processus manuel. Cependant, il existe des outils automatisés qui peuvent être utilisés pour insérer des scripts automatiquement et à distance.

Non seulement un attaquant doit trouver une vulnérabilité qui permet aux scripts d’être intégrés de manière permanente, mais il doit également trouver un site Web avec suffisamment de trafic pour que cela en vaille la peine.

Les principales cibles des attaques XSS stockées

Pratiquement tous les sites Web sur lesquels les utilisateurs peuvent partager du contenu sont une cible potentielle pour les attaques XSS persistantes. Pensez aux endroits dotés de zones de commentaires ou de zones de texte pour les entrées utilisateur, ainsi qu’aux sites Web où cette entrée est enregistrée et présentée aux autres utilisateurs. Les objectifs typiques sont:

  • tableau d’affichage
  • Réseaux sociaux
  • Commentez des sections de sites Web tels que des blogs ou des plateformes de partage de vidéos
  • Outils de collaboration
  • Systèmes CRM / ERP
  • Consoles de serveur de messagerie

Les attaques XSS enregistrées réussissent grâce à la confiance de l’utilisateur dans de vrais sites Web. Le site Web présente une vulnérabilité qui pourrait être exploitée via XSS.

Conséquences des attaques XSS enregistrées

L’impact des attaques XSS stockées est considérable et un attaquant peut utiliser cette technique pour atteindre divers objectifs. Le vol de cookies de session et de données sensibles fait partie des cibles les plus courantes. En volant des cookies de session, un hacker Effectuer un détournement de sessionCela leur permet de se faire passer pour des victimes sur le site Web et d’accéder potentiellement à toutes sortes d’informations privées.

Les attaques XSS persistantes peuvent également être utilisées pour modifier l’apparence et la convivialité d’un site Web, par ex. B. une sorte de graffiti numérique. Cela peut aller de changements subtils essayant de tromper l’utilisateur pour qu’il entreprenne une action, à la dégradation complète d’un site Web avec des déclarations politiques ou des images et des mots offensants.

Les attaquants pourraient utiliser des attaques XSS stockées pour rediriger les utilisateurs vers un autre site. Très probablement, ils ne vous enverront pas dans un endroit sympa ou ne vous enverront pas simplement de Rickroll (bien qu’ils le fassent) est arrivé avant). Au lieu de cela, vous serez dirigé vers un site hostile qui contient très probablement des logiciels malveillants, des scripts malveillants, des tentatives de phishing ou tout ce qui précède. Les fausses pages de connexion sont également un vecteur d’attaque courant et sont similaires à la version légitime, mais envoient vos informations de connexion directement à l’attaquant.

Un exemple d’une fausse invite de connexion Facebook.

Une autre possibilité est qu’un keylogger soit placé sur la machine d’une victime. Toutes les frappes sont envoyées à l’attaquant, qui peut contenir des extras tels que des informations de carte de crédit et des mots de passe.

Exemple XSS enregistré

Voyons maintenant comment une attaque stockée XSS fonctionne réellement dans le monde réel. Nous utiliserons un site Web de commerce électronique comme exemple – appelons-le Widgets de Wanda. Un élément commun sur les pages de produits est un endroit où les clients peuvent laisser un avis. Wanda a installé un plugin WordPress sur son site Web qui permet aux utilisateurs d’évaluer leurs produits sur une échelle de un à cinq et de laisser également un avis de texte si vous le souhaitez. Malheureusement, le plugin de Wanda contient une faille de sécurité qui permet à des tiers d’intégrer des balises HTML dans leur texte de révision.

Un attaquant en profite en attribuant la note suivante:

J’adore ce produit et c’est aussi une bonne affaire! «