本文翻譯自：http://www.mbsd.jp/blog/20160921.html ,有改動

原作者：プロフェッショナルサービス事業部　寺田 健

譯者：Holic (知道創宇404安全實驗室)

0x00 漏洞概述

漏洞簡介

URL重定向漏洞有時會造成與上下文變量有關的漏洞，其導致的XSS便是常見的例子之一。本文所描述的漏洞在一年前提交至蘋果官方，對應CVE-2016-4585，下面介紹這個漏洞的相關細節。

漏洞利用點

  1. 操縱請求中的Host頭
  2. Origin Confusion XSS 此外還可以盜取敏感信息和展開釣魚攻擊。

受影響的組件

Safari < v9.1.2、iOS < v9.3.3、tvOS <v9.2.2

0x01 漏洞詳情

1.操縱Host頭

在服務端返回302或者307狀態碼的情況下，我們可以構造如下請求：

Location: http://example.com:abc<'">()foo/

注意上面URL的端口號不是數字。Safari在處理的時候會訪問example.com:80 ，并將請求頭轉換成下面這樣：

Host: example.com:abc'%3C%26%22%3E()foo

Host頭的端口是無效的，這意味著可以操縱瀏覽器的Host頭訪問任何位置。

漏洞利用有兩點限制：

  • 這些字符有一部分是編碼過的；
  • 只有":" 后面的內容可以修改

下面來探索一些攻擊利用的技巧

閉合單引號導致的XSS

上面看到一些字符是受限的，比如"'"和"&"。 一些XSS攻擊在Safari下是受限的：

Safari的XSS過濾機制對Host頭反射型同樣生效。當然下面的這種情況是可以觸發XSS的。

可操縱hostname的XSS

Host頭可以影響類似于以下的部分的代碼：

<script src="http://(HOST)/js/jquery.js">
<link href="http://(HOST)/css/style.css" rel="stylesheet" type="text/css">

當server中有類似代碼的時候會觸發漏洞。

在Github上能找到很多類似的代碼，我在本地也進行了一系列驗證。

我們看下<script src=標簽這兒，假如Host頭中的“example.com”修改為“example.com:abc"：

<script src="http://example.com:abc/js/jquery.js">

這種情況下，Safari并不會加載此畸形的URL（URL不合法），而攻擊者是想要在Safari加載他自己服務器上面的JS。

經過一系列實驗，想出以下思路：

攻擊者服務器上的響應：

此時對目標服務器上的請求：

在接收到Location之后，Safari連接至example.jp:80,發送的Host頭如下

Host: example.jp:evil

開始部分的a@被當做了基礎認證信息。

目標服務器返回的內容： （原圖） 后面包括@的部分被再次去掉了。由此可見，JS從攻擊者的host獲取，成功執行了XSS攻擊。

攻擊實例(加載了外部網站的js)：

信息竊取

上面所說的技巧同樣可以用來竊取信息。假設一些web服務會重定向的URL包含了一些私密信息：

Location: http://(HOST)/foo?token=fj0t9wj958...

在這種情況下，攻擊者還是可以通過@大法操縱Host頭。

這種情景其實非常普遍，因為Location header是服務端對Host頭的反饋最常見的地方。這可能因為不是web app的開發者這么寫的，而是使用了相同的web平臺，把相對URL處理成絕對路徑的時候是基于Host頭的。比如Java 的 HttpServletResponse#sendRedirect()方法。

順便說下協議背景，路徑絕對化的格式按照 HTTP/1.1 標準，RFC2616 是禁止 Location header 中使用相對 但是 RFC7231允許這么做 )。

如果header的值受到hostname的影響，除了Location header，HTML的URI屬性像<form action= 和 <a href=同樣可以造成信息竊取漏洞。

2.域混淆XSS

根據原文作者的例子，他在使用:非數字的方法測試目標鏈接的時候，像http://www.mbsd.jp:xyz/在加載外部資源的時候會出現以下情況。 明顯采用相對路徑的URL資源沒有正確加載。 我們可以在瀏覽器console下面可以進行驗證：

此頁面的域是損壞的，這便是為什么采用相對路徑加載資源會失敗了。cookie也因此無法獲取。同源策略在一定程度上抑制了攻擊者的行為，不過如果能夠好好利用的話這個故事就會變得截然不同。

想到的最好的利用方法便是iframe了，我們可以找個在header中"X-Frame-Options"限制寬松的站進行測試。

原作者的示例如下：

我們發現經過一系列混淆，瀏覽器會加載以iframe的父頁面為baseURL的資源，導致了加載錯誤。

同樣我也在線上驗證了這種情況： 同理，相對路徑加載資源導致這種情況。

造成的影響

加載的JS是在加載損壞內容的情況下進行的，因此不能通過XHR的方式獲取同站點的cookie。但是依然可以對自身的document內容進行操作，這意味著攻擊者可以修改頁面內容。使用Cookie驗證的頁面也是可以進行攻擊利用的，因為請求中帶有cookie。

漏洞要點

  • Safari 在處理無效端口時使用默認端口（80，443）
  • 畸形Host頭比如Host: hostname:xyz可以發送至 Apache, WebLogic 和 Nginx等服務器，Tomcat 和 IIS 不會接收。
  • 可以使用GET 和 POST的HTTP請求方法，使用302或者307進行跳轉
  • 在iframe中，base URL繼承自父頁面，奇怪的是至今<base href=被完全忽略了
  • JS是在blank域下執行的，與iframe父頁面分離，除了cookie，DOM對象皆可訪問
  • CSP (或者 X-Frame-Options) 可能會防止此XSS攻擊

0x02 修復建議

升級Safari至 2016 年 7 月 18日以后的版本

官方修復：加強驗證，不合法URL會顯示錯誤

0x03 參考

  • https://www.seebug.org/vuldb/ssvid-92437
  • http://www.mbsd.jp/blog/20160921.html
  • https://support.apple.com/HT206900

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/51/