最新の OWASP トップ 10 リリース（2017 リリース候補が拒否されているため 2013 年からのも のです！）の 7 番目のエントリは「機能レベルアクセス制御の欠落」で、これは基本的に特権 昇格（Privilege Escalation）の問題につながります。この一般的な脆弱性は、下記のような 「私 は強制アクセスに対して脆弱でしょうか？」という質問に関連してい ます。
「アプリケーションが機能レベルアクセスを適切に制限できなかったかどうかを調べる最善の 方法は、すべての アプリケーション機能を検証することです…」
「すべての」という言葉はもともと太字で書かれており、その背景にはちゃんとした理由があり ます。多くの場合、アプリケーションは、「ほとんど」ではなくすべてのアプリケーション機能に対 して、機能レベルアクセス制御を実装します。これは、特定の機能を実行するために、従来の コードに依然として依存している大規模なアプリケーションに特に当てはまります。Web アプリ ケーションのペネトレーション（侵入）テスト中にすべての可能性のあるケースをテストすること は時に非常に時間がかかり、容易に巨大な数になり、そしてもちろん人為的エラーの対象とな ります。
このブログ記事では、特権昇格の問題を特定するのに非常に役立つツールを紹介したいと思 います。
まず基礎から始めましょう。このブログを読んでいるということは、実質的にユーザーの分離が 遅れている、垂直および水平の権限昇格について既にご存知かもしれません。しかし、完全 性を期すために、それらが何であるかを簡単に説明しましょう。
垂直権限昇格
垂直権限昇格は、より低い特権ユーザーが、より高い特権ユーザーにしかアクセスできないデ ータにアクセスまたは変更することを可能にする、一種の欠陥です。
アプリケーション UI が異なるユーザーのロール（役割）に対して異なるオプションを表示するこ とがよくありますが、アプリケーション機能レベルではサーバー側で承認を実行しません。たと えば、通常のユーザーには URL http://app/admin/user_list を指す UI パーツは表示されませ ん。 しかし、ユーザーがこの URL をブラウザのアドレスバーに直接入力するか、他のツール を使用してそのような要求を送信すると、アプリケーションは不正なコンテンツで誤って応答し ます。
水平権限昇格
水平権限昇格も同様の問題です。2 つのユーザーロールの代わりに、同じロールと権限を持 つ 2 人のユーザーがいます。この問題が存在する場合、ユーザーは同じレベルの権限を持つ 他のユーザーの個人データにクロスアクセスできます。垂直エスカレーションと同様に、（A 社 の）「User1」には「A 社」のユーザーのみが使用できるドキュメントのリストが表示されるとしま す。そのリストは URL http://app/documents/list?companyId=A で利用可能であり、リストの 各要素は URL http://app/documents?docId=NNN を指しています。
明らかに「B 社」の「User2」には、UI（http://app/documents/list?companyId=B）を介して URL にナビゲートしながら、異なる文書のリストが表示されますが、もし User2（「B 社」の）が次の URL を直接要求するとどうなるでしょうか？
- http://app/documents/list?companyId=A, or
- http://app/documents?docId=NNN, where NNN is an ID of a document belonging to Company A?
アプリケーションが要求されたコンテンツで正常に応答する場合は、権限の昇格の具体例であ る「セキュアでない直接オブジェクト参照」の問題があります。
特権エスカレーションのテスト
特権エスカレーションのテストでは、通常、手動によるアプローチが必要です。これは、この脆 弱性がコンテキストに依存する傾向があるためです。1 つのユーザーロールまたはユーザー だけが利用可能で、他のユーザーロールまたはユーザーは利用できないと期待されるものを 認識できるようにテストソフトウェアをプログラムすることは難しいです。
Burp ツールの 1 つは、水平方向の昇格を発見する場合に特に便利です。Burp Intruder は、 さまざまなリソースを列挙し、その処理方法を大幅に制御できます。垂直権限の昇格について は、アプリケーションに送信するリクエストの数は、テストされた URL とユーザーのロールの数 に正比例します。より正確には、少なくともこれらの数の掛け算となります。よくあることです が、Web アプリケーション内の承認機能が、すべてではなく、「ほとんど」すべてのアプリケーシ ョン機能に対して適切に実装されているという場合には、包括的なテストはこれらの要求をす べてカバーする必要があります。
さらに、すべての特権アプリケーション機能が何らかの非特権ロールとしてテストされている場 合、他の非特権ロールとして再度それらのすべてを行うことが賢明です。たとえば、アプリケー ションに 3 つのロール（管理者、編集者、閲覧者）があり、すべての管理者のアプリケーション 機能が閲覧者のセッションでテストされている場合、編集者ユーザーとしても全てのテストを再度通すことをお勧めします。特殊なツールが手元にない場合、この種のテストは簡単にはいき ませんが、そこがまさに Burplay が役に立つ場面となります。
Burplay
Burplay は Burp の拡張で、さまざまな変更を加えながら任意の数の要求を再生できます。
現在 Burplay は下記に対する追加、変更、または削除をサポートしています：
- Cookies
- Request ヘッダー
- GET パラメータ
- POST パラメータ
さらに、セッションを定義できるため、他の特定のユーザーとして要求を簡単にリプレイ可能で す。
たとえば、アプリケーションがセッション Cookie を使用してユーザーのセッションを追跡する場 合は、次の操作を実行できます。
- Burp によってプロキシされているブラウザで、高特権ユーザーとしてアプリケーションにロ グインし、テスト対象のすべての URL を参照します。
- Burp Proxy の履歴またはターゲットサイトマップで、興味のあるすべてのリクエストを選択 し、「リプレイに送信（Send to Replay）」を選びます。
それらは「リプレイ（REPLAY）」タブに表示されます：
- 低特権ユーザーとしてアプリケーションにログインします。
- 低特権ユーザー用のアプリケーションによって発行された Cookie に基づいて Burplay セッ ションを定義します。
セッションは、Burp 内の任意の要求または応答ビューで Cookie 名と値を選択することで定義 することが可能です。
5. リプレイタブの変更として新しく定義されたセッションを「適用（Apply）」します。
- 6. 「リプレイ（REPLAY！）」ボタンをクリックしてテストを開始します。
Burplay の UI の右側には、すべてのリプレイと元のリクエストとレスポンスのセットを示すタブ があります。現在、リプレイタブのマニュアル検査は、問題を特定する唯一の方法です。
結論
特権昇格は、包括的なテストが必要な難題です。Burplay は、アプリケーション内の脆弱な領 域をすべて特定し、時間を大幅に節約、そしてマニュアル作業のテストによる潜在的な過ちを 無くす助けとなります。
Burplay の将来バージョンでサポートされる応答に対する自動比較機能を今後紹介する予定 ですので、お待ちください！
Burplay は下記から入手してください。
https://github.com/SpiderLabs/burplay
参考文献
- Burplay - https://github.com/SpiderLabs/burplay
- OWASP Top 10 2013 - https://www.owasp.org/images/f/f8/OWASP_Top_10_-_2013.pdf
- Burp Suite - https://portswigger.net/burp/
- Burp Intruder - https://portswigger.net/burp/help/intruder_using.html