CN107634967B

CN107634967B - 一种CSRF攻击的CSRFToken防御系统和方法

Info

Publication number: CN107634967B
Application number: CN201710974140.2A
Authority: CN
Inventors: 聂长海; 王顺
Original assignee: Nanjing University
Current assignee: Nanjing University
Priority date: 2017-10-19
Filing date: 2017-10-19
Publication date: 2021-06-25
Anticipated expiration: 2037-10-19
Also published as: CN107634967A

Abstract

本发明提出一种CSRF攻击的CSRFToken防御系统和方法，一种CSRF攻击的CSRFToken防御系统，包括有：HTTP请求信息收集模块，用户身份认证模块，用户权限授权模块，Csrftoken‑verify‑list.xml模块，CSRFTokenManager模块，能够阻止用户的执行请求，并能够有效识别CSRF攻击，并对CSRF攻击进行防御，更高效快速做到有效防护。

Description

一种CSRF攻击的CSRFToken防御系统和方法

技术领域

本发明涉及网络通信技术领域，具体尤其涉及一种CSRF攻击的CSRFToken防御系统和方法。

背景技术

随着科技的发展，现有各种网络应用盛行，在Web应用层面上的安全攻击逐渐占据主流。跨站点请求伪造(CSRF)因其攻击隐蔽性强，攻击危害性大，从2007至2017近十年都排在Web安全攻击前十名，对上网用户生活与财产安全构成极大威胁，然而，目前无论是手工还是自动化检测都缺少对CSRF漏洞的准确识别，CSRF的防御方法也较多，但大多适用特定场合，很难得到全面防护，让这种攻击防不胜防。

CSRF的思想可以追溯到上世纪八十年代，早在1988年Norm Hardy发现这个应用级别的信任问题，并把它称为混淆代理人(Confused Deputy)。2001年Peter Watkins第一次将其命名为CSRF，并将其报在Bugtraq缺陷列表中，从此CSRF开始进入人们的视线，而从2007年至今，CSRF攻击一直排名在Web安全攻击前十名。

大量研究发现，国际互联网上CSRF攻击普遍存在，典型的CSRF攻击如荷兰国际集团旗下的网络银行INGDirect可以任意创建用户，可以任意汇款，导致银行个人财产的丢失；孟加拉银行Bangladesh Bank 1亿美元被窃取；视频网站YouTube可以任意添加用户、加为好友列表等；阿里巴巴安全部门发生的抢月饼事件等，CSRF就像一个狡猾的猎人在自己的狩猎区布置了一个个陷阱，上网用户就像一个个猎物，在自己不知情的情况下被其引诱，触发了陷阱，导致了用户的信息暴露，财产丢失。因为其极其隐蔽，并且利用的是互联网Web认证自身存在的漏洞，所以很难被发现并且破坏性大。

CSRF之所以能够广泛存在，主要原因是Web身份认证及相关机制的缺陷，而当今Web身份认证主要包括像隐式认证、同源策略、跨域资源共享、Cookie安全策略、Flash安全策略等。CSRF是通过第三方伪造用户请求来欺骗服务器，以达到冒充用户身份、行使用户权利的目的。

CSRF攻击比较隐蔽，在通常情况下，用户访问了一个攻击者精心构造的网页，或点击了一个不知名的网络链接，攻击就生效了，攻击者就像一个捕猎者，首先寻找容易设下陷阱的网站，无论是跨域或同域(寻找场合)；然后在较为隐蔽的场合伪造请求设置陷阱(等候猎物)，最后等待用户点击链接或访问某个网页导致攻击生效(成功捕获)；不管上网用户是主动点击某个恶意链接，还是无意访问某个网页，都有可能进入攻击者精心设计的CSRF圈套。

