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() 引數指定的 mask 總是容易與 chmod() 引數混淆。umask() 線上手冊以錯誤陳述式開頭：chmod() 的用法，即使用者提供的引數指定某些位元在指定的檔案上啟用，但事實上 umask() 的行為恰恰相反： umask() 將 umask 設為 ~mask & 0777。umask() 線上手冊接下來描述了對於 umask() 的正確使用方式：open() 使用 umask 來為新建立的檔案設定初始化檔案權限。 特別是，umask 的權限關閉了傳送給 open(2) 的 mode 引數 (例如，一般的 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() 引數指定的 mask 總是容易與 chmod() 引數混淆。umask() 線上手冊以錯誤指令開頭：chmod() 的用法，即使用者指定引數中某些位元值來控制檔案存取權限，但事實上 umask() 做的恰恰相反：umask() 將 umask 設為 ~mask & 0777。umask() 線上手冊接下來描述了對於 umask() 的正確使用方式：transactionId 寫入至應用程式文件目錄中的暫存檔案：
...
//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 權限來執行程式，已經造成了無數的 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 屬性是多餘的。dangerouslySetInnerHTML 屬性可取代在瀏覽器 DOM 中使用 innerHTML，但 API 已重新命名以傳達使用它的潛在危險。通常，從程式碼設定 HTML 是有風險的，因為它很容易在無意中使您的使用者遭受 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。為了將其中任何資料對映注入其動作程式碼，開發人員需要實作介面中指定的 Setter (例如：SessionAware 介面的 setSession)：
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: 字首可用於動作 URL 中，在啟用「動態方法呼叫」時呼叫動作中的任何公用方法。未發覺此功能的開發人員會不慎向攻擊者洩漏內部業務邏輯。http://server/app/recoverpassword!getPassword.actionorg.apache.struts2.interceptor.ApplicationtAware、org.apache.struts2.interceptor.SessionAware 和 org.apache.struts2.interceptor.RequestAware。為了將其中任何資料對映注入其動作程式碼，開發人員需要實作介面中指定的 Setter (例如：SessionAware 介面的 setSession)：
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。為了將其中任何資料對映注入其動作程式碼，開發人員需要實作介面中指定的 Setter (例如：SessionAware 介面的 setSession)：
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