是的，最好先覆蓋然後刪除/釋放該值。 不要假設，您要做的就是“覆蓋數據”或讓其超出GC的處理範圍，因為每種語言與硬件的交互方式都不相同。

在保護變量時，您可能需要考慮以下問題：

• 加密（在內存轉儲或頁面緩存的情況下）
• 固定在內存中
• 將標記為只讀（以防止進一步修改）的能力
• 通過不允許在優化編譯器中傳遞常量字符串來保證安全構造（請參見
• 鏈接文章中的註釋 re：ZeroMemory宏）

“擦除”的實際實現取決於語言和平台。研究您使用的語言，並查看是否有可能進行安全編碼。

為什麼這是個好主意？故障轉儲以及包含堆的任何內容都可能包含您的敏感數據。保護內存中數據時請考慮使用以下內容

• SecureZeroMemory
• .NET SecureString
• C ++模板

有關每種語言的實施指南，請參考StackOverflow。

即使使用供應商，也應注意指南（在這種情況下為MSFT）仍然可以轉儲SecureString的內容，並且可能具有針對高安全性場景的特定使用指南。

存儲不再使用的值？似乎可以對其進行優化，無論它可能帶來什麼好處。

此外，您可能實際上並不會根據語言本身的工作方式覆蓋內存中的數據。例如，在使用垃圾收集器的語言中，不會立即將其刪除（這是假設您沒有留下任何其他引用）。

例如，在C＃中，我認為

  string secret =“我的秘密數據”; ...大量工作... string secret =“ blahblahblah”;  

“我的秘密數據” 一直掛到垃圾被收集，因為它是不可變的。最後一行實際上是在創建一個新字符串並對其進行秘密指向。它不能加快刪除實際機密數據的速度。

有好處嗎？假設我們以彙編語言或低杠桿語言編寫了數據，那麼我們可以確保覆蓋數據，並讓計算機進入睡眠狀態或在應用程序運行時將其保留，並且我們的RAM被一個邪惡的女僕刮掉了，邪惡的女僕在機密被覆蓋之後但在被刪除之前（可能是很小的空間）就獲得了我們的RAM數據，而RAM或硬盤驅動器上的其他任何內容都不會洩露此秘密...然後我看到了可能的增加

但是，成本與收益的關係似乎使得此安全​​性優化在我們的優化列表中非常低（並且通常在大多數應用程序中都低於“有價值”的水平）。

我可能會看到這種在特殊芯片中的使用受到限制，意味著可以在短時間內保存秘密，以確保它們在盡可能短的時間內保存下來，但是即使如此，我仍不確定成本會帶來什麼好處。

您需要一個威脅模型

您甚至不應該開始考慮覆蓋安全變量，除非您有一個威脅模型來描述要阻止的黑客種類。 安全性總是要付出代價的。在這種情況下，代價就是教導開發人員維護所有這些額外代碼以保護數據的開發成本。 這筆費用意味著您的開發人員很可能會犯錯誤，並且這些錯誤更可能是洩漏的根源而不是內存問題。

• 可以攻擊者訪問您的記憶？如果是這樣，您是否有理由認為他們不能/不會只是在改寫之前先嗅探值？攻擊者可以在什麼時間範圍內訪問您的內存
• 攻擊者可以訪問核心轉儲嗎？您是否介意它們是否可以訪問敏感數據以換取足夠高的噪聲以首先引起核心轉儲？
• 這是開放源還是封閉源？如果它是開源的，則您必須擔心多個編譯器，因為編譯器會始終優化諸如覆蓋數據之類的東西。他們的工作不是提供安全性。 （對於一個真實的例子，Schneier的PasswordSafe具有專門的類來保護未加密的密碼數據。為此，他使用Windows API函數來鎖定內存，並強制其被正確覆蓋，而不是使用編譯器。為他做）
• 這是垃圾收集的語言嗎？您知道如何迫使您的特定垃圾收集器的特定版本實際刪除您的數據嗎？
• 在您注意到並用其他方法切斷攻擊者之前，攻擊者可以進行幾次嘗試來獲取敏感數據（例如防火牆）？
• 這是在虛擬機中運行嗎？您如何確定Hypervisor的安全性？
• 攻擊者是否具有物理訪問權限？例如，Windows非常樂意使用閃存驅動器來緩存虛擬內存。攻擊者所需要做的就是說服Windows將其推入閃存驅動器。發生這種情況時，真的很難解決。實際上，是如此的困難，以至於沒有可靠的方法可以從閃存驅動器中可靠地清除數據。

