"La cybersécurité ressemble à une partie d'échecs sans fin : pour chaque attaque, une défense doit être trouvée."

Dans le cadre de notre cours de sécurité logicielle, nous avons développé en équipe de 6 personnes un scanneur de vulnérabilités pour applications web. Ce projet n'a pas la prétention d'être révolutionnaire, mais notre démarche et les défis techniques surmontés pourraient intéresser ceux qui veulent comprendre comment automatiser la sécurité web.

🛡️ Les vulnérabilités web expliquées simplement

Le problème : des failles partout

Votre site web, c'est comme une maison avec des dizaines de portes et fenêtres. Une vulnérabilité, c'est une serrure défectueuse qui permet à un intrus d'entrer. Le souci ? Un site moderne peut avoir des centaines de points d'entrée à vérifier.

Les 3 failles les plus courantes :

🔹 Injection SQL : un attaquant peut "parler" directement à votre base de données
🔹 Authentification cassée : les mots de passe ou sessions mal protégés
🔹 Données exposées : des informations sensibles visibles par tous

Pourquoi automatiser ? Tester manuellement des centaines de paramètres prendrait des semaines. De nouvelles vulnérabilités apparaissent chaque jour. Même les experts peuvent oublier un détail.

⚙️ Notre solution : de l'idée simple à l'architecture complexe

L'inspiration : "l'Ansible des attaques"

Au début, on voulait créer des "recettes d'attaques" automatiques. Comme Ansible automatise la configuration de serveurs, on voulait automatiser les tests de sécurité avec des fichiers YAML simples.

Le problème qu'on a vite découvert : les tests de sécurité peuvent durer un certain temps en fonction de leur implémentation.

Comment permettre plusieurs scans simultanés sans planter l'interface ?

Notre architecture distribuée

La solution : séparer l'interface utilisateur de l'exécution des tests avec une architecture distribuée.

Technical Evidence

Technical Evidence

Les 4 composants clés :

1. Interface React : pour configurer et suivre les scans en temps réel
2. API Flask : le chef d'orchestre qui coordonne tout
3. Redis : la file d'attente ultra-rapide qui stocke les tâches
4. Workers Python : les "ouvriers" qui exécutent les tests en parallèle

Le système modulaire : la magie du YAML

L'idée : Chaque test de sécurité est décomposé en "modules" réutilisables, orchestrés par des fichiers YAML.

hljs yaml
name: test_securite_complete
description: Analyse complète des vulnérabilités web
steps:
  - module: http_request
    params:
      url: "{{ target }}"
      timeout: 10
  - module: analyze_headers
  - module: test_sql_injection
  - module: test_xss

L'avantage : N'importe qui peut créer un nouveau test sans programmer !

Technical Evidence

Technical Evidence

🔍 Exemple concret : détecter une faille XSS

Notre approche : le scanneur teste automatiquement différents "payloads" malveillants pour voir si le site les filtre correctement.

hljs yaml
name: detection_xss
description: Test automatisé de vulnérabilités XSS
steps:
  - module: http_request
    params:
      url: "{{ target }}"
  - module: xss_tester
    params:
      payloads:
        - "<script>alert('Faille détectée!')</script>"
        - '''"><img src=x onerror=alert(''XSS'')>'

Le processus :

1. Requête HTTP normale vers la cible
2. Test de différents codes malveillants
3. Analyse de la réponse : le site a-t-il exécuté notre code ?
4. Rapport automatique avec niveau de risque

🚧 Les 3 défis techniques majeurs

1. La synchronisation distribuée

Le défi : comment coordonner plusieurs workers sans qu'ils se marchent dessus ?

Notre solution : redis gère la file d'attente. Chaque worker prend une tâche, la traite, renvoie le résultat. Simple et efficace.

2. Le système de contexte partagé

Le défi : comment partager des infos entre les différents modules d'un test ?

Notre solution : un "contexte" (dictionnaire Python) qui voyage de module en module, s'enrichissant à chaque étape.

hljs python
# Exemple : un module enrichit le contexte
def run(self, context):
    response = requests.get(context['url'])
    context['response_headers'] = response.headers
    context['response_time'] = response.elapsed.total_seconds()
    return context

3. L'interface utilisateur

Le défi : Présenter des résultats techniques de façon compréhensible.

Notre apprentissage : Un bon outil de sécurité doit être accessible aux non-experts. Nous ne sommes pas très bon en design, nous avons essayé de présenter nos résultats de façon clair (peut etre trop simplement)

🤝 Éthique et responsabilité

Pour conclure

Ce projet n'est pas parfait, mais il nous a énormément appris sur la sécurité web moderne et les architectures distribuées.

Et vous avez-vous déjà développé des outils de sécurité ? Quelles fonctionnalités considéreriez-vous comme prioritaires ?

---

Le code source est disponible à cette adresse : https://github.com/TugdualDek/projet-secu-logicielle