CSRF攻击隐蔽性强，破坏性大，并且容易被忽视，如何有效的识别与定位CSRF攻击点变得非常重要，如果能快速找到这些能被攻击的点，软件架构师就能从设计上去预防，软件开发工程师也能有的放矢的进行防护，软件测试工程师也能有针对性地进行CSRF攻击验证测试，从而消除CSRF潜在威胁，给广大网络用户提供一个相对安全的上网环境，令人可惜的是，目前市面上还没有一个专门准确的扫描CSRF攻击漏洞的工具，同时由于CSRF攻击大多是人为精心设计的陷阱，所以通过目前基于模式匹配方式进行扫描或渗透攻击的工具，对CSRF的识别与定位非常薄弱，以静态扫描工具Coverity、JTest等为例，这些工具能够非常方便的扫描出XSS攻击，但对于CSRF攻击基本上是无能为力，而安全动态渗透工具像AppScan、ZAP等，能比较方便的渗透出SQL Injection或XSS攻击，但仅能少量的扫描出CSRF攻击，并且扫描出来的结果还需要人工去分析，扫描的结果是否正确，大量的CSRF漏洞无法准确识别出来，到目前为止，市面上还没有一个工具能准确的识别与定位CSRF攻击。

由于CSRF攻击影响大，对CSRF攻击的防御研究相对来说主要存在以下几个方面；初期开发者认为CSRF之所以能够攻击成功，主要是攻击者模拟一个可运行的URL，并且这个URL中的参数都显示在浏览器的地址栏中，很方便攻击者伪造同样的URL进行攻击，不过开发者很快就发现，这种防护只是稍微增加了攻击者的门槛，实际上只要有一点HTML网页编程基础的人，都很容易将Get改成Post发出，所以这种防护相对来说，并不能真正防护CSRF攻击，只是增加一点攻击的门槛；另有提出HTTP Referer header防护，初期开发者认为CSRF能发生，主要由于跨域的伪造URL请求，从而导致CSRF攻击成功，所以程序员们认为检查HTTP Referer header会是避免CSRF攻击的很有效方法，只要链接过来的域和网站原先的域不一致，就不让其访问，这样就能够防止CSRF攻击了，这个方法的确能够有一定的防护作用，但目前的浏览器Referer header是能被篡改的，同时弹出窗口中Referer header经常为空，这就导致Referer header的解决方案存在及缺陷，同时Referer header只能防跨域攻击，对同域的CSRF攻击无能为力；还有提出解决方法是在浏览器中安装一个插件，这个插件用来限制哪些站点能跳转，哪些站点不能跳转，许多安全工程师和程序员认为这是一个很好的方法，可以不用每个应用程序自己改代码，只要浏览器增加插件能做这事，就能解决一切问题，但是这样做的问题在于并不是所有的用户都知道要浏览器安装这个插件才能上网，另外即使装上了这个插件，普通用户也不知道如何设置，因为浏览器插件防护，只能防跨域的CSRF攻击，如果是同域的攻击无法防护，同时客户端插件很容易被其他程序禁用掉，一旦插件被禁用，这个防护就形同虚设；还有提出每个关键操作需要用户确认，或者说是二次认证(可能是图形验证码，短信验证码，支付密码等等)，比如需要结账时可能需要重新登录，目前亚马逊采用这种方式，比如最后结账时需要输入支付密码，目前支付宝采用这种方式，比如网银付款时，系统会给用户发一个短信确认此次支付行为，比如关键的操作，要求用户输入图形验证码或者选择合适的图形(12306购票)等等，如果用户不进一步确认就不能进行相应的操作，这样能避免用户在茫然无知的情况下执行一些关键的操作，这些设计的确能够给用户提醒，防止一些不必要的损失，但同时也给用户操作带来不便；还有提出用CSRFToken进行防护，因为CSRFToken总是变化的，攻击者无法预知，所以能够保证每个关键链接不能被攻击者构造出来，这样就能防护住CSRF攻击，这种方案目前也是CSRF防护中各大软件公司使用最广的，认为是最安全的，同时又不改变用户行为，不增加用户频繁认证的负担的解决方案，但基于CSRFToken防护需要首先考虑的是CSRFToken如何生成，同时需要考虑到CSRFToken什么时候生成，什么时候验证CSRFToken，而现有的技术基本是每一个步骤都会带与验证CSRFToken，这样就需要额外的数据库进行有效支撑，用于保存并验证CSRFToken，这样会大大增加额外的开销，增加了企业的投入成本。

