SOAP メッセージ レベルでの暗号化により、真のエンドツーエンドの機密性が保証されます。SOAP メッセージは、HTTPS、HTTP、TCP、SMTP、UDP などの多数のトランスポート プロトコルを介して送信できます。メッセージ レベルの暗号化により、トランスポート プロトコルに関係なくメッセージの機密性が保証されます。Web サービスに共通するシナリオは、サービス間で SOAP メッセージを中継することです。したがって、メッセージ レベルの暗号化は、メッセージの送信者と受信者が中継ポイント間のすべてのトランスポート セキュリティについて心配する必要がないことを意味します。

例 1: Apache Axis2 Rampart クライアントの次の設定では、<items> タグに Encrypt ディレクティブが含まれていないため、受信メッセージの暗号化は要求されていません。

<service>
...
	<parameter name="OutflowSecurity">
		<action>
			<items>Timestamp Signature</items>
			...
		</action>
	</parameter>
</service>

メッセージに署名されていない部分があると、受信者側で変更が検出されることなく、傍受および変更される可能性があります。シグネチャがないと、受信者はメッセージの内容の発信元を暗号で確認できません。

次のクライアント設定は、署名されていないリクエストを送信するように Axis 2 に指示します。

<axisconfig name="AxisJava2.0">
...
	<parameter name="OutflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</axisconfig>

セキュリティ タイムスタンプは、メッセージのセキュリティ データの新しさを示します。攻撃者がメッセージを傍受して後で再送信した場合、タイムスタンプでメッセージが古くなっていることが示されるため、受信者がリプレイ攻撃を拒否できます。オプションで、タイムスタンプに、セキュリティのセマンティクスを有効とする期間を厳しく制限する有効期限属性を含めることができます。

攻撃者がタイムスタンプを改ざんするのを防ぐために、タイムスタンプに署名する必要があります。タイムスタンプに署名がないと、攻撃者が SOAP メッセージを傍受し、タイムスタンプを変更して、受信者に知られずにメッセージを送信する可能性があります。このような状況では、攻撃者が受信者をだまして、悪意のあるメッセージを受け入れるように仕向ける可能性があります。

次の Apache Axis 2 Rampart 設定は、<items> タグから Timestamp ディレクティブを省略するため、クライアントはタイムスタンプを含むリクエストを送信しません。

<axisconfig name="AxisJava2.0">
...
   <parameter name="OutflowSecurity">
      <action>
        <items>Signature Encrypt</items>
...
</axisconfig>

WS-Security は、トランスポート プロトコルに関係なく、エンドツーエンドのメッセージの整合性と機密性を提供する SOAP の拡張機能です。WS-Security が使用されていない場合、メッセージは整合性と機密性をトランスポート セキュリティに依存します。サービスがメッセージを他のサービスにリレーする場合、メッセージはリレー ポイント間で使用される最も弱いトランスポート メカニズムにさらされます。WS-Security は、トランスポート セキュリティへの依存を排除し、メッセージ自体にセキュリティを組み込みます。

Apache Axis 2 設定ファイルに OutflowSecurity パラメーターがない場合は、送信メッセージのセキュリティが有効でないことを意味します。

パスワード タイプとして PasswordText を使用することは、実際のパスワードを平文で送信していることを示すことにつながります。WS-Security UsernameToken プロファイルは、UsernameToken <Password> タグで送信されるテキストが実際のパスワードだけでなく、パスワード派生物を代わりに含めることもできることを示しています。しかし、パスワード派生物ではなく実際のパスワードを送信するのが開発者にとっては一般的です。暗号化されていないパスワードまたはパスワード ハッシュを送信すると、トラフィックの傍受者に資格情報が公開されます。

セキュリティ タイムスタンプは、メッセージの新しさを示します。攻撃者がメッセージを傍受して後で再送信した場合、タイムスタンプでメッセージが古くなっていることが示されるため、受信者がリプレイ攻撃を拒否できます。オプションで、タイムスタンプに、セキュリティのセマンティクスを有効とする期間を厳しく制限する有効期限属性を含めることができます。

攻撃者がタイムスタンプを改ざんするのを防ぐために、タイムスタンプに署名する必要があります。署名されたタイムスタンプがないと、受信者が気づかないまま、攻撃者が SOAP メッセージを傍受し、タイムスタンプを変更し、メッセージを送信する可能性があります。このような状況では、攻撃者が、悪意のあるメッセージを受け入れるように受信者をだます可能性があります。

