CSRF（跨站请求伪造）攻击 --

CSRF（跨站请求伪造）攻击

CSRF(Cross Site Request Forgery,跨站请求伪造)是一种近年来才逐渐被大众了解的网络攻击方式，又被称为One-Click Attack或Session Riding。

攻击原理

CSRF攻击的大致方式如下：某用户登录了A网站，认证信息保存在cookie中。当用户访问攻击者创建的B网站时，攻击者通过在B网站发送一个伪造的请求提交到A网站服务器上，让A网站服务器误以为请求来自于自己的网站，于是执行响应的操作，该用户的信息边遭到了篡改。总结起来就是，攻击者利用用户在浏览器中保存的认证信息，向对应的站点发送伪造请求。用户的认证是通过保存在cookie中的数据实现，在发送请求是，只要浏览器中保存了对应的cookie，服务器端就会认为用户已经处于登录状态，而攻击者正是利用了这一机制。

攻击示例

假设我们网站是一个社交网站（example.com），简称网站A，攻击者的网站可以是任意类型的网站，在我们的网站中，删除账户的操作通过GET请求执行，使用下面的视图处理：

@app.route('/account/delete')
def delete_account():
    if not current_user.authenticated:
        abort(401)
    else:
        current_user.delete()
    return 'Deleted'

 

当用户登录后，只要访问http://example.com/account/delete就会删除账户。那么在攻击者的网站上，只要创建一个显示图片的img标签，其中的src属性加入删除账户的URL:

<img src=”http://example.com/account/delete”>

当用户访问B网站时，浏览器在解析网页时会自动向img标签的src属性中的地址发送请求。此时你在A网站的登录信息保存在cookie中，因此，仅仅是访问B网站的页面就会让你的账户被删除掉。

当然，现实中很少有网站会使用GET请求来执行包含数据更改的敏感操作，这里只是一个示例。

现在，假设我们吸取了教训，改用POST请求提交删除账户的请求。尽管如此，攻击者只需要在B网站中内嵌一个隐藏表单，然后设置在页面加载后执行提交表单的javaScript函数，攻击仍然会在用户访问B网站时发起。

防范措施

正确使用HTTP方法

防范CSRF的基础就是正确使用HTTP方法。在普通的Web程序中，一般只会用到GET和POST方法。而且目前在HTML中仅支持GET和POST方法（借助AJAX则可以使用其他方法）。在使用HTTP方法时，通常应该遵循下面 的原则：

1、 GET方法输入安全方法，不会改变资源状态，仅用于获取资源。页面中所有可以通过链接发起的请求都属于GET请求。

2、 POST方法用户创建、修改和删除资源。在HTML中使用form标签创建表单并设置提交方法为POST,在提交时会创建POST请求。

在GET请求中，查询参数用来传入过滤返回的资源，但是在某些情况下，也可以通过查询参数传递少量非敏感信息。

在删除资源时，应该将删除按钮内嵌在使用了POST方法的form元素中

CSRF令牌校验

当处理非GET请求时，要想避免CSRF攻击，关键在判断请求是否来自自己的网站。理论上讲，通过HTTP referrer可以判断原站点从而避免CSRF攻击，但是referer很容易被修改和伪造，所以不能作为主要的防御措施。

除了在表单中加入校验码外，一般的做法是通过在客户端页面中加入伪随机数来防御CSRF攻击，这个伪随机数通过被称为CSRF令牌（token）。

在计算机语境中，令牌（token）指用于标记、验证和传递信息的字符，通常是通过一定算法生成的随机数。

在HTML中，POST方法的请求通过表单创建。我们把在服务器端创建的伪随机数（CSRF令牌）添加到表单中的隐藏字段里和session变量（即签名cookie）中，当用户提交表单时，这个令牌会和表单数据一起提交。在服务器端处理POST请求时，会对表单中的令牌值进行验证，如果表单中的令牌值和seesion中的令牌值相同，就说明请求来自自己的网站。因为CSRF令牌在用户向包含表单的页面发起GET请求时创建，并且在一定时间内过期，一般情况下攻击者无法获取到这个令牌值，所以我们可以有效地区分出请求的来源是否安全。

 

对于AJAX请求，我们可以在XMLHttpRequest请求首部添加一个自定义字段X-CSRFToken来保存CSRF令牌。

 

如果程序存在XSS漏洞，那么攻击者可以使用javaScript窃取cookie内容，进而获取CSRF令牌。