多くの DNS サーバーが偽装攻撃にさらされているので、危険な状態の DNS サーバーの環境でソフトウェアが使用される可能性も想定してください。攻撃者が DNS を更新できる場合 (DNS キャッシュポイズニングとも呼ばれます)、攻撃者はネットワークトラフィックが自分のマシンを経由するようにしたり、攻撃者の IP アドレスが攻撃対象のドメインの一部であるかのように見せかけたりすることができます。システムのセキュリティが DNS 名に依存することがないようにしてください。
例: 次のコードサンプルは、DNS ルックアップを使用して、着信リクエストが信頼できるホストからのものかどうかを判断します。攻撃者が DNS キャッシュをポイズニングできる場合、信頼できるというステータスを取得できます。

 IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
 IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress);
 if (hostInfo.HostName.EndsWith("trustme.com")) {
   trusted = true;
 }

IP アドレスは DNS 名よりは信頼できますが、偽装可能であることに変わりはありません。攻撃者は、送信するパケットのソース IP アドレスを容易に偽装できますが、レスポンス パケットは偽装された IP アドレスに戻されます。攻撃者はレスポンスパケットを参照するため、攻撃対象のマシンと偽装 IP アドレスの間のトラフィックを盗聴する必要があります。攻撃者は必要な盗聴を実行するため、攻撃対象のマシンと同じサブネットに入り込もうとします。攻撃者はソースルーティングを使用してこの要件を回避できる場合がありますが、今日ではインターネットでのソースルーティングは多くの場合、無効にされています。つまり、IP アドレス検証は Authentication 方式の有用な部分とすることができます。しかし、Authentication に必要な唯一の要素ではありません。

通常、getlogin() 関数は、ターミナルで現在ログオン中のユーザー名を含む文字列を戻しますが、攻撃者は getlogin() を操作し、そのマシンにログオンした任意のユーザー名を戻すことができます。このため、セキュリティに関する決定を行う際に、getlogin() 関数によって戻された名前を信頼しないようにします。
例 1: 次のコードでは、getlogin() の結果を信頼し、信頼できるユーザーかどうかを判断しています。しかし、これは全く当てになりません。

 pwd = getpwnam(getlogin());
 if (isTrustedGroup(pwd->pw_gid)) {
 allow();
 } else {
 deny();
 }

プログラムが記述されている言語に関係なく、最も被害が深刻な攻撃ではリモートからコード実行されることが多く、攻撃者はプログラムの権限で悪意あるコードを実行できます。.NET フレームワークの Decoder および Encoding クラスの GetChars メソッドと Encoder および Encoding クラスの GetBytes メソッドは、char および byte 配列に対して内部的にポインタ算術を実行し、文字の範囲をバイトの範囲に (およびその逆に) 変換します。
ポインタ算術操作の実行時、開発者が上記のメソッドを不適切な方法で上書きすることで、任意のコード実行、アプリケーション ロジックの悪用、サービス拒否などの脆弱性が生じることがあります。

文字セットがオペレーティングシステムとオペレーティングシステム上のアプリケーションで一致していない場合、デフォルトの API メソッドに渡されたサポート対象外の文字を危険な文字にベストフィットマッピングすることができます。

例 1:Objective-C の場合、次の例は UTF-8 文字を含んだ NSString オブジェクトを ASCII データに変換し、その後戻します。

...
unichar ellipsis = 0x2026;
NSString *myString = [NSString stringWithFormat:@"My Test String%C", ellipsis];
NSData *asciiData = [myString dataUsingEncoding:NSASCIIStringEncoding allowLossyConversion:YES];
NSString *asciiString = [[NSString alloc] initWithData:asciiData encoding:NSASCIIStringEncoding];
NSLog(@"Original: %@ (length %d)", myString, [myString length]);
NSLog(@"Best-fit-mapped: %@ (length %d)", asciiString, [asciiString length]);
// output:
// Original: My Test String... (length 15)
// Best-fit-mapped: My Test String... (length 17)
...

