XML Web サービスをハッカーから守るには (第 2 部)

Matt Powell
Microsoft Corporation

2001 年 9 月 19 日
日本語版最終更新日 2001 年 11 月 26 日

第 1 部では、各種の攻撃、およびこれらの攻撃を防ぐためにできることを構成の観点から説明しました。第 2 部では、攻撃を防ぐための設計および開発上の問題に焦点を当てます。

その前に、Web サーバーを可能な限り安全にするために Microsoft® が新たに用意したツールを紹介します。IIS Lockdown Tool (英語情報) は、Microsoft Internet Information Server (IIS) に対するハッカーのアクセスを可能な限り防ぎます。この Lockdown Tool には、希望の設定を選択できる "詳細" オプションがあります。また、行った変更が意図したものでない場合に使用できる "変更のロールバック" オプションも用意されています。一度試してみる価値はあります。

もう 1 つの重要なツールは、IIS 5.0 Hotfix Checking Tool (英語情報) です。このツールは、使用可能なすべてのセキュリティパッチに関して Microsoft が定期的に更新して発行している XML ドキュメントを照会し、それをローカルマシンにインストールされているものと比較して差異をレポートします。このツールを使用すると、単一の Web サーバーや大規模な Web ファームに対するセキュリティパッチの管理作業が大変容易になります。

設計上の問題

Web サービスを設計する場合は、セキュリティ上の問題点や攻撃のリスクを軽減する方法を慎重に考える必要があります。攻撃防止策に関連する要因については、多くの場合、そのほとんどを設計時に明らかにすることができます。この時点で、認証の実行方法や返すエラーの種類などの問題点を検討します。

セキュリティ上のニーズを判断する

XML Web サービスの設計段階の初期において、必要なセキュリティレベルを決定する必要があります。認証をまったく必要としない XML Web サービスもあれば、サービスの対象ユーザーを決定するために厳しい要件があるものもあります。XML Web サービスによって送受信されるデータに一定のプライバシーレベルを定義する必要があります。また、XML Web サービスのユーザーが、使用履歴に記録されているサービスを要求しなかったと主張した場合、人件費、処理能力、または法的費用の点で発生するコストについても考える必要があります。

最初に、認証について検討します。認証の種類によっては、より攻撃を受けやすいものがあります。下位レベルでは、"HTTP 基本認証" を使用した場合、ネットワーク上でパケットを参照できるユーザーは、その気になれば別のユーザーのユーザー名およびパスワードを見ることができます。インターネット経由で要求を送信している場合は、自分のパケットに対する参照をどのユーザーに許可するのか制御できません。認証における上位レベルでは、SSL クライアント証明書を使用した認証の実行を考えることができます。この認証では、チャネルが暗号化されて悪質なパケット傍受者に対する弱点がなくなります。認証方法の詳細については、Mary Kirtland の「At Your Service」コラムの「認証と承認」を参照してください。

認証時におけるプライバシーの問題をスプーフィングの観点から言及しましたが、ユーザー名やパスワードだけでなく、XML Web サービスとの間でやり取りするデータに関連したプライバシーの問題点も認識しておく必要があります。たとえば、認証されているユーザー用に生成されるセッションキーがあります。ユーザーは、本人確認のためにこのキーを各要求と共に送信します。このキーが暗号化されずに送信された場合は、悪質なパケット傍受者がそのキーを見つけ、それを使って自分の要求を Web サービスに送信する可能性があります。その場合、Web サービスがこのパケット傍受者を正規のユーザーとして認識してしまいます。

もう 1 つのプライバシーの問題点は、Web サービスで送受信される単純なデータです。そのデータは、暗号化を必要とするほど重要なデータでしょうか。SSL の暗号化機能を使用する際の問題点は、Web サービスへの送信および Web サービスからの送信に使用されるチャネル全体を暗号化するためにパフォーマンスが低下することです。要求内の重要な項目だけを暗号化することもできますが、その場合は、暗号化および復号化を行う特別なソフトウェアがクライアント側で必要になります。SSL を使用してチャネル全体を暗号化する利点の 1 つは、現行のほとんどのクライアントのプラットフォームで基本の SSL 通信がサポートされているので、アプリケーションに固有のコードを作成する必要がないことです。

