[译]w3af指南(二)

原文链接：http://resources.infosecinstitute.com/w3af-tutorial-2/

本文我们将继续学习如何使用w3af的discovery和audit插件来进行web漏洞扫描和相应的漏洞利用。同时我们将学习各种w3af使用的技术来发现这些漏洞。本文我们使用gui版本。

Web Security Dojo
进行测试w3af的时候，首先也是最重要的是要有一个测试环境以及测试工具。Web Security Dojo是一个有web漏洞的VM。在这些漏洞环境中有一个“w3af Test Environment”，这个就是用于w3af单元测试的环境。默认的Web Security Dojo安装了w3af控制台版本和gui版本。可以从这里下载http://sourceforge.net/projects/websecuritydojo/files/
下载之后，跳转到Applications–>Targets–>w3af Test Environment，可以看到如下画面：

注意：即使Web Security Dojo对于w3af测试十分有用，我也推荐使用BT5来进行测试。 Web Sec Dojo is的主要问题是它没有最新的w3af版本。
Audit Plugins
我们看看w3af测试环境中Audit部分。我们可以看到，页面基于基本漏洞分成不同种类。


如果我们转向Cross Site Script，我们可以看到有一些含有CSS漏洞的连接。

因此下一步是把url设定给w3af，并且进行XSS扫描。打开w3afGUI，左边可以看见我们可以选择的配置文件。

我们可以根据所需时间来选择任何配置文件。这些配置文件是为某些任务配置的含有特定的配置参数的文件。如果我们打开OWASP_TOP10，我们可以看见几个已经选中的Audit，Grep，以及Discovery插件。

我们将会使用一个Empty profile，因为我们系那个检查单个url的XSS漏洞。注意，这个例子不同我们通常使用w3af的场景。在现实环境中，我们将会选择一些特定的discovery插件来查找不同的url注入点，auth插件来自动登录表单，以及预先爬虫，grep插件来查找响应中的有用的信息，以及audit插件来扫描注入点中的漏洞。
在target域中输入url，从audit插件中选择xss插件

然后点击start开始扫描给定的url。从输出可以看见发现的XSS漏洞。

如果你想知道发生了什么，转到Result标签。点击左边的xss，在右边，你可以看到关于漏洞是如何发现的描述。在右下方，同时可以看见导致识别漏洞的请求和应答。通过查看请求/应答可以帮我们了解究竟发生了什么。

w3af发送javascript字符串到url中的每一个参数，然后检查应答中的这些字符串。对于存储性XSS，w3af记录注入的字符串，然后再次请求url来查找相应的字符串。如果找到，那么就是XSS漏洞。
现在我们使用OS commanding漏洞来获得系统上的一个shell。在w3af测试环境中的OS commanding部分，选择一个url，用它来设定w3af的target。在audit插件部分，选择OS commanding插件。

然后点击start开始扫描，从输出中可以看到，w3af识别出OS commanding漏洞。

w3af支持检查simple和blind OS commanding漏洞。在simpleOScommanding中，它发送简单的命令到每一个参数然后检查相应中那个命令的输出。在blind OS commanding时，命令的相应不会出现在输出中，它使用时间延迟来识别漏洞是否存在。例如如果它发送延迟数秒的命令，并且我们发现了延迟，那么我们可以说存在blind OS commanding漏洞。
在Result部分，我们可以看到导致延迟漏洞的请求和应答。

w3af同时允许我们利用漏洞。如果我们转到Exploit部分，我们可以看见Vulnerabilities部分的已识别漏洞。如果我们点击它，我们可以看见Exploit部分的osCommandignShell变黑。这指示漏洞可以通过osCommandignShell插件被使用。右击osCommandignShell，点击 Exploit ALL vulns.

如果漏洞成功利用，我们可以获得目标机的一个shell。我们可以从右边看到shell列表。注意，每个漏洞都获得一个shell是不可能的。

双击shell即可使用

类似地，我们使用一个文件上传漏洞来获得一个shell。设定w3af的目标，点击audit中的fileUpload插件。

