脆弱な認証メカニズムは、組織を不正アクセスの危険にさらします。

認証メカニズムは、次のようなさまざまな理由で失敗する可能性があります。
- パスワードが脆弱である
- 不適切な検証
- 資格情報の管理が弱い

脆弱な認証メカニズムは、組織を不正アクセスの危険にさらします。

認証メカニズムは、次のようなさまざまな理由で失敗する可能性があります。
- パスワードが脆弱である
- 不適切な検証
- 資格情報の管理が弱い

脆弱な認証メカニズムは、組織を不正アクセスの危険にさらします。

認証メカニズムは、次のようなさまざまな理由で失敗する可能性があります。
- パスワードが脆弱である
- 不適切な検証
- 資格情報の管理が弱い

脆弱な認証メカニズムは、組織を不正アクセスの危険にさらします。

認証メカニズムは、次のようなさまざまな理由で失敗する可能性があります。
- パスワードが脆弱である
- 不適切な検証
- 資格情報の管理が弱い

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);

タッチ ID ベースの認証を、LocalAuthentication フレームワークを使用する方法またはキーチェーン サービスでタッチ ID ベースのアクセス制御を使用する方法の 2 つの異なる方法で実装できます。

両方とも、ほとんどのアプリケーションでは十分に強力ですが、LocalAuthentication アプローチには、銀行取引、医療、保険などリスクの高いアプリケーションにはやや適さない特性がいくつかあります。

- LocalAuthentication はデバイスの Secure Enclave 外で定義され、これは API を脱獄デバイス上でフックして変更できることを意味します。
- LocalAuthentication は、コンテキスト ポリシーを true または false にのみ評価することでユーザーを認証します。このブール評価は、アプリケーションは実際に誰が認証されているかを把握できず、デバイスに登録されているフィンガープリントが使用されたか否かのみ把握できることを意味します。また、将来登録されるフィンガープリントも正常に true に評価されます。


例 1: 次のコードは、LocalAuthentication フレームワークを使用してユーザー認証を実行します。

    ...
    LAContext *context = [[LAContext alloc] init];  
    NSError *error = nil;  
    NSString *reason = @"Please authenticate using the Touch ID sensor.";
    
    if ([context canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&error]) {  
        [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics
            localizedReason:reason
                reply:^(BOOL success, NSError *error) {
                    if (success) {
                        // Fingerprint was authenticated
                    } else {
                        // Fingerprint could not be authenticated
                    }
            }
        ];
    ...

キーチェーン サービスを使用して、タッチ ID ベースの認証を実装できます。それには、キーチェーンにアイテムを格納して、後からアイテムを取得するにはフィンガープリントを使用することをユーザーに要求するアクセス制御を設定します。次のポリシーを使用して、フィンガープリントを使用してユーザーを認証する方法を定義できます。

- kSecAccessControlUserPresence: タッチ ID またはパスコードでのアクセスへの制約。タッチ ID が使用可能である、または登録されている必要はありません。フィンガープリントが追加または削除された場合でも、引き続きタッチ ID でアイテムにアクセスできます。
- kSecAccessControlTouchIDAny: 登録されている任意のフィンガープリントのタッチ ID でのアクセスへの制約。フィンガープリントが追加または削除された場合、アイテムは無効化されません。
- kSecAccessControlTouchIDCurrentSet: 現在登録されているフィンガープリントのタッチ ID でのアクセスへの制約。フィンガープリントが追加または削除された場合、アイテムは無効化されます。

タッチ ID を使用する場合、kSecAccessControlTouchIDCurrentSet 属性を使用して、フィンガープリントが今後追加または削除されるのを防ぐ必要があります。

例 1: 次のコードは、今後登録されるフィンガープリントでキーチェーンのアイテムをロック解除できる kSecAccessControlTouchIDAny 制約を使用しています。

    ...
    SecAccessControlRef sacRef = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
                 kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
                 kSecAccessControlTouchIDCurrentSet, 
                 nil);
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:account forKey:(__bridge id)kSecAttrAccount];
    [dict setObject:service forKey:(__bridge id) kSecAttrService];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:sacRef forKey:(__bridge id)kSecAttrAccessControl];
    [dict setObject:@"Please authenticate using the Touch ID sensor." forKey:(__bridge id)kSecUseOperationPrompt];

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        OSStatus status = SecItemAdd((__bridge CFDictionaryRef)dict, nil);
    });
    ...

