I. Introduction aux applications web

---

I.1 Les concepts

I.1.1 Définition

Les applications Web fournissent une interface entre les utilisateurs finaux et les serveurs Web via un ensemble de pages Web générées côté serveur ou contenant du code de script à exécuter de manière dynamique dans le navigateur Web du client.

Bien que les applications Web appliquent certaines politiques de sécurité, elles sont vulnérables à diverses attaques telles que l’injection SQL, les scripts intersites, le détournement de session, XSS, CSRF, au détournement de session, etc.

Cependant, les technologies Web aident au développement des affaires, mais elles offrent une plus grande surface par l’exploitation des applications Web pour faire des attaques.

I.1.2 Application web 2.0

Le Web 2.0 fait référence à une génération d’applications Web qui fournissent une infrastructure pour une participation des utilisateurs, une interaction sociale et une collaboration plus dynamiques.

Il offre diverses fonctionnalités telles que:

• Interopérabilité: Blogs (WP), Jeux avancés, Syndication générée par RSS, etc.
• Collaboration sur le Web: Facilité de manipulation des données, logiciel de bureau en ligne, sites Web de cloud Computing  (amazon), encyclopédies interactives.
• Conception centrée sur l’utilisateur: Réseaux sociaux, Mash-ups, Wikis, services gratuits basés sur Googel (MAPS)
• Partage de données interactif: Framework, Applications mobiles, Nouvelles technologies (Gmail, Youtube), sites Web à interface riche en Flash.

I.2 Le projet ouvert de sécurité des application web (OWASP)

L’OWASP (Open Web Application Security Project) est une communauté ouverte dédiée qui permet d’établir des projets  pour les organisations afin de développer, acheter et maintenir des applications et des API fiables c’est-à-dire sécurisées.

Le Top 10 de l’OWASP  spécifie les plus grandes menaces pesant sur les sites Web, il s’agit de :

A1) INJECTION

A2) AUTHENTIFICATION CASSÉE

A3) EXPOSITION DE DONNÉES SENSIBLES

A4) ENTITÉ EXTERNE XML

A5) CONTRÔLE D’ACCÈS ROMPUE

A6) CONFIGURATION INCORRECTE DE LA SÉCURITÉ

A7) SCRIPTS INTER-SITES (XSS)

A8) DESERIALISATION NON SÉCURISÉE

A9) UTILISATION DE COMPOSANTS AVEC DES VULNÉRABILITÉS CONNUES.

A10) JOURNALISATION ET SURVEILLANCE INSUFFISANTES

A1) INJECTION

Une injection de code se produit lorsqu’un attaquant envoie des données invalides ou des requêtes malveillantes à l’application Web avec l’intention de lui faire faire quelque chose pour lequel l’application n’a pas été conçue ou programmée entraînant une exposition de données sensibles en raison d’une vulnérabilité non corrigée.

Les défauts d’injection sont répandus dans le code hérité, selon la requête utilisée, on parle de :

• INJECTION SQL
• INJECTION DE COMMANDE
• INJECTION LDAP

**********Attaque par injection SQL**********

L’injection SQL utilise une série de requêtes SQL malveillantes pour manipuler directement la base de données.

L’attaquant utilise une application Web vulnérable pour contourner les mesures de sécurité normales et obtenir des données précieuses.

Les attaques par injection SQL peuvent souvent être exécutées à partir de la barre d’adresse, à partir des champs d’application et via des requêtes et des recherches.

**********Attaque par injection SHELL**********

• Injection Shell : l’attaquant tente de créer une chaîne d’entrée pour obtenir un accès Shell à un serveur Web.
• Intégration de balises HTML: l’attaquant ajoute un contenu HTML supplémentaire pour dégrader l’application Web vulnérable
• Injection de fichiers: l’attaquant exploite la vulnérabilité et injecte du code malveillant dans les fichiers système.

**********Exemple d’injection de commande**********

L’attaquant ajoute un code malveillant avec un nouveau mot de passe en utilisant une petite commande.

Le script serveur suppose que seule l’URL du fichier image de la bannière est insérée.

**********Attaque d’injection de fichier**********

L’attaquant injecte un fichier hébergé à distance sur www.jasoneval.com contenant un exploit.

Les attaques par injection de fichiers permettent aux attaquants d’exploiter des scripts vulnérables sur le serveur afin qu’il utilise un fichier distant au lieu d’un fichier vraisemblablement approuvé du système de fichiers local.

**********Attaque d’injection ldap**********

Les injections LDAP sont similaires aux attaques par injection SQL mais exploitent les paramètres utilisateur pour générer une requête LDAP.

Les services d’annuaire LDAP stockent et organisent les informations en fonction de leurs attributs. Ils sont organisées hiérarchiquement sous forme d’arborescence d’entrées de répertoire.

LDAP est basé sur le modèle client-serveur, les clients peuvent rechercher les entrées de l’annuaire à l’aide de filtres.

L’injection LDAP permet d’obtenir un accès direct à la base de données derrière une arborescence LDAP en tirant parti des vulnérabilités d’entrée d’applications Web non validées pour passer les filtres LDAP utilisés pour la recherche des services d’annuaire.

Par exemple : certifiedhacker)(&)).

A2) AUTHENTIFICATION CASSÉE

Un attaquant utilise des vulnérabilités dans les fonctions d’authentification ou de gestion de session telles que les comptes exposés, les identifiants de session, la déconnexion, la gestion des mots de passe, les délais d’expiration, se souvenir de moi, la question secrète, la mise à jour du compte et d’autres pour se faire passer pour des utilisateurs. Prenons les 3 fonctions suivantes :

• ID de session dans les URL : L’attaquant renifle le trafic réseau ou trompe l’utilisateur pour obtenir les ID de session et les réutiliser à des fins malveillantes.
• Exploitation des mots de passe : l’attaquant accède à la base de données de mots de passe de l’application Web  et s’ils ne sont pas chiffrés, l’attaquant peut exploiter le mot de passe de chaque utilisateur.
• Exploitation du délai d’expiration : si les délais d’expiration d’une application ne sont pas définis correctement et qu’un utilisateur ferme simplement le navigateur sans se déconnecter des sites accessibles via un ordinateur public, l’attaquant peut utiliser le même navigateur plus tard et exploiter les privilèges de l’utilisateur.

Par exemple : http://www.certifiedhacker.com/sale/saleitems=304;jsessionid=139824719802kjkljsf024u0284?dest=NewMexico

