AccessibleObject API によって、プログラマは Java アクセス指定子によって行われる Access Control チェックを回避できます。特に、これによってプログラマは、反映されたオブジェクトが Java Access Control を迂回することでプライベートフィールドの値を変更するかまたはプライベートメソッドを呼び出せるようにすることができます。通常これらは許可されない挙動です。

通常の JSF アプリケーションでは、UI コンポーネントで指定されたコンバーターとバリデーターを使用して、値が変換および検証されます。変換と検証自体は、ページが送信されたときに行われます。Fusion アプリケーションでブックマーク可能なビューを使用すると、ページが送信されないため、デフォルトでは同様の変換や検証は実行されません。

例 1: 次の設定ファイル スニペットは、paramName URL パラメーターの変換または検証を実行しないように設定された、ブックマーク可能なビューのサンプルを示しています。

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

Android Class Loading Hijacking の脆弱性には、次の 2 つの形態があります。

- プログラムがクラスをロードするために検索するディレクトリの名前を攻撃者が変更可能である。攻撃者は、プログラムに自分が制御するディレクトリへのパスを参照させることで、クラスが検索されるパスを明示的に制御することになります。

- クラスがロードされる環境を攻撃者が変更可能である。攻撃者はパス名の意味を暗黙的に制御することになります。

この場合は 1 つ目の状況が最も懸念されます。攻撃者は、ロードするクラスが検索されるディレクトリを制御できる可能性があります。このタイプの Android Class Loading Hijacking の脆弱性が発生するのは、次の場合です。

1.信頼できないソースからアプリケーションにデータが入り込んだ場合。



2.データが、ロードするクラスが検索されるライブラリ ディレクトリを表す文字列 (またはその一部) として使用された場合。



3.アプリケーションがライブラリ パスのコードを実行することにより、本来付与されないはずの権限や能力を攻撃者に与えられた場合。

例 1: 次のコードでは、ユーザーが変更可能な userClassPath を使用して、ロードするクラスが検索されるディレクトリを決定します。

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

このコードでは、攻撃者は、制御している別のパスを参照するように userClassPath の結果を変更できるため、ライブラリをロードしてアプリケーションの任意のコードを昇格された権限で実行できます。このプログラムは環境から読み取った値の検証を行わないので、攻撃者は、userClassPath の値を制御できれば、元のアプリケーションと同じ権限を使用し、アプリケーションを操作して制御するディレクトリを参照させることで、自分が定義したクラスをロードできます。

例 2: 次のコードでは、ユーザーが変更可能な userOutput を使用して、Optimized DEX ファイルを書き込むディレクトリを決定します。

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

このコードでは、攻撃者が Optimized DEX (ODEX) ファイルの出力ディレクトリを指定できます。その結果、悪意のあるユーザーが userOutput の値を、外部ストレージなど、攻撃者が制御するディレクトリに変更できます。これが実行された後は、出力される ODEX ファイルを悪意のある ODEX ファイルに置き換えるだけで、元のアプリケーションと同じ権限でこれを実行できるようになります。

検証できない入力は、ASP.NET Web API サービスの主な脆弱性の 1 つです。Cross-Site Scripting、Process Control、Access Control や SQL Injection などのさまざまな脆弱性の原因は入力の未検証です。ASP.NET Web API サービスは通常、メモリ破壊攻撃には影響を受けませんが、ASP.NET Web API サービスが配列境界チェックを行わないネイティブ コードを呼び出す場合には、攻撃者が ASP.NET Web API サービスの入力脆弱性を利用して Buffer overflow 攻撃を仕掛ける可能性があります。

そのような攻撃を防止するためには、以下の手順を実行します。
1. ASP.NET Web API サービス アクションへのパラメーターまたはモデルバインド オブジェクト パラメーターのメンバーの検証チェックを、検証属性を使用してプログラム的にチェックする。
2. ModelState.IsValid を使用してモデル検証の合否をチェックする。

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

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 が原因で、プログラムは割り当てられたメモリの境界外にデータを書き込みます。

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

void formatString(double d) {
    char c;

    scanf("%d", &c)
}