killvxk 执行 Web 应用程序渗透测试
使用场景
- 在生产部署前测试 Web 应用程序，识别可利用漏洞
- 开展合规驱动的安全评估（PCI-DSS 要求 6.6、SOC 2 Type II）
- 在重新测试期间验证之前识别的 Web 应用漏洞的修复情况
- 在将第三方 Web 应用集成到组织环境之前对其进行评估
- 评估仅凭自动化扫描不足的自定义开发 Web 应用程序
不适用场景：未获书面授权擅自测试 Web 应用程序、在高峰流量期间未经明确批准测试生产系统，或对 Web 基础设施进行拒绝服务测试。
前置条件
- 已签署的工作说明书（SoW），定义目标应用 URL、环境（预发布/生产）和测试边界
- 安装了最新扩展（Active Scan++、Autorize、JSON Beautifier、Logger++）的 Burp Suite Professional 授权
- 每个权限级别的有效测试账户（未认证、标准用户、管理员），用于授权测试
- 应用程序文档，包括 API 规范（OpenAPI/Swagger）、站点地图和技术栈详情
- 配置了 Burp Suite 代理（推荐 FoxyProxy）并安装了 Burp CA 证书的浏览器
工作流程
步骤一：侦察与应用程序映射
映射 Web 应用程序的整个攻击面：
- 配置 Burp Suite 代理，手动浏览每个页面、表单和功能，同时 Burp 捕获站点地图
- 使用 Burp 的"发现内容"功能查找未从可见应用链接的隐藏目录和文件
- 从响应标头（
X-Powered-By、Server）、Cookie（JSESSIONID = Java，PHPSESSID = PHP，ASP.NET_SessionId = .NET）和页面扩展名识别技术栈 - 使用
ffuf枚举端点：ffuf -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u https://target.com/FUZZ -mc 200,301,302,403 - 使用 Burp 的 JS Link Finder 扩展或
LinkFinder.py审查 JavaScript 文件，查找硬编码 API 端点、密钥和客户端路由 - 记录所有入口点：URL 参数、POST 请求体、HTTP 标头、Cookie、文件上传和 WebSocket 连接
步骤二：认证测试
测试认证机制的弱点：
- 凭据枚举：提交有效和无效用户名，识别响应差异（时序、消息、HTTP 状态），这些差异会泄露有效账户
- 暴力破解保护：尝试 10-20 次快速登录失败，验证账户锁定和速率限制是否被执行
- 密码策略：使用弱密码（123456、password、单字符）测试密码创建，验证策略执行
- 多因素认证绕过：通过直接访问认证后页面、操控 MFA 令牌或重放成功的 MFA 响应来测试 MFA 绕过
- 会话固定：记录认证前后的会话令牌。若登录后令牌不变，则存在会话固定漏洞
- "记住我"功能：检查持久化认证令牌的可预测性、加密和正确过期时间
- 密码重置：测试密码重置流程的令牌可预测性、令牌过期、通过重置表单枚举账户和主机头注入
步骤三：授权测试
验证访问控制是否正确执行：
- 水平权限提升（IDOR）：使用账户 A 捕获访问 A 资源的请求，将请求中账户 A 的标识符（用户 ID、订单号、文件名）替换为账户 B 的标识符进行重放。使用 Burp 的 Autorize 扩展在所有端点自动化此过程
- 垂直权限提升：使用低权限账户，尝试通过直接浏览管理 URL、修改请求中的角色参数或操控 JWT 声明来访问管理功能
- 强制浏览：通过直接请求映射阶段收集的内部 URL 来访问应需要认证的资源
- HTTP 方法篡改：若 GET 在某端点被阻止，尝试 PUT、POST、DELETE、PATCH，或使用方法覆盖标头（
X-HTTP-Method-Override: DELETE） - 授权中的路径遍历：测试 URL 路径操控（
/api/users/123/../456/profile）以绕过基于路径的授权检查
步骤四：输入验证与注入测试
测试所有输入点的注入漏洞：
- SQL 注入：在每个参数中插入载荷，如
' OR 1=1--、' UNION SELECT NULL,NULL--和时间盲注载荷（'; WAITFOR DELAY '0:0:5'--）。对已确认的注入点使用 sqlmap 进行自动化检测和利用 - 跨站脚本（XSS）：使用
<script>alert(document.domain)</script>、"><img src=x> 和事件处理器等载荷测试反射型、存储型和 DOM 型 XSS。在所有上下文中测试：HTML 正文、属性、JavaScript 和 URL - 服务器端请求伪造（SSRF）：在获取外部资源的参数（Webhook、图片 URL、导入功能）中提供内部 URL（
http://169.254.169.254/latest/meta-data/、http://127.0.0.1:6379/） - 命令注入：在服务器处理的参数中插入操作系统命令分隔符（
;、|、&&、`）后跟命令（id、whoami、ping -c 3 collaborator.net） - XML 外部实体（XXE）：在 XML 上传或 API 端点中提交带外部实体声明的 XML 载荷（
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>） - 服务器端模板注入（SSTI）：在模板引擎渲染的参数中测试
{{7*7}}、${7*7}、<%= 7*7 %>
步骤五：会话管理测试
评估会话处理的安全性：
- 会话令牌分析：收集 100 个以上的会话令牌，使用 Burp Sequencer 分析随机性。检查令牌长度（最少 128 位熵）、字符集和可预测性
- 会话过期：验证会话在定义的空闲超时和绝对超时后是否过期。通过捕获会话令牌，等待超过超时时间，然后重放来测试
- Cookie 安全标志：验证会话 Cookie 是否设置了
Secure、HttpOnly和SameSite标志。缺少HttpOnly会导致基于 XSS 的会话窃取；缺少SameSite会导致 CSRF - CSRF 测试：识别状态变更操作（密码更改、邮箱更新、资金转账），测试是否可以在没有有效 CSRF 令牌的情况下从跨域页面触发
- 并发会话处理：测试应用是否限制并发会话数量，以及从新位置登录是否会使之前的会话失效
步骤六：业务逻辑测试
测试自动化扫描器无法检测到的应用特定逻辑缺陷：
- 竞态条件：使用 Burp Turbo Intruder 同时发送多个请求，利用检查时间到使用时间（TOCTOU）漏洞（双重消费、优惠券重用、多次投票）
- 工作流绕过：通过直接请求后期端点，尝试跳过多步骤流程（结账、注册、审批）中的步骤
- 数值操控：将价格、数量或金额修改为负值、零或极大数字，测试整数溢出或逻辑错误
- 文件上传绕过：通过修改 MIME 类型、双扩展名（file.php.jpg）、空字节（file.php%00.jpg）和 Content-Type 操控来测试文件上传限制
步骤七：报告与修复指导
将所有发现汇编成结构化报告：
- 撰写执行摘要，以业务术语描述整体应用安全态势
- 为每个发现记录标题、严重性（CVSS 3.1）、受影响的 URL/参数、描述、重现步骤、截图以及来自 Burp 的 HTTP 请求/响应对
- 为每个发现提供具体的修复指导，包括适用时的代码级修复
- 包含展示各严重性级别发现分布的风险矩阵
- 安全传递报告（加密，非邮件附件）并安排与开发团队的发现讲解会议
核心概念
| 术语 | 定义 |
|---|---|
| OWASP WSTG | Web 安全测试指南；按测试类别（认证、授权、输入验证等）组织的全面开源 Web 应用安全测试指南 |
| IDOR | 不安全直接对象引用；应用程序暴露内部对象标识符且未验证请求用户是否有权访问该对象的漏洞 |
| CSRF | 跨站请求伪造；强制已认证用户的浏览器向存在漏洞的 Web 应用发送伪造请求的攻击 |
| 会话固定 | 攻击者在用户认证前将其会话 ID 设置为已知值，然后在登录后劫持会话的攻击 |
| 强制浏览 | 通过直接请求不从可见应用链接的 URL 来访问应用资源，绕过预期访问控制的技术 |
| SSTI | 服务器端模板注入；将模板指令注入服务器端模板引擎以实现远程代码执行 |
工具与系统
- Burp Suite Professional：主要 Web 应用测试代理，提供拦截、扫描和手动测试工具，包括 Repeater、Intruder 和 Sequencer
- ffuf：快速 Web 模糊测试器，用于目录/文件发现、参数模糊测试和虚拟主机枚举
- sqlmap：自动化 SQL 注入检测和利用工具，支持所有主要数据库引擎和注入技术
- Nuclei：基于模板的漏洞扫描器，具有社区维护的已知 CVE 和错误配置模板
- SecLists：用于模糊测试、凭据测试和载荷投递的精选词表集合，贯穿整个 Web 应用测试过程
常见场景
场景：电子商务应用上线前安全评估
背景：一家零售公司正在推出基于 Node.js 和 React 前端、PostgreSQL 数据库构建的新电子商务平台。应用通过 Stripe 集成处理信用卡支付并存储客户 PII。测试范围包括具有完整 API 访问权限的预发布环境。
方法：
- 通过手动浏览和 API 文档审查映射应用程序，识别 47 个唯一端点
- 测试认证流程，包括社交登录（OAuth）、标准登录和密码重置
- 在订单获取 API（
/api/orders/{orderId}）中发现 IDOR 漏洞，任何已认证用户可通过遍历订单 ID 查看任意订单 - 在产品评论功能中发现存储型 XSS，管理员查看后台时会执行
- 在产品图片导入功能中发现 SSRF，可读取 AWS EC2 实例元数据
- 在结账提交前通过操控客户端购物车中的价格值来测试支付逻辑
- 报告所有发现，附带具体的 Node.js 代码级修复（参数化查询、使用 DOMPurify 净化输入、授权中间件）
常见陷阱：
- 仅测试前端，忽略缺乏独立授权检查的 API 层
- 仅依赖自动化扫描而不进行手动测试，遗漏业务逻辑缺陷
- 未跨不同权限级别测试相同功能，遗漏授权问题
- 忽视客户端 JavaScript 中的硬编码 API 密钥、调试端点和内部 URL
输出格式
## 发现：订单 API 中的不安全直接对象引用
**ID**: WEB-003
**严重性**: 高危（CVSS 7.5）
**受影响 URL**: GET /api/v1/orders/{orderId}
**参数**: orderId（路径参数）
**描述**:
订单获取端点未验证已认证用户是否拥有所请求的订单。任何已认证用户
均可通过递增路径参数中的 orderId，访问包含客户姓名、收货地址、邮箱、
电话号码和订单项目的任意订单详情。
**重现步骤**:
1. 以用户 A（testuser@example.com）身份认证
2. 记录用户 A 的订单 ID：10451
3. 使用用户 A 的会话令牌发送 GET /api/v1/orders/10452
4. 观察到返回了用户 B 的订单详情，包含完整 PII
**HTTP 请求**:
GET /api/v1/orders/10452 HTTP/1.1
Host: staging.example.com
Authorization: Bearer eyJhbGc....[用户 A 的令牌]
**HTTP 响应**（截断）:
HTTP/1.1 200 OK
{"orderId":10452,"customerName":"Jane Smith","email":"jane@...","address":"123 Main St"}
**影响**:
攻击者可枚举所有客户订单，提取约 25,000 名客户的 PII（姓名、邮箱、
地址、电话号码）。
**修复建议**:
添加授权中间件，在返回订单数据前验证已认证用户的 ID 与订单的 userId 字段是否匹配。
使用 UUID 代替顺序整数作为订单标识符，防止枚举。