web-app-security-audit

Web 应用安全审计

概述

一种基于 The Web Application Hacker's Handbook 的结构化渗透测试方法。通过 10 个连续阶段，引导你系统地识别正在开发或审查的任何 Web 应用中的漏洞。

适用场景

• 将 Web 应用部署到生产环境之前
• 添加身份验证、支付处理或面向用户的功能时
• 定期安全审查期间
• 集成第三方服务或 API 后
• 怀疑存在某类特定漏洞，但希望进行全面检查时

不适用场景

• 测试不属于你所有或未获授权测试的应用
• 替代对关键系统进行的专业渗透测试
• 网络层安全（本方法侧重应用层）

流程

按顺序逐一完成各个阶段。在每个阶段：

1. 询问有关具体应用的针对性问题
2. 阅读 cybersecurity/web-application-hackers-handbook/ 中相关章节的摘要，以获取详细指导
3. 提出并执行具体测试（源代码中的 grep 模式、curl 命令、Burp Suite 操作步骤、自动化脚本）
4. 按严重程度标记发现：CRITICAL / HIGH / MEDIUM / LOW / INFO
5. 总结发现，然后再进入下一阶段

如果应用不具备某个阶段相关的攻击面（例如没有文件上传功能），请说明情况并给出跳过理由。

digraph audit_phases {
  rankdir=TB;
  node [shape=box, style=rounded];

  p1 [label="Phase 1\nMap the Application"];
  p2 [label="Phase 2\nAnalyze the Application"];
  p3 [label="Phase 3\nClient-Side Controls"];
  p4 [label="Phase 4\nAuthentication"];
  p5 [label="Phase 5\nSession Management"];
  p6 [label="Phase 6\nAccess Controls"];
  p7 [label="Phase 7\nInjection Vulnerabilities"];
  p8 [label="Phase 8\nApplication Logic"];
  p9 [label="Phase 9\nApplication Server"];
  p10 [label="Phase 10\nReview & Report"];
  report [label="Security Audit\nReport", shape=note];

  p1 -> p2 -> p3 -> p4 -> p5 -> p6 -> p7 -> p8 -> p9 -> p10 -> report;
}

---

阶段 1：梳理应用

参考资料： cybersecurity/web-application-hackers-handbook/ch04-mapping-the-application.md

目标： 在开始测试之前，发现完整的攻击面。

要询问的问题：

• 应用采用什么技术栈？（框架、语言、数据库、托管方式）
• 所有路由/端点有哪些？（查看路由文件、API 定义、OpenAPI 规范）
• 是否存在管理面板、API 文档或调试端点？
• 集成了哪些第三方服务？

要运行的测试：

• 从源代码中枚举所有路由：

  # Express.js
  grep -rn "app\.\(get\|post\|put\|delete\|patch\)" --include="*.ts" --include="*.js"
  # Django
  grep -rn "path\|url(" --include="*.py" urls.py
  # Rails
  grep -rn "get\|post\|put\|delete\|patch\|resources\|resource" config/routes.rb
  # Next.js — check app/ and pages/ directory structure
  

• 检查是否存在暴露的文件：robots.txt、sitemap.xml、.env、.git/、package.json
• 在源代码中搜索硬编码的机密信息：

  grep -rni "password\|secret\|api_key\|token\|private_key" --include="*.ts" --include="*.js" --include="*.py" --include="*.env*"
  

• 检查 HTML/JS 注释中是否包含敏感信息
• 识别所有输入向量：URL 参数、POST 请求体、Cookie、标头、文件上传、WebSocket

交付内容： 完整的攻击面地图——路由、参数、技术、入口点。

---

阶段 2：分析应用

参考资料： cybersecurity/web-application-hackers-handbook/ch03-web-application-technologies.md

目标： 了解应用的功能，并识别高风险区域。

要询问的问题：

• 核心业务功能有哪些？（用户管理、支付、数据 CRUD、搜索、文件处理）
• 哪些功能会处理敏感数据？（PII、财务信息、凭据）
• 是否存在多步骤流程？（结账、注册、审批工作流）
• 有哪些用户角色？每种角色可以执行哪些操作？

测试优先级（按风险从高到低）：

