當不止一次地在同一個記憶體位址將 free() 做為一個引數來呼叫，就會出現 double free (釋放相同的記憶體空間兩次) 錯誤。



以相同值呼叫 free() 兩次，會導致 Buffer overflow。當程式使用相同引數呼叫 free() 兩次，就會毀損程式中的記憶體管理資料結構。這樣的毀損會使程式當機，或者在某些情況下，還會導致之後兩次的 malloc() 呼叫回傳相同的指標。如果 malloc() 兩次回傳值都相同，且程式之後讓攻擊者控制整個已經寫入雙倍分配記憶體的資料，此程式就變得容易受到 Buffer overflow 攻擊。

範例 1：以下程式碼顯示關於 double free (釋放相同的記憶體空間兩次) 弱點的簡單範例。

	char* ptr = (char*)malloc (SIZE);
	...
	if (abrt) {
	  free(ptr);
	}
	...
	free(ptr);

Double free 弱點的產生有兩個常見的原因 (有時候這兩個原因會同時出現)：

- 錯誤條件以及其他異常情況。

- 對於程式中負責釋放記憶體的部分混淆了。

雖然某些 double free (釋放相同的記憶體空間兩次) 弱點的複雜程度不會比之前這個範例高出太多，但是其中大部分弱點分散在好幾百行的程式碼中，甚至是不同的檔案中。程式設計師似乎特別容易受到多次釋放全域變數的影響。

包含 Unicode 雙向覆寫控制字元的原始程式碼可能是內部威脅攻擊的徵兆。攻擊者可透過 C、C++、C#、Go、Java、JavaScript、Python 和 Rust 等程式設計語言的供應鏈來運用這種攻擊。Nicholas Boucher 和 Ross Anderson 已發佈數種變體攻擊，包括以下各項：Early Returns、Commenting-Out 和 Stretched Strings。
範例 1：以下程式碼顯示一個控制字元，其存在於 C 原始程式碼檔案中，會導致 Early Return 攻擊：

#include <stdio.h>

int main() {
	/* Nothing to see here; newline RLI /*/ return 0 ;
	printf("Do we get here?\n");
	return 0;
}

在 Example 1 中，從右到左隔離 (RLI) Unicode 雙向控制字元導致程式碼被視為以下內容：

#include <stdio.h>

int main() {
	/* Nothing to see here; newline; return 0 /*/
	printf("Do we get here?\n");
	return 0;
}

需要特別注意的是，開發人員在易受攻擊的編輯器/檢視器中執行程式碼檢閱時，不會明顯看到易受攻擊的編譯器將處理的內容。特別是修改程序流程的 early return 陳述式。

這個程式庫被視為實驗性，在您瞭解所從事為何之後才可將其用於生產環境。

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 會導致程式從分配記憶體邊界以外的位置存取值。

範例 1：以下程式碼從堆疊讀取任意值，因為格式規範的數值與傳送到函數的引數數值不同。

void wrongNumberArgs(char *s, float f, int d) {
   char buf[1024];
   sprintf(buf, "Wrong number of %.512s");
}

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 會導致程式以錯誤的方式轉換資料值，或從分配記憶體邊界以外的位置存取值。

範例 1：以下程式碼錯誤地使用 %d 格式規範從浮點數轉換 f。

void ArgTypeMismatch(float f, int d, char *s, wchar *ws) {
   char buf[1024];
   sprintf(buf, "Wrong type of %d", f);
   ...
}

內部 Intent 使用內部元件定義的自訂動作。隱含 Intent 可以促進從任何指定外部元件呼叫 Intent，而無需了解特定元件。將兩者相結合，會允許應用程式從所需的應用程式內容外部存取指定給特定內部使用的 Intent。

從外部應用程式處理內部 Intent 的能力，可以引發從資訊洩漏、Denial of Service 到遠端程式碼執行等各種不同嚴重程度的 man-in-the-middle 攻擊，具體取決於 Intent 指定之內部動作的能力。

範例 1：以下程式碼使用內部隱含內部 Intent。

...
val imp_internal_intent_action = Intent("INTERNAL_ACTION_HERE")
startActivity(imp_internal_intent_action)
...

