BinaryFormatter 安全性指南BinaryFormatter security guide

本文適用于下列 .NET 部署:This article applies to the following .NET implementations:

  • .NET Framework 所有版本.NET Framework all versions
  • .NET Core 2.1-3。1.NET Core 2.1 - 3.1
  • .NET 5.0 和更新版本.NET 5.0 and later



BinaryFormatter 類型是危險的, 建議用於資料處理。The BinaryFormatter type is dangerous and is not recommended for data processing. 應用程式應該儘快停止使用 BinaryFormatter ,即使它們認為所要處理的資料值得信任。Applications should stop using BinaryFormatter as soon as possible, even if they believe the data they're processing to be trustworthy. BinaryFormatter 是不安全的,且無法進行安全。BinaryFormatter is insecure and can't be made secure.

本文也適用于下列類型:This article also applies to the following types:

還原序列化弱點是在, 處理要求承載的威脅類別。Deserialization vulnerabilities are a threat category where request payloads are processed insecurely. 針對應用程式成功利用這些弱點的攻擊者,可能會在目標應用程式內造成拒絕服務 (DoS) 、資訊洩漏或遠端程式碼執行。An attacker who successfully leverages these vulnerabilities against an app can cause denial of service (DoS), information disclosure, or remote code execution inside the target app. 此風險類別一致地讓 OWASP 前10個This risk category consistently makes the OWASP Top 10. 目標包括以 各種語言撰寫的應用程式,包括 C/c + +、JAVA 和 c #。Targets include apps written in a variety of languages, including C/C++, Java, and C#.

在 .NET 中,最大的風險目標是使用類型來還原序列化資料的應用程式 BinaryFormatterIn .NET, the biggest risk target is apps that use the BinaryFormatter type to deserialize data. BinaryFormatter 在整個 .NET 生態系統中廣泛使用,因為它的強大功能和易用性。BinaryFormatter is widely used throughout the .NET ecosystem because of its power and its ease of use. 不過,這個相同的威力讓攻擊者能夠影響目標應用程式內的控制流程。However, this same power gives attackers the ability to influence control flow within the target app. 成功的攻擊可能會導致攻擊者能夠在目標進程的內容中執行程式碼。Successful attacks can result in the attacker being able to run code within the context of the target process.

更簡單的方式是,假設對承載的呼叫 BinaryFormatter.Deserialize 等同于將該承載解讀為獨立可執行檔並加以啟動。As a simpler analogy, assume that calling BinaryFormatter.Deserialize over a payload is the equivalent of interpreting that payload as a standalone executable and launching it.

BinaryFormatter 安全性弱點BinaryFormatter security vulnerabilities


搭配 BinaryFormatter.Deserialize 未受信任的輸入使用時,方法 絕對 不安全。The BinaryFormatter.Deserialize method is never safe when used with untrusted input. 強烈建議取用者改為考慮使用本文稍後所述的其中一個替代方案。We strongly recommend that consumers instead consider using one of the alternatives outlined later in this article.

BinaryFormatter 在還原序列化弱點之前實作為充分瞭解的威脅類別。BinaryFormatter was implemented before deserialization vulnerabilities were a well-understood threat category. 因此,程式碼不會遵循新式的最佳作法。As a result, the code does not follow modern best practices. Deserialize方法可作為攻擊者用來對取用應用程式執行 DoS 攻擊的向量。The Deserialize method can be used as a vector for attackers to perform DoS attacks against consuming apps. 這些攻擊可能會導致應用程式沒有回應,或導致非預期的進程終止。These attacks might render the app unresponsive or result in unexpected process termination. 這類的攻擊無法透過 SerializationBinder 或任何其他設定交換器來緩和 BinaryFormatterThis category of attack cannot be mitigated with a SerializationBinder or any other BinaryFormatter configuration switch. .NET 會將此行為視為 設計 ,且不會發出程式碼更新來修改行為。.NET considers this behavior to be by design and won't issue a code update to modify the behavior.

BinaryFormatter.Deserialize 可能很容易受到其他攻擊類別的攻擊,例如資訊洩漏或遠端程式碼執行。BinaryFormatter.Deserialize may be vulnerable to other attack categories, such as information disclosure or remote code execution. 利用自訂之類的功能 SerializationBinder 可能無法正確地緩和這些風險。Utilizing features such as a custom SerializationBinder may be insufficient to properly mitigate these risks. 有一個可能的原因是,.NET 無法實際發佈安全性更新時,會發現新穎弱點。The possibility exists that a novel vulnerability will be discovered for which .NET cannot practically publish a security update. 取用者應該評估其個別案例,並考慮其對這些風險的潛在風險。Consumers should assess their individual scenarios and consider their potential exposure to these risks.

我們建議取用 BinaryFormatter 者對其應用程式執行個別的風險評估。We recommend that BinaryFormatter consumers perform individual risk assessments on their apps. 消費者必須自行負責判斷是否要使用 BinaryFormatterIt is the consumer's sole responsibility to determine whether to utilize BinaryFormatter. 取用者應該有風險來評估使用的安全性、技術、信譽、法律和法規需求 BinaryFormatterConsumers should risk assess the security, technical, reputation, legal, and regulatory requirements of using BinaryFormatter.

