透過 AccessibleObject API，程式設計人員可以避開 Java 存取規範提供的存取控制檢查。特別是，程式設計人員可藉此允許回傳的物件避開 Java 存取控制，轉而變更私有欄位的值或呼叫私有方法、行為 (通常這是不允許的)。

在一般的 JSF 應用程式中，會使用 UI 元件指定的轉換器和驗證器來轉換值。轉換和驗證本身會在提交頁面時發生。Fusion 應用程式中可加上書籤的檢視不會導致任何頁面提交，因此預設不會執行任何類似的轉換或驗證。

範例 1：下列組態設定檔案片段顯示了一個可加上書籤的檢視範例，該檢視組態為不執行 paramName URL 參數的任何轉換或驗證。

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

Android Class Loading Hijacking 弱點有以下兩種形式：

- 攻擊者可以變更程式為載入類別而搜尋的目錄名稱，從而指向處於其控制下之某個目錄的路徑：攻擊者明確控制應該從其中搜尋類別的路徑。

- 攻擊者可以篡改載入類別的環境：攻擊者間接控制路徑名稱代表的意義。

在此案例中，我們著重於第一種情況，即攻擊者可以控制為要載入之類別而搜尋的目錄的可能性。在以下情況下，會發生此類型的 Android Class Loading Hijacking 弱點：

1. 資料從不可信賴的來源進入應用程式。



2. 資料用作代表程式庫目錄的整個字串或一部分字串，以便搜尋要載入的類別。



3. 藉由從程式庫路徑執行程式碼，應用程式會給予攻擊者不應該擁有的權限或能力。

範例 1：以下程式碼使用使用者可變更的 userClassPath 來決定搜尋要載入的類別所在的目錄。

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

此程式碼能夠透過修改 userClassPath 的結果來指向所控制的其他路徑，從而讓攻擊者利用應用程式的提升權限，載入程式庫並潛在地執行任意程式碼。因為程式不會驗證從環境讀取的值，所以如果攻擊者可以控制 userClassPath 的值，則攻擊者便可使用與原始應用程式相同的權限，愚弄應用程式，讓應用程式指向他們所控制的目錄，從而載入他們所定義的類別。

範例 2：以下程式碼使用使用者可變更的 userOutput 來決定應寫入最佳化 DEX 檔案的目錄。

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

此程式碼可讓攻擊者指定最佳化 DEX 檔案 (ODEX) 的輸出目錄。然後，此程式碼還會讓惡意使用者將 userOutput 值變更為他們所控制的目錄，如外部儲存裝置。一旦完成竄改，便只需將輸出的 ODEX 檔案替換為惡意 ODEX 檔案，就可以使用與原始應用程式相同的權限執行該動作。

在 ASP.NET Web API 服務中，未經驗證的輸入是弱點產生的主因之一。未經檢查的輸入資料會導致許多弱點的產生，包括 Cross-Site Scripting、Process Control、Access Control 和 SQL injection。雖然 ASP.NET Web API 服務在通常情況下不容易因記憶體損壞攻擊而受到影響，但是如果 ASP.NET Web API 服務呼叫未執行陣列界限檢查的本地程式碼，攻擊者就能夠在 ASP.NET Web API 服務中利用輸入驗證弱點發起 Buffer overflow 攻擊。

若要防止此類攻擊：
1. 使用驗證屬性將針對參數或模型繫結物件參數之成員執行的驗證檢查，以程式化方式註解至 ASP.NET Web API 服務動作。
2. 使用 ModelState.IsValid 檢查模型是否通過驗證。

Bean 屬性名稱和值在填入任何 bean 之前皆需驗證。Bean 填寫功能允許開發人員設定 bean 屬性或巢狀屬性。攻擊者可利用此功能存取類似於 class.classLoader 的特別 bean 屬性，這些屬性允許攻擊者取代系統屬性，並可能執行任意程式碼。

範例：以下程式碼會設定使用者控制的 bean 屬性，但不正常驗證屬性名稱或值：

String prop = request.getParameter('prop');
String value = request.getParameter('value');
HashMap properties = new HashMap();
properties.put(prop, value);
BeanUtils.populate(user, properties);

Buffer overflow 可能是軟體安全性弱點最為人知的一種形式。大部分軟體開發人員都知道什麼是 Buffer overflow 弱點，但傳統和新開發的應用程式仍常遭到 Buffer overflow 攻擊。此問題的部份原因是，發生 Buffer overflow 的方式很多，部分原因是人們常常用不恰當的方式來防範 Buffer overflow。

