DAST(动态应用安全测试)
某金融科技公司的渗透测试团队接到了一个有趣的挑战:测试一个新上线的移动支付应用。测试时间只有 48 小时,但应用有 300 多个 API 端点、复杂的业务逻辑和三层认证机制。
如果用传统的渗透测试方法,48 小时根本不够。但测试团队带来了一件秘密武器——DAST 工具。工具在 4 小时内完成了对所有端点的自动化扫描,发现了 47 个漏洞,其中 12 个是高危。最终测试报告指出,这个工具发现的漏洞占了全部漏洞的 60%。
DAST,让动态安全测试从「奢侈品」变成了「日用品」。
DAST 的定义
DAST(Dynamic Application Security Testing,动态应用安全测试)是一种通过模拟攻击者的行为,在运行时对应用进行黑盒测试的安全检测技术。与 SAST 不同,DAST 不需要访问源代码,而是通过发送精心构造的请求来测试应用的行为。
工作原理
爬虫 + 攻击模式
DAST 的核心工作流程是「发现 + 测试」:
漏洞检测方法
DAST 通过观察应用对恶意输入的响应来检测漏洞:
工具对比
企业级工具
开源工具
OWASP ZAP 集成
OWASP ZAP(Zed Attack Proxy)是最流行的开源 DAST 工具:
ZAP API 调用
爬虫策略
深度优先 vs 广度优先
认证处理
DAST 最大的挑战之一是处理认证:
Session 管理
API 测试
OpenAPI/Swagger 支持
现代 DAST 工具可以直接导入 API 定义:
GraphQL 测试
GraphQL API 需要专门的测试策略:
CI/CD 集成
完整 CI/CD 集成示例
增量扫描策略
优势与局限性
DAST 的优势
DAST 的局限性
:::warning 重要认知 DAST 不是万能的:
- 覆盖率受限:只能测试爬虫能发现的端点
- 认证挑战:处理复杂认证机制困难
- 单向测试:只能测试公开的请求-响应,无法测试服务端回调
- 性能影响:扫描可能对被测系统造成负载
- 业务逻辑漏洞:无法发现越权、认证绕过等业务逻辑问题
- 异步问题:无法有效测试异步操作和后台任务 :::
思考题
问题 1:某电商网站的 DAST 扫描报告发现了一个高危 SQL 注入漏洞,但开发团队复查代码后认为「这是误报,因为代码使用了 MyBatis ORM」。你如何评估这个情况?
参考答案
评估步骤:
-
确认注入点
- 获取扫描报告中的具体请求和响应
- 确定注入发生的 URL、参数和 payload
-
分析 ORM 使用方式
- MyBatis 的
#{}参数化查询是安全的 - MyBatis 的
${}直接拼接是危险的 - 即使使用 ORM,错误的写法仍然可能导致注入
- MyBatis 的
-
验证漏洞
- 在测试环境手动复现注入
- 观察是否有数据库错误或异常行为
- 检查是否有 WAF 拦截了测试请求
-
可能的情况
- 如果开发团队使用的是安全的参数化查询:可能是 DAST 工具误报
- 如果使用了
${}或动态 SQL:漏洞真实存在 - 如果使用了原生 SQL:漏洞真实存在
结论:即使使用了 ORM,注入漏洞仍可能存在。应该通过代码审查和手动测试来确认,而不是直接否认。
问题 2:某公司计划将 DAST 集成到 CI/CD 流程中,但团队担心扫描时间太长(完整扫描需要 2 小时)会影响部署效率。你会如何设计一个兼顾安全性和效率的 DAST 策略?
参考答案
分层 DAST 策略:
- CI 阶段:快速扫描(5-15 分钟)
- CD 阶段:完整扫描(可选,异步)
- 定时扫描(深度覆盖)
- 性能优化
- 报告分级处理
建议的流程:
- PR 阶段:快速增量扫描(5-10分钟),阻塞高危漏洞
- 每日:完整扫描(异步,不阻塞)
- 每周:安全审查,处理积累的中低危漏洞