web-pentest

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Web Pentest — Live Web Application Testing

Web渗透测试——在线Web应用测试

Structured black-box / grey-box penetration testing of a live web application against an authorized target. Pairs with

recon

(which maps the surface) and complements

owasp-audit

(which reads the source). Use

recon

first; use this once you have a target list and credentials (or guest access).

针对授权目标的结构化黑盒/灰盒在线Web应用渗透测试。可与

recon

（用于梳理攻击面）配合使用，作为

owasp-audit

（用于源代码审计）的补充。请先执行

recon

；当你拥有目标列表和凭证（或访客访问权限）后，再使用此方法。

Authorization Check

授权检查

Before touching the target, confirm:

Written authorization for this specific application (pentest engagement, bug bounty in-scope domain, CTF/lab, your own asset)
The application is currently in scope and live (not deprecated, not under maintenance freeze)
Test credentials provided (if grey-box), or guest access confirmed (if black-box)
Out-of-scope items documented — production user data, payment flows, social engineering, DoS

If anything is unclear, ask before proceeding. Never assume authorization.

在接触目标前，请确认：

针对该特定应用的书面授权（渗透测试委托、漏洞赏金范围内域名、CTF/实验环境、自有资产）
应用当前处于测试范围内且正常运行（未废弃、未处于维护冻结状态）
已提供测试凭证（灰盒测试），或已确认访客访问权限（黑盒测试）
已记录测试范围外的内容——生产用户数据、支付流程、社会工程学攻击、DoS攻击

如有任何不明确之处，请先询问再执行操作。切勿假设已获得授权。

Methodology

测试方法论

Follows the OWASP Web Security Testing Guide (WSTG) structure. Each phase produces evidence; document everything as you go.

遵循OWASP Web安全测试指南（WSTG）的结构。每个阶段都会生成证据，请随时记录所有操作。

Phase 1: Configuration & deployment

阶段1：配置与部署

Goal: understand what's running and how it's exposed.

HTTP headers — pull with
```
curl -I
```
and
```
curl -I -H "Origin: https://evil.com"
```
:
- ```
Server
```
  ,
```
X-Powered-By
```
  revealing stack
- HSTS, CSP, X-Frame-Options, X-Content-Type-Options presence and values
- CORS —
```
Access-Control-Allow-Origin
```
  reflection without an allow-list,
```
Allow-Credentials: true
```
  paired with
```
*
```

TLS —

testssl.sh https://target

sslyze --regular target

Backups / configs exposed —

/.git/

/.env

/backup.sql

/web.config

/server-status

/.aws/credentials

Default admin paths —

/admin

/administrator

/manage

/console

/actuator/

/_debug/

/swagger

/graphql

/.well-known/

Robots.txt and sitemap.xml — often list non-indexed but accessible endpoints
Subdomain & host header testing — does the app behave differently when sent
```
Host: internal.target.com
```
?

目标：了解运行的服务及其暴露方式。

HTTP头信息——使用
```
curl -I
```
和
```
curl -I -H "Origin: https://evil.com"
```
获取：
- ```
Server
```
  、
```
X-Powered-By
```
  字段可暴露技术栈
- HSTS、CSP、X-Frame-Options、X-Content-Type-Options的存在性及配置值
- CORS——
```
Access-Control-Allow-Origin
```
  无允许列表的反射、
```
Allow-Credentials: true
```
  与
```
*
```
  搭配使用

TLS——使用

testssl.sh https://target

或

sslyze --regular target

测试

暴露的备份/配置文件——

/.git/

、

/.env

、

/backup.sql

、

/web.config

、

/server-status

、

/.aws/credentials

默认管理员路径——

/admin

、

/administrator

、

/manage

、

/console

、

/actuator/

、

/_debug/

、

/swagger

、

/graphql

、

/.well-known/

Robots.txt和sitemap.xml——通常会列出未索引但可访问的端点
子域名与Host头测试——当发送
```
Host: internal.target.com
```
时，应用行为是否发生变化？

Phase 2: Identity management

阶段2：身份管理

Goal: understand who can be created, how, and with what privileges.

Registration — can you self-register? Does the role default to anything other than "user"?
Username enumeration via differential responses on signup ("email already exists"), login ("user not found" vs "wrong password"), password reset ("we sent an email" vs "no such user")
Account provisioning — does a verification email arrive? Can it be skipped? Does the reset link expire? Does the reset link tie to the original session?
Account lockout vs rate-limit — does 100 failed logins lock the account (denial of service vector) or just slow down (good)?

