Nous y sommes ! La dernière étape avec la fin de notre aventure sur la méthodologie OWASP. Après avoir vu un grand nombre de points à contrôler - de la collecte d'information à l'exploitation d'injections - il ne nous reste plus qu'à voir les attaques possibles sur AJAX. Je finirai par un résumé très rapide sur la vision de la norme pour la partie "post-pentest".
Dixième épisode ! Hé oui, nous y voilà ! Il synthétise la section 4.11 de la norme. J'irai très vite car je ne suis pas un expert AJAX ;) Mais il me fallait être exhaustif en abordant tous les chapitres de la méthodo. Pour finir, je décrirai brièvement la partie 5 de l'OWASP à propos du travail d'un pentester une fois les tests réalisés.
2 - Phase de tests actifs 9 - tests sur les applications AJAX
AJ-001 - Les vulnérabilités d'AJAX
Notre démarche consiste dans un premier temps à explorer les vulnérabilités potentielles sur les applications AJAX ou du moins, de contrôler qu'il n'y a pas de faille exploitable par un attaquant. Pour s'en assurer, nous devons couvrir un champ assez large de recherche car les applis AJAX sont concernées par de nombreux vecteurs d'attaque :
AJ-002 - Tests sur les applications AJAX
Il n'y a pas de méthode précise ici mais nous donnerons quelques pistes. La première est de travailler avec un proxy local (ex : paros). Comme pour tout type d'application WEB, ce genre d'outil nous permet souvent de trouver "ce qui cloche". Du moins, cela nous permet de mieux comprendre l'application.
La deuxième piste est de trouver les erreurs ou les lacunes dans le code JavaScript. Cette fois, nous pourrons utiliser une extension de Firefox comme Firebug. L'objectif est de trouver les failles dans le code qui nous permettront de réaliser des injections.
3 - Après les tests ...
La réalisation des tests constituent le coeur de la prestation d'un test d'intrusion d'une application WEB. Cependant, le résultat final, c'est le rapport.
3.1 - Étude des faille
Cependant, le résultat final, c'est le rapport. L'OWASP propose six étapes pour étudier une faille :
Étape 1 : Description et identification du risque pour la faille trouvée
Par exemple, atteinte à l'image de la compagnie, pertes financières, etc...
Étape 2 : Estimation de la probabilité
Est-il envisageable qu'une telle attaque se produise ? Si oui, dans quelle mesure ? Par exemple, s'il existe un gain financier à la clé, un attaquant sera plus motivé à attaquer la cible en question.
Deuxième cas : imaginons une attaque distante. Si la compagnie a bien sécurisé les accès extérieurs avec pare-feu correctement configuré et plateforme de protection WEB, l'attaque aura moins de chance de succès.
Étape 3 : Estimation de l'impact sur l'entreprise
Les risques identifiés doivent être évalué. Nous apportons un coefficient différent selon que une ou plusieurs personnes peuvent être touchées par l'exploitation de la faille étudiée. Les impacts financiers consistent-ils en une perte d'une journée de production ou d'une durée plus longue ?
Étape 4 : Estimation de la sévérité du risque.
Nous obtenons une criticité de "Faible" à "Critique".
Étape 5 : Recommandations
Il est temps ici d'apporter les solutions pour corriger les failles. Les recommandations devront tenir compte du contexte du client afin qu'elles puissent être réalisées.
Étape 6 : Personnalisation
L'idée est ici d'affiner l'étude en donnant un point de vue personnaliser pour le client : des solutions adaptées au secteur, aux besoins et à l'évolution de l'entreprise.
3.2 - Écriture du rapport
Nous découpons le rapport en trois points :
Conclusion / En résumé
Pour conclure sur les dix posts à propos de la méthodologie OWAP, je dirai qu'il s'agit pour moi de la seule norme éprouvée dédiée aux applications WEB. Elle a l'avantage de traiter tous les types de tests les plus communs (ex : injections) et les tests attraits aux nouvelles technologies WEB (ex : application AJAX). Ensuite, elle aborde tous ces sujets d'une manière très technique (partie 4 du document) mais aussi les parties environnantes pour proposer un test d'intrusion complet (contexte des tests, évaluation des résultats, écriture d'un rapport).
Bref, un fil conducteur très intéressant pour qui souhaite mener un test d'intrusion d'application WEB de manière rigoureuse.
2 - Phase de tests actifs 9 - tests sur les applications AJAX
AJ-001 - Les vulnérabilités d'AJAX
Notre démarche consiste dans un premier temps à explorer les vulnérabilités potentielles sur les applications AJAX ou du moins, de contrôler qu'il n'y a pas de faille exploitable par un attaquant. Pour s'en assurer, nous devons couvrir un champ assez large de recherche car les applis AJAX sont concernées par de nombreux vecteurs d'attaque :
- Les attaques de type injection (cf. épisode 7) : ex ; SQL / XSS /CSRF ;
- Les dénis de services (cf. épisode 8) ;
- Attaque côté client (navigateur). Surveiller les nouvelles failles ! (ex : www.securityfocus.com).
AJ-002 - Tests sur les applications AJAX
Il n'y a pas de méthode précise ici mais nous donnerons quelques pistes. La première est de travailler avec un proxy local (ex : paros). Comme pour tout type d'application WEB, ce genre d'outil nous permet souvent de trouver "ce qui cloche". Du moins, cela nous permet de mieux comprendre l'application.
La deuxième piste est de trouver les erreurs ou les lacunes dans le code JavaScript. Cette fois, nous pourrons utiliser une extension de Firefox comme Firebug. L'objectif est de trouver les failles dans le code qui nous permettront de réaliser des injections.
3 - Après les tests ...
La réalisation des tests constituent le coeur de la prestation d'un test d'intrusion d'une application WEB. Cependant, le résultat final, c'est le rapport.
3.1 - Étude des faille
Cependant, le résultat final, c'est le rapport. L'OWASP propose six étapes pour étudier une faille :
Étape 1 : Description et identification du risque pour la faille trouvée
Par exemple, atteinte à l'image de la compagnie, pertes financières, etc...
Étape 2 : Estimation de la probabilité
Est-il envisageable qu'une telle attaque se produise ? Si oui, dans quelle mesure ? Par exemple, s'il existe un gain financier à la clé, un attaquant sera plus motivé à attaquer la cible en question.
Deuxième cas : imaginons une attaque distante. Si la compagnie a bien sécurisé les accès extérieurs avec pare-feu correctement configuré et plateforme de protection WEB, l'attaque aura moins de chance de succès.
Étape 3 : Estimation de l'impact sur l'entreprise
Les risques identifiés doivent être évalué. Nous apportons un coefficient différent selon que une ou plusieurs personnes peuvent être touchées par l'exploitation de la faille étudiée. Les impacts financiers consistent-ils en une perte d'une journée de production ou d'une durée plus longue ?
Étape 4 : Estimation de la sévérité du risque.
sévérité risque = probabilité d'exploit (étape 2) * impact (étape 3)
Nous obtenons une criticité de "Faible" à "Critique".
Étape 5 : Recommandations
Il est temps ici d'apporter les solutions pour corriger les failles. Les recommandations devront tenir compte du contexte du client afin qu'elles puissent être réalisées.
Étape 6 : Personnalisation
L'idée est ici d'affiner l'étude en donnant un point de vue personnaliser pour le client : des solutions adaptées au secteur, aux besoins et à l'évolution de l'entreprise.
3.2 - Écriture du rapport
Nous découpons le rapport en trois points :
- une partie destinée aux managers (avec une synthèse des tests) ;
- une partie technique pour les équipes opérationnelles ;
- la réalisation des tests proprement dite en tenant compte du travail effectué en 3.1.
Conclusion / En résumé
Pour conclure sur les dix posts à propos de la méthodologie OWAP, je dirai qu'il s'agit pour moi de la seule norme éprouvée dédiée aux applications WEB. Elle a l'avantage de traiter tous les types de tests les plus communs (ex : injections) et les tests attraits aux nouvelles technologies WEB (ex : application AJAX). Ensuite, elle aborde tous ces sujets d'une manière très technique (partie 4 du document) mais aussi les parties environnantes pour proposer un test d'intrusion complet (contexte des tests, évaluation des résultats, écriture d'un rapport).
Bref, un fil conducteur très intéressant pour qui souhaite mener un test d'intrusion d'application WEB de manière rigoureuse.
Aucun commentaire:
Enregistrer un commentaire