A3) EXPOSITION DE DONNÉES SENSIBLES

L’exposition de données sensibles est l’une des vulnérabilités les plus répandues. Il s’agit de données compromettantes qui auraient dû être protégées (Identifiants, Numéros de carte de crédit, Information médicale, Informations personnelles identifiables, Autres informations personnelles).

De nombreuses applications ne protègent pas leurs données sensibles des utilisateurs non autorisés par la mise en place de moyens de stockage sécurisés.

L’application utilise parfois un code de cryptage mal écrit pour sécuriser ses données sensibles.

Voici quelques exemples de ce qui peut arriver lorsque des données sensibles sont exposées :

• Une application crypte les numéros de carte de crédit dans une base de données à l’aide du cryptage automatique de la base de données. Cependant, ces données sont automatiquement déchiffrées lors de leur récupération, ce qui permet à une faille d’injection SQL de récupérer les numéros de carte de crédit en texte clair.
• Un site n’utilise ni n’applique TLS pour toutes les pages ou prend en charge un cryptage faible. Un attaquant surveille le trafic réseau (par exemple sur un réseau sans fil non sécurisé), rétrograde les connexions de HTTPS vers HTTP, intercepte les requêtes et vole le cookie de session de l’utilisateur. L’attaquant rejoue alors ce cookie et détourne la session (authentifiée) de l’utilisateur, accédant ou modifiant les données privées de l’utilisateur. Au lieu de ce qui précède, ils pourraient modifier toutes les données transportées, par exemple le destinataire d’un transfert d’argent.
• La base de données de mots de passe utilise des hachages simples ou non salés pour stocker les mots de passe de tout le monde. Une faille de téléchargement de fichier permet à un attaquant de récupérer la base de données de mots de passe. Tous les hachages non salés peuvent être exposés avec une table arc-en-ciel de hachages pré-calculés. Les hachages générés par des fonctions de hachage simples ou rapides peuvent être craqués par les GPU, même s’ils ont été salés.

A4) ENTITÉ EXTERNE XML (XXE)

Une attaque d’entité externe XML est un type d’attaque contre une application qui analyse l’entrée XML. Cette attaque se produit lorsque l’entrée XML contenant une référence à une entité externe est traitée par un analyseur XML faiblement configuré. On parle d’attaque de falsification de demande côté serveur (SSRF)

L’analyseur XML mal configuré donne la possibilité à l’attaquant d’analyser l’entrée XML à partir d’une source non fiable.

Lorsque des entrées XML malveillantes sont traitées par un analyseur XML faiblement configuré, cela permet d’accéder à des fichiers et services protégés depuis des serveurs, réseaux connectés.

A5) CONTRÔLE D’ACCES CASSE

Le contrôle d’accès consiste à limiter les sections ou pages que les visiteurs peuvent atteindre, en fonction de leurs besoins.

L’attaquant identifie une faille liée au contrôle d’accès, l’utilise pour contourner l’authentification de certains utilisateurs privilégiés et restreint l’accès, au contenu de l’application Web, aux utilisateurs autorisés.

Il permet à l’attaquant d’agir en tant qu’utilisateur avec des privilèges d’administrateur pour manipuler chaque enregistrement.

Les attaquants peuvent exploiter les failles d’autorisation pour :

• Accéder à des fonctionnalités et / ou des données non autorisées
• Afficher les fichiers sensibles
• Modifier les droits d’accès

A6) MAUVAISE CONFIGURATION DE SÉCURITÉ

Une mauvaise configuration de sécurité est simplement définie comme l’échec de la mise en œuvre de tous les contrôles de sécurité pour un serveur ou une application Web, ou la mise en œuvre des contrôles de sécurité, mais avec des erreurs.

Cela peut se produire à n’importe quel niveau d’une pile d’applications, y compris la plate-forme, le serveur Web, le serveur d’applications, le framework et le code personnalisé.

Les attaquants peuvent obtenir des accès non autorisés aux comptes par défaut, lire des pages inutilisées, accéder à des fichiers non protégés.

Entrées non validées, manipulation des paramètres, mauvaise gestion des erreurs, protection de la couche de transport insuffisante.

Par exemple si un serveur d’applications est fourni avec des exemples d’applications qui ne sont pas supprimés du serveur de production. Ces exemples d’applications présentent des failles de sécurité connues que les attaquants utilisent pour compromettre le serveur. Si l’une de ces applications est la console d’administration et que les comptes par défaut n’ont pas été modifiés, l’attaquant se connecte avec les mots de passe par défaut et prend le relais.

A7) SCRIPTS INTERSITES (XSS)

Les scripts intersites, communément appelés XSS, exploitent les vulnérabilités des pages Web générées dynamiquement, ce qui permet à un attaquant malveillant d’injecter des scripts

Ces attaques XSS se produisent lorsque des pirates exécutent du JavaScript malveillant dans le navigateur d’une victime en le cachant avec des requêtes légitimes.

L’exécution du code permet de rediriger la victime vers des sites malveillants ou d’exploiter ses privilèges

Lors de l’injection initiale, le site n’est généralement pas entièrement contrôlé par l’attaquant. Au lieu de cela, il attache son code malveillant au-dessus du site Web légitime, incitant essentiellement le navigateur à exécuter son logiciel malveillant chaque fois que le site est chargé.

Nous avons 3 types de XSS :

• XSS réfléchi : l’application ou l’API inclut une entrée utilisateur non validée et sans échappement dans le cadre de la sortie HTML, ce qui permet à l’attaquant d’exécuter du HTML et du JavaScript arbitraires dans le navigateur de la victime. 
• XSS stocké : l’application ou l’API stocke les entrées utilisateur non contrôlées qui sont affichées ultérieurement par un autre utilisateur ou un administrateur. Le XSS stocké est souvent considéré comme un risque élevé ou critique.
• DOM XSS : les Framework JavaScript, les applications à page unique et les API, qui incluent dynamiquement des données contrôlables par l’attaquant dans une page, sont vulnérables à DOM XSS. Idéalement, l’application n’enverrait pas de données contrôlables par l’attaquant à des API JavaScript non sécurisées. Les attaques XSS typiques incluent le vol de session, la prise de contrôle de compte, le contournement MFA, le remplacement ou la dégradation du nœud DOM (comme les panneaux de connexion des chevaux de Troie), les attaques contre le navigateur de l’utilisateur tel que les téléchargements de logiciels malveillants, l’enregistrement de frappe et d’autres attaques côté client.

