依存関係の管理を支援するためのいくつかのツールが 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 回侵害するだけで、ビルドが行われているマシンを侵害できます。

CakePHP を誤って設定すると、エラー、警告、SQL ステートメント、およびスタックトレースを含むデバッグ情報が公開される場合があります。実運用環境では、デバッグ情報を使用しないでください。

例 1:

    Configure::write('debug', 3);

Configure::write() メソッドへの 2 番目のパラメーターは、デバッグレベルを示しています。数字が大きいほど、ログメッセージが詳細になります。

セッションが開いている時間が長ければ、それだけ、ユーザーアカウントが侵害される機会が長くなります。セッションがアクティブになっていると、攻撃者は、ユーザーのパスワードに Brute-Force 攻撃を仕掛けたり、ユーザーのワイヤレス暗号鍵を解読したり、あるいは開いているブラウザからセッションを乗っ取ったりできるようになる可能性があります。また、セッションタイムアウトを長くしているとメモリが解放されず、大量のセッションが作成される場合に Denial of Service となる場合があります。

例 1: 次の例は、low セッションセキュリティで設定されている CakePHP を示しています。

    Configure::write('Security.level', 'low');

Security.level 設定と Session.timeout 設定を一緒に使用すると、セッションが有効な期間を定義できます。実際のセッションタイムアウト時間は、次の倍数のいずれかを Session.timeout と積算した値と等しくなります。

'high' = x 10
'medium' = x 100
'low' = x 300

平文の証明書を設定ファイルまたはマニフェスト ファイルに保存すると、そのファイルを読み取ることができるすべてのユーザーが、証明書で保護されたリソースにアクセスできるようになります。開発者は、設定にアクセスできる人からアプリケーションを防御できないと考えることがありますが、この考え方は攻撃者の作業を容易にします。適切な証明書管理ガイドラインでは、証明書を平文で保存しないことが求められます。

ClassLoader 操作により、攻撃者は基盤となるアプリケーション サーバー設定にアクセスして変更することができます。Tomcat 8 などの特定のアプリケーション サーバーでは、攻撃者がこれらの設定を微調整して Web シェルをアップロードし、任意のコマンドを実行する可能性があります。

DNS 偽装は、DNS キャッシュ ポイズニングとも呼ばれ、攻撃者が DNS リゾルバーのキャッシュを破壊し、誤った IP アドレスを返すようにする攻撃タイプです。DNS 偽装を使用すると、攻撃者はユーザーに気付かれずに悪意のある Web サイトにリダイレクトできます。Node.js を使用したサーバーサイド JavaScript では、DNS サーバー設定の不適切な処理によりセキュリティ上の脆弱性が生じる可能性があります。

例 1: Node.js アプリケーションでユーザーがカスタム DNS サーバーを指定できるシナリオについて考えてみましょう。この入力が適切に検証およびサニタイズされていない場合、攻撃者は悪意のある DNS サーバーを提供し、DNS 偽装攻撃を実行することができます。

const dns = require('dns');

// User-controlled input for DNS servers
const customDnsServers = from_user_controlled_input;

// Set custom DNS servers
dns.setServers(customDnsServers);

この例では、customDnsServers 変数には、ユーザー制御入力から得られた値が割り当てられます。その後、この入力は dns.setServers(customDnsServers) で DNS サーバーを設定する際に使用されます。攻撃者が悪意のある DNS サーバー アドレスを指定すると、アプリケーションに攻撃者のサーバーを使用してドメイン名を解決するように指示できるため、偽の IP アドレスが返される可能性があります。

Dockerfile が USER を指定していない場合、デフォルトでは Docker コンテナーはスーパー ユーザー権限で実行されます。これらのスーパー ユーザー権限は、コンテナー内で実行されているコードに伝達されます。これは通常、必要以上の権限です。スーパー ユーザー権限で Docker コンテナーを実行すると、攻撃対象領域が広がり、攻撃者による深刻な形式の悪用が可能になるおそれがあります。

