使用开源免费工具检查 Web 应用潜在的安全缺陷

          这几天应工作的需要，一直在调查、研究一些开源、免费的 Web 应用安全缺陷检测软件。经过试用，感觉这方面的工具很多，但和 Rational AppScan 这种商用软件相比都不够强大、全面（当然，可比性也不大），各个工具都覆盖了一些方面的问题，但又都不全面，可能这也就是开源社区“产品”的特点和优势吧，呵呵。在这里把觉得比较好的三款工具实践过程在这里做个简单记录、分享。

 

这里要说的三个工具分别是：

 

1. Google Ratproxy (1.54 beta，Apache 2.0 协议)
2. Nikto (2.03，GPL 协议)
3. 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 允许配置一些选项，这个就不详细罗列了，可以参见网站提供的文档。在这里我使用了如下参数来启动它。

 

./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 格式的安全测试报告。

 

./ratproxy-report.sh test1.log > ratproxy_report.html

 

 

          从生成的结果中可以掌握 Web 应用中潜在的如下几类安全缺陷：

 

1. POST query with no XSRF protection
2. Confirmed XSS vectors
3. Bad caching headers
4. Ambiguous HTTP content headers
5. Cookie issuer with no XSRF protection
6. HTTP errors
7. Bad or no charset declared for renderable file
8. XSS candidates
9. Request splitting candidates
10. GET query with no XSRF protection
11. All Flash applications
12. All POST requests
13. 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 包括了一个可以更新的测试用例库，可以由用户手动更新。

 

perl nikto.pl -host demo.testfire.net -mutate 1234 -Tuning 0123456789abg -C all

 

          其中 -mutate 1234 -Tuning 0123456789abg -C all 选项都是为了提高测试结果质量。具体的可以参考文档。生成的日志如下。

 

- ***** 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 /images directory. The value is "http://192.168.1.117/images/".
+ 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 测试过程。

 

python wapiti.py http://demo.testfire.net/

 

很简单吧，但需要说明的是，如果你测试的 Web 应用需要登录操作（覆盖到那些登录后才启用的功能），可能需要预先设置 cookie，wapiti 提供了 getcookie.py 脚本来辅助完成。在这里 demo.testfire.net 一些功能也是有登录保护的，因此需要通过如下方式来为 wapiti.py 测试脚本来准备 cookie。

 

python getcookie.py cookies.txt http://demo.testfire.net/bank/login.aspx

 

          通过给出必要的登录用户/密码（jsmith/demo1234）来生成 cookie 并保存在 cookies.txt 中。

 

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。

 

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 应用中潜在的如下几类安全缺陷：

 

1. SQL Injection
2. File Handling
3. Cross Site Scripting
4. CRLF
5. Commands execution
   

          觉得这种分类也比较原始，还是建议参考 WASC 提供的威胁分类。

 

          实际上从上面的结果来看，三个工具都能获得一些潜在的 Web 安全缺陷，但又都不完整。如果真要用这些开源、免费的安全测试工具的话，建议还是认真分析，结合使用，多多迭代吧。另外，所有的结果报告只是强调了应予关切的领域，并不一定表明实际的缺陷，所采集的数据和获得的结果应提供给具有良好理解的安全专家来分析、使用，并获得最终结论。因此，Web 应用的安全缺陷防治，到底来还是对本质原理的掌握。

 

这个就到这里吧，欢迎交流、共同进步。

kernel 和 linux os 又好多天没大进展了，哎～

 

// 2009.02.24 22:05 添加 ////

 

列出一些缺陷所表示的意义。呵呵，顺便 SEO 一下。

 

1. 几个常见的 Web 应用安全缺陷及样例
2. 几个常见的 Web 应用安全缺陷及样例（续）

// 2009.02.24 22:17 添加 ////

 

          忘了说的是，wapiti 2.0.0-beta 包中没有包括 getcookie.py 脚本文件，忘记了？不知道为什么。需要的兄弟可以下载 wapiti 1.1.6 其中包括了这个文件。

wapiti-1.1.6.tar.gz

 

// 2009.03.07 13:23 添加 ////

作者：lzy.je
出处：http://lzy.iteye.com
本文版权归作者所有，只允许以摘要和完整全文两种形式转载，不允许对文字进行裁剪。未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

 

评论

6 楼 lzy.je 2009-04-16  

jiangduxi 写道

你好： 我想请教下：关于Wapiti的使用；
我测试的网站有登陆，所以根据
python wapiti.py http://demo.testfire.net/ -c cookies.txt -x http://demo.testfire.net/bank/logout.aspx 
这种方法，有Cookies.txt文件但是在测试的时候

python wapiti.py http://192.168.123.34/login.jsp  -c cookies.txt
的时候出现
Wapiti-2.1.0 (wapiti.sourceforge.net)
No links or forms found in this pag
Make sure the url is correct.
望你抽时间看下。
谢谢