A8) DESERIALISATION NON SÉCURISÉE

La désérialisation non sécurisée est une vulnérabilité dans laquelle des données non fiables ou inconnues sont utilisées pour infliger une attaque par déni de service ( attaque DoS ), exécuter du code, contourner l’authentification ou encore abuser de la logique derrière une application.

La sérialisation est le processus qui convertit un objet dans un format qui peut être restauré ultérieurement.

La désérialisation est le processus opposé qui prend les données d’un fichier, d’un flux ou d’un réseau et les reconstruit en un objet.

 C’est le processus efficace pour le transporter vers un autre réseau ou système.

L’attaquant peut abuser du processus de désérialisation s’il n’est pas sécurisé, il injecte du code malveillant dans les données sérialisées pour le transmettre à la victime.

L’ordinateur de la victime initialiserait la désérialisation des données hostiles. L’attaquant peut alors modifier l’angle d’attaque, faisant de la désérialisation non sécurisée le point d’entrée initial de l’ordinateur de la victime, et compromettre le système ou le réseau.

A9) UTILISATION DE COMPOSANTS AVEC DES VULNERABILITES CONNUES

Les vulnérabilités connues sont des vulnérabilités qui ont été découvertes dans des composants open source et publiées dans des avis de sécurité ou des outils de suivi des problèmes. Dès la publication, une vulnérabilité peut être exploitée par des hackers.

Par exemple, L’utilisation de composants avec OS non mis à jour, correctifs, bibliothèques, Framework est une vulnérabilité

Cela conduira l’attaquant à provoquer de graves pertes de données ou à prendre le contrôle des serveurs.

A10) JOURNALISATION ET SURVEILLANCE INSUFFISANTES

L’application Web maintient des journaux, pour suivre l’utilisation des informations d’identification des utilisateurs.

Les attaquants utiliseront ces journaux pour se livrer à des activités malveillantes ou cacher leur identité.

Une surveillance de la journalisation insuffisante n’enregistre pas l’événement malveillant, la détection des tentatives est plus difficile, cela conduit à voler des informations.

A11) AUTRES MENACES

• DIRECTORY TRAVERSAL : Il permet à l’attaquant d’accéder aux répertoires restreints, au code source, à la configuration, aux fichiers système. Par exemple ./ ../dir/dir
• REDIRECTS ET FORWARDS NON VALIDÉS : les utilisateurs seront redirigés vers une page de l’application Web contenant des logiciels malveillants et seront incités à divulguer des informations sensibles.
• ATTAQUE DE TROU D’EAU : l’attaquant doit connaître le site Web que la victime visite souvent, puis exploiter une vulnérabilité du site et rediriger la victime sur un site malveillant, (comme un piège de lion attendant sa proie au point d’eau pour boire de l’eau).
• CROSS SITE REQUEST FORGERY (CSRF) : Il s’agit d’une attaque qui altère l’intégrité du site légitime visité à travers un utilisateur, en envoyant une requête http simultanément l’utilisateur visite un site malveillant et l’attaquant peut compromettre la victime.
• COOKIE / SESSION EMPOISONNEMENT : Les cookies sont utilisés pour maintenir l’état de la session. L’attaquant modifie le contenu du cookie avec un contenu malveillant pour obtenir des informations non autorisées. Un proxy peut être utilisé pour réécrire les données de session, en affichant les données du cookie, en spécifiant un nouvel ID utilisateur ou d’autres identifiants de session dans le cookie.
• ATTAQUE DES SERVICES WEB : Les protocoles XML sont chargés de décrire la connexion entre les ports des services Web, donc il offre de nouveaux vecteurs d’attaque.
• EMPREINTE DES SERVICES WEB : Les attaquants empruntent une application Web pour obtenir des informations UDDI telles que l’entité commerciale, le service commercial, le tModel.
• EMPOISONNEMENT XML DES SERVICES WEB : L’insertion de code malveillant dans les requêtes SOAP permet de modifier le nœud xml pour casser la logique d’exécution. Cela conduira TCP à ouvrir des connexions qui peuvent être exploité pour d’autres attaques de services Web. (DOS)
• ATTAQUE DE MANIPULATION DE CHAMP CACHÉ : L’utilisateur peut manipuler la demande qui est cachée dans le code HTML de la page pour modifier les demandes de publication au serveur.

II. Méthodologie de piratage d’application web

---

Il existe différents moyens, pour attaquer une application Web. Ils aideront à sélectionner les victimes et à identifier leurs vulnérabilités.  Par exemple : découverte de serveur, découverte de service, identification de serveur, découverte de contenu caché.

II.1 Découverte de serveurs

Cela permet d’avoir des informations sur l’emplacement des serveurs et nous assure qu’il est actif sur Internet ou non.

Pour cette découverte, on peut utiliser WhoisLookup, ou faire une interrogation DNS (dnsstuff.com), ou une analyse de port (Nmap).

II.2 Découverte de services

Il s’agit de rechercher des ports communs dans un serveur Web pour vérifier les différents services.

Ces outils suivants peuvent être utilisés : nmap, netscan tools pro, navigateur Sandcat.

Les services identifiés servent de chemins d’attaque pour les pirates d’applications Web.

II.3 Identification de serveur / Saisie de bannière (Banner Grabbing)

L’attaquant analyse le champ d’en-tête des réponses du serveur pour identifier la marque, le modèle, la version

SYNTAXE :    telnet <URL du site> ou <@IP>  80

                          s_client -host <site Web cible> -port 443

                          GET/HTTP/1.0 pour obtenir des informations sur le serveur

II.4 Détection de proxy et pare-feu d’application web

II.4.1 Proxy

Le serveur proxy ajoute généralement certains en-têtes dans le champ d’en-tête de réponse.

Pour détecter les Proxy existants, on peut utiliser ‘TRACE’ qui est une des méthodes courantes pour HTTP / 1.1.

La méthode HTTP TRACE est utilisée pour invoquer un bouclage distant, des messages le long du chemin vers la ressource cible, au niveau de la couche application du message de demande.

TRACE permet à l’attaquant de voir ce qui est reçu à l’autre extrémité de la chaîne de demande et d’utiliser ces données pour des tests ou des diagnostics afin d’obtenir des informations des Proxy.

Syntaxe d’utilisation : TRACE /index.html.

II.4.2 Pare-feu d’application web (WAF)

WAF est un service de pare-feu d’application web qui vous permet de surveiller les demandes HTTP et HTTPS, de contrôler l’accès à votre contenu afin de fournir une protection contre les attaques visant à exploiter une vulnérabilité de votre site web.

