inlinetoc

L'énumération de l'application et sa surface d'attaque est un précurseur clé avant tout test ne soit entrepris, car il permet au testeur d'identifier les domaines susceptibles de faiblesse. Cette section a pour but d'aider à identifier et cartographier les zones à l'intérieur de l'application qui devrait être étudiée une fois que l'énumération et la cartographie ont été achevés.

Avant d'entreprendre tout test, toujours obtenir une bonne compréhension de la demande et la façon dont l'utilisateur / navigateur communique avec elle. En vous promenant dans l'application, porter une attention particulière à toutes les demandes HTTP ( méthodes GET et POST), ainsi que tous les paramètres et champ de formulaire qui sont transmis à l'application. En outre, prêter attention lorsqu'une demandes GET est utilisée mais que la réponse est fournies sous la forme d'une requête POST pour passer des paramètres à la demande. Il est très fréquent que les demandes GET soient utilisés, mais lorsque des informations sensibles doivent être retournées, cela est souvent fait dans le corps d'une requête POST. Notez que pour voir les paramètres envoyés dans une requête POST, vous aurez besoin d'utiliser un outil tel qu'un proxy (par exemple, WebScarab OWASP) ou un plug-in du navigateur. Dans la requête POST, également une attention spéciale doit être portée sur tous les champs de formulaire cachés qui sont passés à l'application, car ceux-ci contiennent généralement des informations sensibles, telles que des informations d'état, la quantité d'articles, le prix des articles, que le développeur ne souhaite pas afficher ou modifier.

A ce stade de l'expérimentation il est très utile d'utiliser un proxy d'interception et un tableur. Le proxy conserve la trace de chaque requête et des réponses entre vous et l'application que vous parcourrez. De plus, à ce stade, le testeur doit capturer chaque demande et réponse de sorte qu'il puisse voir exactement chaque en-tête, paramètre, etc qui est transmis à l'application et ce qui est retourné. Cela peut être assez fastidieux par moments, surtout sur les grands sites interactifs (dans le genre d'une application bancaire). Cependant, l'expérience vous apprendra ce qu'il faut rechercher, et, par conséquent, cette phase peut être considérablement réduite. En vous promenant dans l'application, vous devrez prendre connaissance de tous les paramètres intéressants dans l'URL, des en-têtes ou le corps des requêtes / réponses, et les enregistrer dans votre feuille de calcul. La feuille de calcul doit inclure la page que vous avez demandé (il pourrait être bon d'ajouter également le numéro de la demande du mandataire, à titre de référence), les paramètres intéressants, le type de requête (POST / GET), si l'accès est authentifié / non authentifié, si SSL est utilisé, si elle fait partie d'un processus en plusieurs étapes, et toutes les autres notes pertinentes. Une fois que vous avez tous les domaines de l'application tracé, alors vous pouvez passer à la phase d'attaque afin de tester chacun des domaines que vous avez identifiés et prendre des notes pour ce qui a fonctionné et ce qui n'a pas fonctionné. Le reste de ce guide permettra d'identifier la façon de tester chacun de ces domaines d'intérêt, mais cette section doit être entreprise avant de commencer tout essai proprement dit.

Voici quelques points d'intérêts pour toutes les demandes et les réponses. Dans la section requêtes, se concentrer sur les méthodes GET et POST, tels qu'ils apparaissent dans la majorité des demandes. Notez que d'autres méthodes, telles que PUT et DELETE, peuvent être utilisées. Bien que souvent, ces demandes soient plus rares, car si on les laisse elles peuvent exposer à des vulnérabilités. Il y a une section spéciale dans ce guide dédié pour tester ces méthodes HTTP.

Identifier où les méthodes GET et POST sont utilisées.