1. 身份验证和凭据处理
2. 支付/金融交易处理
3. 文件上传功能
4. 管理界面
5. API 端点（其控制通常不如 Web UI 严格）
6. 搜索功能（经常成为注入攻击目标）
7. 用户间功能（存储型 XSS 攻击向量）
8. 数据导入/导出（注入、XXE）

交付内容： 功能地图，以及按风险优先级排列的关注区域。

---

第 3 阶段：测试客户端控件

参考： cybersecurity/web-application-hackers-handbook/ch05-bypassing-client-side-controls.md

目标： 验证服务器绝不信任客户端验证或状态。

要问的问题：

• 是否存在服务器依赖的隐藏表单字段？（价格、角色、用户 ID）
• 输入验证是否只在客户端执行？（JavaScript、HTML5 属性）
• 客户端是否传输了本应由服务器维护的状态数据？（购物车总额、折扣标志、权限级别）

要运行的测试：

• 搜索隐藏字段：

  grep -rn 'type="hidden"\|type=.hidden.' --include="*.html" --include="*.tsx" --include="*.jsx"
  

• 搜索仅在客户端执行的验证：

  grep -rn "maxlength\|pattern=\|required\b" --include="*.html" --include="*.tsx" --include="*.jsx"
  

• 检查服务器端验证是否与客户端验证一致：

  grep -rn "validate\|sanitize\|zod\|yup\|joi\|class-validator" --include="*.ts" --include="*.js" --include="*.py"
  

• 对每个表单，提交包含以下情况的请求：缺少必填字段、值超出 maxlength、值不符合模式、修改隐藏字段
• 通过修改请求体来测试价格／角色／权限篡改

发现模板：

[SEVERITY] Client-Side Control Bypass: [description]
  Affected: [endpoint/parameter]
  Test: [what you did]
  Result: [what happened]
  Impact: [what an attacker could achieve]
  Fix: [server-side validation recommendation]

---

第 4 阶段：测试身份验证

参考： cybersecurity/web-application-hackers-handbook/ch06-attacking-authentication.md

目标： 验证身份验证无法被绕过、暴力破解或滥用。

要运行的测试：

用户名枚举：

• 比较登录、注册和密码重置时，输入有效用户名与无效用户名的响应
• 检查响应正文、状态码、响应时间差异和响应长度
• 搜索不一致的错误消息：

  grep -rn "invalid.*username\|user.*not found\|no.*account\|incorrect.*password" --include="*.ts" --include="*.js" --include="*.py"
  

暴力破解防护：

• 检查是否有账户锁定、速率限制、CAPTCHA
• 搜索速率限制实现：

  grep -rn "rate.limit\|throttle\|brute\|lockout\|max.*attempts" --include="*.ts" --include="*.js" --include="*.py"
  

密码策略：

• 测试最小长度、复杂度要求、常见密码拦截
• 检查密码存储：

  grep -rn "bcrypt\|argon2\|scrypt\|pbkdf2\|sha256\|sha1\|md5\|plaintext" --include="*.ts" --include="*.js" --include="*.py"
  

• 如果密码以明文、MD5 或未加盐的 SHA1 存储，则标记为 CRITICAL

密码重置：

• 检查令牌的随机性、有效期和单次使用限制
• 检查重置令牌是否出现在 URL 中（可能记录在服务器日志和浏览器历史记录中）

多因素身份验证：

• 能否通过直接请求需身份验证的端点来跳过 MFA 步骤？
• 能否通过重放验证码或使用过期验证码绕过 MFA？

记住我：

• 解码记住我令牌（Base64、JWT）——其中是否包含用户信息？
• 更改密码后，令牌是否会失效？

---

第 5 阶段：测试会话管理

参考： cybersecurity/web-application-hackers-handbook/ch07-attacking-session-management.md

目标： 验证会话无法被劫持、固定或预测。

要运行的测试：

令牌生成：

• 收集多个会话令牌并检查是否存在规律（递增、基于时间戳、熵低）
• 解码令牌（Base64、JWT）——其中是否包含敏感数据？

  # For JWTs
  grep -rn "jwt\|jsonwebtoken\|jose" --include="*.ts" --include="*.js" --include="*.py"
  

Cookie 标志：

