Comment bloquer les requêtes côté serveur et la désérialisation

Un pare-feu contrôle des flux réseau, pas l’intention métier d’une requête émise par une application légitime. Une SSRF et une désérialisation dangereuse exploitent précisément cette confiance : le serveur devient l’outil de l’attaquant, avec ses accès, ses identités et ses angles morts.

→ Lire l’explication complète de la marmotte

SSRF : le serveur comme relais vers les zones interdites

Une SSRF apparaît lorsqu’une donnée contrôlée par l’utilisateur devient une destination réseau. Une fonction de prévisualisation d’URL (Uniform Resource Locator), un import depuis une adresse distante, un webhook ou un connecteur de paiement suffisent. L’application émet alors une requête Hypertext Transfer Protocol (HTTP) depuis son propre réseau, avec ses routes et parfois ses en-têtes d’authentification.

Le compromis central est net : accepter des destinations dynamiques accélère les intégrations, mais transfère à l’application la responsabilité de gouverner les sorties réseau. La recommandation est de refuser tout accès direct d’un service applicatif vers Internet ou les réseaux internes non nécessaires. Les sorties doivent passer par un proxy de sortie, avec une politique par service et par destination. Cette position reste valide si le proxy applique la politique après résolution de nom et au moment de la connexion, pas seulement sur la chaîne de caractères fournie.

Bloquer localhost, 127.0.0.1 et 169.254.169.254 dans une expression régulière ne protège rien. Une destination peut être fournie sous forme d’adresse Internet Protocol (IP) version 6, d’adresse IP version 4 encodée en entier, d’adresse IP version 6 mappée sur IP version 4, de nom résolu par le Domain Name System (DNS), ou par une redirection HTTP. Une résolution DNS peut aussi changer entre la validation et la connexion : c’est le DNS rebinding. Valider un nom, puis laisser la bibliothèque résoudre ce nom plus tard, revient à confier le contrôle d’accès à une course réseau. Très moderne, très distribué, très mauvais.

Les cibles à couvrir explicitement sont les plages privées définies par la Request for Comments (RFC) 1918, les adresses de boucle locale, les plages link-local, les réseaux de conteneurs, les interfaces d’administration et les services de métadonnées cloud. Un Instance Metadata Service (IMDS) compromis donne souvent des jetons temporaires ou des informations de configuration. Le pare-feu voit une connexion autorisée depuis le serveur vers une adresse locale. Il n’a aucune raison de deviner que cette connexion vient d’un champ imageUrl.

Les redirections doivent être désactivées par défaut pour les requêtes issues de données externes. Si elles sont requises, chaque destination redirigée doit repasser la validation et la politique de sortie. Les schémas autorisés doivent être limités à https, avec vérification du certificat Transport Layer Security (TLS), durée maximale, taille maximale de réponse et nombre de redirections borné. Autoriser file:, gopher:, ftp: ou des schémas spécifiques à une bibliothèque ouvre des chemins rarement présents dans les schémas d’architecture, donc rarement défendus. Les diagrammes adorent les flèches, les attaquants aussi.

La segmentation réseau reste nécessaire, mais elle ne remplace pas ce contrôle applicatif. Une SSRF depuis un pod autorisé à joindre une base de données contourne la séparation entre navigateur et base de données sans casser le moindre paquet réseau.

Désérialisation : exécuter une structure devenue programme

La désérialisation transforme une représentation stockée ou transmise en objet manipulable par un programme. Le danger commence quand le format embarque des types, des constructeurs, des références ou des comportements exécutables. Des mécanismes comme pickle en Python, ObjectInputStream en Java ou certains sérialiseurs .NET peuvent instancier des classes et déclencher des méthodes pendant la lecture.

