web-app-security-audit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Web Application Security Audit

Web应用程序安全审计

Overview

概述

A structured penetration testing methodology based on The Web Application Hacker's Handbook. Guides you through 10 sequential phases to systematically identify vulnerabilities in any web application you're building or reviewing.

基于《Web应用黑客手册》的结构化渗透测试方法论，指导你完成10个连续阶段，系统地识别你正在构建或审查的任何Web应用程序中的漏洞。

When to Use

适用场景

Before deploying a web application to production
When adding authentication, payment processing, or user-facing features
During periodic security reviews
After integrating third-party services or APIs
When you suspect a specific vulnerability class but want comprehensive coverage

Web应用程序部署到生产环境前
添加身份验证、支付处理或用户面向功能时
定期安全审查期间
集成第三方服务或API后
怀疑存在特定漏洞类别但需要全面覆盖时

When NOT to Use

不适用场景

Against applications you don't own or have authorization to test
As a replacement for professional penetration testing on critical systems
For network-level security (this is application-layer focused)

针对你不拥有或未获得测试授权的应用程序
作为关键系统专业渗透测试的替代方案
用于网络级安全测试（本方法专注于应用层）

Process

测试流程

Work through each phase sequentially. At each phase:

Ask targeted questions about the specific application
Read the relevant chapter summary from
```
cybersecurity/web-application-hackers-handbook/
```
for detailed guidance
Suggest and execute concrete tests (grep patterns in source code, curl commands, Burp Suite steps, automated scripts)
Flag findings with severity:
```
CRITICAL
```
/
```
HIGH
```
/
```
MEDIUM
```
/
```
LOW
```
/
```
INFO
```
Summarize findings before moving to the next phase

If the application doesn't have a relevant surface for a phase (e.g., no file uploads), acknowledge and skip with rationale.

dot

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;
}

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

提问：针对特定应用提出针对性问题
阅读：参考
```
cybersecurity/web-application-hackers-handbook/
```
中的相关章节摘要获取详细指导
建议并执行：具体测试（源代码中的grep模式、curl命令、Burp Suite步骤、自动化脚本）
标记发现：按严重程度分类：
```
CRITICAL
```
/
```
HIGH
```
/
```
MEDIUM
```
/
```
LOW
```
/
```
INFO
```
总结：进入下一阶段前总结发现

如果应用程序某阶段没有相关测试面（例如无文件上传功能），请说明理由后跳过该阶段。

dot

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

  p1 [label="阶段1\n应用程序映射"];
  p2 [label="阶段2\n应用程序分析"];
  p3 [label="阶段3\n客户端控制测试"];
  p4 [label="阶段4\n身份验证测试"];
  p5 [label="阶段5\n会话管理测试"];
  p6 [label="阶段6\n访问控制测试"];
  p7 [label="阶段7\n注入漏洞测试"];
  p8 [label="阶段8\n应用逻辑测试"];
  p9 [label="阶段9\n应用服务器测试"];
  p10 [label="阶段10\n审查与报告"];
  report [label="安全审计\n报告", shape=note];

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

Phase 1: Map the Application

阶段1：应用程序映射

Reference:

cybersecurity/web-application-hackers-handbook/ch04-mapping-the-application.md

Goal: Discover the full attack surface before testing anything.

Questions to ask:

What is the application's tech stack? (framework, language, database, hosting)
What are all the routes/endpoints? (read route files, API definitions, OpenAPI specs)
Are there admin panels, API docs, or debug endpoints?
What third-party services are integrated?

Tests to run:

Enumerate all routes from source code:

# 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

Check for exposed files:

robots.txt

sitemap.xml

.env

.git/

package.json

Search for hardcoded secrets in source:

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

Review HTML/JS comments for sensitive information
Identify all input vectors: URL params, POST bodies, cookies, headers, file uploads, WebSockets

Deliverable: Complete attack surface map — routes, parameters, technologies, entry points.

参考文档：

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 — 检查app/和pages/目录结构

检查暴露的文件：

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、请求头、文件上传、WebSockets

交付成果：完整的攻击面映射——路由、参数、技术栈、入口点。

Phase 2: Analyze the Application

阶段2：应用程序分析

Reference:

cybersecurity/web-application-hackers-handbook/ch03-web-application-technologies.md

Goal: Understand what the application does and identify high-risk areas.

Questions to ask:

What are the core business functions? (user management, payments, data CRUD, search, file handling)
Which functions handle sensitive data? (PII, financial, credentials)
Are there multi-step processes? (checkout, registration, approval workflows)
What user roles exist? What can each role do?

