shenyan~
shenyan~

关于 Web安全：1. Web 安全基础知识

一、HTTP/HTTPS 协议详解

1. HTTP协议基础

什么是 HTTP？

HTTP（HyperText Transfer Protocol）是互联网中浏览器和服务器之间传输数据的协议，基于请求-响应模式。它是一个无状态协议，意思是每次请求都是独立的，服务器不会记住之前的请求状态。

HTTP 工作模式

  • 客户端（浏览器、爬虫等）发起请求

  • 服务器接收请求，处理后返回响应

  • 双方通过TCP连接（通常是80端口）进行通信

2. HTTP 请求结构

HTTP 请求由四部分组成：

请求行（Request Line）
请求头（Request Headers）
空行
请求体（Request Body，可选）

1）请求行

格式：

METHOD URL HTTP/VERSION

  • METHOD：请求方法，如 GET、POST、PUT、DELETE 等

  • URL：请求的资源路径和参数

  • HTTP/VERSION：HTTP版本，如 HTTP/1.1

示例：

GET /index.html HTTP/1.1

2）请求头

键值对格式，告知服务器客户端信息：

  • Host: 必须，目标服务器域名和端口

  • User-Agent: 客户端软件信息

  • Accept: 可接受的数据格式

  • Cookie: 浏览器存储的Cookie信息

  • Content-Type: 请求体类型（POST/PUT）

  • Content-Length: 请求体大小（字节）

示例：

Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
Cookie: sessionid=abc123

3）空行

请求头和请求体之间必须有一个空行。

4）请求体

  • 只有部分请求方法（如POST、PUT）有请求体

  • 通常携带提交的数据，如表单、JSON、文件等

3. HTTP 响应结构

HTTP 响应由四部分组成：

状态行（Status Line）
响应头（Response Headers）
空行
响应体（Response Body）

1）状态行

格式：

HTTP/VERSION STATUS_CODE REASON_PHRASE

  • STATUS_CODE：三位数字，表示请求状态

  • REASON_PHRASE：简短描述状态码

示例：

HTTP/1.1 200 OK

2）响应头

描述响应的元数据：

  • Content-Type: 响应体格式和编码

  • Content-Length: 响应体大小

  • Set-Cookie: 设置Cookie

  • Cache-Control: 缓存策略

  • Server: 服务器信息

示例：

Content-Type: text/html; charset=UTF-8
Content-Length: 1024
Set-Cookie: sessionid=abc123; HttpOnly
Cache-Control: no-cache

3）空行

响应头和响应体之间必须有空行。

4）响应体

服务器返回的实际数据，比如HTML页面、JSON、图片等。

4. HTTP 状态码详解

状态码反映服务器对请求的处理结果，按首位数字分类：

类别 代码范围 描述 说明
1xx 100-199 信息性状态码 请求已接收，继续处理
2xx 200-299 成功 请求成功完成
3xx 300-399 重定向 需要客户端进一步操作，如跳转
4xx 400-499 客户端错误 请求有错误，如参数不合法、未授权等
5xx 500-599 服务器错误 服务器处理请求时发生错误

常见状态码示例

状态码 含义
200 OK — 请求成功
201 Created — 资源成功创建
301 Moved Permanently — 永久重定向
302 Found — 临时重定向
304 Not Modified — 资源未修改，使用缓存
400 Bad Request — 请求格式错误
401 Unauthorized — 未认证
403 Forbidden — 禁止访问
404 Not Found — 资源未找到
500 Internal Server Error — 服务器错误
503 Service Unavailable — 服务不可用

5. HTTP工作流程

  1. 客户端发起 TCP 连接，通常连接到服务器的 80 端口

  2. 发送 HTTP 请求

  3. 服务器处理请求并返回 HTTP 响应

  4. 客户端解析响应，根据响应状态执行后续操作

  5. 根据 Connection 头是否为 keep-alive 决定是否关闭连接

6. HTTPS协议详解

HTTPS 是什么？

