プログラムが記述されている言語に関係なく、最も被害が深刻な攻撃ではリモートからコード実行されることが多く、攻撃者はプログラムの権限で悪意あるコードを実行できます。.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 が発生します。

例 1:

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 のタイプです。
例 1:

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

<input type="file">

UNIX 環境では、root 権限を使って実行するプログラムが原因で無数のセキュリティ被害が発生しています。多種のセキュリティ問題に対して、権限を必要とするプログラムを注意深く調べることは非常に大切です。しかし、それ以上に重要なのは、見逃された脆弱性によって発生する被害の拡大を防ぐために、権限を持ったプログラムを権限のない状態になるべく早く戻すことです。


Privilege Management 関数の動作は明確ではなく、異なる環境では異なる結果を招きます。こうした非一貫性は、root 以外のユーザー間で移動する場合にとりわけ顕著に現れます。

シグナルハンドラおよび生成されたプロセスは所有プロセスの権限で実行されます。したがって、シグナルを実行したりサブプロセスを実行したりするときに root としてプロセスを実行している場合は、シグナルハンドラまたはサブプロセスはルート権限で動作します。攻撃者はこの昇格された権限を利用して、さらに大きな打撃を与える可能性があります。

root 権限で実行されるプログラムは、数え切れないほどの Unix セキュリティ災害を引き起こしてきました。権限が必要なプログラムにあらゆる種類のセキュリティ上の問題がないか慎重に検討することは必要ですが、見落とされた脆弱性が引き起こす被害を最小限に抑えるために、権限が必要なプログラムの権限をできるだけ早く降格することも同様に重要です。


権限管理機能は、目立たない方法で動作することがあり、また、プラットフォームによって異なる癖があります。このような不整合は、ある非 root ユーザーから別のユーザーに移行する場合に特に顕著になります。

シグナル ハンドラーや生成されたプロセスは、所有するプロセスの権限で実行されるため、シグナルが発生したときやサブプロセスが実行されたときにプロセスが root として実行されている場合、シグナル ハンドラーやサブプロセスは root 権限で動作します。攻撃者は、これらの昇格された特権を利用して、さらなる損害を与えることができる可能性があります。

UNIX 環境では、root 権限を使って実行するプログラムが原因で無数のセキュリティ被害が発生しています。多種のセキュリティ問題に対して、権限を必要とするプログラムを注意深く調べることは非常に大切です。しかし、それ以上に重要なのは、見逃された脆弱性によって発生する被害の拡大を防ぐために、権限を持ったプログラムを権限のない状態になるべく早く戻すことです。


Privilege Management 関数の動作は明確ではなく、異なる環境では異なる結果を招きます。こうした非一貫性は、root 以外のユーザー間で移動する場合にとりわけ顕著に現れます。

シグナルハンドラおよび生成されたプロセスは所有プロセスの権限で実行されます。したがって、シグナルを実行したりサブプロセスを実行したりするときに root としてプロセスを実行している場合は、シグナルハンドラまたはサブプロセスはルート権限で動作します。攻撃者はこの昇格された権限を利用して、さらに大きな打撃を与える可能性があります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の ABAP コードはユーザーのブラウザに対して、ユーザーがリンクをクリックしたタイミングで dest リクエストパラメーターからパースされた URL を開くように命令しています。

...
DATA: str_dest TYPE c.

str_dest = request->get_form_field( 'dest' ).
response->redirect( str_dest ).
...

たとえば、攻撃対象が "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックします。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の ActionScript コードはユーザーのブラウザに対して、ユーザーがリンクをクリックしたタイミングで dest リクエストパラメーターから読み取られた URL を開くように命令しています。

        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var strDest:String = String(params["dest"]);
        host.updateLocation(strDest);
        ...