发明内容

为此，本发明提出一种CSRF攻击的CSRFToken防御系统和方法，能够有效识别CSRF攻击，并对CSRF攻击进行防御，更高效快速做到有效防护。

本发明通过如下手段实现：

本发明一种CSRF攻击的CSRFToken防御系统，包括有：

HTTP请求信息收集模块，用户访问某网站的URL通过Get或Post请求发数据至服务器；

用户身份认证模块，服务器端进行用户身份的认证，确认该用户是否已经登录；

用户权限授权模块，服务器端对用户进行授权是否允许访问特定的功能；

Csrftoken-verify-list.xml模块，Csrftoken-verify-list.xml中配置所有需要进行CSRFToken验证的URL；

CSRFTokenManager模块，如果某url在csrftoken-verify-list模块中，就进行CSRFTokenManager模块，用于验证用户的csrftoken是否正确，如果不正确或者没有这个参数，就阻止用户的执行请求。

一种CSRF攻击的CSRFToken防御方法，包括有以下步骤：

接收HTTP请求；

对HTTP请求进行信息收集；

认证：判断该请求是否需要登录，如果执行，则判断该用户是否有权限执行，如果不执行，则确定HTTP请求正常，并对HTTP请求进行下一步处理；

授权：判断该用户是否有权限执行，如果执行，则判断请求是否在csrftoken-verify-list中，如果不执行，则返回无权限执行异常页面；

判断请求是否在csrftoken-verify-list中，如果执行，则CSRFTokenManager负责检验CSRFToken参数是否有，并且CSRFToken的值是否正确，如果不执行，则确定HTTP请求正常，并对HTTP请求进行下一步处理；

CSRFTokenManager负责检验CSRFToken参数是否有，并且CSRFToken的值是否正确，如果执行，则确定HTTP请求正常，并对HTTP请求进行下一步处理，如果不执行，则CSRFToken校验错，返回出错页面；

确定HTTP请求正常，并对HTTP请求进行下一步处理；

返回无权限执行异常页面；

CSRFToken校验错，返回出错页面。

本发明系统中对CSRF攻击的拦截，包括有以下步骤：

用户登录一个网站，Web服务器验证后，用户获得身份；已经登录成功的用户，服务器认证完成后，会与客户端进行Cookie交换；用户再访问这个网站中的其他网页或链接就不需要重新走登录认证流程，因为系统自动附带已认证的cookie，而这个cookie代表了这个用户的合法身份；攻击者设置陷阱，伪造一个链接或邮件或二维码等，诱导用户访问，一旦用户点击或访问；系统就会附带用户在该网站中已经认证的Cookie，发到服务器端请求执行；本发明对于需要进行CSRF防护的URL，都会从请求中获取CSRFToken；获取完成，对CSRFToken的正确性进行校验；因为CSRFToken每个人都不同，不同时刻访问也不同，每次登录都会变化，攻击者无法预知CSRFToken值，所以攻击者无法伪造出一个可以执行的URL，这样就会校验失败，中止操作，从而完成CSRF攻击的防护。

本发明防御系统中CSRFTokenManager模块包括有CSRFToken的生成、CSRFToken的校验、CSRFToken的清除功能。

本发明防御系统中CSRFTokenManager模块对CSRFToken的生成的时机，其中：用户访问一个网站的URL；用户登录某网站，完成身份认证，准备去执行那些只有自己本人才能做的事(业务功能)；用户登录成功，完成身份验证的同时，服务器除了按目前的统一方式，完成认证Cookie和客户端的交换，同时会生成本发明中的CSRFToken(包括网卡MAC地址、时间戳、名字空间、随机或伪随机数、时序等元素，确保其唯一性，不能被攻击者猜测到)。也就是说本发明中CSRFToken生成的时机是在用户正确登录完成身份认证时生成。