Apple のポリシーによると、アプリケーションは常にフィンガープリントが必要な理由をユーザーに説明する必要があります。説明しない場合、ユーザーが混乱したり、AppStore からアプリケーションを拒否する可能性があります。

例 1: 次のコードでは、タッチ ID を使用してユーザーを認証しますが、なぜ認証が必要か説明するローカライズされた理由を示すことができません。

    [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics localizedReason:nil
        reply:^(BOOL success, NSError *error) {
            if (success) {
                NSLog(@"Auth was OK");
            } 
    }];

Buffer Overflow は、ソフトウェアセキュリティの脆弱性の中で最も有名な形態でしょう。Buffer Overflow の脆弱性については大半のソフトウェア開発者に知られているにも関わらず、依然として Buffer Overflow は新旧を問わずアプリケーションに対して最も多く見られる攻撃です。これは、Buffer Overflow には多種多様の発生形態があることや、この攻撃を阻止するために使用される手法が誤りやすいものであることによるものです。

古典的な Buffer Overflow の悪用では、攻撃者がプログラムに送信したデータが、それよりも小さいサイズのスタックバッファに格納されます。その結果、コールスタックにある情報、特に関数の戻りポインタが上書きされます。このデータがセットした戻りポインタの値に関数が戻ると、攻撃者のデータに含まれる悪意あるコードに制御が移ります。

このタイプのスタック Buffer Overflow は一部のプラットフォームや開発コミュニティでは今でも一般的ですが、ほかにもヒープ Buffer Overflow や「一つ違い」エラーなどのさまざまな Buffer Overflow があります。Buffer Overflow 攻撃の仕組みを解説した書籍には、Building Secure Software [1]、Writing Secure Code [2]、The Shellcoder's Handbook [3] など優れた本が数多くあります。

コードのレベルでは、Buffer Overflow 脆弱性には通常、プログラマの想定外のことが含まれます。C および C++ のメモリ操作関数の多くは境界チェックを行わないため、動作しているバッファに対して割り当てられた境界を簡単に上書きすることができます。strncpy() など境界が定められた関数の場合も、不正に使用されると脆弱性の原因になります。メモリの操作と、データのサイズや構成に関する誤った想定が同時に発生することが、大部分の Buffer Overflow の根本的な原因です。

Buffer Overflow の脆弱性は通常、以下のようなコードで発生します。

- 外部データがコードの動作を制御することを許容している。

- コードの直接のスコープの外部で強制されているデータのプロパティに依存している。

- コードが複雑すぎてプログラマにも動作が正確に予測できない。



これら 3 つのシナリオを以下の例で説明します。

例 1.a: 次のサンプルコードは単純な Buffer Overflow の例です。多くの場合、コードの動作制御を外部データに任せるという 1 つ目のシナリオによって引き起こされます。このコードは gets() 関数を使用して、任意の量のデータをスタックバッファに読み込みます。この関数により読み込まれるデータ量を制限する方法がないので、このコードが安全かどうかは、ユーザーが常に BUFSIZE 字以下しか入力しないということにかかっています。

	...
	char buf[BUFSIZE];
	gets(buf);
	...

例 1.b: この例は、>> 演算子を使用して入力を char[] 文字列に読み込むことによって C++ の gets() 関数の危険な動作を簡単に模倣できることを示しています。

	...
	char buf[BUFSIZE];
	cin >> (buf);
	...

例 2: これもコードの動作の制御がユーザー入力にかかっているコードの例ですが、境界のあるメモリコピー関数 memcpy() の使用により、さらに間接的になっています。この関数は、コピー先バッファ、コピー元バッファ、およびコピーするバイト数を受け取ります。入力バッファには read() への境界のあるコールが入りますが、memcpy() がコピーするバイト数はユーザーが指定します。

	...
char buf[64], in[MAX_SIZE];
printf("Enter buffer contents:\n");
read(0, in, MAX_SIZE-1);
printf("Bytes to copy:\n");
scanf("%d", &bytes);
memcpy(buf, in, bytes);
	...

注：このタイプの Buffer Overflow 脆弱性 (プログラムはデータを読み取った後、残りのデータに対する以降のメモリ操作でデータから送られる値を信頼する) は、一定の頻度で画像やオーディオなどのファイルを処理するライブラリに発生します。