HTTPS 是在 HTTP 之上增加了 SSL/TLS 加密层的安全协议，主要解决 HTTP 明文传输导致的信息泄露和篡改问题。

HTTPS 端口

默认端口是 443。

HTTPS 工作流程（简化版）

  1. 客户端发起 HTTPS 连接请求

  2. 服务器返回数字证书（包含公钥）

  3. 客户端验证证书（是否由可信CA签发、是否过期、域名是否匹配）

  4. 客户端生成对称密钥，用服务器公钥加密后发给服务器

  5. 服务器用私钥解密得到对称密钥

  6. 双方使用对称密钥加密通信数据

HTTPS 特点

  • 加密通信：保护数据不被窃听

  • 身份认证：防止伪造服务器

  • 数据完整性：防止数据被篡改

  • 防止中间人攻击

总结

内容 说明
HTTP 请求 请求行 + 请求头 + 空行 + 请求体（可选）
HTTP 响应 状态行 + 响应头 + 空行 + 响应体
状态码 1xx信息，2xx成功，3xx重定向，4xx客户端错，5xx服务器错
HTTPS HTTP + SSL/TLS加密
HTTPS 工作流程 证书交换、密钥协商、加密通信

二、Cookie 详解

Cookie 是服务器通过 HTTP 响应头 Set-Cookie 向客户端（浏览器）写入的一段小型数据，浏览器会在下一次请求时自动将它附带在请求头 Cookie 中发送给服务器，用于状态保持。

Cookie 具有以下特性：

  • 每个 Cookie 大小不超过 4KB

  • 同一域名下最多存储 20 个 Cookie（浏览器不同略有差异）

  • 自动附带到相同域名的每次请求中

1. Cookie 的基本结构

Set-Cookie 响应头格式：

Set-Cookie: name=value; Path=/; Expires=Wed, 01 Jan 2025 00:00:00 GMT; HttpOnly; Secure; SameSite=Strict

常见属性详解：

属性 说明
name=value 键值对数据
Expires 过期时间（绝对时间）
Max-Age 存活时间（秒，优先于 Expires）
Path 限制在哪些路径下 Cookie 会被发送
Domain 可跨子域访问的设置，如 .example.com
Secure 仅在 HTTPS 连接下才发送
HttpOnly JS 不能访问，防止 XSS 盗取
SameSite 控制跨站请求时是否发送（Strict / Lax / None）

2. Cookie 的作用

状态保持（Session 管理）

  • 登录状态：如 sessionid=abc123

  • 用户偏好：如 lang=zh-CN

  • 购物车：记录加入商品的 ID

追踪用户行为

  • 统计页面访问、点击行为

  • 第三方广告 Cookie（如 Google Analytics）

3. Cookie 生命周期

会话 Cookie（Session Cookie）

  • 不设置 Expires 或 Max-Age

  • 浏览器关闭后自动失效

持久 Cookie（Persistent Cookie）

  • 设置了 Expires 或 Max-Age

  • 即使关闭浏览器，指定时间内依然有效

4. Cookie 的安全问题

1）XSS 攻击（跨站脚本）盗取 Cookie

攻击者通过注入恶意 JS 代码，调用 document.cookie 读取用户 Cookie 并发送给远程服务器。

防御：

  • 设置 HttpOnly，防止 JS 访问 Cookie

  • 对用户输入进行严格过滤或转义

2）CSRF 攻击（跨站请求伪造）

利用用户浏览器已存的 Cookie 向目标网站发起伪造请求，如提交表单、转账等。

防御：

  • 设置 SameSite=Strict 或 Lax

  • 使用 CSRF Token 验证来源合法性

3）Cookie 劫持

如果用户在 HTTP 下传输 Cookie，攻击者可以使用中间人攻击（MITM）截获 Cookie。

防御：

  • 设置 Secure 属性，只允许 HTTPS 传输

  • 使用 HTTPS 加密所有通信

4）Cookie 固定攻击（Session Fixation）

攻击者提前设置用户 Cookie，诱导用户使用该 Cookie 登录，从而复用 Session。