たとえば、攻撃対象が "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックします。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトに使用される URL が未検証の入力によって制御されると、フィッシング攻撃を容易にしてしまう可能性があります。Web アプリケーションはリダイレクトにより、ユーザーが同一アプリケーション内の別のページまたは外部サイトにアクセスするよう方向付けます。アプリケーションでは、サイト ナビゲーションに役立てるためにリダイレクトが使用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。Open Redirect 脆弱性は、Web アプリケーションでクライアントがリダイレクトされる宛先が、攻撃者による制御が可能な任意の URL である場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の Visualforce アクション メソッドは、dest リクエスト パラメーターからの URL を含む PageReference オブジェクトを返します。

public PageReference pageAction() {
    ...
    PageReference ref = ApexPages.currentPage();
    Map<String,String> params = ref.getParameters();
    return new PageReference(params.get('dest'));
}

たとえば、攻撃対象のユーザーが "http://trusted.vf.force.com/apex/vfpage?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックするはずです。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザーは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが確実に既知の信頼できるサイトを指し示しているかどうか必ず調べるよう教えられています。しかし、攻撃者はリンク先の URL を次のようにエンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえも、だまされてリンクにアクセスしてしまうことがあります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次のコードはユーザーのブラウザに対して、ユーザーがリンクをクリックしたタイミングで dest リクエストパラメーターからパースされた URL を開くように命令しています。

    String redirect = Request["dest"];
    Response.Redirect(redirect);

たとえば、攻撃対象のユーザーが http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックするはずです。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL をエンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

Web アプリケーションはリダイレクトにより、ユーザーが同一アプリケーション内の別のページまたは外部サイトにアクセスするよう方向付けます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。Open Redirect 脆弱性は、Web アプリケーションでクライアントがリダイレクトされる宛先が、攻撃者による制御が可能な任意の URL である場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の JSP コードでは、ユーザーのブラウザーに対し、ユーザーがリンクをクリックしたタイミングで、dest リクエスト パラメーターからパースされた URL を開くよう指示しています。

    ...
    final server = await HttpServer.bind(host, port);
      await for (HttpRequest request in server) {
        final response = request.response;
        final headers = request.headers;
        final strDest = headers.value('strDest');
        response.headers.contentType = ContentType.text;
        response.redirect(Uri.parse(strDest!));
        await response.close();
      }
    ...

たとえば、攻撃対象が "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックします。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが確実に既知の信頼できるサイトを指し示しているかどうか必ず調べるよう教えられています。しかし、攻撃者はリンク先の URL を次のように Hex エンコードする場合があります。
「http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D」

このような場合、知識の豊富なエンドユーザーでさえも、だまされてリンクにアクセスしてしまうことがあります。

Web アプリケーションはリダイレクトにより、ユーザーが同一アプリケーション内の別のページまたは外部サイトにアクセスするよう方向付けます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。Open Redirect 脆弱性は、Web アプリケーションでクライアントがリダイレクトされる宛先が、攻撃者による制御が可能な任意の URL である場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次のコードでは、ユーザーのブラウザーに対し、ユーザーがリンクをクリックしたタイミングで、dest リクエスト パラメーターからパースされた URL を開くよう指示しています。

    ...
    strDest := r.Form.Get("dest")
    http.Redirect(w, r, strDest, http.StatusSeeOther)
    ...

たとえば、攻撃対象のユーザーが「http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com」へのリンクをクリックするよう指示する電子メールを受信した場合、高い確率で、信頼されているサイトへ転送されるものと信じてこのリンクをクリックします。しかし、攻撃対象のユーザーがこのリンクをクリックすると、Example 1 のコードによって、ブラウザーは「http://www.wilyhacker.com」にリダイレクトされます。

多くのユーザーは、電子メールで受け取った URL のリンクが確実に既知の信頼できるサイトを指し示しているかどうか必ず調べるよう教えられています。しかし、攻撃者はリンク先の URL を次のように Hex エンコードする場合があります。
「http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D」

