无论编写程序所用的语言是什么，最具破坏性的攻击通常都会涉及执行远程代码，攻击者借此可在程序上下文中成功执行恶意代码。在 .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 权限运行。因此，攻击者有可能利用这个提高的权限来进行更严重的破坏。

通过重定向，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"

那么，即使再聪明的最终用户也可能会被欺骗，打开该链接。

当密码以明文形式存储在应用程序的属性文件或其他配置文件中时，会发生 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');
    ...

该代码可以正常运行，但是任何访问包含此代码的网页的人都可以查看密码。

当密码以明文形式存储在应用程序的属性文件或其他配置文件中时，会发生 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 非常重要。

当密码以明文形式存储在应用程序的属性文件或其他配置文件中时，会发生 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;
...

该代码可以正常运行，但是有权访问该代码的任何人都能得到这个密码。一旦程序发布，除非修补该程序，否则可能无法更改数据库用户“scott”和密码“tiger”。雇员可以利用手中掌握的信息访问权限入侵系统。

当密码以明文形式存储在应用程序的属性文件或其他配置文件中时，会发生 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 非常重要。

当密码以明文形式存储在应用程序的属性文件或其他配置文件中时，会发生 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的值。任何心怀不轨的雇员可以利用手中掌握的信息访问权限入侵系统。

为密码变量指定空字符串绝非一个好方法。如果使用 empty password 成功通过其他系统的验证，那么相应帐户的安全性很可能会被减弱，原因是其接受了 empty password。如果在为变量指定一个合法的值之前，empty password 仅仅是一个占位符，那么它将给任何不熟悉代码的人造成困惑，而且还可能导致出现意外控制流路径方面的问题。

示例 1：此代码可初始化空密码变量。

...
password = ''.
...

为密码变量指定空字符串绝非一个好方法。如果使用 empty password 成功通过其他系统的验证，那么相应帐户的安全性很可能会被减弱，原因是其接受了 empty password。如果在为变量指定一个合法的值之前，empty 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', '');
...

如果代码成功运行，则表明证书配置有一个空密码，攻击者可以轻松地猜测到该密码。