概要
本記事では架空のブログサービスを例に、下記のようなアクセス制御(認可)の欠陥を発見するためのテストを作る流れを説明する。
アクセス制御の欠陥
- ログインしてないのに機能を使えてしまった
- 一般ユーザが管理機能を使えてしまった
- 他のユーザの秘密情報を閲覧・変更できてしまった
テストを作るまでの流れ
- ユースケースをもとにロール、リソース、操作を列挙する
- アクセス制御マトリクスを作る
- テストを設計する
ユースケースからユーザ・ロール、リソース、操作を抽出
アクセス制御をテストするには、まず「誰が」「何を」「どう」できる(許可)・できない(不許可)を明確にする必要がある。
- 誰が：ユーザ・ロール
- 何を：リソース
- どう：操作
これらはユースケースやユーザーストーリーから抜き出せる。ブログサービスには次のようなユースケースがあるとすると、
- 登録済みユーザは、自己紹介を作成できる
- 登録済みユーザは、記事を投稿・更新・削除できる
- 登録済みユーザは、記事にコメントできる
- 記事とコメントはだれでも参照できる
- サービス管理者は不適切なプロフィールを変更できる
- サービス管理者は不適切な記事・コメントを削除できる
下記のユーザ・ロール、リソース、操作が列挙できる。
- ユーザ・ロール
- 匿名ユーザ（だれでも）
- 登録済みユーザ
- サービス管理者
- リソース
- プロフィール
- 記事
- コメント
- 操作
- 投稿（作成）
- 参照
- 更新
- 削除
ここで抽出した ユーザ・ロール、リソース、操作 を組み合わせて、できる・できないを明確にしていく。
アクセス制御マトリクスを作る
アクセス制御マトリクスは、誰が(ユーザ・ロール)、何に（リソース）、何をできるか（操作）を表で表したもの。subject-object-activity matrix と呼ぶこともある。
アクセス制御マトリクスを作るには、列にユーザ・ロール、行にリソース、セルに可能な操作を書く。（行列は逆でも良い）
表1：アクセス制御マトリクスの例
表1はできることは明確だが、できないことが暗黙のままである。そこで操作をヘッダに入れてセルを○×にすると、できること・できないことがより明確になる。
表2：操作をヘッダに入れたアクセス制御マトリクス
表2にはまだ曖昧さ（※2）が残っている。これはロールとリソースを具体的なユーザに分解すると排除できる。
表3：ロールをユーザに分解したアクセス制御マトリクス
このような曖昧さが少ないアクセス制御マトリクスができれば、テストケースは容易に作れるようになる。
テスト手法
アクセス制御マトリクスを使ってできるテスト手法を3つ挙げる。
アクセス制御ルールのレビュー
アクセス制御マトリクスと要件との一貫性を確認する。
例えば、自分の記事に書かれた他人のコメントは消せなくていいんだっけ？のようなユースケースの列挙漏れ（または設計ミス）を発見できるかもしれない。
コードインスペクション
マトリクスに従ったアクセス制御(認可)を実装できているかをレビューする。コードインスペクションで検出できる欠陥は動的テストでも検出できるが、コードインスペクションのほうが早期に実行できるという利点がある。
マトリクスのセル1つ毎にコードを追いかけても良いし、下記のような観点でレビューすることもできる。
| 観点 | 説明 | 欠陥の例 |
|---|---|---|
| 縦方向の権限昇格 | ロールに基づいたアクセス制御が実装されていること | 登録済みユーザが管理者機能を使えてしまう |
| 横方向の権限昇格 | ユーザに基づいたアクセス制御が実装されていること | 登録済みユーザAがBのプロフィールを変更できでしまう |
| アクセス制御の回避 | すべてのアクセスはアクセス制御ロジックを経由すること | あるリソースへの（またはあるロールからの）アクセスはアクセス制御を経由しない |
| 表4：アクセス制御に関するコードレビューの観点 | ||
 |
||
| 図1：縦(Vertical)と横(Horizontal)の権限昇格 |
Web(API)テスト
図3のアクセス制御マトリクスからテストケース一覧を作る。1つのセルが1つのテストケースになる。すべてのテストを実行することでアクセス制御の妥当性を検証できる。
表4：アクセス制御マトリクスをもとに作成したテストケース一覧
もしテスト対象が API であれば、ログインユーザは Authorization ヘッダ、リソースは URI、操作は HTTP メソッド、のようになる。
表5：アクセス制御マトリクスをもとに作成したテストケース一覧(API版)
Next Step
アクセス制御マトリクスに基づいたテストを実行することで、アプリケーションに実装したアクセス制御とそのルールの妥当性を検証できるようになった。ただしこのテストではWebアプリケーションを経由しないアクセスは検証できない点に注意。
例えばAWSにデプロイしたWebアプリケーションをテストする場合、下記の赤線の経路は検証される。
図2：Webアプリケーションの構成例（構成に深い意味はない）
しかし次のような攻撃経路を想定したセキュリティの検証にはならない。
図3：Webアプリケーションを経由しないリソースへのアクセス
また、上図以外に下記のような攻撃経路も考えられる。
- キャッシュ (CDN) からの情報漏洩
- 不正ログインされたリモート管理サービス経由での情報改ざん・漏洩
- エラーログからの情報漏洩
このようなWebアプリケーションを経由しないリソースへのアクセスの制御は、別のテストで検証する必要がある。
その他、 CWE を参照して認可に関するよくあるエラーも把握しておくとよい。⇒ CWE CATEGORY: Authorization Errors
まとめ
アクセス制御マトリクスをもとにテストを作成する流れを紹介した。
- ユースケースを列挙する
- ユースケースからユーザ・ロール、リソース、操作を抽出
- アクセス制御マトリクスを作る
- テストを設計する（レビュー、Web・APIテスト）
ただしこのテストでは Web アプリケーションを経由しないアクセスの欠陥は検出できない点に注意。
補足
アクセス制御マトリクスはテストじゃなくて設計のフェーズで作るものでは？⇒そのとおり。