次のクライアント設定は、署名されていないタイムスタンプを受け入れるように Axis 2 に指示します。

<axisconfig name="AxisJava2.0">
...
	<parameter name="InflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</axisconfig>

セキュリティ タイムスタンプは、メッセージの新しさを示します。攻撃者がメッセージを傍受して後で再送信した場合、タイムスタンプでメッセージが古くなっていることが示されるため、受信者がリプレイ攻撃を拒否できます。オプションで、タイムスタンプに、セキュリティのセマンティクスを有効とする期間を厳しく制限する有効期限属性を含めることができます。

攻撃者がタイムスタンプを改ざんするのを防ぐために、タイムスタンプに署名する必要があります。署名されたタイムスタンプがないと、受信者が気づかないまま、攻撃者が SOAP メッセージを傍受し、タイムスタンプを変更し、メッセージを送信する可能性があります。このような状況では、攻撃者が、悪意のあるメッセージを受け入れるように受信者をだます可能性があります。

次のクライアント設定は、署名されていないタイムスタンプを送信するように Axis 2 に指示します。

<axisconfig name="AxisJava2.0">
...
	<parameter name="OutflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</axisconfig>

暗号化されていないチャネルを介して平文のパスワードを送信すると、SOAP メッセージを盗聴できる攻撃者に資格情報が公開される可能性があります。

例 1: Axis2 クライアントの次の設定では、UsernameToken (パスワード) が使用されています。

<axisconfig name="AxisJava2.0">
...
    <parameter name="OutflowSecurity">
      <action>
        <items>UsernameToken</items>
        <user>bob</user>
        <passwordCallbackClass>org.apache.rampart.samples.PWCBHandler</passwordCallbackClass>
        <passwordType>PasswordText</passwordType>
      </action>
    </parameter>
...
</axisconfig>

Rampart WS-Security モジュールが有効になっていません。WS-Security は、トランスポート プロトコルに関係なく、エンドツーエンドのメッセージの整合性と機密性を提供する SOAP の拡張機能です。WS-Security が使用されていない場合、メッセージは整合性と機密性をトランスポート セキュリティに依存します。サービスがメッセージを他のサービスにリレーする場合、メッセージはリレー ポイント間で使用される最も弱いトランスポート メカニズムにさらされます。WS-Security は、トランスポート セキュリティへの依存を排除し、メッセージ自体にセキュリティを組み込みます。

サーバー設定ファイルで axis.development.system が true に設定されている場合、システムは開発環境として動作します。また、スタック トレースを、システムまたはアプリケーションに関する情報を漏洩する可能性のある SOAP レスポンスで送信します。

axis.disableServiceList が false に設定されている場合に、サーブレット ルートで GET が実行されると、Apache Axis は利用可能なサービスのリストを返します。サービス リストには、一般アクセスが許可されていない機能のリストが含まれている場合があります。

パスワード タイプとして PasswordText を使用することは、実際のパスワードを平文で送信していることを示すことにつながります。WS-Security UsernameToken プロファイルは、UsernameToken <Password> タグで送信されるテキストが、実際のパスワードだけではないことを示しています。代わりに、パスワード派生物も指定できます。しかし、パスワード派生物ではなく実際のパスワードを送信するのが開発者にとっては一般的です。暗号化されていないパスワードまたはパスワード ハッシュを送信すると、トラフィックの傍受者に資格情報が公開されます。

UsernameToken を使用するサービス プロバイダーは、平文で送信されたパスワードを受け入れる場合があります。暗号化されていないチャネルを介して平文のパスワードを送信すると、SOAP メッセージを盗聴できる攻撃者に資格情報が公開される可能性があります。

例 1: Axis サービスプロバイダの次の設定では、UsernameToken が使用されています。

<deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
...
	<parameter name="action" value="UsernameToken"/>
...
</deployment>

パスワード タイプとして PasswordText を使用することは、実際のパスワードを平文で送信していることを示すことにつながります。WS-Security UsernameToken プロファイルは、UsernameToken <Password> タグで送信されるテキストが、実際のパスワードだけではないことを示しています。代わりに、パスワード派生物も指定できます。しかし、パスワード派生物ではなく実際のパスワードを送信するのが開発者にとっては一般的です。暗号化されていないパスワードまたはパスワード ハッシュを送信すると、トラフィックの傍受者に資格情報が公開されます。