Prioritize testing areas (highest risk first):

Authentication and credential handling
Payment/financial transaction processing
File upload functionality
Administrative interfaces
API endpoints (often have weaker controls than web UI)
Search functionality (frequent injection target)
User-to-user features (stored XSS vector)
Data export/import (injection, XXE)

Deliverable: Functional map with risk-prioritized areas of interest.

参考文档：

cybersecurity/web-application-hackers-handbook/ch03-web-application-technologies.md

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

需提问的问题：

核心业务功能是什么？（用户管理、支付处理、数据增删改查、搜索、文件处理）
哪些功能处理敏感数据？（个人身份信息PII、财务数据、凭证）
是否存在多步骤流程？（结账、注册、审批工作流）
有哪些用户角色？每个角色的权限是什么？

优先测试区域（风险从高到低）：

身份验证和凭证处理
支付/财务交易处理
文件上传功能
管理接口
API端点（通常比Web UI控制更弱）
搜索功能（常见注入目标）
用户间交互功能（存储型XSS载体）
数据导出/导入（注入、XXE风险）

交付成果：带风险优先级标记的功能映射。

Phase 3: Test Client-Side Controls

阶段3：客户端控制测试

Reference:

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

Goal: Verify the server never trusts client-side validation or state.

Questions to ask:

Are there hidden form fields the server relies on? (prices, roles, user IDs)
Is input validation only done client-side? (JavaScript, HTML5 attributes)
Does the client transmit data that should be server-side state? (cart totals, discount flags, permission levels)

Tests to run:

Search for hidden fields:

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

Search for client-only validation:

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

Check if server-side validation mirrors client-side:

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

For each form, submit requests with: missing required fields, values exceeding maxlength, values violating patterns, modified hidden fields
Test price/role/permission manipulation by modifying request bodies

Finding template:

[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]

参考文档：

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"

针对每个表单，提交以下请求：缺少必填字段、值超出最大长度、违反格式规则、修改隐藏字段
通过修改请求体测试价格/角色/权限篡改

发现模板：

[严重程度] 客户端控制绕过: [描述]
  影响范围: [端点/参数]
  测试操作: [你执行的步骤]
  测试结果: [发生的情况]
  影响: 攻击者可实现的后果
  修复建议: [服务器端验证建议]

Phase 4: Test Authentication

阶段4：身份验证测试

Reference:

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

Goal: Verify authentication cannot be bypassed, brute-forced, or abused.

Tests to run:

Username enumeration:

Compare responses for valid vs invalid usernames on login, registration, and password reset
Check response body, status codes, timing differences, and response length

Search for inconsistent error messages:

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

Brute-force resilience:

Check for account lockout, rate limiting, CAPTCHA

Search for rate limiting implementation:

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

Password policy:

Test minimum length, complexity requirements, common password blocking

Check password storage:

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

```
CRITICAL
```
if passwords stored as plaintext, MD5, or SHA1 without salt

Password reset:

Check token randomness, expiry, single-use enforcement
Check if reset tokens are in URLs (logged in server logs, browser history)

Multi-factor authentication:

Can MFA step be skipped by directly requesting authenticated endpoints?
Can MFA be bypassed by replaying codes or using expired codes?

Remember me:

Decode the remember-me token (Base64, JWT) — does it contain user info?
Is it invalidated on password change?

参考文档：

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步骤？
是否可通过重放验证码或使用过期验证码绕过MFA？

记住我功能：

解码“记住我”令牌（Base64、JWT）——是否包含用户信息？
密码更改时是否失效？

Phase 5: Test Session Management

阶段5：会话管理测试

Reference:

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

Goal: Verify sessions cannot be hijacked, fixated, or predicted.

Tests to run:

Token generation:

Collect multiple session tokens and check for patterns (sequential, timestamp-based, low entropy)

Decode tokens (Base64, JWT) — do they contain sensitive data?

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

Cookie flags:

Check every cookie for:

Secure

HttpOnly

SameSite

Domain

Path

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

```
HIGH
```
if session cookie missing
```
HttpOnly
```
(XSS can steal it)
```
HIGH
```
if session cookie missing
```
Secure
```
(transmitted over HTTP)
```
MEDIUM
```
if session cookie missing
```
SameSite
```
(CSRF vector)

Session lifecycle:

Does the token change after login? (session fixation if not)
Is the session invalidated server-side on logout? (not just cookie deletion)
Is there idle timeout and absolute timeout?

