许多 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 方法在内部对字符数组和字节数组执行指针运算，以将字符范围转换为字节数范围，反之亦然。
在执行指针算术运算时，开发人员通常会以错误的方式覆盖上述方法，进而引入诸如任意代码执行、应用程序逻辑滥用和拒绝服务等漏洞。

当操作系统及其上运行的应用程序之间的字符集不匹配时，传递给默认 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)
...

如果仔细查看输出，您会发现“...”字符已转换成三个连续的句号。如果根据输出缓冲区调整了输出缓冲区大小，则应用程序易受缓冲区溢出攻击。其他字符可从一个字符映射到两个。希腊字符“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)
...

如果仔细查看输出，您会发现“...”字符已转换成三个连续的句号。如果根据输出缓冲区调整了输出缓冲区大小，则应用程序易受缓冲区溢出攻击。其他字符可从一个字符映射到两个。希腊字符“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() man page 以错误的指令开始：

“umask sets the umask to mask & 0777”

尽管这种行为可以更好地遵从 chmod() 的用法，这种情况下，由用户提供的参数指定在特定文件上启用的位数，但事实上 umask() 的行为恰恰相反：umask() 将 umask 设为 ~mask & 0777。

umask() man page 接下来描述了 umask() 的正确使用方法：

“umask 用于为新建文件设置初始文件权限。具体的说，将会通过 mode 参数关闭 umask 中的权限（例如，umask 的通用默认值 022 会导致以权限 0666 & ~022 = 0644 = rw-r--r-- 创建新文件，而在正常情况下，mode 应该为 0666）。”

许多 API 通过完全写入临时文件，然后再将整个文件复制到目标位置，来最大限度地降低数据丢失的风险。确保识别的方法不会用于公共或临时目录中的文件或路径，因为攻击者会在临时文件写入目标文件之前将其即时替换。这使攻击者能够控制公共目录中应用程序使用的文件内容。

示例 1：以下代码使用易受攻击的方法将活动的 transactionId 写入应用程序 Documents 目录下的一个临时文件：

...
//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 或危险的 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 或 remote include 漏洞，那么攻击者就可能上传带恶意内容的文件，并利用另一种漏洞促使程序读取或执行该文件。

无论编写程序所用的语言是什么，最具破坏性的攻击通常都会涉及执行远程代码，攻击者借此可在程序上下文中成功执行恶意代码。如果允许攻击者上传文件到公开的可执行目录中，则他们可以让这些文件中包含的恶意代码在服务器上执行。

即使程序将上传的文件存储在一个无法公开访问的目录中，攻击者仍然有可能通过向服务器环境引入恶意内容来发动其他攻击。如果程序容易出现 path manipulation、command injection 或 remote include 漏洞，那么攻击者就可能上传带恶意内容的文件，并利用另一种漏洞促使程序读取或执行该文件。

无论编写程序所用的语言是什么，最具破坏性的攻击通常都会涉及执行远程代码，攻击者借此可在程序上下文中成功执行恶意代码。如果允许攻击者向某个可通过 Web 访问的目录上传文件，并能够将这些文件传递给代码解释器（如 JSP/ASPX/PHP），他们就能促使这些文件中包含的恶意代码在服务器上执行。
即使程序将上传的文件存储在一个无法通过 Web 访问的目录中，攻击者仍然有可能通过向服务器环境引入恶意内容来发动其他攻击。如果程序容易出现 path manipulation、command injection 或危险的 file inclusion 漏洞，那么攻击者就可能上传带恶意内容的文件，并利用另一种漏洞促使程序读取或执行该文件。

类型为 file 的 <input> 标签表示程序接受文件上传。
示例 1：

<input type="file">

利用 root 权限运行的程序已经造成了无数的 Unix 安全灾难。仔细检查您的程序授权是否会引发安全问题十分必要，同样重要的是，对那些授予了权限的应用程序，应及时撤销其权限并返回至未授权状态，把因忽略漏洞而引发的破坏控制到最小。


Privilege management 函数有时会以一些不明显的方式运行，并且它们在不同的平台上面会有较大差异。当您从一个非 root 用户切换到另外一个用户时，这种差异会尤其明显。

信号处理程序以及产生的进程会在其本身进程所具有的权限运行，所以当触发某一个信号或执行子进程时，一个进程以 root 权限运行，信号处理程序或者子进程将会以 Root 权限运行。因此，攻击者有可能利用这个提高的权限来进行更严重的破坏。

以 root 权限运行的程序已导致了无数的 Unix 安全灾难。您必须仔细审查特权程序是否存在各种安全问题，但同样重要的是，特权程序应尽快恢复到非特权状态，以限制被忽略的漏洞可能造成的损害。


权限管理功能可能会以一些不太明显的方式运行，并且它们在不同平台上具有不同的特性。如果您从一个非 root 用户转换到另一个非 root 用户，这些不一致尤为明显。

信号处理程序和派生的流程以所拥有流程的权限运行，因此，如果在触发信号或执行子流程时某个流程以 root 身份运行，则信号处理程序或子流程将以 root 权限运行。攻击者可能会利用这些提升的权限进行进一步的破坏。

利用 root 权限运行的程序已经造成了无数的 Unix 安全灾难。仔细检查您的程序授权是否会引发安全问题十分必要，同样重要的是，对那些授予了权限的应用程序，应及时撤销其权限并返回至未授权状态，把因忽略漏洞而引发的破坏控制到最小。


Privilege management 函数有时会以一些不明显的方式运行，并且它们在不同的平台上面会有较大差异。当您从一个非 root 用户切换到另外一个用户时，这种差异会尤其明显。

信号处理程序以及产生的进程会在其本身进程所具有的权限运行，所以当触发某一个信号或执行子进程时，一个进程以 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 漏洞：

攻击者可能利用 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 进行 16 进制编码：
"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：以下 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 进行 16 进制编码：
"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 漏洞：

攻击者可能利用 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，以确保链接指向他们知道的可信赖的站点。尽管如此，如果攻击者对目标 URL 进行 16 进制编码：
"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，以确保链接指向他们知道的可信赖的站点。尽管如此，如果攻击者对目标 URL 进行 16 进制编码：
"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：以下 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 进行 16 进制编码：
"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：以下 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 进行 16 进制编码：
"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 漏洞：

攻击者可能利用 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 进行 16 进制编码：
"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 漏洞：

攻击者可能利用 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 进行 16 进制编码：
"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：以下 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 进行 16 进制编码：
"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：以下 Paly 控制器方法指示用户浏览器打开从 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 进行 16 进制编码：
“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：下面的代码可处理使用应用程序的自定义 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，以确保链接指向一个他们所熟知的可信赖站点。尽管如此，如果攻击者对目标 URL 进行 16 进制编码：

"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 漏洞：

攻击者可能利用 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 进行 16 进制编码：
"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 定义将始终覆盖相应的全局设置。

但是，如果没有为操作定义这些设置，则它们默认为全局指定的值。