Il permet aussi de vérifier la réponse des cookies à votre demande.

Pour détecter le WAF, l’attaquant peut utiliser des outils comme ‘WAFW00F’

WAFW00F est un outil détection de pare-feu applicatif web (ou WAF, Web Application Firewall). Son rôle est d’aider à identifier la présence d’un pare-feu, mais aussi sa technologie.

L’utilisation de wafw00f est tout aussi simple, si je souhaite repérer la présence d’un WAF sur wikipedia.org :   ‘ wafw00f   https://wikipedia.org’.

II.5 Découverte de contenus cachés

Il s’agit ici de découvrir des contenus cachés et des fonctionnalités qui ne sont pas visibles afin d’exploiter les privilèges de l’utilisateur sur l’application Web.

Cela permet aux hackers de récupérer des copies de sauvegarde de fichiers en direct, des fichiers de configuration, des fichiers journaux contenant des données sensibles, etc.

Les méthodes suivantes peuvent être utilisées :

• le robot d’indexation (en anglais web crawler ou web spider, littéralement araignée du Web) est un logiciel qui explore automatiquement le Web et permet de découvrir automatiquement le contenu et les fonctionnalités cachés en analysant le HTML des requêtes et réponses JavaScript côté client.
• Attacker Directed Spidering (Araignée dirigée par l’attaquant) : L’attaquant accède à toutes les fonctionnalités de l’application et utilise un proxy d’interception pour surveiller toutes les demandes et réponses. Le proxy d’interception analyse toutes les réponses de l’application et signale le contenu et les fonctionnalités qu’il découvre.
• Attaque par Force brute : il s’agit d’utiliser des outils d’automatisation tels que Burp Suite pour faire un grand nombre de requêtes au serveur Web afin de deviner les noms ou les identifiants du contenu et des fonctionnalités cachés.

II.6 Exploration web à l’aide de MOZENDA Web Agent Builder

Mozenda Web Agent Builder explore un site Web et récolte des pages d’informations.

Le logiciel prend en charge les connexions, l’index des résultats, AJAX, les bordures et autres.

Les données extraites peuvent être consultées en ligne, exportées et utilisées via une API.

II.7 Analyse des applications web

Cela consiste à analyser les fonctionnalités et technologies de l’application active afin d’identifier les surfaces d’attaque qu’elle expose.

• Identifier les points d’entrée pour l’entrée utilisateur :
  • Examinez l’URL, l’en-tête HTTP, les paramètres de chaîne de requête, les données POST et les cookies pour déterminer tous les champs de saisie utilisateur.
  • Identifiez les paramètres d’en-tête HTTP qui peuvent être traités par l’application en tant qu’entrées utilisateur telles que les en- têtes User-Agent, Referer, Accept, Accept-Language et Host.
  • Déterminez les techniques de codage d’URL et les autres mesures de cryptage mises en œuvre pour sécuriser le trafic Web telles que SSL.
  • Outils utilisés : Suite Burp, HttPrint, WebScarab, Proxy d’attaque Zed OWASP

• Identifier les fonctionnalités côté serveur :
  • Examiner la source de la page et les URL et faire une estimation pour déterminer la structure interne et les fonctionnalités des applications Web.

• Identifier les technologies côté serveur :
  • Effectuer une empreinte digitale détaillée du serveur, analyser les en-têtes http et le code source HTML pour identifier les technologies côté serveur.
  • Examiner les URL pour les extensions de fichier et d’autres informations d’identification.
  • Examiner les messages de la page d’erreur
  • Examiner les jetons de session.
  • « httprint »

• Cartographier la surface d’attaque : identifiez les différentes surfaces d’attaque découvertes par les applications et les vulnérabilités associées à chacune. Le tableau suivant illustre cela :

II.10 Schémas d’autorisation d’attaque

Les attaquants accèdent d’abord à l’application Web à l’aide d’un compte à faibles privilèges, puis augmentent leurs privilèges pour accéder aux ressources protégées.

Ils manipulent les requêtes HTTP pour subvertir les schémas d’autorisation d’application en modifiant les champs d’entrée liés à l’ID utilisateur, au nom d’utilisateur, au groupe d’accès, au coût, aux noms de fichiers, aux identificateurs de fichiers, etc.

• Falsification de demande HTTP
  • L’attaquant falsifie la chaîne de requête si celle-ci est visible dans la barre d’adresse du navigateur, ainsi il peut facilement modifier le paramètre de chaîne pour contourner les mécanismes d’autorisation.
  • Les attaquants peuvent aussi utiliser des outils de détection Web tels que Burp Suite pour analyser l’application Web à la recherche de paramètres POST.
  • Si l’application utilise l’en-tête ‘Referer’ (vrai ou faux), pour prendre des décisions de contrôle d’accès, les attaquants peuvent le modifier pour accéder aux fonctionnalités d’application protégées.

• Altération des paramètres de cookie
  • D’abord, l’attaquant collecte certains cookies définis par l’application Web et les analyse pour déterminer le mécanisme de génération de cookies.
  • L’attaquant piège alors les cookies définis par l’application Web, falsifie ses paramètres à l’aide d’outils, tels que OWASP Zed Attack Proxy, et rejoue sur l’application.

• Attaque du contrôle d’accès
  • L’attaquant analyse le Site Web pas à pas pour identifier l’accès individuel à un sous-ensemble de sites de données.
  • Il essaie d’avoir les fonctionnalités ADmin pour configurer, surveiller et effectuer une escalade de privilèges.
  • Le contrôle d’accès est basé sur les paramètres, sur le référent et sur l’emplacement.

III. Mécanisme de gestion de session d’attaque

---

Les attaquants interrompent le mécanisme de gestion de session d’une application pour contourner les contrôles d’authentification et se faire passer pour des utilisateurs d’application privilégiés.

III.1 Mécanisme de génération de jeton de session

Lors du codage hexadécimal d’une chaîne ASCII, l’attaquant peut utiliser un encodage faible et prédire un autre jeton de session en changeant simplement la date et en l’utilisant pour une autre transaction avec le serveur.

Les attaquants obtiennent un jeton de session valide en reniflant le trafic ou en se connectant légitimement à l’application et en l’analysant pour l’encodage (codage hexadécimal, Base64) ou tout autre modèle. Ensuite ils tentent de deviner les jetons récemment émis à d’autres utilisateurs de l’application et effectuent ensuite un grand nombre de requêtes pour déterminer un jeton de session valide.

