Web安全之CSRF(跨站请求伪造)

CSRF(跨站请求伪造)概述

Cross-site request forgery 简称为“CSRF”,在CSRF的攻击场景中攻击者会伪造一个请求(这个请求一般是一个链接),然后欺骗目标用户进行点击,用户一旦点击了这个请求,整个攻击就完成了。所以CSRF攻击也成为"one click"攻击。 很多人搞不清楚CSRF的概念,甚至有时候会将其和XSS混淆,更有甚者会将其和越权问题混为一谈,这都是对原理没搞清楚导致的。

CSRF与XSS的区别:CSRF是借用户的权限完成攻击,攻击者并没有拿到用户的权限,而XSS是直接盗取到了用户的权限,然后实施破坏。

如何确认一个web系统存在CSRF漏洞:

1.对目标网站增删改的地方进行标记,并观察其逻辑,判断请求是否可以被伪造

  •   ****比如修改管理员账号时,并不需要验证旧密码,导致请求容易被伪造;
  •   ****比如对于敏感信息的修改并没有使用安全的token验证,导致请求容易被伪造;

2.确认凭证的有效期(这个问题会提高CSRF被利用的概率)

  •   ****虽然退出或者关闭了 浏览器,但cookie仍然有效 ,或者session并没有及时过期 ,导致CSRF攻击变的简单;

CSRF(get)

打开pikachu的CSRF(get)页面,输入账号密码,修改个人信息,然后到burp中抓包查看

 

 我们可以看到后台并没有一些防CSRF的措施,同时有时通过get请求来提交的

接来下我们只需要获取到网站修改个人信息的get请求链接,把信息修改成我们想要修改的信息,发送给用户就可以了,一旦用户点击攻击就完成了

 http://127.0.0.1:88/pikachu/vul/csrf/csrfget/csrf_get_edit.php? sex=girl&phonenum=12345678922&add=wuhan&email=lucy%40pikachu.com&submit=submit 

 

 CSRF(post)

打开pikachu的CSRF(post)页面,登入账号密码,修改个人信息,然后打开burp抓包查看

 

 

可以看到请求是以post方式提交的,所有的参数都在请求体里传输的,无法利用url来伪造请求

这个是之前post型的xss方式是一样的,我们构造一个自己的站点,在这个站点上做一个表单,然后让用户去点我们恶意站点的表单url

利用这表单的url去向网站的后台提交请求

相应的恶意站点后台文件,把里面相应的信息修改成我们想要的,

 

 将我们伪造表单的url /http://127.0.0.1:88/pikachu/vul/csrf/csrfpost/csrf_post.php 发给用户,诱使用户点击,一旦用户点击我们的攻击就完成了

 

 CSRF(token)的防范措施

CSRF的主要问题是敏感操作容易被伪造,可以加通过加入Token让请求不容易被伪造

  • 即每次都增加一个随机码(需要够随机,不容易被伪造),后台每次对这个随机码进行验证!

我们登入pikachu平台的CSRF(token)页面,修改个人信息,然后burp中抓包查看个人信息修改的get请求

 

 可以看到和之前相比这里多一个token值,来防CSRF的

接下来我们看看前端如何拿到token,以及如何提交给后端验证的

 

 每次用户后台都会生成一个token,用户做一些敏感操作后台都回去验证这个token,这样就有效的防范了CSRF攻击

CSRF的防范措施

增加Token验证(常用做法):

  1. 对关键操作增加token参数,token值必须随机,每次都不一样;

关于安全的会话管理(避免会话被利用) :

  1. 不要在客户端端保存敏感信息(比如身份认证信息) ;
  2. 测试直接关闭,退出时,关闭浏览器的会话过期机制;
  3. 设置会话过期机制,比如15分钟内无操作,则自动登录超时;

访问控制安全管理:

  1. 敏感信息的修改时需要对身份进行二次认证,比如修改账号时,需要判断旧密码;
  2. 敏感信息的修改使用post,而不是get ;
  3. 通过http头部中的referer来限制原页面;

增加验证码:
一般用在登录(防暴力破解) , 也可以用在其他重要信息操作的表单中(需要考虑可用性);

posted @ 2020-07-28 17:25  墨尐丶小傲  阅读(400)  评论(0编辑  收藏  举报