在HTML5移動應(yīng)用中挖掘XSS漏洞
Linus(@_zulln)是一位有著15年漏洞挖掘經(jīng)驗的瑞士黑客,本文就是他寫的。
現(xiàn)在使用HTML5開發(fā)移動APP越來越受歡迎。HTML5不僅開發(fā)效率高,而且可以跨平臺,代碼重用性也很高。Zoho(***大在線軟件提供商,總部位于美國)是一個有著1300萬用戶的HTML5郵件系統(tǒng),我打算挖挖他們的漏洞。
尋找Html和Javascript代碼
首先我從Google Play上下載了APK,用解壓軟件打開。
assets文件夾中有很多html文件,html文件和javascript文件要比java文件讀起來易懂很多。
翻了幾下之后我發(fā)現(xiàn)mailDetail.html是用來顯示郵件內(nèi)容的,這里有一個漏洞非常有趣。
讀了代碼,懂了代碼結(jié)構(gòu)之后,發(fā)現(xiàn)它調(diào)用了setContent方法:
function setContent(contentToSet,margin){
document.body.style.marginTop = margin + "px";
document.body.style.marginBottom = "10px";
setBaseURL();
document.getElementById('mailcontentid').innerHTML = "";
handleContentForMailThread($('mailcontentid'), contentToSet);
androidResponse();
}
function handleContentForMailThread(contentEl,value) {
var ind = value.indexOf("<blockquote");// NO I18N
if(ind < 0) {
addContentToElement(contentEl,value);
return;
}
else
{
// removed 54 lines here for readability
}
}
function addContentToElement(contentEl,value){
contentEl.innerHTML = value;
addListener();
}
如果你跟蹤contentToSet變量(應(yīng)該是郵件內(nèi)容),你會發(fā)現(xiàn)javascript代碼中沒有對數(shù)據(jù)做任何轉(zhuǎn)義操作,所以,如果有任何轉(zhuǎn)義或者安全操作,都只能是在服務(wù)端做的,或者在java代碼中做的。
確定郵件內(nèi)容是否做過安全處理
最簡單的辦法就是在setContent函數(shù)的開始未知加入payload代碼,比如alert(contentToSet),然后打包重簽名。
我在apk 包中加入了如下幾個payload:
結(jié)果如下:
前兩個payload被正確處理了,但是第三個payload(我事先對數(shù)據(jù)做了url編碼)中顯示了一個<尖括號。
貌似后臺有一個黑名單,如果時間足夠,這些黑名單肯定可以被繞過,但是我對手工fuzzing已經(jīng)無感了,所以我走了另外一條路。
逆向APK
我沒有寫過apk,所以我決定尋找webview相關(guān)的代碼來讀,當(dāng)我找到從java傳遞數(shù)據(jù)到html的代碼的時候,我被webView.loadUrl絆倒了,這明顯可以執(zhí)行javascript代碼呀:
webView.loadUrl("javascript:initialize(" + myNumber + ");");
很明顯zoho使用了跟上面類似的代碼,才使得前面用url編碼過得數(shù)據(jù)正確地顯示出來。
通過使用dex2jar將apk逆向為.jar文件,我使用JD-GUI閱讀這些jar文件,我搜索了setContent函數(shù)(之前提到的javascript函數(shù)),
this.webView.loadUrl("javascript:setContent(" + JSONObject.quote(this.content) + "," + i + ")");
正如你看到的,zoho使用了類似的代碼。
總結(jié)
zoho使用了webview.loadurl方法來調(diào)用setContent方法,這告訴我們什么?用這種方式打開uri,里面的 javascript就會被執(zhí)行,任何pct-encode ugo的代碼都會被當(dāng)做正常代碼來執(zhí)行。
下面這些代碼很容易理解
// this line of code:location.href = 'javascript:setContent("%22-alert%281%29-%22")';// is the same as this:location.href = 'javascript:setContent(""-alert(1)-"")';
問題很明顯,通過在郵件中的任意地方包含如下的payload,就可以在郵件客戶端中執(zhí)行任意javascript代碼:
%22-alert%281%29-%22
在我將這個漏洞報告給zoho幾天過后,他們在Google Play上發(fā)布了新版,并且我收到郵件被告知已經(jīng)有其他人給zoho報告了這個漏洞。
我覺得這個漏洞非常有趣,其他很多APP可能會有很多相似的漏洞。不過在使用HTML開發(fā)的應(yīng)用中尋找漏洞比在web中尋找漏洞要難一些。讓我們一起挖洞拯救世界,讓互聯(lián)網(wǎng)更安全吧!