このような場合、知識の豊富なエンドユーザーでさえも、だまされてリンクにアクセスしてしまうことがあります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の JavaScript コードはユーザーのブラウザに対して、ユーザーがリンクをクリックしたタイミングで dest リクエスト パラメーターから読み取られた URL を開くように命令しています。

	...
	strDest = form.dest.value;
	window.open(strDest,"myresults");
	...

たとえば、攻撃対象が "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックします。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の PHP コードはユーザーのブラウザに対して、ユーザーがリンクをクリックしたタイミングで dest リクエストパラメーターからパースされた URL を開くように命令しています。

    <%
        ...
        $strDest = $_GET["dest"];
        header("Location: " . $strDest);
        ...
    %>

たとえば、攻撃対象のユーザーが "http://trusted.example.com/ecommerce/redirect.php?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックするはずです。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect.php?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次のプロシージャーはユーザーのブラウザに対して、ユーザーがリンクをクリックしたタイミングで dest リクエストパラメーターからパースされた URL を開くように命令しています。

      ...
      -- Assume QUERY_STRING looks like dest=http://www.wilyhacker.com
      dest := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 6);
      OWA_UTIL.redirect_url('dest');
      ...
  

たとえば、攻撃対象のユーザーが "http://trusted.example.com/pls/hr/showemps?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックするはずです。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://trusted.example.com/pls/hr/showemps?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の Python コードはユーザーのブラウザに対して、ユーザーがリンクをクリックしたタイミングで dest リクエストパラメーターからパースされた URL を開くように命令しています。

        ...
        strDest = request.field("dest")
        redirect(strDest)
        ...

たとえば、攻撃対象が "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックします。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の Ruby コードはユーザーのブラウザに対して dest リクエスト パラメーターからパースされた URL を開くように命令しています。

...
str_dest = req.params['dest']
...
res = Rack::Response.new
...
res.redirect("http://#{dest}")
...

たとえば、攻撃対象が "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックします。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次のプレイ コントローラー メソッドはユーザーのブラウザに対して dest リクエスト パラメーターからパースされた URL を開くように命令しています。

  def myAction = Action { implicit request =>
    ...
    request.getQueryString("dest") match {
      case Some(location) => Redirect(location)
      case None => Ok("No url found!")
    }
    ...
  }

たとえば、攻撃対象が "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックします。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次のコードは、アプリケーションのカスタム URL スキームを使用するあらゆるリクエストを処理し、元の URL の "dest" パラメーター (ある場合) をポイントするように、および http:// スキームを使用して元の URL をポイントするように requestToLoad を設定し、さらにこのリクエストを WKWebView 内でロードします。

AppDelegate.swift:

...
let requestToLoad : String
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
  ...
  if let urlComponents = NSURLComponents(URL: url, resolvingAgainstBaseURL: false) {
    if let queryItems = urlComponents.queryItems as? [NSURLQueryItem]{
      for queryItem in queryItems {
        if queryItem.name == "dest" {
          if let value = queryItem.value {
            request = NSURLRequest(URL:NSURL(string:value))
            requestToLoad = request
            break
          }
        }
      }
    }
    if requestToLoad == nil {
        urlComponents.scheme = "http"
        requestToLoad = NSURLRequest(URL:urlComponents.URL)
    }
  }
  ...
}
...

ViewController.swift

...
let webView : WKWebView
let appDelegate = UIApplication.sharedApplication().delegate as! AppDelegate
webView.loadRequest(appDelegate.requestToLoad)
...

被害者は、"custom_url_scheme://innocent_url?dest=www.wilyhacker.com" へのリンクに従うように指示する電子メールを受け取った場合、実行される動作に害は何もないと信じてそのリンクをクリックすることが考えられます。実際には、被害者がこのリンクをクリックすると、Example 1 のコードによって WKWebView で "http://www.wilyhacker.com" がリクエストおよびロードされます。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。

"custom_url_scheme://innocent_url?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

