在 .NET 中，您可以使用 BinaryFormatter 類別將物件轉變為二進位串流，該二進位串流包含物件本身以及還原序列化期間重建物件所需的中繼資料。

使用 BinaryFormatter 類別可能導致不安全的還原序列化情景，攻擊者可以執行任意程式碼，濫用應用程式邏輯，或觸發 denial of service 條件。

使用 BinaryFormatter 類型是危險行為，不建議用於資料處理，因為它不能保證安全。

範例 1：該應用程式透過在 runtimeConfig.json 檔案中，將組態屬性 EnableUnsafeBinaryFormatterSerialization 設為 true，允許使用不安全的 BinaryFormatter。

...
AppContext.SetSwitch("System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization", true);
...

透過 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>
...

Oracle ADF Faces 元件的屬性值通常只能在伺服器上設定。但是，有許多元件允許開發人員定義可以在用戶端上設定的屬性清單。這些元件的 unsecure 屬性可以指定此類清單。

目前，唯一能夠在 unsecure 屬性內顯示的屬性是 disabled，而且它允許用戶端定義哪些元件為啟用，而哪些元件不啟用。讓用戶端控制應該在僅能在伺服器上設定的屬性值，絕對不是個好方法。

範例 1：以下程式碼示範了 inputText 元件，該元件會從使用者收集密碼資訊，並使用 unsecure 屬性。

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

根據 RFC 2109，Cookie 嚴格意義上來說是 HTTP 機制。 不應合理預期 Cookie 適用於除 HTTP 以外的通訊協定，包括 file://。 目前尚不確定其行為，以及應套用哪些安全性劃分規則。 例如，從網際網路下載到本機磁碟的 HTML 檔案是否應該與本機安裝的任何 HTML 程式碼共用相同的 Cookie？

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 檔案，就可以使用與原始應用程式相同的權限執行該動作。

當惡意動作執行者可以在指定 Zip 檔案中指定 Zip 檔案項目名稱時，就會出現 Zip Path Traversal 弱點。當惡意指定 Zip 檔案項目名稱時，攻擊者可以在擴充對應的 Zip 檔案時覆寫關鍵系統檔案的內容。攻擊者可能會使用此類路徑穿越習慣用法 (例如 ../ 和 /) 來存取不在程式範圍內的系統檔案。依預設，瞄準 Android 14 及更高版本的 Android 應用程式可能會在 Zip 檔案解壓縮過程中偵測到 ../ 和 / 等習慣用法時法時拋出異常。此安全功能可以被覆寫或完全停用。

範例 1：以下程式碼將停用 Zip Entry Overwrite Protection。

...
dalvik.system.ZipPathValidator.clearCallback();
...

在 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 檢查模型是否通過驗證。

未依正確順序新增到中介軟體管道的 ASP.NET Core 中介軟體將無法依預期般執行，進而使應用程式可能面臨各種安全問題。

範例 1：UseCookiePolicy() 方法將 Cookie 原則中介軟體新增到中介軟體管道，進而允許自訂 Cookie 原則。當以錯誤的順序指定時，程式設計師聲明的任何 Cookie 原則將被忽略。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseCookiePolicy();
...

未依正確順序新增到中介軟體管道的 ASP.NET Core 中介軟體將無法依預期般執行，進而使應用程式可能面臨各種安全問題。

範例 1：UseHttpsRedirection() 方法將 HTTPS 重新導向中介軟體新增到中介軟體管道，進而允許將不安全的 HTTP 要求重新導向到安全的 HTTPS 要求。如果以錯誤的順序指定，則在透過重新導向之前列出的中介軟體處理要求之前，不會發生有意義的 HTTPS 重新導向。這將允許應用程式在重新導向到安全 HTTPS 連線之前處理 HTTP 要求。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpsRedirection();
...

未依正確順序新增到中介軟體管道的 ASP.NET Core 中介軟體將無法依預期般執行，進而使應用程式可能面臨各種安全問題。

範例 1：UseHttpLogging() 方法將 HTTP 記錄中介軟體新增到中介軟體管道，進而允許記錄中介軟體元件。當以錯誤的順序指定時，在呼叫 UseHttpLogging() 之前將不會記錄新增到管道的任何中介軟體。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpLogging();
...