目标：了解可创建的用户身份、创建方式及对应的权限。

注册——是否支持自助注册？默认角色是否为“用户”以外的其他角色？
通过注册（“邮箱已存在”）、登录（“用户不存在” vs “密码错误”）、密码重置（“已发送邮件” vs “无此用户”）的差异化响应枚举用户名
账户配置——是否会收到验证邮件？能否跳过验证？重置链接是否过期？重置链接是否与原始会话绑定？
账户锁定与速率限制——100次登录失败会锁定账户（拒绝服务攻击向量）还是仅降低登录速度（合理配置）？

Phase 3: Authentication

阶段3：认证测试

Goal: break in as someone you shouldn't be.

Login form — is HTTPS enforced? Are credentials sent in URL params (logged everywhere)?
Password policy — minimum length / complexity / breach-database check (haveibeenpwned API)
MFA — required for admin / privileged users? Bypass paths (recovery code, "remember this device" cookie persistence, downgrade to SMS)?
Session token — entropy looks high? Cookie has
```
HttpOnly
```
,
```
Secure
```
,
```
SameSite=Lax
```
or
```
Strict
```
?
Session fixation — does the session ID rotate on login? Pre-auth session ID still valid post-auth?
"Remember me" — long-lived token in a separate cookie; revocable on logout from all devices?
Logout — does it actually invalidate the session server-side? (Test by replaying the cookie post-logout.)
Password reset — token format, expiration, single-use, host-header poisoning (
```
Host: evil.com
```
in the reset email link)
OAuth flow — PKCE used?
```
state
```
parameter validated?
```
redirect_uri
```
strictly matched (not prefix-matched)?

目标：以非授权身份登录系统。

登录表单——是否强制使用HTTPS？凭证是否通过URL参数传输（会被多处记录）？
密码策略——最小长度/复杂度/泄露数据库检查（使用haveibeenpwned API）
MFA——管理员/特权用户是否强制启用？是否存在绕过路径（恢复码、“记住此设备”Cookie持久化、降级为SMS验证）？
会话令牌——熵值是否足够高？Cookie是否设置
```
HttpOnly
```
、
```
Secure
```
、
```
SameSite=Lax
```
或
```
Strict
```
属性？
会话固定——登录时会话ID是否会轮换？登录前的会话ID在登录后是否仍有效？
“记住我”功能——是否在独立Cookie中存储长期令牌？登出时能否在所有设备上撤销令牌？
登出——是否会在服务器端真正使会话失效？（测试方法：登出后重放Cookie）
密码重置——令牌格式、有效期、是否单次使用、是否存在Host头劫持（重置邮件链接中的
```
Host: evil.com
```
）
OAuth流程——是否使用PKCE？是否验证
```
state
```
参数？是否严格匹配
```
redirect_uri
```
（而非前缀匹配）？

Phase 4: Authorization (the highest-yield phase)

阶段4：授权测试（最高收益阶段）

Goal: access things you shouldn't.

Horizontal privilege escalation (IDOR / BOLA):

Sign in as user A. Get a resource that belongs to user A. Note the ID.
Sign in as user B. Try to access user A's resource by ID — direct fetch, in the body of an update, as a foreign key in another operation.
Watch for response codes — 200 (bad), 403 (good), 404 (good if all unauthorized requests return 404; bad if your own 404 looks different)

Try every endpoint that takes an ID —

GET /users/:id

POST /users/:id/...

DELETE /users/:id

GET /api/users/:id/orders

, GraphQL

user(id: ...)

Vertical privilege escalation (BFLA):

