一种基于加密的跨站请求攻击防范方法及其装置
技术领域
本发明涉及网络安全,主要是浏览器安全与web应用安全。更具体地,涉及一种盗用用户权限的跨站请求伪造攻击的防御方法和***。
背景技术
跨站请求伪造(Cross Site Request Forgery,CSRF)攻击,是一种挟制终端用户在已登录的Web应用程序上执行非用户意愿操作的攻击方法。其攻击的目标是用户而不是web应用,并且不需要利用任何浏览器漏洞,而是利用已进行过身份认证的会话进行攻击,即利用隐式认证漏洞来达到攻击。
跨站请求伪造是一种比较隐晦的攻击,受害者很可能不小心点击一个恶意链接,就会被攻击者利用,其本质是攻击者盗用了受害者的身份,以受害者的名义发送恶意请求,能够做的事情包括:发送邮件,消息,盗取账号,甚至于购买商品,虚拟货币转账等。造成的问题包括:个人隐私泄露以及财产安全。攻击后果取决于所利用的漏洞以及受害者的权限。
现有技术中,由于超文本传输协议(Hyper Text Transfer Protocol,HTTP)自身是一种无状态协议,即无法关联两次连续的请求,因此通过Cookie、Session和HTTP等身份验证信息来记录状态,关联同一个用户连续的请求。例如,当用户成功进行身份验证之后浏览器就会得到一个标识其身份的Cookie,只要不关闭浏览器或者退出登录,每当向该站点发送请求的时候,浏览器都会“自动地”连同该Cookie一起发出,无须用户干预,而不管这个请求是源自于应用程序提供的链接、从其他地方收到的统一资源定位符(UniformResource Locator,URL)或是其他来源。站点服务器是通过Cookie来识别用户的,即如果站点服务器收到了带有受害者的Cookie的请求,那么它就会把这个请求看作是已登录的受害者发来的,站点服务器会认为这是经过确认的有效请求,所以会执行这个“可信的动作”,从而为攻击提供了机会。Web站点的这种的身份验证机制虽然可以向目标站点保证一个请求来自于某个用户的浏览器,但是却无法保证该请求的确是那个用户发出的,或者是经过那个用户批准的。跨站请求伪造攻击之所以会发生,根本原因就是Web站点所验证的是Web浏览器而非用户本身。
图1为CSRF攻击相关流程图。图中步骤1为用户请求保护站点的保护页面;然后步骤2为站点服务器提示用户输入认证信息;步骤3为用户提交自己的用户名与密码信息;步骤4为站点服务器验证用户信息建立合法的会话,并且向用户生成标识用户的Cookie信息;步骤5-8为用户正常向站点服务器发送请求,并且站点服务器对其进行业务处理发送回应;步骤9-11为攻击者的攻击过程,其中步骤9为受害者及用户访问恶意站点,步骤10为恶意站点返回用户请求的内容,其中返回的内容中含有发向保护站点的恶意请求,步骤11为用户不小心点击恶意链接向保护站点发起请求或者网页中的恶意请求自动向保护站点发起请求,浏览器会自动将该站点下用户的Cookie携带然后发出这个请求,由于请求中含有Cookie信息,站点服务器会以为是已登录用户发出的合法请求,从而进行业务处理,执行攻击者的恶意动作。
目前,针对跨站请求伪造,主要有两种方法:
第一种是使用POST请求进行跨站请求伪造攻击,对重要的写操作,网站只接受POST请求,以此来防御跨站请求伪造攻击。但是该方法的缺点是,任何GET请求都可以构造表单通过POST请求来发送,因此此方法只能增加攻击者实现攻击的难度,并不能防范跨站请求伪造。
第二种是通过验证token来实现跨站请求伪造攻击的防范,可以在HTTP请求中以参数的形式加入一个随机产生的token,并在服务器端建立一个***来验证这个token,如果请求中没有token或者token内容不正确,则认为可能是CSRF攻击而拒绝改请求。这个“验证token”应该不能轻易的被未登录的用户猜测出来。但是开发者常常忘记实施这一防范,该方法还有一个缺点是难以保证token本身的安全,有可能通过URL或者HTTP Refererheader泄露token给其他站点。在期刊名为:In IEEE International Conference onSecurity and Privacy in Communication Networks(SecureComm),2006.,文献名称为:Preventing cross site request forgery attacks,作者名称为:Nenad Jovanovic,Engin Kirda,and Christopher Kruegel的文献中公开了该方法。
第三种是验证HTTP Referer header,(HTTP Referer是header的一部分,当浏览器向web服务器发送请求的时候,一般会带上Referer,告诉服务器我是从哪个页面链接过来的,服务器籍此可以获得一些信息用于处理。)通过验证HTTP Referer header,只接受来自可信源的请求,但是由于Referrer内容中涉及用户浏览记录等隐私内容,因此HTTP请求中绝大多数禁止了Referer头文件的使用,在期刊名称为:Proc.15th ACM Conf.Computerand Communications Security,ACM Press,2008,pp.75–87.,文献名称为:RobustDefenses for Cross-Site Request Forgery,作者名称为:A.Barth,C.Jackson,andJ.C.Mitchell的文献中公开了该方法。
可见,针对现存服务器,现有技术中存在的一些解决方法不能很好的防范跨站请求伪造攻击,因此,需要一种方法有效的防范跨站请求伪造攻击。
发明内容
本发明所要解决的技术问题在于提供一种基于加密的跨站请求攻击防范方法及其装置,以克服现有技术中存在的不能很好防范跨站请求攻击的问题。
为达上述目的,本发明提供了一种基于加密的跨站请求攻击防范方法,应用于包含客户端和服务器端的***,其特征在于,所述方法包括:
身份验证步骤:用于通过所述服务器端对所述客户端进行身份验证;
客户端攻击防范步骤:通过所述身份验证步骤验证为合法用户的客户端接收所述服务器端发送的随机数token,并采用所述随机数token对后续的请求进行加密成为加密请求;
服务器端攻击防范步骤:在所述服务器端接收所述合法用户的客户端的后续所述加密请求时,采用所述随机数token进行解密验证,以实现跨站请求攻击防范。
上述基于加密的跨站请求攻击防范方法,其特征在于,所述服务器端防范步骤包括:
页面判断步骤:判断所述客户端登陆的页面为受保护页面或公共访问页面;
随机数token生成步骤:针对通过验证的所述合法用户的客户端生成所述随机数token,并将所述随机数token发送给所述合法用户的客户端,所述随机数token与所述合法用户的会话id相关联。
上述基于加密的跨站请求攻击防范方法,其特征在于,所述客户端防范步骤包括:
提取token步骤:所述合法用户的客户端接收从所述服务器端发送的所述随机数token,并进行提取所述随机数token;
判断请求步骤:根据源网站服务器的域名与目的网站服务器的域名是否相同判断所述请求是否为本客户端应用发出,如果为所述本客户端应用请求,则通过所述随机数token进行加密,如果为非所述本客户端应用请求,则直接发送;
加密请求步骤:对所述合法用户的客户端向所述服务器端发送的请求内容通过所述随机数token进行加密;
发送请求步骤:将加密后的所述请求发送给所述服务器端。
上述基于加密的跨站请求攻击防范方法,其特征在于,所述服务器端防范步骤还包括:
解密步骤:对所述客户端发送的所述加密请求采用所述token作为密钥进行解密,以验证所述加密请求的合法性;
业务处理步骤:根据解密后的所述加密请求,进行相应的业务处理。
上述基于加密的跨站请求攻击防范方法,其特征在于,所述随机数token生成步骤还包括:
用户未登录步骤:查询用户的会话id不存在,判断所述用户未登录,则重新进行登录认证,针对认证通过的合法用户的客户端生成所述随机数token和会话id;
用户已登录步骤:查询用户的会话id存在,判断所述用户已登录,则为所述合法用户的客户端。
上述基于加密的跨站请求攻击防范方法,其特征在于,所述解密步骤还包括:
查找token步骤:通过与所述合法用户的会话id,查找与所述会话id相关联的所述随机数token;
原始请求解密步骤:采用查找token步骤获取的所述随机数token解密所述客户端发送的请求,获取所述客户端的原始请求。
上述基于加密的跨站请求攻击防范方法,其特征在于,所述业务处理步骤还包括:
解密成功步骤:如果采用所述原始请求解密步骤解密所述请求成功,则按照所述请求进行业务处理;
解密失败步骤:如果采用所述原始请求解密步骤解密所述请求失败,则不进行业务处理,并对所述合法用户发出警告信息。
本发明还提供一种基于加密的跨站请求攻击防范装置,采用如所述基于加密的跨站请求攻击防范方法,所述方法应用于包含客户端和服务器端的***,其特征在于,所述装置包括:
身份验证模块:用于通过所述服务器端对所述客户端进行身份验证;
客户端攻击防范模块:通过所述身份验证步骤验证为合法用户的客户端接收所述服务器端发送的随机数token,并采用所述随机数token对后续的请求进行加密成为加密请求;
服务器端攻击防范模块:在所述服务器端接收所述合法用户的客户端的后续所述加密请求时,采用所述随机数token进行解密验证,以实现跨站请求攻击防范。
上述基于加密的跨站请求攻击防范装置,其特征在于,所述服务器端防范模块包括:
页面判断模块:判断所述客户端登陆的页面为受保护页面或公共访问页面;
随机数token生成模块:针对通过验证的所述合法用户的客户端生成所述随机数token,并将所述随机数token发送给所述合法用户的客户端,所述随机数token与所述合法用户的会话id相关联。
上述基于加密的跨站请求攻击防范装置,其特征在于,所述客户端防范模块包括:
提取token模块:所述合法用户的客户端接收从所述服务器端发送的所述随机数token,并进行提取所述随机数token;
判断请求模块:根据源网站服务器的域名与目的网站服务器的域名是否相同判断所述请求是否为本客户端应用发出,如果为所述本客户端应用请求,则通过所述随机数token进行加密,如果为非所述本客户端应用请求,则直接发送;
加密请求模块:对所述合法用户的客户端向所述服务器端发送的请求内容通过所述随机数token进行加密;
发送请求模块:将加密后的所述请求发送给所述服务器端。
上述基于加密的跨站请求攻击防范装置,其特征在于,所述服务器端防范模块还包括:
解密模块:对所述客户端发送的所述加密请求采用所述token作为密钥进行解密,以验证所述加密请求的合法性;
业务处理模块:根据解密后的所述加密请求,进行相应的业务处理。
上述基于加密的跨站请求攻击防范装置,其特征在于,所述随机数token生成模块还包括:
用户未登录模块:查询用户的会话id不存在,判断所述用户未登录,则重新进行登录认证,针对认证通过的合法用户的客户端生成所述随机数token和会话id;
用户已登录模块:查询用户的会话id存在,判断所述用户已登录,则为所述合法用户的客户端。
上述基于加密的跨站请求攻击防范装置,其特征在于,所述解密模块还包括:
查找token模块:通过与所述合法用户的会话id,查找与所述会话id相关联的所述随机数token;
原始请求解密模块:采用查找token步骤获取的所述随机数token解密所述客户端发送的请求,获取所述客户端的原始请求。
上述基于加密的跨站请求攻击防范装置,其特征在于,所述业务处理模块还包括:
解密成功模块:如果采用所述原始请求解密步骤解密所述请求成功,则按照所述请求进行业务处理;
解密失败模块:如果采用所述原始请求解密步骤解密所述请求失败,则不进行业务处理,并对所述合法用户发出警告信息。
本发明与现有的跨站请求攻击防范技术相比,本发明的有益效果在于:
1、不需要修改现有的站点服务器代码:通过简单的配置就可以防范跨站请求伪造攻击,现有的防范技术有的需要修改站点服务器代码才能实现,对很多已经发展很成熟的应用来讲,要想使用这种防范技术,意味着必须重新开发或者修改应用,这不仅会耗费大量资源,而且会造成很多性能的降低,因此这种需要修改站点服务器的防范方法,发展很慢;
2、适用性强:对需要进行防范的应用没有特殊的要求,不需要应用使用特定的开发技术,JAVA,PHP,ASP等开发技术开发的应用都可以使用本发明提出的方法;
3、使用简单:不需要用户交互,不需要用户定义白名单,使用应用的用户不需要有相关的安全知识,减少了用户使用的难度;
4、通过对URL请求加密,使攻击者无法知道请求的具体格式(调用页面,参数等),加大了攻击者对要攻击应用了解的难度,即加大了攻击者实现攻击的难度。
附图说明
图1为 CSRF攻击相关流程图;
图2为本发明方法步骤流程示意图;
图3为本发明方法详细步骤流程示意图;
图4为本发明提供的防御CSRF攻击的服务器端流程示意图;
图5为本发明跨站攻击防范方法的客户端流程示意图;
图6为本发明跨站请求攻击防范装置的结构示意图;
图7为本发明跨站请求攻击防范装置的详细结构示意图。
其中,附图标记:
100 身份验证模块 200 客户端攻击防范模块
300 服务器端攻击防范模块
201 提取token模块 202 判断请求模块
203 加密请求模块 204 发送请求模块
301 页面判断模块 302 随机数token生成模块
303 解密模块 304 业务处理模块
S1~S3、S21~S24、S31~S34、S321~S322、S331~S332、S341~S342:本发明各实施例的施行步骤
具体实施方式
下面给出本发明的具体实施方式,结合附图和具体实施实例对本发明做详细描述。
本发明提出一种利用随机数(token)作为密钥对URL进行加密的方法,实现跨站请求伪造攻击的防范。为了达到上述目的,本发明利用站点服务器生成的攻击者难以猜测的随机数,并使用随机数加密URL,由于攻击者无法通过嗅探抓包等手段截获随机数,他无法伪造正确的请求。即便浏览器会将登录用户的Cookie自动附带到伪造的请求上,由于请求不是站点服务器认可的,故站点服务器不予处理,从而实现跨站请求伪造攻击的防范。
本发明主要涉及两类实体:客户端(用户通过浏览器来访问应用站点)和服务端(应用站点部署的服务器)。
本发明提供的一种基于加密的跨站请求攻击防范方法,应用于包含客户端和服务器端的***,图2为本发明方法步骤流程示意图,如图2所示,该方法包括:
身份验证步骤S1:用于通过服务器端对客户端进行身份验证;
客户端攻击防范步骤S2:通过身份验证步骤验证为合法用户的客户端接收服务器端发送的随机数token,并采用随机数token对后续的请求进行加密成为加密请求;
服务器端攻击防范步骤S3:在服务器端接收合法用户的客户端的后续加密请求时,采用随机数token进行解密验证,以实现跨站请求攻击防范。
其中,客户端攻击防范步骤S2包括:
提取token步骤S21:合法用户的客户端接收从服务器端发送的随机数token,并进行提取随机数token;
判断请求步骤S22:根据源网站服务器的域名与目的网站服务器的域名是否相同判断请求是否为本客户端应用发出,如果为本客户端应用请求,则通过随机数token进行加密,如果为非本客户端应用请求,则直接发送;
加密请求步骤S23:对合法用户的客户端向服务器端发送的请求内容通过随机数token进行加密;
发送请求步骤S24:将加密后的所述请求发送给所述服务器端。
其中,服务器端攻击防范步骤S3包括:
页面判断步骤S31:判断客户端登陆的页面为受保护页面或公共访问页面;
随机数token生成步骤S32:针对通过验证的合法用户的客户端生成随机数token,并将随机数token发送给合法用户的客户端,随机数token与合法用户的会话id相关联;
解密步骤S33:对客户端发送的加密请求采用token作为密钥进行解密,以验证加密请求的合法性;
业务处理步骤S34:根据解密后的加密请求,进行相应的业务处理。
其中,图3为本发明方法详细步骤流程示意图,如图3所示,随机数token生成步骤S32还包括:
用户未登录步骤S321:查询用户的会话id不存在,判断用户未登录,则重新进行登录认证,针对认证通过的合法用户的客户端生成所述随机数token和会话id;
用户已登录步骤S322:查询用户的会话id存在,判断用户已登录,则为合法用户的客户端。
其中,解密步骤S33还包括:
查找token步骤S331:通过与合法用户的会话id,查找与会话id相关联的随机数token;
原始请求解密步骤S332:采用查找token步骤获取的随机数token解密客户端发送的请求,获取客户端的原始请求。
其中,业务处理步骤S34还包括:
解密成功步骤S341:如果采用原始请求解密步骤解密请求成功,则按照请求进行业务处理;
解密失败步骤S342:如果采用原始请求解密步骤解密请求失败,则不进行业务处理,并对合法用户发出警告信息。
以下为了更好的对本发明技术方案的原理进行介绍,首先针对跨站请求伪造攻击给出一个具体实施例。
假设用户A已经登录了自己的银行账户,站点服务器为A返回了相应的会话session id认证信息,A在银行有一笔存款,此时通过对银行的网站发送HTTP请求http://bank.example/withdraw?account=A&amount=10000&for=B可以让A把10000的存款转到B的账号下,该请求发送到银行网站后,站点服务器会先验证该请求是否来自合法的会话,并且这个会话的用户是否已经登录,若此请求上附带有A的session id认证信息,则站点服务器会认为这个请求操作是已登录用户A发出的。
如果有一个攻击者B在该银行也有账户,并且他通过对银行网站的了解,知道通过上文中的URL可以进行转账操作。B可以自己发送一个请求给银行:http://bank.example/withdraw?account=A&amount=10000&for=B。但是由于这个请求来自B本身而非A,因此并没有包含A的相关认证信息,不能通过安全认证,该请求不会起作用。
这时,B想到使用CSRF的攻击方式,他在一个自己可以控制的网站,放入如下代码:src=“http://bank.example/withdraw?account=A&amount=10000&for=B”,并且通过广告,中奖信息等诱使A来访问他的网站。若A此时已经登录银行网站,并且打开新的标签来访问该恶意网站时,上述URL会从A的浏览器以GET的方式发送HTTP请求到银行,由于A此时已经登录银行网站,浏览器就会将A的session id一起附带发出,如果A的浏览器与银行的会话还未过期,由于站点服务器是通过session id识别用户的,因此银行网站会认为这是A发出的请求,悲剧发生了,银行网站将上述请求视为合法的请求进行处理,钱将从A的账号转移到B的账号,而A当时毫不知情。当A发现账户钱少了,去银行查询日志,他也只能发现确实有一个来自于他本人的合法请求转移了资金,没有任何被攻击的痕迹。
上面简要介绍了跨站请求伪造攻击的原理,本发明中站点服务器判断请求访问的内容是否是保护内容,如果是提示用户输入用户名和密码等验证信息,并生成会话相应的session id与随机数token,发送给客户端。用户后续的请求中,客户端会用随机数token对URL请求内容进行加密,然后发送请求。站点服务器会根据相应的session id找到对应的token,并且对URL请求解密,对于解密成功的请求,说明请求是利用随机数token加密的,而这个随机数只有客户端用户知道,是合法请求,因此站点服务器会根据请求内容进行相关业务处理。由于攻击者无法获得随机数,无法对伪造的请求进行正确加密,即便浏览器会将登录用户的session id自动附带到伪造的请求上,解密也会失败,站点服务器不仅不会进行业务处理,并且会向用户发出警告,这样便可以防范跨站请求伪造攻击。
以下将结合上述实施例以及附图对本发明实施例的步骤进行详细说明。
图4为本发明提供的防御CSRF攻击的服务器端流程示意图,如图4所示,服务器端的主要步骤包括:
10、判断是否是保护页面;
20、判断用户是否登录;
30、对加密的请求进行解密;
40、业务处理。
具体的一种实施方式如下:
10、判断是否是保护页面。一般应用都分为保护页面和公共页面。
1)公共页面不需要用户登录就可以访问,如login.html,index.html等,因为没有重要操作,不会造成危害,因此站点服务器可以直接根据请求进行相应的业务处理。
2)保护页面需要用户登录才能访问,即需要用户进行认证,比如修改用户密码,个人信息,转账等。因此站点服务器需要判断用户是否登录,当前是否是合法的会话。
20、判断用户是否登录。根据session id是否合法有效来判断用户是否登录,是否存在一个合法的会话。
1)如果不存在session id则说明用户没有登录,或者会话已过期,需要重新进行登录认证。具体主要包括以下步骤:
11)跳转到登录界面,提示用户输入认证信息(一般为用户名与密码)。
12)站点服务器验证用户输入的用户名与密码是否正确,不正确的话,重新跳转到登录页面,要求用户重新输入认证信息。
13)验证通过后,站点服务器会创建一个合法会话,并且生成关联用户会话的session id及随机数token,返回用户请求的页面,并且将session id及随机数token返回给客户端。
2)如果存在session id,说明用户已经成功登录,客户端拥有站点服务器发送过来的随机数token,此时后续的请求,如果是合法的,是应用发出的,应该是利用token随机数进行过加密的。
30、对加密的请求进行解密,已登录的用户,会拥有站点服务器发送回来的随机数token,因此后续本应用发出的请求都应该是利用token作为密钥加密的,因为攻击者没有token,不能正确解密的请求有可能是攻击者伪造的。
1)在站点服务器存储的session id与token的关联表中,根据请求中的sessionid找到对应的token。
2)用token解密请求中加密的部分(调用页面,参数等),就可以得到客户端发送的原始请求。
40、业务处理。
1)、用token解密成功,说明请求时利用站点服务器发送的token加密的,是应用发出的合法请求,因此站点服务器会按照请求进行相应的业务处理。
2)、解密失败,说明请求使用的加密密钥是错误的,有可能是攻击者猜测的token,用猜测的token对伪造的请求进行了加密;或者请求没有加密,解密失败,因此对其不进行业务处理,并且向用户发出相应警告信息。
图5为本发明跨站攻击防范方法的客户端流程示意图,如图5所示,客户端的主要步骤包括:
50、提取token;
60、判断请求是否是本应用发出的;
70、加密请求;
80、发送请求。
具体的一种实施方式如下:
50、提取token。客户端从站点服务器的响应中提取服务端发送给客户端的token。token可以放在站点服务器的响应页面中带回,也可以单独传送。
60、判断请求是否是本应用发出的。判断发出请求的源网站服务器的是否与目的网站的完整域名匹配,如果匹配则可以认为请求时本应用发出的,否则认为请求不是本应用发出的。
1)如果请求时本应用发出的,利用token对其加密。
2)如果请求不是本应用发出的,则不作处理,直接发送。
70、加密请求。对URL请求中的部分内容(调用页面,参数等)加密,URL请求中的应用的服务器地址等还是以明文形式发送,以保证请求可以正确的发送到服务端。其中加密操作,可以通过应用发布的一个插件来完成。
例如上述例子中,http://bank.example/withdraw?account=A&amount=10000&for=B,利用服务器发送的token对“withdraw?account=A&amount=10000&for=B”部分加密。应当理解,本发明可以采用其他方式进行加密,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
80、发送请求。将加密后的请求发给服务端。
本发明还提供一种基于加密的跨站请求攻击防范装置,采用所述基于加密的跨站请求攻击防范方法,该方法应用于包含客户端和服务器端的***,图6为本发明跨站请求攻击防范装置的结构示意图,如图6所示,该装置包括:
身份验证模块100:用于通过服务器端对客户端进行身份验证;
客户端攻击防范模块200:通过身份验证步骤验证为合法用户的客户端接收服务器端发送的随机数token,并采用随机数token对后续的请求进行加密成为加密请求;
服务器端攻击防范模块300:在服务器端接收合法用户的客户端的后续加密请求时,采用随机数token进行解密验证,以实现跨站请求攻击防范。
其中,客户端攻击防范模块200包括:
提取token模块201:合法用户的客户端接收从服务器端发送的随机数token,并进行提取随机数token;
判断请求模块202:根据源网站服务器的域名与目的网站服务器的域名是否相同判断请求是否为本客户端应用发出,如果为本客户端应用请求,则通过随机数token进行加密,如果为非本客户端应用请求,则直接发送;
加密请求模块203:对合法用户的客户端向服务器端发送的请求内容通过随机数token进行加密;
发送请求模块204:将加密后的请求发送给服务器端。
其中,服务器端攻击防范模块300包括:
页面判断模块301:判断客户端登陆的页面为受保护页面或公共访问页面;
随机数token生成模块302:针对通过验证的合法用户的客户端生成随机数token,并将随机数token发送给合法用户的客户端,随机数token与合法用户的会话id相关联;
解密模块303:对客户端发送的加密请求采用token作为密钥进行解密,以验证加密请求的合法性;
业务处理模块304:根据解密后的加密请求,进行相应的业务处理。
其中,图7为本发明跨站请求攻击防范装置的详细结构示意图,如图7所示,随机数token生成模块302还包括:
用户未登录模块3021:查询用户的会话id不存在,判断用户未登录,则重新进行登录认证,针对认证通过的合法用户的客户端生成所述随机数token和会话id;
用户已登录模块3022:查询用户的会话id存在,判断用户已登录,则为合法用户的客户端。
其中,解密模块303还包括:
查找token模块3031:通过与合法用户的会话id,查找与会话id相关联的随机数token;
原始请求解密模块3032:采用查找token步骤获取的随机数token解密客户端发送的请求,获取客户端的原始请求。
其中,业务处理模块304还包括:
解密成功模块3041:如果采用原始请求解密步骤解密请求成功,则按照请求进行业务处理;
解密失败模块3042:如果采用原始请求解密步骤解密请求失败,则不进行业务处理,并对合法用户发出警告信息。
综上所述,本发明提供的基于加密的跨站请求攻击防范方法及其装置,不需要修改现有的站点服务器,便可以进行很好的跨站请求攻击防御。
当然,本发明还可有其它多种实施例,在不背离本发明精神及其实质的情况下,熟悉本领域的技术人员当可根据本发明做出各种相应的改变和变形,但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。