Résumé
L’analyse des requêtes et des réponses est essentielle lors d’un test d’intrusion visant une application Web. La capacité d’interception, de consultation et de modification de ces éléments est un prérequis indispensable dans l’évaluation de la sécurité d’une telle application par un auditeur, dans la mesure où ce dernier doit pouvoir librement injecter ou modifier des entrées utilisateurs et autres entêtes du protocole HTTP.L’outil Burp Suite [1], développé par la société PortSwigger, répond parfaitement à ces besoins dans la plupart des situations. Il montre néanmoins ses limites dans certains cas où la structure des messages échangés et du protocole applicatif utilisé n'est pas standard, par exemple dans un cas où pour chaque requête, un entête HTTP personnalisé ou un paramètre spécifique (token CSRF, hash, etc.) doit être ajouté pour que la requête soit acceptée. Face à ces situations, l’auditeur va généralement tenter de contourner ces limitations en développant tant bien que mal un script qui sera plus ou moins fonctionnel, qui ne sera généralement pas réutilisable par d’autres et surtout, qui ne sera pas intégré à « l’outil-qui-va-bien » utilisé en temps normal… Afin de répondre à cette problématique, un mécanisme « d’extension » a été introduit au sein de Burp pour étendre ses fonctionnalités de manière programmatique via une API. À travers cet article, nous vous proposons une introduction pragmatique au développement d’extensions Burp en nous appuyant sur deux cas d’usages détaillés, afin de pouvoir rapidement intégrer les éventuelles spécificités protocolaires que vous pourriez rencontrer dans un test d’intrusion.