在典型的 Buffer overflow 攻擊中，攻擊者會將資料傳送到程式，而程式會將其儲存在一個較小的堆疊緩衝區內。結果就是呼叫這個堆疊的資訊超出了它的邊界，其中包括函數的回傳指標。該資料設定了回傳指標的值，當函數回傳時，會將控制傳送到攻擊者資料所包含的惡意程式碼。

這類型的堆疊 Buffer overflow 在一些平台和開發社群中仍然很常見，但卻還有多種其他類型的 Buffer overflow，包括堆積 Buffer overflow 和差一錯誤 (off-by-one-error) 等等。有許多優秀的著作提供了關於堆疊 Buffer overflow 如何攻擊的具體資訊，包括 Building Secure Software[1]、Writing Secure Code[2]和 The Shellcoder's Handbook[3]。

在程式碼層級，會發生 Buffer overflow 弱點通常是因為程式設計師的假設被推翻。許多在 C 和 C++ 的記憶體操作函數不執行範圍檢查，且可以輕易地覆寫所操作的緩衝區已分配的範圍。甚至如 strncpy() 的範圍函數，使用不正確時也會引起弱點。大多數 Buffer overflow 弱點的根本原因，都是緩衝區的處理，加上對資料的大小或組成假設錯誤。

Buffer overflow 弱點通常出現在這樣的程式碼中：

- 依靠外部資料來控制運作方式者。

- 仰賴被強制位於程式碼臨接範圍外的資料特性者。

- 程式碼複雜到程式設計師不能準確預測到其運作方式者。



以下範例顯示了這三種情況。

範例 1.a：接下來的程式碼範例展示了通常由第一種情況導致的簡單 Buffer overflow，即靠外部資料控制運作方式者。程式碼使用 gets() 函數，將一個任意長度的資料讀取到堆疊緩衝區。因為沒有什麼方法可以限制這個函數讀取的資料量，所以使用者輸入的字元數必須少於 BUFSIZE，以確保程式碼的安全性。

	...
	char buf[BUFSIZE];
	gets(buf);
	...

範例 1.b：此範例顯示只要使用 >> 運算子將輸入讀取到 char[] 字串中，即可輕易模仿 C++ 中 gets() 函數不安全的運作方式。

	...
	char buf[BUFSIZE];
	cin >> (buf);
	...

範例 2：雖然這個範例中的程式碼也是依賴於使用者的輸入來控制它的運作方式，但是它會藉由使用邊界記憶體複製函數 memcpy() 增加一個間接的層面。此函數接受目的緩衝區、來源緩衝區，以及要複製的位元組數量。輸入緩衝區由 read() 的範圍呼叫所填滿，但使用者指定 memcpy() 要複製的位元組數量。

	...
char buf[64], in[MAX_SIZE];
printf("Enter buffer contents:\n");
read(0, in, MAX_SIZE-1);
printf("Bytes to copy:\n");
scanf("%d", &bytes);
memcpy(buf, in, bytes);
	...

注意：這個類型的 Buffer overflow 弱點 (程式讀取資料，然後信賴其他資料上後續記憶體操作中的一個數值) 在圖形、音頻和其他的檔案處理庫中發生次數頻繁。

範例 3：這是第二種情況的範例，其中的程式碼根據非本地驗證的資料特性而異。在這個範例中，一個名為 lccopy() 的函數將一個字串做為引數讀取，然後將這個字串中所有的大寫字母轉化成小寫字母回傳一個堆疊分配的字串副本。這個函數不會對其輸入執行範圍檢查，因為程式預期 str 始終小於 BUFSIZE。如果攻擊者避開對呼叫 lccopy() 的程式碼的測試，或者，如果程式碼有什麼變化，使得關於 str 長度的假設失真，那麼 lccopy() 就會在 strcpy() 超出邊界的呼叫過程中溢位 buf。

char *lccopy(const char *str) {
	char buf[BUFSIZE];
	char *p;

	strcpy(buf, str);
	for (p = buf; *p; p++) {
		if (isupper(*p)) {
			*p = tolower(*p);
		}
	}
	return strdup(buf);
}