Identifier tous les paramètres utilisés dans une requête POST (ils sont dans le corps de la requête). Dans la requête POST, accorder une attention particulière à tous les paramètres cachés. Quand un POST est envoyé tous les champs du formulaire (y compris les paramètres cachés) sont envoyés dans le corps du message HTTP de l'application. Ceux-ci ne sont généralement pas vu, sauf si vous utilisez un proxy ou afficher le code source HTML. En outre, sur la page suivante, vous verrez, ces données, mais l'affichage peut être différent en fonction de la valeur du (des) paramètre(s) caché(s).

Identifier tous les paramètres utilisés dans une requête GET (c'est à dire dans l'URL), en particulier la chaîne de requête (généralement après un ?).

Identifier tous les paramètres de la chaîne de requête. Ceux-ci sont généralement dans un format paire, comme foo = bar. A noter également que de nombreux paramètres peuvent être dans une chaîne de requête séparés par un &, ~,:, ou tout autre caractère spécial ou d'encodage spécial.

Une attention particulière doit être portée quand il s'agit d'identifier plusieurs paramètres dans une chaîne ou dans une requête POST car certains ou tous les paramètres identifiés seront nécessaires pour exécuter vos attaques. Vous devrez identifier tous les paramètres (même ceux codés ou chiffrés) et déterminer ceux qui sont traitées par l'application. Les sections ultérieures de ce guide permettront d'identifier la façon de tester ces paramètres. À ce stade, assurez-vous d'identifier chacun d'entre eux. Faites également attention à tout paramètres de type supplémentaires ou personnalisés qui ne sont généralement pas visibles (comme debug = False).

Identifier où de nouveaux cookies sont activés (Set-Cookie header), modifiés ou ajoutés. Identifier où il ya des redirections codes d'état HTTP 300, 400 (en particulier 403 Forbidden) et 500 (erreurs de serveur internes).

Relever également, où les en-têtes intéressantes sont utilisés. Par exemple, “Serveur: BIG-IP” indique que le site dispose d'un mécanisme d'équilibrage de charge. Ainsi, si un site pour savoir si un serveur particulier est est configuré correctement vous pourriez avoir à faire de multiples demandes pour accéder au serveur vulnérable, en fonction du type d'équilibrage de la charge utilisé.

Voici deux exemples sur la façon de vérifier les points d'entrée de l'application.

Ce exemple montre une requête GET qui serait d'acheter un article à partir d'une application d'achat en ligne.

GET https://x.x.x.x/shoppingApp/buyme.asp?CUSTOMERID=100&ITEM=z101a&PRICE=62.50&IP=x.x.x.x 
Host: x.x.x.x
Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIGZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy

Résultat attendu

Ici, on notera tous les paramètres de la requête comme CLCLEUNIK, ITEM PRICE, IP et le cookie (ce qui pourrait être simplement des paramètres codés ou utilisé pour l'état de session).

Cet exemple montre une requête POST qui permet de se connectez à une application.

POST https://x.x.x.x/KevinNotSoGoodApp/authenticate.asp?service=login
Host: x.x.x.x
Cookie: SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIHByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMTIzNA####
CustomCookie=00my00trusted00ip00is00x.x.x.x00

Corps du message POST:

user=admin&pass=pass123&debug=true&fromtrustIP=true

Résultat attendu

Dans cet exemple, on notera tous les paramètres y compris les les paramètres qui sont passés dans le corps du message et non dans l'URL. En outre, notez qu'il y a un cookie personnalisé qui est utilisé.

L'identification des points d'entrée d'une l'application dans cette méthodologie consisterait à ce que toutes les entrées aient déjà été identifiées. Ce serait les cas si :

Il existe des sources externes à partir de laquelle l'application reçoit des données et des processus (tels que les interruptions SNMP, messages syslog, SMTP, ou des messages SOAP à partir d'autres serveurs). Une réunion avec les développeurs d'applications permet d'identifier les fonctions qui acceptent ou attendent une entrée utilisateur et comment celles ci sont formatées. (par exemple, le développeur pourrait aider à comprendre comment formuler une requête SOAP telle que l'application l'accepter ou l'arborescence du service Web).