AppScan安全测试实验报告

实验用的全测靶机是本地搭的DVWA，一个故意留了十个洞的试实PHP应用。AppScan扫了四十分钟，验报跑出37个问题，全测其中SQL注入占了11条——这数字比我想象的试实干净，毕竟DVWA的验报低安全级别连过滤都没开。真正让我意外的全测是，它把两个看似无关的试实漏洞关联成了同一攻击链，这事后面细说。验报

扫描配置没改默认，全测只是试实把登录会话导了进去。AppScan的验报爬虫在登录页卡了两次，因为DVWA的全测token是动态生成的，它第一次提交表单时被服务器拒了。试实解决办法很笨——手动录了一段登录流程，验报再让扫描器接着跑。这提醒我，工具再自动也架不住应用自己作妖，动态token就是个典型例子。

结果列表按风险排序，红色高亮的是个存储型XSS，藏在留言板的name字段里。payload是``，AppScan自己构造的，没经过我手。它甚至能判断出输出点在HTML的`

`标签内，所以用了闭合标签的变体。这种细节比单纯报个“XSS存在”有用得多，省了人工验证的时间。

SQL注入那部分最有趣。AppScan对参数`id`做了三十多种测试，从单引号到时间盲注的`sleep(3)`，最后确认是UNION注入。但它没停在那儿，反而顺着注入点继续爬，把数据库里的表名都枚举出来了。这行为像极了真实攻击者的思路——拿到库结构后，下一步就是找管理员密码哈希。实验报告里这部分证据链特别完整，请求响应逐条对应，连数据库版本号都从报错信息里抠出来了。

有个低危问题让我犹豫了会儿。它标记了一处“不安全的反序列化”，位置在`/api/update.php`。我翻了源码，发现确实用了`unserialize()`处理用户输入，但没配`allowed_classes`限制。理论上能构造恶意对象链，不过DVWA这台机器没装额外扩展，实际利用难度很高。AppScan给了CVSS分数3.7，偏低，可它提示的修复建议是“白名单类名”而不是“禁用反序列化”——这个度把握得挺准，没瞎吓唬人。

跑完扫描后我做了个对比实验：把DVWA安全级别调到中级，再扫一遍。注入漏洞从11条降到4条，因为过滤函数挡掉了大部分直接拼接。但XSS反而多了2条，原因是中级的`htmlspecialchars`没处理属性上下文，AppScan抓到个`" onfocus="alert(1)`的变体。这说明漏洞修复不是一锤子买卖，打地鼠式补丁只会让攻击者换条路走。

最后说点工具本身的感受。AppScan的报表导出成PDF有三百多页，但真正有用的就前二十页的执行摘要和修复建议。剩下的是请求响应快照，除非做合规审计，否则没人会翻。还有个烦人的点——它把DVWA的`robots.txt`里禁止的目录也扫了，这算白噪音。后来我在配置里加了排除规则，扫描时间缩短了三分之一。

实验做到这儿，结论很直白：AppScan适合当自动化巡检的第一道筛子，能挖出明显漏洞并给出证据链，但别指望它替代人工渗透测试。像那个反序列化问题，它报了，可要判断实际风险还得靠人读代码。工具的价值在于把重复劳动压缩掉，让安全测试人员把精力留给需要思考的部分——这大概就是它存在的意义。