III.2 Reniflement de jeton

Les cookies de jeton de session: Les attaquants reniflent le trafic de l’application à l’aide d’un outil de reniflage tel que Wireshark ou d’un proxy d’interception tel que Burp.

Si les cookies HTTP sont utilisés comme mécanisme de transmission pour les jetons de session et que l’indicateur sécurisé n’est pas défini, les attaquants peuvent rejouer le cookie pour obtenir un accès non autorisé à l’application.

III.3 Attaque par Injection / Validation d’netrées

Dans les attaques par injection, les attaquants fournissent une entrée malveillante spécialement conçue qui est syntaxiquement correcte en fonction du langage interprété utilisé afin de briser la normale prévue de l’application.

Parmi ces attaques, on a : Buffer Overflow, Injection de scripts Web, Injection SQL, Injection de commandes du système d’exploitation, XPath Injection, XPath Injection, etc.

**DÉMO SUR LES FAILLES LOGIQUES DES ATTAQUES D’APPLICATION WEB**

III.4 Attaque par Connexion à la base de données

Les chaînes de connexion à la base de données sont utilisées pour connecter les applications aux moteurs de base de données.

Exemple de chaîne de connexion courante utilisée pour se connecter à une base de données Microsoft SQL Server :  » Data Source=Server, Port; Network Library=DBMSSOCN; Initial Catalog=DataBase; User ID=Username; Password=pwd; « 

Les attaques par connectivité à la base de données exploitent la façon dont les applications se connectent à la base de données au lieu d’abuser des requêtes de base de données.

III.5 Attaque par connectivité aux données

• Injection de chaîne de connexion : environnement d’authentification déléguée dans lequel les attaquants injectent des paramètres dans une chaîne de connexion en les ajoutant avec le point-virgule. Cela peut se produire lorsque la concaténation de chaînes dynamique est utilisée pour créer des chaînes de connexion en fonction de l’entrée utilisateur.
• Attaques de pollution des paramètres de chaîne de connexion (CSPP, Connection String Parameter Pollution) : les attaquants écrasent les valeurs des paramètres dans la chaîne de connexion.
• Connection Pool DoS : les attaquants examinent les paramètres de pooling de connexions de l’application cible, construisent une grande requête SQL malveillante et exécutent plusieurs requêtes simultanément pour consommer toutes les connexions dans le pool de connexions, provoquant à leur tour l’échec des requêtes de base de données pour les utilisateurs légitimes.

III.6 Injection de cordes de connexion

Injecter des paramètres dans une chaîne de connexion en l’ajoutant avec.

Lorsque la chaîne de connexion est remplie, le cryptage sera ajouté à l’ensemble de paramètres précédemment configuré.

Par exemple : « Data source = Server, port; UserID=Username, Password=pwd; Encryption=off« 

III.7 Injection de chaines de connexion

Dans un environnement d’authentification déléguée, l’attaquant injecte des paramètres dans une chaîne de connexion en les ajoutant avec le caractère point-virgule (;).

Une attaque par injection de chaîne de connexion peut se produire lorsqu’une concaténation de chaîne dynamique est utilisée pour créer des chaînes de connexion en fonction de l’entrée utilisateur.

• Avant l’injection :

«  Data Source=Server, Port; Network Library=DBMSSOCN; Initial Catalog=DataBase; User ID=Username; Password=pwd; « 

• Après l’injection :

 » Data Source=Server, Port; Network Library=DBMSSOCN; Initial Catalog=DataBase; User ID=Username; Password=pwd; Encryption=off « 

Lorsque la chaîne de connexion est remplie, la valeur de chiffrement est ajoutée à l’ensemble de paramètres précédemment configuré.

III.8 Attaque par pollution des paramètres de chaîne de connexion (CSPP)

Dans les attaques CSPP, les attaquants écrasent les valeurs des paramètres dans la chaîne de connexion.

• Vol de hachage :

L’attaquant remplace la valeur du paramètre Source de données par celle d’un serveur Microsoft SQL Server non autorisé et connecté à Internet exécutant un renifleur.

Il reniflera ensuite les informations d’identification Windows (hachages de mot de passe) lorsque l’application tente de se connecter à un serveur Rogue avec les informations d’identification Windows sur lesquelles elle s’exécute.

• Balayage des ports : L’attaquant tente de se connecter à différents ports en modifiant la valeur et en voyant les messages d’erreur obtenus.

• Détournement d’informations d’identification Web : L’attaquant tente de se connecter à la base de données en le compte d’application Web au lieu d’un ensemble d’informations d’identification fourni par l’utilisateur.

III.9 Pool de connexion DoS

L’attaquant examine les paramètres de regroupement de connexions de l’application, construit une grande requête SQL malveillante et exécute plusieurs requêtes simultanément pour consommer toutes les connexions du pool de connexions, provoquant l’échec des requêtes de base de données pour les utilisateurs légitimes.

Exemple : par défaut dans ASP.NET, le nombre maximal de connexions autorisées dans le pool est de 100 et le délai d’expiration est de 30 secondes.

Ainsi, un attaquant peut exécuter 100 requêtes multiples avec plus de 30 secondes de temps d’exécution dans les 30 secondes pour provoquer une piscine de connexion DoS telle que personne d’autre ne serait en mesure d’utiliser les pièces liées à la base de données de l’application.

III.10 Attaque sur le client d’application web

Les attaquants interagissent avec les applications côté serveur de manière inattendue afin d’exécuter des actions malveillantes contre les utilisateurs finaux et d’accéder à des données non autorisées.

Les différentes attaques sur les clients d’application Web sont les suivantes :

• Cross-Site Scripting : un attaquant contourne le mécanisme de sécurité de l’ID client et obtient des privilèges d’accès, puis injecte des scripts malveillants dans les pages Web d’un site Web. Ces scripts malveillants peuvent même réécrire le contenu HTML du site Web.
• Injection d’en-tête HTTP : les attaquants divisent une réponse HTTP en plusieurs réponses en injectant une réponse malveillante dans un en-tête HTTP. Ce faisant, les attaquants peuvent endommager les sites Web, empoisonner le cache et déclencher des scripts intersites.
• Attaque de falsification de demande : dans une attaque de falsification de demande, les attaquants exploitent la confiance d’un site Web ou d’une application Web sur le navigateur d’un utilisateur. L’attaque fonctionne en incluant un lien sur une page, qui conduit l’utilisateur vers un site Web authentifié.
• Attaques de redirection : les attaquants développent des codes et des liens qui ressemblent à un site légitime qu’un utilisateur souhaite visiter; cependant, ce faisant, l’URL redirige l’utilisateur vers un site Web malveillant sur lequel les attaquants pourraient potentiellement obtenir les informations d’identification de l’utilisateur et d’autres informations sensibles.
• Fixation de session : la fixation de session aide les attaquants à détourner des sessions utilisateur valides. Ils s’authentifient à l’aide d’un ID de session connu, puis utilisent l’ID de session déjà connu pour détourner une session validée par l’utilisateur. Ainsi, les attaquants incitent les utilisateurs à accéder à un véritable serveur Web en utilisant une valeur d’identifiant de session existante.

