SAST et DAST

Comprendre comment détecter les vulnérabilités dans un programme grâce à l'analyse statique et dynamique du code.

Notions théoriques

L'analyse de sécurité des logiciels est essentielle pour éviter les failles exploitables par des attaquants.

Il existe 2 grandes méthodes pour détecter les vulnérabilités dans le code :

• L'analyse statique du code (SAST) qui examine le code source sans l'exécuter.
• L'analyse dynamique du code (DAST) qui teste l'application en cours d'exécution.

Analyse statique du code (SAST)

L'analyse statique permet de détecter des erreurs et des failles de sécurité avant même que le programme ne soit exécuté.

Fonctionnement

1. Un outil analyse le code source et identifie des failles potentielles.
2. Il signale les erreurs, avertissements et recommandations.
3. Les développeurs corrigent les problèmes avant l'exécution du programme.

Avantages

• Détection précoce des erreurs.
• Identification des failles de sécurité dans le code source.
• Amélioration de la lisibilité et de la maintenabilité du code.

Inconvénients

• Peut générer des faux positifs.
• Ne détecte pas les erreurs liées à l'exécution du programme.

Analyse dynamique du code (DAST)

L'analyse dynamique permet de tester un programme en cours d'exécution pour repérer des vulnérabilités exploitables.

Fonctionnement

1. L'application est exécutée dans un environnement de test.
2. Un outil simule des attaques et analyse les réponses du programme.
3. Les résultats indiquent les vulnérabilités détectées.

Avantages

• Permet de détecter des erreurs qui ne sont visibles qu'à l'exécution.
• Teste le programme dans des conditions réelles.
• Identifie les failles exploitables par des attaquants.

Inconvénients

• Nécessite un environnement de test fonctionnel.
• Peut être plus long à exécuter qu'une analyse statique.

Différences entre SAST et DAST

Critère	Analyse statique (SAST)	Analyse dynamique (DAST)
Moment d'analyse	Avant l'exécution	Pendant l'exécution
Type d'analyse	Code source	Comportement du programme
Détection	Erreurs de syntaxe, failles connues	Vulnérabilités exploitables, erreurs d'exécution
Rapidité	Rapide	Plus long
Faux positifs	Possibles	Moins fréquents

---

Exemple pratique

Il est possible d'utiliser SonarQube pour une analyse statique et OWASP ZAP pour une analyse dynamique d'une application Web.

Étape 1 : Analyse statique avec SonarQube

1. Installer et exécuter SonarQube en local :

docker run -d --name sonarqube -p 9000:9000 sonarqube

2. Accéder à l'interface web sur http://localhost:9000 et créer un projet.
3. Installer SonarScanner et analyser un projet local :

sonar-scanner -Dsonar.projectKey=mon-projet -Dsonar.sources=. -Dsonar.host.url=http://localhost:9000

4. Observer les résultats et corriger les erreurs détectées.

Étape 2 : Analyse dynamique avec OWASP ZAP

1. Installer OWASP ZAP :

sudo apt install zaproxy

2. Lancer OWASP ZAP et entrer l'URL d'une application web de test.
3. Exécuter un scan de sécurité et analyser les vulnérabilités détectées.

---

Test de mémorisation/compréhension

Quelle est la principale différence entre SAST et DAST ?

SAST analyse le code source, DAST teste l'application en cours d'exécution

DAST analyse le code source, SAST teste l'application en cours d'exécution

SAST et DAST sont identiques mais utilisés à des moments différents

Quel outil est couramment utilisé pour l'analyse statique du code ?

Wireshark

SonarQube

Docker

Pourquoi l'analyse statique est-elle utile ?

Elle permet de tester le programme en conditions réelles

Elle détecte les erreurs avant l'exécution

Elle empêche les attaques en temps réel

Quel est un inconvénient de l'analyse dynamique ?

Elle ne fonctionne que sur les fichiers texte

Elle nécessite un environnement de test fonctionnel

Elle ne peut pas détecter les erreurs de syntaxe

Quand l'analyse dynamique du code est-elle effectuée ?

Avant l'exécution du programme

Pendant l'exécution du programme

Après la mise en production

Quel outil est utilisé pour l'analyse dynamique des applications web ?

OWASP ZAP

Visual Studio Code

SonarQube

Pourquoi utiliser les deux types d'analyse ensemble ?

Pour maximiser la détection des vulnérabilités

