Ressources · 72
Imports par URL : prévenir les requêtes serveur non autorisées
Prévenir les attaques SSRF dans les téléchargements, aperçus et connecteurs utilisant une adresse fournie par un utilisateur.
· 3 min
Ce que ce guide permet
- Inventorier les sorties
- Réduire les destinations
- Limiter au niveau réseau
- Tester les refus
Contrôle express
- Quelles destinations le composant peut-il atteindre ?
- Une redirection est-elle contrôlée avant connexion ?
- Les refus sont-ils vérifiés sur des cibles factices ?
Méthode pas à pas
- 01
Inventorier les sorties
Recensez import d’images, récupération de documents, aperçus de liens et connecteurs. Notez les protocoles, bibliothèques, destinations légitimes et réseaux accessibles depuis chaque composant. L’interface publique ne décrit pas les accès du serveur.
Livrable : carte des sorties.
- 02
Réduire les destinations
Si les services sont connus, utilisez une liste d’autorisation stricte. Validez schéma, nom, port et adresses résolues avec des outils adaptés. Contrôlez chaque redirection ou désactivez-la. Une expression régulière sur le texte de l’URL ne suffit pas.
Livrable : politique de destination.
- 03
Limiter au niveau réseau
Complétez la validation applicative par des restrictions de sortie et l’isolation du composant de récupération. Limitez temps, taille et nombre de redirections. Vérifiez les protections des services internes et de métadonnées sans utiliser de secrets dans les essais.
Livrable : règles de sortie et limites.
- 04
Tester les refus
Dans un laboratoire autorisé, utilisez des destinations factices représentant réseau privé, boucle locale, redirection et changement de résolution. Vérifiez le refus avant connexion et l’absence d’information sensible dans l’erreur. Conservez les résultats à chaque évolution du connecteur.
Livrable : tests négatifs et preuves de refus.
Fiche de travail à réutiliser
À compléter avec vos observations autorisées. Ces champs constituent une trame de travail, pas des résultats observés.
| Champ | Information à consigner |
|---|---|
| Fonction | Entrée URL, composant et destinations légitimes |
| Politique | Schémas, hôtes, ports, résolution et redirections |
| Essai | Destination factice, refus attendu et observé |
Exemple d’application
Situation illustrative
Exemple fictif : un outil d’aperçu accepte une URL publique de test qui redirige vers un service privé factice.
Décision et preuve attendue
La politique refuse cette nouvelle destination. L’équipe vérifie le journal de refus, les limites de transfert et l’absence de contenu privé renvoyé.
Distinguer les mécanismes
| Mécanisme | Utilité | Point de vigilance |
|---|---|---|
| Destinations connues | Limiter à des services explicitement autorisés | Vérifier résolution et redirections |
| URL externes ouvertes | Accepter une fonctionnalité plus large | Exige une isolation et des contrôles supplémentaires |
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| Sorties documentées | Fonctions reliées à une politique | Traiter les connecteurs sans propriétaire |
| Refus vérifiés | Cas interdits bloqués avant connexion | Corriger les chemins non contrôlés |
Erreurs fréquentes
- Valider uniquement le nom affiché dans l’URL
- Laisser le composant accéder à tous les réseaux internes
Questions fréquentes
HTTPS suffit-il ?
Non. Le protocole ne prouve pas qu’une destination est autorisée ni qu’elle reste la même après résolution ou redirection.
Le filtre doit-il être uniquement dans le navigateur ?
Non. Le service effectuant la requête doit appliquer sa politique, complétée par le réseau.
Peut-on tester sur un système tiers ?
Utilisez un environnement maîtrisé et une autorisation explicite. Cette méthode ne demande aucun test intrusif sur des tiers.
Références officielles
Date de consultation des références : . La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.
Pour aller plus loin
Analyses associées
