Django DeleteView without confirmation template, but with CSRF attack

随便写点东西吧。

Django的Class based view十分好用,也很灵活。其中DeleteView( https://docs.djangoproject.com/en/1.10/ref/class-based-views/generic-editing/ )有点特别蛋疼的,他理想的流程是这样:点击删除 -> 跳转到确认页面 -> 点击确认删除 -> 删除对象 -> 跳转到success_url。

这样导致删除的流程特别麻烦,特别是这个“确认页面”:

sp161014_034704.png

因为“删除”是一个敏感操作,所以一定要有CSRF防御,所以点击上图这个“是的,我确认”按钮以后,会发送一个POST请求到后端的。Django会自动检查CSRF TOKEN。但实际上,我们也可以操作JavaScript向后端发送POST请求,而无需确认页面里的这个表单。

所以,我理想中的删除逻辑应该是这样的:点击删除 -> Javascript弹出确认框 -> 用户点击确认 -> Javascript生成一个表单 -> 提交 -> 跳转到success_url。

我写了个JavaScript函数,专门用来执行删除等需要POST的逻辑:

function submit(action_url) {
    if(!confirm('确认要执行这个操作?')) {
        return false;
    }
    var f = $('<form method="post"></form>');
    var xsrf = $("{% csrf_token %}");
    f.append(xsrf);
    f.prop('action', action_url);
    f.submit();
}

使用的时候,只要传入后端url作为action_url即可。

所以,我这个逻辑里面是不需要GET请求的,也就是说不需要写“确认删除”的模板,所以我上网上搜了一下如何才能不要这个模板: http://stackoverflow.com/questions/17475324/django-deleteview-without-confirmation-template ,果然是有人问过的。所以其实有很多人和我遇到同样的问题。

但我一看回答……:

sp161014_035750.png

很无语,直接把get导向post了,这样做必然会存在CSRF。因为 django.middleware.csrf.CsrfViewMiddleware 是不检查GET方法的:

sp161014_040011.png

准确来说,是不检查GET、HEAD、OPTIONS、TRACE方法。所以说,如果按照stackoverflow上面的事例来写代码的话,就是存在漏洞的。

另外,关于检查的方法。让我想到flask,flask-wtf有个小缺陷,默认情况下,它只检查POST/PUT/PATCH三个方法 https://github.com/lepture/flask-wtf/blob/f306c360f74362be3aac89c43cdc7c37008764fb/flask_wtf/csrf.py ,不知道开发者怎么想的。正常开发中,ajax请求里会存在很多DELETE方法,所以DELETE一定要检查CSRF TOKEN,否则很容易出现漏洞。

那么回到Django。既然上述做法会引发CSRF漏洞,那么我们怎么办?

我们分析一下问题,现在问题是:我们只需要POST方法,但默认的DeleteView要求提供GET和POST两个方法,并且GET方法需要一个模板,也就是“确认删除”这个页面的模板。如果我们不提供模板,用户在以GET方法访问这个页面的时候就会报错,但要写个模板,感觉多此一举,很不优雅。

(当然你可以无视报错,反正不影响正常使用,但作为一个强迫症我忍不了)

我们先分析一下Class based view的原理。Django的一个基类View类,其中有一个dispatch方法,所有的请求经由dispatch方法,再根据请求的方法具体分发到get、post、delete这样的函数里。

那么,一个请求允许哪些方法,是在_allowed_methods函数里定义的:

sp161014_041554.png

这个函数的意思就是:根据子类中定义过的方法名确定允许哪些方法。

比如,Django提供的BaseUpdateView类中定义了两个方法get和post:

sp161014_041811.png

所以,继承这个类的View一定允许GET和POST两种请求。而Python是个多继承语言,当它还继承了其他辅助类(Mixin),还可能会允许其他请求。那么,一旦用户的请求不在允许的范围内,就会调用http_method_not_allowed,具体现象就是返回405错误:

sp161014_043721.png

回到上面的问题,所以现在解决问题的方法就很明显了:重写get函数,让“GET”请求返回self.http_method_not_allowed()就可以了:

class LinkDeleteView(AdminPermissionMixin, DeleteView):
    model = Link
    success_url = reverse_lazy('management-link-list')
    permission_required = 'archives.delete_link'

    def get(self, request, *args, **kwargs):
        return self.http_method_not_allowed(request, *args, **kwargs)

就是这么简单。

或者,换个更调皮、更简略的写法:

class LinkDeleteView(AdminPermissionMixin, DeleteView):
    model = Link
    success_url = reverse_lazy('management-link-list')
    permission_required = 'archives.delete_link'

    get = DeleteView.http_method_not_allowed

想想为什么可以这么写,不懂的话可以看看Django源码,答案就在里面。

相关推荐: 如何判断目标站点是否为Django开发

老文一篇,几个月以前发在【代码审计】小密圈里的文章,当时是写一个系列(Django安全漫谈),抽出其中的一部分,分享一下。 在黑盒测试的情况下,如何判断一个站是否是Django开发的?以下这些方法,很多都能在我的博客( https://www.leaveson…

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论