許多 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 Framework 中，Decoder 和 Encoding 類別中的 GetChars 方法，以及 Encoder 和 Encoding 類別中的 GetBytes 方法，會在內部針對字元與位元組陣列進行指標算術運算，來將一系列字元轉換為一系列位元組，或是將一系列位元組轉換為一系列字元。
在執行指標算術運算時，開發人員通常會用不適當的方式覆寫上述方法，進而導致執行任意程式碼、濫用應用程式邏輯和 Denial of Service 等弱點。

若作業系統和在其上執行之應用程式之間的字元集不符，則傳送至預設 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)
...

如果仔細觀察輸出，「...」字元被會被翻譯成三個連續的句號。如果您比較輸出緩衝區和輸入緩衝區，則您的應用程式可能會面臨 Buffer overflow。其他字元可能對應至一個字元至兩個字元。希臘文的「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)
...

如果仔細觀察輸出，「...」字元被會被翻譯成三個連續的句號。如果您比較輸出緩衝區和輸入緩衝區，則您的應用程式可能會面臨 Buffer overflow。其他字元可能對應至一個字元至兩個字元。希臘文的「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() 呼叫就可能會溢出 outputDirectoryName 緩衝區，因為這個緩衝區比 MAX_PATH 位元組小。

已知識別的特定函數會盲目的遵循符號連接。發生此狀況時，您的應用程式將會開啟、讀取或寫入資料至符號連接指向的檔案，而非符號連接的代表。攻擊者可能欺騙應用程式寫入其他或重要的系統檔案，或向應用程式提供有問題的資料。

範例 1：以下程式碼會利用遵循符號連結的函數：

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

umask() 線上手冊以錯誤指令開頭：

「umask sets the umask to mask & 0777」

儘管這種做法最好遵從 chmod() 的用法，即使用者指定引數中某些位元值來控制檔案存取權限，但事實上 umask() 做的恰恰相反：umask() 將 umask 設為 ~mask & 0777。

umask() 線上手冊接下來描述了對於 umask() 的正確使用方式：

「umask 用來為新建立的檔案設定初始化檔案權限。特別是，umask 的權限關閉了 mode 引數 (例如，一般的 umask 預設值 022 會讓新建立的檔案擁有 0666 & ~022 = 0644 = rw-r--r--的權限，而在一般情況下，mode 應該為 0666)」。

許多 API 都會藉由完全寫入暫存檔案再完全複製該檔案至目標目的地的方式來最小化資料遺失風險。確保識別的方法不會在公開檔案或路徑，或是暫存目錄上運作，因為攻擊者可以在將暫存檔案寫入目標檔案前將其取代。如此可讓攻擊者控制應用程式在公開目錄中使用的檔案內容。

範例 1：以下程式碼會使用易受攻擊的方式將運作中的 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)
...

