渗透的艺术-CSRF攻击

Posted 2021-04-25 渗透的艺术

关注我，你的眼睛会怀孕

 

概念

 CSRF简述

  当你登陆某个网站时，通常浏览器与网站都会形成一个会话，在会话没有结束时你可以执行发表文章、发邮件、

删除文章等操作，若会话结束，你再操作的话会提示你会话已经结束，请重新登陆。
CSRF可以做什么

　　你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。

CSRF漏洞现状

　　CSRF这种攻击方式在2000年已经被国外的安全人员提出，但在国内，直到06年才开始被关注，08年，国内外的多个大型社区和交互网站分别爆出CSRF漏洞，如：NYTimes.com（纽约时报）、Metafilter（一个大型的BLOG网站），YouTube和百度HI......而现在，互联网上的许多站点仍对此毫无防备，以至于安全业界称CSRF为“沉睡的巨人”。

 

案例

   

     自然，这里拿Rails程序来举例子说明这些问题，大家知道Rails2之前是把session放在服务器端（文件或者DB或者缓存中），客户但在 cookie中保存sessionid；而到了Rails2后，还有一种方式是把session放在基于cookie的客户端中。当然这两样都各有道理， 各有优劣，不在我们这次说的范围之内。我们继续说，当我们向一个域名发送一个请求的时候，如果本店存在这个域名的cookie，浏览器会自动的把 cookie附带上。这样本来没有啥问题，也是我们为了解决http无状态记录的解决方案，但是有个问题出现了，如果出现一个到其他域名的请求，浏览区在 加载的时候，也把cookie给带上了，会有什么问题？我们举个简单的也很常见的例子来说明这个问题。

-----------------------------案例------------------------------
1、Bob在自己的电脑上刚刚查看完自己的银行A账户余额，然后比较无聊就跑到一个公开的BBS上灌水，当他看到一篇“银行A的内部照片”的帖子，很有兴趣的打开这个帖子想看看自己信任的银行A的内部图片是啥样子的，殊不知，这其实是一个attacker精心设计的骗局。
2、在这个帖子中确实有几个图片，看上去真的像是银行A的照片，但是其中有个图片没显示出来，Bob以为是自己网速太慢，导致这个图片没有加载进来，也没在意。只是对这些并不是十分满意的照片摇摇头，就关了这个帖子。
3、几天后，Bob猛然发现自己在银行A的账户上少了1000元，到底是怎么了？

分析：
为什么钱少了呢？我们得分析一下上面这个案例，好记得当时Bob说有个图片没显示么，是的，我们来看看这个图片的地址,惊奇的发现是：

<img .src="http://www.banka.com/transfer?account=myself&amount=1000&destination=attacker;">

这是一个什么地址？聪明的您一定很快就能明白，这个地址是邪恶的，看上去，他的意思是打开这个地址的人，给attacker转了1000元。
这怎么可能？你肯定急了，我怎么能随便给一个人转1000元呢，而且我都不知道呀！但是，注意了，这其实是完全有可能的。还记得当时Bob刚刚查看完整及的帐号信息，基于银行A的cookie并不过期，当出现如上链接出现在src的时候（note that .src is meant to be src），浏览器尝试着按照本地的cookie去加载上面这个URL，而银行A验证了来源请求的cookie是可以的，所以就这样事情就悄悄的发生了。
-------------------------------案例结束-------------------------

   看明白了么，这就是CSRF，一句话给他下个定义就是：借你的cookie在你不知道的时候悄悄的做了一些你不愿意做 的事情。恶日期这里有个更要命的是，这个包含上述URL的图片或者链接，并不需要一定是放在银行A的服务器上，相反可以在任一地方，比如blog，公开的 BBS，或者一些群发的Mail中等等，如此多的场合下，这些都有可能存在陷阱。
再看一副图片吧，其说明的正是CSRF的攻击原理。

 

防御

       限制验证cookie的到期时间。这些cookie的合法时间越短，黑客利用你的Web应用程序的机会就越小。不过，这个时间越短，用户就越不方便。因此，你需要在安全性和方便性之间进行平衡。

      执行重要业务之前，要求用户提交额外的信息。要求用户在进行重要业务前输入口令，这可以防止黑客发动CSRF攻击（只要浏览器中没有包含口令），因为这种重要信息无法预测或轻易获得。

       使用秘密的无法预测的验证符号。当保存在用户浏览器中的cookie仅由一次会话确认时，CSRF攻击才会有效。所以在每次HTTP请求（当然攻击者无法提前知道）中都有附加的特定会话的信息，这样就可以挫败CSRF攻击。不过，如果这种应用程序存在跨站脚本漏洞，黑客就有可能访问这种验证符号。

      使用定制的HTTP报头。如果执行交易的所有请求都使用XMLHttpRequest并附加一个定制的HTTP报头，同时拒绝缺少定制报头的任何请求，就可以用XMLHttpRequest API来防御CSRF攻击。由于浏览器通常仅准许站点将定制的HTTP报头发送给相同站点，从而了防止由CSRF攻击的源站点所发起的交易。

      检查访问源的报头。在浏览者发送HTTP请求时，它通常会包含源自访问源报头的URL。理论上讲，你可以使用这些信息来阻止源自其它任何站点（而不是来自Web应用程序自身）的请求。不过，访问源报头并不总是可用的，（例如，有些单位由于私密性的缘故而将它剥离了），或者这个报头容易被欺骗，所以说，这条措施并不真正有效。

渗透的艺术

shentoudeyishu

 长按识别左侧二维码，关注我