例 3: この 2 つ目のシナリオの例では、ローカルで検証されていないデータのプロパティにコードが依存しています。この例では、lccopy() という名の関数で文字列をその引数として取り、その文字列の大文字をすべて小文字に変換した上で、文字列のヒープに割り当てられたコピーを返します。この関数では、str は常に BUFSIZE より小さいと想定されているため、入力に対して境界チェックが行われません。lccopy() をコールするコードで攻撃者がチェックを回避する場合や、コードが変更された結果 str のサイズに関する想定が正しくなくなった場合、lccopy() は strcpy() への境界のないコールで buf を オーバーフローさせます。

char *lccopy(const char *str) {
	char buf[BUFSIZE];
	char *p;

	strcpy(buf, str);
	for (p = buf; *p; p++) {
		if (isupper(*p)) {
			*p = tolower(*p);
		}
	}
	return strdup(buf);
}

例 4: 次のコードは、コードが非常に複雑なので動作を簡単に予測できない 3 番目のシナリオを示しています。このコードは、さまざまなアプリケーションで使用されている、人気の libPNG 画像デコーダーからのものです。

このコードは変数の長さをチェックしているので、安全に境界チェックを実行しているように見えます (この変数長は、後で png_crc_read(). によってコピーされたデータ量を制御するために使用されます)。しかし、長さをテストする直前で、このコードは png_ptr->mode のチェックを実行しており、このチェックが失敗した場合は警告を出して処理を継続します。length は else if ブロックでテストされているので、1 回目のチェックが失敗すると length はテストされません。このため png_crc_read() に対するコールで無条件に使用されることになり、スタック Buffer Overflow が発生する可能性があります。

この例のコードは最も複雑な部類に属するものではありませんが、メモリ操作を実行するコードの複雑性を最小限に抑えなければならない理由がよくわかります。

if (!(png_ptr->mode & PNG_HAVE_PLTE)) {
	/* Should be an error, but we can cope with it */
png_warning(png_ptr, "Missing PLTE before tRNS");
}
else if (length > (png_uint_32)png_ptr->num_palette) {
png_warning(png_ptr, "Incorrect tRNS chunk length");
png_crc_finish(png_ptr, length);
return;
}
...
png_crc_read(png_ptr, readbuf, (png_size_t)length);

例 5: これも第 3 のシナリオの例で、プログラムが複雑なために Buffer Overflow の危険が生じています。この場合、危険の原因は、前の例のようにコードの構造にあるのではなく、いずれかの関数のインターフェイスが多義的であることにあります。

getUserInfo() 関数は、マルチバイト文字列として指定されたユーザー名およびユーザー情報を格納する構造体へのポインタを受け取り、ユーザーに関する情報を構造体に代入します。Windows Authentication ではユーザー名に Unicode が使用されるため、username 引数はまずマルチバイト文字列から Unicode 文字列に変換されます。次に、この関数は unicodeUser のサイズを、文字数ではなく、誤ってバイト単位で渡しています。このため、MultiByteToWideChar() のコールは最大で (UNLEN+1)*sizeof(WCHAR) のワイド文字、
つまり (UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) バイトを unicodeUser 配列に書き込む可能性があります。これに対し、この配列には (UNLEN+1)*sizeof(WCHAR) バイトしか割り当てられていません。username 文字列に含まれる文字数が UNLEN 字を超えている場合、MultiByteToWideChar() のコールにより、バッファ unicodeUser はオーバーフローします。

void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1];
	MultiByteToWideChar(CP_ACP, 0, username, -1,
    	      			unicodeUser, sizeof(unicodeUser));
NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info);
}

Buffer Overflow は、ソフトウェアセキュリティの脆弱性の中で最も有名な形態でしょう。Buffer Overflow の脆弱性については大半のソフトウェア開発者に知られているにも関わらず、依然として Buffer Overflow は新旧を問わずアプリケーションに対して最も多く見られる攻撃です。これは、Buffer Overflow には多種多様の発生形態があることや、この攻撃を阻止するために使用される手法が誤りやすいものであることによるものです。

