API 是调用方和被调用方之间的约定。最常见的 API 滥用是由于调用方未能遵守此约定的终止导致的。例如，如果某个程序在调用 chroot() 后未能调用 chdir()，则违反了用于指定如何安全地更改活动根目录的约定。库滥用的另一个典型示例是期望被调用方向调用方返回可信的 DNS 信息。在这种情况下，调用方通过对被调用方行为做出某种假设（返回值可用于身份验证目的）滥用其 API。另一方也可能违反调用方-被调用方约定。例如，如果编码器子类化 SecureRandom 并返回一个非随机值，则将违反此约定。
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);