基本的なセキュリティ設計では、否認の概念も考慮に入れる必要があります。つまり、あるユーザーが XML Web サービスを介して行われた処置の承認を拒否する可能性があることを考える必要があります。たとえば、株取引サービスにおいて、あるユーザーが、システムによって売却された株についてその売却を指示しなかったと主張した場合には、そのユーザーは売り注文を否認していることになります。この種の問題に関する考慮が特に必要な XML Web サービスもありますが、サービスで発生する可能性のあるリスクを判断し、自分のシナリオに有効な手段を決定する必要があります。

セキュリティで保護された認証システムを使用することは、当然、この種のリスクを回避する最初のステップです。たとえば、HTTP 基本認証を使用することもできますが、これはセキュリティで保護されていないので、その場合は SSL により暗号化された安全なチャネルを使用してください。セキュリティで保護された認証システムを用意しても、ユーザーがパスワードを空白にしたり簡単に推測できるパスワードを使用する場合は、その価値のほとんどが失われます。強力なパスワードの使用を義務付けることは、この種のクレームを防ぐ重要なステップです。結局のところ、パスワードを危険から守るのは、ユーザーとサービス提供者双方の責任です。

最後に、サービスで発生するイベントを監査していない場合は、セキュリティで保護された認証および強力なパスワードを使用したところで、否認に関してはほとんど意味を持たないことに注意してください。否認される恐れがあるすべてのトランザクションは、ユーザー名、日時、およびトランザクションの詳細を識別できる情報と共にログに記録する必要があります。そうしないと、不一致が発生した場合、サービス側の主張の正当性を裏付けるのに必要な証拠がないことになります。

監査、報告、および監視

監査は、否認のリスクの軽減に重要な役割を負っています。また、そのほかの攻撃の識別にも重要な役割を負っています。たとえば、サービスの異常使用を判断するための監査レコードの統計データがない場合には、サービスが攻撃にさらされているのに気付かない可能性すらあります。サービスへのログオンで辞書攻撃を仕掛けられていることに気付くことができる確証はありますか。ここでは、XML Web サービスを攻撃から守るために監査、報告、および監視に関して考慮すべき点について説明します。

監査の基本となる概念は、発生する各イベントのすべての情報を記録するというものです。しかし、大量のデータが XML Web サービスで送受信される場合は、これは現実的ではありません。監査レコードには、少なくとも、すべての要求の日時および IP アドレスが記録されている必要があります。認証機能を備えた XML Web サービスの場合は、各監査レコードにユーザー名も記録します。サービスが複数のメソッドやメッセージ形式をサポートしている場合は、どれが呼び出されているかを識別する必要があります。さらに、呼び出しの詳細を識別するというニーズを満たすのに十分な情報の記録も必要です。たとえば、XML Web サービスがメソッドを開示する場合は、そのメソッドに渡されるすべてのパラメータをログに記録することもできます。

サイトがハッキングされた場合にトランザクションのロールバックを可能にするなど、そのほかのニーズにも留意する必要があります。また、監査レコードはある種のレポートの良質な情報源としても活用することができます。なお、監査ログはかなり大きくなる可能性があるので、バックアップ計画も考慮に入れて監査の設計を調整する必要があります。