本发明防御系统中CSRFTokenManager模块对CSRFToken验证的时机，其中：用户点击URL，请求执行某功能；系统检查用户想要执行的功能，是否需要用户已经登录，并且需要用户的身份才有权限去做此事；检查此功能是否在csrftoken-verify-list.xml中，如果在就要验证客户端传过来的CSRFToken值是否正确，因为攻击者无法预知并伪造出正确的CSRFToken，所以能有效阻止CSRF攻击。这样做的好处是能精确进行CSRF防护，对不需要防护的URL，按正常方式放行。

本发明系统中CSRFTokenManager模块对CSRFToken的管理，其中：用户登录成功后生成CSRFToken本发明用generateCSRFToken()方法，当用户执行登录并成功后，系统会生成一个CSRFToken，并且把这个CSRFToken返回给调用者，这样调用者在组装后续URL时，必须要带上这个CSRFToken，用于后续URL防CSRF攻击；检查用户请求访问的URL，是否在csrftoken-verify-list.xml中，csrftoken-verify-list.xml文件的调用配置在web.xml中，由CsrfFilter.java负责处理URL是否在需要进行CSRFToken校验的列表中，如果匹配上就强制进行CSRFToken的校验。本发明用verifyCSRFToken()方法，该方法首先判断CSRFToken这个参数是否存在，是否为空，如果发现此URL请求参数没有带CSRFToken或CSRFToken的值为空，就直接返回错，如果发现用于带的CSRFToken和系统生成的CSRFToken不一致，说明有伪造，也会中止程序继续向后执行，拦截CSRF攻击；当用户退出时，系统会销毁本次生成的CSRFToken，removeCSRFToken()，将CSRFToken置空，本次生成的CSRFToken也会永久失效，下次用户重新登录，会生成新的CSRFToken。

本发明有益效果：本发明能够快速有效防护CSRF攻击，方便网站开发与维护者，尽快做好防御工作，本发明能够有效快速高效的防护CSRF漏洞。

附图说明：

图1为本发明跨站点请求伪造防御系统框架图；

图2为本发明跨站点请求伪造防御方法流程图；

图3为本发明跨站点请求伪造防御系统拦截攻击示意图；

图4为本发明跨站点请求伪造防御系统CSRFToken生成示意图；

图5为本发明跨站点请求伪造防御系统CSRFToken验证示意图；

图6为本发明跨站点请求伪造防御系统CSRFToken管理示意图。

具体实施方式：

为了使本领域的技术人员更好地理解本发明的技术方案，下面结合实施例对本发明作进一步说明：

如图1所示，本发明一种CSRF攻击的CSRFToken防御系统，包括有HTTP请求信息收集模块101、用户身份认证模块102、用户权限授权模块103、Csrftoken-verify-list.xml模块104、CSRFTokenManager模块105。

其中TTP请求信息收集模块101，用户访问某网站的URL通过Get或Post请求发数据至服务器；

用户身份认证模块102，服务器端进行用户身份的认证，确认该用户是否已经登录；

用户权限授权模块103，服务器端对用户进行授权是否允许访问特定的功能；

Csrftoken-verify-list.xml模块104，Csrftoken-verify-list.xml中配置所有需要进行CSRFToken验证的URL；

CSRFTokenManager模块105，如果某url在csrftoken-verify-list模块中，就进行CSRFTokenManager模块，用于验证用户的csrftoken是否正确，如果不正确或者没有这个参数，就阻止用户的执行请求。

如图2所示，一种CSRF攻击的CSRFToken防御方法，包括有以下步骤：

步骤201，接收HTTP请求；

步骤202，对HTTP请求进行信息收集；

步骤203，认证：判断该请求是否需要登录，如果执行，则进行步骤204，如果不执行，则进行步骤207；

步骤204，授权：判断该用户是否有权限执行，如果执行，则进行步骤205，如果不执行，则进行步骤208；

步骤205，判断请求是否在csrftoken-verify-list中，如果执行，则进行步骤206，如果不执行，则进行步骤207；

