RPO漏洞学习

Internet Explorer存在URL问题

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

GitHub OAuth Code Theft

URL编码或百分号编码通常用于查询字符串或请求正文中。主机名也接受URL编码。但是，当Internet Explorer重定向到URL编码的主机名时，会发生奇怪的事情。例如，如果您使用Windows 7 / 8.1上的Internet Explorer 11与其他浏览器访问以下链接，您会发现目标完全不同：

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

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头中。

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=code

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链接的任何用户都会将代码泄露给拥有该域的攻击者。当然，它也会影响其他应用程序。

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

References:

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，必须阅读这些技术。

原文链接

转载于:https://www.cnblogs.com/esthermalley/p/9546549.html