出力を注意深く見ると、「...」という文字は 3 つの連続するピリオドに変換されています入力バッファに基づいて出力バッファのサイジングを行った場合、アプリケーションが Buffer Overflow に対して脆弱である可能性があります。その他の文字は、1 文字から 2 文字にマッピングすることができます。ギリシャ文字の「fi」という文字は、「f」と「i」にマッピングされます。攻撃者は、これらの文字を使用してバッファをフロントローディングすることによって、バッファをオーバーフローさせるのに使用される文字の数を完全に制御できます。

文字セットがオペレーティングシステムとオペレーティングシステム上のアプリケーションで一致していない場合、デフォルトの API メソッドに渡されたサポート対象外の文字を危険な文字にベストフィットマッピングすることができます。

例 1: Swift の場合、次の例は UTF-8 文字を含んだ NSString オブジェクトを ASCII データに変換し、その後戻します。

...
let ellipsis = 0x2026;
let myString = NSString(format:"My Test String %C", ellipsis)
let asciiData = myString.dataUsingEncoding(NSASCIIStringEncoding, allowLossyConversion:true)
let asciiString = NSString(data:asciiData!, encoding:NSASCIIStringEncoding)
NSLog("Original: %@ (length %d)", myString, myString.length)
NSLog("Best-fit-mapped: %@ (length %d)", asciiString!, asciiString!.length)

// output:
// Original: My Test String ... (length 16)
// Best-fit-mapped: My Test String ... (length 18)
...

出力を注意深く見ると、「...」という文字は 3 つの連続するピリオドに変換されています入力バッファに基づいて出力バッファのサイジングを行った場合、アプリケーションが Buffer Overflow に対して脆弱である可能性があります。その他の文字は、1 文字から 2 文字にマッピングすることができます。ギリシャ文字の「fi」という文字は、「f」と「i」にマッピングされます。攻撃者は、これらの文字を使用してバッファをフロントローディングすることによって、バッファをオーバーフローさせるのに使用される文字の数を完全に制御できます。

Windows には、ファイル名を格納するバッファを操作するユーティリティ関数が多数用意されています。ほとんどの場合、結果は入力として渡されたバッファーの中に返されます。(通常、ファイル名がそのままの場所で変更されます。)大部分の関数には最低 MAX_PATH バイト数の長さを持つバッファが必要ですが、各関数については関連資料で確認してください。バッファサイズが処理結果を格納するのに十分でなかった場合には、Buffer Overflow が発生します。

例:

char *createOutputDirectory(char *name) {
	char outputDirectoryName[128];
	if (getCurrentDirectory(128, outputDirectoryName) == 0) {
		return null;
	}
	if (!PathAppend(outputDirectoryName, "output")) {
		return null;
	}
	if (!PathAppend(outputDirectoryName, name)) {
		return null;
	}
	if (SHCreateDirectoryEx(NULL, outputDirectoryName, NULL)
        != ERROR_SUCCESS) {
		return null;
	}
	return StrDup(outputDirectoryName);
}

上記の関数では、現在のディレクトリに「output\<name>」という名前のディレクトリが作成され、ヒープに割り当てたディレクトリ名のコピーを戻しています。この関数は、現在のディレクトリおよび名前パラメーターのほとんどの値で正しく機能します。ただし、name パラメーターが極端に長いと、PathAppend() への 2 度目のコールで MAX_PATH バイト数より小さなバッファである outputDirectoryName のオーバーフローを引き起こす可能性があります。

特定の関数は、無条件にシンボリックリンクをたどることが知られています。そのような場合、アプリケーションは、シンボリックリンクが表しているものではなくシンボリックリンクが指し示しているファイルを開いたり、読み取ったり、データ書き込みを行ったりします。攻撃者はアプリケーションを操って重要なシステム ファイルを改ざんしたり、不正なデータをアプリケーションに渡したりできます。

例 1: 次のコードは、シンボリック リンクをたどる関数を使用しています。

...
	struct stat output;
	int ret = stat(aFilePath, &output);
	// error handling omitted for this example
	struct timespec accessTime = output.st_atime;
...

umask() の man ページは、次のような間違った記述で始まります。