CSRF protection:

Identify all state-changing operations (POST/PUT/DELETE)

Check for anti-CSRF tokens:

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

Can state-changing requests succeed without the CSRF token?

参考文档：

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

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

需执行的测试：

令牌生成：

收集多个会话令牌并检查是否存在模式（顺序、基于时间戳、低熵）

解码令牌（Base64、JWT）——是否包含敏感数据？

# 针对JWT
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缺少
```
Secure
```
则标记为
```
HIGH
```
（通过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令牌时状态变更请求是否可成功？

Phase 6: Test Access Controls

阶段6：访问控制测试

Reference:

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

Goal: Verify users cannot access unauthorized data or functionality.

Questions to ask:

What user roles exist? (admin, user, moderator, API consumer)
How is authorization enforced? (middleware, decorators, inline checks)
Are there resource IDs in URLs or request bodies that could be manipulated?

Tests to run:

IDOR (Insecure Direct Object Reference):

Find all endpoints with resource IDs:

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

As User A, request User B's resources by changing IDs
```
CRITICAL
```
if successful

Vertical privilege escalation:

As a regular user, request admin endpoints directly

Check if authorization is enforced per-endpoint:

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

Check if any endpoints lack authorization middleware

Horizontal privilege escalation:

Modify user-identifying parameters (
```
user_id
```
,
```
account_id
```
,
```
email
```
) in requests
Check if the server validates that the requested resource belongs to the authenticated user

Multi-step process controls:

For multi-step flows (checkout, approval), test skipping to later steps directly
Test performing steps out of order

参考文档：

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身份请求用户B的资源（修改ID）
若成功则标记为
```
CRITICAL
```

垂直权限提升：

以普通用户身份直接请求管理员端点

检查是否按端点实施授权：

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

检查是否存在未配置授权中间件的端点

水平权限提升：

修改请求中的用户标识参数（
```
user_id
```
,
```
account_id
```
,
```
email
```
）
检查服务器是否验证请求资源属于已认证用户

多步骤流程控制：

针对多步骤流程（结账、审批），测试直接跳转到后续步骤
测试打乱步骤顺序执行

Phase 7: Test for Injection Vulnerabilities

阶段7：注入漏洞测试

Reference:

cybersecurity/web-application-hackers-handbook/ch09-attacking-data-stores.md

ch10-attacking-back-end-components.md

ch12-attacking-users-xss.md

Goal: Verify all input is safely handled across every context.

SQL Injection:

undefined

参考文档：

cybersecurity/web-application-hackers-handbook/ch09-attacking-data-stores.md

ch10-attacking-back-end-components.md

ch12-attacking-users-xss.md

目标：验证所有输入在任何上下文下都被安全处理。

SQL注入：

undefined

Find raw query construction (CRITICAL pattern)

查找原始查询构造（CRITICAL模式）

Verify parameterized queries are used

验证是否使用参数化查询

grep -rn "prepare|parameterized|$[0-9]|placeholder|?" --include=".ts" --include=".js" --include="*.py"

- `CRITICAL` if string concatenation/interpolation used in SQL queries

**XSS (Cross-Site Scripting):**

grep -rn "prepare|parameterized|$[0-9]|placeholder|?" --include=".ts" --include=".js" --include="*.py"

- 若SQL查询使用字符串拼接/插值则标记为`CRITICAL`

**跨站脚本（XSS）**：

Find dangerous DOM operations

查找危险DOM操作

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

查找eval使用

grep -rn "eval(|Function(|setTimeout.string|setInterval.string" --include=".ts" --include=".js"

- `HIGH` for stored XSS, `MEDIUM` for reflected XSS, `MEDIUM` for DOM-based XSS

**OS Command Injection:**

- `CRITICAL` if user input flows into command execution

**Path Traversal:**

- Check if user input is used in file paths without sanitization

**XXE (XML External Entity):**

- Check if external entity processing is disabled

**SSRF (Server-Side Request Forgery):**

- Check if user-supplied URLs are validated against an allowlist
- `CRITICAL` if user input flows directly into server-side HTTP requests without validation

**Server-Side Template Injection (SSTI):**

- Check if user input is embedded in templates before rendering

---

grep -rn "eval(|Function(|setTimeout.string|setInterval.string" --include=".ts" --include=".js"

- 存储型XSS标记为`HIGH`，反射型XSS标记为`MEDIUM`，DOM型XSS标记为`MEDIUM`

**操作系统命令注入**：

