孙 歆，张 闻

（浙江省电力试验研究院，杭州 310014）

应用系统的安全性越来越受到人们的关注，利用B/S（浏览器/服务器，Browser/Server）应用系统的漏洞进行入侵、渗透已经成为互联网安全隐患之一。企业内部的管理信息系统大部分采用B/S架构，如何保障系统安全和企业核心数据不受破坏，已成为企业信息部门的焦点问题。应用系统在上线前进行安全性测试，可以验证其是否存在安全缺陷和漏洞，是企业信息安全管控的重要手段。很多厂商或企业内部QA部门虽能提供安全性测试服务，但安全性测试对技能要求较高，也缺乏可参照的标准和规程。本文分析了B/S结构应用系统存在的主要安全问题并介绍了测试方法，可为企业安全性测试提供指导。

1 B/S结构特点

B/S是当前主流的应用系统结构，具有客户层、应用层、数据层等多层结构，用户可通过浏览器访问应用，实现瘦客户端。与传统的C/S（客户端/服务器，Client/Server）结构相比，B/S结构更加灵活高效，特别是Web2.0技术兴起之后，其在客户端的表现丝毫不逊色于C/S。但与此同时，B/S应用系统存在更多的安全隐患，原因是：B/S结构系统只要有浏览器就可访问，用户难以控制；HTTP（S）协议为无连接协议，较难进行会话跟踪；AJAX技术使B/S系统由“瘦”转“胖”，交互更多样化、更加隐蔽；B/S系统开发门槛较低，不专业的开发者可能引起系统安全问题等。

2 测试方法与手段

本文介绍的安全性测试属于软件测试中的黑盒测试，除了向用户获取部分系统相关信息和资料，如系统采用的技术、系统构架、所使用的中间件、数据库和操作系统等，测试人员并不知道系统的工作原理和细节。安全性测试手段可以分为工具测试和手工测试两种，工具测试指利用自动化测试工具帮助测试人员完成信息搜集或常见安全漏洞检测工作，提高测试效率和准确性，较为常用的商业测试工具有IBM AppScan和A-cunetix Web Vulnerability Scanner。手工测试指安全测试团队凭借个人经验，通过测试向量的输入和相应的输出判断系统是否存在安全问题，并进行一定程度的渗透测试，确定安全问题的风险等级。一般来说，安全测试应以人工测试的结果为主要依据，工具测试的结果只能作为参考，测试人员应对其进行验证和确认，不可盲从。

3 安全性测试技术

对B/S应用系统漏洞的检测方法和渗透技术，目前还没有相应的测试标准，但有一些安全组织团体编写了安全性测试的指导文档，比较有代表性的是OWASP组织编写的OWASP Testing Guide，也有书籍和论文阐述了关于B/S系统的安全测试以及漏洞检测方法。本文参考了上述方法，结合本企业应用系统的实际情况，着重介绍SQL注入、跨站脚本、上传漏洞等几种常见应用系统漏洞的安全性测试方法。

3.1 SQL注入

SQL注入是最常见的B/S应用系统漏洞，危害极大。该漏洞是由于对输入参数过滤不严，导致任意语句可注入到程序原有的SQL语句，执行数据库权限范围内的任意SQL语句。图1为某新闻内容显示页面存在SQL注入的语句。

图1 典型的SQL注入漏洞代码

由于没有对参数id进行过滤而直接将其拼接到SQL语句中执行，攻击者可以通过id参数注入自己的SQL语句。比如当id＝1;drop table author;时，SQL语句select id,news,time,author from article where id＝1;drop table author;被执行，author表将被删除。

绝大多数应用系统都可用安全测试工具检测SQL注入漏洞，但为了确保测试结果，建议以手动测试为主，工具检测为辅。测试是否存在SQL注入就是要确认参数是否被带入SQL语句执行，注入的参数类型有数字型、字符型和搜索型3种。可利用经典法依次对链接中的参数进行测试，在参数中注入SQL语句，检查语句是否被执行。假设被测链接为article.php?id＝1，其测试向量如表1所示。

表1 3种参数类型SQL注入漏洞的测试方法