• 检查每个 Cookie 的以下属性：Secure、HttpOnly、SameSite、Domain、Path

  grep -rn "Set-Cookie\|cookie\|setCookie\|httpOnly\|secure\|sameSite" --include="*.ts" --include="*.js" --include="*.py"
  

• 如果会话 Cookie 缺少 HttpOnly，则标记为 HIGH（XSS 可窃取该 Cookie）
• 如果会话 Cookie 缺少 Secure，则标记为 HIGH（Cookie 会通过 HTTP 传输）
• 如果会话 Cookie 缺少 SameSite，则标记为 MEDIUM（存在 CSRF 攻击途径）

会话生命周期：

• 登录后令牌是否会变化？（若不变化，则可能存在会话固定）
• 注销时，会话是否在服务器端失效？（而不只是删除 Cookie）
• 是否设置了空闲超时和绝对超时？

CSRF 防护：

• 确定所有会更改状态的操作（POST/PUT/DELETE）
• 检查是否有防 CSRF 令牌：

  grep -rn "csrf\|xsrf\|_token\|csrfmiddleware" --include="*.ts" --include="*.js" --include="*.py" --include="*.html"
  

• 不带 CSRF 令牌时，更改状态的请求能否成功？

---

阶段 6：测试访问控制

参考： cybersecurity/web-application-hackers-handbook/ch08-attacking-access-controls.md

目标： 确认用户无法访问未经授权的数据或功能。

需要询问的问题：

• 有哪些用户角色？（管理员、用户、版主、API 使用者）
• 如何实施授权？（中间件、装饰器、内联检查）
• URL 或请求正文中是否包含可能被篡改的资源 ID？

要运行的测试：

IDOR（不安全的直接对象引用）：

• 找出所有包含资源 ID 的端点：

  grep -rn "/users/\|/orders/\|/documents/\|/api/.*/:id\|/api/.*/<.*>" --include="*.ts" --include="*.js" --include="*.py"
  

• 以用户 A 的身份，通过更改 ID 请求用户 B 的资源
• 如果成功，则为 CRITICAL

垂直权限提升：

• 以普通用户的身份直接请求管理员端点
• 检查是否在每个端点都实施了授权：

  grep -rn "isAdmin\|requireAdmin\|role.*admin\|authorize\|permission\|@Roles\|@RequiresRole" --include="*.ts" --include="*.js" --include="*.py"
  

• 检查是否有端点缺少授权中间件

水平权限提升：

• 修改请求中用于标识用户的参数（user_id、account_id、email）
• 检查服务器是否验证所请求的资源属于已通过身份验证的用户

多步骤流程控制：

• 对于多步骤流程（结账、审批），测试是否可以直接跳到后续步骤
• 测试是否可以按错误顺序执行步骤

---

阶段 7：测试注入漏洞

参考： cybersecurity/web-application-hackers-handbook/ch09-attacking-data-stores.md、ch10-attacking-back-end-components.md、ch12-attacking-users-xss.md

目标： 确认所有输入在每种上下文中都得到安全处理。

SQL 注入：

# Find raw query construction (CRITICAL pattern)
grep -rn "query.*+\|execute.*+\|raw.*+\|\\.format.*SELECT\|f\".*SELECT\|f'.*SELECT" --include="*.ts" --include="*.js" --include="*.py"
# Verify parameterized queries are used
grep -rn "prepare\|parameterized\|\$[0-9]\|placeholder\|\?" --include="*.ts" --include="*.js" --include="*.py"

• 如果 SQL 查询中使用了字符串拼接或插值，则为 CRITICAL

XSS（跨站脚本）：

# Find dangerous DOM operations
grep -rn "innerHTML\|outerHTML\|document\.write\|\.html(\|dangerouslySetInnerHTML\|v-html\|\{!! " --include="*.ts" --include="*.js" --include="*.tsx" --include="*.jsx" --include="*.vue" --include="*.blade.php"
# Find eval usage
grep -rn "eval(\|Function(\|setTimeout.*string\|setInterval.*string" --include="*.ts" --include="*.js"

• 存储型 XSS 为 HIGH，反射型 XSS 为 MEDIUM，基于 DOM 的 XSS 为 MEDIUM

OS 命令注入：