步骤206，CSRFTokenManager负责检验CSRFToken参数是否有，并且CSRFToken的值是否正确，如果执行，则进行步骤207，如果不执行，则进行步骤209；

步骤207，确定HTTP请求正常，并对HTTP请求进行下一步处理；

步骤208，返回无权限执行异常页面；

步骤209，CSRFToken校验错，返回出错页面。

如图3所示，本发明拦截攻击步骤，其中：

步骤301，用户登录一个网站，Web服务器验证后，用户获得身份；步骤302，已经登录成功的用户，服务器认证完成后，会与客户端进行Cookie交换；步骤303，用户再访问这个网站中的其他网页或链接就不需要重新走登录认证流程，因为系统自动附带已认证的cookie，而这个cookie代表了这个用户的合法身份；步骤304，攻击者设置陷阱，伪造一个链接或邮件或二维码等，诱导用户访问，一旦用户点击或访问；步骤305，系统就会附带用户在该网站中已经认证的Cookie，发到服务器端请求执行；步骤306，本发明对于需要进行CSRF防护的URL，都会从请求中获取CSRFToken；步骤307，获取完成，对CSRFToken的正确性进行校验；步骤308，因为CSRFToken每个人都不同，不同时刻访问也不同，每次登录都会变化，攻击者无法预知CSRFToken值，所以攻击者无法伪造出一个可以执行的URL，这样就会校验失败，中止操作，从而完成CSRF攻击的防护。

如图4所示，本发明跨站点请求伪造防御系统CSRFToken生成时机，其中：

步骤401，用户访问一个网站的URL；

步骤402，用户登录某网站，完成身份认证，准备去执行那些只有自己本人才能做的事(业务功能)；

步骤403，用户登录成功，完成身份验证的同时，服务器除了按目前的统一方式，完成认证Cookie和客户端的交换，同时会生成本发明中的CSRFToken(包括网卡MAC地址、时间戳、名字空间、随机或伪随机数、时序等元素，确保其唯一性，不能被攻击者猜测到)。也就是说本发明中CSRFToken生成的时机是在用户正确登录完成身份认证时生成。

如图5所示，本发明跨站点请求伪造防御系统CSRFToken验证的时机，其中：

步骤501，用户点击URL，请求执行某功能；

步骤502，系统检查用户想要执行的功能，是否需要用户已经登录，并且需要用户的身份才有权限去做此事；

步骤503，检查此功能是否在csrftoken-verify-list.xml中，如果在就要验证客户端传过来的CSRFToken值是否正确，因为攻击者无法预知并伪造出正确的CSRFToken，所以能有效阻止CSRF攻击。这样做的好处是能精确进行CSRF防护，对不需要防护的URL，按正常方式放行。

如图6所示，本发明系统中对CSRFToken的管理，其中：

步骤601，用户登录成功后生成CSRFToken本发明用generateCSRFToken()方法，当用户执行登录并成功后，系统会生成一个CSRFToken，并且把这个CSRFToken返回给调用者，这样调用者在组装后续URL时，必须要带上这个CSRFToken，用于后续URL防CSRF攻击；

步骤602，检查用户请求访问的URL，是否在csrftoken-verify-list.xml中，csrftoken-verify-list.xml文件的调用配置在web.xml中，由CsrfFilter.java负责处理URL是否在需要进行CSRFToken校验的列表中，如果匹配上就强制进行CSRFToken的校验。本发明用verifyCSRFToken()方法，该方法首先判断CSRFToken这个参数是否存在，是否为空，如果发现此URL请求参数没有带CSRFToken或CSRFToken的值为空，就直接返回错，如果发现用于带的CSRFToken和系统生成的CSRFToken不一致，说明有伪造，也会中止程序继续向后执行，拦截CSRF攻击；

步骤603，当用户退出时，系统会销毁本次生成的CSRFToken，removeCSRFToken()，将CSRFToken置空，本次生成的CSRFToken也会永久失效，下次用户重新登录，会生成新的CSRFToken。

