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

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

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

<deployment 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:java="http://xml.apache.org/axis/wsdd/providers/java">
...
	<parameter name="action" value="UsernameToken"/>
...
</deployment>

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

例: 次のコードは、プロパティ名または値の適切な検証を行うことなく、ユーザー制御の 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 で指定された依存関係を取得します。このアプローチは、開発者が各外部の依存関係をソフトウェア プロジェクトに含まれるアーティファクトとして文書化するシナリオと機能的には同等ですが、ビルドの実行時に依存関係の取得と組み込みが自動化されるため、より望ましい方法です。

例: 以下の 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 回侵害するだけで、ビルドが行われているマシンを侵害できます。