web-app-penetration-testing

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Pentest a web application

Web应用渗透测试

Black-box (and optionally source-assisted) penetration testing of a running web app with Strix's autonomous agents. Every reported finding is validated with a working exploit, so there are no signature-based false positives to triage.

Install, LLM setup, all CLI flags, and the managed-cloud alternative are covered in the penetration-testing-with-strix skill — read it if the target is not a running web app, or if

strix --version

fails. This skill is the web-app-specific workflow.

通过Strix的自主代理对运行中的Web应用进行黑盒（可选辅助源代码）渗透测试。每个报告的漏洞都经过可运行的利用验证，因此不会出现基于特征的误报需要分类处理。

安装、LLM设置、所有CLI参数以及托管云替代方案都在penetration-testing-with-strix技能中有所介绍——如果目标不是运行中的Web应用，或者

strix --version

命令执行失败，请阅读该技能。本技能是针对Web应用的特定工作流程。

1. Confirm authorization and scope

1. 确认授权与测试范围

Before running anything, establish:

The target is the user's (or they are explicitly authorized to test it). Never pentest a third-party site on a hunch.
Which environment. Prefer staging over production; agents send real exploit payloads and will create/modify data.
Out-of-scope paths — payment flows, mass-email endpoints, admin destructive actions, third-party SSO providers.
Credentials. Most real vulnerabilities live behind login. Without a test account, the agents only ever see the marketing surface.

Ask for anything missing rather than guessing.

在运行任何测试之前，需明确：

目标属于用户所有（或用户已获得明确授权进行测试）。切勿仅凭猜测对第三方站点进行渗透测试。
测试环境。优先选择预发布环境而非生产环境；代理会发送真实的利用载荷，可能会创建或修改数据。
测试范围外的路径——支付流程、批量邮件端点、管理员破坏性操作、第三方SSO提供商。
凭据。大多数真实漏洞存在于登录后。如果没有测试账户，代理只能看到营销页面。

如有缺失信息，请询问用户，切勿自行猜测。

2. Run the scan

2. 运行扫描

bash

strix -n -t https://staging.example.com --max-budget 20 \
  --instruction "Test account: qa@example.com / <password>. In scope: /app/*, /api/*. Do not touch /billing or send email. Focus on access control between the two seeded orgs."

Notes that matter for web apps specifically:

Give it credentials via
--instruction
(or
```
--instruction-file
```
for anything long), including how to log in if the flow is unusual (magic link, SSO, MFA-exempt test user).
Two accounts beat one. Multi-tenant IDOR and broken-access-control bugs — consistently the highest-impact class in web apps — can only be proven when the agent can attempt cross-account access.
Add the repo for white-box depth when you have the source:
```
-t https://github.com/org/app -t https://staging.example.com
```
(or a local path). Source access materially improves coverage of business-logic and authorization flaws.
Localhost works. Point at
```
http://host.docker.internal:3000
```
(Docker Desktop) so the sandbox can reach a dev server on the host.
```
--scan-mode quick
```
for a fast dev-loop pass,
```
standard
```
(~30 min) for a normal review,
```
deep
```
for pre-release assurance. Always set
```
--max-budget
```
.

For a hosted run with no Docker/LLM key, or when the user wants a shareable dashboard and an auditor-ready PDF, use the cloud path in managed-pentesting-with-strix instead — same engine, same findings.

bash

strix -n -t https://staging.example.com --max-budget 20 \
  --instruction "Test account: qa@example.com / <password>. In scope: /app/*, /api/*. Do not touch /billing or send email. Focus on access control between the two seeded orgs."

针对Web应用的重要注意事项：

通过
--instruction
参数提供凭据（如果内容较长，可使用
```
--instruction-file
```
），包括特殊登录流程的操作方法（如魔法链接、SSO、豁免MFA的测试用户）。
两个账户优于一个。多租户IDOR和访问控制失效漏洞——Web应用中影响最大的漏洞类别——只有当代理能够尝试跨账户访问时才能被验证。
若有源代码，添加仓库以实现白盒深度测试：
```
-t https://github.com/org/app -t https://staging.example.com
```
（或本地路径）。源代码访问能显著提升对业务逻辑和授权漏洞的覆盖范围。
支持本地主机。指向
```
http://host.docker.internal:3000
```
（Docker Desktop），以便沙箱能够访问主机上的开发服务器。
```
--scan-mode quick
```
用于快速开发循环测试，
```
standard
```
（约30分钟）用于常规审查，
```
deep
```
用于发布前验证。始终设置
```
--max-budget
```
参数。

如果没有Docker/LLM密钥，或者用户需要可共享的仪表板和符合审计要求的PDF，请使用managed-pentesting-with-strix中的云路径——引擎相同，测试结果一致。

3. Review results

3. 查看测试结果

Read

strix_runs/<run>/penetration_test_report.md

first, then per-finding files in

vulnerabilities/

. Each contains the PoC — re-run it yourself to confirm before reporting to the user.

Exit codes:

no validated vulns in what was analyzed,

vulnerabilities found,

fatal error. A

is not proof of full coverage — if the budget or turn cap was hit the scan wraps up early, so check

run.json

status and cost against

--max-budget

before calling the app clean.

首先阅读

strix_runs/<run>/penetration_test_report.md

，然后查看

vulnerabilities/

目录下的单个漏洞文件。每个文件都包含概念验证（PoC）——在向用户报告之前，请自行重新运行以确认。

退出代码：

表示分析范围内未发现已验证的漏洞，

表示发现漏洞，

表示致命错误。

并不代表完全覆盖——如果达到预算或轮次上限，扫描会提前结束，因此在判定应用安全之前，请检查

run.json

的状态和成本是否符合

--max-budget

设置。

4. Fix and verify

4. 修复与验证

Hand findings to the fix-security-vulnerabilities-with-strix skill: patch the root cause, then re-run Strix against the same target to prove the exploit no longer works. Re-testing is the only reliable confirmation a fix landed.

To keep the app tested on every change rather than once, wire Strix into CI with ci-security-scanning-with-strix.

将漏洞信息交给fix-security-vulnerabilities-with-strix技能：修复根本原因，然后针对同一目标重新运行Strix，以证明漏洞利用已失效。重新测试是确认修复生效的唯一可靠方式。

若要在每次变更时持续测试应用，而非仅测试一次，请将Strix集成到CI流程中，使用ci-security-scanning-with-strix技能。