防御：

  • 登录成功后重新生成 Cookie / Session ID

  • 拒绝来源不明的 Session Cookie

5. Cookie 示例（请求 + 响应）

服务端响应设置 Cookie：

HTTP/1.1 200 OK
Set-Cookie: sessionid=abc123; HttpOnly; Secure; SameSite=Strict

浏览器下一次请求自动携带 Cookie：

GET /user/profile HTTP/1.1
Host: example.com
Cookie: sessionid=abc123

6. Cookie 与浏览器 JS 操作

// 读取
console.log(document.cookie); // name=value; another=123

// 设置
document.cookie = "token=xyz456; path=/; max-age=3600";

// 删除（设置过期）
document.cookie = "token=; expires=Thu, 01 Jan 1970 00:00:00 GMT";

注意：如果设置了 HttpOnly，JavaScript 是无法访问该 Cookie 的。

7. Cookie 与跨域

Cookie 默认 不跨域，但有策略支持：

  • 前提是设置了 Access-Control-Allow-Credentials: true

  • 客户端请求必须使用 withCredentials: true

  • Cookie 的 Domain 设置为顶级域名（如 .example.com）

总结

属性 用途 是否可防攻击
HttpOnly 禁止 JS 访问 防止 XSS
Secure 只在 HTTPS 传输 防止 MITM
SameSite 跨站请求限制 防止 CSRF
Expires 控制 Cookie 失效时间 控制生命周期
Domain 控制子域可访问 易被滥用，小心设置

三、Session详解

Session 是服务器端用于 记录客户端状态 的一种机制。它解决了 HTTP 协议无状态的问题（服务器无法记住每个用户是谁）。

客户端登录后，服务器生成一个 Session ID，用于标识当前会话，并将它保存在服务端，同时通过 Cookie 发给客户端。客户端每次请求时携带这个 Session ID，服务器就能识别该用户是谁。

1. Session 的工作流程

[客户端] —— 登录请求 ——> [服务端]
                     <—— Set-Cookie: sessionid=abc123 —— 

[客户端] —— 后续请求（带 Cookie） ——> [服务端]
                         查找 sessionid=abc123 对应的用户状态

示例流程：

  1. 用户第一次访问网站，服务端创建一个新的 Session，生成一个唯一的 sessionid

  2. 服务器通过 Set-Cookie 把 sessionid 设置到客户端浏览器中

  3. 之后客户端请求中都会自动携带 Cookie: sessionid=xxx

  4. 服务端根据 sessionid 在内存/数据库中查找用户的会话信息（如登录状态、用户名等）

2. Session 与 Cookie 的区别

项目 Cookie Session
存储位置 客户端浏览器 服务端内存、数据库、Redis 等
安全性 较低，易被盗用 较高，不暴露用户数据，仅暴露 ID
容量限制 每个 Cookie 最大约 4KB 较大，可存储任意复杂结构
生命周期 设置 Expires/Max-Age 控制 通常存在内存中，浏览器关闭或过期失效
易用性 无需服务器端资源 需要服务器维护 Session 状态

3. Session 存储机制

Session 本质是一个 Key-Value 结构：

  • Key 是 sessionid（保存在客户端 Cookie 中）

  • Value 是服务端保存的用户状态信息（保存在服务器）

Session 数据的存储方式常见如下：

存储方式 特点
内存（默认） 简单、速度快，重启丢失，不可扩展
文件 存在磁盘，可持久，速度较慢
数据库 可持久、易管理，性能中等
Redis 高性能分布式，适合高并发场景

4. Session 生命周期

  • 默认有效期：浏览器关闭时失效，或服务端设定超时时间（如 30 分钟）

  • 设置方式（以 PHP 为例）：

ini_set('session.gc_maxlifetime', 3600); // 设置有效期 1 小时
session_start();

5. Session 安全问题与攻击方式

1）Session Fixation（固定会话攻击）

攻击者诱导用户使用事先构造的 sessionid，然后服务器将其绑定为合法 Session。