監査とはサービスで発生するすべてのイベントを記録することですが、報告とはシステムの使用状況に関する情報をユーザー、オペレータ、および管理者へ提示することです。報告はサービスの使用状況を観察する手段を提供するので、XML Web サービスを攻撃から守る重要な要素の 1 つです。不可欠な報告の 1 つに、発生したエラーを報告するものがあります。最も重要なのは、XML Web サービスで発生した処理エラーを報告する能力です。同様に、クライアントの悪意を示すようなエラーも報告する必要があります。たとえば、要求内のパラメータの 1 つとして例外的に長い文字列を受信した場合、そのエラーを分かりやすい方法で報告する必要があります。この種のエラーの場合は、アプリケーションイベントログにイベントが記録されるので、適切に監視することができます。イベントログへのイベント記録については、プラットフォーム SDK の「Event Logging」 (英語情報) を参照してください。

サービスで重要なもう 1 つの報告の種類は、サービスの使用状況の要約レポートの生成です。これには 2 つの形式があります。1 つは、使用レベルおよび何らかの異常なパターンの検出に使用できる分析用のグローバルレポートの作成です。正常なレポートを良く理解しておくことが大切です。そうすれば、異常使用が発生した場合にそれを認識できます。もう 1 つは、ユーザー用のレポートの提供です。ユーザーも自身のサービスの使用状況を監視する必要があります。グローバルレポートでは攻撃行為を認識しづらいことがありますが、個人レポートでは個々のユーザーが問題点に即座に気付く場合があります。

XML Web サービスが Internet Information Server (IIS) 上で稼動している場合、基本的に自由に入手できる非常に有用なレポートに触れずに報告について語ることはできません。この有用なレポートは、サービスへの要求を含むすべての受信 HTTP リクエストについて実行される IIS ログです。IIS ログ内の情報を使用することによって、報告機能を強化することができます。　

最後に、監査を実行し、適切な報告手段を取る場合は、報告された問題点を発見するための何らかのメカニズムが確実に用意されている必要があることに注意してください。ここで監視が重要になってきます。

監視はさまざまなレベルで実行できます。もちろん、定期レポートを自ら参照するのも XML Web サービスの使用状況を監視する 1 つの方法ではありますが、報告されたエラーがないかイベントログを確認して、パフォーマンスモニタのログを使用し、Web サーバーのダウンを監視する数あるツールの 1 つを利用する必要があります。パフォーマンスモニタは、攻撃を検出する際に重要になります。幸い、IIS に関連付けられた多数のパフォーマンスカウンタから、問題点を検出するための重要な統計を多数得ることができます。

XML Web サービス用に固有のパフォーマンスカウンタを作成することもできます。固有のパフォーマンスカウンタの作成については、「Performance Monitoring」 (英語情報) を参照してください。異常と認められる要素がある場合は、何が起きているのかを通知できることが大変重要です。異常なイベントが発生した場合にポップアップメッセージ表示するパフォーマンスモニタの警告機能を活用するか、または同等の機能を持つプログラムを実行してください。図 1 に、処理待ちの IIS ISAPI リクエスト数および現在キューに登録されている ASP リクエスト数を監視するパフォーマンスモニタの警告を示します。

図 1. パフォーマンスモニタの警告の作成

結局のところ、問題が発生した場合の対策を講じない限り、不正な行為の監査、報告、および監視は何の役にも立ちません。サービス拒否攻撃は、特定の IP アドレスに対して定義されている場合があります。つまり、そのアドレスからの要求をルーターでフィルタにかける必要があるということです。一方、サービス拒否攻撃やスプーフィング攻撃が XML Web サービスの特定のユーザーに関連付けられている場合もあります。このような問題が発生した場合は、そのユーザーのアカウントを使用不可にする必要があります。Microsoft Active Directory™ で Windows ユーザーアカウントを使用不可にすることができます。または、独自の認証システムを実行している場合は、ユーザーレコードに状態を示すフィールドを追加して、使用不可のアカウントを示すことができるようにします。また、どのような場合にユーザーのアカウントを削除または使用不可にするかを明記した "サービス条件" に XML Web サービスのユーザーが同意していることを確認する必要があります。

インターフェイスを定義する

