技术领域
[0001] 本
发明实施例涉及通信技术领域，尤其是涉及一种跨站点伪造请求CSRF攻击识别方法和设备。
背景技术
[0002] CSRF(Cross-Site Request Forgery，跨站点伪造请求)攻击的核心是伪造表单，通过伪造表单在受影响的应用系统添加任意管理员，例如添加的管理员命名为X1，并给部分关键的参数设置好值，如在添加管理员时需将新用户名，用户密码，用户邮箱等关键参数设置好值。以此用户在
访问恶意
网站时，恶意网站会窃取正常用户的权限来将伪造的表单发送给系统
服务器中，在系统服务器执行该伪造的表单之后进行攻击。
[0003] CSRF攻击最常用的就是通过伪造表单进行攻击，但如果目标服务器部署了入侵防御设备，这种攻击方法可能会被入侵防御系统识别，导致攻击失败；对此某些攻击者可能会继续采用一些逃逸入侵防御设备检测的方法进行攻击；例如利用伪造src(Source，信息来源)代替伪造表单的方法来进行CSRF攻击，将攻击所用的伪造表单替换成img的src形式，这样当正常网站的管理员在以管理员身份登录了正常网站后，再点击包含img标签的恶意网站时，攻击者构造的管理员(例如X1)将被添加，用户的权限被窃取，从而后续可以利用窃取到的用户权限对该正常网站进行CSRF攻击。
[0004] 而在
现有技术中，所采取的措施都只能识别基于伪造表单的CSRF攻击，而无法识别基于伪造src的CSRF攻击。
发明内容
[0005] 本发明实施例提供了一种跨站点伪造请求CSRF攻击检测方法，包括：
[0006] 检测获取的超文本传输协议HTTP请求的负载中的信息来源src是否处于异常状态；
[0007] 若src处于异常状态，判断在预定时间内是否接收到源IP与HTTP请求的源IP相同的异常GET请求；
[0008] 若在预定时间内接收到源IP与所述HTTP请求的源IP相同的异常GET请求，则确认受到了CSRF攻击。
[0009] 优选的，检测获取的HTTP请求负载中的src是否处于异常状态，具体为：
[0010] 检测获取的HTTP请求的负载中src的长度是否大于
阈值，以及检测src中的统一资源标识符uri后面是否存在问号；
[0011] 若src的长度大于阈值，且uri后面存在问号，检测问号后面是否存在有不少于两个值为非空的参数；
[0012] 若问号后面是否存在有不少于两个值为非空的参数，则确定src处于异常状态。
[0013] 优选的，判断在预定时间内是否接收到源IP与HTTP请求的源IP相同的异常GET请求，具体为：
[0014] 判断在预定时间内是否接收到源IP与HTTP请求的源IP相同的GET请求；
[0015] 若在预定时间内接收到源IP与HTTP请求的源IP相同的GET请求，则判断GET请求中的uri与处于异常状态的src中的uri是否一致，以及判断GET请求中的uri和前一个链接标识referer是否不相关；
[0016] 若GET请求中的uri与处于异常状态的src中的uri一致，且GET请求中的uri和referer不相关，则确定接收到的GET请求是源IP与HTTP请求的源IP相同的异常GET请求。
[0017] 优选的，判断GET请求中的uri和referer是否不相关，具体为：
[0018] 提取GET请求中的uri和referer；
[0019] 基于uri和referer中的斜杠将uri和referer划分为多个部分；
[0020] 若所述uri中的任意一个部分均与所述referer中的任一部分不同，则确定GET请求中的uri和referer不相关。
[0021] 优选的，判断在预定时间内是否接收到基于处于异常状态的src生成的异常GET请求，具体为：
[0022] 将HTTP请求中的源IP，处于异常状态的src中的统一资源标识符uri和当前的时间记录在危险列表中，危险列表中存储的信息基于记录的时间定时老化；
[0023] 基于危险列表中存储的信息判断在预定时间内是否接收到源IP与HTTP请求的源IP相同的异常GET请求；
[0024] 若在预定时间内接收到源IP与所述HTTP请求的源IP相同的异常GET请求，将危险列表中记录的时间更新为接收异常GET请求的时间。
[0025] 本发明实施例还提供了一种跨站点伪造请求CSRF攻击检测设备，包括：
[0026] 检测模
块，用于检测获取的超文本传输协议HTTP请求中负载中的信息来源src是否处于异常状态；
[0027] 判断模块，用于当确定src处于异常状态时，判断在预定时间内是否接收到源IP与HTTP请求的源IP相同的异常GET请求；
[0028] 识别模块，用于在预定时间内接收到源IP与所述HTTP请求的源IP相同的异常GET请求时，确认受到了CSRF攻击。
[0029] 优选的，检测模块，具体用于：
[0030] 检测获取的HTTP请求的负载中src的长度是否大于阈值，以及检测src中的统一资源标识符uri后面是否存在问号；
[0031] 若src的长度大于阈值，且uri后面存在问号，检测问号后面是否存在有不少于两个值为非空的参数；
[0032] 若问号后面存在有不少于两个值为非空的参数，则确定src处于异常状态。
[0033] 优选的，判断模块，具体用于：
[0034] 判断在预定时间内是否接收到源IP与HTTP请求的源IP相同的GET请求；
[0035] 若在预定时间内接收到源IP与HTTP请求的源IP相同的GET请求，则判断GET请求中的uri与处于异常状态的src中的uri是否一致，以及判断GET请求中的uri和前一个链接标识referer是否不相关；
[0036] 若GET请求中的uri与处于异常状态的src中的uri一致，且GET请求中的uri和referer不相关，则确定接收到的GET请求是源IP与HTTP请求的源IP相同的异常GET请求。
[0037] 优选的，判断模块判断GET请求中的uri和referer是否不相关，具体包括：
[0038] 提取GET请求中的uri和referer；
[0039] 基于uri和referer中的斜杠将uri和referer划分为多个部分；
[0040] 若所述uri中的任意一个部分均与所述referer中的任一部分不同，则确定GET请求中的uri和referer不相关。
[0041] 优选的，判断模块，具体用于：
[0042] 将HTTP请求中的源IP，处于异常状态的src中的统一资源标识符uri和当前的时间记录在危险列表中，危险列表中存储的信息基于记录的时间定时老化；
[0043] 基于危险列表中存储的信息判断在预定时间内是否接收到源IP与HTTP请求的源IP相同的异常GET请求；
[0044] 若在预定时间内接收到源IP与所述HTTP请求的源IP相同的异常GET请求，将危险列表中记录的时间更新为接收异常GET请求的时间。
[0045] 与现有技术相比，本发明实施例公开了通过在检测到获取的HTTP请求的负载中的src处于异常状态时，判断在预定时间内是否接收到源IP与HTTP请求的源IP相同异常GET来确认是否受到了CSRF攻击；以此通过持续检测处于异常状态的src和异常GET请求来共同确认是否受到了基于伪造src的CSRF攻击，实现了对基于伪造src的CSRF攻击的识别。
附图说明
[0046] 图1是本发明实施例提出的一种CSRF攻击检测方法的流程示意图；
[0047] 图2是CSRF攻击原理的示意图；
[0048] 图3是本发明实施例提出的一种CSRF攻击检测设备的结构图。
具体实施方式
[0049] 针对现有技术中存在的上述问题，本发明实施例提供了一种跨站点伪造请求CSRF攻击检测方法，如图1所示，包括以下步骤：
[0050] 步骤101、检测获取的HTTP请求负载中的src是否处于异常状态。
[0051] 以图2的环境为例来进行说明，在用户C通过浏览器访问正常的网站A，且验证通过后，网站A返回Cookie信息给浏览器，在Cookie信息的有效时间之内，用户C又访问了网站B，此时，网站B会将HTTP(HyperText Transfer Protocol，超文本传输协议)请求返回给用户C，本发明中的步骤101也就是不断检测所有获取的HTTP请求，并进一步解析获取到HTTP请求负载中的src是否处于异常状态。
[0052] 在一个例子中，检测src是否处于异常状态的过程，具体为：
[0053] 检测获取的HTTP请求的负载中src的长度是否大于阈值，以及检测src中的统一资源标识符uri后面是否存在问号；
[0054] 若src的长度大于阈值，且uri后面存在问号，检测问号后面是否存在有不少于两个值为非空的参数；
[0055] 若问号后面存在有不少于两个值为非空的参数，则确定src处于异常状态；若问号后面不存在有不少于两个值为非空的参数，则可以认为该src未处于异常状态；
[0056] 也即需要满足上述的三个条件，才能确定src处于异常状态。
[0057] 具体的，在正常的情况下src引用的是站内资源，只能实现一些简单功能，所以正常的src在一般情况下是不携带协议名(HTTP)，也不携带域名(host)或者服务器IP的，也即正常的src长度不会特别长；再者正常的src对应的资源一般为一张图片或者一个页面，这种资源一般情况下没有参数，也即uri后面没有参数以及问号；即使偶尔携带有参数，值为非空的参数个数不会超过两个；因此对应于正常src的特征，同时考虑到判断的准确性，可以将同时满足上面三个条件的src称为处于异常状态的src。
[0058] 以一个具体的src为例来进行说明，例如该src具体为：http://192.168.20.172/vlun/axous/admin/administrators_add.php？user_name＝img1&new_passwd＝&new_passwd1＝passimg1…，该src中的uri为/vlun/axous/admin/administrators_add.php。在判断的该src是否异常的过程中，判断该src的长度是否超过阈值，以及判断该src中的uri后面是否存在问号，若该src的长度超过阈值，且src中的uri为：/vlun/axous/admin/administrators_add.php，可见src中的uri后存在一个问号。在此情况下，继续判断问号后面是否存在至少两个值为非空的参数。该src中uri的问号后面还存在内容“user_name＝img1&new_passwd＝&new_passwd1＝passimg1…”。其中，包括值为非空的参数“user_name＝img1”和“new_passwd1＝passimg1”，及值为空的参数“new_passwd＝”，也即该src中uri的问号后面存在不少于两个值为非空的参数，因此可以确认该src处于异常状态。
[0059] 在确认了src处于异常状态之后，执行步骤102；若确认src并未处于异常状态，针对该HTTP请求的检测结束。
[0060] 步骤102、判断在预定时间内是否接收到源IP与HTTP请求的源IP相同的异常GET请求。
[0061] 其中判断的具体过程可以如下：
[0062] 判断在预定时间内是否接收到源IP与HTTP请求的源IP相同的GET请求；若在预定时间内接收到源IP与HTTP请求的源IP相同的GET请求，则判断GET请求中的uri与处于异常状态的src中的uri是否一致，以及判断GET请求中的uri和referer(前一个链接标识，Referer是GET请求头部的一部分，当浏览器向web服务器发送请求的时候，web服务器可以基于Referer知道GET请求是从哪个页面链接过来的)是否不相关；若GET请求中的uri与处于异常状态的src中的uri一致，且GET请求中的uri和referer不相关，则确定接收到的GET请求是基于异常的src产生的异常GET请求。
[0063] 具体的，HTTP请求的源IP是用户的IP，当用户访问了恶意网站时，恶意网站要窃取用户的权限，并利用用户的权限来对之前用户访问的正常的网站进行攻击，而该攻击需要利用用户的IP，因此需要判断GET请求的源IP是否与HTTP请求的源IP相同，若相同，则继续判断该GET请求是否是异常GET请求。
[0064] 判断GET请求是否是异常的GET请求，其过程如下：
[0065] 由于uri是用来标识资源的，在此情况下检测到GET请求的uri和处于异常状态的uri一致时，说明疑似被攻击的IP试图访问服务器上的疑似本次攻击需要访问的页面，由于只能判断为疑似攻击，为了进一步判断是否该疑似攻击是真正的攻击，需要进一步判断GET请求中的uri(对应新页面的地址)和referer(对应前一个页面的地址)的相关性。
[0066] 正常访问一个网页时都是从同网站的一个页面跳转到另一个页面，也就是说要从前一个页面(referer)跳转新页面(uri)，此时两个地址因为是同一个网站内，所以具有一定的相关性，比如从http://rdbbs/bbs/forum.php？mod＝forumdisplay&fid＝58页面点击跳转到http://rdbbs/bbs/forum.php？mod＝viewthread&tid＝129页面时，可以看到“/bbs/forum.php？mod”部分是相同的，也即两者相关，但若是在进行攻击时，并不是在同一个网站的一个页面跳转到另一个页面，而是在不同的网站之间的不同的页面进行跳转，这样GET请求中的uri和referer就不会相关，也即各个部分都是不相同的。
[0067] 因此，若同时满足以上两个条件，则可以确定接收到的GET请求是异常GET请求，就可以确定接收到的是源IP与HTTP请求的源IP相同的异常GET请求。
[0068] 具体的过程中，如图2以及前述，用户C访问正常的网站A，产生的Cookie信息是有时间限制的，而CSRF攻击就是要窃取用户的权限来攻击正常的网页，因此必须要在Cookie信息的有效时间内发动攻击，为此需要在预定时间(具体的预定时间基于Cookie信息的有效时间进行设置)内检测是否接收到来自于用户的IP(也即HTTP请求中的源IP，例如为192.168.20.170)的GET请求，若是在预定的时间内没有接收到来自用户的IP的GET请求，Cookie信息过了有效期，也就意味着用户的权限无法被窃取，可以认为无法进行CSRF攻击；
而若是在预定时间收到了来自用户的IP的GET请求，也需要进一步判断该GET请求是否是异常GET请求才能确定是否受到了CSRF攻击。
[0069] 具体的判断GET请求是否是异常GET请求，是根据判断该GET请求中的referer与uri是否不相关，以及GET请求的uri和处于异常状态的uri是否一致来共同确定的，例如GET请求中的referer为：http://192.168.20.174/test/7829.htm，GET请求中的uri为/vlun/axous/admin/administrators_add.php，这两者是不相关的，而处于异常状态的src中的uri为/vlun/axous/admin/administrators_add.php，与GET请求中的uri一模一样，是一致的，因此可以确认该GET请求为异常GET请求。
[0070] 其中、具体的判断GET请求中的uri和referer是否不相关，有如下过程：提取GET请求中的uri和referer；基于uri和referer中的斜杠将uri和referer划分为多个部分；若uri中的任意一个部分均与所述referer中的任一部分不同，则确定GET请求中的uri和referer不相关。
[0071] 以一个合法用户通过web方式正常实现跨站访问功能的请求为例来进行说明，例如请求中uri为/vlun/axous/admin_list.php，而referer为http://192.168.20.172/vlun/axous/admin/administrators_add.php，这两者之间的/vlun/axous/是相同的，因此uri和referer是相关的。
[0072] 以一个非法的方式实现跨站访问功能的请求为例来进行说明，该请求中referer具体为：http://192.168.20.174/test/7829.htm，而uri为：/vlun/axous/admin/administrators_add.php，将uri中的字符串转换成数组url[]：以斜杠为分隔符进行转换，非第一个斜杠需同时出现在前后两个数组元素中。此时将uri转换后的url[]为：url[]＝{‘/vlun/’,‘/axous/’,‘/admin/’,‘/administrators_add.php’}。然后将referer进行相同的转换，将其转换为referer[]＝{‘/192.168.20.174/’,‘/test/’,‘/7829.htm/’}，再在referer字符串中遍历查找url数组的所有元素，如果Referer字符串中存在uri数组的某个元素，则停止查找，说明uri和referer相关，如果uri数组中的所有元素中的任意一个元素均不存在于referer字符串中，则说明uri和referer不相关。
[0073] 另外，在确定src处于异常状态时，还可以将HTTP请求中的源IP，处于异常状态的src中uri以及当前的时间记录在危险列表中，危险列表中存储的信息基于记录的时间定时老化；基于危险列表中存储的信息判断在预定时间内是否接收到源IP与HTTP请求中的源IP相同的异常GET请求；若在预定时间内接收到源IP与HTTP请求的源IP相同的异常GET请求，将危险列表中记录的时间更新为接收异常GET请求的时间。
[0074] 具体的，以上述HTTP请求中的源IP(192.168.20.170)以及Uri(/vlun/axous/admin/administrators_add.php)信息为例，该危险列表可以如表1所示：
[0075] 表1
[0076]
[0077] 表1中的时间D1为当前的时间(即接收到该异常HTTP请求)，后续基于Cookie信息有效时间确定表1中的老化时间，由于在确定src处于异常状态时，就建立了危险列表，并基于该危险列表对接收到的GET请求进行检测，因此该危险列表老化时间即为前述的预定时间，当到达老化时间时，说明Cookie信息不再有效了，可以删除对应的信息；而若是还未到达老化时间，也即Cookie信息仍旧有效，就可以利用该表1中的信息，判断在预定时间内是否接收到源IP与HTTP请求的源IP相同的异常GET请求，其具体的过程与前述过程相同，在此不再进行赘叙，而在预定时间内接收到源IP与HTTP请求的源IP相同的异常GET请求，接收的时间是在Cookie信息仍旧有效的时间段内，例如为时间为A，将危险列表中的时间D1更新为时间A，这是由于Cookie信息有效时间是基于每一次的登陆时间来重新以该次登陆的时间作为起点进行计算的，若在预定时间内接收到源IP与HTTP请求的源IP相同的异常GET请求，表示基于盗取的用户权限又登陆了正常的网站，因此Cookie信息有效时间就需要基于该次登陆的时间作为开始时间，向后延一段时间，例如一个小时，并继续基于更新了时间的危险列表中存储的信息判断在“预定时间”(该预定时间是基于延长后的Cookie信息有效时间进行设置的)内是否接收到源IP与HTTP请求中的源IP相同的异常GET请求。
[0078] 若判断在预定时间内接收到源IP与HTTP请求的源IP相同的异常GET请求，则执行步骤103；若在预定时间内并未接收到源IP与HTTP请求的源IP相同的异常GET请求，针对该HTTP请求的检测流程结束。
[0079] 步骤103、确认受到了CSRF攻击。
[0080] 具体的，在确定了预定时间内接收到源IP与HTTP请求的源IP相同的异常GET请求，也即接收到的GET请求的源IP与HTTP请求的源IP相同，且该GET请求中的uri和处于异常状态下的src中的uri一致，且该GET请求的uri和referer不相关，则可以确认受到了CSRF攻击。
[0081] 本发明实施例还提出了一种跨站点伪造请求CSRF攻击检测设备，如图3所示，包括：
[0082] 检测模块301，用于检测获取的HTTP请求的负载中的src是否处于异常状态；
[0083] 判断模块302，用于当确定src处于异常状态时，判断在预定时间内是否接收到源IP与HTTP请求的源IP相同的异常GET请求；
[0084] 识别模块303，用于在预定时间内接收到源IP与HTTP请求的源IP相同的异常GET请求时，确认受到了CSRF攻击。
[0085] 具体的，检测模块301，具体用于：
[0086] 检测获取的HTTP请求的负载中src的长度是否大于阈值，以及检测src中的统一资源标识符uri后面是否存在问号；
[0087] 若src的长度大于阈值，且uri后面存在问号，检测问号后面是否存在有不少于两个值为非空的参数；
[0088] 若问号后面存在有不少于两个值为非空的参数，则确定src处于异常状态。
[0089] 具体的，判断模块302，具体用于：
[0090] 判断在预定时间内是否接收到源IP与HTTP请求的源IP相同的GET请求；
[0091] 若在预定时间内接收到源IP与HTTP请求的源IP相同的GET请求，则判断GET请求中的uri与处于异常状态的src中的uri是否一致，以及判断GET请求中的uri和前一个链接标识referer是否不相关；
[0092] 若GET请求中的uri与处于异常状态的src中的uri一致，且GET请求中的uri和referer不相关，则确定接收到的GET请求是源IP与HTTP请求的源IP相同的异常GET请求。
[0093] 判断模块302判断GET请求中的uri和referer是否不相关，具体包括：
[0094] 提取GET请求中的uri和referer；
[0095] 基于uri和referer中的斜杠将uri和referer划分为多个部分；
[0096] 若所述uri中的任意一个部分均与所述referer中的任一部分不同，则确定GET请求中的uri和referer不相关。
[0097] 判断模块302，具体用于：
[0098] 将HTTP请求中的源IP，处于异常状态的src中的统一资源标识符uri和当前的时间记录在危险列表中，危险列表中存储的信息基于记录的时间定时老化；
[0099] 基于危险列表中存储的信息判断在预定时间内是否接收到源IP与HTTP请求的源IP相同的异常GET请求；
[0100] 若在预定时间内接收到源IP与所述HTTP请求的源IP相同的异常GET请求，将危险列表中记录的时间更新为接收异常GET请求的时间。
[0101] 与现有技术相比，本发明实施例公开了一种跨站点伪造请求CSRF攻击检测方法和设备通过通过在检测到获取的HTTP请求的负载中的src处于异常状态时，判断在预定时间内是否接收到源IP与HTTP请求的源IP相同异常GET来确认是否受到了CSRF攻击；以此通过持续检测处于异常状态的src和异常GET请求来共同确认是否受到了基于伪造src的CSRF攻击，实现了对基于伪造src的CSRF攻击的识别。
[0102] 通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可以通过
硬件实现，也可以借助
软件加必要的通用硬件平台的方式来实现。基于这样的理解，本发明的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动
硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施场景所述的方法。
[0103] 本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本发明所必须的。
[0104] 本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。
[0105] 上述本发明序号仅仅为了描述，不代表实施场景的优劣。
[0106] 以上公开的仅为本发明的几个具体实施场景，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。