古典的な Buffer Overflow の悪用では、攻撃者がプログラムに送信したデータが、それよりも小さいサイズのスタックバッファに格納されます。その結果、コールスタックにある情報、特に関数の戻りポインタが上書きされます。このデータがセットした戻りポインタの値に関数が戻ると、攻撃者のデータに含まれる悪意あるコードに制御が移ります。

このタイプのスタック Buffer Overflow は一部のプラットフォームや開発コミュニティでは今でも一般的ですが、ほかにもヒープ Buffer Overflow や「一つ違い」エラーなどのさまざまな Buffer Overflow があります。Buffer Overflow 攻撃の仕組みを解説した書籍には、Building Secure Software [1]、Writing Secure Code [2]、The Shellcoder's Handbook [3] など優れた本が数多くあります。

コードのレベルでは、Buffer Overflow 脆弱性には通常、プログラマの想定外のことが含まれます。C および C++ のメモリ操作関数の多くは境界チェックを行わないため、動作しているバッファに対して割り当てられた境界を簡単に超過する場合があります。strncpy() など境界が定められた関数の場合も、不正に使用されると脆弱性の原因になります。メモリの操作と、データのサイズや構成に関する誤った想定が同時に発生することが、大部分の Buffer Overflow の根本的な原因です。

この場合、不適切に構築されている Format String が原因で、プログラムは割り当てられたメモリの境界外にデータを書き込みます。

例 1:double タイプには c に割り当てられている以上の領域が必要であるため、次のコードでは c がオーバーフローします。

void formatString(double d) {
    char c;

    scanf("%d", &c)
}

Buffer Overflow は、ソフトウェアセキュリティの脆弱性の中で最も有名な形態でしょう。Buffer Overflow の脆弱性については大半のソフトウェア開発者に知られているにも関わらず、依然として Buffer Overflow は新旧を問わずアプリケーションに対して最も多く見られる攻撃です。これは、Buffer Overflow には多種多様の発生形態があることや、この攻撃を阻止するために使用される手法が誤りやすいものであることによるものです。

古典的な Buffer Overflow の悪用では、攻撃者がプログラムに送信したデータが、それよりも小さいサイズのスタックバッファに格納されます。その結果、コールスタックにある情報、特に関数の戻りポインタが上書きされます。このデータがセットした戻りポインタの値に関数が戻ると、攻撃者のデータに含まれる悪意あるコードに制御が移ります。

このタイプのスタック Buffer Overflow は一部のプラットフォームや開発コミュニティでは今でも一般的ですが、ほかにもヒープ Buffer Overflow や「一つ違い」エラーなどのさまざまな Buffer Overflow があります。Buffer Overflow 攻撃の仕組みを解説した書籍には、Building Secure Software [1]、Writing Secure Code [2]、The Shellcoder's Handbook [3] など優れた本が数多くあります。

コードのレベルでは、Buffer Overflow 脆弱性には通常、プログラマの想定外のことが含まれます。C および C++ のメモリ操作関数の多くは境界チェックを行わないため、動作しているバッファに対して割り当てられた境界を簡単に超過する場合があります。strncpy() など境界が定められた関数の場合も、不正に使用されると脆弱性の原因になります。メモリの操作と、データのサイズや構成に関する誤った想定が同時に発生することが、大部分の Buffer Overflow の根本的な原因です。

この場合、不適切に構築されている Format String が原因で、プログラムは割り当てられたメモリの境界外にデータを書き込みます。

例 1: 次のコードでは buf がオーバーフローしますが、これは f のサイズに応じて、Format String 指定子 "%d %.1f ... " が割り当てられているメモリ量を超えるからです。

void formatString(int x, float f) {
   char buf[40];
   sprintf(buf, "%d %.1f ... ", x, f);
}

Buffer Overflow は、ソフトウェアセキュリティの脆弱性の中で最も有名な形態でしょう。Buffer Overflow の脆弱性については大半のソフトウェア開発者に知られているにも関わらず、依然として Buffer Overflow は新旧を問わずアプリケーションに対して最も多く見られる攻撃です。これは、Buffer Overflow には多種多様の発生形態があることや、この攻撃を阻止するために使用される手法が誤りやすいものであることによるものです。

古典的な Buffer Overflow の悪用では、攻撃者がプログラムに送信したデータが、それよりも小さいサイズのスタックバッファに格納されます。その結果、コールスタックにある情報、特に関数の戻りポインタが上書きされます。このデータがセットした戻りポインタの値に関数が戻ると、攻撃者のデータに含まれる悪意あるコードに制御が移ります。