举例：

http://example.com/login?PHPSESSID=abc123

用户点击后登录，攻击者就可以使用相同 Session ID 登录。

防御：

  • 登录成功后强制重新生成 Session ID

  • 拒绝 URL 中传递 Session ID（禁止 SID）

  • 设置 HttpOnly，禁用 JS 操作 Cookie

2）Session Hijacking（劫持）

攻击者通过 XSS、流量嗅探、恶意扩展等手段获取用户的 sessionid，然后伪造请求。

防御：

  • 使用 Secure + HttpOnly 属性保护 Cookie

  • 全站强制 HTTPS，防止中间人窃取

  • Session ID 绑定用户 UA/IP，防止伪造

3）会话过期攻击

用户长时间不操作，Session 被销毁，攻击者在这个时间发起请求。

防御：

  • 设置合理的 Session 过期时间

  • 登录前置验证 + Session 管理机制

6. 常见 Session 实现方式

PHP

session_start(); // 启动 Session
$_SESSION['user'] = 'admin';

Cookie 自动设置：

Set-Cookie: PHPSESSID=abc123; path=/; HttpOnly

Python Flask

from flask import session
session['user'] = 'admin'

默认使用 Cookie 存储（可配置为 Redis 等）

Java Servlet

HttpSession session = request.getSession();
session.setAttribute("user", "admin");

默认使用 JSESSIONID 来标识会话

Set-Cookie: JSESSIONID=abc123; Path=/; HttpOnly

7. Session 的高级安全控制

1）Session ID 强度

  • 应该使用高熵的随机值生成（如 UUID、SHA256 随机串）

  • 不要使用简单自增或可预测字符串

2）Session ID 绑定策略

绑定到以下信息可防止伪造：

  • User-Agent（浏览器指纹）

  • IP 地址（不建议绑定完整 IP，可绑定前几段）

8. Session 与 Token 的区别

项目 Session Token（如 JWT）
存储 服务端 客户端本地
状态 有状态（服务端维护会话） 无状态（不需要存储）
性能 占用内存，扩展差 适合分布式，多终端场景
安全性 受控于服务端，泄漏风险低 需要加密签名验证，防止伪造

总结

核心要素 内容
Session 本质 用于服务端保存用户状态，配合 Cookie 识别身份
Cookie 作用 存储 sessionid，标识用户是谁
安全关键点 HttpOnly、Secure、SameSite、重新生成 ID、防 Fixation
攻击方式 Fixation、Hijacking、XSS、CSRF
防御方法 绑定信息、使用 HTTPS、短期有效期、验证来源

四、Token详解

Token（令牌）是一种服务端生成的字符串，用于客户端访问受保护资源时 标识身份 的认证机制。

Token 是为了解决传统 Session 需要在服务器维护用户状态的问题（即“有状态认证”），而引入的 无状态认证方式，广泛用于：

  • Web 前后端分离项目

  • 移动端、APP 登录认证

  • 分布式认证（单点登录）

1. Token 的工作流程（认证机制）

[客户端] —— 登录 ——> [服务端]
                    <—— 返回 Token —— 

[客户端] —— 后续请求（携带 Token） ——> [服务端]
                      验证 Token 合法性，返回数据

常见传输方式：

请求头方式（推荐）：

Authorization: Bearer

URL 参数：

GET /api/user?token=abc123

请求体（POST JSON）中提交：

{ "token": "abc123" }

2. Token 的种类

1）自定义 Token（普通随机串）

  • 结构简单：如 abc123xyz456

  • 存在 Redis、数据库中，和 Session 类似

  • 每次请求服务器查一次数据库，验证合法性

2）JWT（JSON Web Token）

  • 无需数据库查找，使用签名校验即可

  • 常用于分布式认证、前后端分离系统

3. JWT 的结构

xxxxx.yyyyy.zzzzz

由三部分组成，每部分使用 Base64 编码：

