# Sécurité web : injection SQL, XSS et CSRF

Informatique de gestion · Bachelor 3

> Principales vulnérabilités web, parades techniques et obligations de sécurité des données en Suisse.

## Introduction

Une application web exposée sur Internet reçoit des données non fiables : tout ce qui vient du navigateur doit être considéré comme potentiellement malveillant. Les vulnérabilités les plus courantes, documentées par le projet OWASP, ont des parades bien connues mais encore trop souvent oubliées.

L'injection SQL survient lorsque des entrées utilisateur sont concaténées dans une requête, ce qui permet à un attaquant d'en modifier la logique ; la parade est l'usage de requêtes préparées (paramétrées). Le cross-site scripting (XSS) consiste à faire exécuter du script dans le navigateur d'autres utilisateurs ; il se combat par l'échappement des sorties et une politique de sécurité du contenu (CSP). Le cross-site request forgery (CSRF) force un utilisateur connecté à exécuter une action à son insu ; on s'en protège par des jetons anti-CSRF et des cookies SameSite.

Les mots de passe ne se stockent jamais en clair mais sous forme de hachage lent salé (bcrypt, Argon2). En Suisse, la loi fédérale sur la protection des données (LPD, révisée et en vigueur depuis le 1er septembre 2023) impose aux responsables de traitement de prendre des mesures techniques et organisationnelles appropriées pour garantir la sécurité des données personnelles, et d'annoncer au PFPDT toute violation entraînant un risque élevé.

## Objectifs d'apprentissage

- Expliquer le mécanisme d'une injection SQL et sa parade
- Distinguer XSS stocké, réfléchi et basé sur le DOM
- Décrire une attaque CSRF et les contre-mesures
- Choisir un stockage sûr des mots de passe
- Relier les mesures de sécurité aux obligations de la LPD

## Concepts clés

- **Injection SQL** : Une entrée mal traitée modifie la requête exécutée (par exemple ' OR '1'='1). Parade : requêtes préparées, validation côté serveur, droits minimaux du compte de base de données.
- **Cross-site scripting (XSS)** : Du code JavaScript injecté s'exécute dans le navigateur d'une victime et peut voler session ou données. Parades : échapper les sorties, CSP, cookies HttpOnly.
- **Cross-site request forgery (CSRF)** : Un site tiers déclenche une requête authentifiée vers l'application cible grâce au cookie de session. Parades : jeton anti-CSRF, SameSite, vérification de l'origine.
- **Authentification et mots de passe** : Hachage lent et salé (bcrypt, Argon2), authentification multifacteur, limitation des tentatives, HTTPS obligatoire.
- **Cadre suisse : LPD** : La LPD exige des mesures de sécurité adéquates et l'annonce au PFPDT des violations de la sécurité des données présentant un risque élevé pour les personnes concernées.

## Conclusion

La sécurité web repose sur quelques réflexes : ne jamais faire confiance aux entrées, séparer code et données, échapper les sorties, protéger les sessions et stocker correctement les secrets. Ces mesures techniques sont aussi une exigence juridique pour les responsables de traitement en Suisse.

Une approche de défense en profondeur et des tests réguliers réduisent significativement les risques.

## Cartes

### Qu'est-ce qu'une injection SQL ?

Une attaque où des entrées utilisateur non traitées modifient la requête SQL exécutée par le serveur.

### Quelle est la parade principale contre l'injection SQL ?

Les requêtes préparées (paramétrées), qui séparent le code SQL des données.

### Que fait une attaque XSS ?

Elle fait exécuter un script malveillant dans le navigateur d'une victime sur un site de confiance.

### Comment se protéger contre le XSS ?

Échapper ou encoder toute donnée affichée, utiliser une Content Security Policy et marquer les cookies de session HttpOnly.

### Quelle est la différence entre XSS stocké et réfléchi ?

Stocké : le script est enregistré côté serveur et servi à tous. Réfléchi : il est renvoyé immédiatement depuis un paramètre de requête.

### Qu'est-ce que le CSRF ?

Une attaque qui pousse un utilisateur authentifié à envoyer, à son insu, une requête vers une application où il est connecté.

### Quelles contre-mesures contre le CSRF ?

Jeton anti-CSRF par formulaire, cookies SameSite, vérification de l'en-tête Origin, ré-authentification pour les actions sensibles.

### Comment stocker un mot de passe ?

Sous forme de hachage lent et salé (bcrypt, scrypt, Argon2), jamais en clair ni avec un hachage rapide non salé.

### Pourquoi valider côté serveur et pas seulement dans le navigateur ?

Parce que la validation côté client est contournable ; seul le serveur garantit le respect des règles.

### Quelle obligation impose la LPD en cas de violation de la sécurité des données ?

Annoncer au PFPDT, dans les meilleurs délais, les violations entraînant vraisemblablement un risque élevé pour la personnalité ou les droits fondamentaux des personnes concernées.

## Glossaire

- **OWASP** : Communauté publiant notamment la liste des risques de sécurité les plus critiques des applications web.
- **Requête préparée** : Requête SQL à paramètres séparant le code des données.
- **XSS** : Injection de script exécuté dans le navigateur de la victime.
- **CSRF** : Requête forgée exploitant la session d'un utilisateur authentifié.
- **Salage** : Valeur aléatoire ajoutée à un mot de passe avant hachage pour contrer les tables précalculées.
- **PFPDT** : Préposé fédéral à la protection des données et à la transparence, autorité de surveillance en Suisse.

https://ruvy.ch/decks/-P5CT2ssr5-GKTTejf6e