暗号化されていないチャネルで平文のパスワードまたはパスワード ハッシュを送信すると、SOAP メッセージを盗聴できる攻撃者に資格情報が公開される可能性があります。

例 1: Axis クライアントの次の設定では、UsernameToken が使用されています。

<deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
...
	<parameter name="action" value="UsernameToken"/>
...
</deployment>

bean を入力する前に bean プロパティ名および値を検証する必要があります。bean の入力機能によって、開発者は bean プロパティまたはネストされたプロパティを設定できます。攻撃者がこの機能を利用して、システム プロパティを上書きし、任意のコードを実行できるようにする class.classLoader のような特殊な bean プロパティにアクセスする可能性があります。

例 1: 次のコードは、プロパティ名または値の適切な検証を行うことなく、ユーザー制御の bean プロパティを設定します。

String prop = request.getParameter('prop');
String value = request.getParameter('value');
HashMap properties = new HashMap();
properties.put(prop, value);
BeanUtils.populate(user, properties);

Apache Ivy の自動依存関係管理システムを使用すると、ユーザーは、特定の依存関係を一覧表示する代わりに、動的リビジョンと呼ばれるバージョン ステータスを指定できます。攻撃者が依存関係リポジトリを侵害したり、ビルド システムをだまして攻撃者の制御下でリポジトリから依存関係をダウンロードさせたりできる場合、侵害された依存関係をサイレントにダウンロードして実行するのにビルド システムが必要とするのは、動的リビジョンの指定子だけです。セキュリティ リスクに加え、動的リビジョンは、コード品質の面でリスクの要素ももたらします。動的リビジョンは、ソフトウェアのセキュリティと安定性を、ソフトウェアが使用する依存関係を開発およびリリースするサードパーティの管理下に置きます。

ビルド時に、Ivy はリポジトリに接続し、リストされたステータスに一致する依存関係を取得しようとします。

Ivy は、次の動的リビジョンの指定子を受け入れます。

- latest.integration: 依存関係モジュールの最新リビジョンを選択します。
- latest.[any status]: 少なくとも指定されたステータスを持つ依存関係モジュールの最新リビジョンを選択します。たとえば、latest.milestone は最新バージョン (マイルストーンまたはリリース) を選択し、latest.release は最新のリリースのみを選択します。
- + で終わるリビジョン: 依存関係モジュールの最新のサブリビジョンを選択します。たとえば、依存関係がリビジョン 1.0.3、1.0.7、および 1.1.2 にある場合、1.0.+ と指定されたリビジョンは 1.0.7 を選択します。
- バージョンの範囲: < や > などの範囲の数学記号を使用して、バージョンの範囲を指定できます。

例 1: 次の設定エントリは、クローバー コンポーネントの最新リリース バージョンを取得するように Ivy に指示します。

<dependencies>
        <dependency org="clover" name="clover"
                    rev="latest.release" conf="build->*"/>
	...

リポジトリが危険にさらされると、攻撃者が動的基準を満たすバージョンをアップロードするだけで、悪意のあるバージョンの依存関係を Ivy にダウンロードさせることができます。

依存関係の管理を支援するためのいくつかのツールが Java の開発環境で利用できるようになっています。Apache Ant および Apache Maven のいずれのビルドシステムにも、依存関係を管理しやすくするために特別に設計された機能が搭載されており、Apache Ivy は明示的に依存関係マネージャとして開発されています。これらのツールの動作は異なりますが、ビルド時にビルドプロセスで指定された外部の依存関係を自動的にダウンロードするという共通の機能を実装しています。この機能により、開発者 B は開発者 A と同じ方法でソフトウェアを簡単にビルドできるようになります。開発者は依存関係情報をビルドファイルに格納するだけで、ソフトウェアをビルドできます。つまり、各開発者およびビルドを担当するエンジニアは、手動で依存関係を管理する作業に付帯する問題に煩わされることなく、一貫性のある方法で依存関係を取得して、コードをコンパイルし、配布できます。次の例では、ビルドプロセスの一環として外部の依存関係を管理するために Ivy、Ant、および Maven がどのように使用されているかを示しています。

