AppScan 在测试阶段，向登陆页面发送请求，我们假定 AppScan 将 Username 和 Password 均设置为"'"，服务器返回错误信息"Syntax error: Encountered "\'" at line 1, column 63. "。由于在 Response 中并未包含 SQL 异常信息，所以 AppScan 无法判断是否存在 SQL 注入漏洞。
图 3. 页面显示的错误信息
但是如果我们写一个测试代码，可得知当我们输入单引号时，服务器端确实报了 SQL 语法错误信息，如图 4 所示。Glass Box 安装在服务器端，当它发现请求值为 g'[number]b，且包含了单引号的信息请求时，如果出现 SQL 异常错误信息，那么 Glass Box 便判断出该页面存在 SQL 注入漏洞。
图 4.SQL 异常信息
3. 在生成报告阶段，可提供代码级的调试信息和修复建议
我们以 AltoroJ 项目的登陆页面为例，对比一下使用黑盒测试和使用 Glass Box 发现的漏洞的修复过程。AppScan 通过分别在 Username 和 Password 输入框中输入"4ppSc4n"和"A' OR '7659'='7659"，发现了该页面存在 SQL 注入漏洞（AppScan 中称之为"SQL 注入的认证旁路"）。我们根据"请求 / 响应"信息可以发现，该漏洞存在于 doLogin 这个 servlet 中，如图 5 所示。
图 5.AppScan “请求 / 响应”
我们根据 WEB-IBF/web.xml 中的信息进一步判断出漏洞存在于 LoginServlet.java 文件中。
清单 1.web.xml 文件中的 LoginServlet 配置
<servlet-mapping> <servlet-name>LoginServlet</servlet-name> <url-pattern>/doLogin</url-pattern> </servlet-mapping> <servlet> <description> </description> <display-name> LoginServlet</display-name> <servlet-name>LoginServlet</servlet-name> <servlet-class> com.ibm.rational.appscan.altoromutual.servlet.LoginServlet </servlet-class> </servlet> |
打开 LoginServlet.java 文件，我们依然很难一眼就判断出漏洞的准确位置，需要对代码做进一步的分析。经过分析，找到存在漏洞的语句：
清单 2. LoginServlet.java 文件中存在漏洞的语句
if (!DBUtil.isValidUser(username, password))
然后，我们再找到 DBUtil 类中的 isValidUser 函数，最终找到了存在漏洞的 sql 语句：
清单 3. 存在漏洞的 SQL 语句
ResultSet resultSet = statement.executeQuery("SELECT COUNT(*)FROM PEOPLE WHERE USER_ID
= '"+ user +"' AND PASSWORD='" + password + "'");
/* BAD - user input should always be sanitized */
虽然有时候对于经验丰富的开发者来说，对于逻辑简单程序能够直接定位到某个 java 文件，省去一些步骤，但是大部分情况下，我们都需要一步步的去分析。而对于 Glass Box 发现的漏洞，则可以大大节省开发人员定位代码漏洞的时间。Glass Box 可报告出漏洞的具体位置信息，如方法名、类名、文件名和行号等信息；并可报告运行时信息。如图 6 所示。
图 6. Glass Box 问题信息
总结
黑盒测试技术由于无法获取应用程序的内部信息，导致扫描覆盖率偏低，且无法提供详细的调试信息；而白盒测试技术的代价过于高昂，需要大量的人工成本，且误报率较高。而 Glass Box 是有别于传统黑盒测试和白盒测试的一种混合测试技术，将有效解决这一难题，为客户创造更好的价值。