慣用的替代方案Preferred alternatives

.NET 提供數個可安全處理不受信任資料的內建序列化程式:.NET offers several in-box serializers that can handle untrusted data safely:

危險的替代方案Dangerous alternatives

避免下列序列化程式:Avoid the following serializers:

上述序列化程式全都執行不受限制的多型多型還原序列化,而且也很危險 BinaryFormatterThe preceding serializers all perform unrestricted polymorphic deserialization and are dangerous, just like BinaryFormatter.

假設資料值得信任的風險The risks of assuming data to be trustworthy

通常,應用程式開發人員可能會認為它們只處理受信任的輸入。Frequently, an app developer might believe that they are processing only trusted input. 在某些罕見的情況下,安全的輸入案例是 true。The safe input case is true in some rare circumstances. 但是,如果承載不需要開發人員就能跨越信任界限,則會比較常見。But it's much more common that a payload crosses a trust boundary without the developer realizing it.

請考慮使用內部部署伺服器 ,讓員工使用其工作站的桌面用戶端與服務互動。Consider an on-prem server where employees use a desktop client from their workstations to interact with the service. 這種情況可能會被視為「安全」的設定,可 BinaryFormatter 接受使用。This scenario might be seen naïvely as a "safe" setup where utilizing BinaryFormatter is acceptable. 不過,此案例提供惡意程式碼的向量,可取得單一員工電腦的存取權,以散佈到整個企業。However, this scenario presents a vector for malware that gains access to a single employee's machine to be able to spread throughout the enterprise. 惡意程式碼可以利用企業使用 BinaryFormatter ,從員工的工作站橫向移至後端伺服器。That malware can leverage the enterprise's use of BinaryFormatter to move laterally from the employee's workstation to the backend server. 然後,它會竊取公司的敏感性資料。It can then exfiltrate the company's sensitive data. 這類資料可能包括交易秘密或客戶資料。Such data could include trade secrets or customer data.

另外也請考慮使用 BinaryFormatter 來保存儲存狀態的應用程式。Consider also an app that uses BinaryFormatter to persist save state. 這可能是一種安全的案例,因為讀取和寫入您自己的硬碟上的資料,代表的是一種小威脅。This might at first seem to be a safe scenario, as reading and writing data on your own hard drive represents a minor threat. 不過,在電子郵件或網際網路之間共用檔很常見,大部分的使用者都不會察覺以具風險的行為來開啟這些下載的檔案。However, sharing documents across email or the internet is common, and most end users wouldn't perceive opening these downloaded files as risky behavior.

您可以利用這個案例來惡意地產生效果。This scenario can be leveraged to nefarious effect. 如果應用程式是遊戲,共用儲存檔案的使用者在不知情的情況下會有風險。If the app is a game, users who share save files unknowingly place themselves at risk. 開發人員本身也可以設為目標。The developers themselves can also be targeted. 攻擊者可能會傳送電子郵件給開發人員的技術支援、附加惡意的資料檔案,並要求支援人員加以開啟。The attacker might email the developers' tech support, attaching a malicious data file and asking the support staff to open it. 這類攻擊可能會讓攻擊者在企業中據點。This kind of attack could give the attacker a foothold in the enterprise.

另一種情況是將資料檔案儲存在雲端儲存體中,並自動在使用者的電腦之間同步處理。Another scenario is where the data file is stored in cloud storage and automatically synced between the user's machines. 能夠取得雲端儲存體帳戶存取權的攻擊者,可能會損害資料檔案。An attacker who is able to gain access to the cloud storage account can poison the data file. 此資料檔案將會自動同步至使用者的電腦。This data file will be automatically synced to the user's machines. 使用者下次開啟資料檔案時,會執行攻擊者的承載。The next time the user opens the data file, the attacker's payload runs. 因此,攻擊者可以利用雲端儲存體帳戶入侵來獲得完整的程式碼執行許可權。Thus the attacker can leverage a cloud storage account compromise to gain full code execution permissions.

請考慮從桌面安裝模型移至雲端優先模型的應用程式。Consider an app that moves from a desktop-install model to a cloud-first model. 此案例包括從桌面應用程式或豐富型用戶端模型移至 web 架構模型的應用程式。This scenario includes apps that move from a desktop app or rich client model into a web-based model. 針對桌面應用程式所繪製的任何威脅模型,都不一定適用于雲端式服務。Any threat models drawn for the desktop app aren't necessarily applicable to the cloud-based service. 桌面應用程式的威脅模型可能會將指定的威脅解除為「不感興趣,讓用戶端遭受攻擊」。The threat model for the desktop app might dismiss a given threat as "not interesting for the client to attack itself." 但在將遠端使用者視為 (用戶端) 攻擊雲端服務本身時,相同的威脅可能會變得有趣。But that same threat might become interesting when it considers a remote user (the client) attacking the cloud service itself.


一般而言,序列化的目的是要將物件傳入或移出應用程式。In general terms, the intent of serialization is to transmit an object into or out of an app. 威脅模型化練習幾乎一律會將這類資料傳輸標示為跨越信任界限。A threat modeling exercise almost always marks this kind of data transfer as crossing a trust boundary.

進一步資源Further resources