Identify admin-only routes (from
```
/admin/*
```
exploration, from JS bundle strings, from Burp's site map)
Hit them as a regular user. 403 (good), 200 (very bad)

Check for verb tampering —

DELETE /admin/users/x

blocked, but

POST /admin/users/x/delete

works

Mass assignment — registration endpoint that accepts
```
{ role: "admin" }
```
because it does
```
User.create(req.body)
```
without filtering

Tenant isolation (multi-tenant SaaS):

Create org A with user U1. Create org B with user U2.
As U1, try every URL that includes the org/tenant ID and swap it to org B's. Expect 403 / 404 on every one. A 200 is a tenancy break.

目标：访问非授权资源。

横向权限提升（IDOR / BOLA）：

以用户A身份登录，获取属于用户A的资源并记录其ID。
以用户B身份登录，尝试通过ID访问用户A的资源——直接请求、更新请求体、其他操作中的外键。
关注响应码——200（存在漏洞）、403（正常）、404（若所有未授权请求均返回404则正常；若自身404响应与其他不同则存在漏洞）

尝试所有接收ID的端点——

GET /users/:id

、

POST /users/:id/...

、

DELETE /users/:id

、

GET /api/users/:id/orders

、GraphQL

user(id: ...)

纵向权限提升（BFLA）：

识别管理员专属路由（来自
```
/admin/*
```
探测、JS包字符串、Burp站点地图）
以普通用户身份访问这些路由。403（正常）、200（严重漏洞）
检查请求方法篡改——
```
DELETE /admin/users/x
```
被拦截，但
```
POST /admin/users/x/delete
```
可正常执行
批量赋值——注册端点接受
```
{ role: "admin" }
```
，因为代码直接执行
```
User.create(req.body)
```
未做过滤

租户隔离（多租户SaaS）：

创建组织A及用户U1，创建组织B及用户U2。
以U1身份尝试所有包含组织/租户ID的URL，将其替换为组织B的ID。预期所有请求均返回403/404。若返回200则存在租户隔离漏洞。

Phase 5: Session management

阶段5：会话管理

Session token in URL? Anywhere logged → access logs leak it
Concurrent sessions allowed? Should be configurable / loggable
Token after password change — invalidated everywhere? (Test by changing password in browser 1 and replaying browser 2's cookie.)
CSRF protection — synchronizer token, SameSite cookie, custom request header? Test by forging a request from a different origin

会话令牌是否出现在URL中？是否被记录在任何地方→访问日志会泄露令牌
是否允许多会话？应支持配置/日志记录
修改密码后的令牌——是否在所有设备上失效？（测试方法：在浏览器1中修改密码，重放浏览器2的Cookie）
CSRF防护——是否使用同步令牌、SameSite Cookie、自定义请求头？通过伪造跨域请求进行测试

Phase 6: Input validation

阶段6：输入验证

For each input — URL params, query strings, headers, JSON bodies, file uploads:

XSS — reflected (in error pages, search results,
```
<title>
```
injection), stored (in profile fields, comments, file names), DOM (look at JS sinks like
```
innerHTML
```
,
```
eval
```
,
```
location
```
)
- Payload bank — see
```
owasp-audit
```
  Verify Fixes XSS payloads
SQLi —
```
' OR 1=1 --
```
, time-based blind (
```
'; SELECT pg_sleep(5)--
```
), error-based, UNION-based
- Modern stacks usually use parameterized queries; look for the one endpoint that didn't get the memo
Command injection — anywhere file names, image processing, PDF generation, or shell-out happens
SSRF — webhook URLs, image-fetch, PDF render — see
```
owasp-audit
```
A10 bypass matrix
XXE — XML inputs in SOAP / SVG-upload / DOCX-import paths
Server-side template injection —
```
{{7*7}}
```
in a name field renders
```
49
```
? You're in
Open redirect — see
```
owasp-audit
```
A01 with control-byte rejection
Insecure deserialization — base64-decode any opaque tokens and look for serialized format markers (
```
O:
```
for PHP,
```
\xac\xed
```
for Java,
```
cos\nsystem
```
for Python pickle)

针对每个输入——URL参数、查询字符串、请求头、JSON体、文件上传：

XSS——反射型（错误页面、搜索结果、
```
<title>
```
注入）、存储型（个人资料字段、评论、文件名）、DOM型（关注
```
innerHTML
```
、
```
eval
```
、
```
location
```
等JS sink）
- payload库——参考
```
owasp-audit
```
  中的XSS验证修复payload
SQLi——
```
' OR 1=1 --
```
、基于时间的盲注（
```
'; SELECT pg_sleep(5)--
```
）、基于错误的注入、基于UNION的注入
- 现代技术栈通常使用参数化查询；寻找未遵循此规范的端点
命令注入——任何涉及文件名、图像处理、PDF生成或调用shell的场景
SSRF——Webhook URL、图片获取、PDF渲染——参考
```
owasp-audit
```
中的A10绕过矩阵
XXE——SOAP/SVG上传/DOCX导入路径中的XML输入
服务器端模板注入——在名称字段中输入
```
{{7*7}}
```
是否渲染为
```
49
```
？若是则存在漏洞
开放重定向——参考
```
owasp-audit
```
中的A01及控制字节拦截方法
不安全反序列化——对任何不透明令牌进行base64解码，查找序列化格式标记（PHP的
```
O:
```
、Java的
```
\xac\xed
```
、Python pickle的
```
cos\nsystem
```
）

Phase 7: Error handling

阶段7：错误处理

Stack traces visible in 500 responses
Database errors leak schema (table names, column names)
File paths leak server filesystem layout
Different errors for valid vs invalid usernames (enumeration)
```
/health
```
/
```
/status
```
/
```
/metrics
```
/
```
/actuator/*
```
exposed

500响应中是否显示堆栈跟踪
数据库错误是否泄露 schema（表名、列名）
文件路径是否泄露服务器文件系统布局
有效用户名与无效用户名的错误信息是否不同（用户名枚举）
```
/health
```
/
```
/status
```
/
```
/metrics
```
/
```
/actuator/*
```
是否暴露

Phase 8: Business logic

阶段8：业务逻辑

The category most scanners can't touch. Look at what the app is supposed to do and ask "what if I do that, but wrong?"

Race conditions — submit the same coupon code 100× concurrently; can you redeem it more than once?
Negative numbers — can you transfer
```
-100
```
and credit yourself?
Out-of-order workflows — can you complete step 4 before step 2?
Quota bypass — free tier limits enforced server-side or just in the UI?
Workflow approval — can you approve your own request by tampering with
```
approver_id
```
?
File upload — can you upload an
```
.html
```
and have the server serve it with
```
Content-Type: text/html
```
?

这是扫描工具无法覆盖的类别。思考“应用应该做什么”，并提问“如果我按错误的方式操作会怎样？”

竞争条件——同时提交100次相同优惠券代码；能否多次兑换？
负数——能否转账
```
-100
```
给自己增加余额？
无序工作流——能否在完成步骤2前完成步骤4？
配额绕过——免费层限制是在服务器端还是仅在UI中执行？
工作流审批——能否通过篡改
```
approver_id
```
批准自己的请求？
文件上传——能否上传
```
.html
```
文件并让服务器以
```
Content-Type: text/html
```
返回？

Phase 9: Client-side

阶段9：客户端测试

JS bundle review —
```
view-source:
```
/ DevTools, look for inline secrets, API keys, internal endpoint hints
CSP — try to inject a
```
<script>
```
and see if it's blocked
Browser storage — what's in
```
localStorage
```
/
```
sessionStorage
```
/ IndexedDB? Tokens? PII?
Cross-origin — can
```
postMessage
```
from your origin reach the app's window without origin check?

JS包审查——使用
```
view-source:
```
/开发者工具，查找内嵌密钥、API密钥、内部端点提示
CSP——尝试注入
```
<script>
```
标签，查看是否被拦截
浏览器存储——
```
localStorage
```
/
```
sessionStorage
```
/IndexedDB中存储了什么？令牌？个人可识别信息？
跨域——你的域名能否通过
```
postMessage
```
访问应用窗口而无需来源检查？

Tooling

工具集

Burp Suite Community (free) — proxy, repeater, intruder (rate-limited), decoder
Burp Suite Pro — scanner, faster intruder, session handling rules
OWASP ZAP — free alternative, active scanner, fuzzer
ffuf / feroxbuster / gobuster — directory and parameter brute-forcing
sqlmap — SQLi exploitation (use carefully; can be noisy and destructive —
```
--risk=1 --level=1
```
to start)
dalfox / XSStrike — XSS scanners (high false-positive; use as a starting point)
nuclei — template-driven vulnerability scanner; the templates themselves are excellent reading
curl / httpie — repeatable manual requests; everything you find should reduce to a curl command

Burp Suite Community（免费）——代理、重放器、入侵者（速率限制）、解码器
Burp Suite Pro——扫描器、高速入侵者、会话处理规则
OWASP ZAP——免费替代工具、主动扫描器、模糊测试器
ffuf / feroxbuster / gobuster——目录与参数暴力破解
sqlmap——SQLi利用工具（谨慎使用；可能产生大量噪音并具有破坏性——从
```
--risk=1 --level=1
```
开始）
dalfox / XSStrike——XSS扫描器（高误报率；仅作为起点使用）
nuclei——模板驱动的漏洞扫描器；其模板本身是极佳的学习资料
curl / httpie——可重复的手动请求；所有发现都应能转化为curl命令

Output Format

输出格式

markdown

undefined

markdown

undefined

Web Application Pentest Report

Web应用渗透测试报告

Target: [target name and scope]

目标：[目标名称与范围]

Engagement window: [start - end]

测试周期：[开始日期 - 结束日期]

Methodology: OWASP WSTG

方法论：OWASP WSTG

Date: [date]

报告日期：[日期]

Executive summary

执行摘要

[2-3 paragraphs — overall posture, top 3 critical findings, business impact]

[2-3段文字——整体安全状况、Top3关键发现、业务影响]

Findings

发现列表

ID	Severity	OWASP	CWE	Title

ID	严重程度	OWASP	CWE	标题

Per-finding detail

详细发现说明

[SEVERITY] [Title]

[严重程度] [标题]

Endpoint:

METHOD /path

OWASP / CWE: WSTG-XXX / CWE-XXX

Description: [what + why it matters]

Proof of concept: [curl / Burp request showing the issue, minimal viable repro]

Observed response: [response excerpt showing the issue]

Remediation: [concrete fix + reference to owasp-audit or api-audit if applicable]

Risk rating: [Critical / High / Medium / Low / Info — with rationale]

Verification: [what to re-test after fix]

端点：

METHOD /path

OWASP / CWE： WSTG-XXX / CWE-XXX

描述： [问题内容 + 影响原因]

概念验证： [curl / Burp请求示例，最小可复现步骤]

观察到的响应： [显示问题的响应片段]

修复建议： [具体修复方案 + 若适用可参考owasp-audit或api-audit]

风险评级： [Critical / High / Medium / Low / Info — 附理由]

验证方式： [修复后需重新测试的内容]

Out-of-scope / not tested

测试范围外/未测试项

[Anything skipped, with reason]

[所有跳过的内容及原因]

Recommendations

建议

[Prioritized 30/60/90 day fixes]

undefined

[按优先级排序的30/60/90天修复计划]

undefined

Boundaries

边界规则

Stay strictly within the authorized scope — never test adjacent systems, subdomains, or third-party services without explicit confirmation
Rate-limit your own testing — Burp Intruder at 100 req/s for hours is indistinguishable from a DoS attack
Never modify or destroy real user data — test on test accounts you own, or test data you created
If you find evidence of active compromise (someone else's webshell, exfiltration in progress), STOP testing and notify the user immediately
Refuse requests to test systems without authorization
Refuse to weaponize findings — proof-of-concept is the minimum viable demonstration, not a working exploit kit
For DoS / availability testing, get explicit written approval naming the maintenance window
For social engineering / phishing tests, scope must explicitly name this — it is not "in" pentest scope by default

严格遵守授权范围——未经明确确认，切勿测试相邻系统、子域名或第三方服务
限制测试速率——Burp入侵者以100请求/秒持续数小时的行为与DoS攻击无法区分
切勿修改或销毁真实用户数据——使用你拥有的测试账户或自行创建的测试数据进行测试
若发现系统已被入侵的证据（他人的webshell、正在进行的数据泄露），立即停止测试并通知用户
拒绝无授权的系统测试请求
拒绝将发现武器化——概念验证是最小可行演示，而非可运行的 exploit 套件
若要进行DoS/可用性测试，需获得明确的书面授权并指定维护窗口
若要进行社会工程学/钓鱼测试，测试范围必须明确包含此项——默认不属于渗透测试范围

References

参考资料

OWASP Web Security Testing Guide (WSTG) — canonical methodology
OWASP Application Security Verification Standard (ASVS) — checklist version
PTES (Penetration Testing Execution Standard)
Bug Bounty Methodology (Jason Haddix / TBHM)
PortSwigger Web Security Academy — free training labs
HackTricks (book.hacktricks.xyz) — technique reference (verify against fresh sources; HackTricks aggregates community knowledge of varying quality)

OWASP Web安全测试指南（WSTG）——标准方法论
OWASP应用安全验证标准（ASVS）——清单版本
PTES（渗透测试执行标准）
漏洞赏金方法论（Jason Haddix / TBHM）
PortSwigger Web安全学院——免费培训实验环境
HackTricks（book.hacktricks.xyz）——技术参考（需结合最新来源验证；HackTricks聚合了质量参差不齐的社区知识）