akca

Scanner DAST orienté preuves en Go qui explore les applications web et les API, puis exécute des vérifications adaptatives de SQLi, XSS, RCE, SSRF et d'authentification avec des preuves rejouables.

AKCA est un scanner DAST (Dynamic Application Security Testing) open source, orienté preuves, écrit en Go. Il combine le crawling HTTP et assisté par navigateur, l'analyse JavaScript, les imports d'API, les tests actifs adaptatifs, l'inspection passive et les preuves rejouables dans un seul flux de travail en ligne de commande.

Pourquoi AKCA

De nombreux scanners explorent une application puis envoient un large ensemble de charges utiles à chaque endpoint découvert. Cette stratégie peut générer un trafic inutile, déclencher des systèmes défensifs et produire des signaux faibles nécessitant un tri manuel conséquent. AKCA adopte une approche plus contextuelle : il commence par apprendre à connaître la cible, modélise la surface d'attaque découverte, puis sélectionne les tests en fonction de la pile technologique, des paramètres, de l'état d'authentification, du comportement du WAF et des capacités de vérification disponibles.

AKCA est conçu pour :

• Découvrir les routes cachées, les endpoints chargés par JavaScript, les paramètres non documentés, les opérations d'API et les chemins soumis à contrôle d'accès avant les tests actifs.
• Identifier la technologie et le comportement du WAF, puis calibrer le rythme des requêtes et les transformations de charges utiles sûres en fonction de la cible observée.
• Répartir le travail entre les combinaisons d'endpoints, de méthodes, de paramètres et de modules au lieu d'appliquer aveuglément chaque charge utile partout.
• Mettre en pause et récupérer après une limitation de débit ou un blocage au niveau de l'hôte, dans les limites de scan et de temps configurées.
• Rejouer les signaux prometteurs avec des lignes de base, des contrôles négatifs, des vérifications d'état, des comparaisons d'identité ou des callbacks OAST avant de les promouvoir en vulnérabilités.
• Préserver le contexte de requête, de réponse, de charge utile, de confiance et de politique de preuve afin que les résultats puissent être investigués plutôt qu'acceptés sur parole.

L'objectif n'est pas d'épuiser ou de submerger la cible. Il s'agit de trouver de véritables faiblesses avec des requêtes délibérées et des preuves utiles.

AKCA ne prétend pas atteindre la parité de fonctionnalités ou de détection avec des plateformes commerciales matures telles qu'Acunetix, Invicti/Netsparker ou Burp Suite Professional. Ces produits sont développés par des équipes expérimentées sur de nombreuses années. AKCA est maintenu indépendamment par un seul développeur sur son temps personnel disponible, inspiré par des outils de sécurité établis et façonné par des idées originales et les retours de la communauté. La priorité actuelle est un scanner simple, utile et transparent. Une interface graphique est prévue lorsque le moteur sera suffisamment stable et fiable.

_{Session de scan AKCA v0.2.4 avec état du moteur en direct, télémétrie des ressources et vulnérabilités confirmées.}

Installation

Installation via Go

Nécessite Go 1.25 ou version ultérieure.```bash go install github.com/akha-security/akca/engine/cmd/akca@latest akca --version

Ajoutez cette ligne à votre configuration de shell pour la conserver entre les sessions.

Windows PowerShell```powershell $env:Path += ";$(go env GOPATH)\bin"

Sous Windows, renommez le fichier téléchargé en akca.exe et exécutez .\akca.exe --help dans PowerShell. Les exemples ci-dessous supposent que akca est disponible dans votre PATH.

Les vérifications via navigateur nécessitent Chrome, Chromium ou Edge.

Utilisation

N'utilisez AKCA que sur des systèmes que vous possédez ou pour lesquels vous disposez d'une autorisation de test. Remplacez l'URL d'exemple par votre cible autorisée.

Lancer un scan```bash

akca -u https://example.com

Choisir des vérifications spécifiques

Exécutez des vérifications d'injection SQL, XSS et d'injection côté serveur, y compris SSTI :```bash akca -u https://example.com -m sql,xss,rce

Les scans passifs envoient tout de même des requêtes pour la découverte et l'inspection.

Utiliser une session authentifiée

Fournissez un cookie de session :```bash akca -u https://example.com -c "session=YOUR_SESSION_COOKIE"

Certaines vérifications d'autorisation nécessitent des identités supplémentaires ou une configuration d'état au-delà d'une seule session.

Importer une définition d'API```bash

akca -u https://api.example.com --api-spec ./openapi.yaml -m api

Exécutez akca --help pour toutes les options disponibles.

