文/lzy.je
这几天应工作的需要，一直在调查、研究一些开源、免费的 Web 应用安全缺陷检测软件。经过试用，感觉这方面的工具很多，但和 Rational AppScan 这种商用软件相比都不够强大、全面（当然，可比性也不大），各个工具都覆盖了一些方面的问题，但又都不全面，可能这也就是开源社区“产品”的特点和优势 吧，呵呵。在这里把觉得比较好的三款工具实践过程在这里做个简单记录、分享。
这里要说的三个工具分别是：
Google Ratproxy (1.54 beta，Apache 2.0 协议)
Nikto (2.03，GPL 协议)
Wapiti (2.0.0-beta，GPL 协议)
拿到的版本都是最新的，不过那也都是 2008 下半年 release 的了。呵呵，既开源又免费，能理解。
Google Ratproxy
Google Ratproxy 是 Google 信息安全技术团队所研发的程序安全缺陷检测工具，开发者是 MIchal Zalewski ，于 2008 年 Google 将其列入 code.google.com，之前它一直在内部使用。Ratproxy 能够分析诸如跨站脚本攻击、检测伪装的跨站请求，以及其它潜在的信息泄露安全缺陷等。它是 c 语言开发的，支持的平台有 Windows（cygwin）、Mac OS/X、*nux 系统。支持的协议有 HTTP/HTTPS 1.0/1.1。比较亮点的是，它允许配置成 No risk of disruptions 模式，即不会向服务器提交高攻击性的测试请求，这适用于生产系统环境。Ratproxy 实际上是一个代理程序，在测试过程中，它将位于客户端与服务器之间，因此它是一种被动方式的测试工具，通过截获用户的浏览行为（提交的请求），将其改造后 提交到服务器，当服务器返回响应后，它会从中分析获得潜在的应用安全缺陷。可见，这种被动的设计让 Ratproxy 优缺各半，一方面测试范围比较容易界定，想测试哪个子系统/模块就人肉访问哪些功能，而另一方面，如果要求覆盖的范围比较全的话，恐怕需要爬虫类程序的辅 助 Explore。 使用前首先要编译 Ratproxy，它没有 configure 过程，直接 make 就好了。在公司我用的是 Ubuntu（gcc 4.3.2）环境，家里也用 cygwin（手工装的 gcc 4.3.3） 编译过。为了提高测试效果，Ratproxy 允许配置一些选项，这个就不详细罗列了，可以参见网站提供的文档。在这里我使用了如下参数来启动它。
Shell代码
./ratproxy -v . -w test1.log -d demo.testfire.net -XCl2efxiscmg -p 9090 |
这样会在 localhost:9090 上开放 ratproxy 代理，-XCl2efxiscmg 参数限定了测试的选项，-d demo.testfire.net 参数限定了测试的网站域，并在当前目录中生成名为 test1.log 的测试日志。如果处在需要嵌套代理的网络环境中，可以使用类似于 -P proxyhost.com:8080 选项来配置它。接下一来就可以在配置了 localhost:9090 代理服务器的浏览器中，开始手动访问被测 Web 应用了，ratproxy 会自动在后台完成测试，并将结果存入预定的 test1.log 日志中。在完成测试后，使用如下工具来生成 html 格式的安全测试报告。
Shell代码
./ratproxy-report.sh test1.log > ratproxy_report.html |
从生成的结果中可以掌握 Web 应用中潜在的如下几类安全缺陷：
POST query with no XSRF protection
Confirmed XSS vectors
Bad caching headers
Ambiguous HTTP content headers
Cookie issuer with no XSRF protection
HTTP errors
Bad or no charset declared for renderable file
XSS candidates
Request splitting candidates
GET query with no XSRF protection
All Flash applications
All POST requests
All cookie setting URLs
当然，上面的分方式不太规范，不过这些分类项都可以与 WASC 威胁分类能对应上。慢慢看吧，不过有一些测得的项目真只是 candidate 而已。试用后总体觉得该工具还是相对不错的，性价比较高，但结果的覆盖率不太理想，而且被动的 Explore 方式让覆盖率较高的测试不容易完成。
Nikto
Nikto 也是一款开放源代码的、功能强大的 Web 应用安全测试验证工具。它也是采用黑盒的方式来测试 Web 应用，与上面的 Google Ratproxy 不同的是，Nikto 采用主动测试方式，抓网过程不需要人为参与，据文档说它可以针对 230 多种服务器，识别出 2600 多种有潜在危险的文件、cgi 程序和其他安全问题。它可以扫描指定主机中的特定目录、cookie 及特定 cgi 漏洞。Nikto 底层使用的是 Whiske 库，但据说要比 Whisker 更新的频繁。Nikto 是由 Perl 语言开发的，支持的平台也很广泛，安装 perl vm 是可以了，包括 Windows、Mac OS/X 和 *nux系统。支持的协议有 HTTP/HTTPS 1.0/1.1，HTTPS 要求安装 ssl 库。Nikto 包括了一个可以更新的测试用例库，可以由用户手动更新。
Shell代码
perl nikto.pl -host demo.testfire.net -mutate 1234 -Tuning 0123456789abg -C all |
其中 -mutate 1234 -Tuning 0123456789abg -C all 选项都是为了提高测试结果质量。具体的可以参考文档。生成的日志如下。
Log代码
- ***** SSL support not available (see docs for SSL install instructions) ***** - Nikto v2.10/2.10 -------------------------------------------------------------------------- + Target IP: 65.61.137.117 + Target Hostname: demo.testfire.net + Target Port: 80 + Using Mutation: Test all files with all root directories + Using Mutation: Guess for password file names + Using Mutation: Enumerate user names via Apache (/~user type requests) + Using Mutation: Enumerate user names via cgiwrap (/cgi-bin/cgiwrap/~user t ype requests) + Start Time: 2009-02-23 12:59:06 --------------------------------------------------------------------------- + Server: Microsoft-IIS/6.0 + OSVDB-0: Retrieved X-Powered-By header: ASP.NET + OSVDB-630: IIS may reveal its internal IP in the Location header via a request to the /p_w_picpaths directory. The value is "http://192.168.1.117/p_w_picpaths/". + OSVDB-0: Allowed HTTP Methods: OPTIONS, TRACE, GET, HEAD, POST + OSVDB-877: HTTP method ('Allow' Header): 'TRACE' is typically only used for de bugging and should be disabled. This message does not mean the server is vulnera ble to XST. + OSVDB-0: Public HTTP Methods: OPTIONS, TRACE, GET, HEAD, POST + OSVDB-877: HTTP method ('Public' Header): 'TRACE' is typically only used for d ebugging and should be disabled. This message does not mean the server is vulner able to XST. + 1 host(s) tested |
测得的潜在缺陷是以 OSVDB 的编号提供的，通过这可编号，可以通过 http://www.osvdb.org/ 来查询得到详细说明，osvdb 提供了一种安全缺陷分类方式。
试用 Nikto 觉得比上面的 Google Ratproxy 逊色不少，结果基本不能满足需求，覆盖率较低，但觉得其易用性较好，很容易上手使用，而且容易、方便。可以搭配 ratproxy 来做补充。
Wapiti
最后要说的就是 Wapiti 了。它的工作方式与 nikto 类似，也采用黑盒的方式主动的对被测 Web 应用进行扫描，寻找其中潜在的安全缺陷，但不像 nikto 提供测试用例库，而是实现了内置的匹配算法。具说可以识别文件处理错误、SQL、LDAP 及 CRLF 类注入攻击，跨站脚本攻击、检查潜在的命令执行。wapiti 是由 python 语言开发的，因此支持的平台也很广泛，安装 python vm 是可以了，包括 Windows、Mac OS/X 和 *nux系统。支持的协议有 HTTP/HTTPS 1.0/1.1，HTTPS 要求安装 ssl 库。支持生成多种格式的安全测试验证报告。通过如下命令启动 wapiti 测试过程。
Shell代码
python wapiti.py http://demo.testfire.net/ |
很简单吧，但需要说明的是，如果你测试的 Web 应用需要登录操作（覆盖到那些登录后才启用的功能），可能需要预先设置 cookie，wapiti 提供了 getcookie.py 脚本来辅助完成。在这里 demo.testfire.net 一些功能也是有登录保护的，因此需要通过如下方式来为 wapiti.py 测试脚本来准备 cookie。
Shell代码
python getcookie.py cookies.txt http://demo.testfire.net/bank/login.aspx |
通过给出必要的登录用户/密码（jsmith/demo1234）来生成 cookie 并保存在 cookies.txt 中。
Shell代码
lswww will be far less effective without tidy please install libtidy ( http://tidy.sourceforge.net/ ), ctypes ( http://starship.python.net/crew/theller/ctypes/ ) and uTidylib ( http://utidylib.berlios.de/ ) Please enter values for the folling form : url = http://demo.testfire.net/bank/login.aspx btnSubmit (Login) : passw (on) : demo1234 uid (on) : jsmith 0 : <Cookie ASP.NET_SessionId=bj2w3d55k4bgzlbvqrvdbq45 for demo.testfire.net/> 1 : <Cookie amCreditOffer=CardType=Gold&Limit=10000&Interest=7.9 for demo.testfi re.net/> 2 : <Cookie amSessionId=23514510510 for demo.testfire.net/> 3 : <Cookie amUserId=100116014 for demo.testfire.net/> 4 : <Cookie amUserInfo=UserName=anNtaXRo&Password=ZGVtbzEyMzQ= for demo.testfire .net/> |
通过新的参数来使用 cookie。
Shell代码
python wapiti.py http://demo.testfire.net/ -c cookies.txt -x http://demo.testfire.net/bank/logout.aspx |
由于 http://demo.testfire.net/bank/logout.aspx 指出的“退出”操作会使 cookie 失效，所以使用 -x 从测试中排除了该 url。测试完成后 wapiti 会自动生成报告，不需要其它操作。
从生成的结果中可以掌握 Web 应用中潜在的如下几类安全缺陷：
SQL Injection
File Handling
Cross Site Scripting
CRLF
Commands execution
觉得这种分类也比较原始，还是建议参考 WASC 提供的威胁分类。
实际上从上面的结果来看，三个工具都能获得一些潜在的 Web 安全缺陷，但又都不完整。如果真要用这些开源、免费的安全测试工具的话，建议还是认真分析，结合使用，多多迭代吧。另外，所有的结果报告只是强调了应予关 切的领域，并不一定表明实际的缺陷，所采集的数据和获得的结果应提供给具有良好理解的安全专家来分析、使用，并获得最终结论。因此，Web 应用的安全缺陷防治，到底来还是对本质原理的掌握。