部分 内容 示例
Header 令牌类型 + 签名算法 { "alg": "HS256", "typ": "JWT" }
Payload 载荷（用户信息） { "uid": 1001, "role": "admin" }
Signature 签名（防篡改） HMAC_SHA256(header + payload + 密钥)

举例：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. // Header
eyJ1aWQiOjEsInJvbGUiOiJhZG1pbiJ9.      // Payload
Abcdefghijklmnopqrstuvwxyz123456      // Signature

4. Token 与 Session 的区别

项目 Session Token（JWT）
存储方式 服务器内存、数据库 客户端本地（无状态）
标识机制 sessionid + 服务端状态记录 Token 自带用户信息 + 签名验证
性能 服务端需查状态，横向扩展差 不依赖服务端状态，易于分布式部署
安全性 不泄漏用户信息，服务端控制较强 用户信息直接暴露在 Payload 中
可控性 服务端可手动销毁、修改 一旦发出不可撤销，需设置过期时间

5. Token 的优点与缺点

 优点：

  • 无需服务端保存状态（节省资源）

  • 可跨服务、跨平台共享身份（如 SSO 单点登录）

  • 不依赖 Cookie，可用于移动端、App

缺点：

  • 无法主动失效（Token 发出后无法收回）

  • 信息容易泄漏（Payload 明文，需加密敏感字段）

  • 体积大于 Session ID，占带宽

6. Token 的存储方式

存储方式 说明
LocalStorage 持久性强，但易被 XSS 攻击
SessionStorage 浏览器关闭即清除，安全略高
Cookie 可配合 HttpOnly + Secure 提升安全

7. Token 的安全问题与攻击方式

1）Token 泄漏（XSS、日志暴露）

  • Token 通常保存在浏览器中，若存在 XSS 漏洞，攻击者可轻松获取

  • URL 中传递 Token 可能被日志、代理服务器记录

防御：

  • Token 不出现在 URL，推荐放在 Header

  • 存储 Token 时避免使用 localStorage（推荐 HttpOnly Cookie）

  • 前端防 XSS：严格 CSP + DOM 过滤

2）Token 伪造

  • 攻击者尝试伪造 JWT，绕过认证

防御：

  • 使用强加密算法（如 HMAC-SHA256）

  • 严格保管密钥，不应泄漏服务端密钥

3）Token 重放攻击（Replay）

  • 攻击者截获合法请求 Token 后，在有效期内重复使用

防御：

  • Token 设置短有效期（如 5 分钟）

  • 配合 一次性 Token / RefreshToken 机制

8. Token 与 Refresh Token 机制

由于 Token 不可撤销，推荐使用双 Token 机制：

类型 用途
Access Token 有效期短，用于请求接口
Refresh Token 有效期长，用于换取新 Token

流程：

[登录] ——> [发出 access_token + refresh_token]

[请求资源] ——> 附带 access_token
   |
   └──[过期]——> 用 refresh_token 换新的 access_token

9. 实战示例：使用 JWT 验证身份

前端请求：

POST /login
Content-Type: application/json

{
  "username": "admin",
  "password": "123456"
}

服务端返回：

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5c..."
}

后续请求附带：

GET /user/info
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5c...

服务端用密钥验证 Token 签名，读取其中的 Payload 信息，判断用户身份。

10. Token 示例分析（JWT 解码）

示例 JWT：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJ1aWQiOjEsInJvbGUiOiJhZG1pbiIsImV4cCI6MTY5ODQzMjAwMH0.
t7I8mVYuqxPhA5KXZMQzN2gUe9eWYmN2coHo5cVdE2g

解码 Payload 得到：

{
  "uid": 1,
  "role": "admin",
  "exp": 1698432000
}

说明用户 ID 为 1，角色为 admin，有效期截止时间为某个时间戳（可用 Python/JS 解码）。

总结

