Quoting des payloads reverse shell : là où JSON, YAML et les formulaires cassent tout

Le quoting est l'endroit où les belles commandes de lab meurent. Une payload reverse shell peut fonctionner dans votre terminal et échouer dès qu'elle traverse du JSON, du YAML, un formulaire web, une variable CI, un wrapper shell, puis seulement l'interpréteur cible.

La payload n'a pas changé. Les parseurs, eux, ont voté.

Chaque couche transforme quelque chose

Prenez une commande avec des guillemets, des espaces, des redirections et des caractères spéciaux. Votre shell local l'interprète une fois. Une API JSON demande d'échapper les guillemets. Un runner YAML peut traiter les deux-points et les backslashes différemment. Une application web peut normaliser les espaces. Un wrapper vulnérable peut placer votre valeur dans des quotes invisibles.

Quand la commande atteint /bin/sh, ce n'est plus forcément celle que vous avez générée.

C'est pour ça qu'un générateur sérieux doit proposer plusieurs formes : brute, single-quoted, double-quoted, URL-encoded, compatible JSON, ou échappée pour PowerShell. Il n'existe pas de payload universelle.

Déboguer avec des commandes inoffensives

Avant d'envoyer un reverse shell dans un chemin compliqué, envoyez quelque chose de banal :

id
pwd
uname -a

Puis testez des caractères contrôlés :

printf 'quote-test\n'

Si ces commandes échouent, le reverse shell ne vous apprendra rien. Il faut d'abord comprendre comment l'entrée est transformée. Dans un lab, loggez la commande reçue. En black-box autorisée, inférez à partir de la sortie, du timing et des effets explicitement permis.

L'encodage n'annule pas le contexte

Base64 peut réduire la douleur, surtout avec PowerShell ou des wrappers shell. Mais il rend aussi la commande moins lisible pour les humains qui relisent la requête. Et il ne dispense pas d'exécuter quelque chose : une couche doit toujours décoder puis lancer le contenu.

Encodez pour préserver les octets à travers des parseurs hostiles. Pas pour éviter de comprendre le contexte.

Afficher les variantes avec des labels clairs

Le comportement utile côté app est simple : montrer plusieurs formes de la même payload et les nommer franchement. L'utilisateur ne devrait pas deviner quelle variante est faite pour JSON et laquelle est faite pour un shell brut.

La plupart des erreurs de quoting viennent de la fatigue, pas de l'ignorance. Les labels clairs gagnent.