Revue d'AuthZ assistée par l'IA : Lecture des limites de permissions dans Ory Kratos

L'IA est mauvaise pour trouver des bugs, mais excellente pour susciter des soupçons.

En sécurité, la chose la moins coûteuse qu'une IA puisse faire est de créer un déluge de faux rapports. C'est pourquoi les programmes de bug bounty suspendent ou durcissent leurs règles.

J'utilise l'IA différemment. Je laisse l'IA générer un surplus d'hypothèses basées sur mon catalogue d'odeurs d'AuthZ. Ensuite, je fais le travail difficile. Mon rôle est de réfuter ces hypothèses.

Une revue réussie n'est pas une liste de bugs. C'est un tableau d'élimination d'idées qui ont échoué au test.

J'ai passé en revue le code source d'Ory Kratos. Kratos gère l'identité et la gestion des utilisateurs. C'est une zone à haut risque car elle utilise de multiples identités et des API publiques.

J'ai testé cinq hypothèses :

  • H1 : L'Admin API n'a pas d'autorisation dans le code.
  • H2 : Fuites de données entre identités ou entre tenants.
  • H3 : Réutilisation de jetons dans les flux de récupération.
  • H4 : Confusion d'identité dans les flux de paramètres.
  • H5 : Attribution de tenant via les payloads de requête.

Les résultats :

  • H1 : ÉLIMINÉE. L'autorisation se situe à la limite du réseau, pas dans le gestionnaire de code. C'est intentionnel.
  • H2 : ÉLIMINÉE. Une couche centrale d'accès aux données filtre toutes les requêtes par ID de tenant. Les utilisateurs ne peuvent pas contourner cela.
  • H3 : ÉLIMINÉE. Les jetons sont à usage unique et limités dans le temps.
  • H4 : ÉLIMINÉE. Les flux sont liés à la session, pas à la saisie de l'utilisateur.
  • H5 : ÉLIMINÉE. Les ID de tenant proviennent du contexte système, pas du corps de la requête.

Cinq hypothèses sont entrées. Zéro résultat n'est ressorti. C'est une revue réussie.

Deux leçons pour votre travail de sécurité :

  1. La sécurité au niveau du déploiement peut ressembler à une absence de sécurité. Si un garde se trouve au niveau du réseau, le code paraîtra nu. Ne signalez rien avant d'avoir vérifié l'architecture.

  2. Trouvez le point de passage obligé. Si un système impose des limites au niveau de la couche de données, les gestionnaires individuels n'ont pas besoin de vérifications. Au lieu de demander « est-ce que ce gestionnaire vérifie les permissions », demandez « est-ce que n'importe qui peut accéder aux données sans passer par le point de passage obligé ? ».

Utilisez l'IA pour rejeter des candidats. Utilisez des humains pour vérifier les survivants. La valeur réside dans le rejet.

Source : https://dev.to/fdjedkdlsspec/ai-assisted-authz-review-reading-permission-boundaries-in-ory-kratos-31cg

Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi