# Démonstration OWASP A05:2025 : faille d'injection (XSS Reflected)

## Objectif

Comprendre la faille de sécurité **OWASP A05:2025 (Injection)**, spécifiquement une attaque XSS (Cross-Site Scripting) Reflétée. L'OWASP Top 10 2025 classe le Cross-site Scripting comme un type de faille d'injection.

Dans cet exercice, nous allons voir comment une donnée fournie par un utilisateur via une URL (un paramètre `search`) peut être utilisée pour injecter et exécuter du code JavaScript malveillant dans la page. Cela est possible lorsque les données fournies par l'utilisateur ne sont pas validées, filtrées ou aseptisées par l'application.

Nous verrons également comment le moteur de template **Pug** nous protège par défaut, et comment une mauvaise utilisation de sa syntaxe peut créer la vulnérabilité.

## Contexte

Nous avons un simple serveur Express.js qui utilise **Pug** comme moteur de template.

1.  L'utilisateur accède à la page, par exemple `http://localhost:3000/`.
2.  Il peut utiliser un formulaire de recherche, qui soumet sa requête via un paramètre d'URL (ex: `http://localhost:3000/?search=chats`).
3.  Le serveur (dans `routes/index.js`) récupère cette valeur `search`.
4.  Il la transmet au template `views/index.pug` pour qu'il l'affiche.

<!-- end list -->

```mermaid
flowchart TD
    subgraph "Navigateur de l'utilisateur"
        A["Formulaire de recherche (index.pug)"]
    end
    subgraph "Serveur (Express + Pug)"
        B["routes/index.js<br>Recupere req.query.search"]
        C["views/index.pug<br>Affiche le 'searchTerm'"]
    end
    A -- "1. Submit GET /?search=..." --> B
    B -- "2. Passe 'searchTerm' au template" --> C
    C -- "3. Rend le HTML et l'envoie au navigateur" --> A
```

## Instructions

### Mise en place

1.  Ouvrez un terminal et placez-vous dans le dossier de ce projet.
2.  Installez les dépendances:
    ```bash
    npm install
    ```
3.  Lancez le serveur API:
    ```bash
    nodemon ./bin/www
    ```
    *(Le serveur tourne maintenant sur `http://localhost:3000`)*
4.  Ouvrez `http://localhost:3000` dans votre navigateur.

-----

### Partie 1 : Test normal (non malveillant)

1.  Sur la page, dans le formulaire de recherche, entrez un texte simple comme **"chats"**.
2.  Cliquez sur "Lancer la recherche".
3.  **Résultat attendu :**
    * L'URL est devenue `http://localhost:3000/?search=chats`.
    * La page affiche "chats" dans la section "1. Rendu SÉCURISÉ".
    * La page affiche "chats" dans la section "2. Rendu VULNÉRABLE".

Tout fonctionne normalement.

-----

### Partie 2 : Démonstration de la faille XSS

Maintenant, nous allons simuler une attaque. Au lieu d'un simple mot, nous allons injecter une balise `<script>`.

1.  Dans le formulaire de recherche, entrez le texte suivant :
    ```html
    <script>alert('Faille XSS !')</script>
    ```
2.  Cliquez sur "Lancer la recherche".

**Résultat attendu :**

* Une boîte d'alerte (pop-up) apparaît dans votre navigateur avec le message "Faille XSS \!".
* Si vous inspectez le code source de la page (clic droit \> Afficher le code source) au niveau des résultats, vous verrez ceci :

**1. Rendu SÉCURISÉ :** Le code a été "échappé". Il est inoffensif.

```html
<span style="background-color: #e0fde0; ...">&amp;lt;script&amp;gt;alert('Faille XSS !')&amp;lt;/script&amp;gt;</span>
```

**2. Rendu VULNÉRABLE :** Le code a été injecté tel quel. Le navigateur l'a lu et exécuté.

```html
<span style="background-color: #fde0e0; ..."><script>alert('Faille XSS !')</script></span>
```

-----

## Analyse : La cause de la faille (`#{}` vs. `!{}`)

La faille ne vient pas d'Express, mais de la façon dont le template Pug a été instruit d'afficher la donnée `searchTerm` (voir `views/index.pug`).

Pug, comme la plupart des moteurs de template modernes, fournit une protection **par défaut** contre les attaques XSS en **"échappant"** les caractères spéciaux.

* `<` devient `&lt;` (less-than)
* `>` devient `&gt;` (greater-than)

<!-- end list -->

```mermaid
sequenceDiagram
    participant Input as "Payload<br><script>alert('...')</script>"
    participant Pug as "Moteur de template Pug"
    participant HTML as "Sortie HTML (pour le navigateur)"

    Input -->> Pug: "Syntaxe SÉCURISÉE<br>code: #35;{searchTerm}"
    Pug-->>HTML: "Pug-->>HTML: "&amp&#59;lt&#59;script&gt&#59;alert('...')&amp&#59;lt&#59;/script&gt&#59;"
    note right of HTML: Le navigateur affiche le texte, n'execute rien.

    Input -->> Pug: "Syntaxe VULNÉRABLE<br>code: !{searchTerm}"
    Pug-->>HTML: "<script>alert('...')</script>"
    note right of HTML: "Le navigateur voit une balise script et l'execute !"
```

### 1. Le Rendu Sécurisé (Escaped)

En utilisant `#{searchTerm}`, nous demandons à Pug d'insérer la variable en l'échappant. C'est le comportement par défaut et souhaité pour toute donnée venant d'un utilisateur.

**Code Pug :**

```pug
span #{searchTerm}
```

**Résultat HTML (Sûr) :**

```html
<span>&amp;lt;script&amp;gt;alert('Faille XSS !')&amp;lt;/script&amp;gt;</span>
```

### 2. Le Rendu Vulnérable (Unescaped)

En utilisant `!{searchTerm}` (notez le `!`), nous disons explicitement à Pug : "Fais confiance à cette variable. Insère-la telle quelle, brute, sans aucun échappement."

C'est extrêmement dangereux si la variable (`searchTerm`) provient d'un utilisateur, car elle permet l'injection de n'importe quel HTML ou JavaScript.

**Code Pug :**

```pug
span !{searchTerm}
```

**Résultat HTML (Vulnérable) :**

```html
<span><script>alert('Faille XSS !')</script></span>
```

## Conclusion et Correction

* **La faille A05 (Injection)** se produit lorsque des données non fiables (venant de l'utilisateur) sont envoyées à un interpréteur (ici, le navigateur) sans être nettoyées ou échappées.
* **La correction** est de **toujours** utiliser la syntaxe d'échappement par défaut de votre moteur de template (`#{variable}` en Pug) lorsque vous affichez des données fournies par l'utilisateur.
* Cela correspond aux mesures préventives de l'OWASP, comme l'utilisation d'une "API sûre" (l'API de Pug par défaut) ou "l'échappement des caractères spéciaux".
* N'utilisez la syntaxe de non-échappement (`!{}`) que pour du contenu HTML que **vous** contrôlez entièrement et dont vous êtes certain qu'il est sûr.