跨站请求伪造攻击的基本原理与防范（转载）

CSRF的形成是因为攻击者较容易猜测某些Web应用一个特定敏感操作的所有细节（若是开源项目，则更直接找到关键操作的漏洞细节）。利用浏 览器能保存会话cookie等凭证，并会自动发送的特点，攻击者可以创建一个恶意web页面生成伪造请求，再利用社会工程学的手段蛊惑受害者进行操作，从 而在被攻击Web应用上伪装成受害者进行的特定敏感操作，如修改密码、通信方式甚至转账等。

CSRF不像XSS那么广为人知，但在OWASP 2013公布的10大Web应用安全威胁中，跨站请求伪造依然位居第8位，依然是一个不可忽略的严重安全漏洞。又因为CSRF比XSS更难以防范，且更具危险性，所以CSRF也被称为“沉睡的巨人”。
　　2 跨站请求伪造的场景　　
跨站请求伪造攻击可以在以受害者名义伪造请求并发送给受攻击的站点，这样就能以受害者的身份和权限执行一些特殊敏感的操作，但这一切受害者是毫不知情的。例如：　　
Tom登录了一个银行网站affectedBank.com，并没有退出。　　
黑客Jerry知道affectedBank.com的转账功能有CSRF漏洞。于是Jerry在大型社交网站sns.com中发表一张帖子，在帖子中Jerry插入一行类似的html代码

image.png

image.png

Tom在浏览器的另外一个标签页中查看Jerry的这条消息　　
Tom的浏览器将Jerry伪造的转账请求发送给affectedBank，从而转出1000元到Jerry的账户。　　
流程如图1所示。　　
上述例子当中的转账操作是通过GET请求方式执行，在实际中可能会更多使用POST的方式。受攻击站点只接纳使用POST方式请求，表面上已 经不能直接将伪造请求包装在其他网站中，但黑客仍然可以使用重定向的方式将社交网站中GET的请求指向一个封装POST的页面，从而实现POST请求组合 与提交。　　
在上述例子中进行一些扩展：　　
A. Jerry在自己控制的站点evil.com中构造一个页面Redirector.php。将使得外部通过GET请求Redirector.php而来的 参数在页面中重新组合出表单的内容，再通过页面内的JavaScript提交到www.affectedBank.com/Transfer.php中。　　
B. 在sns.com的帖子中包装一个不可见的GET请求，申请访问Redirector.php。类似于

image.png

image.png