リダイレクトにより、Web アプリケーションは同一アプリケーション内の別のページまたは外部サイトにアクセスするようにユーザーを仕向けることができます。アプリケーションでは、サイトナビゲーションに役立てるためにリダイレクトが利用されます。また、場合によってはユーザーがサイトを終了する方法を追跡するためにも利用されます。オープンリダイレクトの脆弱性は、Web アプリケーションにおいて攻撃者による制御が可能な任意の URL にクライアントがリダイレクトされる場合に発生します。

Open Redirect を利用する攻撃者は、ユーザーが信頼されるサイトの URL にアクセスするように仕組み、それからそのユーザーを悪意あるサイトにリダイレクトさせます。その URL を攻撃者がエンコーディングした場合、信頼されるサイトへ URL パラメーターとして渡されても、リダイレクト先が悪意あるサイトである、ということに、エンドユーザーは気付きにくくなります。Open Redirect は多くの場合、エンドユーザーの機密データを収集するためのフィッシング攻撃の一部として悪用されます。

例 1: 次の VB コードはユーザーのブラウザに対して、ユーザーがリンクをクリックしたタイミングで dest リクエストパラメータからパースされた URL を開くように命令しています。

	...
	strDest = Request.Form('dest')
	HyperLink.NavigateTo strDest
	...

たとえば、攻撃対象のユーザーが "http://www.trustedsite.com/ecommerce/redirect.asp?dest=www.wilyhacker.com" へのリンクをクリックするよう指示している電子メールを受信した場合、このユーザーは高い確率で、信頼されているサイトに転送されると信じてこのリンクをクリックするはずです。しかし、攻撃対象がこのリンクをクリックすると、Example 1 のコードによってブラウザは "http://www.wilyhacker.com" にリダイレクトされることになります。

多くのユーザーは、電子メールで受け取った URL のリンクが既知の信頼できるサイトを指し示しているかどうか確認するように教えられています。しかし、攻撃者は次のようにリンク先の URL を Hex エンコードする場合があります。
"http://www.trustedsite.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

このような場合、知識の豊富なエンドユーザーでさえもだまされてリンクにアクセスしてしまう可能性があります。

Password Management の問題が発生するのは、アプリケーションのプロパティや設定ファイルにパスワードが平文で保管される場合です。
例 1: 次のコードはプロパティ ファイルからパスワードを読み取り、そのパスワードを使用して URL リクエストのデフォルトの認証情報を設定しています。

...
var fs:FileStream = new FileStream();
fs.open(new File("config.properties"), FileMode.READ);
var password:String = fs.readMultiByte(fs.bytesAvailable, File.systemCharset);

URLRequestDefaults.setLoginCredentialsForHost(hostname, usr, password);
...

このコードは正常に動作しますが、config.properties にアクセスできる全員が passwordの値を読むことができます。不心得な従業員がこの情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。

アプリケーションの設定ファイルなどのデータストアにパスワードが平文で保管されるている場合、Password Management の問題が発生します。
例 1: 次のコードはレジストリからパスワードを読み込み、そのパスワードを使用して新しいネットワーク認証情報を作成しています。

...
string password = regKey.GetValue(passKey).ToString());
NetworkCredential netCred =
           new NetworkCredential(username,password,domain);
...

このコードは正常に動作しますが、パスワードを保管するために使用されているレジストリ キーにアクセスできる全員が passwordの値を読み取れます。不心得な従業員がこの情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。

アプリケーションの設定ファイルなどのデータストアにパスワードが平文で保管されるている場合、Password Management の問題が発生します。
例 1: 次のコードでは、レジストリからパスワードを読み取り、そのパスワードを使用してデータベースに接続しています。

...
RegQueryValueEx(hkey,TEXT(.SQLPWD.),NULL,
                NULL,(LPBYTE)password, &size);
rc = SQLConnect(*hdbc, server, SQL_NTS, uid,
                SQL_NTS, password, SQL_NTS);
