Cookie on SoulJian小站

Cookie 与 Session 入门

Sat, 29 Aug 2026 10:00:00 +0800

写在前面：合法学习边界

本文讲解会话机制的原理与防御。不要拿真实网站、企业系统去测试会话固定、会话劫持或伪造 Cookie。所有验证必须在自建靶场或明确授权的测试环境中完成。

一、为什么 HTTP 需要“会话”

HTTP 本身是无状态的，每次请求都是独立的。服务器收到两次请求，默认不知道是不是同一个人。

但真实业务需要“记住登录状态”，所以出现了会话机制。常见分工是：

1
2


Cookie：浏览器保存的小片段，随请求自动携带
Session：服务端保存的状态，客户端只拿一个标识

理解这两者，才能看懂“登出无效”“换个浏览器又要登录”“会话被劫持”这些问题。

二、Cookie 是什么

Cookie 是服务器通过 Set-Cookie 下发给浏览器的小数据块，浏览器之后会在同域请求里带上它。

一次典型交互：

1
2


服务器：Set-Cookie: sessionid=abc123; Path=/; HttpOnly; Secure; SameSite=Lax
浏览器：Cookie: sessionid=abc123

Cookie 上常见的属性直接决定安全边界：

1
2
3
4
5


Domain / Path：哪些地址会带这个 Cookie
HttpOnly：禁止 JS 读取，防 XSS 直接偷走
Secure：仅 HTTPS 下传输
SameSite：控制跨站请求是否携带
Expires / Max-Age：有效期

如果 Cookie 里直接放了用户名、角色甚至明文密码，那就是把信任交给了客户端，风险很大。

三、Session 是什么

Session 通常放在服务端内存、Redis 或数据库里。客户端只持有 session id，服务端拿这个 id 去查状态。

典型流程：

1
2
3
4


登录成功
服务端创建会话，生成 session id
Set-Cookie 返回给客户端
后续请求带 session id，服务端校验

这里最关键的一句话：Session 内容在服务端，客户端只有一把钥匙。如果把用户身份放在客户端 Cookie 里自己拼，等于把门锁交给了别人。

四、常见风险

1. 会话固定

登录前和登录后 session id 没变。攻击者可以先给自己发一个 session id，诱导用户用它登录，登录后攻击者复用同一个 id。

防御重点是：登录成功后必须重新生成 session id。

2. 会话劫持

session id 被偷，攻击者就能冒充用户。偷取途径包括：

1
2
3


XSS 偷 Cookie（没 HttpOnly）
HTTP 明文传输（没 Secure）
日志、Referer、第三方脚本泄露

3. 会话过期管理不当

会话永远不过期、宽限期过长、登出只清前端不清理服务端，都会放大风险。

4. 并发登录与暴力破解

没有限制单账号登录会话数量、没有失败次数限制，容易被撞库或滥用。

五、防御建议

1
2
3
4
5
6


登录成功后轮换 session id
Cookie 加 HttpOnly、Secure、SameSite=Lax/Strict
设置合理过期时间并支持服务端失效
敏感操作要求二次认证
限制异常登录和会话复用
敏感 Cookie 用独立隔离（如同源策略 + 独立域名）

六、报告中的正确写法

示例：

1
2
3


发现：登录成功后 session id 未重新生成，Cookie 未设置 HttpOnly 且站点允许 HTTP 访问。
风险：可能被会话固定、XSS 窃取会话导致冒充登录态。
建议：登录后重新生成 session id；Cookie 增加 HttpOnly、Secure、SameSite；强制 HTTPS。

写报告时要把“怎么验证的、影响面、修复建议”说清楚，而不是只写“会话不安全”。

七、小结

Cookie 只是标识，Session 才是状态。真正要保护的是服务端会话，而不是客户端那张“钥匙”。把这两者分开理解，会话固定、劫持、过期这些问题就有了统一的解释。

XSS 原理与防御

Sat, 29 Aug 2026 04:45:00 +0800

写在前面：合法学习边界

本文讲解 XSS 的原理与防御。所有示例只用于理解漏洞触发机制，不能直接用于真实网站攻击。任何 XSS 测试都必须在自建靶场、公司授权测试环境或明确书面授权的目标上进行。未经授权窃取 Cookie、劫持会话、执行脚本或读取用户数据，可能违反《网络安全法》《数据安全法》《个人信息保护法》和《刑法》相关规定。

一、XSS 的本质

XSS（跨站脚本攻击）的本质是：浏览器把攻击者提供的输入当成可执行 JavaScript 执行了。

它利用的是浏览器的信任机制：

1
2
3


网页内容由服务器返回
脚本来自网页自身
浏览器默认信任同域脚本

