课程笔记：XSS 劫持 Cookie 的防护策略

课程名称：计算机网络应用 核心摘要：本讲围绕 XSS 攻击窃取 Cookie 的风险展开，讲解通过设置 HttpOnly 属性阻止 JavaScript 读取 Cookie 的核心防护原理。演示 Spring Boot 项目配置与流量网关 Filter 统一处理两种实现方式，强调互联网项目中 Cookie 防护是必备项。

一、核心概念与原理

XSS（跨站脚本攻击）：攻击者向页面植入恶意 JS 脚本，在受害者浏览器端执行。
窃取路径：通过 document.cookie 读取当前域下的 Cookie 信息。
危害升级：获取 Cookie ≈ 获取用户会话权限，可冒充用户身份（会话劫持 / Cookie 劫持），必须极力避免。

1.2 防护核心：HttpOnly 属性

HttpOnly 是 Cookie 的一个属性标志，设置后该 Cookie 仅能通过 HTTP(S) 协议传输，禁止 JS 脚本通过 document.cookie 访问。
作用：即使页面存在 XSS 漏洞，攻击者也无法通过脚本读取受保护的 Cookie，从根源上阻断 Cookie 窃取。
Servlet 容器默认值：默认即为 true（如 Tomcat 的 JSESSIONID 默认带 HttpOnly），生产环境应保持开启。

二、技术细节与协议分析

2.1 HttpOnly 生效前后对比

验证方式	`HttpOnly=false`	`HttpOnly=true`
F12 → Network → Headers → Cookies	可见	可见（仅传输层可见）
控制台 `document.cookie`	可读取 Cookie 值	返回空字符串 `""`
控制台 `alert(document.cookie)`	弹窗显示 Cookie	弹窗为空
XSS 脚本窃取	可窃取（存在风险）	无法窃取（已防护）

说明：HttpOnly 仅限制脚本读取，不影响浏览器自动在请求头中携带 Cookie，业务会话正常工作。

Set-Cookie: JSESSIONID=<sessionId值>; HttpOnly

Set-Cookie 属于 HTTP 响应头，由服务端下发。
多个属性以 分号 ; 拼接，如 ; HttpOnly、; Secure、; SameSite 等。

三、实践应用与配置命令

3.1 方式一：Spring Boot 项目配置（推荐单体/微服务项目）

# application.properties / application.yml
# 显式开启 HttpOnly（默认即为 true，演示时可设为 false）
server.servlet.session.cookie.http-only=true

# application.yml 形式
server:
  servlet:
    session:
      cookie:
        http-only: true

演示流程：将配置设为 false → 重启不生效 → F12 刷新 → document.cookie 可读取 → 改回 true（或删除该行使用默认值）→ 重启生效 → document.cookie 返回空。

3.2 方式二：流量网关 Filter 统一处理（适用于网关层统一拦截）

// 在流量网关的 Filter 过滤器中统一处理所有响应
// 通过 response.setHeader 设置 Set-Cookie 响应头
response.setHeader(
    "Set-Cookie",
    "JSESSIONID=" + request.getSession().getId() + "; HttpOnly"
);

要点：
setHeader 设置的是 响应头（Set-Cookie）。
Key 为 Set-Cookie，Value 由 JSESSIONID=<sessionId> 拼接 ; HttpOnly 组成。
适合未使用 Spring Boot 或需在网关层做综合性统一处理的场景。

3.3 两种方式选型对比

维度	Spring Boot 配置	网关 Filter 统一处理
适用场景	Spring Boot 单体/微服务项目	多技术栈混合、网关统一治理
实现位置	应用配置文件	流量网关过滤器
维护成本	低，声明式配置	中，需编写过滤器代码
覆盖范围	单应用	全局流量统一覆盖

四、重点与难点提示

考点：HttpOnly 的作用是禁止 JS 脚本读取 Cookie，但不影响浏览器正常发送 Cookie，二者不可混淆。
易错点：HttpOnly 不能防御 XSS 攻击本身，仅能阻断 Cookie 被窃取这一后果；XSS 的根治仍需输入过滤、输出编码等手段。
易错点：修改配置后必须重启服务才会生效，热修改无效。
默认值：Servlet 容器（如 Tomcat）JSESSIONID 的 HttpOnly 默认为 true，生产环境切勿关闭。
面试题：如何防止 XSS 攻击窃取 Cookie？→ 答：设置 HttpOnly 属性，配合 Secure（仅 HTTPS 传输）、SameSite（防 CSRF）等属性综合防护。
工程实践：互联网项目中 Cookie 防护 100% 需要做，属基础安全规范。

五、课后疑问/遗留问题

HttpOnly、Secure、SameSite 三者如何组合使用才能形成完整的 Cookie 安全防护体系？
设置 HttpOnly 后，前端是否还有其他方式间接获取会话信息？前后端分离架构下如何设计 Token 方案（如 JWT）替代 Cookie？
若网关层已统一处理 HttpOnly，下游各服务是否还需重复配置？是否存在响应头覆盖冲突？
后续课程是否讲解 CSRF 防护与 SameSite 属性的联动关系？