在考慮覆蓋敏感數據之前，需要解決這些問題。 嘗試覆蓋數據而不解決線程模型是一種錯誤的安全感。

是的，在安全性方面，優良作法是在不再需要數據時覆蓋特別敏感的數據，即作為對象析構函數（由語言提供的顯式析構函數或程序採取的操作）的一部分在取消分配對象之前）。甚至最好的做法是覆蓋本身不敏感的數據，例如將不再使用的數據結構中的指針字段清零，並且當指向的對像被釋放時將指針清零，即使您知道您將不再使用該字段。

這樣做的一個原因是，如果數據因外部因素（例如暴露的核心轉儲，被盜的休眠映像，受損害的服務器允許內存）洩漏而洩漏攻擊者提取RAM棒並利用數據保留能力的物理攻擊很少引起關注，除非在便攜式計算機上，也許在移動設備（例如電話）上（由於RAM被焊接，所以閾值較高），甚至在大多數情況下也只針對目標場景。改寫值的剩餘性不是問題：要在RAM芯片內部進行探測以檢測任何可能受改寫值影響的揮之不去的微小電壓差，將需要非常昂貴的硬件。如果您擔心對RAM的物理攻擊，那麼更大的問題就是確保將數據寫在RAM中，而不僅僅是在CPU緩存中。但這又通常是一個很小的問題。

覆蓋陳舊數據的最重要原因是為了防禦導致使用未初始化內存的程序錯誤，例如臭名昭​​著的 Heartbleed。這超出了敏感數據的範圍，因為風險不僅限於數據洩漏：如果存在某個軟件錯誤導致指針字段在未初始化的情況下被取消引用，則該錯誤不那麼容易被利用，並且如果

請注意，如果好的編譯器檢測到不再使用該值，則該字段將全部清零。

請注意，好的編譯器會優化清零。您可能需要使用一些特定於編譯器的技巧，以使編譯器相信該值仍在使用，從而生成清零代碼。

在許多具有自動管理功能的語言中，對象可以在不移動的情況下移動到內存中注意。這意味著很難控制陳舊數據的洩漏，除非內存管理器本身會擦除未使用的內存（出於性能目的通常不會這樣做）。從好的方面來說，外部洩漏通常是您所要擔心的，因為高級語言往往會阻止使用未初始化的內存（請注意具有可變字符串的語言中的字符串創建函數）。

順便說一句，我在上面寫了“歸零”。您可以使用除全零以外的位模式。全零的優點是在大多數環境中它都是無效的指針。您知道的位模式是無效的指針，但是更具特色的位模式可以幫助調試。

許多安全標準要求擦除敏感數據（例如密鑰）。例如，用於加密模塊的 FIPS 140-2標準甚至在最低保證級別上也要求它，除此之外，它僅要求功能合規且不需要抵抗攻擊。

對於其餘答案的補充（希望很有趣），許多人低估了用C正確覆蓋內存的難度。我將在Colin Percival的博客文章“ 如何將a歸零”中大量引用。緩衝區”。

天真的嘗試覆蓋C語言中的內存所面臨的主要問題是編譯器優化。大多數現代編譯器都非常“聰明”，足以識別出用於覆蓋內存的通用對象實際上並不會改變程序的可觀察行為，因此可以對其進行優化。不幸的是，這完全破壞了我們想要實現的目標。上面鏈接的博客文章中介紹了一些常見的技巧。更糟糕的是，適用於一個版本的編譯器的技巧可能不一定與另一版本的編譯器甚至同一版本的其他版本一起使用。除非您僅分配二進製文件，否則這將是一個問題。