grep -rn "exec(\|execSync\|spawn(\|system(\|popen\|subprocess\|child_process\|shell_exec\|passthru\|backtick" --include="*.ts" --include="*.js" --include="*.py" --include="*.php"

• 如果用户输入流入命令执行，则为 CRITICAL

路径遍历：

grep -rn "readFile\|writeFile\|createReadStream\|open(\|path\.join.*req\|path\.resolve.*req\|fs\." --include="*.ts" --include="*.js" --include="*.py"

• 检查用户输入是否未经清理就用于文件路径

XXE（XML 外部实体）：

grep -rn "parseXML\|DOMParser\|SAXParser\|XMLReader\|etree\.parse\|xml2js\|libxml" --include="*.ts" --include="*.js" --include="*.py"

• 检查是否已禁用外部实体处理

SSRF（服务端请求伪造）：

grep -rn "fetch(\|axios\|request(\|urllib\|http\.get\|https\.get\|curl\|wget" --include="*.ts" --include="*.js" --include="*.py"

• 检查是否根据允许列表验证用户提供的 URL
• 如果用户输入未经验证就直接流入服务端 HTTP 请求，则为 CRITICAL

服务端模板注入（SSTI）：

grep -rn "render_template_string\|Template(\|Jinja2\|nunjucks.*render\|handlebars.*compile\|ejs.*render" --include="*.ts" --include="*.js" --include="*.py"

• 检查用户输入是否在渲染前嵌入模板

---

阶段 8：测试应用逻辑

参考： cybersecurity/web-application-hackers-handbook/ch11-attacking-application-logic.md

目标： 发现自动化扫描器无法找到的业务逻辑缺陷。

需要询问的问题：

• 每个函数对用户行为做出了哪些假设？
• 是否存在多步骤流程？能否跳过或重新排列步骤？
• 是否涉及金融交易？金额能否被篡改（负值、零、溢出）？
• 是否存在推荐、奖励或优惠券系统？能否被滥用？

要运行的测试：

竞争条件：

grep -rn "balance\|credits\|quantity\|stock\|inventory\|coupon\|redeem\|transfer\|withdraw" --include="*.ts" --include="*.js" --include="*.py"

• 对于任何先检查后执行的模式（检查余额 → 扣款），测试并发请求
• 如果可能发生双重消费或双重兑换，则为 HIGH

多步骤流程滥用：

• 梳理每个多步骤流程（结账、注册、审批）
• 测试：跳过步骤、重复步骤、后退、在步骤间更改数据、在步骤间切换用户上下文

交易逻辑：

• 测试负数金额、零金额、极大金额
• 对预期为整数的值测试小数
• 测试自我推荐、循环推荐链

输入规范化冲突：

• 测试 Unicode 规范化问题（同一字符的不同表示形式）
• 测试大小写敏感冲突（当 "admin" 已存在时，尝试注册为 "Admin"）

---

阶段 9：测试应用服务器

参考： cybersecurity/web-application-hackers-handbook/ch18-attacking-the-application-server.md

目标： 验证服务器平台本身已加固。

要执行的测试：

默认凭据：

• 检查常见路径中是否存在管理面板：/admin、/wp-admin、/phpmyadmin、/console、/manager
• 测试发现的任何管理界面的默认凭据

危险的 HTTP 方法：

curl -X OPTIONS <target-url> -i

• 如果不必要地启用了 PUT、DELETE 或 TRACE，则评为 MEDIUM

安全标头：

curl -s -I <target-url>

检查以下内容：

• Content-Security-Policy — 如果缺失，则评为 HIGH（缓解 XSS）
• Strict-Transport-Security — 如果缺失，则评为 HIGH（强制使用 HTTPS）
• X-Frame-Options 或 CSP frame-ancestors — 如果缺失，则评为 MEDIUM（防止点击劫持）
• X-Content-Type-Options: nosniff — 如果缺失，则评为 LOW（防止 MIME 嗅探）
• Referrer-Policy — 如果缺失，则评为 LOW（防止信息泄露）
• Permissions-Policy — 如果缺失，则评为 INFO
• Server / X-Powered-By — 如果存在，则评为 INFO（泄露版本信息）

调试模式：

