Un scanner DAST contextuel que j’ai conçu et développé à l’université ITMO, associant cartographie de la surface d’attaque, tests sélectifs, déduplication des requêtes et vérification des vulnérabilités fondée sur les preuves.
Fig. 01
Hendra · DAST
Hendra : le scanner DAST que j’ai conçu et développé.
Dans le cadre de ma recherche doctorale achevée à l’université ITMO, j’ai développé l’architecture de Hendra, la planification des scans, la déduplication des requêtes, la vérification des vulnérabilités et le cadre d’évaluation. Le contexte applicatif détermine les contrôles que le scanner exécute.
Hendra face à Burp Suite Pro · DVWA, sécurité basse · exécution contrôlée
Burp Suite ProF1 0.929
40 131
HendraF1 0.966
686
58.5×Requêtes en moins
Résultats consignés dans les travaux de mon projet : DVWA en sécurité basse, avec les configurations d’outils testées. Le F1 combine précision et rappel. Ces chiffres décrivent cette expérience, pas un classement universel ni une garantie de performance en production.
Présentation
J’ai conçu et développé Hendra dans le cadre de mon projet de recherche doctorale, désormais achevé, à l’université ITMO. Le travail couvre l’architecture centrale du scanner, l’identification des technologies, la planification des scans, la déduplication et la mémoïsation des requêtes, l’arbitrage des vulnérabilités et le cadre d’évaluation DASTestBed.
Le DAST examine une application en cours d’exécution. Hendra passe par les interfaces qu’elle expose, sans lire le code source. Ma recherche porte sur la façon dont le contexte observé à travers ces interfaces peut orienter des tests utiles, réduire le trafic redondant et étayer les vulnérabilités par des preuves.
L’objectif d’ingénierie est un test sélectif et mesurable : construire un modèle utile de l’application, choisir les contrôles à partir de ce contexte, maîtriser l’envoi des requêtes et évaluer les preuves. Chaque composant répond à une limite précise de l’analyse automatisée.
Comment j’ai conçu le scanner
01
Cartographier l’application
Un crawler instrumenté construit un graphe de la surface d’attaque regroupant endpoints, paramètres, technologies observées et caractéristiques des réponses. Des contrôles passifs enrichissent ce modèle à partir des réponses déjà collectées.
02
Choisir les contrôles pertinents
L’identification des technologies et le graphe orientent la planification du scan, le choix des charges utiles et les modèles Nuclei pertinents. Le scanner combine ses propres sondes génériques avec des scénarios propres à chaque technologie.
03
Maîtriser chaque requête
Une couche d’envoi commune applique la déduplication par équivalence de caractéristiques et la mémoïsation à tous les modules du scanner. La réutilisation dépend du contexte de la requête et de contrôles de validité : des URL similaires ne suffisent donc pas à établir une équivalence.
04
Examiner les preuves
Les vulnérabilités candidates passent par une couche d’arbitrage fondée sur les preuves, assistée par un LLM, avant d’être signalées. La détection est évaluée par rapport à une vérité terrain explicite ; la couche de vérification elle-même doit aussi être évaluée.
Ce qu’a montré l’expérience contrôlée
Lors de l’exécution consignée sur DVWA en sécurité basse, Hendra a détecté 14 des 15 vulnérabilités de référence sans faux positif ; Burp Suite Pro en a détecté 13 sur 15, également sans faux positif. Hendra a manqué une XSS parce que son crawler n’a pas sollicité le paramètre concerné. Le volume de requêtes et le F1 rendent visibles à la fois le résultat de détection et le coût en trafic.
Hendra face à Burp Suite Pro · DVWA, sécurité basse · exécution contrôlée
Scanner
Requêtes envoyées
F1
Hendra
686
0,966
Burp Suite Pro
40 131
0,929
Résultats consignés dans les travaux de mon projet : DVWA en sécurité basse, avec les configurations d’outils testées. Le F1 combine précision et rappel. Ces chiffres décrivent cette expérience, pas un classement universel ni une garantie de performance en production.
Ce que ces résultats établissent
Cette exécution montre un ensemble de requêtes compact avec une détection solide sur la cible et la configuration choisies. Elle n’établit ni une supériorité universelle, ni un temps d’exécution plus court, ni une couverture complète, ni un résultat identique sur l’application d’un client. La vulnérabilité manquée montre aussi pourquoi la couverture du crawl doit faire partie de l’évaluation. Une nouvelle comparaison exige des cibles, des accès et des profils d’outils reproductibles explicites, ainsi qu’une vérité terrain lorsqu’elle existe.
La recherche qui fonde l’ingénierie
Ces publications traitent de volets précis de la recherche. La comparaison sur DVWA ci-dessus provient des travaux consignés de mon projet ; elle n’est pas présentée comme un résultat publié dans les trois articles.
Des caractéristiques comportementales, une supervision faible et un apprentissage automatique assisté par des règles permettent d’établir le contexte applicatif. L’étude publiée évalue 122 technologies sur 8 594 sites web.
Un modèle formel de l’équivalence des requêtes, de la réutilisation sûre, de l’envoi concurrent et des bornes de complexité fournit une base pour maîtriser le trafic redondant du scanner.
Des cibles conteneurisées, des fiches de vulnérabilités explicites et des résultats de scanners normalisés rendent vérifiables les conditions d’évaluation et le coût de la détection.
Ce que cela signifie pour votre projet
Si vous développez un produit de sécurité ou avez besoin d’un outil d’analyse sur mesure, nous pouvons cadrer une mission portant sur l’architecture, la logique de détection, des extensions de scanner ou l’évaluation. Hendra est un exemple concret de mon travail d’ingénierie DAST. Le développement SAST est une compétence distincte, dont le langage, l’approche d’analyse et les livrables sont fixés pour votre projet.
Vous livrez un produit qui traite des données d’utilisateurs ?
Envoyez-moi un bref descriptif. Je réponds sous trois jours avec des questions ou une première proposition, et le prix est fixé par écrit avant le démarrage.