Dockerfile では、依存関係とベース イメージを、バージョンの範囲を限定せずに指定できます。攻撃者が、悪意のあるバージョンの依存関係をリポジトリに追加したり、ビルド システムに攻撃者の制御下にあるリポジトリから依存関係をダウンロードするように仕向けたりできる場合、Docker が特定のバージョンの依存関係なしで設定されていると、Docker は侵害された依存関係をサイレントにダウンロードして実行します。

このタイプの弱点は、攻撃者が開発者による設定ミスを利用したり、タイポスクワッティングしたり、悪意のあるパッケージをオープン ソース リポジトリに追加したりするサプライ チェーン攻撃の結果として、悪用される可能性があります。このタイプの攻撃では、公開されたパッケージの信頼を悪用して、データにアクセスし、盗み出します。

Docker では、latest タグが、バージョンを提供するためにダイジェストまたは一意のタグを使用しないイメージのバージョン レベルを自動的に示します。Docker は自動的に、最新のイメージ マニフェスト ファイルを指すメカニズムとして latest タグを割り当てます。タグは変更可能であるため、攻撃者は latest (または imagename-lst, imagename-last, myimage などの弱いタグ) を使用して、イメージやレイヤーを置き換えることができます。

例 1: 次の設定では、最新バージョンの ubuntu を使用してベース イメージを選択するように Docker に指示します。

    FROM ubuntu:Latest
    ...

Docker は、パッケージ マネージャーをサポートするように設定されたリポジトリが信頼できるかどうかを検証しません。

例 2: 次の設定では、指定されたパッケージの最新バージョンを取得するように、パッケージ マネージャー zypper に指示します。

...
zypper install package
...

Example 2 では、リポジトリが侵害された場合、攻撃者は動的基準を満たすバージョンをアップロードするだけで、zypper が悪意のあるバージョンの依存関係をダウンロードするように仕向けることができます。

root に設定された USER 命令を持つ Dockerfile には、コンテナー内で変更を加えるための、過度に許容的な特権があります。これは、最小限の特権でイメージを実行するという原則に違反します。通常の場合、パッケージをインストールしてフォルダを作成するには、root 権限が必要になる可能性があります。インストールが完了したら、制限された権限を持つユーザーを追加することをお勧めします。

デフォルトでは、Docker は特権ポートをコンテナーにバインドすることを許可します。また、ポートがユーザーによって宣言されていない場合、Docker はコンテナーポートを 49153 から 65535 の範囲で使用可能なポートにマップします。多くの場合、サービスを実行するために特定のポートを開く必要があり、時間の経過とともに、開いているポートの数が増える可能性があります。ポートを開くと、特により高い特権で実行されているサービスの場合、攻撃対象領域が広がります。その特定のサービスに必要なポートのみを開くようにしてください。サービスがより高い特権を必要としない場合は、特権ポート範囲外のポートでサービスを実行します。

docker inspect コマンドと docker history コマンドを使用するか、サードパーティのツールを使用してこのプロセスを自動化することにより、公開されている docker イメージから Dockerfile を再構築できます。ADD/COPY コマンドを使用して機密情報が追加された場合、攻撃者は各 docker レイヤーを再作成してその情報を取得できます。

Volumes を使用した場合も、機密ディレクトリが公開される可能性があります。Volumes を使用してデータを永続化する必要がある場合は、機密性の高いディレクトリのマウントを避けてください。

Secure Shell (SSH) サービスがコンテナー内で実行されている場合、アクセス ポリシー、キー、パスワード、およびセキュリティ アップグレードの管理が困難になります。

CDN を使用して、アプリケーション独自の JavaScript を提供すると、アプリケーション独自のサーバーから JavaScript を提供する場合と比較して、多くの利点があります。パフォーマンスが向上したり、保守するコード量が削減されたりするなど、アプリケーションの所有者にとっての利点があります。しかし、アプリケーションは、CDN がブラウザに安全なコンテンツを配信することを前提としています。攻撃者が CDN を乗っ取っている場合、CDN はユーザーのブラウザに悪意のあるコードを配信します。ユーザーのブラウザは、アプリケーションが制御できないコードまたは悪意があることを検出できないコードを実行してしまいます。