IV. Attaque sur les services web

Les services Web fonctionnent au-dessus des applications Web héritées, et toute attaque sur un service Web exposera immédiatement les vulnérabilités métier et logique d’une application sous-jacente pour diverses attaques. Les différents types d’attaques utilisés pour attaquer les services Web sont :

• ATTAQUES DE DETECTION DES SERVICES WEB :

L’attaquant intercepte le document WSDL du trafic du service Web et l’analyse pour déterminer le but de l’application, la ventilation fonctionnelle, les points d’entrée et les types de messages.

Il crée ensuite un ensemble de requêtes valides en sélectionnant un ensemble d’opérations et en formulant les messages de requête selon les règles du schéma XML qui peuvent être soumis au service Web.

Puis il utilise ces requêtes pour inclure des contenus malveillants dans les requêtes SOAP et analyse les erreurs pour mieux comprendre les failles de sécurité potentielles.

• INJECTION SOAP :

L’attaquant injecte des chaînes de requête malveillantes dans le champ de saisie de l’utilisateur pour contourner les mécanismes d’authentification des services Web et accéder aux bases de données principales.

Cette attaque fonctionne de manière similaire aux attaques par injection SQL. 

• INJECTION XML :

Les attaquants injectent des données XML et des balises dans les champs d’entrée utilisateur pour manipuler le schéma XML ou remplir la base de données XML avec de fausses entrées.

L’injection XML peut être utilisée pour contourner l’autorisation, augmenter les privilèges et générer des attaques DoS sur les services Web.

• ATTAQUES D’ANALYSE DES SERVICES WEB :

Les attaques par analyse exploitent les vulnérabilités et les faiblesses des capacités de traitement de l’analyseur XML pour créer une attaque par déni de service ou générer des erreurs logiques dans le traitement des demandes de service Web.

Charges utiles récursives : créent des requêtes pour les services Web avec un document SOAP grammaticalement correct contenant des boucles de traitement infinies entraînant l’épuisement de l’analyseur XML et des ressources du processeur.

Charges utiles surdimensionnées : envoient une charge utile excessivement volumineuse pour consommer toutes les ressources système, rendant les services Web inaccessibles aux autres utilisateurs légitimes.

• TEST D’APPLICATION WEB FUZZ:

C’est une méthode de test de boîte noire, pour identifier les erreurs de codage et les trous de boucle de sécurité dans les applications Web.

Une énorme quantité de données aléatoires appelées FUZZ seront générées par les outils de test FUZZ et utilisées contre une application Web pour découvrir les vulnérabilités.

Les tests Fuzz sont employés pour tester la robustesse, l’immunité de l’application web contre BOF, DOS, XSS, injection SQL.

• EXAMEN DU CODE SOURCE: DÉTECTER LES BOGUES, LES IRRÉGULARITÉS.

• SCHÉMAS D’ENCODAGE :

Encodage d’url (% 3d,% 0a,% 20), Encodage html & amp; &, & lt; <, & gt; >

Encodage Unicode 16 bits, UTF-8, encodage base 64, encodage Hex.

• OUTILS D’ATTAQUE DE SERVICE WEB: SoapUI PRO, XMLSpy, etc.

• OUTILS DE HACKING POUR APPLICATIONS WEB: BURPSUITE, COOKIE DIGGER, WEBSCARAB

V. Défenses et contremesures

---

V.1 Défense contre les attaques d’injection

1. INJECTION SQL:
   • Limiter la longueur de la saisie utilisateur
   • Utiliser des messages d’erreur personnalisés
   • Surveiller le trafic de base de données à l’aide d’IDS, WAF
   • Désactivez les commandes telles que xp_cmdshell.

2. INJECTION DE COMMANDE:
   • Effectuer la validation d’entrée
   • Échapper à des personnages dangereux
   • Utilisez des bibliothèques spécifiques au langage pour éviter les commandes shell
   • Effectuer le codage d’entrée et de sortie
   • Utilisez une API sûre

3. INJECTION LDAP:
   • Validation de domaine sur toutes les données d’entrée
   • Rendre le filtre LDAP aussi spécifique que possible
   • Valider et limiter la quantité de données renvoyées
   • Mettre en œuvre un contrôle d’accès strict sur les données de l’annuaire LDAP.
   • Effectuer des tests dynamiques et une analyse du code source.

4. ATTAQUE D’INJECTION DE FICHIER:
   • Valider les entrées de l’utilisateur.
   • Désactivez allow_url_fopen et allow_url_include dans php.ini
   • Désactivez register_globals et utilisez E_STRICT pour trouver des variables non initialisées.
   • Assurez-vous que toutes les fonctions de flux (stream_ *) sont soigneusement vérifiées.

V.2 Contremesures pour les attaques d’applications web

1. AUTHENTIFICATION ET GESTION DE SESSION BRISÉES:
   • Utiliser SSL
   • Vérifiez si toutes les identités et informations d’identification des utilisateurs sont stockées sous une forme hachée.
   • Ne soumettez jamais de données de session dans le cadre d’un GET, POST.
2. EXPOSITION SENSIBLE AUX DONNÉES:
   • Ne pas créer ou utiliser un cryptage faible
   • Générer des clés de cryptage hors ligne et stocker en toute sécurité
   • Assurez-vous qu’il n’est pas facile à déchiffrer.
3. ENTITÉ EXTERNE XML:
   • Éviter de traiter l’entrée XML par un analyseur XML faiblement configuré.
   • XML unmarshaller doit être configuré en toute sécurité
   • Analyser le document avec un analyseur configuré en toute sécurité.