範例 2：UseWC3Logging() 方法將 W3C 記錄中介軟體新增到中介軟體管道，進而允許記錄中介軟體元件。當以錯誤的順序指定時，在呼叫 UseWC3Logging() 之前將不會記錄新增到管道的任何中介軟體。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseWC3Logging();
...

透過寫入、更新或刪除方式修改資料的 ASP.NET MVC 控制器動作可能會因受限於只能接受以下其中一個 HTTP 動詞而受益：Post、Put、Patch 或 Delete。這會增加 Cross-Site Request Forgery 的難度，因為不小心點選連結將不會導致動作執行。

以下控制項動作預設狀況下接受任何動詞，可能容易受到跨網站偽造要求攻擊：

public ActionResult UpdateWidget(Model model)
{
  // ... controller logic
}

若使用的模型類別既有需要的屬性 (以 [Required] 屬性標明)，也有選用的屬性 (未以 [Required] 屬性標明)，在攻擊者傳送的要求所含資料多於預期時，會發生問題。

ASP.NET MVC 框架嘗試將要求參數繫結至模型屬性。

若兼具多種需求，但未明確指出哪些參數將繫結至模型，此狀況可能表示有些模型屬性供內部使用，但是可由攻擊者控制。

以下程式碼定義了某種可能的模型類別，該類別既包含擁有 [Required] 的屬性，也包含沒有 [Required] 的屬性：

public class MyModel
{
    [Required]
    public String UserName { get; set; }

    [Required]
    public String Password { get; set; }

    public Boolean IsAdmin { get; set; }
}

若選用參數能變更應用程式的行為，則攻擊者就能透過在要求中傳送選用參數來實際變更該行為。

若使用的模型類別擁有所需的不可為 Null 的屬性 (以 [Required] 屬性標明)，在攻擊者傳送的要求所含資料少於預期時，會發生問題。

ASP.NET MVC 框架嘗試將要求參數繫結至模型屬性。

若模型包含所需的不可為 Null 的參數，而攻擊者並未在要求中傳送所需的該參數 (即攻擊者使用公佈不足攻擊)，則該屬性將具有符合 [Required] 驗證屬性需求的預設值 (通常為零)。這可能會產生非預期的應用程式行為。

以下程式碼定義了某種可能的模型類別，該類別包含所需的列舉 (不可為 Null)：

public enum ArgumentOptions
{
    OptionA = 1,
    OptionB = 2
}

public class Model
{
    [Required]
    public String Argument { get; set; }

    [Required]
    public ArgumentOptions Rounding { get; set; }
}

若模型類別擁有所需的屬性，該屬性的類型是父系模型類型的選用成員，則在攻擊者傳送的要求所含資料少於預期時，可能容易受到公佈不足攻擊。

ASP.NET MVC 框架嘗試將要求參數繫結至模型屬性 (包括子模型)。

若子模型為選用項目 (即父系模型擁有的某個屬性沒有 [Required] 屬性)，則在攻擊者未傳送該子模型時，父系屬性的值將是 null，模型驗證將不會宣告子模型的所需欄位。這是公佈不足攻擊的一種形式。

請考慮以下模型類別定義：

public class ChildModel
{
    public ChildModel()
    {
    }

    [Required]
    public String RequiredProperty { get; set; }
}

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

若攻擊者未傳送 ParentModel.Child 屬性的值，則 ChildModel.RequiredProperty 屬性將擁有未宣告的 [Required]。這可能會產生非預期且不適當的結果。

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

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

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

根據 Apple 的策略，應用程式應總是向使用者解釋要求其輸入指紋的原因。如果沒有這樣做，可能會讓使用者感到困惑，甚至使應用程式在 AppStore 中遭到拒絕。

範例 1：以下程式碼使用 Touch ID 來驗證使用者，但未提供本地化原因來解釋為什麼要求進行驗證。

    [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics localizedReason:nil
        reply:^(BOOL success, NSError *error) {
            if (success) {
                NSLog(@"Auth was OK");
            } 
    }];

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

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

void formatString(double d) {
    char c;

    scanf("%d", &c)
}

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：以下程式碼溢出 buf，因為視 f 的大小而定，Format String 規範 "%d %.1f ... " 會超出配置的記憶體容量。

void formatString(int x, float f) {
   char buf[40];
   sprintf(buf, "%d %.1f ... ", x, f);
}