Le résultat recherché par l’attaquant est souvent une Remote Code Execution (RCE), c’est-à-dire l’exécution de commandes avec l’identité du processus applicatif. Une chaîne de gadgets assemble alors des classes déjà présentes dans les dépendances pour déclencher un effet dangereux : chargement de ressource distante, écriture de fichier, appel système ou expression interprétée. La vulnérabilité ne dépend pas d’une bibliothèque exotique : elle dépend de ce que le processus accepte de reconstruire. Une dépendance oubliée dans une image de conteneur peut devenir un composant actif de l’attaque. Le code mort adore soudainement reprendre du service, tel un tableur de gouvernance ressorti en audit.

La règle à appliquer est stricte : ne jamais désérialiser un format objet natif à partir d’une donnée contrôlée par un tiers, même authentifié. Un jeton signé, un cookie signé ou un message issu d’un partenaire ne rendent pas un mécanisme dangereux acceptable. Une signature prouve l’origine de données, sous réserve que la clé ne soit pas compromise ; elle ne garantit ni l’absence de rejeu, ni l’absence de gadget dans le graphe d’objets, ni la légitimité fonctionnelle de l’action demandée.

Préférer un format de données sans exécution implicite, tel que JavaScript Object Notation (JSON), Protocol Buffers ou un schéma binaire explicitement défini. La sécurité vient alors de trois contrôles distincts :

définir un schéma fermé, avec champs, types, tailles et valeurs autorisées ;
mapper les données vers des types métier connus, sans résolution de classe à partir d’un champ reçu ;
vérifier l’autorisation métier après parsing, car une structure valide n’accorde aucun droit.

Une liste d’autorisation de types peut réduire l’exposition d’un sérialiseur historique, mais elle ne constitue pas une stratégie pérenne. Une liste doit couvrir les classes transitives, les bibliothèques ajoutées et les comportements de conversion. Si un produit impose ce mécanisme, isoler le composant dans un processus sans privilège, sans accès aux secrets et sans sortie réseau directe. Cela limite le rayon d’explosion, sans transformer une grenade en presse-papier.

Les principes de gestion des données s’appliquent ici directement : conserver le format, sa version et son contrat de validation comme des éléments d’architecture, pas comme une commodité de développement.

Exemple : bloquer l’egress applicatif et filtrer les destinations

Une politique Kubernetes peut empêcher un service applicatif de joindre directement le réseau, tout en autorisant le DNS et un proxy de sortie identifié. Kubernetes ne remplace pas un proxy applicatif : il réduit les chemins disponibles. Le proxy doit ensuite appliquer une liste d’hôtes ou de domaines autorisés, résoudre les noms lui-même et refuser les adresses internes après résolution.

# NetworkPolicy Kubernetes : le pod applicatif ne parle qu'au DNS et au proxy.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: application-egress
  namespace: catalogue
spec:
  podSelector:
    matchLabels:
      app: catalogue-api
  policyTypes:
    - Egress
  egress:
    # Résolution DNS limitée au résolveur du cluster.
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

    # Toute sortie HTTP passe par le proxy de sortie.
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: securite
          podSelector:
            matchLabels:
              app: egress-proxy
      ports:
        - protocol: TCP
          port: 3128

Cette politique suppose un plugin réseau qui applique réellement les NetworkPolicy. Certains environnements les acceptent sans les faire respecter, ce qui produit une sécurité décorative. Vérifier le comportement avec un pod de test, une tentative vers une adresse privée et une tentative de contournement par adresse IP directe.

Le proxy de sortie doit journaliser le service appelant, l’hôte demandé, l’adresse effectivement jointe, la décision et le motif de refus. Ne pas journaliser aveuglément les paramètres d’URL : les jetons d’accès finissent régulièrement dans les chaînes de requête, parce que l’humanité a décidé que les secrets méritaient une place dans les logs.

Surface d’attaque, secrets et conditions d’exploitation

Une SSRF exploite les privilèges réseau du processus. Réduire donc les droits réseau par identité de charge de travail, segmenter les plans d’administration et exiger une authentification mutuelle entre services sensibles. Une autorisation fondée uniquement sur une adresse source reste fragile : un service compromis parle depuis la bonne adresse.

