performing-web-application-penetration-test

执行 Web 应用程序渗透测试

何时使用

• 在生产部署前测试 Web 应用程序，以识别可利用的漏洞
• 开展合规驱动的安全评估（PCI-DSS 要求 6.6、SOC 2 Type II）
• 在复测期间验证此前已识别的 Web 应用程序漏洞的修复情况
• 在将第三方 Web 应用程序集成到组织环境之前对其进行评估
• 评估仅靠自动化扫描不足以覆盖的自研 Web 应用程序

请勿在未获得书面授权的情况下对 Web 应用程序使用，未经明确批准在流量高峰时段对生产系统使用，或用于对 Web 基础设施进行拒绝服务测试。

前置条件

• 已签署的工作说明书（SoW），明确目标应用程序 URL、环境（预发布/生产）和测试边界
• Burp Suite Professional 许可证及最新扩展（Active Scan++、Autorize、JSON Beautifier、Logger++）
• 每个权限级别（未认证、标准用户、管理员）的有效测试账户，用于授权测试
• 应用程序文档，包括 API 规范（OpenAPI/Swagger）、站点地图和技术栈详细信息
• 已配置 Burp Suite 代理（推荐 FoxyProxy）并安装 Burp CA 证书的浏览器

工作流

步骤 1：信息收集与应用程序测绘

测绘 Web 应用程序的整个攻击面：

• 配置 Burp Suite 代理，并通过手动浏览每个页面、表单和功能对应用程序进行爬取，同时 Burp 捕获站点地图
• 使用 Burp 的 Discover Content 功能查找未从可见应用程序链接的隐藏目录和文件
• 从响应头（X-Powered-By、Server）、Cookie（JSESSIONID = Java、PHPSESSID = PHP、ASP.NET_SessionId = .NET）和页面扩展名识别技术栈
• 使用 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 连接

步骤 2：身份验证测试

测试身份验证机制的弱点：

• 凭据枚举：提交有效和无效的用户名，以识别响应中的差异（时间、消息、HTTP 状态），从而揭示有效账户
• 暴力破解防护：使用无效凭据尝试 10-20 次快速登录，以验证是否实施了账户锁定和速率限制
• 密码策略：使用弱密码（123456、password、单个字符）测试密码创建，以验证策略是否强制执行
• 多因素身份验证绕过：通过直接访问认证后页面、操纵 MFA 令牌或重放成功的 MFA 响应来测试 MFA 绕过
• 会话固定：记录身份验证前后的会话令牌。如果登录后令牌未发生变化，则可能存在会话固定
• 记住我功能：检查持久身份验证令牌的可预测性、加密和适当的过期设置
• 密码重置：测试密码重置流程中的令牌可预测性、令牌过期、通过重置表单进行账户枚举以及 Host 头注入

第 3 步：授权测试

验证访问控制是否被正确执行：

• 水平权限提升（IDOR）：使用账户 A，捕获访问账户 A 资源的请求。重放这些请求，替换为账户 B 的标识符（用户 ID、订单号、文件名）。使用 Burp 的 Autorize 扩展在所有端点上自动化此过程。
• 垂直权限提升：使用低权限账户，尝试通过直接浏览管理 URL、修改请求中的角色参数或操纵 JWT 声明来访问管理功能
• 强制浏览：尝试通过直接访问在映射期间收集的内部 URL 来访问本应需要身份验证的资源
• HTTP 方法篡改：如果某个端点上的 GET 被阻止，请尝试 PUT、POST、DELETE、PATCH，或使用方法覆盖头（X-HTTP-Method-Override: DELETE）
• 授权中的路径遍历：测试 URL 路径操纵（/api/users/123/../456/profile）以绕过基于路径的授权检查

第 4 步：输入验证与注入测试

测试所有输入点的注入漏洞：

• SQL 注入：将 ' OR 1=1--、' UNION SELECT NULL,NULL-- 等 payload 以及基于时间的盲注 payload（'; WAITFOR DELAY '0:0:5'--）插入每个参数。使用 sqlmap 自动检测和利用已确认的注入点。
• 跨站脚本（XSS）：使用 <script>alert(document.domain)</script>、"><img src=x onerror=alert(1)> 和事件处理器等 payload 测试反射型、存储型和基于 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 payload（<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>）
• 服务端模板注入（SSTI）：在由模板引擎渲染的参数中使用 {{7*7}}、${7*7}、<%= 7*7 %> 进行测试