要素 内容说明
核心机制 客户端持有 Token，服务端验证签名，无需状态存储
推荐方案 使用 JWT + RefreshToken 实现安全、可扩展的认证机制
安全风险 XSS、Token 泄漏、伪造、重放攻击等
防御策略 HttpOnly Cookie / Token 加密 / 过期机制 / 加签验证
与 Session 区别 Token 是无状态的，适合分布式系统；Session 依赖服务端存储

五、JWT 的机制与攻击方式

JWT 全称 JSON Web Token，是一种 无状态的身份验证机制，主要用于前后端分离项目、移动端接口调用、单点登录（SSO）等。

它本质上是一个自包含的令牌，通过数字签名的方式防止篡改。

1. JWT 的结构（三段式）

格式如下：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOjEsInJvbGUiOiJhZG1pbiJ9.WfJ9oX7O1fFLjlR_pIRpZI...

由 Header.Payload.Signature 三部分组成，每部分使用 Base64 编码。

名称 内容类型 作用
Header 元数据（算法类型） 指定加密算法，如 HS256 / RS256
Payload 负载（用户信息） 包含用户身份、权限、过期时间等
Signature 签名（完整性验证） 防止篡改，验证 Token 是否有效

2. JWT 签名机制（核心）

签名生成公式如下（以 HMAC-SHA256 为例）：

Signature = HMAC-SHA256(
    base64url(Header) + "." + base64url(Payload),
    secret_key
)

这个签名可以保证：

  • 内容被篡改 → 签名校验失败

  • 客户端不能伪造 Token（不知道密钥）

3. JWT 的使用流程

[用户登录] → [生成 JWT] → 返回给前端
       ↓
[客户端] 持有 JWT 调用接口
       ↓
[服务器] 验证 JWT 的签名 → 读取 Payload → 允许访问

4. Payload 示例

{
  "uid": 123,
  "username": "admin",
  "role": "super_admin",
  "exp": 1710000000   // 过期时间，Unix 时间戳
}

注意：

  • Payload 不能加密，默认是明文

  • 不应放敏感数据（如密码、银行卡等）

5. JWT 攻击方式（黑客视角）

WT 是无状态的，一旦签发就无法撤销，如果存在配置问题或弱密钥，攻击者可以伪造/篡改 JWT。

常见攻击方式：

1）弱密钥爆破攻击（HS256）

  • 当服务端使用对称加密（如 HS256），如果密钥过于简单，如 123456，攻击者可以使用工具暴力爆破。

工具：

  • jwt-cracker

  • jwt_tool.py

jwt_tool.py  -C -d /path/to/weak_passwords.txt

防御：

  • 使用复杂不可预测的密钥（如 UUID + 高位随机）

  • 使用非对称加密（RS256）

2）算法混淆攻击（alg: none）

有些服务端对 JWT 的 alg 字段没有做校验，如果用户将其修改为 "alg": "none"，服务端就会跳过签名验证。

攻击方式：

篡改 Header 为：

{ "alg": "none", "typ": "JWT" }

删除签名部分，提交伪造 Token。

防御：

  • 拒绝 "alg": "none"，显式验证签名算法

  • 使用经过验证的 JWT 库

3）算法替换攻击（HS256 → RS256）

RS256 是非对称加密（公私钥），攻击者可以利用算法替换绕过验证。

攻击原理：

  • 服务端使用 RS256，但攻击者将 alg 改为 HS256，并用“公钥”代替“密钥”来签名

  • 如果服务端仍用公钥验证，会被成功验证签名

防御：

  • 固定签名算法，不允许前端指定 alg

  • 使用严格的验证库（如 PyJWT, jsonwebtoken）

4）Token 重放攻击

即攻击者截获某用户的合法 Token（通过 XSS、中间人攻击、URL 泄漏等方式），然后在有效期内重复使用。

防御：

  • 使用 HTTPS 加密传输

  • 设置短的有效期（exp）

  • 引入 Refresh Token + 滑动过期机制

  • 绑定 IP / UA 检查

5）JWT 泄漏攻击

泄漏途径：

  • Token 存在 URL 中，容易被浏览器缓存、中间件记录

  • Token 存储在 localStorage，容易被 XSS 拿到

