技术领域
[0001] 本
发明涉及Web应用安全性测试中的跨站点伪造请求(Cross-Site Request Forgery，CSRF)的动态检测，特别涉及通过分析HTTP参数和SQL语句操作数之间的对应关系来伪造HTTP请求，动态检测Web应用中存在的CSRF漏洞。
背景技术
[0002] Web应用中的某些操作需要一定的权限，这种权限一般和用户的账号关联。用户执行这些操作时，Web应用验证用户账户是否拥有相应的权限。显然不能要求用户每执行一次操作都输入账户来进行验证。现通用的做法是：用户登录之后，由用户的浏览器保存其账户信息，用户继续执行操作时，用保存的信息验证用户的权限。
[0003] Web应用是基于HTTP协议的，然而HTTP协议是一种无状态协议，协议本身无法保存用户的账户信息，故通常用浏览器以COOKIE的形式保存用户的账户信息。在COOKIE失效之前，所有从该浏览器发出的请求都将把这些COOKIE发送给对应的Web应用，即使该请求不是用户自主发送的。
[0004] 要获取他人的账户信息比较困难，但是要了解Web应用的特性相对容易，特别是开源的和公用的Web应用，如论坛、网上
银行等。攻击者很容易了解Web应用收到何种请求会执行何种操作，如网上银行收到何种请求将试图执行转账操作。故攻击者可根据Web应用的特性，事先伪造一个请求；估计受害者已经登录获得相应权限时，通过某种方式让受害者的浏览器执行该请求达到攻击目的，这就是跨站点伪造请求(CSRF)攻击。
[0005] 跨站点伪造请求是当今Web应用面临的十大安全威胁之一。现在研究者们关注的大都是如何防范CSRF攻击，常用的防范方法有：(1)所有重要的HTTP请求都附加难以猜测的token，收到请求时验证token；(2)通过HTTP Refer验证发出请求的前一页面是不是期望的页面；(3)通过Ajax来发送请求，在请求中添加验证信息。这些方法或者严重影响Web应用的性能，或者难于实现，给使用者带来较大不变。
发明内容
[0006] 本发明所要解决的技术问题是针对如何动态检测Web应用中的CSRF漏洞，而提供一种跨站点伪造请求的动态检测方法，该方法实现以较少的代价、快速、准确的发现Web应用中的CSRF漏洞。
[0007] 为实现发明上述目的，本发明采用以下步骤：
[0008] 1)收集HTTP请求信息；
[0009] 2)根据收集到的信息，检测每个请求是否为CSRF嫌疑请求，具体过程为：
[0010] 首先根据收集到的HTTP请求获取GET参数和POST参数集合；然后获取HTTP请求对应的
修改型SQL语句操作数集合；最后分析HTTP参数和SQL语句操作数之间的关联；如果至少存在一个HTTP参数的值和某个操作数的值相等，那么该请求即为嫌疑请求，和操作数值相等的HTTP参数为嫌疑参数；
[0011] 3)针对每个CSRF嫌疑请求，找出其所包含的全部嫌疑参数，为每个嫌疑参数生成一个伪造参数，再利用每个伪造参数生成一个对应的伪造请求，而每一个伪造请求再生成一个测试
用例；其中生成伪造参数的过程是：针对嫌疑请求Rs，首先找出Rs的嫌疑参数集合，为每个嫌疑参数生成一个伪造参数，伪造参数的name和嫌疑参数的name相同，伪造参数的value按三种情况处理：整型数，浮点型数和字符串型；构造伪造参数value的对应规则如下：
[0012] 规则1.如果value为一个整型数，分两种情况处理：
[0013] a)如果value为一个大于1的整数，则value减1；
[0014] b)如果value为一个小于或者等于1的整数，则value加1；
[0015] 规则2.如果value为浮点型数；则将value最后一位加1再对10取余；
[0016] 规则3.如果value为字符串型，分三种情况处理：
[0017] a)如果value最后两个字符不相同，则把这两个字符互换
位置；
[0018] b)如果value最后两个字符相同，则比较倒数第一个和倒数第三个，如果也相同，则继续往前找，直到找到一个和最后一个字符不相同的字符为止；再把它们交换位置；
[0019] c)如果value只包含一个字符或者所有字符都相同，且最后一个字符不是‘a’，则直接把最后一个字符用‘a’替换；
[0020] 如果value只包含一个字符或者所有字符都相同，且最后一个字符是‘a’，则直接把最后一个字符用‘b’替换；
[0021] 根据伪造请求生成测试用例分两种情况：
[0022] 情况1.如果请求方法为GET，此时用一个图像IMG标签来表示该请求；请求的GET参数附加在原URL之后形成新的URL；该URL设置为IMG标签的源SRC属性；在该IMG标签之外添加HTML文档
声明之后，保存为一个静态文件，这个静态文件即测试用例；
[0023] 情况2.如果请求方法为POST，此时用一个表单FORM标签来表示该请求；请求的GET参数附加在原URL之后形成新的URL；该URL设置为FORM标签的动作ACTION属性；请求的POST参数作为隐藏域放在FORM标签中；在该FORM标签之外添加HTML文档声明之后，保存为一个静态文件，这个静态文件即测试用例；
[0024] 4)在生成嫌疑请求的环境重现时，执行每一个步骤3)生成的测试用例所对应的伪造请求，执行过程中，收集伪造请求的执行信息；
[0025] 5)根据嫌疑请求、嫌疑请求的执行信息、伪造请求和伪造请求的执行信息，检测伪造请求是否发现了Web应用中的CSRF漏洞，并形成报告，帮助Web应用开发者修复漏洞。
[0026] 上述步骤1)的具体过程是：设计一个HTTP信息收集模
块，并部署在待测试的Web应用中；该HTTP信息收集模块分成两个部分，其一是请求信息收集模块，收集HTTP请求中的信息为：(1)请求的URL、时间和请求方法，(2)GET数据和POST数据；其二是SQL语句收集函数，收集HTTP请求中的信息为(3)动态生成的SQL语句。
[0027] 上述步骤4)的测试用例执行过程为：首先用浏览器打开嫌疑请求所在的Web应用，重现生成嫌疑请求的环境条件；然后用同一浏览器逐个执行嫌疑请求的测试用例，即打开对应的静态HTML文件；最后运用HTTP信息收集模块收集测试用例的执行信息。
[0028] 上述步骤5)中CSRF漏洞的检测过程为：首先提取每一个测试用例的执行信息，该信息对应一个伪造请求Rf，找出伪造请求Rf所对应的嫌疑请求Rs、Rf所有的嫌疑参数、Rf对应的伪造参数、以及伪造参数对应的嫌疑参数；如果Rf伪造参数的值成为了Rf某个修改型SQL语句的操作数，且其伪造参数的值所在的SQL语句和嫌疑参数的值所在SQL语句相似，即这两个SQL语句除嫌疑参数值和自动变更的参数值不同外，其它都是相同的；且这两个值在各自SQL语句中的位置相同，那么通过这个请求就发现了Web应用中的CSRF漏洞。
[0029] 跨站点伪造请求CSRF已经成为Web应用安全的重要威胁之一。目前尚缺乏行之有效的CSRF漏洞防范和检测方法。文发明方法通过记录特权操作的HTTP请求信息和对应的修改型SQL语句，基于操作数比对查找HTTP请求的CSRF嫌疑参数，再根据嫌疑参数逐一生成测试用例。采用动态测试的方法检测CSRF漏洞，可以用较少的代价，快速而准确的发现Web应用中存在的CSRF漏洞。其中唯一可能影响Web应用性能的数据记录和采集操作同Web应用的日志操作类似，实验表明其影响可以忽略。采用本发明方法对多个实际应用的Web
网站实施测试，测试结果表明本发明方法具有较高的测试效率和准确性。特别对一些在防范CSRF方面做了很多工作的网站，本发明方法仍能够以较高的效率发现其中的CSRF漏洞。
附图说明
[0031] 图1是跨站点伪造请求的动态检测方法
框架图，
[0032] 图2是HTTP请求信息收集模块的
流程图，
[0033] 图3是CSRF嫌疑请求检测模块的流程图，
[0034] 图4是获取一个SQL语句的操作数集合的流程图，
[0035] 图5是测试用例生成模块的流程图，
[0036] 图6是测试用例执行模块的流程图，
[0037] 图7是CSRF漏洞检测模块的流程图。
具体实施方式
[0038] 如图1所示，本发明由HTTP请求信息收集模块，CSRF嫌疑请求检测模块，测试用例生成模块，测试用例执行模块和CSRF漏洞检测模块五个模块按照“流”的体系构成。首先收集的HTTP请求信息为下一步分析所用；根据收集到的信息，可以分析一个请求是否为CSRF嫌疑请求，以及请求中哪些参数可能成为攻击时的利用对象，这些参数被称为嫌疑参数；利用嫌疑参数可为每个嫌疑请求生成若干伪造请求，进而生成测试用例；待生成嫌疑请求的条件满足时(用户浏览器获得了必要的认证信息)，执行测试用例；根据嫌疑请求、嫌疑请求的执行信息以及伪造请求和伪造请求的执行信息，可分析出是否发现了Web应用中的CSRF漏洞，最后给出详细的报告信息以便开发者修复漏洞。
[0039] 1、HTTP请求信息收集
[0040] 如图2所示，为动态收集HTTP请求信息，本发明中设计了一个信息收集模块部署在待测试的Web应用中。对每个HTTP请求，依次收集以下信息：(1)请求的基本信息，包括请求的URL、时间、以及请求方法(GET或者POST)；(2)GET数据和POST数据；(3)动态生成的SQL语句。
[0041] Web应用普遍拥有以下两个特点：其一Web应用中存在一个全局模块，用来完成Web应用的基本配置，如
数据库连接。所有HTTP请求处理模块都先加载该模块，然后执行其它操作。其二Web应用中存在一个数据库操作模块，所有的数据库操作都由该模块来完成。为收集信息(1)和(2)，只需在全局文件中加入信息收集模块，并调用其中的信息收集函数；为收集信息(3)，只需在数据库操作模块中加入SQL语句收集函数(包含在信息收集模块中)，让SQL语句在执行之前被收集起来，这样就可以完成对所有HTTP请求的信息的收集。
[0042] 如果Web应用不具备上述两个特点，为收集信息(1)和(2)，必须在所有HTTP请求处理模块的开始出加载信息收集模块，并调用信息收集函数；为收集信息(3)，必须在所有SQL语句执行之前，调用SQL语句收集函数。
[0043] GET数据和POST数据都是以的形式存在，如果name不变但是value是可变的，则称其为GET参数和POST参数，本发明统称它们为HTTP参数。
[0044] 2、CSRF嫌疑请求检测
[0045] 如果一个请求可以被攻击者所利用，使Web应用遭受CSRF攻击，那么该请求是CSRF请求。
[0046] 该模块是本发明独创点之一，主要功能有：(1)判断一个HTTP请求R是否为CSRF嫌疑请求；(2)如果R为嫌疑请求则找出R的所有嫌疑参数。
[0047] 如图3所示，R默认为非嫌疑请求，根据HTTP请求信息收集模块收集到的信息，取出R的GET参数和(或)POST参数构成集合gp_set；取出R中所有的修改型SQL语句。运用图4所示方法，可得到这些SQL语句的操作数集合operand_set。
[0048] 遍历gp_set中的参数p，如果p的值和operand_set中的任意一个操作数op的值相等，那么HTTP参数p就是一个嫌疑参数。只要请求R中至少存在一个嫌疑参数，那么R就是一个CSRF嫌疑请求。因为在该请求中，攻击者可能通过伪造参数的值修改后端数据库。该阶段处理后的输出为：(1)R是否为一个嫌疑请求；(2)如果是，R中嫌疑参数的集合。
[0049] 本发明把SQL语句分为两类：(1)修改型SQL语句，如插入(insert)、修改(update)、和删除(delete)语句，(2)查询型语句，即查询语句(select)。因为查询型语句不会修改后端数据库状态，故不会被CSRF攻击所利用。如图4所示，在2.1.1步，输入一个修改型SQL语句，逐个读取语句中的单词，如果一个单词为运算符的运算对象，则该单词为操作数，故把其加入到SQL语句的操作数集合中。成批输入修改型SQL语句时，只需对这些语句逐个扫描即可找出它们的所有操作数以构成operand_set。
[0050] 3、测试用例生成
[0051] 一个CSRF嫌疑请求，需要进一步证实才能确定其是否为真正的CSRF请求。利用CSRF嫌疑请求可生成若干伪造请求，进而形成测试用例。通过执行测试用例可证实一个CSRF嫌疑请求是否为真正的CSRF请求。
[0052] 本模块是本发明的另一个独创点，如图5所示，输入为一个CSRF嫌疑请求Rs，输出为Rs对应的测试用例集。输入Rs可取到其所有嫌疑参数(由CSRF嫌疑请求检测模块输出)构成一个集合sp_set。对每一个嫌疑参数ps生成一个与之对应的伪造参数pf，pf的name和ps的name一致；pf的value生成遵循一个原则：对ps的value做改变(伪造)，且只做尽可能小的改变。数据库中的数据大致可分为两类：字符串型和数值型；其中数值型又主要包括整型和浮点型。鉴于整型数和浮点型数的区别较大，故本发明分三种情况来生成伪造value，具体生成规则如下：
[0053] 规则1.如果ps的value只包含数字且符合整数书写规则，则其value为一个整型数，分两种情况处理：
[0054] a)如果ps的value为一个大于1的整数，则pf的value为ps的value减1；
[0055] b)如果ps的value为一个小于或者等于1整数，则pf的value为ps的value加1；
[0056] 规则2.如果ps的value只包含数字和小数点且符合浮点数书写规则，则其value为浮点型数。此时将ps的value最后一位加1再对10取余，并把新的浮点型value作为pf的value。
[0057] 规则3.如果不是以上两种情况，本发明把ps的value视为字符串型。在伪造新字符串时，采用以下方法：
[0058] a)如果value最后两个字符不相同，则把这两个字符互换位置，生成新的字符串；
[0059] b)如果value最后两个字符相同，则比较倒数第一个和倒数第三个，如果也相同，[0060] 则继续往前找，直到找到一个和最后一个字符不相同的字符为止；再把它们交换位置生成新的字符串；
[0061] c)如果value只包含一个字符或者所有字符都相同，则直接把最后一个字符用‘a’(若最后一个字符不是‘a’)或者‘b’(若最后一个字符是‘a’)替换。
[0062] 把伪造的新字符串作为pf的value。
[0063] 遍历sp_set后，可得到Rs的伪造参数集合fp_set。对fp_set中的每一个伪造参数pf，本发明生成一个伪造请求Rf，Rf的URL(不包含后面的GET参数)、请求方法和Rs保持一致。本发明首先按照
选定伪造参数pf生成一个GET参数赋给Rf，再把Rs中除伪造参数以外其它的GET参数和POST参数拷贝给Rf。
[0064] 接下来根据Rf生成测试用例，分两种情况：
[0065] 情况1.如果Rf对应的请求方法为GET，则Rf只有GET参数。此时本发明用一个图像(IMG)标签来表示该请求。Rf的参数以GET参数的形式附加在Rf的URL之后，形成新的URL，并把该URL设置为IMG标签的源(SRC)属性。在该IMG标签之外添加HTML文档声明之后，保存为一个静态文件，这个静态文件即测试用例。
[0066] 情况2.如果Rf对应的请求方法为POST，则Rf会同时拥有GET参数和POST参数。此时本发明用一个表单(FORM)标签表示该请求。Rf的GET参数附加在Rf的URL之后，形成的新URL，并把该URL设置为FORM标签的动作(ACTION)属性；Rf的POST参数形成为隐藏域()，放在FORM标签之中。在FORM标签之外添加HTML文档声明之后，保存为一个静态文件，这个静态文件即测试用例。
[0067] 遍历fp_set中的所有参数，分别生成对应的伪造请求Rf后，就可得到针对嫌疑请求Rs的测试用例集tc_set。
[0068] 4、测试用例执行
[0069] 得到嫌疑请求Rs的测试用例集tc_set后，就可以展开测试了。如图6所示，测试时先用浏览器打开Rs所在的Web应用，并重现产生Rs的环境(用户用浏览器登录Web应用，获得权限信息)。对tc_set中的每个测试用例t(用HTML文件表示)，用浏览器打开它。打开HTML文件的过程即执行测试用例的过程。
[0070] 测试用例执行时，在Web应用
服务器端将收到伪造请求Rf的执行要求，此时第1阶段部署的HTTP信息收集模块将记录Rf的执行信息。tc_set中的所有测试用例执行结束后，就得到嫌疑请求Rs的测试结果集rs_set。
[0071] 为提高执行效率，可以用同一浏览器一次打开多个测试用例。
[0072] 5、CSRF漏洞检测
[0073] 本模块也是本发明的独创点。如图7所示，得到Rs的测试结果集rs_set后，就可分析通过上述测试是否发现了Web应用中的CSRF漏洞。对rs_set中每条记录对应的伪造请求Rf，找出以下内容：(1)Rf对应的原始请求Rs；(2)Rf自身的所有嫌疑参数；(3)伪造请求Rf所用的伪造参数pf，以及pf对应的嫌疑参数ps。检测分两种情况：
[0074] 情况1.如果pf的值没有成为Rf某个修改型SQL语句的操作数，则通过Rf没有发现Web应用中的CSRF漏洞。
[0075] 情况2.如果pf的值成为了Rf某个修改型SQL语句的操作数，且该值所在的修改型SQL语句和ps值所在的SQL语句相似(这两个SQL语句除嫌疑参数值和自动变更的参数值不同外，其它都是相同的)；且这两个值在两个SQL语句的位置也相同，那么通过该Rf就发现了Web应用中的CSRF漏洞。这是因为Rf用伪造参数pf，通过修改型SQL语句更改了后端数据库。
[0076] 针对嫌疑请求Rs，若rs_set中至少有一条记录对应的Rf发现Web应用的CSRF漏洞，则通过Rs可构造CSRF攻击，同时分析Rs可帮助修复或避免Web应用的CSRF漏洞。
[0077] 本发明被实现为一个Web应用测试工具。从中国站长站下载的五个被广泛使用的PHP Web应用作为测试对象。这五个Web应用的基本信息如表1所示。五个测试对象具有一定代表性，体现在以下三个方面：
[0078] (1)规模，既有大型的Web应用，如：Discuz！、织梦内容管理系统；也有小型的Web应用，如：BZCMS；
[0079] (2)类别，五个Web应用来自四个不同应用类别，包括博客和论坛等；
[0080] (3)成熟度，既有推出数百个版本的Discuz！和织梦内容管理系统，也有只推出1.1版本的BZCMS系统。其中Discuz！被数十万用户所使用。
[0081] 表1
[0082]Web应用名称 版本 大小 PHP文件个数 代码行数 类别
DYHB-blog 1.3 1.84M 182个 12633行 博客
闻名weenCompany企业网站系统 4.0 2.86M 105个 28660行 整站
Discuz！ 7.2 10.9M 517个 124323行 论坛
BZCMS 1.1 12.6M 80个 9406行 内容管理
织梦内容管理系统 5.1 21M 524个 74165行 内容管理
[0083] 从表2的测试结果数据可知，本发明提出的方法能够有效发现CSRF嫌疑请求和漏洞。大多数识别出的嫌疑请求经动态检测发现了CSRF漏洞，识别准确率最高达100％，总平均可达45％。另外生成的测试用例发现CSRF漏洞的成功率也很高，最高达63.2％，总平均有31.1％，具有较高的测试效率。特别值得一提的是Discuz！和织梦内容系统，它们经过多年的更新，在防范CSRF方面做了很多工作，但本发明方法还是能够在这些Web应用中检测出CSRF漏洞。
[0084] 表2
[0085]
