CSRF 跨站请求伪造

2020-05-07 本文已影响0人代码表演艺术家

跨站请求伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 **CSRF **或者 XSRF，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。下面通过一个实例来说明：

假如在某个网站上，用户可以修改自己的邮箱地址，这个修改的操作是通过POST请求到服务器上的一个url，就像这样：

POST /email/change HTTP/1.1
Host: website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE

email=jack@normal-user.com

黑客研究了这个请求的规律后，自己搭建了这样一个页面：

<html>
  <body>
    <form action="https://website.com/email/change" method="POST">
      <input type="hidden" name="email" value="hijack@evil-user.net" />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

如果一个受害人进入了这个黑客页面，情况是：

1.这个页面在受害人完全不知情的情况下就往website.com 发送了修改邮箱的请求
2.如果受害人之前登录过website.com 网站，那么浏览器会自动带上website.com 网站的cookie(如果没有设置同源cookies的话)去请求website.com
3.服务器只认cookie, 看到黑客的请求里带有cookie, 就当作正常的请求处理了，网站就遭受到了黑客攻击。

django 的 CSRF防御

django项目默认会在setting 里的MIDDLEWARE 配置里添加csrf的防御中间件 'django.middleware.csrf.CsrfViewMiddleware'，原理是这样的：

django在cookie里放置一个键csrftoken，这是一个64位的字符串，每次向服务器提交数据的时候都会带上这个cookie值，同时，在post或put, delete 数据时，数据里要有csrfmiddlewaretoken 这个特殊的数据，在后台django会比较cookie里的csrftoken和请求数据里的csrfmiddlewaretoken是否匹配，如果匹配才会正常处理，否则直接报错。

django可以在form表单通过添加{% csrf_token %}来自动生成如下不可见的csrfmiddlewaretoken字段

<input type="hidden" name="csrfmiddlewaretoken" value="kdA7zoTmrLpZkRU30IsLxNxzJzCxrw9y2pY2OCAzeKteRRi9M9woQknJq2ImxTLN">

这个字段提交到后台时会通过CsrfViewMiddleware中间件来检查，不需要我们操作。

注意：上面提到的检查csrftoken和csrfmiddlewaretoken匹配的操作不是简单的逐字比较是否相同，因为如果你刷新你的表单，会发现表单的csrfmiddlewaretoken在变，而cookie里的csrftoken并没有变。
其实无论是csrftoken还是csrfmiddlewaretoken都是有两部分组成，一个随机的 salt 和秘文secret，通过对csrftoken和csrfmiddlewaretoken分别进行加盐揭秘，最后比较是否相等。

django ajax请求问题

因为自己在javascript 里构造的ajax请求没有csrfmiddlewaretoken 这个值，所以一般ajax 通过post,put,delele 请求到后台会报csrf缺少错误，怎么办？
网上很多的答案都是简单除暴的去掉csrf校验，比如通过删掉配置文件里的CsrfViewMiddleware中间件来全局禁用csrf,或者使用@csrf_exempt装饰器装饰view来局部禁用csrf校验，
但这些方法都是不安全的，就好像你每次回家都要掏钥匙开锁觉得太麻烦，然后干脆出门不锁门一样，没有真的解决问题，而是逃避问题。

正确的解决方法是在ajax请求里手动加上csrf，
比如在模板里写ajax, 这种比较简单，但是不灵活, 没法写到js 文件里，并且每一个ajax请求都是加上csrfmiddlewaretoken

$.ajax({
    data: {
        somedata: 'somedata',
        moredata: 'moredata',
        csrfmiddlewaretoken: '{{ csrf_token }}'
    },

另一种改进的方法是设置全局的ajax参数，后面的所有请求都不用再添加csrfmiddlewaretoken了

$.ajaxSetup({
  data: {csrfmiddlewaretoken: '{{ csrf_token }}' },
});

上面两种代码因为使用了django变量，所以还是必须要写在模板文件里，不完美。

完全脱离后端的方法是在js里获取cookie值，如下：

function getCookie(name) {
# 可以使用现成的js 库https://github.com/js-cookie/js-cookie/ 来代替getCookie这个函数
    var cookieValue = null;
    if (document.cookie && document.cookie !== '') {
        var cookies = document.cookie.split(';');
        for (var i = 0; i < cookies.length; i++) {
            var cookie = cookies[i].trim();
            // Does this cookie string begin with the name we want?
            if (cookie.substring(0, name.length + 1) === (name + '=')) {
                cookieValue = decodeURIComponent(cookie.substring(name.length + 1));
                break;
            }
        }
    }
    return cookieValue;
}
var csrftoken = getCookie('csrftoken');

function csrfSafeMethod(method) {
    // these HTTP methods do not require CSRF protection
    return (/^(GET|HEAD|OPTIONS|TRACE)$/.test(method));
}
$.ajaxSetup({
    beforeSend: function(xhr, settings) {
        if (!csrfSafeMethod(settings.type) && !this.crossDomain) {
            xhr.setRequestHeader("X-CSRFToken", csrftoken);
        }
    }
});

通过getCookie('csrftoken')获取cookie里的csrftoken，然后在$.ajaxSetup 设置请求头的X-CSRFToken 值(前面是设置请求体的csrfmiddlewaretoken)，
注意这里 function csrfSafeMethod 函数，不会对GET，HEAD，这些请求方式进行csrf保护。这就要求我们平时写代码时一定要遵守HTTP请求规范，不要在GET，HEAD，OPTIONS 这些请求里进行任何修改操作。有些人因为GET请求比较简单，把增删改查都用GET请求操作，虽然功能上可以实现，但是很危险，
举个经典的例子,假如你的网站有个链接是这样的：

href = "myAppDeleteImportantData.aspx?UserID=27"

并且google-bot出现并为您的页面编制索引？那么会发生什么？

CSRF 跨站请求伪造

django 的 CSRF防御

django ajax请求问题

猜你喜欢

热点阅读