...

このコードは正常に動作しますが、パスワードの保存に使用されるレジストリ キーにアクセスできる全員が password の値を読み取ることができます。不心得な従業員がパスワード情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。

Password Management の問題が発生するのは、アプリケーションのプロパティや設定ファイルにパスワードが平文で保管される場合です。
例 1: 次のコードはプロパティファイルからパスワードを読み取り、そのパスワードを使用してデータベースに接続しています。

...
01  RECORD.
     05  UID              PIC X(10).
     05  PASSWORD         PIC X(10).
...
EXEC CICS
  READ
  FILE('CFG')
  INTO(RECORD)
  RIDFLD(ACCTNO)
  ...
END-EXEC.

EXEC SQL
  CONNECT :UID
  IDENTIFIED BY :PASSWORD
  AT :MYCONN
  USING :MYSERVER
END-EXEC.
...

このコードは正常に動作しますが、CFGにアクセスできる全員がパスワードの値を読むことができます。不心得な従業員がこの情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。

Password Management の問題が発生するのは、アプリケーションの設定ファイルやデータベースにパスワードが平文で保管されることが許可される場合です。
例 1: 次のコードは Web フォームからパスワードを読み取り、そのパスワードを使用してデータベースに接続しています。

<cfquery name = "GetCredentials" dataSource = "master">
SELECT   Username, Password
FROM     Credentials
WHERE    DataSource="users"
</cfquery>
...
<cfquery name = "GetSSNs" dataSource = "users"
 username = "#Username#" password = "#Password#">
SELECT   SSN
FROM     Users
</cfquery>
...

このコードは正常に動作しますが、テーブル masterにアクセスできる全員が Username と Password の値を読み取ることができます。不心得な従業員がこの情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。

Password Management の問題が発生するのは、アプリケーションのプロパティや設定ファイルにパスワードが平文で保管される場合です。
例 1: 次のコードでは、JSON ファイルからパスワードを読み取り、そのパスワードを使用してリクエストの認証ヘッダーを設定します。

...
file, _ := os.Open("config.json")
decoder := json.NewDecoder(file)
decoder.Decode(&values)

request.SetBasicAuth(values.Username, values.Password)
...

このコードは正常に動作しますが、config.json にアクセスできる全員が values.Password の値を読み取ることができます。不心得な従業員がこの情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。

アプリケーションにパスワードが平文で保管されている場合、Password Management の問題が発生します。
例 1: 次のコードは、ハードコーディングされたパスワードを使用してアプリケーションに接続し、アドレス帳のエントリを取得しています。

    ...
    obj = new XMLHttpRequest();
    obj.open('GET','/fetchusers.jsp?id='+form.id.value,'true','scott','tiger');
    ...

このコードは正常に実行されますが、含まれる Web ページにアクセスする全員がパスワードを閲覧できます。

Password Management の問題が発生するのは、アプリケーションのプロパティや設定ファイルにパスワードが平文で保管される場合です。
例 1: 次のコードは、plist ファイルからパスワードを読み取り、読み取ったパスワードを使用してパスワードで保護されたファイルを解凍します。

...
NSDictionary *dict= [NSDictionary dictionaryWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"Config" ofType:@"plist"]];
NSString *password = [dict valueForKey:@"password"];
[SSZipArchive unzipFileAtPath:zipPath toDestination:destPath overwrite:TRUE password:password error:&error];
...

モバイル環境では、デバイスをなくす機会が高いことを考慮すると、パスワード管理は特に重要です。

Password Management の問題が発生するのは、アプリケーションのプロパティや設定ファイルにパスワードが平文で保管される場合です。
例 1: 次のコードはプロパティファイルからパスワードを読み取り、そのパスワードを使用してデータベースに接続しています。

...
$props = file('config.properties', FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);
$password = $props[0];

$link = mysql_connect($url, $usr, $password);
if (!$link) {
    die('Could not connect: ' . mysql_error());
}
...