ほかのアプリケーションと比較して、XML Web サーバーアプリケーションを使用する主な利点の 1 つは、アプリケーションに渡される XML スキーマ全体が十分定義されていることです。これは、アプリケーション設計者および開発者の観点からは XML Web サービスで処理するデータのフォーマットが有効であることがあらかじめ分かっていることを意味します。受信したデータが適切なフォーマットでない場合は、Microsoft SOAP Toolkit 2.0 や .NET Framework などのツールによってその要求が除去されるので、心配する必要はありません。

たとえば、日付入力が構文上有効かどうかを検証する必要はありません。無効な場合、この要求は以前の段階で破棄されるので、これは既に日付入力に有効な XSD フォーマットになっているはずです。構造検証を利用できるように、文字列変数内部の構造を隠さないでください。XML の能力および柔軟性を利用して、送受信するデータを十分に説明します。

サーバーの情報を特定させない

ハッカーがシステムを攻撃する際は、情報を探すことから始めます。たとえば、この Web サイトは Windows 上またはほかのシステム上でホストされているかのか、Active Server Pages を実行しているか、インデックスサーバーはインストールされているか、脆弱性を持つコンポーネントや CGI アプリケーションはインストールされているか、ホストマシンで Microsoft SQL Server が実行されているか、分散 COM (DCOM) 呼び出しをこのサーバーに対して実行できるかどうか、などの情報が考えられます。

攻撃に対して十分に配慮されたサイトであれば、インターネットを利用する優れたユーザーでもこれらの質問に答えることはできないはずです。得ることのできるシステム関連の情報が少ないほど、ハッカーがプラットフォームについて想定することは困難になり、サーバーの問題点を見つけにくくなります。

たとえば、XML Web サービスの URL が "http://www.coldrooster.com/ssf/account.asp" であるということから、ハッカーが何を理解するのか考えてみてください。この URL には拡張子 .asp が付いているので、これが Active Server Pages (ASP) を実行する Windows マシンであると想定することができます。今やハッカーは、Internet Information Server の既定の構成に関する知識を基に、構成が不適切な可能性がある多くの箇所に攻撃を仕掛けるだけの十分な情報を持っています。彼らは、構成方法に関する数多くの適切な仮定に基づいてマシンを攻撃する可能性があります。

では、URL が "http://www.coldrooster.com/ssf/account/" であったらどうでしょうか。この場合、ハッカーは、サーバーで使用されているオペレーティングシステムに関する情報を何も得ることができないので、その構成をまったく想定できません。仮想ディレクトリレベルの要求を特定の ASP ページに割り当てるというのは簡単な構成オプションですが、サーバーの安全性は大幅に向上します。

基本 HTTP プロトコルを熟知している読者は、使用している Web サーバーの種類を明確に示す HTTP ヘッダーが存在することをご存知だと思います。これを利用して、マシンで実行されているオペレーティングシステムを判断するのはより高度で難しい方法ですが、これによって HTTP ヘッダーを削除または置換する ISAPI フィルタを記述することは可能なのです。この方法については、『IIS Programmer's Guide』の「Developing ISAPI Filters」 (英語情報) および「SF_NOTIFY_SEND_RESPONSE notification」 (英語情報) を参照してください。サーバーで使用されているシステムの認識が難しくなるほど、インターネット上を徘徊して特定の種類のマシンを見つけるためのハッカーによるスクリプトでマシンを検出される可能性が低くなります。

ただし、オペレーティングシステムが唯一の弱点というわけではありません。作成した ASP ページがバックエンドに対して SQL クエリを実行し、例外をスローする場合を考えてみます。また、その例外情報がユーザーのブラウザに返される場合はどうでしょうか。この例外情報には、Web サーバーのプラットフォームだけでなく、データベースのプラットフォームの情報も含まれています。その上、ユーザーに実行中の SQL クエリについての知識を与え、フォームの入力内容の変更方法についての情報を提供し、そのユーザーがアクセス権を持たない情報を入手できるようにする可能性があります。

