使 ASP.Net 文件上傳安全

Question

我正在創建一個帶有文件上傳控件的 ASP.Net 表單，然后將表單和文件的詳細信息通過電子郵件發送給另一個管理員。 我想確保這是安全的（對於服務器和收件人）。 附件應該是簡歷，因此我將其限制為典型的文本文檔。

據我所知，最好的辦法是檢查文件擴展名或 MIME 類型是否屬於這種類型，並根據“幻數”進行檢查以驗證擴展名是否未更改。 我不太關心如何去做，但想知道這是否真的足夠了。

我也很樂意使用處理此問題的第三方產品，並且我已經看過一些：

blueimp jQuery 文件上傳http://blueimp.github.io/jQuery-File-Upload/

和cutesoft ajaxuploader http://ajaxuploader.com/Demo/

但是 blueimp one 似乎仍然需要自定義服務器驗證（我猜它只是 jQuery 它只是處理客戶端驗證）並且 .net 一個檢查 MIME 類型與擴展名匹配，但我認為 MIME 類型無論如何都跟隨擴展名。

所以，

當文件作為附件添加但未保存時，我是否需要擔心服務器安全？ 是否有插件或控件可以很好地處理這個問題？ 如果我需要為服務器驗證實現一些東西，我自己是否將 MIME 類型與“幻數”匹配得足夠好？

我確信沒有什么是 100% 防彈的，但文件上傳是很常見的東西，我認為大多數實現都是“足夠安全的”——但是如何！？

如果相關，這是我目前的基本代碼

<p>Please attach your CV here</p>
<asp:FileUpload ID="fileUploader" runat="server" />

並提交

MailMessage message = new MailMessage();
if (fileUploader.HasFile)
{
    try
    {
        if (fileUploader.PostedFile.ContentType == "text")
        {
            // check magic numbers indicate same content type... if(){}

            if (fileUploader.PostedFile.ContentLength < 102400)
            {
                string fileName = System.IO.Path.GetFileName(fileUploader.PostedFile.FileName);
                message.Attachments.Add(new Attachment(fileUploader.PostedFile.InputStream, fileName));
            }
            else
            {
                // show a message saying the file is too large
            }
        }
        else
        { 
           // show a message saying the file is not a text based document
        }
    }
    catch (Exception ex)
    {
        // display ex.Message;
    }
}

Answer 1

服務器永遠不可能是 100% 安全的，但我們應該盡最大努力將事故風險降至最低。 在這一點上我應該說我不是專家，我只是一個計算機科學專業的學生。 所以，這是我在這種情況下會遵循的一種方法。 請評論您可以提供的任何其他提示。

---

一般來說，要獲得安全的表單，必須檢查和驗證所有客戶端輸入。 任何不是來自我們系統的信息都是不可信的。

在我們的案例中來自客戶的輸入：

• 文件名
  • 姓名
  • 擴展
• 文件的內容

擴展

我們並不真正關心 minetype，這是 Web 服務器的信息。 我們關心文件擴展名，因為這是操作系統如何運行/讀取/打開文件的指標。 我們必須只支持特定的文件擴展名（您的管理員的電腦可以處理什么），支持未知的文件類型毫無意義。

名稱（不帶擴展名）

文件名並不總是有價值的信息。 當我處理文件上傳時，我通常將其重命名（設置）為 id（用戶名、時間戳、哈希等）。 如果名稱很重要，請始終檢查/修剪它，如果您只希望字母或數字刪除所有其他字符（我避免留下“/”、“\\”、“.”，因為它們可用於注入路徑）。

所以現在我們假設生成的文件名是安全的。

內容

當您不支持結構化文件時，您就無法驗證文件的內容。 因此，讓專家程序為您執行此操作……使用防病毒軟件掃描它們。 從控制台調用防病毒軟件（小心，使用避免注入的機制）。 許多防病毒軟件也可以掃描 zip 內容（服務器上的文件夾中的惡意文件不是一個好主意）。 始終保持掃描程序更新。

---

在評論中，我建議壓縮文件，以避免在管理員的機器和服務器上自動執行。 管理員機器的防病毒軟件可以在解壓縮之前處理它。

還有一些提示，不要向客戶提供超出他需要的更多信息……不要讓客戶知道文件的保存位置，如果不需要，不要讓網絡服務器訪問它們以進行分發。 保留帶有奇怪操作的日志（文件名中的斜杠、文件過大、名稱過長、警告擴展名如“sh”“exe”“bat”），如果發生任何奇怪的事情，請通過電子郵件向管理員報告（很高興知道您的保護措施有效）。

所有這些都會造成服務器工作負載（更多系統漏洞），因此您可能應該在接受新文件上傳請求之前計算當前掃描/檢查的文件數量（這就是我發起 DDoS 攻擊的地方）。

通過快速谷歌搜索Avast！ 對於 Linux - 命令行指南，我不宣傳 Avast，我只是將其作為現有示例展示。

最后但並非最不重要的一點是，您並不偏執，我管理着一個我編寫的自定義翻譯系統……垃圾郵件和黑客攻擊不止一次發生。

---

還有一些想法，在網頁上運行的 JavaScript 只對客戶端的計算機是安全的（感謝瀏覽器的安全性）。 我們可以使用它來防止向服務器發送無效帖子，但這並不能確保此類請求不會被完成，因為 JavaScript 可以被繞過/編輯。

因此，所有 JavaScript 解決方案都僅用於第一次驗證（通常只是為了幫助用戶糾正錯誤）並正確設置表單數據。