4. CONTRÔLE D’ACCÈS BRISÉ:
   • Effectuer des contrôles de contrôle d’accès
   • Éviter les identifiants non sécurisés pour éviter de deviner
   • Fournir un délai d’expiration de session
   • Limiter les autorisations de fichiers aux utilisateurs autorisés.
5. MAUVAISE CONFIGURATION DE SÉCURITÉ:
   • Désactiver tous les services inutilisés
   • Configurer les rôles, les autorisations, et les comptes et désactiver tous les comptes par défaut.
   • Rechercher les dernières vulnérabilités de sécurité.
   • Rediriger la demande vers les pages SSL.
   • Configurer SSL pour prendre en charge des algorithmes puissants.
   • Définir un drapeau sécurisé sur les cookies sensibles.
6. ATTAQUES XSS:
   • Valider tous les en-têtes, chaînes de requête, champs de formulaire et champs masqués.
   • Utiliser des outils de test pour rechercher des trous XSS.
   • Utiliser WAF
   • Convertir tous les caractères non alphanumériques en entités de caractères HTML avant d’afficher l’entrée utilisateur dans les moteurs de recherche et les forums.
   • Ne faites pas confiance aux sites avec HTTPS en ce qui concerne XSS
   • Déployer une infrastructure à clé publique (PKI) pour l’authentification des scripts.
7. DESERIALISATION INSÉCURISÉE:
   • Valider l’entrée non approuvée qui doit être des données sérialisées ne contient que des classes approuvées.
   • Les développeurs doivent réorganiser leurs applications.
   • Protéger les données sensibles lors de la sérialisation
   • Filtrer les données série non fiables.
8. UTILISATION DE COMPOSANTS AVEC DES VULNÉRABILITÉS CONNUES:
   • Vérifiez les versions des composants côté client et côté serveur et leurs dépendances.
   • Appliquer des correctifs
   • Moniteur pour CVE
   • Appliquer les politiques de sécurité
9. TRAVERSEE D’ANNUAIRE :
   • Définir les droits d’accès aux zones protégées du site:
   • Appliquez des vérifications / correctifs qui empêchent l’exploitation de la vulnérabilité comme Unicode d’affecter la traversée du répertoire.
   • Les serveurs Web doivent être mis à jour avec des correctifs de sécurité en temps opportun.
10. REDIRECTIONS ET TRANSFERTS NON VALIDES :
    • Évitez d’utiliser des redirections et des transferts.
    • Si les paramètres de destination ne peuvent être évités, assurez-vous que la valeur fournie est valide et autorisée pour l’utilisateur.
11. ATTAQUE DE WATERHOLE:
    • appliquez régulièrement des correctifs,
    • surveillez le trafic réseau,
    • analysez le comportement des utilisateurs,
    • inspectez les sites populaires.
12. CSRF (CROSS SITE REQUEST FORGERY) :
    • déconnectez-vous immédiatement après avoir utilisé une application Web et effacez l’historique.
    • Ne jamais enregistrer les informations de connexion
    • Vérifiez l’en-tête du référent HTTP, ignorez les paramètres d’URL.
13. EMPOISONNEMENT DES COOKIES / SESSIONS :
    • Ne stockez pas de texte brut ou de mot de passe faiblement crypté dans un cookie.
    • Implémentez le délai d’expiration du cookie.
    • Les informations d’authentification du cookie doivent être associées à une adresse IP.
    • Rendre les fonctions de déconnexion disponibles.
14. ATTAQUE DES SERVICES WEB:
    • Configurer les autorisations de contrôle d’accès WSDL pour accorder ou refuser l’accès à tout type de messages SOAP basés sur WSDL.
    • Utiliser des informations d’authentification centrées sur le document qui utilisent SAML
    • Déployer des pare-feu compatibles avec les services Web et capables de filtrer au niveau SOAP et ISAPI
    • Configurer les pare-feu / systèmes IDS pour une anomalie des services Web et la détection de signature.
15. OUTILS DE TEST DE SÉCURITÉ DES APPLICATIONS WEB: ACUNETIX WVS, Outil de sécurité Web Watcher, NETSPARKET, NESSUS, VEGA, OWSAP ZAP.
16. Pare-feu d’application Web (WAF): dotDEFENDER, IBM SECURITY APPSCAN, RADWARE’S APPWALL, SERVERDEFENDER VP, BARRACUDA WAF.

VI. Test de pénétration sur une application web

Le test de pénétration d’application Web est utilisé pour identifier, analyser et signaler des vulnérabilités telles que la validation d’entrée, le dépassement de tampon, l’injection SQL, le contournement de l’authentification, l’exécution de code, etc.

Les étapes générales des tests de pénétration des applications Web sont répertoriées sont les suivantes :

ÉTAPE 1: – Définir l’objectif

ÉTAPE 2: – Collecte d’informations

ÉTAPE 3: – Test de gestion de la configuration

ÉTAPE 4: – Test d’authentification

ÉTAPE 5: – Test de gestion de session

ÉTAPE 6: – Test de déni d service

ÉTAPE 7: – Test de validation des données

ÉTAPE 8: – Test de logique métier

ÉTAPE 9: – Test d’autorisation

ÉTAPE 10: Test des services Web

ÉTAPE 11: -Test d’AJAX

ÉTAPE 12: -Documenter toutes les conclusions.

1. LA COLLECTE D’INFORMATIONS

• Récupérez et analysez le fichier robots.txt à l’aide d’outils tels que GNU Wget .
• Utilisez l’opérateur de recherche avancé « site: » puis cliquez sur « En cache » pour effectuer une reconnaissance des moteurs de recherche.

• Identifiez les points d’entrée des applications à l’aide d’outils tels que Webscarab, Burp proxy, OWASP ZAP, TamperID (pour Internet Explorer) ou Tamper Data (pour Firefox).

• Pour identifier les applications Web: recherchez les URL, effectuez une recherche de type répertoire (estimation intelligente) et effectuez une analyse de vulnérabilité à l’aide d’outils tels que Nmap (Scanner de port) et Nessus.

• Mettre en œuvre des techniques telles que les transferts de zone DNS, les requêtes DNS inverses, les recherches DNS sur le Web, l’interrogation des moteurs de recherche (googling).
• Analysez les codes d’erreur en demandant des pages invalides et utilisez d’autres méthodes de demande (POST / PUT / Autre) afin de collecter des informations confidentielles auprès du serveur.

• Examinez le code source à partir des pages accessibles du front-end de l’application.