そのほかの COM 例外はどうでしょうか。例外情報をユーザーに返すようにした場合は、ハッカーはサーバーマシンにインストールされている COM コンポーネントを判断することができます。COM オブジェクトがサードパーティ製の DLL である場合、ハッカーはそのコピーを入手して、その脆弱性を徹底的に調べることができます。この方法では、非常に簡単な調査でサーバーに存在する問題点を見つけ出すことができます。

また、COM 例外が引き起こされたという事実を使って、ハッカーが意図的にサーバー処理を滞らせる可能性もあります。ハッカーは、ほとんどの例外コードのパスが十分にテストされておらず、リソースリークなどの原因になることがあるということをを知っています。この種のリークを防ぐには、サーバー上のコードですべての例外を受け止めて、一般的なエラーだけを返すようにする必要があります。XML Web サービスの場合は、プラットフォーム情報をほとんど含まない SOAP Fault を返すようにします。エラーを監査ログのレコードと照合できるようにする ID と共にデータをユーザーに返すことはお勧めしますが、エラーの詳細は、返す SOAP Fault ではなく監査ログに入れてください。アプリケーション設計者は、独自のアプリケーションの SOAP Fault スキーマおよび可能な選択肢を記した簡単な一覧を作成し、一覧内のエラーだけを返すようにすることをお勧めします。XML Web サービスを呼び出すクライアントには SQL クエリの例外の詳細は必要ありません。SOAP Server Fault が発生したことが分かれば十分です。

Microsoft SOAP Toolkit 2.0 を使用している場合は、ISoapError インターフェイスを COM オブジェクトに実装して、一般的なツールキットエラーの代わりに適切な SOAP Fault を返すことができます。これにより、エラー発生時にサーバーで発生したイベントに関する十分な情報が提供されます。ツールキットエラーは、開発時においてデバッグの目的では大変役に立ちますが、稼動サーバーを使用する段階ではまったく役に立ちません。このエラーは、大量の危険な情報をハッカーに提供する可能性があります。

XML Web サービスのユーザーが知る必要があるのは、サービスへ送信およびサービスから送信される SOAP メッセージの形式、およびサービスのエンドポイントの場所だけです。そのほかの情報は、システムを悪用しようとするハッカーにその手段を提供するだけです。ハッカーからの攻撃を防ぐには、プラットフォームの固有情報をユーザーに返すことを制限し、マシン上の余分なコンポーネントを削除します。これには、外部からシステムを識別できる既定の仮想ディレクトリやスクリプトの割り当ても含まれます。

開発上の問題

ハッカーに対するサーバーの脆弱性は、サーバー上で実行されるコードの品質と反比例します。これには、基本のシステム (オペレーティングシステム、Web サーバー、および使用している SOAP ツール) および特定のアプリケーション用に記述されたコードの品質も含まれます。また、アプリケーションとは関係ない場合でも、サーバーで実行されるそのほかのコードの品質も対象になる可能性があります。ただし、開発者の立場からは、制御可能な問題点および高品質なコードを保つための具体策に目を向け、XML Web サービスおよびサーバー上で動作するアプリケーションの脆弱性が増大するのを防ぐ必要があります。

バッファオーバーラン

サーバーに対する最も恐ろしい攻撃は、リモートユーザーが悪意のあるコードを実行し、その結果システムが完全に損なわれるというものです。この種の攻撃の大半は、バッファオーバーフローバグが原因で発生します。このようなバグの代表例に、ある C コード内のローカル変数に固定長が割り当てられていて、そのコードが HTTP リクエストの情報を変数にコピーするものがあります。要求内のデータ長が任意の値を超えないと仮定している場合には、サーバーに対する悪質な要求がその値を超え、割り当てられているバッファサイズ以上のデータが書き込まれる可能性があります。ローカル変数の場合、バッファはスタックに保存されます。スタックには、現在の関数の終了時にその結果が返される先となるコードのアドレスも格納されています。ローカル変数のバッファのサイズ以上の書き込みを行うことにより、ハッカーはリターンアドレスを上書きし、Windows CreateProcess 関数のアドレスなどの任意のアドレスに関数の結果を返すようにすることができます。CreateProcess 関数に渡されるパラメータはスタック上でも機能するので、ハッカーはこれらのパラメータの格納場所を上書きした場合でも、サーバー上にあるアプリケーションを起動することができます。