「umask はファイル作成モードを mask & 0777 に設定します」

この動作は、chmod() でユーザーが特定のファイルでアクセス許可を有効にするビットを設定する使用方法と呼応していますが、実際には umask() の動作は全く正反対です。umask() はファイル作成モードを ~mask & 0777 にセットします。

umask() の man ページでは、続いて以下のように正しい umask() の使用法について述べています。

「umask は新規作成ファイルに対して初期ファイル権限を設定するために使用されます。具体的には、モード引数から umask に設定されているビットが引かれます (たとえば一般的な umask のデフォルト値は 022 ですが、モードが 0666 と指定されていると、新規ファイルは 0666 & ~022 = 0644 = rw-r--r-- のアクセス許可で作成されます)。」

多くの API は、テンポラリ ファイルにすべてを書き込んでからそのファイルを目的の場所にコピーすることによって、データ損失のリスクを最小限に抑えます。テンポラリ ファイルがターゲット ファイルに書き込まれる直前に、テンポラリ ファイルが攻撃者によって置き換えられる可能性があります。そのため、特定されたメソッドが、パブリック ディレクトリまたはテンポラリ ディレクトリのファイルやパスを操作しないことを確認してください。操作している場合、パブリック ディレクトリでアプリケーションが使用するファイルの内容を攻撃者に制御される可能性があります。

例 1:次のコードは、脆弱なメソッドを使用して、アプリケーションの Documents ディレクトリ内の一時ファイルにアクティブな transactionId を書き込んでいます。

...
//get the documents directory:
let documentsPath = NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0]
//make a file name to write the data to using the documents directory:
let fileName = NSString(format:"%@/tmp_activeTrans.txt", documentsPath)
// write data to the file
let transactionId = "TransactionId=12341234"
transactionId.writeToFile(fileName, atomically:true)
...

プログラムが記述されている言語に関係なく、最も被害が深刻な攻撃ではリモートからコード実行されることが多く、攻撃者はプログラムの権限で悪意あるコードを実行できます。攻撃者が Web からのアクセスが可能なディレクトリにファイルをアップロードし、アップロードしたファイルをコードインタプリタ (JSP、ASPX、PHP など) に渡すことができる場合、これらのファイルに含まれている悪意あるコードがサーバーで実行される可能性があります。

次のコードはアップロードされたファイルを受け取り、それを posted オブジェクトに割り当てます。FileUpload は System.Web.UI.HtmlControls.HtmlInputFile のタイプです。
例:

HttpPostedFile posted = FileUpload.PostedFile;

アップロードされたファイルが Web からアクセスできないディレクトリに保存された場合であっても、攻撃者はこの機能を利用してサーバー環境に悪意のあるコンテンツを持ち込み、その他の攻撃を仕掛ける可能性があります。プログラムが Path Manipulation、Command Injection、または Dangerous File Inclusion の脆弱性の危険にさらされている場合、攻撃者は悪意のあるコンテンツを含んだファイルをアップロードし、別の脆弱性を悪用することによってそのファイルをプログラムで読み取る、あるいは実行させる可能性があります。

プログラムが記述されている言語に関係なく、最も被害が深刻な攻撃ではリモートからコード実行されることが多く、攻撃者はプログラムの権限で悪意あるコードを実行できます。攻撃者が Web からのアクセスが可能なディレクトリにファイルをアップロードし、アップロードしたファイルを PHP インタプリタに渡すことができる場合、これらのファイルに含まれている悪意あるコードがサーバーで実行される可能性があります。

例 1: 次のコードはアップロードされたファイルを処理し、処理したファイルを Web ルートの下のディレクトリに移動するものです。攻撃者は悪意ある PHP ソース ファイルをこのプログラムにアップロードし、続いてそれらのファイルをサーバーにリクエストします。その結果、それらのファイルは PHP インタープリターによって実行されます。

<?php
$udir = 'upload/'; // Relative path under Web root
$ufile = $udir . basename($_FILES['userfile']['name']);
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $ufile)) {
    echo "Valid upload received\n";
} else {
    echo "Invalid upload rejected\n";
} ?>

