Essentiels de la sécurité Web : SSRF, CSRF et CORS expliqués

Dans le paysage Web moderne, la sécurité n’est pas seulement une fonctionnalité, c’est une fondation. À mesure que les applications deviennent plus interconnectées, comprendre les nuances de la gestion des requêtes à travers différents origines et serveurs est crucial pour tout développeur.

Aujourd’hui, nous plongeons dans trois concepts critiques que chaque développeur Web devrait maîtriser : SSRF, CSRF et CORS. Bien qu’ils puissent ressembler à une soupe à l’alphabet, ils représentent les premières lignes de la sécurité des applications Web.

1. SSRF (Server-Side Request Forgery)

La SSRF est une vulnérabilité où un attaquant peut forcer une application côté serveur à effectuer des requêtes HTTP vers un domaine arbitraire de son choix.

Comment ça marche

Imaginez une application Web qui prend une URL en entrée (par exemple, pour récupérer une photo de profil ou prévisualiser un lien) et effectue ensuite une requête vers cette URL depuis le serveur. Si l’application ne valide pas correctement cette URL, un attaquant pourrait fournir une adresse IP interne ou une adresse de bouclage (127.0.0.1).

Le serveur, agissant comme un proxy, pourrait alors récupérer des données sensibles à partir de services internes qui ne sont pas exposés sur l’Internet public, tels que :

• Métadonnées Cloud : Accès à 169.254.169.254 sur AWS/GCP pour récupérer les identifiants IAM.
• Panneaux d’administration internes : Accès à des outils internes comme Jenkins ou des tableaux de bord Kubernetes.
• Scan de ports : Découverte d’autres services fonctionnant sur le réseau interne.

Prévention

• Liste d’autorisation (Allowlisting) : N’autorisez que les requêtes vers une liste prédéfinie de domaines de confiance.
• Validation des entrées : Assurez-vous que l’URL utilise des protocoles autorisés (par exemple, https:// uniquement) et ne pointe pas vers des plages d’adresses IP internes.
• Ségrégation du réseau : Assurez-vous que le serveur Web a un accès restreint aux ressources internes.

2. CSRF (Cross-Site Request Forgery)

La CSRF est une attaque qui trompe le navigateur d’une victime pour lui faire effectuer une action non souhaitée sur un autre site Web où la victime est actuellement authentifiée.

Comment ça marche

Cette attaque exploite le fait que les navigateurs incluent automatiquement les identifiants ambiants — comme les cookies de session — avec chaque requête vers un domaine.

1. Un utilisateur se connecte à bank.com.
2. L’utilisateur visite un site malveillant evil.com dans un autre onglet.
3. evil.com contient un formulaire caché qui soumet une requête POST à bank.com/transfer?amount=1000&to=attacker.
4. Le navigateur envoie la requête accompagnée du cookie de session bank.com de l’utilisateur.
5. bank.com voit une session valide et traite le transfert.

Prévention

• Jetons Anti-CSRF : Incluez un jeton unique, secret et imprévisible dans chaque requête modifiant l’état. Le serveur vérifie ce jeton avant le traitement.
• Cookies SameSite : Définissez l’attribut SameSite sur les cookies à Strict ou Lax pour empêcher leur envoi lors de requêtes intersites.
• En-têtes personnalisés : Pour les requêtes AJAX, exigez un en-tête personnalisé (par exemple, X-Requested-With) qui ne peut pas être défini par un formulaire HTML standard.

3. CORS (Cross-Origin Resource Sharing)

Contrairement à SSRF et CSRF, le CORS n’est pas une vulnérabilité en soi, mais un mécanisme de sécurité. C’est un moyen pour les serveurs de dire au navigateur : “C’est d’accord pour que cette origine externe spécifique accède à mes ressources.”

Pourquoi il existe

Par défaut, les navigateurs appliquent la Politique de même origine (SOP), qui empêche un script sur un site de lire des données d’un autre site. Cela empêche evil.com de lire vos e-mails sur gmail.com.

Le CORS permet aux serveurs d’assouplir cette politique en toute sécurité. Lorsqu’une application Web effectue une requête cross-origin, le navigateur envoie un en-tête Origin. Le serveur répond avec Access-Control-Allow-Origin.

Mauvaises configurations courantes

• Origine générique (*) : Autoriser toutes les origines. Bien que cela soit acceptable pour les API publiques, c’est dangereux si combiné avec Access-Control-Allow-Credentials: true.
• Reflet de l’origine : Définir dynamiquement l’origine autorisée en fonction de l’en-tête Origin sans validation. Cela contourne effectivement complètement la SOP.

Bonnes pratiques

• Soyez spécifique : N’autorisez que les domaines spécifiques qui ont besoin d’un accès.
• Évitez les identifiants si possible : Si votre API n’a pas besoin de cookies ou d’en-têtes d’autorisation, ne les autorisez pas.
• Utilisez un middleware de sécurité : Utilisez des bibliothèques bien testées pour gérer la configuration CORS au lieu de gérer les en-têtes manuellement.

Résumé comparatif

Comprendre ces trois piliers de la sécurité Web est essentiel pour créer des applications modernes et robustes. En mettant en œuvre des stratégies de défense en profondeur, vous pouvez protéger à la fois l’infrastructure interne de votre serveur et les données privées de vos utilisateurs.

Restez en sécurité et bon codage !