要求から読み取られるデータに対して何の仮定も立てないことによってこの種の攻撃を防ぎ、バッファ操作コードにバグがないことを確認してください。さらに、C または C++ プログラマーの方は、strcpy、strcat、memcpy、gets、sprintf、scanf、およびこれらの関数の全変種 (lstrcpy、wcscpy、CopyMemory など) に特に注意を払ってください。これらのシナリオでは、長さ変数がプログラムに基づいて頻繁に決定され、固定長のバッファを上書きすることができるので、strncpy 関数およびその他の 'n' 関数にも注意する必要があります。'n' 関数内の長さパラメータは、受信文字列のサイズではなく、出力バッファのサイズに基づいている必要があります。上記の関数を使用する場合は、'n' バージョンを使い、バッファをヒープから動的に割り当て、スタックがオーバーランする可能性を排除してください。また、Microsoft Visual Studio® .NET C コンパイラでは、コードを数多くの一般的なバッファオーバーランの問題から保護する新しい /GS スイッチをサポートしています。

.NET Framework およびマネージコードを利用すると、ほとんどのバッファオーバーフロー問題を解消できます。Microsoft では、.NET Framework の設計時にガベージコレクションの利点および従来のバッファ操作によって発生する可能性がある問題の解消方法に気付き、マネージコードにこのような機能を用意しました。マネージコードとアンマネージコードの相互作用についてはまだ注意する必要がありますが、少なくとも、アプリケーションを適切に保護するための選択肢はあります。

エラーを確認する

呼び出すすべての関数のリターンコードを確認します。Win32® API を呼び出す場合は、呼び出しが問題なく完了したことを確認します。メモリを割り当てる場合は、NULL 値が返されなかったことを確認します。COM 呼び出しを実行する場合は、特に Microsoft Visual Basic® を使って呼び出しを実行する場合は、例外が発生しなかったこと、および "On Error Resume Next" を指定したことを確認します。要求のデータ長と同様に、このような呼び出しの結果に関して仮定を行わないでください。

Win32 セキュリティ関数を呼び出す場合は、さらに注意が必要です。たとえば、ImpersonateLoggedOnUser を呼び出す場合は、リターンコードにエラーがないことを確認する必要があります。リターンコードにエラーがある場合、高度なセキュリティコンテキストをユーザーに提供してしまう可能性があります。これは、Web アプリケーションが IIS 上で "In Process" を実行するように構成されている場合に特に重要です。理由は、ローカルマシン上での制限がほとんどないローカルシステムアカウントとしてコードが実行される可能性があるからです。また、特定のクロスアパートメント COM 呼び出しは、高度な権限を持つスレッド内でも実行できることを認識しておく必要があります。

入力内容をすばやく検証する

XML Web サービスで要求が受信されたときに最初にしなければならないことは、送信されたデータの検証です。スキーマに対する Web サービス記述言語 (WSDL) による検証で多くのエラーを発見できますが、必要なアプリケーションレベルの検証を直ちに実行する必要があります。この検証には、特殊文字、数値の範囲、および文字列の長さなどの確認も含まれます。すべての要求が間違いなく特定のアプリケーションから送信されたと思われる場合でも、それが証明されるまでは、受信データは無効であると考えてください。実際には、XML Web サービスへの要求はあらゆる場所から送信される可能性があります。データに関して行う仮定は、"データが悪質なユーザーから送信されている可能性がある" というものでなければなりません。

