CSRF攻击原理及防护

CSRF攻击原理及防护

CSRF 跨站点请求伪造(Cross—Site Request Forgery)。

个人理解就是：攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来讲这个请求是彻底合法的，可是却完成了攻击者所指望的一个操做，好比以你的名义发送邮件、发消息，盗取你的帐号，添加系统管理员，甚至于购买商品、虚拟货币转帐等。

• 原理图：

  图CSRF原理图

这是一种对网站的恶意利用，CSRF比XSS更具危险性。想要深刻理解CSRF的攻击特性咱们有必要了解一下网站session的工做原理。

session详解

1、术语session

1. session，中文常常翻译为会话，其原本的含义是指善始善终的一系列动做/消息，好比打电话时从拿起电话拨号到挂断电话这中间的一系列过程能够称之为一个session。有时候咱们能够看到这样的话“在一个浏览器会话期间，...”，这里的会话一词用的就是其本义，是指从一个浏览器窗口打开到关闭这个期间①。最混乱的是“用户（客户端）在一次会话期间”这样一句话，它可能指用户的一系列动做（通常状况下是同某个具体目的相关的一系列动做，好比从登陆到选购商品到结帐登出这样一个网上购物的过程，有时候也被称为一个transaction），然而有时候也可能仅仅是指一次链接，也有多是指含义。

2. 然而当session一词与网络协议相关联时，它又每每隐含了“面向链接”和/或“保持状态”这样两个含义，“面向链接”指的是在通讯双方在通讯以前要先创建一个通讯的渠道，好比打电话，直到对方接了电话通讯才能开始，与此相对的是写信，在你把信发出去的时候你并不能确认对方的地址是否正确，通讯渠道不必定能创建，但对发信人来讲，通讯已经开始了。“保持状态”则是指通讯的一方可以把一系列的消息关联起来，使得消息之间能够互相依赖，好比一个服务员可以认出再次光临的老顾客而且记得上次这个顾客还欠店里一块钱。这一类的例子有“一个TCP session”或者“一个POP3 session”③。

3. session在web开发语境下的语义又有了新的扩展，它的含义是指一类用来在客户端与服务器之间保持状态的解决方案④。有时候session也用来指这种解决方案的存储结构，如“把xxx保存在session里”⑤。因为各类用于web开发的语言在必定程度上都提供了对这种解决方案的支持，因此在某种特定语言的语境下，session也被用来指代该语言的解决方案，好比常常把Java里提供的javax.servlet.http.HttpSession简称为session。

2、session和cookie

HTTP协议自己是无状态的，这与HTTP协议原本的目的是相符的，客户端只须要简单的向服务器请求下载某些文件，不管是客户端仍是服务器都没有必要纪录彼此过去的行为，每一次请求之间都是独立的。

人们发现提供一些按需生成的动态信息会使web变得更加有用，就像给有线电视加上点播功能同样。这种需求一方面迫使HTML逐步添加了表单、脚本、DOM等客户端行为，另外一方面在服务器端则出现了CGI规范以响应客户端的动态请求，做为传输载体的HTTP协议也添加了文件上载、cookie这些特性。其中cookie的做用就是为了解决HTTP协议无状态的缺陷所做出的努力。至于后来出现的session机制则是又一种在客户端与服务器之间保持状态的解决方案。

具体来讲cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时咱们也看到，因为采用服务器端保持状态的方案在客户端也须要保存一个标识，因此session机制可能须要借助于cookie机制来达到保存标识的目的，

• 咱们举个简单的例子：
  一、该店的店员很厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，店员就知道该怎么对待了。这种作法就是协议自己支持状态。 （HTTP协议是无状态的，而出于种种考虑也不但愿使之成为有状态的）

  二、发给顾客一张卡片，上面记录着消费的数量，通常还有个有效期限。每次消费时，若是顾客出示这张卡片，则这次消费就会与之前或之后的消费相联系起来。这种作法就是在客户端保持状态。

  三、发给顾客一张会员卡，除了卡号以外什么信息也不纪录，每次消费时，若是顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种作法就是在服务器端保持状态。

3、cookie机制

正统的cookie分发是经过扩展HTTP协议来实现的，服务器经过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。（纯粹的客户端脚本如JavaScript或者VBScript也能够生成cookie。）

而cookie的使用是由浏览器按照必定的原则在后台自动发送给服务器的。浏览器检查全部存储的cookie，若是某个cookie所声明的做用范围大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器。

cookie的内容主要包括：名字，值，过时时间，路径和域。

• 路径与域合在一块儿就构成了cookie的做用范围。若是不设置过时时间，则表示这个cookie的生命期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览器会话期的cookie被称为会话cookie。会话cookie通常不存储在硬盘上而是保存在内存里，固然这种行为并非规范规定的。若是设置了过时时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过时时间。

4、session机制

