Shikata Ga Nai

Private? There is no such things.

安全でない直接オブジェクト参照のテスト方法について翻訳してみた

Hello there, ('ω')ノ

 

概要

安全でない直接オブジェクト参照は、アプリケーションがユーザ提供の入力に基づいてオブジェクトへの直接アクセスを提供するときに発生します。

この脆弱性の結果として、攻撃者は認証をバイパスし、データベースレコードやファイルなどのシステム内のリソースに直接アクセスできます。

安全でない直接オブジェクト参照により、攻撃者は、オブジェクトを直接指すために使用されるパラメータの値を変更することにより、認証をバイパスし、リソースに直接アクセスできます。

このようなリソースには、他のユーザに属するデータベースエントリ、システム内のファイルなどがあります。

これは、アプリケーションがユーザ指定の入力を受け取り、それを使用して十分な承認チェックを実行せずにオブジェクトを取得するために発生します。

 

テスト方法

この脆弱性をテストするには、まず、ユーザ入力を使用してオブジェクトを直接参照するアプリケーション内のすべての場所をマップする必要があります。

 

たとえば、ユーザ入力を使用して

 データベースカラム

 ファイル

 アプリケーションページ

などにアクセスする場所など。

 

次に、オブジェクトの参照に使用されるパラメータの値を変更し、他のユーザに属するオブジェクトを取得できるか、それとも認証をバイパスできるかを評価します。

直接オブジェクト参照をテストする最良の方法は、少なくとも2人(多くの場合)のユーザに、異なる所有オブジェクトと関数をカバーさせることです。

たとえば、それぞれが異なるオブジェクト(購入情報、プライベートメッセージなど)へのアクセス権を持つ2人のユーザと、(関連する場合)異なる権限を持つユーザ(管理者ユーザなど)が、アプリケーション機能への直接参照があるかどうかを確認します。

複数のユーザがいることにより、他のユーザに属するオブジェクトへのアクセスを試みることができるため、異なるオブジェクト名を推測する際に貴重なテスト時間を節約できます。

以下は、この脆弱性のいくつかの典型的なシナリオと、それぞれについてテストする方法です。

 

パラメータの値を直接使用してデータベースレコードを取得する

サンプルリクエスト:

http://foo.bar/somepage?invoice=12345

 

この場合、invoiceパラメータの値は、データベースの請求書テーブルのインデックスとして使用されます。

アプリケーションはこのパラメータの値を受け取り、データベースへのクエリで使用します。

次に、アプリケーションは請求書情報をユーザに返します。

invoiceの値はクエリに直接入力されるため、パラメータの値を変更することにより、請求書が属するユーザに関係なく、任意の請求書オブジェクトを取得できます。

このケースをテストするには、テスタは別のテストユーザに属する請求書の識別子を取得し(アプリケーションビジネスロジックごとにこの情報を表示することを想定していないことを確認)、承認なしでオブジェクトにアクセスできるかどうかを確認します。

 

パラメータの値は、システムで操作を実行するために直接使用されます

サンプルリクエスト:

http://foo.bar/changepassword?user=someuser

 

この場合、userパラメータの値を使用して、パスワードを変更する必要があるユーザをアプリケーションに通知します。

多くの場合、このステップはウィザードの一部または複数ステップの操作になります。

最初のステップで、アプリケーションはどのユーザのパスワードを変更するかを示す要求を受け取り、次のステップでユーザは新しいパスワードを(現在のパスワードを要求せずに)提供します。

userパラメータは、パスワード変更操作を実行するユーザのオブジェクトを直接参照するために使用されます。

この場合をテストするには、テスタは現在ログインしているユーザ名とは異なるユーザ名を入力して、別のユーザのパスワードを変更できるかどうかを確認する必要があります。

 

パラメータの値を直接使用してファイルシステムリソースを取得する

サンプルリクエスト:

http://foo.bar/showImage?img=img00011

 

この場合、fileパラメータの値は、ユーザが取得しようとしているファイルをアプリケーションに通知するために使用されます。

別のファイルの名前または識別子(たとえば、file = image00012.jpg)を提供することにより、攻撃者は他のユーザに属するオブジェクトを取得することができます。

この場合をテストするには、ユーザがアクセスできないはずの参照を取得し、それをファイルパラメーターの値として使用してアクセスを試みる必要があります。

注:この脆弱性は、ディレクトリ/パストラバーサルの脆弱性と組み合わせて悪用されることがよくあります。

 

パラメータの値は、アプリケーション機能にアクセスするために直接使用されます

サンプルリクエスト:
http://foo.bar/accessPage?menuitem=12

 

この場合、menuitemパラメータの値を使用して、ユーザがアクセスしようとしているメニュー項目(つまり、アプリケーションの機能)をアプリケーションに通知します。

ユーザが制限されているため、メニューアイテム1、2、3へのアクセスにのみリンクが利用できると想定します。

menuitemパラメータの値を変更することで、認証をバイパスし、追加のアプリケーション機能にアクセスできます。

この場合をテストするために、メニュー項目を参照してアプリケーションの機能が決定される場所を特定し、特定のテストユーザがアクセスできるメニュー項目の値をマップしてから、他のメニュー項目を試行します。

 

上記の例では、単一のパラメーターの変更で十分です。

ただし、オブジェクト参照が複数のパラメーターに分割されることがあり、それに応じてテストを調整する必要があります。

 

Best regards, (^^ゞ