Test des scripts intersites

Le Cross-site Scripting (XSS) se produit chaque fois qu'une application prend des données non approuvées et les envoie au client (navigateur) sans validation. Cela permet aux attaquants d'exécuter des scripts malveillants dans le navigateur de la victime, ce qui peut entraîner le piratage des sessions utilisateur, la dégradation de sites Web ou la redirection de l'utilisateur vers des sites malveillants.

Comprenons les agents de menace, les vecteurs d'attaque, la faiblesse de la sécurité, l'impact technique et les impacts commerciaux de cette faille à l'aide d'un diagramme simple.

Types de XSS

  • Stored XSS - Le XSS stocké également connu sous le nom de XSS persistant se produit lorsque l'entrée de l'utilisateur est stockée sur le serveur cible, comme la base de données / le forum de message / le champ de commentaire, etc.

  • Reflected XSS - Le XSS reflété également connu sous le nom de XSS non persistant se produit lorsque l'entrée de l'utilisateur est immédiatement renvoyée par une application Web dans un message d'erreur / résultat de recherche ou l'entrée fournie par l'utilisateur dans le cadre de la demande et sans stocker en permanence les données fournies par l'utilisateur.

  • DOM Based XSS - DOM Based XSS est une forme de XSS lorsque la source des données est dans le DOM, le puits est également dans le DOM et le flux de données ne quitte jamais le navigateur.

Exemple

L'application utilise des données non fiables dans la construction sans validation. Les caractères spéciaux doivent être échappés.

http://www.webpage.org/task/Rule1?query=try

L'attaquant modifie le paramètre de requête dans son navigateur pour -

http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>

Mains allumées

Step 1- Connectez-vous à Webgoat et accédez à la section Cross-site scripting (XSS). Exécutons une attaque XSS (Stored Cross-site Scripting). Voici un aperçu du scénario.

Step 2- Selon le scénario, laissez-nous nous connecter en tant que Tom avec le mot de passe «tom» comme mentionné dans le scénario lui-même. Cliquez sur «afficher le profil» et passez en mode édition. Puisque Tom est l'attaquant, injectons un script Java dans ces zones d'édition.

<script> 
   alert("HACKED")
</script>

Step 3 - Dès que la mise à jour est terminée, tom reçoit une boîte d'alerte avec le message «piraté» qui signifie que l'application est vulnérable.

Step 4 - Maintenant, selon le scénario, nous devons nous connecter en tant que jerry (HR) et vérifier si jerry est affecté par le script injecté.

Step 5 - Après vous être connecté en tant que Jerry, sélectionnez «Tom» et cliquez sur «Voir le profil» comme indiqué ci-dessous.

Lors de la visualisation du profil de Tom à partir du compte de Jerry, il peut obtenir la même boîte de message.

Step 6 - Cette boîte de message n'est qu'un exemple, mais l'attaquant réel peut faire bien plus que simplement afficher une boîte de message.

Mécanismes préventifs

  • Les développeurs doivent s'assurer qu'ils échappent à toutes les données non approuvées en fonction du contexte HTML, tel que le corps, l'attribut, le JavaScript, le CSS ou l'URL dans lequel les données sont placées.

  • Pour les applications qui nécessitent des caractères spéciaux en entrée, des mécanismes de validation robustes doivent être en place avant de les accepter comme entrées valides.