确认下login.jsp页里有登录form？

5 楼 jiangduxi 2009-04-16  

你好： 我想请教下：关于Wapiti的使用；
我测试的网站有登陆，所以根据
python wapiti.py http://demo.testfire.net/ -c cookies.txt -x http://demo.testfire.net/bank/logout.aspx 
这种方法，有Cookies.txt文件但是在测试的时候

python wapiti.py http://192.168.123.34/login.jsp  -c cookies.txt
的时候出现
Wapiti-2.1.0 (wapiti.sourceforge.net)
No links or forms found in this pag
Make sure the url is correct.
望你抽时间看下。
谢谢

4 楼 lzy.je 2009-03-17  

helloconan 写道

lzy.je 写道helloconan 写道您好，想向您请教一些关于ratproxy使用的问题：我的环境是Cygwin，在使用如下参数./ratproxy -v . -w test1.log -d google.com -XCl2efxiscmg -p 9090  启动ratproxy后，将IE代理设置为http://localhost:9090,发现无法通过IE访问www.google.com了。请问是怎么回事呢？谢谢！我这里的测试是可以的。当你访问 www.google.com 是，默认 google.com 会将页面转向到 www.google.cn。而 -d google.com 又限定了测试的 domain。我推测，你的问题应该与这有关。你可以尝试使用设置代理的浏览器打开 http://www.google.com/ncr 来访问 google.com 网站来开始测试。预祝顺利。非常感谢您的热情解答。问题已经解决。不过在测试的过程中，点击链接，经常会出现“页面无法访问”的现象，需要刷新或是再次点击链接才能进入相关页面。不知道您是否也遇到过类似问题？再次感谢您写的这么好技术文章，受益良多！

同样也谢谢你的支持！

我这里偶尔也会发生你所讲的情况，但发生概率很小。这可能与你所在网络环境和网站响应性能有关。

这里隐身一个问题。如果单单使用 ratproxy 往往很难达到比较高的覆盖率，这里的原因倒不是指 ratproxy 匹配算法而言的，而是由于它依赖手动 explor 过程来完成测试，因此往往会因为我们手工能难达到比较理想的功能/页面覆盖率。本文也提到了这点。

不过倒也有个可行的替代办法，就是可以将 ratproxy 作为其它具有 explore 功能的测试功能的代理来使用，如上面提到的 Nikto、Wapiti 都可以，这样可以使用它们的 explore 功能驱动 ratproxy 完成测试，并以此作为补充。

预祝好运。

3 楼 helloconan 2009-03-17  

lzy.je 写道

helloconan 写道
您好，想向您请教一些关于ratproxy使用的问题：我的环境是Cygwin，在使用如下参数./ratproxy -v . -w test1.log -d google.com -XCl2efxiscmg -p 9090  启动ratproxy后，将IE代理设置为http://localhost:9090,发现无法通过IE访问www.google.com了。请问是怎么回事呢？谢谢！


我这里的测试是可以的。

当你访问 www.google.com 是，默认 google.com 会将页面转向到 www.google.cn。而 -d google.com 又限定了测试的 domain。我推测，你的问题应该与这有关。

你可以尝试使用设置代理的浏览器打开 http://www.google.com/ncr 来访问 google.com 网站来开始测试。

预祝顺利。

非常感谢您的热情解答。问题已经解决。不过在测试的过程中，点击链接，经常会出现“页面无法访问”的现象，需要刷新或是再次点击链接才能进入相关页面。不知道您是否也遇到过类似问题？
再次感谢您写的这么好技术文章，受益良多！

2 楼 lzy.je 2009-03-16  

helloconan 写道

您好，想向您请教一些关于ratproxy使用的问题：我的环境是Cygwin，在使用如下参数./ratproxy -v . -w test1.log -d google.com -XCl2efxiscmg -p 9090  启动ratproxy后，将IE代理设置为http://localhost:9090,发现无法通过IE访问www.google.com了。请问是怎么回事呢？谢谢！

我这里的测试是可以的。

当你访问 www.google.com 是，默认 google.com 会将页面转向到 www.google.cn。而 -d google.com 又限定了测试的 domain。我推测，你的问题应该与这有关。

你可以尝试使用设置代理的浏览器打开 http://www.google.com/ncr 来访问 google.com 网站来开始测试。

预祝顺利。

1 楼 helloconan 2009-03-16  

您好，想向您请教一些关于ratproxy使用的问题：
我的环境是Cygwin，在使用如下参数
./ratproxy -v . -w test1.log -d google.com -XCl2efxiscmg -p 9090 
启动ratproxy后，将IE代理设置为http://localhost:9090,发现无法通过IE访问www.google.com了。请问是怎么回事呢？谢谢！