测试实际上就是输入布尔逻辑，根据回显判断或推理想要的数据。 表 1 中的“1＝1、 1＝2”等可以用其他布尔逻辑代替。数字型和字符型注入则多出现在用于检索的id值，比如文献的id，搜索型注入则多出现在搜索关键字段中。各种类型的参数都有可能出现注入漏洞，包括GET，POST，HTTP头、COOKIE等，前两者较为常见，后两者虽出现较少，但容易被程序员忽视。检测HTTP头和COOKIE注入或者AJAX程序时，需要用到代理工具截获并篡改HTTP数据包进行测试，常用的代理工具有Webscarab和TamperIE。

3.2 跨站脚本

跨站脚本漏洞也是较常见的漏洞，是由于对输入参数验证不严导致客户端可执行任意构造的客户端脚本，实质上属于一种代码注入漏洞。典型的存在跨站漏洞的代码如图2所示。

图2 典型的跨站漏洞代码

图2中的代码没有对$keyword变量进行过滤，直接输出到表现层，用户可以构造恶意客户端代码，进行跨站攻击。例如可以构造如下代码盗取用户 cookie：＜script＞document.write （"＜img src ＝'http∶//evilsite.com/getCookies?c ＝ "+document.cookie+"'＞"）＜/script＞。 跨站脚本漏洞会对存在漏洞页面的客户端产生巨大危害，造成挂马、信息泄露等严重安全问题。随着Web2.0技术的广泛应用，跨站漏洞危害将越来越大。

跨站脚本漏洞可以用工具检测，但可能输入垃圾数据。手工测试时一般对请求参数注入＜script＞alert（/xss/）＜/script＞等跨站测试向量， 查看该Javascript代码是否反馈到了客户端。如果系统未经处理直接反馈代码，将弹出一个对话框。与测试不同，恶意攻击者通常是将代码改为盗取cookie、下载木马等操作。测试中应考虑以下几种情况：

（1）＞＜script＞window.alert（"xss"）＜/script＞， 前面添加尖括号闭合之前的HTML标签，使得代码生效。

（2）＜script＞alert[String.fromCharCode（88， 115，115,84,101,115,116）]， 利用 ASCII码转换绕过引号过滤。

（3）利用＜sCripT＞或＜scr%00ipt＞等混淆手段绕过特征字符串过滤。

（4）＜img src＝javascript∶alert（'xss'）；＞， 使用img或iframe等标签绕过script特征字符串。

（5）＜div style＝"width∶expression（alert（'xss'））；"＞，绕过script和javascript特征字符串。

3.3 上传漏洞

上传漏洞是由于程序没有对上传的文件进行类型判断，从而造成恶意文件上传至服务器，攻击者可能因此获得应用系统的webshell。当系统存在上传文件模块时，测试人员必须注意。

上传漏洞检测比较复杂，只能靠人工测试。一般是上传各种类型文件并判断上传是否成功，所以测试过程中会引入垃圾数据。如果上传成功，还应判断文件上传后是否可执行，因为某些程序会将上传文件改名或隐藏文件路径，使得文件无法运行。常用的上传漏洞测试向量如下：

（1）直接上传 asp，php，jsp， asa甚至 exe等脚本文件或可执行文件，检查系统是否对文件类型进行过滤。

（2）文件后缀大小写混编（如 AsP， pHp）， 或后缀嵌套（如asaspp），绕过后缀过滤。

（3）IIS，Apache等服务器软件的某些版本存在文件名解析漏洞，如利用IIS路径解析漏洞上传文件名为test.asp；1.jpg的脚本。

（4）有些程序通过 HTTP头的Content-Type参数判断文件类型，则可利用代理工具修改该参数再上传，绕过文件类型过滤机制。

（5）某些系统采用第三方文字编辑插件，如FCKEditor，eWebEditor等，这些插件的多个版本存在上传漏洞，可依据相关漏洞测试方法测试。

3.4 目录遍历

目录遍历是较为常见的Web应用漏洞，是由于程序没有对父路径进行有效限制，造成攻击者可获取主机任意文件资源。某些系统利用参数传递文件路径，读取目标文件后再输出，进行文件下载或图片显示，此时可能存在遍历漏洞。典型的问题代码如图3所示。

图3 典型的目录遍历漏洞代码

图3中的代码没有对path参数进行验证，如果用户将path改为../../../etc/passwd，将会直接下载Linux系统的passwd文件。Windows系统也可用c∶/windows/boot.ini进行测试。

