Le canal canari : quand un en-tête client choisit votre niveau de privilège
Le défi
L'application Android de ParcelPal demande au backend ce qu'elle a le droit de faire dès son lancement, et elle indique dans un en-tête à quel canal de publication elle appartient. Vous disposez de la requête de lancement dans un repeater. Le réflexe évident est d'essayer les canaux que l'API reconnaît, et cela n'apporte rien d'intéressant : stable et beta renvoient à peu près la même configuration. La valeur recherchée ne figure pas dans cette liste. Lisez attentivement ce que le serveur renvoie, car un champ de la réponse stable ordinaire nomme un canal que le client ne demande jamais, et ce canal reçoit une configuration de build réservée aux appareils internes. Envoyez la requête avec ce canal et soumettez l'identifiant qu'il expose.
Ce que tu vas apprendre
- Repérer une réponse qui varie selon un en-tête contrôlé par le client
- Lire une réponse ordinaire à la recherche de références à des variantes non évidentes
- Comprendre pourquoi la liste de valeurs valides d'un message d'erreur ne fait pas autorité
- Expliquer pourquoi un client ne doit pas choisir son propre niveau de privilège
- Distinguer un identifiant actif d'un identifiant de test grâce à son préfixe
Compétences testées
Prérequis
- Lecture d'une requête et d'une réponse HTTP
- Bases de JSON
Comment ça marche
Les applications mobiles demandent à un endpoint de configuration ce qu'elles ont le droit de faire, et elles s'identifient généralement au passage : une version, une plateforme, un canal de publication. Dès que le serveur change sa réponse en fonction de l'une de ces valeurs, cet en-tête devient une décision de contrôle d'accès prise par le client, et le client est sous le contrôle de l'attaquant.
La partie instructive ici est l'endroit où se trouve l'indice. Envoyez un canal fantaisiste et l'API renvoie known: ["stable", "beta"], ce qui ressemble à une énumération des valeurs valides. Ce n'en est pas une. C'est l'ensemble des canaux que le serveur accepte de nommer. Traiter un message d'erreur comme faisant autorité, c'est ainsi qu'on conclut qu'il n'y a rien là et qu'on passe à autre chose.
La véritable référence se trouvait dans la première réponse, avant toute manipulation : flags_manifest pointe vers /v1/config?channel=canary. Personne n'a classé ce champ comme sensible puisque ce n'est qu'un chemin, mais il nomme le troisième canal. Envoyer canary renvoie une configuration de build avec courier_debug_overlay activé et un objet debug contenant dispatch_api_key.
Le préfixe pp_live_ est ce qui transforme cela d'une curiosité en incident. C'est un identifiant de production dans la configuration d'un build interne, servi à tout appareil qui revendique le bon canal.
Erreurs fréquentes
- Faire confiance à la liste du corps d'erreur.
known: ["stable", "beta"]est ce que le serveur admet, pas ce qu'il sert. - Survoler la réponse stable à la recherche de quelque chose qui a l'air secret. L'indice est un chemin, le champ qui a l'air le moins intéressant de la page.
- Faire du brute force sur les noms de canaux. Inutile. Le nom vous est donné dans la première réponse.
- Soumettre le nom du canal. La réponse attendue est l'identifiant que le canal expose, pas le canal.
- Changer l'en-tête Host en expérimentant. Le garde-fou renvoie un 404 et on dirait que l'endpoint est mort.
Comment s'en protéger
Le bug n'est pas le canal canari. Le problème, c'est qu'un en-tête décide de la configuration qu'un appelant reçoit.
- Déduisez les droits de la session authentifiée ou d'une attestation de build signée, jamais d'un en-tête auto-déclaré.
- Gardez la configuration de build interne sur un endpoint séparé derrière une véritable autorisation plutôt que comme une valeur dans la même forme de réponse.
- Ne mettez aucun identifiant dans une configuration livrée au client. Tout ce qui est envoyé à un appareil est public. Proxifiez plutôt l'appel de dispatch côté serveur.
- Recherchez les préfixes d'identifiants actifs dans les réponses en CI. Une chaîne
pp_live_dans une charge utile accessible au client doit faire échouer le build. - Évitez de divulguer les noms de variantes dans les réponses publiques, et traitez une liste dans un message d'erreur comme une décision de conception plutôt que comme un accident.