安全测试之跨站请求伪造攻击

愿关注我们的人都能找到高薪工作

一、CSRF攻击的概念

CSRF（Cross Site Request Forgery, 跨站请求伪造）是一种网络攻击方式，该攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在并未授权的情况下执行在权限保护之下的操作，对用户的安全及网站的安全具有很大的危害性。

一、CSRF攻击的原理

如下图所示，CSRF攻击的原理比较容易理解，其中Web A是存在CSRF漏洞的网站，Web B是攻击者构造的恶意网站，User为Web A的合法用户。

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

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

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

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

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

三、CSRF攻击和XSS攻击是同一个概念吗？

CSRF和XSS不是同一个概念，两者还是有一定的区别的，CSRF是对网站的恶意利用。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。CSRF攻击通过在授权用户访问的页面中包含链接或者脚本的方式工作。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。

四、CSRF攻击的危害？

攻击者可以盗用了你的身份，以你的名义发送恶意请求。CSRF的危害包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账……造成的问题包括且不局限于：个人隐私泄露以及财产安全。

五、造成CSRF攻击的原因

跨站请求伪造能否成功，与以下几个方面有很大的关系：

1. 浏览器对会话的处理

Web浏览器对于Cookie和HTTP身份验证信息之类的会话信息的处理方式，目前，浏览器会自动地发送标识用户对话的信息，而无需用户干预，换句话说，当浏览器发送这些身份信息的时候，用户根本感觉不到。

假设站点A上有一个Web应用程序，并且受害者正好已经在该站点上通过了身份认证，这时，站点会向受害者发送一个cookie作为响应，这个cookie的作用是什么呢？主要是被站点作为用户会话的标志，即如果站点收到了带有受害者的cookie的请求，那么它就会把这个请求看作是已登录的受害者发来的。一般情况下，浏览器收到站点设置的cookie之后，每当向该站点发送请求的时候，浏览器都会“自动地”连同该cookie一起发出。

2. 攻击者对WEB应用有关URL的了解

如果应用程序没有在URL中使用跟会话有关的信息的话，那么通过代码分析或者通过访问该应用程序并查看嵌入HTML/JavaScript中的URL以及表单来了解应用程序有关的URL、参数和容许值。

3. 应用程序赖以管理会话的信息对浏览器的透明性以及各种能够引发资源请求HTML标签等

我们知道，为了提高Web应用的便利性，用来管理会话的信息，例如Cookie或者基于HTTP的身份验证（例如HTTP基本认证、非基于表单的认证）等敏感信息，都是由浏览器来存放的，并在每当向需要身份验证的应用程序发送请求时自动捎带上这些信息。也就是说，浏览器可以访问会话管理信息，如果Web应用程序完全依赖于这类信息来识别一个用户会话，这就为跨站请求伪造创造了条件。

4. 存在多种HTML标签

上面所说的三个因素，是跨站请求伪造攻击的必要的条件，而第四个因素，即使没有它也能发动跨站请求伪造攻击，但是有了它能使该攻击更加容易。这就是存在多种HTML标签，如果页面内出现这些标签，会立刻引起浏览器对http[s]资源的访问，例如图像标签img便是其中之一。（例如;(img src=”https://www.company.example/action” width=”0” height=”0”),这个img标签，因为其将width设置为0所以在页面上是显示不出来的，但是这个img所携带的命令仍然能够跟随页面的打开执行一些恶意代码。）

六、CSRF攻击的实例

小明如果遭受 CSRF 攻击严重的有如下现象，情景假设： 小明早上起来登录了 shopping.com 购物网站； 在登录后同时在新的标签中打开了一个恶意（malicious）网站，并点击了里面的一个按钮或者图片； 回到 shopping.com 的时候发现，他账户里的钱少了 ￥1000。 上面的只是情景假设，一般的购物网站不会这样单纯。

试着看看里面它是如何工作的：

小明成功登录了 shopping.com 网站，他的浏览器保存了浏览器产生的一个 cookie，注意此 cookie 中保存了某些登录信息或者授权信息。同时我们假设：shopping.com 服务器向账户 「123456」转账 ￥1000 的接口是： http://shopping.cm/Transfer.html?toAccount=123456&money=1000

产生的 HTTP 请求可能是：

未名攻击者特地写了个带图片的链接，可以是下面的形式：

小明傻乎乎的点击打开，于是浏览器尝试装载图片的时候，同时提交了小明的 cookie。服务器收到此请求，验证 cookie 正确后，于是修改了数据，即给账户「123456」转账 ￥1000.没错，在装载图片过程中会产生上面形式的 HTTP 请求。

电商 shopping.com 不会简单的发送 HTTP GET 请求转账，HTTP GET 本身基因就决定他必须把参数暴露在链接中。那采用安全点的 POST 如何？编写一个 method 为 POST 的表单就达到目标。以上的情况严重点，CSRF 稍微好一点的情景是通由小明在某个站点上的登录，提交一个评论。

七、CSRF攻击的防御措施

针对CSRF攻击的防范措施可以分为：服务器端的防御、用户端的防御和安全设备的防御。因为本人是测试的，所以这里重点讲关于在服务器端的防御措施。

1. 服务器端的防御措施

（1）验证HTTP Referer字段

根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。在通常情况下，访问一个安全受限页面的请求必须来自于同一个网站。

比如某银行的转账是通过用户访问http://bank.com/XX?XX=xx&XX=xx页面完成，用户必须先登录bank.com，然后通过点击页面上的按钮来触发转账事件。当用户提交请求时，该转账请求的Referer值就会是转账按钮所在页面的URL(本例中，通常是以bank.com域名开头的地址)。而如果攻击者要对银行网站实施CSRF攻击，他只能在自己的网站构造请求，当用户通过攻击者的网站发送请求到银行时，该请求的Referer是指向攻击者的网站。

因此，要防御CSRF攻击，银行网站只需要对于每一个转账请求验证其Referer值，如果是以bank.com开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果Referer是其他网站的话，就有可能是CSRF攻击，则拒绝该请求。

（2）在请求地址中添加token并验证

CSRF攻击之所以能够成功，是因为攻击者可以伪造用户的请求，该请求中所有的用户验证信息都存在于Cookie中，因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的Cookie来通过安全验证。

由此可知，抵御CSRF攻击的关键在于：在请求中放入攻击者所不能伪造的信息，并且该信息不存在于Cookie之中。

鉴于此，系统开发者可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token内容不正确，则认为可能是CSRF攻击而拒绝该请求。

（3）在HTTP头中自定义属性并验证

自定义属性的方法也是使用token并进行验证，和前一种方法不同的是，这里并不是把token以参数的形式置于HTTP请求之中，而是把它放到HTTP头中自定义的属性里。通过XMLHttpRequest这个类，可以一次性给所有该类请求加上csrftoken这个HTTP头属性，并把token值放入其中。

这种方法解决了前一种方法在请求中加入token的不便，同时，通过这个类请求的地址不会被记录到浏览器的地址栏，也不用担心token会通过Referer泄露到其他网站。

2. 其他方式的防御措施

（1）CSRF攻击是有条件的，当用户访问恶意链接时，认证的cookie仍然有效，所以当用户关闭页面时要及时清除认证cookie，对支持Tab模式(新标签打开网页)的浏览器尤为重要。

（2） 尽量少用或不要用request()类变量，获取参数指定request.form()还是request. querystring ()，这样有利于阻止CSRF漏洞攻击，此方法只不能完全防御CSRF攻击，只是一定程度上增加了攻击的难度。