【要約】IDOR — ソフトウェアアーキテクチャにおける「無邪気」だが致命的な脆弱性？ [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
バックエンドエンジニアが「認証さえあれば安全である」と誤認し、オブジェクトレベルの認可チェックを怠ることで、深刻な脆弱性が生じている。具体的には以下の問題が発生する。
- ・認証（誰か）と認可（何ができるか）の混同による、権限外アクセス。
- ・URL、Header、Bodyに露出した識別子の無検証な利用。
- ・WAFや自動スキャナーでは検知困難な、構文的に正当なリクエストによる攻撃。
- ・連番IDの使用による、大規模な自動列挙攻撃の標的化。
// Approach
開発者は「クライアントを一切信頼しない」という原則に基づき、多層防御（Defense in Depth）の戦略を採用すべきである。以下のステップで対策を講じる。
- ・データ層：クエリに必ず所有者ID（user_id等）を条件として付加する。
- ・コントローラー層：フレームワークのPolicy機能を用い、入口で認可を行う。
- ・難読化：UUIDやHashidsを使用し、IDの推測による列挙攻撃を遮断する。
- ・自動テスト：権限違いのユーザーによるアクセスが拒否されることを検証する。
// Result
適切な認可設計を導入することで、システム全体のセキュリティ強度が劇的に向上する。具体的には以下の成果が得られる。
- ・水平・垂直権限昇格による、個人情報や機密データの流出を防止する。
- ・アカウント削除等の書き込み型攻撃による、データの破壊を防ぐ。
- ・連番IDの悪用による、大規模な自動列挙攻撃を無効化する。
Senior Engineer Insight
> IDORは構文エラーではなく、設計思想の欠陥である。大規模システムでは、認可ロジックをビジネスロジックから分離し、Repository層やPolicy層で一貫して適用するアーキテクチャが不可欠だ。UUIDによる難読化は補助手段に過ぎず、根本解決にはデータ層での厳格な所有権検証が求められる。これを怠れば、McHireのような大規模なデータ流出を招くリスクがある。