• Testez les types de fichiers / extensions / répertoires reconnus en demandant des extensions de fichier courantes telles que .ASP, .HTM, .PHP, .EXE, et surveillez toute sortie inhabituelle ou codes d’erreur.

• Effectuez des empreintes TCP / ICMP et des services à l’aide d’outils de fingerpriting traditionnels tels que Nmap et Queso, ou l’outil plus récent d’empreintes digitales d’application Amap.

2. TEST DE GESTION DE LA CONFIGURATION:

• Identifiez les ports associés aux services encapsulés SSL / TLS à l’aide de Nmap et Nessus.

• Effectuez une analyse du réseau et analysez la bannière du serveur Web.

• Testez la gestion de la configuration de l’application à l’aide de scanners CGI et examinez le contenu du serveur Web, du serveur d’applications, des commentaires, de la configuration et des journaux.

• Utilisez des scanners de vulnérabilité, des outils de spidering et de mise en miroir, des requêtes de moteurs de recherche ou effectuez une inspection manuelle pour tester la gestion des extensions de fichiers.
• Passez en revue le code source, énumérez les pages d’application et les fonctionnalités.
• Effectuer l’énumération des répertoires et des fichiers, consulter la documentation du serveur et des applications, etc. pour tester les interfaces d’administration de l’infrastructure et des applications.

• Consultez la méthode HTTP OPTIONS à l’aide de Netcat ou Telnet.

3. TEST D’AUTHENTIFICATION:

• Tester le mot de passe vulnérable et les mots de passe de réinitialisation : pwd, faiblesse d’authentification
• Test de déconnexion et de gestion du cache du navigateur : Vulnérabilités d’authentification
• Test avec CAPTCHA : des vulnérabilités d’authentification
• Test d’authentification à plusieurs facteurs : Authentification à 2 facteurs
• Test des conditions de course : Conditions de course

4. TEST DE GESTION DE SESSION:

• Collectez un nombre suffisant d’échantillons de cookies, analysez l’algorithme de génération de cookies et forgez un cookie valide afin de lancer l’attaque.
• Testez les attributs des cookies en utilisant des proxys d’interception ou des plug-ins de navigateur d’interception de trafic
• Testez la fixation de session, faire une demande au site à tester et analysez les vulnérabilités
• Testez les variables de session exposées en inspectant le chiffrement et la réutilisation du jeton de session, les proxies et la mise en cache, GET & POST et les vulnérabilités de transport.
• Examinez les URL dans la zone restreinte pour tester CSRF.

5. TEST D’AUTORISATION:

• Testez le parcours de chemin en effectuant une énumération des vecteurs d’entrée et en analysant les fonctions de validation d’entrée présentes dans l’application Web.
• Testez la falsification des requêtes HTTP
• Testez la falsification des paramètres de cookie
• Testez la manipulation des rôles, l’augmentation de privilèges, etc .

6. TEST DE VALIDATION DES DONNÉES:

• Détectez et analysez les vecteurs d’entrée pour les vulnérabilités potentielles,
• Analysez le code HTML, testez Stored XSS,
• Effectuer une analyse du code source pour identifier les erreurs de codage JavaScript.
• Analysez les fichiers SWF
• Effectuez des tests d’injection SQL standard, des tests d’injection SQL Union Query, des tests d’injection SQL aveugle et des injections de procédures stockées à l’ aide d’outils tels que OWASP SQLiX, sqlninja, SqlDumper, SQLPower Injector, etc.
• Utilisez un essai et approche d’erreur par l’insertion de « (, |, &, * » afin de vérifier l’application des erreurs. Utilisez l’outil Softerra LDAP Browser.
• Découvrez les vulnérabilités d’un outil ORM et testez les applications Web qui utilisent ORM. Utilisez des outils tels que Hibernate ORM, Nhibernate et Ruby On Rails.
• Essayez d’insérer des métacaractères XML.
• Trouvez si le serveur Web prend en charge les directives SSI à l’aide d’outils tels que Web Proxy Burp Suite, OWASP ZAP, WebScarab, String search: grep.
• Injectez du code XPath et interférer avec le résultat de la requête.
• Identifiez les paramètres vulnérables. 
• Injectez du code (une URL malveillante) et effectuez une analyse du code source pour découvrir les vulnérabilités d’injection de code.
• Effectuez une analyse manuelle du code et créez des requêtes HTTP malveillantes.
• Effectuez une analyse de code manuelle et automatisée à l’aide d’outils tels que OllyDbg pour détecter les conditions de dépassement de la mémoire tampon.
• Téléchargez un fichier qui exploite un composant sur le poste de travail de l’utilisateur local
• Identifiez toutes les entrées contrôlées par l’utilisateur 

7. TEST DE DENI DE SERVICE:

• Test des attaques par joker SQL pour avoir des informations sur l’application web
• Test de verrouillage des comptes clients pour avoir des informations sur ceux-ci
• Test des POINTS
• Test d’allocation d’objets spécifiés par l’utilisateur afin de connaitre le nombre max d’objets que l’application peut gérer.
• Test de saisie utilisateur comme compteur de boucle pour identifier les erreurs logiques
• Écrire les données fournies par l’utilisateur pour risquer l’épuisement du disque local
• Test pour une bonne libération des ressources par les faux programmes
• Test pour stocker beaucoup de données dans la session pour avoir des erreurs de gestion de  session.

8. TEST DES SERVICES WEB:

• Rassembler les informations WS de UDDI, SOAP, UBR
• Tester les points d’entrée WSDL
• Test de structure XML automatisés
• Tester les informations de niveau de contenu XML sur les vulnérabilités SQL, BOF, CI.
• Test du paramètre HTTP GET / des vecteurs d’attaque REST HTTP GET / REST
• Tester les pièces jointes SOAP pour vérifier si le document XML présente une vulnérabilité de pièce jointe SOAP.
• Effectuer des tests de relecture.

9. TEST AJAX:

• Énumérez les points de terminaison d’appel AJAX pour les appels
• Observez les fichiers HTML et JavaScript pour trouver des URL d’exposition de surface d’application supplémentaire.
• Utilisez des proxys et des renifleurs pour observer le trafic généré par les pages visibles par l’utilisateur et le trafic asynchrone d’arrière-plan vers les points de terminaison AJAX afin de déterminer le format et la destination des demandes.

10. FRAMEWORK POUR TEST DE PENETRATION D’APPLICATION WEB:

• Metasploit,
• Browser Exploitation Framework (BeEF),  
• PowerSploit,
• WAFNINJA,
• NETSPARKER, etc.