Android Intent 用於透過提供有關特定元件執行之動作的指令，將應用程式和應用程式元件繫結在一起。建立 Pending Intent 是為了稍後傳送 Intent。隱含 Intent 有助於從任何特定外部元件呼叫 Intent，並使用通用名稱和篩選器來確定執行。

將隱含 Intent 做為 PendingIntent 建立時，可能會導致 Intent 被傳送到在預期暫存內容外部執行的非預期元件，從而使系統容易受到諸如 Denial of Service、私人和系統資訊洩漏和提升特權等的攻擊。

範例 1：以下程式碼使用隱含 PendingIntent。

...
val imp_intent = Intent()
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable_impintintent = PendingIntent.getService(
    this,
    0,
    imp_intent,
    flag_mut
)
...

若允許在建立 PendingIntent 後修改其底層 Intent，可能會使系統容易受到攻擊。這主要取決於底層 Intent 的整體能力。在大多數情況下，最佳方式是將 PendingIntent 旗標設為 FLAG_IMMUTABLE 來防止潛在問題。

範例 1：以下包括建立一個使用 FLAG_MUTABLE 旗標值建立 PendingIntent。

...
val intent_flag_mut = Intent(Intent.ACTION_GTALK_SERVICE_DISCONNECTED, Uri.EMPTY, this, DownloadService::class.java)
val flag_mut = PendingIntent.FLAG_MUTABLE

val pi_flagmutable = PendingIntent.getService(
    this,
    0,
    intent_flag_mut,
    flag_mut
)
...

記憶體洩露有兩個常見的原因 (有時這兩個原因會一起出現)：

- 錯誤條件以及其他異常情況。

- 對於程式中負責釋放記憶體的部分混淆了。

大部分記憶體洩漏會導致一般軟體可靠性問題，但是如果攻擊者能夠蓄意觸發資源的洩漏，攻擊者就可能會發動 Denial of Service 攻擊 (藉由損壞程式)，或利用因記憶體不足的狀況 [1] 導致的其他非預期程式行為。

範例 1：以下 C 函數將會洩漏已分配的記憶體區塊的資訊，當程式呼叫 read() 時未能回傳預期的位元組數：

  char* getBlock(int fd) {
  char* buf = (char*) malloc(BLOCK_SIZE);
  if (!buf) {
    return NULL;
  }
  if (read(fd, buf, BLOCK_SIZE) != BLOCK_SIZE) {
    return NULL;
  }
  return buf;
}

記憶體洩露有兩個常見的原因 (有時這兩個原因會一起出現)：

- 錯誤條件以及其他異常情況。

- 對於程式中負責釋放記憶體的部分混淆了。

大部分記憶體洩漏會導致一般軟體可靠性問題，但是如果攻擊者能夠蓄意觸發資源的洩漏，攻擊者就可能會發動 Denial of Service 攻擊 (藉由損壞程式)，或利用因記憶體不足的狀況 [1] 導致的其他非預期程式行為。

範例 1：以下的 C 函數在呼叫 realloc() 調整原始分配大小失敗時，洩露了分配記憶體區塊。

char* getBlocks(int fd) {
  int amt;
  int request = BLOCK_SIZE;
  char* buf = (char*) malloc(BLOCK_SIZE + 1);
  if (!buf) {
    goto ERR;
  }
  amt = read(fd, buf, request);
  while ((amt % BLOCK_SIZE) != 0) {
     if (amt < request) {
        goto ERR;
     }
     request = request + BLOCK_SIZE;
     buf = realloc(buf, request);
     if (!buf) {
        goto ERR;
     }
     amt = read(fd, buf, request);
  }

  return buf;

  ERR:
  if (buf) {
    free(buf);
  }
  return NULL;
}

Null 指標錯誤通常是由於一個或者多個程式設計人員的假設被破解而造成的。

大部分的 Null 指標問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發 Null 指標解除參照的話，攻擊者就可能會使用引發的異常來略過安全性邏輯，或是使應用程式洩漏出除錯資訊，這些資訊對於計畫後續攻擊很有價值。

