API 是调用方和被调用方之间的约定。最常见的 API 滥用是由于调用方未能遵守此约定的终止导致的。例如，如果某个程序在调用 chroot() 后未能调用 chdir()，则违反了用于指定如何安全地更改活动根目录的约定。库滥用的另一个典型示例是期望被调用方向调用方返回可信的 DNS 信息。在这种情况下，调用方通过对被调用方行为做出某种假设（返回值可用于身份验证目的）滥用其 API。另一方也可能违反调用方-被调用方约定。例如，如果编码器子类化 SecureRandom 并返回一个非随机值，则将违反此约定。
_alloca() 函数会抛出一个堆栈溢出异常，可能造成程序的崩溃。_alloca() 函数在堆栈上分配存储空间。如果分配请求对于可用的堆栈空间来说太大，_alloca() 将会抛出一个异常。如果未能捕获到异常，程序将会崩溃，并有可能引起 denial of service 攻击。_alloca() 已经被淘汰。它已由更加安全的 _alloca_s() 所取代。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 字节小。umask() 指定的掩码常常很容易与 chmod() 的参数混淆。umask() man page 以错误的指令开始：chmod() 的用法，这种情况下，由用户提供的参数指定在特定文件上启用的位数，但事实上 umask() 的行为恰恰相反： umask() 将 umask 设为 ~mask & 0777。umask() man page 接下来描述了 umask() 的正确使用方法：open() 使用 umask 为新建文件设置初始文件权限。 具体而言，它会关闭 umask 从 mode 参数传递到 open(2) 的权限（例如，umask 的通用默认值 022 会导致以权限 0666 & ~022 = 0644 = rw-r--r-- 创建新文件，而在正常情况下，mode 应该为 0666）。”
...
struct stat output;
int ret = stat(aFilePath, &output);
// error handling omitted for this example
struct timespec accessTime = output.st_atime;
...
umask() 指定的掩码常常很容易与 chmod() 的参数混淆。umask() man page 以错误的指令开始：chmod() 的用法，这种情况下，由用户提供的参数指定在特定文件上启用的位数，但事实上 umask() 的行为恰恰相反：umask() 将 umask 设为 ~mask & 0777。umask() man page 接下来描述了 umask() 的正确使用方法：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)
...
posted 对象。FileUpload 属于类型 System.Web.UI.HtmlControls.HtmlInputFile。
HttpPostedFile posted = FileUpload.PostedFile;
@Controller
public class MyFormController {
...
@RequestMapping("/test")
public String uploadFile (org.springframework.web.multipart.MultipartFile file) {
...
} ...
}
<?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";
} ?>
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))
...
file 的 <input> 标签表示程序接受文件上传。
<input type="file">
myModule.config(function($interpolateProvider){
$interpolateProvider.startSymbol("[[");
$interpolateProvider.endSymbol("]]");
});
root 权限运行的程序已经造成了无数的 Unix 安全灾难。仔细检查您的程序授权是否会引发安全问题十分必要，同样重要的是，对那些授予了权限的应用程序，应及时撤销其权限并返回至未授权状态，把因忽略漏洞而引发的破坏控制到最小。root 用户切换到另外一个用户时，这种差异会尤其明显。 root 权限运行，信号处理程序或者子进程将会以 Root 权限运行。因此，攻击者有可能利用这个提高的权限来进行更严重的破坏。root 权限运行的程序已导致了无数的 Unix 安全灾难。您必须仔细审查特权程序是否存在各种安全问题，但同样重要的是，特权程序应尽快恢复到非特权状态，以限制被忽略的漏洞可能造成的损害。root 用户转换到另一个非 root 用户，这些不一致尤为明显。root 身份运行，则信号处理程序或子流程将以 root 权限运行。攻击者可能会利用这些提升的权限进行进一步的破坏。root 权限运行的程序已经造成了无数的 Unix 安全灾难。 仔细检查您的程序授权是否会引发安全问题十分必要，同样重要的是，对那些授予了权限的程序，应及时撤销其权限并返回至未授权状态，将因忽略漏洞而引发的损害控制到最小。root 用户切换到另外一个用户时，这种差异会尤其明显。root 权限运行时，如果触发某一个信号或执行子进程，则信号处理程序或者子进程将会以 root 权限运行。 因此，攻击者有可能利用这些提高的权限来进行更严重的破坏。root 权限运行的程序已经造成了无数的 Unix 安全灾难。仔细检查您的程序授权是否会引发安全问题十分必要，同样重要的是，对那些授予了权限的应用程序，应及时撤销其权限并返回至未授权状态，把因忽略漏洞而引发的破坏控制到最小。root 用户切换到另外一个用户时，这种差异会尤其明显。root 权限运行，信号处理程序或者子进程将会以 Root 权限运行。因此，攻击者有可能利用这个提高的权限来进行更严重的破坏。...
Device.OpenUri("sms:+12345678910");
...
...
[[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];
...
...
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)
...
MultiByteToWideChar()、WideCharToMultiByte()、UnicodeToBytes() 和 BytesToUnicode() 函数，以在多字节（通常为 ANSI）字符串和 Unicode（宽字符）字符串之间进行转换。由于这些函数的长度参数所指定的单位各不相同，一个是字节，另一个是字符，使得它们的使用很容易出错。在一个多字节字符串中，每一个字符占用的字节数是可变的，因此，此类字符串的长度很容易指定为所有字节数的总量。但在 Unicode 中，字符通常有固定的长度，所以字符串长度一般都是根据它们所包含的字符数来决定的。所以，在长度参数中错误地指定了错误的单位，会导致 buffer overflow。
void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1];
MultiByteToWideChar(CP_ACP, 0, username, -1,
unicodeUser, sizeof(unicodeUser));
NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info);
}
unicodeUser 的长度以字节形式传递出去，而不是字符形式。调用 MultiByteToWideChar() 可能会把 (UNLEN+1)*sizeof(WCHAR) 宽字符或者 (UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) 字节，写到 unicodeUser 数组，该数组仅分配了 (UNLEN+1)*sizeof(WCHAR) 字节。如果 username 字符串包含了多于 UNLEN 的字符，那么调用 MultiByteToWideChar() 将会溢出 unicodeUser 缓冲区。sun.misc.Unsafe 中的功能。此类中的所有功能本质上均不安全，只能通过反射进行访问。sun.misc.Unsafe 类用于执行不安全的低级操作，不适合开发人员使用。Unsafe 类只能通过受信任代码获取，且通常通过反射获取，因为其可用来破坏系统或手动分配堆内存，如果处理不当，可能会对系统产生不利影响。必须仔细检查和测试与 sun.misc.Unsafe 相关的所有功能，确保不出现错误。
String password=request.getParameter("password");
...
DefaultUser user = (DefaultUser) ESAPI.authenticator().createUser(username, password, password);
finalize() 只能在对象回收后才能由 JVM 进行调用。finalize() 方法，但这其实并不是一个好办法。例如，直接调用 finalize() 意味着要不止一次地调用 finalize() 方法：第一次将会直接调用，而最后一次调用会在对象回收之后执行。finalize() 方法：
// time to clean up
widget.finalize();
dangerouslySetInnerHTML 属性不必要地被设置 HTML from code。dangerouslySetInnerHTML 属性可以替代在浏览器 DOM 中使用 innerHTML，但 API 已重命名以传达使用 innerHTML 的潜在危险。通常情况下，设置 HTML from code 是有风险的，因为它很容易在无意中使您的用户遭受 Cross-Site Scripting (XSS) 攻击。dangerouslySetInnerHTML 属性：
function MyComponent(data) {
return (
<div
dangerouslySetInnerHTML={{__html: data.innerHTML}}
/>
);
}
AUTHID CURRENT_USER 程序包中，标识符是根据当前用户的架构首先解析的。如果该代码的定义程序未明确表明标识符所属的架构，这可能会导致意外的行为。SYS.PERMISSIONS 的读取权限，且无法修改已定义的权限。
CREATE or REPLACE FUNCTION check_permissions(
p_name IN VARCHAR2, p_action IN VARCHAR2)
RETURN BOOLEAN
AUTHID CURRENT_USER
IS
r_count NUMBER;
perm BOOLEAN := FALSE;
BEGIN
SELECT count(*) INTO r_count FROM PERMISSIONS
WHERE name = p_name AND action = p_action;
IF r_count > 0 THEN
perm := TRUE;
END IF;
RETURN perm;
END check_permissions
check_permissions 函数的用户在其架构中定义了一个 PERMISSIONS 表，则该数据库会解析该标识符以引用本地表。该用户将具有对新表的写入权限，并可以对其进行修改以获得在其他情况下不可能拥有的权限。org.apache.struts2.interceptor.ApplicationtAware、org.apache.struts2.interceptor.SessionAware 和 org.apache.struts2.interceptor.RequestAware。为了将这些数据映射中的任意内容注入到其 Actions 代码中，开发人员需要实现接口中指定的 setter（例如：setSession，适用于 SessionAware 接口）：
public class VulnerableAction extends ActionSupport implements SessionAware {
protected Map<String, Object> session;
@Override
public void setSession(Map<String, Object> session) {
this.session = session;
}
SessionAware、RequestAware、ApplicationAware 接口所示。
http://server/VulnerableAction?session.roles=admin
execute() 方法。execute()。!（感叹号）字符或 method: 前缀可用于 Action URL，在启用“动态方法调用”的情况下，可调用 Action 中的任何公共方法。没有意识到此功能的开发者可能会无意中将内部业务逻辑暴露给攻击者。http://server/app/recoverpassword!getPassword.actionorg.apache.struts2.interceptor.ApplicationtAware、org.apache.struts2.interceptor.SessionAware 和 org.apache.struts2.interceptor.RequestAware。为了将这些数据映射中的任意内容注入到其 Actions 代码中，开发人员需要实现接口中指定的 setter（例如：setSession，适用于 SessionAware 接口）：
public class VulnerableAction extends ActionSupport implements SessionAware {
protected Map<String, Object> session;
@Override
public void setSession(Map<String, Object> session) {
this.session = session;
}
SessionAware、RequestAware、ApplicationAware 接口所示。
http://server/VulnerableAction?session.roles=admin
org.apache.struts2.interceptor.ApplicationtAware、org.apache.struts2.interceptor.SessionAware 和 org.apache.struts2.interceptor.RequestAware。为了将这些数据映射中的任意内容注入到其 Actions 代码中，开发人员需要实现接口中指定的 setter（例如：setSession，适用于 SessionAware 接口）：
public class VulnerableAction extends ActionSupport implements SessionAware {
protected Map<String, Object> session;
@Override
public void setSession(Map<String, Object> session) {
this.session = session;
}
SessionAware、RequestAware、ApplicationAware 接口所示。
http://server/VulnerableAction?session.roles=admin