- 若用户输入流入命令执行则标记为`CRITICAL`

**路径遍历**：

- 检查用户输入是否在未经过滤的情况下用于文件路径

**XML外部实体（XXE）**：

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

**服务器端请求伪造（SSRF）**：

- 检查用户提供的URL是否针对允许列表验证
- 若用户输入直接流入服务器端HTTP请求且无验证则标记为`CRITICAL`

**服务器端模板注入（SSTI）**：

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

---

Phase 8: Test Application Logic

阶段8：应用逻辑测试

Reference:

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

Goal: Identify flaws in business logic that automated scanners cannot find.

Questions to ask:

What assumptions does each function make about user behavior?
Are there multi-step processes? Can steps be skipped or reordered?
Are there financial transactions? Can amounts be manipulated (negative values, zero, overflow)?
Are there referral/reward/coupon systems? Can they be abused?

Tests to run:

Race conditions:

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

For any check-then-act pattern (check balance → deduct), test concurrent requests
```
HIGH
```
if double-spending or double-redemption is possible

Multi-step process abuse:

Map every multi-step flow (checkout, registration, approval)
Test: skip steps, repeat steps, go backward, change data between steps, switch user context between steps

Transaction logic:

Test negative amounts, zero amounts, extremely large amounts
Test fractional values where integers expected
Test self-referral, circular referral chains

Input normalization conflicts:

Test unicode normalization issues (different representations of same character)
Test case sensitivity conflicts (register as "Admin" when "admin" exists)

参考文档：

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"已存在）

Phase 9: Test Application Server

阶段9：应用服务器测试

Reference:

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

Goal: Verify the server platform itself is hardened.

Tests to run:

Default credentials:

Check if admin panels exist at common paths:
```
/admin
```
,
```
/wp-admin
```
,
```
/phpmyadmin
```
,
```
/console
```
,
```
/manager
```
Test default credentials for any discovered admin interfaces

Dangerous HTTP methods:

bash

curl -X OPTIONS <target-url> -i

```
MEDIUM
```
if PUT, DELETE, or TRACE are enabled unnecessarily

Security headers:

bash

curl -s -I <target-url>

Check for:

```
Content-Security-Policy
```
—
```
HIGH
```
if missing (XSS mitigation)
```
Strict-Transport-Security
```
—
```
HIGH
```
if missing (HTTPS enforcement)
```
X-Frame-Options
```
or CSP
```
frame-ancestors
```
—
```
MEDIUM
```
if missing (clickjacking)
```
X-Content-Type-Options: nosniff
```
—
```
LOW
```
if missing (MIME sniffing)
```
Referrer-Policy
```
—
```
LOW
```
if missing (information leakage)
```
Permissions-Policy
```
—
```
INFO
```
if missing
```
Server
```
/
```
X-Powered-By
```
—
```
INFO
```
if present (version disclosure)

Debug mode:

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
```
if debug mode enabled in production config

Dependency vulnerabilities:

bash

undefined

参考文档：

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

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

需执行的测试：

默认凭证：

检查常见路径下是否存在管理面板：
```
/admin
```
,
```
/wp-admin
```
,
```
/phpmyadmin
```
,
```
/console
```
,
```
/manager
```
针对发现的任何管理接口测试默认凭证

危险HTTP方法：

bash

curl -X OPTIONS <target-url> -i

若不必要启用PUT、DELETE或TRACE则标记为
```
MEDIUM
```

安全请求头：

bash

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
```

依赖漏洞：

bash

undefined

Node.js

npm audit

Python

pip-audit # or safety check

pip-audit # 或safety check

Ruby

bundle audit


**Known CVEs:**
- Check framework/library versions against known vulnerabilities
- `CRITICAL` for RCE CVEs, `HIGH` for auth bypass CVEs

---

bundle audit


**已知CVE**：
- 对比框架/库版本与已知漏洞
- 远程代码执行（RCE）类CVE标记为`CRITICAL`，身份验证绕过类CVE标记为`HIGH`

---

Phase 10: Review & Report

阶段10：审查与报告

Reference:

cybersecurity/web-application-hackers-handbook/ch15-exploiting-information-disclosure.md

ch21-web-application-hackers-methodology.md

Final checks:

Information disclosure:

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

Check for verbose error messages exposing internals
Check for exposed
```
.git/
```
,
```
.env
```
, source maps, backup files

SSL/TLS:

bash

undefined

参考文档：

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：

bash

undefined

If accessible externally

若对外可访问

nmap --script ssl-enum-ciphers -p 443 <target>