範例 4：下列程式碼示範了第三種情況，其中程式碼太過複雜以致無法輕易預測其行為。這段程式碼來自於主流的 libPNG 圖像解碼器，此解碼器廣泛用於多種應用程式。

該程式碼似乎能安全執行界限檢查，因為它檢查了變數長度的大小，之後這會被用來控制 png_crc_read() 複製的資料量。不過，在測試長度之前，程式碼會立即對 png_ptr->mode 執行檢查。檢查失敗時，系統會發出警告，而處理會繼續執行下去。由於 length 會在一個 else if 區塊中進行測試，所以當第一個檢查失敗時，就不會測試 length；且在呼叫 png_crc_read() 期間對其的盲目使用易引發堆疊 Buffer overflow。

雖然這個範例中的程式碼不是我們所見到的當中最複雜的一個，但是它解釋了為什麼執行緩衝區操作的程式碼的複雜度應該減到最低。

if (!(png_ptr->mode & PNG_HAVE_PLTE)) {
	/* Should be an error, but we can cope with it */
png_warning(png_ptr, "Missing PLTE before tRNS");
}
else if (length > (png_uint_32)png_ptr->num_palette) {
png_warning(png_ptr, "Incorrect tRNS chunk length");
png_crc_finish(png_ptr, length);
return;
}
...
png_crc_read(png_ptr, readbuf, (png_size_t)length);

範例 5：此範例同樣證明了第三種情況，程式的複雜性將 Buffer overflow 的問題暴露出來。在此案例中，弱點歸咎於函數某個不明確的介面，而不是程式碼的結構 (就如同前面一個範例中所描述的)。

getUserInfo() 函數採用一個定義為多位元組字元串的使用者名和一個指標來組成使用者資訊的結構，並將使用者資訊填入這個結構。因為 Windows 對使用者名稱的 authentication 是使用統一的字元編碼標準，所以 username 是第一個從多位元組字元串轉換成統一字元編碼標準的字串的參數。函數接著會不正確地以位元組而非字元傳送 unicodeUser 的大小。呼叫 MultiByteToWideChar() 可能會因此而將最多 (UNLEN+1)*sizeof(WCHAR) 個寬字元，或
(UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) 個位元組寫入 unicodeUser 陣列，而僅為該陣列分配了 (UNLEN+1)*sizeof(WCHAR) 個位元組。如果 username 字串包含了多於 UNLEN 的字元，那麼呼叫 MultiByteToWideChar() 將會溢出 unicodeUser 緩衝區。

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);
}

Buffer overflow 可能是軟體安全性弱點最為人知的一種形式。大部分軟體開發人員都知道什麼是 Buffer overflow 弱點，但傳統和新開發的應用程式仍常遭到 Buffer overflow 攻擊。此問題的部份原因是，發生 Buffer overflow 的方式很多，部分原因是人們常常用不恰當的方式來防範 Buffer overflow。

在典型的 Buffer overflow 攻擊中，攻擊者會將資料傳送到程式，而程式會將其儲存在一個較小的堆疊緩衝區內。結果就是呼叫這個堆疊的資訊超出了它的邊界，其中包括函數的回傳指標。該資料設定了回傳指標的值，當函數回傳時，會將控制傳送到攻擊者資料所包含的惡意程式碼。

這類型的堆疊 Buffer overflow 在一些平台和開發社群中仍然很常見，但卻還有多種其他類型的 Buffer overflow，包括堆積 Buffer overflow 和差一錯誤 (off-by-one-error) 等等。有許多優秀的著作提供了關於堆疊 Buffer overflow 如何攻擊的具體資訊，包括 Building Secure Software[1]、Writing Secure Code[2]和 The Shellcoder's Handbook[3]。

在程式碼層級，會發生 Buffer overflow 弱點通常是因為程式設計師的假設被推翻。C 和 C++ 中的很多記憶體處理函數都沒有執行邊界值檢查，並會輕易地超出操作中緩衝區被配置的邊界值。甚至如 strncpy() 的範圍函數，使用不正確時也會引起弱點。大多數 Buffer overflow 弱點的根本原因，都是緩衝區的處理，加上對資料的大小或組成假設錯誤。

在此案例中，錯誤建構的 Format String 會導致程式寫入分配記憶體邊界以外的位置。

範例：以下程式碼溢出 c，因為 double 類型需要為 c 所分配的空間還要大的空間。

void formatString(double d) {
    char c;

    scanf("%d", &c)
}