開発者は、<get> タスクを使用して Ant ターゲットの外部の依存関係を指定します。このタスクは、対応する URL で指定された依存関係を取得します。このアプローチは、開発者が各外部の依存関係をソフトウェア プロジェクトに含まれるアーティファクトとして文書化するシナリオと機能的には同等ですが、ビルドの実行時に依存関係の取得と組み込みが自動化されるため、より望ましい方法です。

例 1: 以下の Ant build.xml 設定ファイルからの抜粋は、典型的な外部の依存関係への参照を示しています。

<get src="http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
dest="${maven.repo.local}/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
usetimestamp="true" ignoreerrors="true"/>

これらのシステムには、2 つの異なるタイプの攻撃シナリオが影響します。攻撃者は、依存関係をホストしているサーバーを侵害するか、ビルド マシンが使用している DNS サーバーを侵害して、依存関係をホストするサーバーのホスト名のリクエストを、攻撃者が制御するマシンにリダイレクトする可能性があります。どちらのシナリオでも、攻撃者は、侵害されていない他のマシンで実行されているビルドに、悪意のあるバージョンの依存関係を挿入できます。

トロイの木馬の依存関係を提供するために使用される攻撃手段かどうかに関係なく、これらのシナリオには、ビルド システムが悪意のあるバイナリを盲目的に受け入れてビルドに含めるという共通の要素があります。ビルド システムには悪意のあるバイナリを拒否する手段がなく、コード レビューなどの既存のセキュリティ メカニズムは通常、外部の依存関係ではなく内部で開発されたコードに焦点を当てているため、このタイプの攻撃は、高い確率で、開発環境や実運用環境に目立たぬように広がります。

侵害された依存関係が手動のビルド プロセスに組み込まれるリスクはあるものの、自動ビルド システムでは外部ソースから依存関係を取得する傾向があるため、新しい環境でビルド システムを実行すると、そのたびに攻撃者による攻撃のチャンスが増えます。攻撃者は、依存関係が何度も取得される間に、依存関係サーバーまたは DNS サーバーを 1 回侵害するだけで、ビルドが行われているマシンを侵害できます。

依存関係の管理を支援するためのいくつかのツールが Java の開発環境で利用できるようになっています。Apache Ant および Apache Maven のいずれのビルドシステムにも、依存関係を管理しやすくするために特別に設計された機能が搭載されており、Apache Ivy は明示的に依存関係マネージャとして開発されています。これらのツールの動作は異なりますが、ビルド時にビルドプロセスで指定された外部の依存関係を自動的にダウンロードするという共通の機能を実装しています。この機能により、開発者 B は開発者 A と同じ方法でソフトウェアを簡単にビルドできるようになります。開発者は依存関係情報をビルドファイルに格納するだけで、ソフトウェアをビルドできます。つまり、各開発者およびビルドを担当するエンジニアは、手動で依存関係を管理する作業に付帯する問題に煩わされることなく、一貫性のある方法で依存関係を取得して、コードをコンパイルし、配布できます。次の例では、ビルドプロセスの一環として外部の依存関係を管理するために Ivy、Ant、および Maven がどのように使用されているかを示しています。

Ivy では、依存関係を取得する明示的な URL を一覧表示する代わりに、開発者が依存関係の名前とバージョンを指定し、Ivy はその基盤となる設定に基づいて、依存関係を取得するサーバーを識別します。よく使用されるコンポーネントの場合、これによって開発者は依存関係の場所を調査する必要がなくなります。

例 1: 以下の Ivy ivy.xml ファイルからの抜粋は、開発者が複数の外部の依存関係を、その名前とバージョンを使用してどのように指定するかを示しています。

<dependencies>
  <dependency org="javax.servlet"
             name="servletapi"
              rev="2.3" conf="build->*"/>
  <dependency org="javax.jms"
             name="jms"
              rev="1.1" conf="build->*"/>  ...
</dependencies>

これらのシステムには、2 つの異なるタイプの攻撃シナリオが影響します。攻撃者は、依存関係をホストしているサーバーを侵害するか、ビルド マシンが使用している DNS サーバーを侵害して、依存関係をホストするサーバーのホスト名のリクエストを、攻撃者が制御するマシンにリダイレクトする可能性があります。どちらのシナリオでも、攻撃者は、侵害されていない他のマシンで実行されているビルドに、悪意のあるバージョンの依存関係を挿入できます。