Utilisez akca -h pour une aide quotidienne concise, ou akca --help pour la référence complète des options. Les cibles de scan doivent être fournies explicitement avec -u ou --url.

Profils de scan

Sélectionnez un profil avec -m, ou combinez-en plusieurs avec des virgules.

L'exécution dépend des points de terminaison découverts, de la configuration, des capacités de vérification disponibles et des limites de scan. Consultez FEATURES.md pour le guide complet des capacités.

Comment fonctionne AKCA

AKCA utilise un pipeline par étapes afin que les vérifications ultérieures puissent bénéficier des informations apprises précédemment :

1. Empreinte et calibration — identifier les technologies, le comportement du serveur, les signaux WAF, la posture TLS et le rythme sûr des requêtes.
2. Découvrir la surface d'attaque — combiner le crawling HTTP, une session de navigateur persistante, l'analyse JavaScript, les définitions d'API, le fuzzing de chemins, la découverte de paramètres et les observations de contournement 403.
3. Modéliser les candidats de test — regrouper les points de terminaison par méthode, type de contenu, paramètres, contexte d'authentification et classe de vulnérabilité probable.
4. Planifier des sondes adaptatives — prioriser les familles de payloads pertinentes, préserver le travail pour les points de terminaison ultérieurs et appliquer un encodage ou un rythme adapté à la cible lorsque un comportement défensif est observé.
5. Vérifier les signaux — comparer les lignes de base et les contrôles, rejouer les résultats prometteurs, inspecter les changements d'état ou d'identité et corréler les callbacks OAST lorsque nécessaire.
6. Produire des preuves — exporter les résultats avec des transactions HTTP de style Burp, les payloads, les classifications, la confiance, le statut de preuve et les conseils de reproduction.

La couverture est explicite. Une cible ignorée, échouée, limitée par le budget ou inachevée est enregistrée comme couverture incomplète ; elle n'est pas silencieusement traitée comme un résultat de sécurité propre.

Couverture des tests de sécurité

La liste suivante décrit les moteurs de découverte et les familles de tests de sécurité implémentés. Les vérifications individuelles ne s'exécutent que lorsque la surface découverte, le profil de scan, la configuration, la politique de sécurité et les prérequis de vérification les rendent applicables. Une capacité listée ne garantit pas que chaque variante d'une vulnérabilité sera détectée.

Portée et limites de scan

Définissez un budget total de requêtes et une durée maximale :```bash akca -u https://example.com --request-budget 5000 --time-budget 30m

AKCA répartit des budgets de modules bornés entre les modules, les URL et les paramètres. Les allocations inutilisées sont reportées sur les travaux ultérieurs. Un --request-budget positif est prioritaire sur --requests-per-target.

Par défaut, le scan du module n'a pas de quota de requêtes. Les interruptions de budget sont signalées comme couverture incomplète. Les cibles interrompues ne sont pas automatiquement reprises lorsque des travaux ultérieurs libèrent un budget inutilisé. Aucun réglage de budget ne garantit la détection de chaque vulnérabilité.

Les sous-domaines d'API/service liés sont en dehors du périmètre de cible par défaut. Pour inclure les sous-domaines liés sous la même racine :```bash akca -u https://www.example.com --include-linked-api-subdomains

Formats pris en charge : HTML, JSON, Markdown, CSV et SARIF. Chaque invocation démarre un nouveau scan.

Les rapports HTML sont autonomes et incluent le logo AKCA, des résumés des risques et de la gravité, des statistiques de vulnérabilités, des détails structurés sur les constats et des preuves HTTP dépliables. Les onglets de requête et de réponse prennent en charge une vue combinée, l'expansion du contenu complet et la copie. Lorsqu'un constat conserve une valeur de réponse correspondante, AKCA la met en évidence en jaune, ce qui vous aide à localiser une charge utile réfléchie ou un secret exposé. Les constats de secrets passifs conservent un extrait autour de la correspondance.

Selon le module, les constats incluent :

• Les requêtes et réponses HTTP enregistrées.
• Les charges utiles et les commandes de reproduction cURL.
• La confiance, les observations de vérification et le statut de la politique de preuve.
• Les mappages CWE et OWASP.

Les constats de timing, les en-têtes manquants et les callbacks externes peuvent ne comporter aucun texte de réponse à mettre en évidence. Leur contexte de vérification fournit les preuves pertinentes.