这样CSRFToken在每次用户登录时都不一样，所以攻击者很难去预知并伪造。从而确保用户对本网站所有的操作都能代表自己的行为，伪造的请求，都会被系统拦截而不真正执行，从而防护住CSRF攻击。

以上只通过说明的方式描述了本发明的某些示范性实施例，毋庸置疑，对于本领域的普通技术人员，在不偏离本发明范围的情况下，可以用各种不同的方式对所描述的实施例进行修正。因此，上述附图和描述在本质上是说明性的，不应理解为对本发明权利要求保护范围的限制。

除非另有定义，本文所使用的所有学术和科学术语具有本发明所属技术领域普通技术人员所理解的相同含义。

在相抵触的情况下，以本说明书中的定义为准。

除非另有说明，所有的百分数、份数、比例等都是以重量计。

当给出数值或数值范围、优选范围或一系列下限优选值和上限优选值时，应当理解其具体公开了由任何较小的范围限值或优选值和任何较大的范围限值或优选值的任何一对数值所形成的任何范围，而无论范围是否分别被公开。除非另有说明，在本说明书描述数值范围之处，所述的范围意图包括范围端值和范围内的所有整数和分数。

当术语“约”或“左右”用于描述数值或范围的端值时，所公开的内容应当是包括该具体数值或所涉及的端值。

采用“一”和“一个/种”的用法描述本发明的要素和组分，这只是出于便利和为了给出本发明一般情况。除非另有明显表述，应将该说明理解为包括一个/种或至少一个/种。

Claims

1.一种CSRF攻击的CSRFToken防御系统，其特征在于：应用于同域、跨域防御，包括有：

CSRFTokenManager模块，CSRFTokenManager模块包括有CSRFToken的生成、CSRFToken的校验、CSRFToken的清除功能。

2.根据权利要求1所述的一种CSRF攻击的CSRFToken防御系统，其特征在于：CSRFToken的管理，其中：用户登录成功后生成CSRFToken用generateCSRFToken()方法，当用户执行登录并成功后，系统会生成一个CSRFToken，并且把这个CSRFToken返回给调用者，这样调用者在组装后续URL时，必须要带上这个CSRFToken，用于后续URL防CSRF攻击；检查用户请求访问的URL，是否在csrftoken-verify-list.xml中，csrftoken-verify-list.xml文件的调用配置在web.xml中，由CsrfFilter.java负责处理URL是否在需要进行CSRFToken校验的列表中，如果匹配上就强制进行CSRFToken的校验，用verifyCSRFToken()方法，该方法首先判断CSRFToken这个参数是否存在，是否为空，如果发现此URL请求参数没有带CSRFToken或CSRFToken的值为空，就直接返回错，如果发现用于带的CSRFToken和系统生成的CSRFToken不一致，说明有伪造，也会中止程序继续向后执行，拦截CSRF攻击；当用户退出时，系统会销毁本次生成的CSRFToken，removeCSRFToken()，将CSRFToken置空，本次生成的CSRFToken也会永久失效，下次用户重新登录，会生成新的CSRFToken。

3.一种CSRF攻击的CSRFToken防御方法，其特征在于：应用于同域、跨域防御，包括有以下步骤：

接收HTTP请求；

对HTTP请求进行信息收集；

认证：判断该请求是否需要登录，如果执行登录，则判断用户是否有权限执行，如果不执行登录，则确定HTTP请求正常，并对HTTP请求进行下一步处理；

授权：判断该用户是否有权限执行，如果执行授权，则判断请求是否在csrftoken-verify-list中，如果不执行授权，则返回无权限执行异常页面；

判断请求是否在csrftoken-verify-list中，如果在csrftoken-verify-list中，则CSRFTokenManager负责检验CSRFToken参数是否有，并且CSRFToken的值是否正确，检验CSRFToken参数在且CSRFToken的值正确，确定HTTP请求正常，并对HTTP请求进行下一步处理，如果检验CSRFToken参数不在且CSRFToken的值不正确，则CSRFToken校验错，返回出错页面；如果不在csrftoken-verify-list中，则确定HTTP请求正常，并对HTTP请求进行下一步处理。