Wapiti

定义

Wapiti 是一个开源的 Web 应用漏洞扫描器，用 Python 编写，以命令行程序的形式提供给用户使用^[1][4]。它的定位是对网站或 Web 应用进行安全审计，属于动态应用安全测试工具，即在应用运行状态下从外部发起测试，而不是通过阅读源码来查找缺陷^[5][2]。

在各类发行版中，它通常被归类为 Web 类的工具包，例如 Debian 将其源码包列入 web 分类，Ubuntu 与 Fedora 也把 Wapiti 作为常规软件包收录，其 Python 发行包名为 wapiti3^[6][7][8]。它依靠一组彼此独立的检测模块工作，用户可以在扫描时自由选择启用哪些模块^[9]。

原理

Wapiti 的工作过程分为两个阶段。第一个阶段是爬取，程序从给定的入口网址出发，沿页面链接逐层向下遍历，识别出页面中的脚本、表单、URL 参数、Cookie 与 HTTP 头等可能的注入点^[2][4]。这一阶段对应扫描器的爬虫部分，它决定后续测试能够覆盖多大范围^[10]。

第二个阶段是攻击，程序对爬取阶段收集到的每一个输入点运行相应模块，向其中注入构造好的载荷，再检查返回内容中是否出现报错信息、特定字符串、异常状态码或响应时间变化，据此判断漏洞是否存在^[1][5]。这样的做法在原理上属于模糊测试：测试者并不预先知道应用内部实现，只能通过输入与响应之间的差异来推断问题^[2]。

模块化的结构是 Wapiti 的核心设计。每个攻击模块针对一类漏洞独立编写，模块名可用 -m 或 --module 参数以逗号分隔的列表形式指定，例如 crlf 负责 HTTP 头中的 CR-LF 注入，wapp 模块并不发起攻击，而是借助 Wappalyzer 数据库识别目标使用的 Web 技术及其版本并关联已知漏洞编号^[11][4]。扫描过程中的状态保存在 SQLite 数据库中，因此长时间扫描可以被中断并在之后恢复^[12][4]。

发展历程

Wapiti 由法国安全研究者 Nicolas Surribas 于 2006 年发起，他当时的动机是学习 Python 编程语言^[3][13]。项目最初只专注于查找 XSS 类漏洞，之后随着模块不断加入，检测范围才扩展到当时已经广为人知的其他 Web 漏洞类型^[14]。

该工具早期即被纳入 OWASP 的项目体系，称为 OWASP Wapiti Project，并在 OWASP 的维基页面上以“Web 应用漏洞扫描器／安全审计器”的名义登记，项目负责人一栏记为 Nicolas Surribas^[15][10]。早期版本的授权方式在 OWASP 页面上记为 GNU 宽通用公共许可证，而在后来的项目仓库与各类发行版中则记为 GNU 通用公共许可证第 2 版^[2][1][8]。

2018 年 1 月，3.0.0 版本发布，这一版本带来了大量新选项，同时标志着项目从旧版 Python 迁移到 Python 3^[14]。此后版本继续迭代，其 Python 包对运行环境的要求达到 Python 3.12 及以上^[1][5]。开发工作由一支志愿者团队在全球范围内协作完成^[2]。

应用

Wapiti 的典型使用场景是对自己拥有或被授权测试的网站与 Web 应用做安全自查，在应用部署之后从外部验证其防护状况^[16]。它可检测的范围包括数据库注入与 XPath 注入、反射型与持久型跨站脚本、本地与远程文件包含、命令执行、XML 外部实体注入、CRLF 注入、服务器端请求伪造、开放重定向、跨站请求伪造等类别，并可借助 Nikto 数据库查找服务器上存在风险的已知文件、发现弱 htaccess 配置与脚本备份文件^[6][4]。

由于是命令行工具，Wapiti 便于写入自动化流程，常被安排在持续集成或定期自动化测试中执行^[17][18]。它支持 Basic、Digest、NTLM 等认证方式以及登录表单与浏览器 Cookie 导入，从而具备扫描登录后才能访问的页面的能力，也支持通过 HTTP、HTTPS 代理发起请求^[4][2]。扫描完成后可输出 HTML、XML、JSON、TXT、CSV 等格式的报告，便于人工查看或交由其他系统解析^[4][5]。

局限

作为基于爬虫与模糊测试的工具，Wapiti 的效果首先受爬取覆盖范围限制。有对比研究显示，在给定目标上 Wapiti 的爬取覆盖率约为 45%，低于同期对照工具，未能发现全部已知入口点，其爬虫还曾因遗漏表单中的隐藏参数而导致对某些漏洞的利用失败^[18][19]。

误报是此类工具的常见问题。个别评测指出，Wapiti 在自定义错误页面或返回 HTTP 200 的异常响应上容易给出误判，其检出的漏洞精确率明显低于带图形界面的同类工具，使用时往往需要人工复核被标记的 SQL 注入与 XSS 结果^[20][18]。相关对比还记录到，Wapiti 在一次测试中的完整扫描耗时接近 3 小时，明显长于对照工具，这使得把它作为每次代码提交的必过检查并不现实，更适合定期自动化执行^[18]。

从原理上讲，黑盒方式本身也带来两类结构性的不足。其一，Wapiti 不解析 JavaScript，页面中由脚本动态生成的链接难以被跟随，由此形成深层页面与爬虫难以到达的部分无法进入测试范围^[21]。其二，程序只能依据注入与响应之间的差异进行推断，无法看到应用内部逻辑，因此即便存在漏洞也可能因为缺少必要参数或触发条件而未被显现，其结论应当由人工确认后才能作为判断依据^[19][5]。

参见

• 动态应用安全测试 —— Wapiti 所属的工具类别，通过运行中的应用从外部查找漏洞。

• 模糊测试 —— Wapiti 注入载荷并观察响应所依据的基本方法。

• 网络爬虫 —— Wapiti 扫描第一个阶段用来收集页面、链接与表单的技术。

• SQL 注入 —— Wapiti 的数据库注入模块所针对的漏洞类型。

• 跨站脚本 —— Wapiti 能够区分反射型与持久型的另一类常见 Web 漏洞。

• OWASP —— 曾将 Wapiti 作为其项目之一收录的开源安全组织。