AIを活用したAuthZレビュー：Ory Kratosにおける権限境界の読み解き方
AIはバグを見つけるのは苦手だが、疑念を生み出すことには長けている。
セキュリティにおいて、AIが最も安価に行えることは、誤検知の洪水を作り出すことだ。これが、バグバウンティプログラムがルールを一時停止したり、厳格化したりしている理由である。
私はAIを異なる方法で活用している。自身のAuthZ Smell Catalogに基づき、AIに仮説を過剰なほど生成させる。その後、私が困難な作業を行う。私の仕事は、それらの仮説を「却下（kill）」することだ。
成功したレビューとは、バグのリストではない。テストに失敗したアイデアの「却下リスト（kill table）」である。
私はOry Kratosのソースコードをレビューした。Kratosはアイデンティティとユーザー管理を担う。複数のアイデンティティや公開APIを使用するため、非常にリスクの高い領域である。
私は5つの仮説を検証した：
- H1: Admin APIにコードレベルでの認可実装がない。
- H2: アイデンティティ間、またはテナント間でのデータ漏洩。
- H3: リカバリフローにおけるトークンの再利用。
- H4: 設定フローにおけるアイデンティティの混同。
- H5: リクエストペイロードによるテナントの割り当て。
結果：
- H1: 却下。認可はコードのハンドラではなく、ネットワーク境界で行われている。これは設計通りの挙動である。
- H2: 却下。中央のデータアクセス層が、テナントIDに基づいてすべてのクエリをフィルタリングしている。ユーザーがこれをバイパスすることはできない。
- H3: 却下。トークンは単回利用かつ有効期限付きである。
- H4: 却下。フローはユーザー入力ではなく、セッションに紐付けられている。
- H5: 却下。テナントIDはリクエストボディからではなく、システムコンテキストから取得される。
5つの仮説を投入し、発見された脆弱性はゼロだった。これが成功したレビューである。
セキュリティ業務における2つの教訓：
デプロイ層のセキュリティは、セキュリティが欠如しているように見えることがある。ガードがネットワークレベルに存在する場合、コードは無防備に見える。アーキテクチャを確認するまでは、報告してはならない。
チョークポイントを見つけること。システムがデータ層で境界を強制している場合、個々のハンドラにチェックは不要である。「このハンドラは権限をチェックしているか？」と問うのではなく、「チョークポイントを通らずにデータに到達できる者はいるか？」と問うべきである。
AIを使って候補を却下せよ。生き残ったものを検証するために人間を使え。価値は却下することにある。
Optional learning community: https://t.me/GyaanSetuAi