Une désérialisation exploite les privilèges d’exécution. Le processus concerné doit disposer d’un compte dédié, de droits système minimaux, d’un système de fichiers en lecture seule lorsque possible et d’un accès aux secrets limité au strict besoin. Un coffre de secrets n’empêche pas une RCE ; il réduit ce qu’une RCE peut voler. La différence compte beaucoup après l’incident, nettement moins sur une slide.

Les bibliothèques de parsing et de sérialisation doivent être inventoriées avec leur version. Toute mise à jour de dépendance peut introduire de nouveaux types exploitables ou modifier un comportement de parsing. Les tests de sécurité doivent inclure des charges malformées, des objets profondément imbriqués, des réponses compressées démesurées, des redirections et des noms DNS à réponses multiples.

La supervision doit alerter sur les refus du proxy vers des plages internes, les pics de redirections, les échecs TLS, les erreurs de désérialisation et les sorties réseau inhabituelles par identité applicative. Une alerte sans corrélation avec le déploiement, la version applicative et l’identité de service crée surtout du bruit. Le bruit est le meilleur allié d’une intrusion lente.

Les politiques de proxy, listes d’autorisation, schémas de messages et règles réseau doivent être versionnés, revus et sauvegardés. La reprise exige de restaurer ces politiques avec les applications, puis de vérifier que les identités, certificats et secrets associés restent valides. Une sauvegarde de base de données sans restauration des contrôles de sortie remet le château sur pied en oubliant la porte.

🐝 Ce qui arrive si on s’en passe

Sans sorties gouvernées ni formats fermés, la porte reste ouverte et personne ne regarde qui entre. Un champ d’URL devient un point d’appui pour interroger des services internes depuis une identité applicative légitime, et la trace collectée ne montre qu’un appel sortant banal, sans hôte demandé, sans adresse réellement jointe, sans motif de refus. L’analyse post incident ne peut plus distinguer une intégration normale d’un détour provoqué, ni dater le début de l’abus. Côté objets reconstruits sans schéma, la dépendance ayant fourni le gadget reste inconnue faute d’inventaire de versions, ce qui empêche de délimiter les instances concernées et de décider quoi reconstruire. La reprise se limite alors à restaurer des données, sans garantie que les destinations autorisées, les certificats et les droits du processus reviennent dans un état vérifié.

🦫 Explication de la marmotte 🍫

Une requête côté serveur forcée apparaît quand une application reçoit une adresse fournie par une personne externe et va la consulter elle-même. L’application possède souvent le droit de contacter des services auxquels le navigateur n’a pas accès. Si elle accepte n’importe quelle adresse, elle peut être poussée vers une base de données, un service interne ou une page qui contient des informations réservées. Pour éviter cela, il faut limiter les destinations autorisées, vérifier l’adresse réellement contactée et faire passer les sorties par un point de contrôle dédié.

La désérialisation concerne les données transformées en objets utilisables par un programme. Certains formats ne décrivent pas seulement des valeurs comme du texte ou des nombres : ils peuvent demander au programme de créer des objets particuliers et d’exécuter des actions pendant cette création. Une donnée hostile peut alors déclencher une commande ou accéder à des fichiers. Le bon choix est de recevoir des formats de données contrôlés, de vérifier chaque champ et de ne reconstruire que des objets prévus par le programme.

Le pare-feu reste nécessaire, mais il voit surtout qui contacte qui. Il ne sait pas forcément qu’une application autorisée a été trompée par une adresse ou un fichier reçu. Il faut donc ajouter des contrôles dans l’application, dans les sorties réseau et dans les droits accordés au processus.

Pages voisines

La citent

Comment bloquer les requêtes côté serveur et la désérialisation

Elle cite

Comment bloquer les requêtes côté serveur et la désérialisation

Comment bloquer les requêtes côté serveur et la désérialisation

SSRF : le serveur comme relais vers les zones interdites

Désérialisation : exécuter une structure devenue programme

Exemple : bloquer l’egress applicatif et filtrer les destinations

Surface d’attaque, secrets et conditions d’exploitation

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines