浮雲雅築: [研究]Ｗeb.Config 的 sameSite 設定，某些情況下 AppScan 還是不認為有設定，解法 ?

[研究]Ｗeb.Config 的 sameSite 設定，某些情況下 AppScan 還是不認為有設定，解法 ?

2025-07-07

環境：Visual Studio 2022 + ASP.NET + WebForm + Web Application + C# + SQL Server 2019 + SQL Server Management Studio (SSMS) 20

********************************************************************************

Ｗeb.Config 的 sameSite 設定，某些情況下 AppScan 還是不認為有設定，解法 ?

ChatGPT 說：

非常好的問題，針對你提到的：

✅ Web.Config 已經設定 <httpCookies sameSite="Strict" />

⚠️ 但 HCL AppScan（或其他掃描工具）仍報告 SameSite 弱點

這是常見現象，以下原因與解法說明：

一、原因解析

1.AppScan 檢查的是回應頭 (Response Header) 的實際 Set-Cookie

AppScan 會觀察實際 HTTP 回應中：

Set-Cookie: ASP.NET_SessionId=xxxx; path=/; SameSite=Strict

如果掃描過程中：

某些 Cookie 未包含 SameSite
或因動態程式碼覆蓋、框架 Bug，導致漏設
第三方元件自行設置 Cookie，未受 Web.Config 控制

則 AppScan 視為「存在 SameSite 弱點」。

2.Web.Config 限制

<httpCookies sameSite="Strict" /> 主要影響：

FormsAuthentication Cookie
SessionID Cookie

其他自訂或第三方程式碼動態建立的 Cookie，不會自動套用

3.舊版 ASP.NET 行為不一致

.NET Framework 4.7.2 前，未內建 SameSite 支援
某些舊版雖配置了 <httpCookies>，但實際回應未反映
部分瀏覽器或中間層（如負載平衡設備）可能攔截或改寫 Set-Cookie

二、標準解法

1. 明確在程式碼層設置 SameSite，C#

HttpCookie cookie = new HttpCookie("TestCookie", "value");
cookie.SameSite = SameSiteMode.Strict;
cookie.Secure = true;
Response.Cookies.Add(cookie);

✔️ 確保自訂所有 Cookie 明確設定 SameSite

2. 在 Global.asax.cs，針對 ASP.NET 內建 Cookie 額外補強

protected void Application_EndRequest(Object sender, EventArgs e)
{
    if (Response.Cookies[".ASPXAUTH"] != null)
    {
        Response.Cookies[".ASPXAUTH"].SameSite = SameSiteMode.Strict;
    }

    if (Response.Cookies["ASP.NET_SessionId"] != null)
    {
        Response.Cookies["ASP.NET_SessionId"].SameSite = SameSiteMode.Strict;
    }
}

3. 在 Global.asax.cs，全面掃描 Response.Cookies

通用方案：

protected void Application_EndRequest(Object sender, EventArgs e)
{
    foreach (string key in Response.Cookies)
    {
        var cookie = Response.Cookies[key];
        if (cookie != null && cookie.SameSite == (SameSiteMode)(-1)) // 未設置 SameSite
        {
            cookie.SameSite = SameSiteMode.Strict;
        }
    }
}

比較：

寫法	覆蓋範圍	優點
foreach 全掃描寫法	所有 Response.Cookies	自動覆蓋所有未設置 SameSite 的 Cookie
指定 .ASPXAUTH、SessionId 寫法	只針對特定 Cookie	控制更明確，但其他 Cookie 不處理

4. 升級 .NET Framework

若可行，建議：

升級至 .NET Framework 4.8
完整支援 Web.Config 同時結合程式碼設置
減少非預期行為

5. 確認 HTTPS 配置

Web.Config 若設置：

<httpCookies sameSite="None" requireSSL="true" />

✔️ 確保網站實際使用 HTTPS，否則瀏覽器拒絕該 Cookie，AppScan 誤判為弱點

三、實務經驗補充

許多團隊發現：

✅ 單靠 Web.Config 設定，掃描工具仍偶爾報告 SameSite 缺失
✅ 結合程式碼層全域補強，是最穩定的解法
✅ 少數自訂控制元件、第三方 SDK 需檢查其 Cookie 操作方式，必要時 override

四、總結建議

✔️ Web.Config 設置是基礎
✔️ Application_EndRequest 或 BeginRequest 額外補強 Response.Cookies
✔️ 自訂、第三方 Cookie 主動設置 SameSite
✔️ 升級至新版本 ASP.NET 提升整體兼容性
✔️ 掃描前檢查實際回應的 Set-Cookie 標頭，確保符合預期

********************************************************************************

foreach 全掃描寫法，會否造成甚麼功能癱瘓不能用？

ChatGPT 說：

【理論上可能的影響】

這段程式會影響到所有回應中的 Cookie，不論是你自己程式設的，還是 ASP.NET 內建機制產生的，尤其：

✅ Session Cookie (ASP.NET_SessionId)
✅ Forms 認證 Cookie (.ASPXAUTH)
✅ ViewState MAC 驗證依賴的加密 Cookie（若有額外保護機制）
✅ 你自己加的其他業務用 Cookie

因此影響面如下：

【常見問題與功能癱瘓風險】

項目	影響說明
Session 無法跨站點維持	SameSite.Strict 會禁止從外站跳回時附帶 ASP.NET_SessionId，導致 session 斷線。
第三方登入或跳轉失效	如果用戶從其他系統跳轉回來，Session 或認證 Cookie 不附帶，造成驗證失敗。
OAuth、SSO 等登入流程失效	外部登入服務重導回來後 Cookie 無法帶上，登入流程中斷。
部分 iframe、跨域功能受限	嵌入或跨域 POST 請求因 Cookie 被阻擋導致功能錯誤。

********************************************************************************

指定 .ASPXAUTH、SessionId 寫法，會否仍有 AppScan 掃描發現 SameSite 沒設定的情況？

ChatGPT 說：

仍然有可能，原因如下：

來源類型	SameSite 設定情況
.ASPXAUTH、ASP.NET_SessionId	你強制設置，若掃描時這兩個 Cookie 存在，會通過。
其他自訂 Cookie	若程式碼其他地方設置 Cookie，沒設 SameSite，仍會被報告。
第三方元件、舊有程式產生的 Cookie	沒有設 SameSite，掃描也會報告。

重點：AppScan 是看所有 Response.Set-Cookie 標頭，任何一個 Cookie 沒設 SameSite，都會列為弱點。

(完)

相關

浮雲雅築

2025年7月7日星期一

[研究]Ｗeb.Config 的 sameSite 設定，某些情況下 AppScan 還是不認為有設定，解法 ?

沒有留言:

張貼留言

2025年7月7日 星期一

[研究]Ｗeb.Config 的 sameSite 設定，某些情況下 AppScan 還是不認為有設定，解法 ?

沒有留言:

張貼留言

2025年7月7日星期一