トロイの木馬の依存関係を提供するために使用される攻撃手段かどうかに関係なく、これらのシナリオには、ビルド システムが悪意のあるバイナリを盲目的に受け入れてビルドに含めるという共通の要素があります。ビルド システムには悪意のあるバイナリを拒否する手段がなく、コード レビューなどの既存のセキュリティ メカニズムは通常、外部の依存関係ではなく内部で開発されたコードに焦点を当てているため、このタイプの攻撃は、高い確率で、開発環境や実運用環境に目立たぬように広がります。

侵害された依存関係が手動のビルド プロセスに組み込まれるリスクはあるものの、自動ビルド システムでは外部ソースから依存関係を取得する傾向があるため、新しい環境でビルド システムを実行すると、そのたびに攻撃者による攻撃のチャンスが増えます。攻撃者は、依存関係が何度も取得される間に、依存関係サーバーまたは DNS サーバーを 1 回侵害するだけで、ビルドが行われているマシンを侵害できます。

依存関係の管理を支援するためのいくつかのツールが Java の開発環境で利用できるようになっています。Apache Ant および Apache Maven のいずれのビルドシステムにも、依存関係を管理しやすくするために特別に設計された機能が搭載されており、Apache Ivy は明示的に依存関係マネージャとして開発されています。これらのツールの動作は異なりますが、ビルド時にビルドプロセスで指定された外部の依存関係を自動的にダウンロードするという共通の機能を実装しています。この機能により、開発者 B は開発者 A と同じ方法でソフトウェアを簡単にビルドできるようになります。開発者は依存関係情報をビルドファイルに格納するだけで、ソフトウェアをビルドできます。つまり、各開発者およびビルドを担当するエンジニアは、手動で依存関係を管理する作業に付帯する問題に煩わされることなく、一貫性のある方法で依存関係を取得して、コードをコンパイルし、配布できます。次の例では、ビルドプロセスの一環として外部の依存関係を管理するために Ivy、Ant、および Maven がどのように使用されているかを示しています。

Maven では、依存関係を取得する明示的な URL を一覧表示する代わりに、開発者が依存関係の名前とバージョンを指定し、Maven はその基盤となる設定に基づいて、依存関係を取得するサーバーを識別します。よく使用されるコンポーネントの場合、これによって開発者は依存関係の場所を調査する必要がなくなります。

例 1: 以下の Maven pom.xml ファイルからの抜粋は、開発者が複数の外部の依存関係を、その名前とバージョンを使用してどのように指定するかを示しています。

<dependencies>
  <dependency>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <version>1.1</version>
  </dependency>
  <dependency>
    <groupId>javax.jms</groupId>
    <artifactId>jms</artifactId>
    <version>1.1</version>
  </dependency>
  ...
</dependencies>

これらのシステムには、2 つの異なるタイプの攻撃シナリオが影響します。攻撃者は、依存関係をホストしているサーバーを侵害するか、ビルド マシンが使用している DNS サーバーを侵害して、依存関係をホストするサーバーのホスト名のリクエストを、攻撃者が制御するマシンにリダイレクトする可能性があります。どちらのシナリオでも、攻撃者は、侵害されていない他のマシンで実行されているビルドに、悪意のあるバージョンの依存関係を挿入できます。

トロイの木馬の依存関係を提供するために使用される攻撃手段かどうかに関係なく、これらのシナリオには、ビルド システムが悪意のあるバイナリを盲目的に受け入れてビルドに含めるという共通の要素があります。ビルド システムには悪意のあるバイナリを拒否する手段がなく、コード レビューなどの既存のセキュリティ メカニズムは通常、外部の依存関係ではなく内部で開発されたコードに焦点を当てているため、このタイプの攻撃は、高い確率で、開発環境や実運用環境に目立たぬように広がります。

侵害された依存関係が手動のビルド プロセスに組み込まれるリスクはあるものの、自動ビルド システムでは外部ソースから依存関係を取得する傾向があるため、新しい環境でビルド システムを実行すると、そのたびに攻撃者による攻撃のチャンスが増えます。攻撃者は、依存関係が何度も取得される間に、依存関係サーバーまたは DNS サーバーを 1 回侵害するだけで、ビルドが行われているマシンを侵害できます。