C. Tom在访问帖子时，实际将执行两次请求，第一次是GET请求跳转到Redirector页面，第二次是POST请求将数据提交到affectedBank.com/Transfer.php。　　
流程如图2所示：　　　
图2 重定向实现POST请求的CSRF　　
直接利用GET请求Redirector.php页面容易暴露黑客的攻击意图，Jerry可以在Evil.com的Web服务器中设置一个 Rewrite功能，将请求而来的face.png重写为http：//www.evil.com/Redirector.php？csrf= http：//www.affectedBank.com/Transfer.php？toAccount=Jerry&money=1000， 这样在sns.com发帖时的引用部分就可以直接写成“http：//www.evil.com/face.png”，使得攻击更加隐蔽。
　　3 跨站请求伪造的基本原理　　
从上述的跨站请求伪造攻击的场景中，有三个引发攻击形成的必要条件。　　
1） 浏览器会自动发送用户标识的会话信息，并且用户毫不知情也无法干预。换而言之，用户不知道浏览器发送的内容中，已经包含身份标识信息。身份标识信息（例如 cookie）主要是站点用于识别受认证用户的一个标志。如果站点收到带有受害者认证信息的请求，那么这个请求就会被看作是已登录的受害者发送而来的正确 操作请求。　　
2） 攻击者清楚在被攻击网站的特殊敏感操作的URL结构，并能分析其中所支持的参数和允许值。一般而言，通过访问被攻击Web应用程序，查看潜入在HTML或 JavaScript中的URL、分析提交的表单结构就可以了解到相应的信息。如果是一个开源项目，攻击者直接就可以从源代码中进行分析提取可以攻击的特 殊敏感操作。　　
3） 被攻击网站完全依赖于会话信息识别用户。因为会话信息其实对浏览器而言是透明的，浏览器只负责存放和在发送请求时附加相关的会话信息，通过浏览器并不能解 析出会话信息的内容。为了提高Web应用的便利性，降低开发的成本，部分Web应用就会完全依赖这类信息来标识一个用户会话。从而导致Web应用程序不会 判断一个请求是否真是由合法用户发送的。　　
一般来说，要发生跨站请求伪造攻击，需要有以下几个特点：　　
1） 在受攻击站点已经登录，且没有正常退出。　　
2） 受攻击站点的会话失效时间比较长。而且失效时间越长受攻击机率越高。　　
3） 受攻击站点的特殊敏感操作没有严谨的用户身份标识验证。　　
4） 受害者主动访问含有伪造请求的页面。电子邮件、论坛、博客等常见的互联网应用都是攻击者可利用的社会工程学的范围。
　　4 跨站请求伪造防范的主要方法　　
要做好攻击的防范，首先需要明确攻击的目标。跨站请求伪造攻击的对象，就是要保护的对象。从上文的分析可知，跨站请求伪造攻击是黑客利用受害 者浏览器中包含的用户身份认证信息骗取服务器的信任，但是黑客其实并不能拿到身份认证的具体凭证，也看不到身份认证的内容。另外，由于浏览器同源策略的限 制，黑客也无法进行解析查看从受攻击服务器响应回来的内容。因此，黑客无法从服务器响应中得到任何东西。他所能做的仅仅是给服务器发送请求，以执行请求中 所包含的特殊敏感操作，从而达到在服务器端直接更改数据，并非窃取服务器的敏感信息或受害者的个人资料。
　　因此，针对跨站请求伪造攻击要保护的对象是那些可以直接影响数据改变的操作或服务，其他仅仅读取信息的操作或服务，则不需要进行跨站请求伪造 攻击的防范。例如上文中的银行系统，查询余额是仅仅返回读取到的金额数，跨站请求伪造攻击无法拦截服务器返回的结果，不需要防范。而转账的操作会涉及改变 账户的金额，有遭受跨站请求伪造攻击的威胁，需要保护。
　　一般的攻击防范，都可以从服务端和客户端两方面入手，因为跨站请求伪造主要是针对服务端的欺骗，所以这里攻击的防范主要在服务端进行。防范的核心思想则是在服务器端不唯一依靠浏览器所直接提交的身份认证信息，而需要添加额外的校验信息。主要的实现方式有以下几种。　　
1） 验证 HTTP Referer。在 HTTP 协议的请求头部含有一个字段叫 Referer，它记录了本次请求的来源地址。只需校验Referer是否以本域作为来源，则可以判断这个请求的真伪。
　　这种方式的优点在于简单易用，开发人员只需用在敏感操作前增加一个拦截器检查Referer的值即可。对于已有的系统，不需要改动内部的逻 辑，比较方便。但这种方法并不是百分百有效。每个浏览器对HTTP协议的实现有一些差别，目前已经发现，IE6的浏览器Referer的值是可以被篡改。 对于新版浏览器，虽然无法纂改Referer值，但部分用户基于隐式权的需要，可以设置浏览器发送的请求不包含Referer信息。这些用户在访问时会被 误认为伪造的请求，从而拒绝了合法用户的访问。　　
2） 加密cookie信息。在敏感操作的提交内容中，添加一个对cookie进行Hash后的值，服务器端对Hash值进行校验，若通过则是合法的用户请求。 因为在直接的跨站请求伪造攻击中，黑客其实是无法获取cookie的具体内容，因此也无法构造一个Hash后的cookie值，从而基本杜绝了跨站请求攻 击的实施。但是这种方法还有一种可能的泄露情况。如果黑客先通过XSS攻击盗取了用户的cookie，然后再利用盗取的cookie生成Hash值而制作 伪造请求。这种情况的攻击实现比较繁琐复杂，涉及到XSS和CSRF两种攻击的结合使用。　　
3） 使用令牌。添加一个隐藏表单域记录随机的令牌，在求的参数中包含该令牌。服务器端执行操作前验证这个令牌，如果请求中没有令牌或者内容不正确，则认为可能 是伪造请求攻击而拒绝该请求。这种方法也可以完全解决请求伪造的问题。但在一个网站中，需要防范的地方非常多，要求每一个请求都加上令牌会增加了开发人员 的工作量，而且还很容易遗漏。　　
4） 在 HTTP 头中自定义属性。为了解决上一个方法设置Token比较麻烦的问题，可以将令牌放到 HTTP 头中自定义的属性里。利用XMLHttpRequest这个对象，一次性为所有敏感操作在请求头增加一个新的属性，该属性的值则是一个令牌。这种添加令牌 的方式比上一种方法简单。而且，通过 XMLHttpRequest请求的地址不会被记录到浏览器的访问历史，不用担心令牌会透过Referer被窃取。这种其实是使用Ajax方法在页面局部 的异步刷新的操作，令牌在前进，后退，收藏等行为中将失效，而且如果是遗留系统，添加Ajax请求的方法等同重新设计整个系统，代价过高。
　　此外，还有一些措施加固防范。如：在每次敏感操作都弹出对话框需要用户进行二次确认。服务器端将用户会话的失效时间设置得较短一些。用户自己养成习惯，在一个站点操作完成后，马上退出登录以撤销认证会话。
　　5 总结
　　跨站伪造请求攻击的威胁虽然比较大，但是其原理与机制相对集中。只要把握其无法伪造的一些信息，就可以有效的防范该类攻击。在防范伪造请求攻 击的方法选用时，注意选择最有效而且代价最少的方案，不能盲目追求技术的先进或复杂，而且在先满足系统的安全需要的前提下，尽量做到用户的易用性和系统的 安全性的平衡。Web应用的安全威胁层出不穷，在系统设计的时候需要注意做好安全漏洞的测试，以防止用户和企业不必要的损失。
本文章来源于：http://www.qklw1.com/article-3847.html 转载请注明来路，谢谢合作