框架与CSRF防御

框架与CSRF防御

CSRF攻击的目标，一般都会产生“写数据”操作的URL，比如“增”、“删”、“改”；而“读数据”操作并不是CSRF攻击的目标，因为在CSRF的攻击过程中攻击者无法获取到服务器端返回的数据，攻击者只是借用户之手触发服务器动作，所以读数据对于CSRF来说并无直接的意义（但是如果同时存在XSS漏洞或者其他的跨域漏洞，则可能会引起别的问题，在这里，仅仅就CSRF对抗本身进行讨论）。

因此，在Web应用开发中，有必要对“读操作”和“写操作”予以区分，比如要求所有的“写操作”都使用HTTP POST。

在很多讲述CSRF防御的文章中，都要求使用HTTP POST进行防御，但实际上POST本身并不足以对抗CSRF，因为POST也是可以自动提交的。但是POST的使用，对于保护token有着积极的意义，而security token的私密性（不可预测性原则），是防御CSRF攻击的基础。

对于Web框架来说，可以自动地在所有涉及POST的代码中添加token，这些地方包括所有的form表单、所有的Ajax POST请求等。

完整的CSRF防御方案，对于Web框架来说有以下几处地方需要改动。

（1）在Session中绑定token。如果不能保存到服务器端Session中，则可以替代为保存到Cookie里。

（2）在form表单中自动填入token字段，比如 。

（3）在Ajax请求中自动添加token，这可能需要已有的Ajax封装实现的支持。

（4）在服务器端对比POST提交参数的token与Session中绑定的token是否一致，以验证CSRF攻击。

在Rails 中，要做到这一切非常简单，只需要在Application Controller中增加一行即可：

protect_from_forgery :secret => "123456789012345678901234567890..."

它将根据secret和服务器端的随机因子自动生成token，并自动添加到所有form和由Rails生成的Ajax请求中。通过框架实现的这一功能大大简化了程序员的开发工作。

在Django中也有类似的功能，但是配置稍微要复杂点。

首先，将 django.middleware.csrf.CsrfViewMiddleware 添加到 MIDDLEWARE_CLASSES中。

('django.middleware.common.CommonMiddleware',

 'django.contrib.sessions.middleware.SessionMiddleware',

 'django.middleware.csrf.CsrfViewMiddleware',

 'django.contrib.auth.middleware.AuthenticationMiddleware',

 'django.contrib.messages.middleware.MessageMiddleware',)

然后，在form表单的模板中添加token。

{% csrf_token %}

接下来，确认在View层的函数中使用了django.core.context_processors.csrf，如果使用的是 RequestContext，则默认已经使用了，否则需要手动添加。

from django.core.context_processors import csrf

from django.shortcuts import render_to_response

 

def my_view(request):

    c = {}

    c.update(csrf(request))

    # ... view code here

    return render_to_response("a_template.html", c)

这样就配置成功了，可以享受CSRF防御的效果了。

在 Ajax请求中，一般是插入一个包含了token的HTTP头，使用HTTP头是为了防止token泄密，因为一般的JavaScript无法获取到HTTP头的信息，但是在存在一些跨域漏洞时可能会出现例外。

下面是一个在Ajax中添加自定义token的例子。

$(document).ajaxSend(function(event, xhr, settings) {

    function getCookie(name) {

        var cookieValue = null;

        if (document.cookie && document.cookie != '') {

            var cookies = document.cookie.split(';');

            for (var i = 0; i < cookies.length; i++) {

                var cookie = jQuery.trim(cookies[i]);

                // 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;

    }

    function sameOrigin(url) {

        // url could be relative or scheme relative or absolute

        var host = document.location.host; // host + port

        var protocol = document.location.protocol;

        var sr_origin = '//' + host;

        var origin = protocol + sr_origin;

        // Allow absolute or scheme relative URLs to same origin

        return (url == origin || url.slice(0, origin.length + 1) == origin + '/') ||

            (url == sr_origin || url.slice(0, sr_origin.length + 1) == sr_origin + '/') ||

            // or any other URL that isn't scheme relative or absolute i.e relative.

            !(/^(\/\/|http:|https:).*/.test(url));

    }

    function safeMethod(method) {

        return (/^(GET|HEAD|OPTIONS|TRACE)$/.test(method));

    }

 

    if (!safeMethod(settings.type) && sameOrigin(settings.url)) {

        xhr.setRequestHeader("X-CSRFToken", getCookie('csrftoken'));

    }

});

在Spring MVC以及一些其他的流行Web框架中，并没有直接提供针对CSRF的保护，因此这些功能需要自己实现。

 

本文节选自《白帽子讲Web安全》一书。

图书详细信息:http://blog.chinaunix.net/uid-13164110-id-3156623.html