Lorsque le scanner a stocké une transaction brute complète, le rapport la préserve exactement. Les preuves plus anciennes ou uniquement structurées sont rendues dans une disposition HTTP conventionnelle de style Burp avec une ligne de requête, des en-têtes ordonnés, un séparateur en-tête/corps et des phrases de raison de réponse HTTP standard. Si la limite de capture du transport a tronqué une réponse, le rapport le signale explicitement ; il ne présente jamais la partie stockée comme la réponse complète indisponible.

Rejouer un constat stocké :```bash akca replay --finding 42

Cela autorise uniquement les requêtes GET/HEAD de scripts, feuilles de style, images, polices et médias vers ces hôtes, en supprimant les identifiants et les en-têtes personnalisés. Cela n'ajoute pas ces hôtes à la portée de scan active et n'autorise pas les appels API cross-origin. Les dépendances de navigateur bloquées produisent des événements de lacune de couverture.

Les URL découvertes sont conservées même lorsqu'elles ne peuvent pas être visitées. Un crawl qui épuise son budget avec du travail en file d'attente produit un scan partiel et un code de sortie CLI non nul. Les messages de préflight des modules distinguent les politiques d'identité/d'état manquantes des capacités de vérification configurées.

Les vérifications de limitation de débit non configurées produisent des observations, et non des constats de vulnérabilité. Une preuve de seuil configurée nécessite également window_seconds ; si les requêtes ne rentrent pas dans cette fenêtre, la vérification n'est pas concluante. Le SQLi ne considère pas une réponse 400 ou une évaluation arithmétique seule comme une preuve. Les nouvelles erreurs SQL spécifiques à un fournisseur dans les réponses 400/422 doivent passer par le chemin de vérification par rejeu et contrôle.

Nouveautés de la v0.2.4

• Préserver les requêtes et réponses HTTP brutes stockées complètes dans les rapports, y compris les corps longs, les en-têtes répétés et les espaces de fin.
• Afficher le trafic structuré uniquement dans une disposition conventionnelle de style Burp avec les en-têtes de requête standard, la longueur du contenu et les phrases de raison HTTP.
• Ajouter un rapport HTML hors ligne de marque AKCA, un tableau récapitulatif des vulnérabilités, des vues Request/Response/Both, des contrôles de contenu complet et des preuves imprimables.
• Reconstruire l'affichage de démarrage sous forme de panneau Scan Session basé sur Lipgloss avec mise en évidence de la cible, détails du système et de la RAM, et un indicateur d'état actif.
• Remplacer l'ETA du scan par un minuteur écoulé mis à jour en continu et afficher des noms de modules conviviaux avec des transitions sur place de Running à Completed.
• Conserver les diagnostics répétitifs de dépendances de navigateur et de couverture dans la sortie verbeuse tout en les préservant dans les métadonnées de scan et les rapports.

Voir CHANGELOG.md pour les détails de version.

Soutenir la mission

AKCA n'accepte pas de parrainages ni de dons personnels. Les contributions de code, les tests, la documentation et les retours réfléchis sont toujours les bienvenus.

Türkiye'den destek olmak isteyenler için

Projeye maddi olarak destek olmak istiyorsanız, bana göndermek yerine Mehmetçik Vakfı, AFAD, Türk Kızılay veya Çocuk Hizmetleri Genel Müdürlüğü aracılığıyla desteklenen güvenilir sosyal yardım çalışmalarından birine bağış yapmanızı rica ediyorum. Mümkünse bağışınızı kızım Akça Aktaş adına yapın. Bağıştan sonra X üzerinden @caneraktas_ hesabına mesaj göndermeniz beni gerçekten çok mutlu eder.

Pour les soutiens en dehors de la Türkiye

Si vous souhaitez soutenir financièrement le projet, veuillez faire un don à une organisation caritative réputée de votre pays qui aide les enfants, les communautés touchées par des catastrophes, les anciens combattants ou les personnes dans le besoin urgent. Lorsque c'est possible, faites le don au nom de ma fille, Akça Aktaş. Vous êtes invité à le partager avec moi sur X à @caneraktas_ ; savoir que ce projet a inspiré un acte utile signifierait beaucoup pour moi.

Développement

Compiler depuis les sources :```bash git clone https://github.com/akha-security/akca.git cd akca/engine go build -buildvcs=false -trimpath -o ../akca ./cmd/akca

Le benchmark mesure son corpus observé. Pour les détails d'implémentation et les limites de vérification, consultez le guide d'architecture et l'audit de vérification.

Les contributions sont les bienvenues. Lisez CONTRIBUTING.md et le Code de conduite avant d'ouvrir une pull request. Signalez les vulnérabilités dans AKCA via SECURITY.md.

Licence

Apache License 2.0 · Copyright 2026 AKHA Security contributors.