Recca Chao 的 gitHub page

推廣網站開發，包含 Laravel 和 Kotlin 後端撰寫、自動化測試、讀書心得等。Taiwan Kotlin User Group 管理員。

View on GitHub

翻譯自

https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/File_Upload_Cheat_Sheet.md

上傳檔案的小抄

簡介

檔案上傳已經是各種應用裡越來越重要的功能，比方說讓用戶可以上傳他們的照片，履歷，或者是展示自己最近工作內容的影片。要保護應用本身以及使用者的安全，檔案上傳功能要可以防範假檔案或者惡意檔案的攻擊。

簡而言之，要實作安全的檔案上傳功能，應該遵守以下原則：

內容

上傳檔案的危險

要保護好系統，知道自己面對什麼樣的問題是非常重要的。這樣才知道具體上要做什麼保護措施。

以下章節展示上傳檔案時隨之而來的風險。

惡意檔案

攻擊者可能會上傳惡意檔案，比方說：

  1. 針對檔案分析器或處理模組的弱點攻擊（比方說 ImageTrick Exploit 和 XXE）
  2. 上傳釣魚檔案（比方說企業簡歷）
  3. 上傳 ZIP bombs 或 XML bombs（也被稱為 billion laughs attack）。或者上傳一個超大的檔案，讓系統容量爆滿，破壞主機的可用性。
  4. 嘗試覆寫系統內已存的檔案
  5. 攻擊客戶端的檔案（XSS、CSRF⋯⋯等）。當其他用戶存取到這些檔案時，會對用戶產生危害。

公開取得檔案的風險

如果上傳的檔案之後會公開，那麼會有其他的風險：

  1. 導致其他文件公開泄露
  2. Initiate a DoS attack by requesting lots of files. Requests are small, yet responses are much larger
  3. File content that could be deemed as illegal, offensive, or dangerous (e.g. personal data, copyrighted data, etc.) which will make you a host for such malicious files.

上傳檔案防護

There is no silver bullet in validating user content. Implementing a defense in depth approach is key to make the upload process harder and more locked down to the needs and requirements for the service. Implementing multiple techniques is key and recommended, as no one technique is enough to secure the service.

副檔名驗證

Ensure that the validation occurs after decoding the file name, and that a proper filter is set in place in order to avoid certain known bypasses, such as the following:

Refer to the Input Validation CS to properly parse and process the extension.

副檔名白名單

只允許使用商業邏輯上極重要的檔案格式，不允許 without allowing any type of non-required extensions. For example if the system requires:

根據應用本身的需求，確保使用傷害最小和風險最低的檔案型態。

副檔名黑名單

只使用副檔名黑名單是非常危險的，除非沒有其他辦法，不然別這樣做。

In order to perform this validation, specifying and identifying which patterns that could should be rejected are used in order to protect the service.

Content-Type Validation

The Content-Type for uploaded files is provided by the user, and as such cannot be trusted, as it is trivial to spoof. Although it should not be relied upon for security, it provides a quick check to prevent users from unintentionally uploading files with the incorrect type.

Other than defining the extension of the uploaded file, its MIME-type can be checked for a quick protection against simple file upload attacks.

This can be done preferrably in a whitelist approach; otherwise, this can be done in a blacklist approach.

File Signature Validation

In conjunction with content-type validation, validating the file’s signature can be checked and verified against the expected file that should be received.

This should not be used on its own, as bypassing it is pretty common and easy.

檔名過濾

惡意檔名有不少種危害系統的可能，比方說使用系統內不合法的字符，或者使用特殊或者限制的檔名。

For Windows, refer to the following MSDN guide. For a wider overview on different filesystems and how they treat files, refer to Wikipedia’s Filename page.

In order to avoid the above mentioned threat, creating a random string as a file-name, such as generating a UUID/GUID, is essential. If the file-name is required by the business needs, proper input validation should be done for client-side (e.g. active content that results in XSS and CSRF attacks) and back-end side (e.g. special files overwrite or creation) attack vectors. File-name length limits should be taken into consideration based on the system storing the files, as each system has its own file name length limit. If user file-names are required, consider implementing the following:

檔案內容驗證

As mentioned in the Public File Retrieval section, file content can contain malicious, inappropriate, or illegal data.

Based on the expected type, special file content validation can be applied:

The File Upload service should allow users to report illegal content, and copyright owners to report abuse.

If there are enough resources, manual file review should be conducted in a sandboxed environment before releasing the files to the public.

Adding some automation to the review could be helpful, which is a harsh process and should be well studied before its usage. Some services (e.g. Virus Total) provide APIs to scan files against well known malicious file hashes. Some frameworks can check and validate the raw content type and validating it against predefined file types, such as in ASP.NET Drawing Library. Beware of data leakage threats and information gathering by public services.

檔案儲存位置

The location where the files should be stored must be chosen based on security and business requirements. The following points are set by security priority, and are inclusive:

  1. Store the files on a different host, which allows for complete segragation of duties between the application serving the user, and the host handling file uploads and their storage.
  2. Store the files outside the webroot, where only administrative access is allowed.
  3. Store the files inside the webroot, and set them in write permissions only.
    • If read access is required, setting proper controls is a must (e.g. internal IP, authorized user, etc.)

Storing files in a studied manner in databases is one additional technique. This is sometimes used for automatic backup processes, non file-system attacks, and permissions issues. In return, this opens up the door to performance issues (in some cases), storage considerations for the database and its backups, and this opens up the door to SQLi attack. This is advised only when a DBA is on the team and that this process shows to be an improvement on storing them on the file-system.

Some files are emailed or processed once they are uploaded, and are not stored on the server. It is essential to conduct the security measures discussed in this sheet before doing any actions on them.

使用者權限

Before any file upload service is accessed, proper validation should occur on two levels for the user uploading a file:

檔案系統權限

Set the files permissions on the principle of least privilege.

Files should be stored in a way that ensures:

上傳下載限制

為了保護上傳容量，應用應該要為上傳功能設置一個合適的檔案大小上限。

If the system is going to extract the files or process them, the file size limit should be considered after file decompression is conducted and by using secure methods to calculate zip files size. For more on this, see how to Safely extract files from ZipInputStream, Java’s input stream to handle ZIP files.

The application should set proper request limits as well for the download service if available to protect the server from DoS attacks.

Java 程式碼節錄

Dominique 所撰寫的 Document Upload Protection

Document Upload Protection repository written by Dominique for certain document types in Java.