如果后端或前端把用户输入直接插入页面，且没有正确处理上下文，攻击者就可能把一段脚本塞进页面中。

二、XSS 的常见类型

1. 存储型 XSS

恶意脚本被保存到服务器，例如评论、个人资料、商品描述、上传文件名。后续访问者打开页面时都会执行脚本。

存储型 XSS 危害通常更大，因为影响范围更广。

2. 反射型 XSS

恶意脚本通过 URL 参数、搜索框、表单回显进入页面，不会保存下来，但特定链接被打开时可能执行。

反射型 XSS 常用于钓鱼和会话劫持。

3. DOM 型 XSS

恶意脚本发生在浏览器端。页面 JS 把某个 DOM 值写入 innerHTML、document.write 或事件属性，浏览器执行了其中的脚本。

DOM 型 XSS 常见于：

1
2
3
4


URL hash 处理
前端路由参数
搜索框回显
富文本编辑器

三、为什么“编码”是关键

XSS 不是简单的“有 <script> 就危险”。危险来自“上下文”。

不同上下文的编码规则不同：

1
2
3
4
5


HTML 文本上下文
HTML 属性上下文
JavaScript 字符串上下文
URL 上下文
CSS 上下文

正确防御是：

1
2
3


在输出时按上下文编码
不要盲目信任前端框架
不要把所有输出都当成安全

四、常见危险点

1. innerHTML

1

element.innerHTML = userInput

如果 userInput 中包含 <img onerror="...">，浏览器可能执行脚本。

2. document.write

旧式脚本中常见：

1

document.write(userInput)

这种写法容易破坏页面安全边界。

3. 事件属性

1

<img src=x onerror="alert(1)">

事件属性是常见触发点。

4. URL 跳转

某些旧系统会把用户输入直接放入 href 或 location.href。如果上下文没处理好，也可能成为 XSS 入口。

影响与危害

XSS 能造成：

1
2
3
4


窃取 Cookie/会话（账号被劫持）
钓鱼与页面篡改
键盘记录
配合 CSRF 执行恶意操作

存储型 XSS 影响所有访问该页面的用户。风险等级：中到高。

五、防御方法

1. 输出编码

按上下文进行输出编码，是 XSS 防御的核心。

2. 输入校验

输入校验可以减少风险，但不应作为唯一防线。它更多是业务层保护。

3. 安全的 DOM API

避免直接写入 HTML，优先使用文本安全 API。

4. CSP

内容安全策略（CSP）可以限制脚本来源，降低 XSS 影响。

给敏感 Cookie 设置：

1
2
3


HttpOnly
Secure
SameSite

即使脚本执行，也不要让它轻易拿到 Cookie。

6. 最小权限和最小暴露

后台、评论、个人资料、富文本编辑器都要做专门审查。

修复

1
2
3
4
5


输出编码（上下文敏感：HTML/属性/JS 分别编码）
输入白名单校验
设置 CSP 降低执行面
HttpOnly 防 Cookie 被窃取
修复后复测：注入 payload 不再被执行

六、XSS 在报告中的正确写法

好的报告要写出触发条件、影响和建议。

示例：

1
2
3


发现：评论区输入 <img src=x onerror="alert(1)"> 会在其他用户页面执行脚本。
风险：可能造成会话劫持、钓鱼、数据读取和页面篡改。
建议：输出编码；启用 CSP；限制富文本标签；敏感 Cookie 设置 HttpOnly、Secure、SameSite。

不要只写“存在 XSS”。要写清楚触发路径和影响。

七、小结

XSS 的核心不是“能不能注入标签”，而是“浏览器在哪个上下文执行了这段输入”。理解上下文，才能同时理解防御和绕过。后续学习 CSRF、SSRF、WAF 和日志分析时，都会回到 XSS 的上下文思维。

Cookie on SoulJian小站

Cookie 与 Session 入门

写在前面：合法学习边界

一、为什么 HTTP 需要“会话”

二、Cookie 是什么

三、Session 是什么

四、常见风险

1. 会话固定

2. 会话劫持

3. 会话过期管理不当

4. 并发登录与暴力破解

五、防御建议

六、报告中的正确写法

七、小结

XSS 原理与防御

写在前面：合法学习边界

一、XSS 的本质

二、XSS 的常见类型

1. 存储型 XSS

2. 反射型 XSS

3. DOM 型 XSS

三、为什么“编码”是关键

四、常见危险点

1. innerHTML

2. document.write

3. 事件属性

4. URL 跳转

影响与危害

五、防御方法

1. 输出编码

2. 输入校验

3. 安全的 DOM API

4. CSP

5. Cookie 保护

6. 最小权限和最小暴露

修复

六、XSS 在报告中的正确写法

七、小结