.NET では、BinaryFormatter クラスを使用して、オブジェクトを、オブジェクト自体と、デシリアライズ中にオブジェクトを再構築するために必要なメタデータの両方を含むバイナリ ストリームに変換することができます。

BinaryFormatter クラスを使用すると、攻撃者が任意のコードを実行したり、アプリケーション ロジックを悪用したり、Denial of Service 状態をトリガーしたりする可能性のある、安全でないデシリアライゼーション シナリオを引き起こす可能性があります。

BinaryFormatter 型の使用は危険であり、安全性が確立できないため、データ処理には推奨されません。

例 1: runtimeConfig.json ファイルで config プロパティ EnableUnsafeBinaryFormatterSerialization を true に設定することによって、アプリケーションは安全でない BinaryFormatter クラスの使用を有効にします。

...
AppContext.SetSwitch("System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization", true);
...

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>
...

開発者がドキュメントに記載されていない、または非表示の API を使用してアプリケーションを構築することはお勧めしません。 Google がこれらの API を今後削除または変更しないという保証がないため、使用を避ける必要があります。そのようなメソッドやフィールドを使用すると、アプリケーションが破壊されるリスクが高くなります。

このコードは、Camera オブジェクトがすでに解放された後でこのオブジェクトの使用を試みます。リソースを再取得しないまま Camera オブジェクトをさらに参照すると例外が発生し、この例外がキャッチされない場合にはアプリケーションがクラッシュする可能性があります。

例 1: 次のコードは、トグル ボタンを使用してカメラのプレビューをオン/オフしています。ユーザーがこのボタンを 1 度押すと、カメラのプレビューは停止し、カメラのリソースは解放されます。ただし、再びボタンを押すと、以前に解放された Camera オブジェクトで startPreview() がコールされます。

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

このコードは、メディアオブジェクトがすでに解放された後でこのオブジェクトの使用を試みます。リソースを再取得しないままこのメディアオブジェクトをさらに参照すると例外が発生し、この例外がキャッチされない場合にはアプリケーションがクラッシュする可能性があります。

例 1: 次のコードは、一時停止ボタンを使用してメディアの再生を切り替えています。ユーザーがこのボタンを 1 度押すと、楽曲または動画の再生が一時停止し、カメラ リソースは解放されます。ただし、再びボタンを押すと、以前に解放されたメディア リソースで start() がコールされます。

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

このコードは、Android SQLite データベースハンドラがすでに閉じられた後でこのオブジェクトの使用を試みます。データベース接続を再確立しないままハンドラをさらに参照すると例外が発生し、この例外がキャッチされない場合にはアプリケーションがクラッシュする可能性があります。

例 1: 次のコードは、ユーザー値を一時的にメモリにキャッシュするプログラムの一部だと考えられますが、ディスクへの変更をコミットするために flushUpdates() をコールすることができます。このメソッドは、データベースに更新を書き込んだ後、データベース ハンドラを適切に閉じます。しかし、再び flushUpdates() がコールされると、再初期化の前にデータベース オブジェクトが再び参照されます。

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

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 ファイルに置き換えるだけで、元のアプリケーションと同じ権限でこれを実行できるようになります。

Zip パス トラバーサル脆弱性が発生するのは、悪意のある攻撃者が特定の Zip ファイル内の Zip ファイル エントリ名を指定できる場合です。Zip ファイル エントリ名が悪意を持って指定されると、攻撃者は対応する Zip ファイルが展開されたときに重要なシステム ファイルの内容を上書きできます。攻撃者は、../ や / などのパス トラバーサル イディオムを使用して、プログラム領域外にあるシステム ファイルにアクセスする可能性があります。Android 14 以降を対象とする Android アプリケーションは、Zip ファイルの抽出中に ../ や / などのイディオムが検出されると、デフォルトで例外を発生させることができます。このセキュリティ機能は、上書きしたり、完全に無効にしたりすることができます。

例 1: 次のコードは、Zip Entry Overwrite 保護を無効にします。

...
dalvik.system.ZipPathValidator.clearCallback();
...

縮小化によってファイルサイズが減少するため、JavaScript ファイルを含むアプリケーションのページロード回数が向上します。縮小化とは、不用な空白、コメント、セミコロン、カッコを削除して、ローカル変数の名前を短縮し、使用しないコードを削除するプロセスです。

例 1: 次の ASPX コードには、Microsoft の jQuery ライブラリの縮小されていないバージョンが含まれています。

...
<script src="http://applicationserver.application.com/lib/jquery/jquery-1.4.2.js" type="text/javascript"></script>
...

検証できない入力は、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 プロパティにアクセスする可能性があります。

例 1: 次のコードは、プロパティ名または値の適切な検証を行うことなく、ユーザー制御の 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 が原因で、プログラムは割り当てられたメモリの境界外にデータを書き込みます。

例 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);
   }
   ...
}

テンプレート エンジンは動的なデータを使用してコンテンツをレンダリングするために使用されます。このコンテキスト データは通常、ユーザーによって制御され、テンプレートによって書式設定されて、Web ページ、電子メールなどが生成されます。テンプレート エンジンでは、コンテキスト データを条件文、ループなどのコード構造で処理することで、動的コンテンツをレンダリングするための強力な言語表現をテンプレートで使用できます。攻撃者がテンプレートを制御してレンダリングできる場合、式を挿入してコンテキスト データを開示したり、悪意のあるコードをブラウザーで実行できます。

例 1: 次の例では、テンプレートを URL から取得し、これを使用して AngularJS による情報のレンダリングを行う方法を示しています。

function MyController(function($stateParams, $interpolate){
    var ctx = { foo : 'bar' };
    var interpolated = $interpolate($stateParams.expression);
    this.rendered = interpolated(ctx);
    ...
}

この場合、$stateParams.expressionはユーザーが制御している可能性のあるデータを取得し、これを指定されたコンテキストで使用するテンプレートとして評価します。これにより、悪意のあるユーザーはブラウザ内で目的のコードを実行できるようになり、コードが実行されているコンテキストについての情報の取得、アプリケーションの作成方法に関する追加情報の検索、または本格的な XSS 攻撃への変換を行えるようになる可能性があります。

ブール値に対する算術演算子の動作は、整数値に対する動作とは異なるため、予期せぬ動作を引き起こす場合があります。

バイト配列からのデータが String に変換された場合、適用可能な文字セットに含まれないデータに何が起こるかは不明です。これによって、データが失われる可能性があります。また、適切なセキュリティ体制を保証するためにバイナリ データが必要な場合は、セキュリティ レベルの低下につながります。

例 1: 次のコードは、ハッシュを生成するためにデータを文字列に変換します。

  ...
  FileInputStream fis = new FileInputStream(myFile);
  byte[] byteArr = byte[BUFSIZE];
  ...
  int count = fis.read(byteArr);
  ...
  String fileString = new String(byteArr);
  String fileSHA256Hex = DigestUtils.sha256Hex(fileString);
  // use fileSHA256Hex to validate file
  ...

ファイルのサイズが BUFSIZE より小さいと仮定すると、myFile の情報がデフォルトの文字セットと同様にエンコードされている限り問題はありません。ただし、別のエンコーディングが使用されていたり、ファイルがバイナリ ファイルである場合は、情報を失います。その結果、生成された SHA ハッシュの信頼性が損なわれ、特にデフォルトの文字セットに含まれないデータが疑問符などの同じ値で表されている場合、衝突が発生しやすくなった可能性があることを意味します。