确保检查fileUpload插件的extensions选项。某些场合下，web只允许某些特定的后缀。

点击start，我们可以看到w3af识别出一个文件上传漏洞

点击Result标签，可以看见w3af试图上传一个w3af_dt4LqT.html文件。它通过在uplaodfile参数中发送一个文件对象，然后在一些通常的文件夹中查找这些文件，如果找到文件，那么就定义为文件上传漏洞。由于大多数web程序基于扩展名过滤文件，所以为了绕过检查，w3af有一些通用扩展名模板，这些模板有一个合法的扩展名但是有一个可以被替换为代码的section。这些模板位于kali的/usr/share/w3af/plugins/audit/fileUpload下图为w3af中不同扩展名文件模板

如果我们使用Kate打开这些文件，我们可以看到他们的内容。下图可以看到，template.png有一连串的A在comment section。他们可以被替换为脚本，例如php。

有了这些基础，现在利用fileUploadShell plugin来利用漏洞。可以通过右击他们，选中Configure the plugin来设置参数。
下图所示，漏洞利用成功

类似地，可以进行许多其他的测试，例如Local File Inclusion，Remote File Inclusion， SQL Injection等。

Discovery插件
在之前的测试中，我们都是用给定的一个有漏洞的url作为目标。然而，现实生活中的漏洞扫描不是这样的。web扫描器应该有能力自动识别不同的url。这些url将会用于不同的注入点。
最流行的两个discovery插件是webSpider和SpiderMan。基本上，webSpider用于给定一个url，从相应中提取连接或form。使用这些连接，它爬虫寻找更多的连接(可能的注入点)。另一个插件SpiderMan对于Javascript/Flash的网站是一个非常有用的插件，基本上，如果web使用Javascript等技术，web爬虫很难抓取连接。实际上，大多数的爬虫完全忽略Javascript。因为他们没法知道J这些avascript的作用。大多数的web爬虫仅仅抓取注入连接，表单等这些静态信息。当webSpider发现一个login表单时，如果使用了auth插件，那么它将会自动插入相关信息，并且继续爬虫。
当web应用程序使用Javascript或Flash时，应该使用spiderMan插件。spiderMan启动一个代理，然后user应该通过代理点击链接。根据user的点击，spiderMan插件能够识别不同的注入点然后发送到audit插件进行漏洞扫描。spiderMan的另一个重要特点是它能保存cookie，并且重复使用他们。如果我们使用spiderMan代理并且login一个表单并且收到一个cookie。spiderMan插件将会把cookie发送到其他从插件，从而可以爬虫其他的应用。
来试试webSpider插件。设定url，确保webSpider是discovery插件中唯一使用的一个插件，点击start

从log标签里面可以看到webSpider已经识别出一些新的url。下图给出一些详细信息。

随着扫描的进行，转到Result标签，点击链接。如下图所示，w3af生成了web应用的图形结构。在左手边，点击+号，显示每个分支的详细信息。

来做一个关于webSpider的另一个实验。把target设为dvwa的login页面，选择webSpider插件，开始运行。我们得到如下的结果。

然而这个是不正确的。因为DVWA有一系列的漏洞文件夹。但是webSpider没法爬虫他们，因为需要输入登录表单。

这时spiderMan插件登场。SpiderMan和webSpider配合使用是一个很好的建议。这是由于SiderMan可以帮我们达到webSpider去不了的地址，而webSpider爬虫可以继续从这些地方爬虫。
现在我们同时使用Siderman和webSpider插件。确保设置监听地址和端口。

然后配置浏览器使用SpiderMan作为代理。如果我们需要结束SpiderMan插件，我们需要浏览一个如下图所示的特殊url

现在配置浏览器使用SpiderMan作为代理。

然后登录dvwa应用(admin/password),开始浏览不用的url。可以看到这些请求被spiderMan插件记录

结束spiderMan插件，跳到下图地址

然后SpiderMan插件将会终止，所有的信息都会传递到其他的不同插件。下图所示，webSpider利用spiderMan提供的信息发现了一些新的url

如果我们看看应用结构，我们看到正确的文件结构以及识别出的漏洞