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

例 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 としてプロセスを実行している場合は、シグナルハンドラまたはサブプロセスはルート権限で動作します。攻撃者はこの昇格された権限を利用して、さらに大きな打撃を与える可能性があります。

SMS 関連の操作は、アプリケーションのコア機能に必要でない限り実行しないでください。モバイル デバイス向けに作成されたマルウェアはしばしば、こうした機能を悪用してユーザーからお金やデータを盗みます。

例 1: 次のケースでは、アプリケーションは SMS メッセージを送信するか、SMS メッセージを事前作成して、送信するかキャンセルするかの判断を求めるメッセージをユーザーに提示します。

...
[[CTMessageCenter sharedMessageCenter] sendSMSWithText:@"Hello world!" serviceCenter:nil toAddress:@"+12345678910"];
...

// or

...
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"sms:+12345678910"]];
...

// or

...
MFMessageComposeViewController *messageComposerVC = [[MFMessageComposeViewController alloc] init];

[messageComposerVC setMessageComposeDelegate:self];
[messageComposerVC setBody:@"Hello World!"];
[messageComposerVC setRecipients:[NSArray arrayWithObject:@"+12345678910"]];

[self presentViewController:messageComposerVC animated:YES completion:nil];
...

SMS 関連の操作は、アプリケーションのコア機能に必要でない限り実行しないでください。モバイル デバイス向けに作成されたマルウェアはしばしば、こうした機能を悪用してユーザーからお金やデータを盗みます。

例 1: 次のケースでは、アプリケーションは SMS メッセージを送信するか、SMS メッセージを事前作成して、送信するかキャンセルするかの判断を求めるメッセージをユーザーに提示します。

...
UIApplication.sharedApplication().openURL(NSURL(string: "sms:+12345678910"))
...

または

...
let messageComposeVC = MFMessageComposeViewController()
messageComposeVC.messageComposeDelegate = self
messageComposeVC.body = "Hello World!"
messageComposeVC.recipients = ["+12345678910"]

presentViewController(messageComposeVC, animated: true, completion: nil)
...

リダイレクトにより、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"

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

資格情報が暗号化されていないチャネルを通過できるようにする API 操作が検出されました。API 操作に対する OpenAPI の security の要件とターゲット servers の定義は、常にそれぞれのグローバル設定をオーバーライドします。

ただし、これらの設定が操作に対して定義されていない場合は、デフォルトでグローバルに指定された値になります。