このコードは正常に動作しますが、config.properties にアクセスできる全員が passwordの値を読むことができます。不心得な従業員がこの情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。

パスワードがハードコーディングされていたり、アプリケーションの設定ファイルなどのデータストアにパスワードが平文で保管されている場合、Password Management の問題が発生します。パスワードをハードコーディングするのはよくない発想です。パスワードをハードコーディングするとプロジェクトの開発者全員がパスワードを見ることができるだけでなく、問題の修復も非常に困難になります。コードが実運用に入ると、ソフトウェアにパッチを当てないとパスワードを変更できません。このパスワードによって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性の二者択一を強いられます。
例 1: 次のコードは、ユーザーがデータベース サーバーにログインするために使用したパスワードを読み込み、期待される値と比較することでユーザー認証を行っています。

...
ip_address := OWA_SEC.get_client_ip;
IF ((OWA_SEC.get_user_id = 'scott') AND
    (OWA_SEC.get_password = 'tiger') AND
    (ip_address(1) = 144) and (ip_address(2) = 25)) THEN
        RETURN TRUE;
ELSE
        RETURN FALSE;
END IF;
...

このコードは正常に動作しますが、コードにアクセスできる全員がパスワードを入手できます。プログラムが頒布された後は、プログラムにパッチを適用しない限り、「tiger」というパスワードを持つデータベース ユーザー「scott」を変更することはできません。この情報へのアクセス権を持っている従業員が、権限を使用してシステムに侵入する可能性があります。

Password Management の問題が発生するのは、アプリケーションのプロパティや設定ファイルにパスワードが平文で保管される場合です。
例 1: 次のコードはプロパティファイルからパスワードを読み取り、そのパスワードを使用してデータベースに接続しています。

...
props = os.open('config.properties')
password = props[0]

link = MySQLdb.connect (host = "localhost",
                           user = "testuser",
                           passwd = password,
                           db = "test")
...

このコードは正常に動作しますが、config.properties にアクセスできる全員が passwordの値を読むことができます。不心得な従業員がこの情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。

アプリケーションの設定ファイルなどのデータストアにパスワードが平文で保管されるている場合、Password Management の問題が発生します。
例 1: 次のコードでは、環境変数からパスワードを読み取り、そのパスワードを使用してデータベースに接続しています。

require 'pg'
...
passwd = ENV['PASSWD']
...
conn = PG::Connection.new(:dbname => "myApp_production", :user => username, :password => passwd, :sslmode => 'require')

このコードは正常に動作しますが、パスワードを保管するために使用されている環境変数にアクセスできる全員が PASSWDの値を読み取れます。不心得な従業員がこの情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。

Password Management の問題が発生するのは、アプリケーションのプロパティや設定ファイルにパスワードが平文で保管される場合です。
例 1: 次のコードはプロパティファイルからパスワードを読み取り、そのパスワードを使用してデータベースに接続しています。

...
val prop = new Properties()
prop.load(new FileInputStream("config.properties"))
val password = prop.getProperty("password")

DriverManager.getConnection(url, usr, password)
...

このコードは正常に動作しますが、config.propertiesにアクセスできる全員がpassword の値を読むことができます。不心得な従業員がパスワード情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。

Password Management の問題が発生するのは、アプリケーションのプロパティや設定ファイルにパスワードが平文で保管される場合です。
例 1: 次のコードは、plist ファイルからパスワードを読み取り、読み取ったパスワードを使用してパスワードで保護されたファイルを解凍します。

...
var myDict: NSDictionary?
if let path = NSBundle.mainBundle().pathForResource("Config", ofType: "plist") {
    myDict = NSDictionary(contentsOfFile: path)
}
if let dict = myDict {
    zipArchive.unzipOpenFile(zipPath, password:dict["password"])
}
...

モバイル環境では、デバイスをなくす機会が高いことを考慮すると、パスワード管理は特に重要です。

