[研究]ASP.NET WebForm 網站被 HCL AppScan 10.18.0 報告【重大】【參數指令注入】弱點，如何處理？
2025-07-17
- 掃描目標 URL：https://(domain)/(遮蔽)
- 參數來源：__AntiXsrfToken（屬於 ASP.NET 的防偽標記 Cookie）
- 測試方式：將 Cookie __AntiXsrfToken 加入一段類似 ping 的命令字串，如：
(遮蔽) " ping -c 1 v3-ping-xxx.adns.appsechcl.com #
接著觀察是否有 DNS 查詢請求到該 *.adns.appsechcl.com 網域。 - 漏洞推論機制：若 AppScan 的測試 payload 出現在外部 DNS 查詢中，AppScan 就推論伺服器有可能執行了該命令（如 ping）。
| 原因 | 是否代表漏洞？ |
| 瀏覽器預讀 / 預取 | ❌ 否 |
| CDN / WAF / 防火牆預掃描（如 Cloudflare） | ❌ 否 |
| 第三方分析工具（如 Google Tag Manager）誤觸發 | ❌ 否 |
| Web 應用程式有紀錄，但無執行（如 log 記錄） | ❌ 否 |
| Web API 回傳未清理內容（如原樣顯示 Cookie 值） | ⚠️ 需注意 |
- 如果完全沒用，幾乎可確定為誤判。
- 如果有，也請確認是否有傳遞該值給：
- Process.Start() / ShellExecute
- 動態 SQL 查詢 / 呼叫系統命令
- 搜尋你的網站中是否會在 HTML、JavaScript 或回應 header 中出現 __AntiXsrfToken 的值。
- 若會回顯，雖然不是指令注入，但有資訊洩漏（Information Disclosure）風險。
var token = Request.Cookies["__AntiXsrfToken"];
var cmd = "ping " + token;
Process.Start("cmd.exe", "/c " + cmd);
|
若沒有這類程式碼，則基本可斷定為誤判。
- 說明使用的為 ASP.NET 內建的防偽 Cookie，未被用於系統命令或資料庫操作。
- 強化輸入來源控管：
<httpCookies httpOnlyCookies="true" requireSSL="true" /> |
3.在 HTTP 回應中隱藏 Cookie 值或避免回顯。
| 項目 | 結論 |
| 指令注入是否存在？ | ❌ 極可能為誤判 |
| 掃描機制是否合理？ | ✅ 技術上合理，但可能誤判 |
| 是否需改善？ | ⚠️ 若有回顯 Cookie，建議改善 |
********************************************************************************
為何會產生此種誤判 ?
ChatGPT 說：
這類誤判通常來自 HCL AppScan 使用的 OAST 技術（Out-of-Band Application Security Testing），這是一種利用「外部觀察系統行為」的掃描方式，不是根據 HTTP Response 判斷，而是觀察 DNS、HTTP 或其他協議是否有回應測試資料。
🔍 產生這類誤判的 核心原因
1. 測試方法：透過 payload + DNS callback
AppScan 會嘗試將一段「類似指令」的 payload（如 "ping -c 1 somehost.appsechcl.com"）注入到各種輸入欄位，包括：
- URL 參數
- Cookie
- POST 表單
- Header
然後 AppScan 會監控它自己控制的 DNS（例如 appsechcl.com）來看伺服器是否發出 DNS 查詢，藉此推論「伺服器是否真的執行該指令」。
2. 誤判場景範例
以下這些情境，都可能觸發 AppScan DNS 監控機制，但實際上伺服器並沒有漏洞：
| 情境 | 為何會造成誤判？ |
| Web 應用程式將 Cookie 或輸入資料寫入 Log 檔 | Log server（如 Splunk、ELK）有 DNS 預抓特性，會發出查詢 |
| WAF / 防火牆偵測不明資料自動觸發 DNS 分析 | 某些防火牆會偵測 payload 並進行反解，產生外部查詢 |
| 內容安全服務 / 分析工具（如 Sentry, New Relic）收集資料後發出查詢 | 回報資料的伺服器去解讀 payload，引發 DNS 請求 |
| 瀏覽器 / Proxy / CDN 預先存取連結資料 | 不等頁面執行就嘗試載入 DNS |
🧪 AppScan 常用的「誤判觸發方式」
| 測試位置 | 範例 payload | DNS 查詢方式 | 可能誤判？ |
| Cookie | __AntiXsrfToken=abc" ping -c 1 x.appsechcl.com # | 若 Cookie 被記錄或處理 | ✅ 很常見 |
| Header | User-Agent: ping -c 1 x.appsechcl.com | 被寫入 log 或 proxy 分析 | ✅ |
| URL param | ?name=abc" ping -c 1 x.appsechcl.com | 若參數被展示或回顯 | ✅ |
🔒 ASP.NET 下常見誤判對象：__AntiXsrfToken
ASP.NET 自動產生的 Cookie __AntiXsrfToken：
- 不會回顯於頁面上
- 伺服器端自動驗證，開發者通常不會操作其值
- 若被 AppScan 注入指令類字串，僅是以測試 DNS 查詢有無發出來判斷漏洞是否存在
因此，若你未主動在後端讀取該 Cookie 並處理成系統命令或 SQL，則幾乎一定是誤判。
✅ 避免誤判的做法建議
| 做法 | 說明 |
| 不在伺服器 Log 中記錄敏感 Cookie 或輸入值 | 避免觸發防護或監控系統 |
| 加強 Cookie HttpOnly 與 Secure 設定 | 減少外部 JavaScript 讀取，避免預抓 |
| 檢查 Web 防火牆設定，是否會主動觸發外部查詢 | 某些 WAF 有啟發式分析導致 DNS 查詢 |
| 說明掃描結果來源於非預期查詢路徑 | 回報安全稽核者這是 OAST 誤判 |
🧾 總結
| 項目 | 說明 |
| 誤判原因 | AppScan 誤認外部 DNS 查詢是伺服器執行了指令 |
| 實際未執行指令 | ASP.NET 的 __AntiXsrfToken 是防禦機制，非輸入處理機制 |
| 造成 DNS 查詢來源 | 日誌系統、WAF、CDN、外部 JS 載入行為 |
| 應對方式 | 檢查是否有回顯、log、或非預期輸入記錄 |
********************************************************************************
2025-07-18補
實際到受測主機測試
✅ DNS 查詢會發送到內部 DNS Server 172.16.xxxx.xxx
❌ 內部 DNS Server 未能將此查詢往外轉送，或被網路政策擋下
根據這些事實，在這種網路架構下：
AppScan 嘗試觸發 SSRF、Command Injection、外部連線等弱點時，可能無法實際送出封包
因為：主機連 DNS 查詢都 timeout，就不可能觸發成功的 OOB（Out-of-Band）漏洞
🔍 AppScan 報告是否為誤判？
本次掃描報告中出現的 OOB 連線測試（如 v3-ping-xxx.adns.appsechcl.com），實測本主機無法進行外部 DNS 查詢（內部 DNS 無法解析外部域名），可合理判定為 誤判（False Positive）。
********************************************************************************
實際上，和 ChatGPT 討論前，已經和參與開發的開發工程師 (也是資安工程師) 討論過，對方認為是誤判。
另外同一個網站使用過 AWVS (Acunetix | Web Application Security Scanner) 正式合法花錢採購的版本測試過，不管重大(危險)、高、中等級都無此問題。
********************************************************************************
(完)
沒有留言:
張貼留言