防御：

  • 推荐使用 Cookie + HttpOnly + Secure 存储 JWT

  • 避免在 URL 中传递 Token

  • 启用 CSP、输入校验防 XSS

6. 渗透测试视角：JWT 检测点

在渗透测试/CTF 中，遇到 JWT 可以重点检查以下点：

检测点 说明
alg 是否为 none 是否能跳过签名验证
alg 能否替换为 HS256 能否使用公钥伪造签名
密钥是否可爆破 使用字典工具尝试爆破
payload 是否可控 是否能提权（role=admin）
过期时间是否有效 是否能修改 exp 绕过校验
是否绑定 IP / UA 是否可进行重放攻击

7. JWT 攻击实战：模拟提权攻击

1）抓取一段正常用户的 Token：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJ1c2VyIjoiZ3Vlc3QiLCJyb2xlIjoiZ3Vlc3QifQ.
ZV1HG9mU_kPvEZfukOVsfAz1-r4PHiZ93KAjtz07Gb0

2）解码 Payload 并修改角色字段为：

{ "user": "guest", "role": "admin" }

3）使用弱密钥爆破签名或尝试算法替换，重新生成 JWT。

4）用篡改后的 JWT 访问管理员接口，判断是否成功提权。

8. 防御最佳实践

措施 描述
固定签名算法 不允许前端通过 Header 控制 alg
不使用 none 算法 拒绝无签名 JWT
使用非对称加密（RS256） 避免密钥泄漏
设置 exp/iatt/nbf 等字段 控制有效期、拒绝过期 Token
配置短有效期 + Refresh机制 Access Token + Refresh Token 组合使用
使用 HttpOnly Cookie 防止 JS 获取 Token（抗 XSS）
输入过滤 + CSP 防 XSS 攻击

9. 推荐工具 & 测试框架

工具名 用途
jwt.io 在线 JWT 解码/编码
jwt_tool.py JWT 爆破、伪造、测试脚本工具
HackBar / Burp Suite 实战中修改 Token 提交重放
Postman 模拟 JWT 接口调用

六、同源策略（SOP）

同源策略（Same-Origin Policy） 是浏览器的一种安全机制，用于隔离不同网站之间的资源，防止恶意网站窃取用户敏感数据。

它最初是为了解决：

  • 网页中的 JavaScript 脚本不能访问其他域下的资源（防止 XSS、CSRF）

  • 保护用户的 Cookie、本地存储、DOM 数据不被第三方网站访问

1. 什么叫“同源”？

要完全同源，必须满足三个条件完全相同：

条件 说明 示例
协议 http vs https http:// ≠ https://
域名 www.example.com vs api.example.com 子域名也算不同源
端口 80 vs 8080 http://a.com:80 ≠ http://a.com:8080

例如：

http://a.com ≠ https://a.com
http://a.com ≠ http://b.com
http://a.com:80 ≠ http://a.com:81

2. SOP 的限制范围（默认禁止访问的内容）

浏览器会对不同源的请求或访问行为进行限制。以下是 SOP 默认禁止的操作：

操作 是否允许
JS 读取 iframe 中的 DOM（不同源）  不允许
JS 发起跨域 Ajax 请求  不允许
JS 访问其他源的 Cookie / localStorage  不允许
表单（form）提交跨域  允许（但无法读取响应）
图片（img）加载跨域资源  允许（只加载，无法操作）

3. SOP 的核心目标：防止跨站攻击

举例：A 网站打开 B 网站的 iframe，尝试通过 JS 读取用户信息

// 假设在 a.com 的页面中：
let content = document.getElementById('iframe').contentWindow.document;
console.log(content.cookie);  // 报错：同源策略阻止了访问

如果不限制，就会产生极大的安全隐患（如 CSRF、XSS 等）。

4. 开发中遇到的常见问题（实际限制表现）

场景 是否被 SOP 限制 说明
使用 fetch 发送跨域请求  被限制 需要服务端设置 CORS 头
JS 读取