アップロードされたファイルが Web からアクセスできないディレクトリに保存された場合であっても、攻撃者はこの機能を利用してサーバー環境に悪意のあるコンテンツを持ち込み、その他の攻撃を仕掛ける可能性があります。プログラムが Path Manipulation、Command Injection、またはリモートインクルードの脆弱性の危険にさらされている場合、攻撃者は悪意のあるコンテンツを含んだファイルをアップロードし、別の脆弱性を悪用することによってそのファイルをプログラムで読み取る、あるいは実行させる可能性があります。

プログラムが記述されている言語に関係なく、最も被害が深刻な攻撃ではリモートからコード実行されることが多く、攻撃者はプログラムの権限で悪意あるコードを実行できます。攻撃者が Web からのアクセスが可能なディレクトリにファイルをアップロードし、アップロードしたファイルを Python インタプリタに渡すことができる場合、これらのファイルに含まれている悪意あるコードがサーバーで実行される可能性があります。

例 1: 次のコードはアップロードされたファイルを処理し、処理したファイルを Web ルートの下のディレクトリに移動するものです。攻撃者は悪意あるファイルをこのプログラムにアップロードし、続いてそれらのファイルをサーバーにリクエストします。

from django.core.files.storage import default_storage
from django.core.files.base import File
...
def handle_upload(request):
  files = request.FILES
  for f in files.values():
    path = default_storage.save('upload/', File(f))
...

アップロードされたファイルが Web からアクセスできないディレクトリに保存された場合であっても、攻撃者はこの機能を利用してサーバー環境に悪意のあるコンテンツを持ち込み、その他の攻撃を仕掛ける可能性があります。プログラムが Path Manipulation、Command Injection、またはリモートインクルードの脆弱性の危険にさらされている場合、攻撃者は悪意のあるコンテンツを含んだファイルをアップロードし、別の脆弱性を悪用することによってそのファイルをプログラムで読み取る、あるいは実行させる可能性があります。

プログラムが記述されている言語に関係なく、最も被害が深刻な攻撃ではリモートからコード実行されることが多く、攻撃者はプログラムの権限で悪意あるコードを実行できます。一般ユーザーが実行可能なファイルが保存されるディレクトリに攻撃者がファイルをアップロードできる場合には、これらのファイルに悪意あるコードを追加して、サーバで実行する可能性があります。

アップロードされたファイルが一般ユーザーがアクセスできないディレクトリに保存された場合であっても、攻撃者はこの機能を利用してサーバー環境に悪意のあるコンテンツを持ち込み、その他の攻撃を仕掛ける可能性があります。プログラムが Path Manipulation、Command Injection、またはリモートインクルードの脆弱性の危険にさらされている場合、攻撃者は悪意のあるコンテンツを含んだファイルをアップロードし、別の脆弱性を悪用することによってそのファイルをプログラムで読み取る、あるいは実行させる可能性があります。

プログラムが記述されている言語に関係なく、最も被害が深刻な攻撃ではリモートからコード実行されることが多く、攻撃者はプログラムの権限で悪意あるコードを実行できます。攻撃者が Web からのアクセスが可能なディレクトリにファイルをアップロードし、アップロードしたファイルをコードインタプリタ (JSP、ASPX、PHP など) に渡すことができる場合、これらのファイルに含まれている悪意あるコードがサーバーで実行される可能性があります。
アップロードされたファイルが Web からアクセスできないディレクトリに保存された場合であっても、攻撃者はこの機能を利用してサーバー環境に悪意のあるコンテンツを持ち込み、その他の攻撃を仕掛ける可能性があります。プログラムが Path Manipulation、Command Injection、または Dangerous File Inclusion の脆弱性の危険にさらされている場合、攻撃者は悪意のあるコンテンツを含んだファイルをアップロードし、別の脆弱性を悪用することによってそのファイルをプログラムで読み取る、あるいは実行させる可能性があります。

file タイプの <input> タグは、そのプログラムでファイルのアップロードが許可されていることを示します。
例:

<input type="file">