我使用「資源注入」進行掃描時遇到了漏洞。asp.net版本2.0中的「資源注入」修復程序
我無法找到此問題的解決方案。 下面的代碼我使用
Me.FileUploadImg1.SaveAs（Me.Server.MapPath（ 「〜」）& 「\」 & System.Configuration.ConfigurationSettings.AppSettings（ 「library_video」）& 「\」 &「 E」 &的EventID & 「\」 & 「A」 & HttpUtility.HtmlEncode（txtAlbumID.Value）& 「\」 & HttpUtility.HtmlEncode（filenameonly））
刀具提出了以下解決方案：
修復建議： 修復XSS的最簡單方法是驗證所有來自外部來源的信息（即，用戶，基礎設施，外部實體或數據庫系統）。數據的驗證確保數據不包含腳本。驗證數據有兩種主要方法：篩選 所有輸入和轉義所有輸出。
過濾所有輸入 最安全，最可能是解決這一漏洞的最有效的方法是僅接受被認爲是有效的數據，並拒絕 一切，被稱爲「積極」或「白名單」過濾。例如，如果輸入數據預期爲數字，那麼通過拒絕任何不是的輸入來確保這種情況是 。除了拒絕所有數據之外，還可以使用清理例程，該例程檢查特殊字符是否存在，並用另一個字符（例如空格）替換每個字符。 積極過濾的弱選擇是「負面」或「黑名單」過濾。這是一個危險的策略，因爲可能的壞數據集 可能是無限的。採用這種策略意味着必須永遠保留「已知不良」字符和模式的列表，並且根據定義，將會有不完整的保護。 與過濾和轉義有關的消毒行動通常涉及丟棄，拒絕，替換，替換，翻譯和編碼污染的輸入或輸出。 轉義所有輸出 有些場景我們不能依靠過濾來丟棄或拒絕數據，因爲用戶被要求提供 包含特殊字符的輸入內容。爲了處理帶有未確診字符或腳本的特殊輸入內容，通常建議使用轉義的機制，允許將編碼字符流轉換爲特殊的字符集序列，服務器或客戶端意外地執行 。
請在這個問題的c＃代碼中提出一些解決方案。
嗨@Ann L.， 爲了測試安全起見，我們使用的是阿碼 - codesecure工具。但我很確定這個「資源注入」的注入與「跨站腳本」的注入完全沒有關係。 – user3119748
**在文件中的「資源Injecton」被解釋爲： 示例代碼 一個多數民衆贊成被廣泛使用ASP.NET中的功能是文件下載** * <％ strFileName =的Request.QueryString [「路徑。 「]; FileStream fs = new FileStream（strFileName，FileMode.Open，FileAccess.Read）; byte [] buffer = new byte [fs.Length]; fs.Read（buffer，0，fs.Length）; fs.Close（）; Response.Clear（）; Response.ContentType =「application/octet-stream」; Response.AddHeader（「Content-Length」，buffer.Length.ToString（））; Response.BinaryWrite（buffer）; Response.End（）; ％* – user3119748
**以上代碼攻擊示例：** 常見的做法是使用「../」更改目錄。例如，「../../../../boot.ini」可能允許攻擊者從網頁服務器 下載C：\ boot.ini。 – user3119748