samedi, août 30, 2008

Fukuyama n'a jamais été un homme révolté

Bien qu'il soit sympa de vérifier chaque jour combien le petit père Francis s'est lamentablement planté en jouant les prophètes, je vous rassure, je ne vais pas tenter de vous démontrer ici en quoi l'éternel retour hégélien peut s'appliquer au Pentest web2.0 ! 
Quant à la notion de révolte, il faut simplement faire un diff entre l'œuvre de Camus (le révolté) et celle de Sartre (le révolutionnaire) pour comprendre l'allusion, mais je ne vais pas  faire ici l'étalage de mes lettres (d'autres Pentesteurs se complaisent  à le faire  quotidiennement !) '];alert('Troll');//.
Les frameworks de Pentest ont révolutionné notre métier en nous délestant, entre autres, de l'énorme travail de veille-techno/adaptation-opcodes-frenchies que tout pentesteur digne de ce nom doit fournir. Bien qu'ayant trouvé un employeur qui reconnaisse enfin cette tâche en tant que "travail à part entière" (vive le code de pointage "Formation_Perso" !), je peux vous avouer, qu'en ce moment, je me fie énormément aux mises à jour de Metasploit pour tout ce qui touche au domaine Client-Serveur, afin de mieux me concentrer sur les appli' Web et en particulier le Web2.0. (Chacun son domaine de prédilection)
Les frameworks de Pentest pour appli Web sont apparemment à la mode parmis mes confrères. Pourtant, je suis resté fidèle à l'Open Source (ou est-ce ma parano/prudence habituelle ?) en m'appuyant sur le trio Burp/Wapiti/w3af plutôt que sur un framework comme Accunetix, Appscan ou Web Inspect.(oui, je sais, Burp n'est pas vraiment de l'Open Source...)
En fait, les frameworks propriétaires actuels sont très décevants lorsqu'il s'agit de réaliser un pentest d'une appli sous Ajax. Les meilleurs d'entre eux arrivent péniblement à passer en revue ("parser" dans le jargon) les objets Thick Clients (Applets Java, Controles ActiveX, ObjectsFlash...) et restent sans voix face à un appel XHR.
En raison de l'extrême transparence des techno Ajax (tout passe en clair), je ne pense pas qu'un parseur web2.0 très poussé soit actuellement indispensable. En effet, la reconnaissance d'une appli sous Ajax est tout à fait réalisable aujourd'hui à l'aide d'un furieux mélange d'interruptions sous Firebug et de scripts Greasemonkey et Chikenfoot. Avec la pratique, on arrive en quelques minutes à obtenir la liste de toutes les requêtes XHR et à extraire les fonctions intéressantes correspondantes.
En parlant de scripts Greasemonkey, je vous déconseille vivement le script WebPageFingerprint d'Aung Khant qui n'est rien d'autre qu'un cheval de Troie sur pattes ! Celui-ci rapatrie toutes les failles potentielles directement au site de yehg. L'étude de ce script est cependant très enrichissante, bien que les fonctions d'analyse restent inaccessibles sur le site de son auteur. ;-)
Pour revenir à l'idée d'un parser Ajax, un tel outil va devenir indispensable lorsque les techno' Ajax vont gagner en maturité et commencer à chiffrer/masquer toutes les XHR. En fait, un petit nombre de développeurs web2.0 semblent avoir déjà entammer ce travail d'obfuscation à l'aide des différents outils d'anonymisation de variables à leur disposition (à moins que je soit tombé sur des développeurs off-shore indiens qui protègent leur gagne-pain ??)
En dépit de l'apparente complexité d'Ajax, un tel parser n'est pas monstrueux à coder. Pour démarrer, on peut se baser sur le parser rudimentaire proposé par Sheeraj Shah : scanajax.rb et l'enrichir peu à peu au fil de ces découvertes. A savoir que cet outil ne fonctionne correctement qu'une fois toutes ces dépendances respectées : gem install rest-open-uri openuri-memcached urirequire jrexml rexml-expansion-fix
Cependant, dès que l'on rencontre des techniques d'obfuscation, il faut se raccrocher aux interruptions de Firebug et à une analyse approfondie sous WebDevelopper pour s'y retrouver. Je doute que les parser d'Acunetix ou de Web Inspect aient un quelconque avenir en la matière. Bref, il nous faut construire l'ollydbg du JavaScript/XHR. 
CQFD pour la digression hégélienne...