例 1: 次の ASPX コードには、Microsoft CDN を参照する Microsoft の jQuery コードが含まれています。

...
<script src="http://ajax.microsoft.com/ajax/jquery/jquery-1.4.2.min.js" type="text/javascript"></script>
...

例 2: 次の ASPX コードを使用すると、すべての ASP.NET フレームワークスクリプトのリクエストを Microsoft Ajax CDN に自動的にリダイレクトできます。

...
<asp:ScriptManager
   ID="ScriptManager1"
   EnableCdn="true"
   Runat="Server" />
...

Example 2 では、ScriptManager コントロールが、ASPX ページを設定して、適切な CDN にスクリプトのリクエストを自動的にリダイレクトしています。

予期せぬイベントを記録 (ログ) するのにBlaze DS を使用している場合、services-config.xml ディスクリプタファイルは "Logging" XML 要素を指定して、ログの各要素を記述します。次のようになります。

例 1:

<logging>
    <target class="flex.messaging.log.ConsoleTarget" level="Debug">
        <properties>
            <prefix>[BlazeDS]</prefix>
            <includeDate>false</includeDate>
            <includeTime>false</includeTime>
            <includeLevel>false</includeLevel>
            <includeCategory>false</includeCategory>
        </properties>
        <filters>
            <pattern>Endpoint.*</pattern>
            <pattern>Service.*</pattern>
            <pattern>Configuration</pattern>
        </filters>
    </target>
</logging>

この target タグでは、ログレベルを示す level と呼ばれる属性をオプションで使用できます。デバッグ レベルが詳細すぎるレベルに設定されている場合、アプリケーションが機密データをログ ファイルに書き込む可能性があります。

カスタマーマネージド暗号鍵 (CMEK) は、保存データに対して有効になっていません。

デフォルトでは、Google Cloud はランダムに生成されたデータ暗号鍵 (DEK) を使用して保存データを暗号化します。CMEK 機能を使用すると、組織は、選択した暗号化キーを使用して DEK を暗号化できます。これにより、組織は暗号化プロセスをより適切に制御し、ログに記録できます。

そのため、CMEK は通常、次のような要件 (これに限らない) に対処するソリューションの一部です。
- 機密データへのアクセスの監査ログ
- データ所在地
- キーの交換、無効化、または破棄
- 改ざん防止ハードウェア セキュリティ モジュール

allUsers や allAuthenticatedUsers などの特殊なプリンシパル タイプにアクセス権や BigQuery ロールを付与すると、だれでも機密データにアクセスできてしまいます。

カスタマーマネージド暗号鍵 (CMEK) は、保存データに対して有効になっていません。

デフォルトでは、Google Cloud はランダムに生成されたデータ暗号鍵 (DEK) を使用して保存データを暗号化します。CMEK 機能を使用すると、組織は、選択した暗号化キーを使用して DEK を暗号化できます。これにより、組織は暗号化プロセスをより適切に制御し、ログに記録できます。

そのため、CMEK は通常、次のような要件 (これに限らない) に対処するソリューションの一部です。
- 機密データへのアクセスの監査ログ
- データ所在地
- キーの交換、無効化、または破棄
- 改ざん防止ハードウェア セキュリティ モジュール

カスタマーマネージド暗号鍵 (CMEK) は、保存データに対して有効になっていません。

デフォルトでは、Google Cloud はランダムに生成されたデータ暗号鍵 (DEK) を使用して保存データを暗号化します。CMEK 機能を使用すると、組織は、選択した暗号化キーを使用して DEK を暗号化できます。これにより、組織は暗号化プロセスをより適切に制御し、ログに記録できます。

そのため、CMEK は通常、次のような要件 (これに限らない) に対処するソリューションの一部です。
- 機密データへのアクセスの監査ログ
- データ所在地
- キーの交換、無効化、または破棄
- 改ざん防止ハードウェア セキュリティ モジュール