このタイプの「一つ違い」エラーは一部のプラットフォームや開発コミュニティでは今でも一般的ですが、ほかにもスタックおよびヒープ Buffer Overflow などのさまざまな Buffer Overflow があります。Buffer Overflow 攻撃の仕組みを解説した書籍には、Building Secure Software [1]、Writing Secure Code [2]、The Shellcoder's Handbook [3] など優れた本が数多くあります。

コードのレベルでは、Buffer Overflow 脆弱性には通常、プログラマの想定外のことが含まれます。C および C++ のメモリ操作関数の多くは境界チェックを行わないため、動作しているバッファに対して割り当てられた境界を簡単に超過する場合があります。strncpy() など境界が定められた関数の場合も、不正に使用されると脆弱性の原因になります。メモリの操作と、データのサイズや構成に関する誤った想定が同時に発生することが、大部分の Buffer Overflow の根本的な原因です。

例 1: 次のコードには、「一つ違い」による Buffer Overflow の問題が含まれています。これは、recv によって、読み取られた最大許容数の sizeof(buf) バイトが返された場合に発生します。この場合、その後に続く buf[nbytes] の間接参照によって、割り当てられたメモリの境界外に null バイトが書き込まれます。

void receive(int socket) {
   char buf[MAX];
   int nbytes = recv(socket, buf, sizeof(buf), 0);
   buf[nbytes] = '\0';
   ...
}

Buffer Overflow は、ソフトウェアセキュリティの脆弱性の中で最も有名な形態でしょう。Buffer Overflow の脆弱性については大半のソフトウェア開発者に知られているにも関わらず、依然として Buffer Overflow は新旧を問わずアプリケーションに対して最も多く見られる攻撃です。これは、Buffer Overflow には多種多様の発生形態があることや、この攻撃を阻止するために使用される手法が誤りやすいものであることによるものです。

古典的な Buffer Overflow の悪用では、攻撃者がプログラムに送信したデータが、それよりも小さいサイズのスタックバッファに格納されます。その結果、コールスタックにある情報、特に関数の戻りポインタが上書きされます。このデータがセットした戻りポインタの値に関数が戻ると、攻撃者のデータに含まれる悪意あるコードに制御が移ります。

このタイプのスタック Buffer Overflow は一部のプラットフォームや開発コミュニティでは今でも一般的ですが、ほかにもヒープ Buffer Overflow や「一つ違い」エラーなどのさまざまな Buffer Overflow があります。Buffer Overflow 攻撃の仕組みを解説した書籍には、Building Secure Software [1]、Writing Secure Code [2]、The Shellcoder's Handbook [3] など優れた本が数多くあります。

コードのレベルでは、Buffer Overflow 脆弱性には通常、プログラマの想定外のことが含まれます。C および C++ のメモリ操作関数の多くは境界チェックを行わないため、動作しているバッファに対して割り当てられた境界を簡単に超過する場合があります。strncpy() など境界が定められた関数の場合も、不正に使用されると脆弱性の原因になります。メモリの操作と、データのサイズや構成に関する誤った想定が同時に発生することが、大部分の Buffer Overflow の根本的な原因です。

例 1: 次のコードは、「一つ違い」による Buffer Overflow の発生を防止するために、getInputLength() から読み取られた信頼できない値が、コピー先バッファである output のサイズより小さいかどうかをチェックしています。しかし、len と MAX の比較は符号付きであるため、len の値が負であった場合にその値が memcpy() の符号なし引数に変換されると、非常に大きな正の数値となります。

void TypeConvert() {
   char input[MAX];
   char output[MAX];

   fillBuffer(input);
   int len = getInputLength();

   if (len <= MAX) {
      memcpy(output, input, len);
   }
   ...
}

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

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

Castor がオブジェクトをロックしていても、他のスレッドによりオブジェクトが読み取られたり書き込まれたりする可能性があります。読み取り専用のクエリは、デフォルトの共有モードと比較して、約 7 倍処理が早くなります。

例 1: 次の例では、クエリモードが SHARED に指定されており、読み取りアクセスと書き込みアクセスの両方が許可されています。

results = query.execute(Database.SHARED);