Parce que c'est obligatoire

Pour accélérer le développement

Quel est un inconvénient de l'analyse statique ?

Elle ne détecte pas les erreurs d'exécution

Elle est trop lente

Elle ne fonctionne que sur les applications web

Quelle analyse est la plus rapide entre SAST et DAST ?

SAST

DAST

Elles sont équivalentes

Quel type d'analyse permet de détecter des vulnérabilités exploitables en conditions réelles ?

Analyse statique

Analyse dynamique

Aucune des deux

---

TP pour réfléchir et résoudre des problèmes

L'objectif de ce TP est d'analyser la sécurité d'une application Web en utilisant des outils d'analyse statique et dynamique.

astuce

L'application cible est Juice Shop, une application volontairement vulnérable développée par OWASP pour l'apprentissage de la sécurité Web.

Étape 1 : Préparation de l'environnement

1. Installer Docker si ce n'est pas déjà fait.
2. Télécharger et exécuter OWASP Juice Shop avec Docker :

docker run -d --name juiceshop -p 3000:3000 bkimminich/juice-shop

3. Accéder à l'application sur http://localhost:3000.

info

Cette étape permet de préparer l'environnement avec une application contenant des vulnérabilités.

• docker run -d --name juiceshop -p 3000:3000 bkimminich/juice-shop télécharge et exécute Juice Shop en arrière-plan.
• Juice Shop est accessible via un navigateur à l'adresse http://localhost:3000.

Une fois cette étape terminée, l'application est prête pour l'analyse.

---

Étape 2 : Analyse statique avec ESLint et SonarQube

1. Installer ESLint, un outil d'analyse statique pour JavaScript :

npm install -g eslint

2. Initialiser ESLint dans le projet Juice Shop :

cd ~/juice-shop
eslint --init

3. Exécuter une analyse statique du code :

eslint .

4. Installer et exécuter SonarQube en local :

docker run -d --name sonarqube -p 9000:9000 sonarqube

5. Configurer SonarQube en créant un fichier sonar-project.properties dans le dossier Juice Shop :

sonar.projectKey=JuiceShop
sonar.sources=.
sonar.host.url=http://localhost:9000

6. Exécuter l'analyse avec SonarScanner :

sonar-scanner

info

L'analyse statique permet d'identifier des erreurs dans le code source avant l'exécution.

• npm install -g eslint installe ESLint globalement.
• eslint --init configure ESLint pour analyser le code JavaScript.
• eslint . exécute une analyse statique sur tous les fichiers du projet.

Pour SonarQube :

• docker run -d --name sonarqube -p 9000:9000 sonarqube lance SonarQube en local.
• Le fichier sonar-project.properties configure l'analyse pour Juice Shop.
• sonar-scanner exécute l'analyse et envoie les résultats à SonarQube.

Les résultats sont visibles sur http://localhost:9000, où les erreurs et recommandations sont affichées.

---

Étape 3 : Analyse dynamique avec OWASP ZAP

1. Installer OWASP ZAP :

sudo apt install zaproxy

2. Lancer OWASP ZAP et entrer l'URL de Juice Shop (http://localhost:3000).
3. Exécuter un scan automatique pour détecter les vulnérabilités.
4. Analyser les résultats et identifier les failles les plus critiques.

info

L'analyse dynamique permet de détecter des failles exploitables en conditions réelles.

• sudo apt install zaproxy installe OWASP ZAP.
• Lancer OWASP ZAP et entrer http://localhost:3000 cible Juice Shop.
• Le scan automatique teste l'application pour identifier les vulnérabilités.

Les résultats affichent les failles détectées, comme les injections SQL ou les failles XSS.

---

Étape 4 : Correction des vulnérabilités et nouvelle analyse

1. Modifier le code source pour corriger les erreurs signalées par ESLint et SonarQube.
2. Mettre à jour les dépendances pour corriger les vulnérabilités identifiées.

npm audit fix

3. Relancer les analyses statique et dynamique pour vérifier les corrections.

info

Cette étape permet de valider les corrections effectuées.

• Modifier le code en suivant les recommandations d'ESLint et SonarQube améliore la qualité et la sécurité.
• npm audit fix met à jour les dépendances pour corriger les failles connues.
• Relancer les analyses permet de vérifier que les vulnérabilités ont bien été corrigées.

Une fois toutes les corrections appliquées, l'application est plus sécurisée.