範例 1：在以下程式碼中，程式設計人員假設系統永遠會定義一個名為「cmd」的屬性。如果攻擊者可以控制程式環境，使「cmd」變成未定義狀態，那麼程式會在嘗試呼叫 trim() 方法時拋出一個 Null 指標異常。

String val = null;
...
cmd = System.getProperty("cmd");
if (cmd)
	val = util.translateCommand(cmd);
...
cmd = val.trim();

隨著程式語言的演變，有時有些方法可能會過時，原因如下：

- 語言進化
- 更加了解應如何有效且安全地
執行作業
- 管理某些特定作業的慣例發生變化

在某種語言中，我們通常都會捨棄某些方法，並以較新且類似的方法取代。新的方法可以使用稍微不同但較好的方式來執行同樣的工作。
範例 1：以下程式碼使用位元組陣列和指定每個 16 位元 Unicode 字元的前 8 個位元的值，組成一個字串物件。

...
String name = new String(nameBytes, highByte);
...

在此範例中，建構函式可能無法正確地將位元組轉換成字元，這需視要使用哪個字元組來編碼由 nameBytes 所呈現的字串而定。由於用於編碼字串的字元組的演變，所以不推薦使用此建構函式，取而代之的是新的構造函式。新的構造函式可接受作為名為 charset 的其中一個參數，用來編碼字元組以進行字元轉換。

並不是所有函數都因為有安全性風險，才不推薦使用或被取代。但是，過時函數的存在通常表示周圍的程式碼已經沒有作用，甚至有可能處在廢棄狀態。長久以來，軟體的安全性始終不是優先的考量，甚或不納入考量。如果程式使用不推薦或過時的函數，則安全性問題更有可能伺機出沒。

不使用函數 IsBadXXXPtr() 類別的原因很多。這些函數的特性如下：
1) 非執行緒安全。
2) 通常會發生因探測無效記憶體位址而引起的當機。
3) 誤認為能夠在發生異常條件時執行適當的錯誤處理。

範例 1：下列程式碼使用 IsBadWritePtr() 以嘗試防止不良的記憶體寫入。

if (IsBadWritePtr(ptr, length))
{
    [handle error]
}

程式設計師通常使用這些函數，目的是希望可藉其偵測異常狀況，但是函數造成的問題通常多過他們可解決的範圍。

在同一個類別中，成員的欄位與方法擁有相同的名稱，很讓人困擾。這很容易讓程式設計師想存取某欄位時卻不小心呼叫與之同名的方法，而當他想要呼叫某方法時卻存取了與之同名的欄位。

範例 1：

public class Totaller {
  private int total;
  public int total() {
    ...
  }
}

在 Java 中進行同步化是很棘手的問題。empty synchronized block 通常只表示程式設計師正在處理同步化問題，但還未達到他們想要的結果。

範例 1：

synchronized(this) { }

Java 語言規範的 3.8 節中有說明美元符號，但僅將它當作用於機器產生的原始程式碼中的識別碼。

範例 1：

int un$afe;

沒有使用變數的初始值。在指定初始值後，會為變數指定另一個值，或者超出範圍之外。

範例 1：以下摘錄的程式碼會為變數 r 指定值，然後在沒有使用的情況下將其覆寫。

  int r = getNum();
  r = getNewNum(buf);

未使用此變數值。在指定值後，會為變數指定另一個值，或者超出範圍之外。

範例 1：以下摘錄的程式碼會為變數 r 指定值，然後在沒有使用的情況下將其覆寫。

  r = getName();
  r = getNewBuffer(buf);

此變數從未被使用過。可能這只是一個無用的程式碼，但是這也可能指出了一個錯誤。

範例 1：在以下程式碼中，一個複製貼上錯誤導致相同的迴圈迭代器 (i) 被使用了兩次。變數 j 從未使用過。

  int i,j;

  for (i=0; i < outer; i++) {
    for (i=0; i < inner; i++) {
      ...

這一類函數的運作方式會根據作業系統而改變，甚至有時候根據作業系統的版本而改變。應用的不同可能包括：

- 參數解譯方式微小的不同會引起不一致的結果。

- 某些函數的執行包含了巨大的安全風險。

- 未在所有平台上定義該函數。