常见的Web漏洞——CSRF

目录

CSRF简介

CSRF原理

CSRF攻击实例

防御措施

总结


CSRF简介

CSRF是跨站请求伪造(Cross-site request forgery)的缩写,和《三十六计》中的“借刀杀人”一样,只不过是攻击者借了受害者的“刀”将受害者“杀”了,简单来讲就是攻击者盗用受害者的身份,以受害者的身份去做自己想要的操作,如发邮件,修改密码,非法转账,获取隐私数据等。

CSRF原理

当用户访问一个存在CSRF漏洞的网站A,并登录该网站时,浏览器会生成一个Cookie,此时攻击者通过社会工程学或其他手段诱骗用户在登录网站A的浏览器访问含有恶意操作(如只允许授权用户修改密码,转账,对网站或数据库的增、删、改、查等操作)的网站B时,用户在毫不知情的情况下帮助攻击者完成了修改密码,转账等攻击者想执行的操作。

CSRF攻击实例

以DVWA中的CSRF为例,登录DVWA,设置安全等级为Low,然后点击CSRF,如图:

可以看到没有输入旧密码的输入框,简单尝试修改密码发现如果两个框中输入的字符串相同就可以修改密码,如果不相同就无法修改。然后查看源代码,如图:

 可以看到客户端使用GET提交参数后服务器端接收到用户提交的password_new和password_conf参数之后直接验证两者的值是否相同,如果相同就将新密码的MD5值插入数据库中,旧密码的MD5值。因此,直接构造payload:http://192.168.204.133/dvwa/vulnerabilities/csrf/?password_new=abc&password_conf=abc&Change=Change,然后发送给用户,当用户在新标签页中打开时,如图:

密码已被修改为abc ,而用户却毫不知情。当然,这样的链接可以骗过普通人,但是对于了解过互联网或信息安全相关知识的人来说这样的链接目的太明显。可以通过将链接隐藏在网页源码中,或将上述payload映射为短链接等来解决这个问题。也可以使用BurpSuite构造Poc然后进行验证,打开BurpSuite,然后设置浏览器代理,使用浏览器访问网站并登录,然后查看Proxy下HTTP history中的修改密码的请求,右键,如图:

 然后修改数据为我们想要的数据,然后点击Regenerate,如图:

 然后点击Test in browser,点击Copy,如图:

接着在浏览器中打开刚刚copy的url,如图:

点击按钮,成功利用CSRF修改密码,如图:

 

设置安全等级为Medium,查看源代码,如图:

可以看到和Low级别的代码不同之处在于新增了判断HTTP请求头中Referer参数的值中是否包含Host参数的值。因此,可以通过创建包含主机IP地址的目录或文件进行绕过,新建一个文件名为上述DVWA服务器IP地址的html文件,内容如下:

<html>
<head>
<meta charset="UTF-8"/>
<title>中奖了</title>
</head>
<body>
<h1>恭喜你!中奖了!</h1>
<a href="http://192.168.204.133/dvwa/vulnerabilities/csrf/?password_new=admin&password_conf=admin&Change=Change">领取奖励</a>
</body>
</html>

 将该文件复制到web服务目录,然后发送链接给用户,当用户打开时,如图:

当用户点击领取奖励时,使用BurpSuite拦截数据包查看,如图:

可以看到Referer参数的值中包含Host参数中的值,点击forward即可成功修改密码。 同理,将上述html文件改为index.html,放在文件夹192.168.204.133下同样可以绕过检测。

设置安全等级为High,查看源代码,如图:

 可以看到当用户提交参数后,首先会检查user_token是否正确,只有正确的时候才可以修改密码。因此需要提交正确的user_token才可以利用CSRF修改密码。

查看网页源代码,发现user_token的值,如图:

 因此可以通过实时获取user_token的值,然后进行CSRF,由于该token直接写在了html中,不是标准的json格式,所以即便通过跨域请求访问来获取token也行不通,况且现在的浏览器安全性很高了,通过JavaScript、iframe等进行跨域请求也无法获取到该页面的token。目前还没找到有效利用的方法,除非让用户使用攻击者设计的浏览器或者自己用前端语言去实现一个可以跨域请求http并解析html的代码。看到很多结合XSS漏洞的,既然用XSS可以获取到有Cookie了还有必要在发送欺骗连接给用户让他点击吗?虽然不能有效利用,但是可以使用BurpSuite的CSRF Token Tracker插件验证该漏洞是否确实存在,设置插件参数,如图:

然后刷新浏览器页面, 在Repeater模块发送数据包可以看到每次都可以成功修改密码,如图:

 也可以生成Poc然后在浏览器新标签页中打开,点击Submit request按钮,同样可以成功修改代码。CSRF Token Tracker插件会刷新页面获取最新的user_token的值,然后在提交修改密码请求的时候替换原来的值。这就是为什么让用户使用攻击者设计的浏览器就可以成功利用的原因。

查看Impossible级别的源码,如图:

可以看到新增了一个password_current参数,需要输入现在的密码 ,并且会在验证当前密码正确之后才能继续修改密码。

防御措施

  • 设置较严格的Referer头验证策略
  • 使用Token进行验证请求是否合法
  • 设置自定义HTTP头进行验证

总结

 本文讲解了CSRF漏洞的原理,使用DVWA环境从代码审计层面分析了漏洞形成原因,并结合BurpSuite演示了漏洞验证的方法。近年来随着人们安全意识的提高,CSRF漏洞越来越少了,不知道在不久的将来会不会退出TOP10,即使如此还是需要掌握其原理及利用方法。

发布了31 篇原创文章 · 获赞 55 · 访问量 28万+

猜你喜欢

转载自blog.csdn.net/qq_32261191/article/details/101702284