Web渗透_CSRF




CSRF

cross-site request forgery:跨站请求伪造



1. CSRF攻击之前,被害人一定是已经登录了目标站点。

2. 黑客的思路目标就是让被害人自己点击链接,发出危险的URL请求。

3. 用户在已登陆目标站点的基础上,进行了非本意的操作(最终执行操作的是被害人本人)。

简单理解:

        CSRF攻击的主要目的是让用户在不知情的情况下攻击自己已登录的一个系统,类似于钓鱼。如用户当前已经登录了邮箱,或bbs,同时用户又在使用另外一个,已经被你控制的站点,我们姑且叫它钓鱼网站。这个网站上面可能因为某个图片吸引你,你去点击一下,此时可能就会触发一个js的点击事件,构造一个bbs发帖的请求,去往你的bbs发帖,由于当前你的浏览器状态已经是登陆状态,所以session登陆cookie信息都会跟正常的请求一样,纯天然的利用当前的登陆状态,让用户在不知情的情况下,帮你发帖或干其他事情。 






场景:修改密码。


happysneaker.com


分析一下这个场景,最终操作其实就是向服务器提交了一个表单:

happysneaker.com


那么思路就出来了,在我们自己的服务器上新建一个包含修改密码Form表单的csrf.php文件,里面的代码作用于目标站点修改密码的url,然后将 csrf.php 所在服务器地址URL 发送给受害人,受害人点击。

happysneaker.com


为什么不能是黑客自己点击链接呢?黑客自己点击链接确实能够访问这个链接,但是黑客之前没有登录过这个网站,而被害者是已经正常登录了这个网站的,被害者拥有网站的cookie等认证,黑客要做的就是以被害者的身份点击危险连接发出请求。



medium等级不会成功,截包发现请求头多了一个referer 参数,尝试修改referer参数再提交,发现:

happysneaker.com

验证,原来referer只要包含Host即可:

happysneaker.com


referer总是和链接一样,包含Host,那么就可以伪造一个和目标站点Host一样的文件,将csrf.php放入,这样的话构造的链接里就包含Host了。

happysneaker.com



medium等级就OK了,来看High等级:

happysneaker.com

多了一个&user_token口令,而且每次修改密码都会变化,但这个&user_token 经常是包含在上一次请求的返回包中。这里又出现了一个名词,CSRF Token,而其实关于user_token 动态变化的这个事情,统称为CSRF Token,口令的出现就是为了防止CSRF的攻击。它保证了攻击者无法猜测到所有参数。

问题:

happysneaker.com



最后impossible模式,这个模式就保证了安全:

happysneaker.com


总结修复方法,做好以下三点能保证较高的安全性:


第三个验证码其实就是自定义属性验证,还可以通过其他形式来实现,比如增加HTTP头的自定义字段等。

happysneaker.com


即:

[1]  在所有请求地址中添加 token 并验证。

[2]  验证 HTTP Referer 字段。

[3]  敏感操作需要验证码,更改密码需要验证老密码。

[4]  在HTTP头中加入其它自定义属性并验证。







CSRF攻击实例:


① 受害者 Bob 在银行有一笔存款,通过对银行的网站发送请求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款转到 bob2 的账号下。通常情况下,该请求发送到网站后,服务器会先验证该请求是否来自一个合法的 session,并且该 session 的用户 Bob 已经成功登陆。

② 黑客 Mallory 自己在该银行也有账户,他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个请求给银行:http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是这个请求来自 Mallory 而非 Bob,他不能通过安全认证,因此该请求不会起作用。

③ Mallory 想到使用 CSRF 的攻击方式,他先自己做一个网站,在网站中放入如下代码: src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”,并且通过广告、美女等诱使 Bob 来主动访问他的网站。

④ 当 Bob 访问该网站时,上述 url 就会从 Bob 的浏览器发向银行,这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数情况下,该请求会失败,因为他要求 Bob 的认证信息。但是,如果 Bob 当时恰巧刚访问他的银行后不久,他的浏览器与银行网站之间的 session 尚未过期,浏览器的 cookie 之中含有 Bob 的认证信息。

这时,悲剧发生了,这个 url 请求就会得到响应,钱将从 Bob 的账号转移到 Mallory 的账号,而 Bob 当时毫不知情。等以后 Bob 发现账户钱少了,即使他去银行查询日志,他也只能发现确实有一个来自于他本人的合法请求转移了资金,没有任何被攻击的痕迹。而 Mallory 则可以拿到钱后逍遥法外。






CSRF简单检测方法:

抓取一个正常请求的数据包,去掉Referer字段后再重新提交,如果该提交还有效,那么基本上可以确定存在CSRF漏洞。






CSRF与SSRF的区别:


https://www.cnblogs.com/blacksunny/p/7478568.html 


https://www.jianshu.com/p/ad7b8079e0d5 


SSRF(Server-Side Request Forgery:服务请求伪造)是一种由攻击者构造,从而让服务端发起请求的一种安全漏洞, 它将一个可以发起网络请求的服务当作跳板来攻击其他服务,SSRF的攻击目标一般是内网。

当服务端提供了从其他服务器获取数据的功能(如:从指定URL地址获取网页文本内容、加载指定地址的图片、下载等), 但是没有对目标地址做过滤与限制时就会出现SSRF。


About SSRF : https://blog.csdn.net/u010726042/article/details/77806775







Web安全技术分享
请先登录后发表评论
  • 最新评论
  • 总共0条评论