Password Management の問題が発生するのは、アプリケーションのプロパティや設定ファイルにパスワードが平文で保管される場合です。
例 1: 次のコードはプロパティファイルからパスワードを読み取り、そのパスワードを使用してデータベースに接続しています。

...
Private Declare Function GetPrivateProfileString _
  Lib "kernel32" Alias "GetPrivateProfileStringA" _
  (ByVal lpApplicationName As String, _
  ByVal lpKeyName As Any, ByVal lpDefault As String, _
  ByVal lpReturnedString As String, ByVal nSize As Long, _
  ByVal lpFileName As String) As Long
...
Dim password As String
...
password = GetPrivateProfileString("MyApp", "Password", _
  "", value, Len(value), _
   App.Path & "\" & "Config.ini")
...
con.ConnectionString = "Driver={Microsoft ODBC for Oracle};Server=OracleServer.world;Uid=scott;Passwd=" & password &";"
...

このコードは正常に動作しますが、config.properties にアクセスできる全員が passwordの値を読むことができます。不心得な従業員がこの情報へのアクセス権を持っている場合、システムに侵入するために使用されることがあります。

空の文字列をパスワード変数に割り当てるのは、いかなる場合でもよくない発想です。別のシステムへの認証に空のパスワードが使用される場合、空のパスワードを受け付けてしまうため、そのアカウントのセキュリティが危険にさらされます。空のパスワードは、適正な値が変数に割り当てられるまでの単なるプレースホルダーとなっている場合に、コードに習熟していないユーザーが混乱したり、予期せぬ制御フローパスで問題が発生したりする可能性があります。

例 1: 次のコードは、空のパスワード変数を初期化します。

...
password = ''.
...

空の文字列をパスワード変数に割り当てるのは、いかなる場合でもよくない発想です。別のシステムへの認証に空のパスワードが使用される場合、空のパスワードを受け付けてしまうため、そのアカウントのセキュリティが危険にさらされます。空のパスワードは、適正な値が変数に割り当てられるまでの単なるプレースホルダーとなっている場合に、コードに習熟していないユーザーが混乱したり、予期せぬ制御フローパスで問題が発生したりする可能性があります。

例 1: 次のコードは、パスワードに空の文字列を指定して、URL リクエストのデフォルトの認証情報を設定しようとしています。

    ...
    URLRequestDefaults.setLoginCredentialsForHost(hostname, "scott", "");
    ...

Example 1 のコードは、ユーザー アカウント「scott」に空のパスワードが設定されており、このパスワードが攻撃者によって簡単に推測されることを示します。プログラムが頒布された後、空ではないパスワードを使用するようにこのアカウントを更新するには、コードの変更が必要となります。

例 2: 次のコードは、パスワード変数を空の文字列に初期化し、格納されているパスワード値の読み取りを試行し、ユーザーが指定した値とその値を比較します。

    ...
    var storedPassword:String = "";
    var temp:String;

    if ((temp = readPassword()) != null) {
        storedPassword = temp;
    }

    if(storedPassword.equals(userPassword))
        // Access protected resources
        ...
    }
    ...

readPassword() が、データベースエラーやその他の問題により格納されているパスワードの取得に失敗する場合、攻撃者は、userPassword に空の文字列を指定して、パスワードチェックを迂回する可能性があります。

空のパスワードの使用は推奨されません。空のパスワードによって保護されたアカウントが危険にさらされると、システムの所有者はセキュリティと可用性のいずれかを選択しなければなりません。コードが実運用に入った後でシステムにパッチを適用することは非常に困難になるためです。

例 1: 次のコードは、空のパスワードを使用してクライアント証明書を認証します。

...
HttpRequest req = new HttpRequest();
req.setClientCertificate('mycert', '');
...

コードが正常に実行されると、証明書が空のパスワードで設定されたことが示されるため、攻撃者によってパスワードが簡単に推測されてしまいます。