この文書は2016年以降更新されていません
Web サービスのセキュリティに関するチートシート
|
最終改訂日 (yy/mm/dd):2015/08/04 はじめにこの記事では、Web サービスを保護し、Web サービスに関連する攻撃を阻止するためのガイダンスについて重点的に説明します。異なるフレームワーク間で実装に差異があることから、このチートシートは概要レベルのチートシートとして位置付けられている点に注意してください。 トランスポートの機密性トランスポートの機密性では、Web サービスとサーバー間の通信を盗聴攻撃や中間者 (Man-in-the-Middle) 攻撃から保護します。 ルール: 機密性の高い機能、認証されたセッション、または機密データ送信を含む Web サービスとのあらゆる通信、および Web サービス間のあらゆる通信を、適切に構成された TLS によって暗号化する必要があります。これは、メッセージ自体が暗号化されている場合にも推奨されます。なぜなら、TLS では、トラフィックの機密性だけでなく、完全性保護、再生防御、サーバー認証などの多数の利点が提供されるためです。これを適切に行う方法の詳細については、「トランスポート層の保護に関するチートシート」を参照してください。 サーバー認証ルール: TLS を使用して、サービスユーザーに対してサービスプロバイダーを認証する必要があります。サービスユーザーは、サーバー証明書が信頼できるプロバイダーによって発行されており、期限切れにも取り消し状態にもなっておらず、かつサービスのドメイン名に一致していることを確認するとともに、公開鍵に関連付けられた秘密鍵を保有していることをサーバーが (何らかの署名を適切に行うか、または関連する公開鍵で暗号化された何かを適切に復号化することによって) 証明していることを確認しなければなりません。 ユーザー認証ユーザー認証では、サービスに接続しようとするユーザーまたはシステムの ID を確認します。このような認証は、通常、Web サービスのコンテナーの機能です。 ルール: Basic 認証を使用する場合は、通信が TLS 上で行われている必要がありますが、Basic 認証は推奨されません。 ルール: TLS を使用したクライアント証明書認証は、強力な認証形式であり、この認証が推奨されます。 トランスポートのエンコードSOAP エンコードスタイルは、ソフトウェアオブジェクト間でデータを XML 形式に変換し、また元に戻すことを意図したものです。 ルール: クライアントとサーバー間で同じエンコードスタイルを適用します。 メッセージの完全性これは保存データに適用されます。転送中のデータの完全性は、TLS によって容易に確保できます。 公開鍵暗号化を使用した場合、暗号化によって機密性は保証されますが、受信側の公開鍵は公開されているため、完全性は保証されません。同じ理由で、送信側の ID も暗号化では保証されません。 ルール: XML データについては、XML デジタル署名を使用して、送信側の秘密鍵に基づいてメッセージの完全性を確保します。この署名は、受信側が送信側のデジタル証明書 (公開鍵) を使用して検証できます。 メッセージの機密性機密とすべきデータ要素は、ブルートフォース攻撃を阻止できるだけの適切な鍵長を持つ強力な暗号によって暗号化する必要があります。 ルール: 機密データを含むメッセージは、強力な暗号によって暗号化する必要があります。これには、トランスポートの暗号化またはメッセージの暗号化が使用されます。 ルール: 受信後暗号化したまま保存する必要がある機密データを含むメッセージは、トランスポートの暗号化だけでなく、強力な暗号化によって暗号化する必要があります。 認可Web アプリケーションがユーザーを認可するのと同じように、Web サービスは Web サービスクライアントを認可する必要があります。Web サービスは、特定のアクション (概要設定) を、リクエスト対象のデータ (詳細設定) に対して実行する権限を Web サービスクライアントが保有していることを確認する必要があります。 ルール: Web サービスは、対象メソッドへのアクセス許可を保有しているかチェックしてクライアントを認可する必要があります。認証後、Web サービスは、リクエスト元のエンティティの権限をチェックして、リクエスト対象リソースへのアクセス許可を保有しているかどうか確認する必要があります。これはリクエストごとに実行しなければなりません。 ルール: Web サービスアプリケーション内の管理機能にアクセスできるのは Web サービス管理者のみであるようにします。理想的には、管理機能はすべて、その管理対象の Web サービスとは完全に分離されたアプリケーション内に配置すべきです。それによって、このような機密性の高い機能から通常のユーザーを完全に分離します。 スキーマの検証スキーマの検証では、スキーマによって定義された制約と構文を適用します。 ルール: Web サービスは SOAP ペイロードを関連する XML スキーマ定義 (XSD) に基づいて検証する必要があります。 ルール: SOAP Web サービスに対して定義された XSD では、少なくとも、Web サービスとの間でやりとりすることが可能なすべてのパラメーターの最大長と文字セットが定義されていなければなりません。 ルール: SOAP Web サービスに対して定義された XSD では、すべての固定形式のパラメーター (郵便番号、電話番号、リスト値など) の強力な (理想的にはホワイトリスト) 検証パターンが定義されていなければなりません。 コンテンツの検証ルール: あらゆる Web アプリケーションと同様に、Web サービスは、入力を検証してから使用する必要があります。XML 入力のコンテンツ検証には、以下を含める必要があります。
出力エンコードWeb サービスからクライアントに送信される出力は、スクリプトとしてではなくデータとして使用されるようにエンコードされていなければなりません。これは、Web サービスクライアントが出力を使用して直接、または AJAX オブジェクトを使用して間接的に HTML ページをレンダリングする場合に非常に重要になります。 ルール: 出力エンコードのすべてのルールは、「クロスサイトスクリプティング (XSS) 対策チートシート」に従って適用されます。 ウイルス対策SOAP には、SOAP メッセージにファイルおよびドキュメントを添付する機能があります。この機能がハッカーに悪用され、SOAP メッセージにウイルスやマルウェアが添付される可能性があります。 ルール: ウイルススキャンテクノロジを必ずインストールしてなるべくインライン化しておき、添付ファイルをディスクに保存する前に必ずチェックするようにします。 ルール: ウイルススキャンテクノロジが必ず最新のウイルス定義 / ルールによって定期的に更新されるようにします。 メッセージサイズWeb アプリケーションと同様に、Web サービスは、何千ものサイズの大きな SOAP メッセージを自動送信する DoS 攻撃の標的となる可能性があります。それによって、アプリケーションの機能が損なわれ、正当なメッセージへのレスポンスができなくなったり、機能が完全に停止してしまったりすることがあります。 ルール: 適切な上限を設定して、SOAP メッセージサイズを制限します。サイズの上限を大きくする (またはまったく制限しない) と、DoS 攻撃が成功してしまう可能性があります。 可用性メッセージのスループットスループットは、特定の時間内に処理される Web サービスリクエスト数を表します。 ルール: メッセージスループットが最大化されるように構成を最適化して、DoS のような状況に陥るのを防止します。 XML DoS (サービス妨害) 対策XML DoS (サービス妨害) は、Web サービスに対する攻撃の中で、おそらく最も深刻な攻撃です。そのため、Web サービスは次の検証を実行する必要があります。 ルール: 再帰的ペイロードに対する検証 ルール: サイズが大きすぎるペイロードに対する検証 ルール: XML エンティティ展開に対する防御 ルール: 長すぎる要素名に対する検証。SOAP ベースの Web サービスの場合、要素名はその SOAP アクションです。
エンドポイントセキュリティプロファイルルール: Web サービスは、少なくとも、Web サービス相互運用性 (WS-I) 基本プロファイルに準拠している必要があります。 Authors and Primary EditorsGunnar Peterson Other CheatsheetsDeveloper Cheat Sheets (Builder)
Assessment Cheat Sheets (Breaker)
Mobile Cheat Sheets OpSec Cheat Sheets (Defender) Draft Cheat Sheets
|
