OWASP ZAP 使用方式与典型场景
四、使用方式与典型场景
下面给出三个可运行的示例,覆盖手工、扫描与 CI 三种使用形态。
示例一,桌面版手工探索流程。先启动 ZAP,把浏览器代理指向 ZAP 监听端口,然后按顺序操作:
1. 新建 Context,把授权范围加入 Include,第三方资源加入 Exclude
2. 配置 Authentication,完成一次登录并让 ZAP 记住会话
3. 浏览目标站点的全部主要功能,让被动扫描收集流量
4. 查看 Alerts 面板,对低风险高置信度的问题先处理
5. 对可疑请求右键 -> Open/Resend with Request Editor,手工改包验证
6. 对需要覆盖动态页面的路径,启动 AJAX Spider 补充爬取
7. 生成报告并导出为 HTML 与 JSON
示例二,用自动化框架 YAML 描述一个完整的受限测试计划。这份文件放进仓库,作为每次发布前执行的固定动作:
env:
contexts:
- name: target-context
urls:
- https://test.example.local
excludePaths:
- "https://.*\\.cdn-provider\\.com/.*"
authentication:
method: browser
parameters:
loginPageUrl: https://test.example.local/login
loginPageWait: 2
verification:
method: response
loggedInRegex: "\\Qlogout\\E"
loggedOutRegex: "\\Qsign in\\E"
parameters:
failOnError: true
failOnWarning: false
progressToStdout: true
jobs:
- type: spider
parameters:
context: target-context
maxDuration: 10
- type: spiderAjax
parameters:
context: target-context
maxDuration: 10
numberOfBrowsers: 1
- type: passiveScan-wait
parameters:
maxDuration: 5
- type: report
parameters:
template: traditional-html
reportFile: zap-report.html
reportDir: /zap/wrk/
执行方式:
docker run -t -v $(pwd):/zap/wrk/:rw zaproxy/zap-stable \
zap.sh -cmd -autorun /zap/wrk/plan.yaml
示例三,CI 流水线中的基线扫描。把基线扫描作为每次合并请求的检查项,只做被动检查,速度快、风险低,适合高频运行:
docker run -t -v $(pwd):/zap/wrk/:rw zaproxy/zap-stable \
zap-baseline.py \
-t https://test.example.local \
-c baseline-rules.tsv \
-J baseline-report.json \
-r baseline-report.html \
-w baseline-report.md \
-I
其中 -c 指定规则配置表,可以对特定规则设置忽略或告警等级;-I 表示不因告警而返回非零退出码,便于先观察一段时间再决定是否开启门禁。建议的做法是初期先只出报告不阻断,等规则调优稳定后再开启阻断。
适用与不适用场景对照。
| 场景 | 是否合适 | 说明 |
|---|---|---|
| 自有系统的常规安全基线检查 | 非常合适 | 开源免费,适合长期跑 |
| CI 流水线中的自动化安全检查 | 非常合适 | Automation Framework 与 Docker 支持完善 |
| 接口定义文件(OpenAPI)的扫描 | 合适 | 有专门的 api-scan 脚本 |
| 复杂业务逻辑漏洞的发现 | 不合适 | 自动扫描无法理解业务语义,需人工测试 |
| 未授权的任何目标 | 绝对不允许 | 违法,且扫描流量容易被识别与追责 |
| 生产环境高强度主动扫描 | 需严格评估 | 可能影响可用性,须授权方明确同意 |
| 纯前端单页应用的深度测试 | 需配合其他手段 | AJAX Spider 能覆盖一部分,但交互逻辑仍需人工 |

