框架与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字段，比如 <input type=hidden
name="anti_csrf_token" value="$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。
<form action="."
method="post">{% 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://www.cnblogs.com/broadview/archive/2012/04/09/2439203.html
