Autorisation de niveau de fonction brisée

Qu'est-ce que Autorisation de niveau de fonction brisée?

Une API confirme qu'un appelant est connecté, puis exécute la fonction demandée, sans vérifier que son rôle peut l'invoquer. Les contrôles privilégiés sont masqués dans l'interface tandis que les points de terminaison eux-mêmes n'effectuent aucune vérification de rôle, de sorte que tout jeton valide les atteint. Vous utiliserez un jeton d'analyste honnête en lecture seule pour extraire une liste complète de clients et mettre en file d'attente un paiement important, chaque demande répond à 200. Ensuite, vous expédiez une garde authorize('admin') au niveau du routeur renvoyant 403, de sorte que la surface d'administration est refusée par défaut et les nouvelles routes héritent du contrôle.

Ce que vous apprendrez dans Autorisation de niveau de fonction brisée

• Reconnaître l'autorisation rompue au niveau de la fonction : une session valide atteignant une fonction privilégiée car le point de terminaison vérifie qui appelle mais pas si son rôle peut l'appeler
• Distinguez-le d'une autorisation au niveau de l'objet brisée (modification d'un identifiant d'objet) et d'une élévation de privilèges forgée par un jeton (falsification de vos propres informations d'identification) ; ici, le jeton est honnête et à faible privilège et la vérification du fonctionnement est manquante
• Comprenez que masquer un contrôle d'administration dans l'interface utilisateur ou omettre une route dans la documentation n'est pas un contrôle d'accès, car les clients appellent directement l'API et le point de terminaison répond toujours
• Appliquez le correctif : appliquez l'autorisation côté serveur sur chaque fonction privilégiée, prenez le rôle de l'appelant de la session authentifiée plutôt que de la demande, et préférez une protection de refus par défaut à la limite du routeur afin que les nouvelles routes héritent de la vérification.
• Auditez chaque point de terminaison administrateur, interne et réservé au personnel pour une vérification de rôle manquant, en particulier lorsque les fonctions privilégiées et ordinaires partagent une API authentifiée.

Autorisation de niveau de fonction brisée — Étapes de la formation

1. Un siège en lecture seule

   Fennmark gère une plate-forme de paiement et distribue des comptes de développeur en libre-service à toute personne qui s'inscrit. Bob en a pris un, avec une identité jetable. Son siège est celui d'un analyste : en lecture seule, à l'échelle du bac à sable, rien de sensible. Il ouvre la console développeur pour se repérer sur ce qu'est son compte et ce que propose l'API.

2. Fonctions d'administration, bien en vue

   Le siège de Bob est en lecture seule, donc les contrôles d'administration lui sont cachés dans l'interface. Cependant, la référence de l'API n'est pas cachée et elle répertorie toutes les fonctions réservées au personnel, juste à côté de celles qu'il est autorisé à appeler.

3. Ce que dit le jeton

   Avant de toucher à quoi que ce soit de privilégié, Bob vérifie l'identité de son propre jeton. Il pointe le testeur d'API vers le point de terminaison du compte et envoie son jeton de session dans un en-tête d'autorisation, de la même manière que l'application.

4. Un analyste honnête

   Le serveur confirme exactement ce à quoi Bob s'attendait. Son gage est authentique et il dit clairement ce qu'il est.

5. Appeler une fonction d'administration

   Bob conserve la même demande et le même jeton en lecture seule, et modifie uniquement la ressource dans l'URL en une fonction dont la référence est marquée réservée au personnel : la liste complète des clients. Si l'API vérifie uniquement que sa session est valide et ne vérifie jamais son rôle, elle répondra.

6. Toute la liste, à un analyste

   La fonction admin a répondu. Le jeton sandbox en lecture seule de Bob vient d'extraire les enregistrements clients de la plateforme.

7. Déplacer l'argent

   Lire des données est une chose. Bob appelle maintenant une fonction qui change d'état : le point final de décaissement qui met en file d'attente un paiement. Il l'envoie avec le même jeton d'analyste et pointe la destination vers un compte qu'il contrôle.

8. Un paiement, mis en file d'attente par un compte sandbox

   La fonction de transfert d’argent fonctionnait également. Pas d'administrateur, pas d'approbation, pas d'informations d'identification spéciales.

9. Contrôle des connaissances

   Vous venez de regarder un compte en lecture seule lire la liste des clients et mettre un paiement en file d'attente. Verrouillez pourquoi.

10. L'alerte débarque

    Vous possédez l'API back-office de Fennmark. Du jour au lendemain, la surveillance a signalé un compte de développeur en libre-service appelant des points de terminaison réservés au personnel. Les opérations de sécurité vous ont envoyé les détails par e-mail.