第 5 步：会话管理测试

评估会话处理的安全性：

• 会话令牌分析：收集 100 个以上会话令牌，并使用 Burp Sequencer 分析其随机性。检查令牌长度（至少 128 位熵）、字符集和可预测性。
• 会话过期：验证会话在定义的空闲超时和绝对超时后是否过期。通过捕获会话令牌、等待超过超时时间并重放来进行测试。
• Cookie 安全标志：验证会话 Cookie 上是否设置了 Secure、HttpOnly 和 SameSite 标志。缺少 HttpOnly 会导致基于 XSS 的会话窃取。缺少 SameSite 会导致 CSRF。
• CSRF 测试：识别改变状态的操作（更改密码、更新邮箱、转账），并测试是否可以在没有有效 CSRF 令牌的情况下从跨源页面触发这些操作
• 并发会话处理：测试应用是否限制并发会话数量，以及从新位置登录是否会使先前的会话失效

第 6 步：业务逻辑测试

测试自动化扫描器无法检测的应用特定逻辑缺陷：

• 竞态条件：使用 Burp Turbo Intruder 发送多个同时请求，利用检查时到使用时（TOCTOU）漏洞（双重消费、优惠券重复使用、多次投票）
• 工作流绕过：尝试通过直接请求后续阶段的端点，跳过多步骤流程（结账、注册、审批）中的步骤
• 数值操纵：将价格、数量或金额修改为负值、零或极大数值，以测试整数溢出或逻辑错误
• 文件上传绕过：通过修改 MIME 类型、双扩展名（file.php.jpg）、空字节（file.php%00.jpg）和 content-type 操纵来测试文件上传限制

第 7 步：报告与修复指导

将所有发现汇总为结构化报告：

• 用业务术语撰写执行摘要，描述应用的整体安全状况
• 记录每个发现，包括标题、严重性（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 访问权限的预发布环境。

方法：

1. 通过手动浏览和审阅 API 文档来梳理应用，识别出 47 个唯一端点
2. 测试身份验证流程，包括社交登录（OAuth）、标准登录和密码重置
3. 在订单检索 API（/api/orders/{orderId}）中发现 IDOR 漏洞，任何已认证用户都可以通过遍历订单 ID 查看任意订单
4. 识别出商品评论功能中的存储型 XSS，该漏洞会在管理员查看管理后台时执行
5. 在商品图片导入功能中发现 SSRF，可允许读取 AWS EC2 实例元数据
6. 通过在下单提交前篡改客户端购物车中的价格值来测试支付逻辑
7. 报告所有发现，并提供具体的 Node.js 代码级修复建议（参数化查询、使用 DOMPurify 进行输入清理、授权中间件）

陷阱：

• 只测试前端，却忽略了缺乏独立授权检查的 API 层
• 仅依赖自动化扫描而不进行手动测试，从而遗漏业务逻辑缺陷
• 未在不同权限级别下测试同一功能，因而无法发现授权问题
• 忽略客户端 JavaScript 中硬编码的 API 密钥、调试端点和内部 URL

输出格式

## Finding: Insecure Direct Object Reference in Order API

**ID**: WEB-003
**Severity**: High (CVSS 7.5)
**Affected URL**: GET /api/v1/orders/{orderId}
**Parameter**: orderId (path parameter)

**Description**:
The order retrieval endpoint does not verify that the authenticated user owns
the requested order. Any authenticated user can access any order's details
including customer name, shipping address, email, phone number, and order
items by incrementing the orderId path parameter.

**Reproduction Steps**:
1. Authenticate as user A ([email protected])
2. Note user A's order ID: 10451
3. Send GET /api/v1/orders/10452 with user A's session token
4. Observe that user B's order details are returned with full PII

**HTTP Request**:
GET /api/v1/orders/10452 HTTP/1.1
Host: staging.example.com
Authorization: Bearer eyJhbGc....[User A's token]

**HTTP Response** (truncated):
HTTP/1.1 200 OK
{"orderId":10452,"customerName":"Jane Smith","email":"jane@...","address":"123 Main St"}

**Impact**:
An attacker can enumerate all customer orders and extract PII (names, emails,
addresses, phone numbers) for an estimated 25,000 customers.

**Remediation**:
Add authorization middleware that verifies the authenticated user's ID matches
the order's userId field before returning order data. Implement UUIDs instead
of sequential integers for order identifiers to prevent enumeration.