session机制是一种服务器端的机制，服务器使用一种相似于散列表(PS :根据关键码值(Key value)而直接进行访问的数据结构。也就是说，它经过把关键码值映射到表中一个位置来访问记录，以加快查找的速度。)的结构（也可能就是使用散列表）来保存信息。

当程序须要为某个客户端的请求建立一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为session id，若是已包含一个session id则说明之前已经为此客户端建立过session，服务器就按照session id把这个session检索出来使用（若是检索不到，可能会新建一个），若是客户端请求不包含session id，则为此客户端建立一个session而且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。

保存这个session id的方式能够采用cookie，这样在交互过程当中浏览器能够自动的按照规则把这个标识发挥给服务器。通常这个cookie的名字都是相似于SEEESION ID.

EP:weblogic对于web应用程序生成的cookie

JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764

的名字就是JSESSIONID。

• 因为cookie能够被人为的禁止，必须有其余机制以便在cookie被禁止时仍然可以把session id传递回服务器。常常被使用的一种技术叫作URL重写，就是把session id直接附加在URL路径的后面，附加方式也有两种:
  
• 1. 一种是做为URL路径的附加信息，表现形式为
     http://...../xxx;jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcE
• 1. 另外一种是做为查询字符串附加在URL后面，表现形式为http://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764

更详细的session应用问题咱们能够参考博客：http://www.javashuo.com/article/p-drmwojqt-mu.html

因此咱们总结一下CSRF攻击步骤：

1. 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登陆网站A；

2. 在用户信息经过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登陆网站A成功，能够正常发送请求到网站A；

3. 用户未退出网站A以前，在同一浏览器中，打开一个TAB页访问网站B；

4. 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；

5. 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的状况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求实际上是由B发起的，因此会根据用户C的Cookie信息以C的权限处理该请求，致使来自网站B的恶意代码被执行。

网上看到一个很形象的例子：（CSRF实例攻击）

受害者 Bob 在银行有一笔存款，经过对银行的网站发送请求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可使 Bob 把 1000000 的存款转到 bob2 的帐号下。一般状况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，而且该 session 的用户 Bob 已经成功登录。

黑客 Mallory 本身在该银行也有帐户，他知道上文中的 URL 能够把钱进行转账操做。Mallory 能够本身发送一个请求给银行：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。可是这个请求来自 Mallory 而非 Bob，他不能经过安全认证，所以该请求不会起做用。

这时，Mallory 想到使用 CSRF 的攻击方式，他先本身作一个网站，在网站中放入以下代码： src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，而且经过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时，上述 url 就会从 Bob 的浏览器发向银行，而这个请求会附带 Bob 浏览器中的 cookie 一块儿发向银行服务器。大多数状况下，该请求会失败，由于他要求 Bob 的认证信息。可是，若是 Bob 当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的 session 还没有过时，浏览器的 cookie 之中含有 Bob 的认证信息。这时，悲剧发生了，这个 url 请求就会获得响应，钱将从 Bob 的帐号转移到 Mallory 的帐号，而 Bob 当时绝不知情。等之后 Bob 发现帐户钱少了，即便他去银行查询日志，他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。而 Mallory 则能够拿到钱后逍遥法外。

CSRF漏洞检测：

• 检测CSRF漏洞是一项比较繁琐的工做，最简单的方法就是抓取一个正常请求的数据包，去掉Referer字段后再从新提交，若是该提交还有效，那么基本上能够肯定存在CSRF漏洞。

随着对CSRF漏洞研究的不断深刻，不断涌现出一些专门针对CSRF漏洞进行检测的工具，如CSRFTester，CSRF Request Builder等。

• 咱们拿CSRFTester工具为例，说明一下CSRF漏洞检测工具的测试原理：
  使用CSRFTester进行测试时，首先须要抓取咱们在浏览器中访问过的全部连接以及全部的表单等信息，而后经过在CSRFTester中修改相应的表单等信息，从新提交，这至关于一次伪造客户端请求。若是修改后的测试请求成功被网站服务器接受，则说明存在CSRF漏洞，固然此款工具也能够被用来进行CSRF攻击。

　

如何使用CSRF漏洞

　 CSRF攻击的主要目的是让用户在不知情的状况下攻击本身已登陆的一个系统，相似于钓鱼。
　如用户当前已经登陆了邮箱，或bbs，同时用户又在使用另一个，已经被你控制的站点，咱们姑且叫它钓鱼网站。这个网站上面可能由于某个图片吸引你，你去点击一下，此时可能就会触发一个js的点击事件，构造一个bbs发帖的请求，去往你的bbs发帖，因为当前你的浏览器状态已是登录状态，因此session登录cookie信息都会跟正常的请求同样，纯自然的利用当前的登录状态，让用户在不知情的状况下，帮你发帖或干其余事情。
　

如何抵御CSRF攻击

经过 referer、token 或者 验证码 来检测用户提交。 尽可能不要在页面的连接中暴露用户隐私信息。 对于用户修改删除等操做最好都使用post 操做。 避免全站通用的cookie，严格设置cookie的域。