4.4 CSRF防御

Posted 白帽子养成记

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了4.4 CSRF防御相关的知识,希望对你有一定的参考价值。

二次确认

  • 在调用某些功能时进行二次验证,

  • 如:删除用户时,产生一个提示对话框,提示“确定删除用户吗?”。

  • 转账操作时,要求用户输入二次密码,设置验证码,在进行敏感操作时输入验证码。

  • 当二次验证后,即使用户打开了 CSRF POC页面,也不会直接去执行,而需要用户再次输才可以完成攻击。

  • 这样,当用户突然收到提示后,可能会心存怀疑,就不再会乖乖地中招。

Token 认证原理

Token即标志、记号的意思,在IT领域也叫作令牌。

CSRF攻击成功的两个要素:

  • 攻击者可得知URL的所有参数项,并了解其含义;

  • 诱导用户访问构造好的POC。

验证码的验证思路

  • 在服务器端生成验证字符串并保存在 Session中,

  • 然后在客户端使用图片显示这段字符串,

  • 当用户输入验证码之后交给服务器处理,

  • 如果验证码与 Session中的字符串相匹配,

  • 就代表验证码正确,可以发起请求,反之亦然。

Token的验证思路

  • 当用户登录Web应用程序后

  • 首先,服务器端会随机产生一段字符串分配给此用户,

  • 并且存储在 Session中,

  • 当用户进入某些页面时,直接传递在用户界面或者 Cookie中。

  • 如果在html中,那么为了用户体验更好,一般都会隐藏起来,如

<input type="hidden" name="token" value="6wku2jsdoi7ewOs"/>
  • 当用户进行提交表单操作时,这段 token代码也会随之被提交。

  • 当服务器端接收到数据时,就会判断这段“验证码”是否与 Session中存储的字符串一致,

  • 如果一致,则认为是合法的请求

  • 如果不一致,则有可能是CSRF攻击。如图所示,表单中就存在一个隐藏的 Token

注意:

有时用户进行一些操作可能不需要提交表单,

比如删除用户操作,仅仅发出一个GET请求即可:

  • 这样fom表单中插入 Token就不合适

  • 通常会在 Cookie中存储 Token

  • 因为无论是GET请求还是POST请求,只要向服务器进行请求,那么一般都会带入 Cookie,

  • 这样就解决了GET请求传入 Token值的问题,

Token防御CSRF步骤

第一步  每当用户登录后会随机生成一段字符串,并且存储在 Session中。

第二步 在敏感操作中加入隐藏标签, value即为 Session中保存的字符串,如

<form action="addUser.action" method="GET"
账号:< input type="text" name=" username”/><br/>
密码:< input type=" password" name=" password”/><br/>
确认密码:< input type=" password" name=" password2”/><br/>
< input type="hidden" name="token" va1ue="3a8d9fxos8v8"/><br/>
<input type="submit" value=”添加">
</form>
注:如果为GET请求,考虑使用在 Cookie中存储 Token。

第三步 提交请求后,服务器端取出 Session中的字符串与提交的 Token对比,

如果一致,则认为是正常请求,否则可能是CSRF攻击。

第四步 更新 Token值。

注意:

  • 当网站同时存在XSS、CSRF漏洞时, Token防御机制将会失效,因为攻击者可以通过 Java Script获取 Token值。

  • 所以在防范CSRF时,首先需要确定网站是否存在ⅹSS漏洞,如果网站存在XSS漏洞那么防范CSRF是没有任何意义的。

摘抄


一盏一直亮着的灯,

你不会去注意,

但是如果她一亮一灭,

你就会注意到。

   ------刘墉



以上是关于4.4 CSRF防御的主要内容,如果未能解决你的问题,请参考以下文章

用代码来细说Csrf漏洞危害以及防御

spring security4.2 配置CSRF防御场景

六十五:CSRF攻击与防御之CSRF防御之form表单防御

CSRF的攻击与防御

CSRF的攻击与防御

CSRF学习笔记之CSRF的攻击与防御以及审计00x2