Pikachu-CSRF模块

一、概述

Cross-site request forgery 简称为"CSRF",在CSRF的攻击场景中攻击者会伪造一个请求(这个请求一般是一个链接),然后欺骗目标用户进行点击,用户一旦点击了这个请求,整个攻击就完成了。所以CSRF攻击也成为"one click"攻击。

网站如果要防止CSRF攻击,则需要对敏感信息的操作实施对应的安全措施,防止这些操作出现被伪造的情况,从而导致CSRF。比如:

--对敏感信息的操作增加安全的token;

--对敏感信息的操作增加安全的验证码;

--对敏感信息的操作实施安全的逻辑流程,比如修改密码时,需要先校验旧密码等。

 

 

二、CSRF(get类型)

漏洞利用:

第一步:用户登陆

第二步:修改一下个人信息并提交,同时利用BurpSuite抓包查看修改个人信息的请求内容:

从提交的请求来看,后台没做CSRF token,同时也是通过GET请求来提交修改信息,我们拿到这个,修改一下,然后让lucy点击就好,我们构造的URL中把地址add改为hacker。lucy一点击就修改了地址。

http://192.168.5.100/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=girl&phonenum=12345678922&add=hack&email=lucy%40pikachu.com&submit=submit HTTP/1.1

   

这个看似很厉害,但是实际上满足条件比较严苛,比如lucy必须是登陆状态,而且防范意识较低,才可以。

另外这个与反射型的XSS也不同,反射型XSS可以获取用户cookie得到了shell,而get型CSRF并没有得到用户的shell。

   

   

三、CSRF(post)

登陆之后修改信息,发现post型并没有显示url中,抓包发现是以form表单的请求体提交:

 

漏洞利用:

思路:这里的攻击方式跟XSS中POST类型是类似的,攻击者可以搭建一个站点,在站点上做一个表单,诱导lucy点击这个链接,当用户点击时,就会自动向存在CSRF的服务器提交POST请求修改个人信息。

第一步:把攻击网页放在服务器上,诱骗受害者点击链接:

192.168.5.100/pikachu/pkxss/csrf/post.html

第二步:发现信息已经更改:

   

   

四、CSRF防范之token防御

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

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

我们进入Pikachu平台的CSRF(token)页面并登录,我们可以看一下这个GET请求

看下控制台源码,看下这个表单,每次点击修改个人信息 都会去访问 token_get_edit_.php 这个文件,这个文件就会生成一个token,value就是后端发过来的,type是隐藏的额,在前端看不到,但是在源码中能看到。每次点提交,token也会被提交到后台,后台会对token进行验证,如果和当前session里面的token相等,才会让你提交。

 

五、其他防范措施

1、增加token验证(常用的做法)

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

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

(1)不要再客户端保存敏感信息(比如身份认证信息);

(2)测试直接关闭,退出时的会话过期机制;

(3)设置会话国企机制,比如几分钟内误操作,自动登陆超时。

3、访问控制安全管理

(1)敏感信息的修改时需要对身份进行二次认证,例如:修改账号时,需要验证旧的密码。

(2)敏感信息的修改使用POST,而不是GET

(3)通过http投不中的referer来限制原页面。

4、增加验证码:

一般用在登陆(防暴力破解),也可以用在其他重要信息操作的表单中(需要考虑可用性)

原文地址:https://www.cnblogs.com/hzk001/p/12609178.html