如何修复ASP.NET MVC中“Cookie未通过SSL传输(4720)”及会话丢失问题

阿华AIGC实验室

2026-5-15

解决ASP.NET MVC中requireSSL="true"导致Session/TempData丢失的问题

你遇到的是安全配置与会话存储的典型冲突——开启Cookie的SSL强制传输后，Session和依赖Session的TempData无法跨页面传递，但关闭配置又会触发安全扫描的4720漏洞。下面我来拆解原因并给出具体解决步骤：

问题根源分析

当你在Web.config中设置<httpCookies httpOnlyCookies="true" requireSSL="true" />时，所有ASP.NET生成的Cookie（包括Session的ASP.NET_SessionId、TempData依赖的Cookie）都会被标记为Secure属性。这意味着只有在HTTPS请求中，浏览器才会将这些Cookie发送回服务器。如果你的网站存在以下情况，就会导致Session/TempData丢失：

部分页面仍使用HTTP协议（比如跳转链接是HTTP而非HTTPS）
Session的Cookie配置未同步开启SSL强制，与httpCookies设置不匹配
Cookie的SameSite属性设置不当，导致跨页面请求时浏览器不传递Cookie

具体解决方案

1. 强制全站HTTPS访问

首先确保用户访问的所有页面都是HTTPS，这样浏览器才会正常发送带Secure标记的Cookie。可以通过两种方式实现：

方式一：Web.config添加URL重写规则

在<system.webServer>节点下添加重写规则，自动将HTTP请求重定向到HTTPS：

<rewrite>
  <rules>
    <rule name="HTTP to HTTPS redirect" stopProcessing="true">
      <match url="(.*)" />
      <conditions>
        <add input="{HTTPS}" pattern="off" ignoreCase="true" />
      </conditions>
      <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
    </rule>
  </rules>
</rewrite>

方式二：使用`[RequireHttps]`属性

在Controller或Action上添加该属性，强制特定页面使用HTTPS：

[RequireHttps]
public class HomeController : Controller {
    // 你的原有代码
}

[RequireHttps]
public class AdminController : Controller {
    // 你的原有代码
}

2. 同步Session Cookie的SSL配置

仅设置httpCookies可能不够，需要单独配置Session的Cookie属性，确保它也强制使用SSL。在Web.config的<system.web>节点下添加或修改<sessionState>：

<sessionState mode="InProc" cookieless="false" timeout="20">
  <cookieSettings requireSSL="true" />
</sessionState>

这会明确将Session的ASP.NET_SessionIdCookie标记为Secure，与httpCookies的设置保持一致。

3. 配置Cookie的SameSite属性

如果网站存在跨子域跳转场景，需要确保SameSite属性设置正确。在<httpCookies>节点中添加sameSite="None"（注意SameSite=None必须配合Secure=true，这也是你已经开启的配置）：

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

这会告诉浏览器在跨站点请求时也传递Cookie，避免因SameSite默认限制导致Session丢失。

4. 验证TempData的存储方式

TempData默认依赖Session存储，只要Session正常工作，TempData就不会有问题。如果你之前修改过TempData的Provider，需要确认它也支持Secure Cookie场景。默认的SessionStateTempDataProvider是完全兼容的，这一步主要排查自定义Provider的特殊情况。