不論撰寫程式所使用的語言為何，毀壞性最大的攻擊通常都包含了遠端程式碼的執行，攻擊者可藉此在程式的上下文環境中成功的執行惡意程式碼。若攻擊者能夠上傳檔案至一個可從網路存取的目錄，並將這些檔案傳遞至程式碼解譯器 (例如 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 或 remote include 弱點，則攻擊者可能會上傳包含惡意內容的檔案，並利用另一個弱點使程式讀取或執行該檔案。

不論撰寫程式所使用的語言為何，毀壞性最大的攻擊通常都包含了遠端程式碼的執行，攻擊者可藉此在程式的上下文環境中成功的執行惡意程式碼。如果允許攻擊者上傳檔案到可從 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 或 Dangerous File Inclusion 的弱點，則攻擊者可能會上傳含有惡意內容的檔案並利用另一項弱點，使程式讀取或執行該檔。

不論撰寫程式所使用的語言為何，毀壞性最大的攻擊通常都包含了遠端程式碼的執行，攻擊者可藉此在程式的上下文環境中成功的執行惡意程式碼。若攻擊者可以上傳檔案至公開執行的目錄，則他們能在伺服器上執行包含在檔案中的惡意程式碼。

即使程式將上傳的檔案儲存於無法公開存取的目錄下，攻擊者仍可透過各種方式將惡意內容導入伺服器環境中以發動攻擊。如果程式容易出現 path manipulation、command injection 或 remote include 弱點，則攻擊者可能會上傳包含惡意內容的檔案，並利用另一個弱點使程式讀取或執行該檔案。

不論撰寫程式所使用的語言為何，毀壞性最大的攻擊通常都包含了遠端程式碼的執行，攻擊者可藉此在程式的上下文環境中成功的執行惡意程式碼。若攻擊者能夠上傳檔案至一個可從網路存取的目錄，並將這些檔案傳遞至程式碼解譯器 (例如 JSP/ASPX/PHP)，則他們可能會造成這些檔案內包含的惡意程式碼在伺服器上執行。
即使程式將上傳的檔案儲存於無法從 Web 存取的目錄下，攻擊者仍然可能透過向伺服器環境引入惡意內容中來發動其他攻擊。若程式容易有 Path Manipulation、Command Injection 或 Dangerous File Inclusion 的弱點，則攻擊者可能會上傳含有惡意內容的檔案並利用另一項弱點，使程式讀取或執行該檔。

file 類型的 <input> 標籤表示程式接受檔案上傳。
範例 1：

<input type="file">

使用 root 權限來執行程式，已經造成了無數的 Unix 安全災難。仔細的檢查您的程式授予的權限是否會引起安全問題是十分重要的，而把那些被授予權限的程式及時撤銷權限也是同等重要，才能把那些弱點引起的破壞控制到最小。


Privilege Management 函數有時會以一些不明顯的方式執行，而且在不同的平台上面會有較大差異。當你把一個非 root 使用者轉換為另外一個時，這種差異會尤其明顯。

訊號處理常式以及產生的處理會在所有處理的權限下執行，所以如果處理以 root 權限執行，當訊號發生或執行子處理時，該訊號處理常式或者子處理將會以 Root 權限執行。這樣攻擊者將有可能利用這一點來擴大弱點造成的破壞。

使用 root 權限來執行程式，已經造成了無數的 Unix 安全災難。仔細檢閱程式授予的權限是否會引起安全問題十分重要，而把那些被授予權限的程式及時撤銷權限也是同等重要，才能把那些弱點引起的破壞控制到最小。


Privilege Management 函數有時會以一些不明顯的方式執行，而且在不同的平台上面會有較大差異。當您把一個非 root 使用者轉換為其他使用者時，這種差異會尤其明顯。

訊號處理常式以及產生的程序會在所有程序的權限下執行，因此，如果程序以 root 權限執行，當訊號觸發或執行子程序時，該訊號處理常式或子程序將會以 Root 權限執行。攻擊者有可能利用這一點來擴大弱點造成的破壞。

使用 root 權限來執行程式，已經造成了無數的 Unix 安全災難。仔細的檢查您的程式授予的權限是否會引起安全問題是十分重要的，而把那些被授予權限的程式及時撤銷權限也是同等重要，才能把那些弱點引起的破壞控制到最小。


Privilege Management 函數有時會以一些不明顯的方式執行，而且在不同的平台上面會有較大差異。當你把一個非 root 使用者轉換為另外一個時，這種差異會尤其明顯。

訊號處理常式以及產生的處理會在所有處理的權限下執行，所以如果處理以 root 權限執行，當訊號發生或執行子處理時，該訊號處理常式或者子處理將會以 Root 權限執行。這樣攻擊者將有可能利用這一點來擴大弱點造成的破壞。

除非 SMS 相關作業對於應用程式的核心功能至關重要，否則不應執行 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 相關作業對於應用程式的核心功能至關重要，否則不應執行 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，以確定該連結是指向他們知悉的可信任網站。不過，如果攻擊者使用 Hex 以下列方式編碼目標的 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：使用者按一下連結時，下列 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，以確定該連結是指向他們知悉的可信任網站。不過，如果攻擊者使用 Hex 以下列方式編碼目標的 URL：
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

那麼，即使再有經驗的終端使用者也可能會被誘騙進入以下連結。

允許未經驗證的輸入控制重新導向中所使用的 URL 有助於網路釣魚攻擊。重新導向會在相同 Web 應用程式中將使用者導引到不同的網頁，或導引到外部網站。應用程式會使用重新導向協助站台內的導覽，且在某些情況下，會追蹤使用者離開網站的方法。Web 應用程式將用戶端重新導向至攻擊者可以控制的任意 URL 時，會發生 Open Redirect 弱點。

攻擊者可能利用 Open Redirect 誘騙使用者造訪可信任網站的 URL，但接著會將其重新導向至惡意網站。透過對 URL 進行編碼，攻擊者可讓一般使用者難以注意到重新導向的惡意目標，即使將這個目標當作 URL 參數傳遞到受信任的網站也是如此。Open Redirect 通常為網路釣魚所使用的方法之一，可用來取得敏感的一般使用者資料。

範例 1：以下 Visualforce 動作方法會傳回 PageReference 物件，其包含來自 dest 要求參數的 URL。

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 應用程式中將使用者導引到不同的網頁，或導引到外部網站。應用程式會利用重新導向協助站台內的導覽，且在某些情況下，會追蹤使用者離開網站的方法。Web 應用程式將用戶端重新導向至可由攻擊控制的任何任意 URL 時，會發生 Open Redirect 弱點。

攻擊者可能利用 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，以確定連結是指向他們知悉的可信任網站。不過，如果攻擊者使用 Hex 以下列方式編碼目標的 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 弱點。

攻擊者可利用 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，以確定連結是指向他們知悉的可信任網站。不過，如果攻擊者使用 Hex 以下列方式編碼目的地 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：當使用者按一下連結時，以下 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，以確定該連結是指向他們知悉的可信任網站。不過，如果攻擊者使用 Hex 以下列方式編碼目標的 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：當使用者按一下連結時，下列 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，以確定該連結是指向他們知悉的可信任網站。不過，如果攻擊者使用 Hex 以下列方式編碼目標的 URL：
"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，以確定該連結是指向他們知悉的可信任網站。不過，如果攻擊者使用 Hex 以下列方式編碼目標的 URL：
"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，以確定該連結是指向他們知悉的可信任網站。不過，如果攻擊者使用 Hex 以下列方式編碼目標的 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：以下 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，以確定該連結是指向他們知悉的可信任網站。不過，如果攻擊者使用 Hex 以下列方式編碼目標的 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：以下 Play 控制項方法指示使用者的瀏覽器開啟從 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，以確定該連結是指向他們知悉的可信任網站。不過，如果攻擊者使用 Hex 以下列方式編碼目標的 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：以下程式碼會處理使用應用程式自訂 URL 架構的任何要求，將 requestToLoad 設定為指向原始 URL 的「dest」參數 (如果存在的話) 以及指向使用 http:// 架構的原始 URL，最後在 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，以確定該連結是指向他們知悉的可信任網站。不過，如果攻擊者使用 Hex 以下列方式編碼目標的 URL：

"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，以確定該連結是指向他們知悉的可信任網站。不過，如果攻擊者使用 Hex 以下列方式編碼目標的 URL：
"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 定義永遠會覆寫各自的全域設定。

但是，如果未針對某項操作定義這些設定，這些設定就會預設為全域指定的值。