Or use testssl.sh

或使用testssl.sh


**Generate the audit report:**

```markdown


**生成审计报告**：

```markdown

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]

[1-2段总结整体安全状况和关键发现]

Findings Summary

发现摘要

#	Severity	Finding	Phase
1	CRITICAL	[title]	[phase]
2	HIGH	[title]	[phase]
...	...	...	...

序号	严重程度	发现内容	阶段
1	CRITICAL	[标题]	[阶段]
2	HIGH	[标题]	[阶段]
...	...	...	...

Detailed Findings

详细发现

Finding 1: [Title]

发现1: [标题]

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:

[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]

严重程度: CRITICAL / HIGH / MEDIUM / LOW / INFO 阶段: [发现阶段] 影响组件: [端点、文件、功能]

描述: [漏洞是什么及存在原因]

复现步骤:

[分步复现]

影响: [攻击者可实现的后果——数据访问、账户接管、RCE等]

修复建议: [具体、可执行的修复方案，如有可能提供代码示例]

参考: [OWASP、CWE或WAHH章节参考]

[每个发现重复上述格式]

Recommendations Priority

建议优先级

[Fix critical/high findings immediately]
[Fix medium findings before next release]
[Fix low/info findings as part of regular maintenance]

[立即修复严重/高危发现]
[下次发布前修复中危发现]
[作为常规维护修复低危/信息类发现]

Out of Scope / Not Tested

超出范围/未测试内容

[What was explicitly excluded and why]

undefined

[明确排除的内容及原因]

undefined

Severity Rating Guide

严重程度评级指南

Severity	Criteria	Examples
CRITICAL	Immediate exploitation, RCE, full data breach, auth bypass	SQL injection with data access, RCE via command injection, hardcoded admin credentials, unauthenticated admin access
HIGH	Significant data exposure, account takeover, privilege escalation	Stored XSS, IDOR on sensitive data, broken access controls, session fixation, missing HTTPS enforcement
MEDIUM	Limited exploitation, requires user interaction, partial data exposure	Reflected XSS, CSRF on non-critical functions, missing SameSite cookies, verbose error messages with internal paths
LOW	Minor information disclosure, best practice violation	Version disclosure in headers, missing X-Content-Type-Options, autocomplete on sensitive fields
INFO	Observation, no direct security impact	Missing Permissions-Policy, minor configuration notes, suggestions for defense-in-depth

严重程度	判定标准	示例
CRITICAL	可立即被利用，远程代码执行RCE、全面数据泄露、身份验证绕过	可访问数据的SQL注入、命令注入导致的RCE、硬编码管理员凭证、未认证管理员访问
HIGH	严重数据泄露、账户接管、权限提升	存储型XSS、敏感数据的IDOR、访问控制失效、会话固定、缺失HTTPS强制
MEDIUM	有限利用，需用户交互，部分数据泄露	反射型XSS、非关键功能的CSRF、缺失SameSite Cookie、暴露内部路径的详细错误信息
LOW	轻微信息泄露、最佳实践违规	请求头中的版本泄露、缺失X-Content-Type-Options、敏感字段自动补全
INFO	观察结果，无直接安全影响	缺失Permissions-Policy、轻微配置说明、深度防御建议

Common Mistakes

常见错误

Mistake	Fix
Testing only the happy path	Test every parameter with malicious input — injection lives in the edge cases
Skipping access control testing	IDOR is consistently a top vulnerability — test every resource endpoint with different user contexts
Only testing through the UI	The UI hides parameters, endpoints, and capabilities — test the API directly
Assuming the framework handles security	Frameworks provide tools, not guarantees — verify each mechanism is correctly configured and used
Testing in isolation	Chain findings — info disclosure + IDOR + XSS can escalate from LOW to CRITICAL
Stopping at first finding per category	One SQL injection doesn't mean all queries are vulnerable — test each endpoint independently

错误	修复方案
仅测试正常流程	针对每个参数测试恶意输入——注入漏洞存在于边缘情况
跳过访问控制测试	IDOR始终是排名靠前的漏洞——针对每个资源端点测试不同用户上下文
仅通过UI测试	UI会隐藏参数、端点和功能——直接测试API
假设框架处理安全	框架提供工具而非保障——验证每个机制配置正确且被使用
孤立测试发现	链式发现——信息泄露+IDOR+XSS可从LOW升级为CRITICAL
每个类别仅测试第一个发现	一个SQL注入不代表所有查询都安全——独立测试每个端点