grep -rn "DEBUG.*=.*True\|debug.*:.*true\|NODE_ENV.*development\|FLASK_DEBUG\|DJANGO_DEBUG" --include="*.py" --include="*.js" --include="*.ts" --include="*.env*" --include="*.yaml" --include="*.yml"

• 如果生产环境配置中启用了调试模式，则评为 HIGH

依赖项漏洞：

# Node.js
npm audit
# Python
pip-audit  # or safety check
# Ruby
bundle audit

已知 CVE：

• 根据已知漏洞检查框架/库的版本
• RCE CVE 评为 CRITICAL，身份验证绕过 CVE 评为 HIGH

---

阶段 10：审查与报告

参考： cybersecurity/web-application-hackers-handbook/ch15-exploiting-information-disclosure.md、ch21-web-application-hackers-methodology.md

最终检查：

信息泄露：

grep -rn "console\.log\|print(\|logger\.\(debug\|info\)\|TODO\|FIXME\|HACK\|XXX" --include="*.ts" --include="*.js" --include="*.py"

• 检查是否存在泄露内部信息的详细错误消息
• 检查是否暴露了 .git/、.env、源映射文件、备份文件

SSL/TLS：

# If accessible externally
nmap --script ssl-enum-ciphers -p 443 <target>
# Or use testssl.sh

生成审计报告：

# Security Audit Report: [Application Name]
**Date:** [date]
**Auditor:** [name]
**Scope:** [what was tested]

## Executive Summary
[1-2 paragraph summary of overall security posture and critical findings]

## Findings Summary
| # | Severity | Finding | Phase |
|---|----------|---------|-------|
| 1 | CRITICAL | [title] | [phase] |
| 2 | HIGH     | [title] | [phase] |
| ... | ... | ... | ... |

## Detailed Findings

### Finding 1: [Title]
**Severity:** CRITICAL / HIGH / MEDIUM / LOW / INFO
**Phase:** [which phase found it]
**Affected Component:** [endpoint, file, function]

**Description:**
[What the vulnerability is and why it exists]

**Reproduction Steps:**
1. [Step-by-step to reproduce]

**Impact:**
[What an attacker could achieve — data access, account takeover, RCE, etc.]

**Remediation:**
[Specific, actionable fix with code example if possible]

**Reference:**
[OWASP, CWE, or WAHH chapter reference]

---
[Repeat for each finding]

## Recommendations Priority
1. [Fix critical/high findings immediately]
2. [Fix medium findings before next release]
3. [Fix low/info findings as part of regular maintenance]

## Out of Scope / Not Tested
[What was explicitly excluded and why]

严重性评级指南

严重性	标准	示例
CRITICAL	可立即利用、RCE、全面数据泄露、身份验证绕过	可访问数据的 SQL 注入、通过命令注入实现 RCE、硬编码的管理员凭据、未经过身份验证即可访问管理功能
HIGH	大量数据暴露、账户接管、权限提升	存储型 XSS、针对敏感数据的 IDOR、访问控制失效、会话固定、未强制使用 HTTPS
MEDIUM	利用范围有限、需要用户交互、部分数据暴露	反射型 XSS、针对非关键功能的 CSRF、缺少 SameSite Cookie、包含内部路径的详细错误消息
LOW	轻微信息泄露、违反最佳实践	标头中泄露版本信息、缺少 X-Content-Type-Options、敏感字段启用了自动完成功能
INFO	观察项，无直接安全影响	缺少 Permissions-Policy、轻微配置备注、纵深防御建议

常见错误

错误	修复方法
只测试正常路径	使用恶意输入测试每个参数——注入漏洞往往隐藏在边缘情况中
跳过访问控制测试	IDOR 一直是最常见的漏洞之一——使用不同的用户上下文测试每个资源端点
只通过 UI 测试	UI 会隐藏参数、端点和功能——直接测试 API
认为框架会处理安全问题	框架提供的是工具，而非保障——验证每种机制都已正确配置和使用
孤立地进行测试	将发现的问题串联起来——信息泄露 + IDOR + XSS 可能会将严重性从 LOW 提升到 CRITICAL
每个类别发现第一个问题后就停止	发现一处 SQL 注入并不意味着所有查询都存在漏洞——独立测试每个端点