可靠地覆蓋C語言中我所知的唯一方法是 memset_s功能。可悲的是，這僅在C11中可用，因此為較早版本的C編寫的程序不走運。

memset_s函數將c的值（轉換為無符號字符）複製到每個s指向的對象的​​前n個字符。與memset不同，對memset_s的任何調用都必須嚴格按照抽像機的規則進行評估，如5.1.2.3中所述。也就是說，對memset_s的任何調用均應假定s和n所指示的內存將來可能可訪問，因此必須包含c所指示的值。

僅覆蓋內存是不夠的。他在標題為“ 歸零緩衝區不足”的後續博客文章中指出

稍加註意，使用協作編譯器，我們可以將緩衝區歸零-但這不是我們所需要的。我們需要做的是將可能存儲敏感數據的每個位置都設為零。請記住，我們之所以首先將敏感信息存儲在內存中，是因為我們可以使用它。並且這種用法幾乎肯定會導致敏感數據被複製到堆棧和寄存器中。

他繼續介紹了使用x86平台上的AESNI指令集洩漏數據的AES實現示例。

他聲稱，

不可能在C中安全地實現任何提供前向保密性的密碼系統。

A確實令人不安。

重要的是在需要後立即覆蓋，這很重要，因為，否則，

• 數據會一直保留在堆棧上直到被覆蓋，並且可以通過
• 數據容易受到內存刮擦。

實際上，如果您查看安全敏感型應用程序的源代碼（例如， openssh），您會發現它在使用後會仔細將敏感數據清零。

編譯器可能會嘗試優化覆蓋，即使沒有這樣做，也確實如此。重要的是要知道數據的物理存儲方式（例如，如果機密存儲在SSD上，則由於損耗平衡而覆蓋它可能不會擦除舊內容）。

原始示例顯示了一個堆棧變量，因為它是本機int類型。

覆蓋它是一個好主意，否則它會一直停留在堆棧上，直到被其他東西覆蓋為止。

我懷疑如果您是在C ++中通過指針和malloc分配了堆對像或C本機類型，那麼

1. 使用 volatile
2. 使用編譯指示符使用該變量將代碼括起來並禁用優化。
3. 如果可能，僅將機密彙編成中間值而不是任何命名變量，因此它僅存在在計算過程中。
ol>

在JVM或C＃下，我認為所有選擇都沒有。

有可能在您刪除並刪除內存之前，已將頁面中的內存分頁，這取決於頁面文件中的使用情況分佈如何播放數據，從而可能永遠存在於其中。

因此，要成功從計算機中刪除機密，必須首先通過固定頁面來確保數據永遠不會到達持久性內存。然後確保編譯器沒有優化對要刪除的內存的寫操作。

實際上答案是肯定的，您可能應該在刪除它之前將其覆蓋。如果您是網絡應用程序開發人員，那麼您可能應該在使用 delete 或 free 函數之前覆蓋所有數據。

此錯誤的示例被利用：

用戶可以在輸入字段中插入一些惡意數據。您繼續處理數據，然後調用已分配內存的 free 函數而不會覆蓋它，因此數據將保留在內存中。然後，用戶使您的Web應用程序崩潰（例如，通過上傳非常大的圖片或類似的東西），UNIX系統將把核心內存轉儲到 core 或 core中。 <pid> 文件。然後，如果用戶可以蠻破解 <pid> （這不會花費太長時間），並且核心轉儲文件將被解釋為Web Shell，因為它包含用戶的惡意數據。

int secret = 13123在本地範圍內不是一個常量嗎？

您不應太在意所寫的東西，而該書幾乎值得一讀。實際上，在一些相反的建議下，我建議您故意讓它保持可讀性。而且，用時間相關的字符串隨機填充它，這些字符串不是以標準方式調用的。

這樣，如果您查看黑暗的網站以發現自己是否受到攻擊，則可以準確地知道它是如何完成的。由於數據庫轉儲與刮板轉儲是分開的。