パラメータ評価コードをすばやく実行することも重要です。無効な要求は、できる限り迅速に識別を行う必要があります。無効な要求の識別が遅れると、XML Web サービスがサービス拒否攻撃を受ける可能性があります。サーバーで不正な要求の処理に時間がかかる場合は、正常な要求の処理を停止することで簡単に対処できます。時間のかかる操作やリソースを大量に使用する操作は、プライベートなデータと同様にセキュリティによる保護を考える必要があります。時間のかかる SQL クエリを実行しなければならない場合や大きな処理能力が必要な操作がある場合は、まず、その要求が正当であることを確認します。ユーザーが有効なユーザーであることを確認します。要求の認証は、無効なユーザーがサーバーのリソースを使用することを防ぐだけでなく、監査ログを使って不正な使用を追跡してユーザーを特定できるようになります。入力内容を評価する場合は、常にユーザーの資格情報を最初に検証してください。通常の HTTP 認証メカニズムを使用する場合は、コードの呼び出しの前にもユーザー認証が実行されます。

裏口を閉める

プロジェクトの開発段階では、サーバー上での処理を回避する手段を用意することがふさわしい場合があります。たとえば、XML Web サービスが、複数の呼び出しに対応したユーザーを識別するキーを生成したり、これらの呼び出し間である種の状態を維持するのは珍しいことではありません。デバッグの目的では、本物のキーの生成処理を実行せずに、何らかのコードを追加してすべてのキーを 1 つにまとめたキーを受け入れるようにすることは意味があります。ただし、実際のデバッグを目的として特定の確認を回避するメカニズムを用意する場合は、必ずこれらの "裏口" を削除してから XML Web サービスを有効にしてください。

同様に、長い目で見ればサービスのサポートに役立つと思われる場合でも、セキュリティをすり抜けるようなメカニズムは用意しないでください。XML Web サービスがアプリケーションレベルの認証を実行している状況を考えてみてください。ハードコードされた管理者レベルの秘密のユーザー名をコード内に挿入し、管理者アカウントのパスワードを忘れたユーザーにシステムへのアクセスを用意するというのは魅力的な考えです。しかし、ユーザーの 1 人がこの裏口を使用したとたんに秘密が漏洩し、このコードのすべてのユーザーが攻撃を受けやすくなります。

実際には、秘密が漏洩するのは、裏口を最初に正当に使用した時点ですらないかもしれません。裏口のアカウントとパスワードが文字列としてコード内に格納されている場合は、バイナリデータを含む送信ファイルを調べれば、コードに定義されている文字列を簡単に見つけることができます。ハッカーが DLL 内に "SecretAdministrativeUser" のような文字列を見つけた場合は、この文字列がコードへのある種の裏口ではないかと疑い、それを利用しようとします。

最後に、サーバーでの情報収集の一般的な手段として裏口を用意しないでください。繰り返しますが、このようなことは製品のサポート性を向上するために頻繁に行われているものの、多くの場合は逆効果です。システム上には、構成ファイルやソースコードの表示またはダウンロードを可能にするコードを作成しないでください。このようなコードは、サーバーで発生した障害を分析する場合に大変便利ですが、ハッカーがこれを使用して構成ファイルやソースコードにアクセスする可能性があります。ほとんどの場合、ユーザー名とパスワードは構成ファイルに保存されます。また、多くの企業では、知的財産であるソースコードを最も貴重な資産であると見なしています。このような外部からのコードへのアクセスの可能性は、サーバー上にあるアプリケーションのファイルも参照できるようになることも意味すると考えると、リスクはさらに大きくなります。したがって、XML Web サービスのコードにこのような弱点が見当たらない場合でも、サーバー上には弱点を持つほかのアプリケーションが存在する可能性があります。

まとめ

Web システムへの攻撃は、Code Red Worm とその変種によってうんざりするほど行われてきました。幸い、XML Web サービスのリスクレベルを低下する手段を講じることは可能です。潜在的な脆弱性およびその解消方法を正しく認識し、安全な XML Web サービスを作成できるようになることを願っています。