许多 DNS 服务器都很容易被攻击者欺骗，所以应考虑到某天软件有可能会在有问题的 DNS 服务器环境下运行。如果允许攻击者进行 DNS 更新（有时称为 DNS 缓存中毒），则他们会通过自己的机器路由您的网络流量，或者让他们的 IP 地址看上去就在您的域中。勿将系统安全寄托在 DNS 名称上。
示例：下面的代码会使用 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。

示例：

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。
示例：

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> 标签表示程序接受文件上传。
示例：

<input type="file">