|
最終改訂日 (yy/mm/dd): 2015/07/18
RESTful Web サービスについて
Web サービスは、コンピューター間の通信に使用される Web テクノロジの実装です。そのため、Web サービスは、アプリケーション間通信、Web 2.0、およびマッシュアップに使用されるとともに、デスクトップアプリケーションおよびモバイルアプリケーションからのサーバーの呼び出しに使用されます。RESTful Web サービス (しばしば単に REST と呼ばれる) は、RESTful デザインパターンに基づく Web サービスの軽量バリアントです。実際のところ、RESTful Web サービスでは、SOAP などの他の Web サービスで複雑なプロトコルが使用されるのとは対照的に、通常の HTTP 呼び出しに似た HTTP リクエストが使用されます。
RESTful Web サービスに関連する主なプロパティ
- リクエスト対象の操作の主要動詞として HTTP メソッド GET、POST、PUT、および DELETE を使用。
- パラメーターの指定方法は標準化されていない:
- パラメーター値、リクエスト本文、またはレスポンス本文での、JSON または XML を使用した構造化パラメーターおよびレスポンス。これらは、コンピューターにとって有用な情報を伝達するために必要です。
- カスタム認証およびセッション管理 (しばしばカスタムセキュリティトークンを使用)。これが必要な理由は、コンピューター間通信ではログインシーケンスを使用できないためです。
- 正式なドキュメントの欠如。 RESTful Web サービスの記述に関する、WADL という標準案が Sun Microsystems によって提出されましたが、正式に採用されることはありませんでした。
RESTful Web サービスのセキュリティテストにおける課題
- アプリケーションの検査では、攻撃対象領域 (その RESTful Web サービスによって使用される URL およびパラメーター構造) は明らかにはなりません。理由は次のとおりです。
- サービスによって公開される利用可能な機能とパラメーターのすべてを使用するアプリケーションはない。
- 使用される機能およびパラメーターは、多くの場合、ページ内のリンクとして用意されているわけではなく、クライアント側コードから動的にアクセスされる。
- クライアントアプリケーションは、Web アプリケーションではないことが多く、アクティブ化リンクの検査ができず、さらには関連コードの検査もできない。
- パラメーターの指定方法に標準はなく、URL の 一部だったりヘッダーで指定されたりする。そのため、ファジングする価値があるパラメーターを判別するのが困難。
- コンピューターインターフェイスとして使用されるため、パラメーターの数が非常に多くなる場合がある。たとえば、1 つの JSON 構造体に何十ものパラメーターが含まれることがある。それぞれのパラメーターに対してファジングテストを行うと、テストの所要時間が大幅に長引きます。
- 独自の認証メカニズムが使われている場合、リバースエンジニアリングが必要となる。一般的なツールは、ログインセッションを追跡できないため、役に立たない。
RESTful Web サービスに対する侵入テストの方法
- ドキュメントを基に、攻撃対象領域を判定します。一定レベルのホワイトボックステストを実施でき、サービスに関する情報を取得できる場合、RESTful 侵入テストをより適切に行える可能性があります。次に挙げるような情報を調べることによって、攻撃対象領域の範囲がより完全なものになります。
-
- 正式なサービス記述。SOAP など、他の種類の Web サービスでは、多くの場合、正式な記述 (通常 WSDL で記述されたもの) が利用可能ですが、REST では正式な記述はめったにありません。とはいえ、WSDL 2.0 または WADL で REST について記述することは可能であり、ときどき使用されています。
- サービスの使用に関する開発者向けガイド。これは、正式な記述に比べると詳細さに欠けますが、一般に広く見られ、また "ブラックボックス" と見なされることもあります。
- アプリケーションのソースまたは設定。dotNet などの多くのフレームワークで、コードではなく設定ファイルから、REST サービスの定義を容易に取得できる場合があります。
- プロキシを使用して完全なリクエストを収集します。これは常に侵入テストの重要なステップですが、REST ベースのアプリケーションでは特に重要です。なぜなら、アプリケーション UI からは実際の攻撃対象領域に関する手がかりがつかめないことがあるためです。注意点として、REST サービスでは GET パラメーターだけでなくその他のものも使用されるため、URL だけでなく完全なリクエストをプロキシで収集できなければなりません。
- 収集されたリクエストを分析して、攻撃対象領域を判定します。
-
- 非標準のパラメーターを探します。
- 通常とは異なる HTTP ヘッダーを探します。これは、多くの場合、ヘッダーベースのパラメーターです。
- 個々の URL セグメントに、複数の URL 間で反復使用されているパターンが含まれていないか調べます。このようなパターンとして、日付、番号、ID のような文字列などがあり、これらはその URL セグメントが URL 埋め込みパラメーターであることを表します。次に例を示します。http://server/srv/2013-10-21/use.php
- 構造化パラメーター値を探します。これは JSON、XML、または非標準の構造体である場合があります。
- URL の最後の要素に拡張子が含まれていない場合、その要素はパラメーターである可能性があります。当該のアプリケーションテクノロジで、通常、拡張子が使用される場合や、前のセグメントに拡張子が含まれている場合は、特にその可能性があります。次に例を示します。http://server/svc/Grid.asmx/GetRelatedListItems
- 変動性が高い URL セグメントを探します。単一の URL セグメントが多くの値を持つ場合、そのセグメントは物理的なディレクトリではなく、パラメーターである可能性があります。たとえば、http://server/src/XXXX/page という URL が繰り返し使用され、XXXX の値が何百もある場合、XXXX はパラメーターである可能性があります。
- 非標準のパラメーターを検証します。
- 場合によっては (すべてに該当するわけではありません)、パラメーターであることが疑われる URL セグメントの値を、無効であると予想される値に設定することによって、それがパス要素であるか、それともパラメーターであるかの判別ができる場合があります。パス要素である場合、Web サーバーは 404 メッセージを返します。パラメーターの無効な値の場合は、アプリケーションレベルのメッセージが返されます。なぜなら、Web サーバーレベルでは、その値は正当な値であるためです。
- 収集されたリクエストを分析して、ファジングテストを最適化します。ファジングテスト対象候補のパラメーターを特定したら、パラメーターごとに収集された値を分析して、次のことについて判定します。
- 有効な値と無効な値。それによって、有効範囲の境界に焦点を絞ったファジングテストを実施できます。たとえば、常に正の整数であることが判明した値に対して "0" を送るなどのテストを行います。
- 現在のユーザーに割り当てられていると推定される範囲を超える値によるファジングテストを可能にするシーケンス。
- 最後に、ファジングテストでは、使用する認証メカニズムをエミュレートすることを忘れないでください。
関連情報
Authors and Primary Editors
Ofer Shezaf - ofer@shezaf.com
Other Cheatsheets
Developer Cheat Sheets (Builder)
Assessment Cheat Sheets (Breaker)
Mobile Cheat Sheets
OpSec Cheat Sheets (Defender)
Draft Cheat Sheets
| 