测试目录遍历漏洞应输入各种形式的父路径，检查是否可以突破应用根目录限制，访问操作系统文件或敏感文件，如数据库连接文件、密码文件等。以获取linux的passwd文件为例，典型的测试向量如下：

（1）利用 URL 编码： %2e%2e%2f%2e%2e%2fetc/passwd。

（2）利用不同路径分隔符：....etcpasswd。

（3）利用 UTF-8 编码：%c0%ae%c0%ae/%c0%ae%c0%ae/etc/passwd。

3.5 权限绕过

权限绕过漏洞十分普遍，通常由程序员权限控制机制存在安全缺陷引起，如只在登陆时进行权限控制，而没有对每个模块的权限控制节点进行控制，导致用户直接输入URL即可访问不具备权限的资源。这种情况通常是程序员疏忽大意或缺乏良好的编程习惯造成的，应在需求分析和设计阶段对安全需求进行规范。

权限绕过测试可以利用管理员账号进入管理模块，搜集管理子模块的URL，再用一般用户账号登陆，直接输入这些URL，验证是否可以进入并进行相应操作，如果URL数量庞大，可适当抽取部分进行验证。可考虑3种情况进行测试：

（1）匿名用户是否可访问系统资源。

（2）低权限用户是否可访问高权限资源。

（3）当系统有工作流模块时，测试是否可以查看和操作非权限内流程节点的内容。

有些系统利用GET，POST，COOKIE等可被用户控制的参数进行权限判断，比如某些程序通过COOKIE参数isAdmin判断当前用户是否为管理员，而COOKIE参数可以在客户端轻易被篡改，从而造成漏洞。测试这种情况一般通过代理工具获取传递的参数，由参数名推测该参数的用途，并在篡改参数后查看是否获取了相关权限。

3.6 代码注入

代码注入是由于没有对输入参数进行严格审核导致参数中的代码被服务器执行，可由多种途径引起，比较典型的是脚本文件包含和命令执行。脚本包含多发生于php程序，php脚本可允许通过include函数包含另一个脚本并执行，而当被包含的脚本路径来自于用户输入的参数，则有可能出现漏洞。当php.ini中的allow_url_fopen和allow_url_include都配置为On时，甚至可以包含执行外部文件，形成远程包含漏洞，其危害更为严重。典型的脚本包含漏洞代码如图4所示。

图4 典型的脚本包含漏洞代码

图4代码中，需要包含connect.php文件进行数据库连接，但如将path改为其他恶意文件路径，do.php将执行该恶意文件。当然，利用本地包含漏洞需要事先在服务器文件中注入恶意代码，而远程包含漏洞的利用则更为便利。

该漏洞无法利用工具测试，只能凭经验人工判断和测试。测试人员可从参数名推测是否用于文件包含路径，并将参数改为自定义的脚本路径，检查是否执行了自定义脚本。对于本地包含，可将恶意代码写入URL，将其注入系统日志文件中，再包含该日志文件以达到利用目的。而远程包含则可在其他站点上传脚本进行包含测试。

4 结语

本文介绍了B/S结构应用系统上线前的安全性测试方法以及实施流程，根据电力企业实际情况结合安全组织的测试方法综合得出，已在浙江电力企业得到实际运用，并取得了良好的效果，为应用系统上线后的安全稳定运行提供了保障。

[1] 中国信息安全测评中心.Web系统安全和渗透性测试基础[M].北京：航空工业出版社，2009.

[2] 刘述景.基于风险评估的渗透测试方案的研究与实施[D].北京邮电大学，2009.

[3] 杨广华，齐璇，施寅生.基于威胁模型的软件安全性测试[J].计算机安全，2010（02）∶11-13.

[4] 施寅生，邓世伟，谷天阳.软件安全性测试方法与工具[J].计算机工程与设计，2008，29（01）∶27-30.

[5] 刘文晋.远程渗透测试中的SQL注入攻击技术研究[D].北京交通大学，2009.

[6] MICHAEL CROSS，STEVEN KAPINOS.Web Application Vulnerabilities Detect，Exploit，Prevent[M].Syngress，2007.

[7] JUSTIN CLARKE，SQL Injection Attacks and Defense[M].Syngress，2009.

[8] JEREMIAH GROSSMAN，XSS Attacks Exploits and Defense[M].Syngress，2007.

[9] ANURAG AGARWWAL，OWASP Testing Guide[S].OWASP，2008.