1. CSRF
- CSRF: Cross-site request forgery, 跨站请求伪造，也被称为one-click attack或者session riding, 通常缩写为CSRF或者XSRF。
- 是一种挟持用户在当前已登陆的web应用程序上执行非本意的操作的攻击方法。
- 跟跨网页脚本(XSS)相比，XSS利用的是用户对特定网站的信任，CSRF利用的是网站对用户网页浏览器的信任。
Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts. There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting(XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.
2. 攻击的细节
- 跨站请求攻击，简单地说，就是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作(如发邮件，发消息，甚至财产操作如转账和购买商品)。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这里用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。
2.1 攻击过程
- 浏览者C登陆信任网站A。
- 验证通过，在用户C处产生A的cookie并存储在本地。
- 用户在没有登出A网站的情况下，访问危险网站B。
- 危险网站B要求用户C的浏览器访问第三方站点A，发出一个请求。
- 根据危险网站B的要求，用户C的浏览器带着验证通过后产出的Cookie访问网站A。
- 网站A不知道这个请求是用户C的浏览器发出的，还是危险网站B发出的。因为浏览器会自动带上用户C的Cookie，所以网站A会根据用户的权限处理请求，这样网站B就达到了模拟用户操作的目的。
3. 防御方法
3.1 检查Referer字段
- HTTP头中有一个Refer字段，这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时，通常来说，Referer字段应和请求的地址位于同一域名下。以转账为例，Referer字段地址通常应该是转账按钮所在的网页地址，应该也位于www.example.com下。如果是CSRF攻击传来的请求，Referer字段会是包含恶意网址的地址，不会位于www.example.com之下，这时候服务器就能识别出恶意的访问。
3.2 添加校验token
- 由于CSRF的本质在于攻击者欺骗服务器，使服务器认为请求是经过验证的用户发送的。所以如果要求在访问敏感数据请求时，要求用户浏览器提供不保存在cookie中，并且攻击者无法伪造的数据作为校验，那么攻击者就无法再执行CSRF攻击。这种数据通常是表单中的一个数据项。服务器将其生成并附加在表单中，其内容是一个伪乱数(每次产生的值都不同)。当客户端通过表单提交请求时，这个伪乱数也一并提交上去以供验证。正常的访问时，客户端浏览器能够正确得到并传回这个伪乱数，而通过CSRF传来的欺骗性攻击中，攻击者无从事先得知这个伪乱数的值，服务器端就会因为校验token的值为空或者错误，拒绝这个可疑请求。
4. django中出现csrf验证失败解决办法
4.1 在django 项目的setting中将csrf中间件屏蔽，不推荐！
MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
#'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
]
4.2 在form表单中添加{% csrf_token%}
- 在使用post方法的form中添加{% csrf_token %}
<div class="container">
<div class="login">
<label>用户登录</label>
<form method="post" action="/user/login/">
{% csrf_token %}
账号:<input type="text" maxlength="20" name="username"><br>
密码:<input type="password" maxlength="20" name="password"><br>
<span style="color: red;">{{ error }}</span>
<input type="submit" value="登录">
</form>
</div>
</div>
- 在实际运行过程中，csrf_token被替换成了如下代码
<div class="container">
<div class="login">
<label>用户登录</label>
<form method="post" action="/user/login/">
<input type='hidden' name='csrfmiddlewaretoken' value='HedcdWXjTwCxyVOd4d8MKLmiCTHZpmU0X0nkQ6dzbBcMawOAwkNdDjZtariC2i1B' />
账号:<input type="text" maxlength="20" name="username"><br>
密码:<input type="password" maxlength="20" name="password"><br>
<span style="color: red;"></span>
<input type="submit" value="登录">
</form>
</div>
</div>
- 我使用的django版本是1.11.6。通过使用Fiddler软件抓包分析，在通信过程中发现请求头中cookie字段有了csrftoken值。
Request sent 137 bytes of Cookie data:
__lnkrntdmcvrd=-1
csrftoken=Htr860vr38EaEumkfWuvEoW3BmyXInDcXfBgJaLHldepg5mHH39WxWze9U9AljKN
sessionid=qjt57gldisr5gb6x5k663l9tv1axl86f
因此可以得出结论django中的csrf验证需要form中的隐藏字段和cookie中的csrftoken一同发给服务器完成csrf验证。
P.S.
- 前端中没有绝对的安全，前端中浏览器和服务器通信过程中的数据都是可以伪造的。
