WebView深度學習(三)之WebView的記憶體洩漏、漏洞以及快取機制原理和解決方案
上兩篇文章講到了WebView的基本使用以及Android和js的互動 以及 全面總結WebView遇到的坑及優化 ,這篇文章講一下記憶體洩漏和漏洞處理。如果你想更深入的瞭解WebView,這篇文章值得一看。
⇒ 六、WebView的記憶體洩漏怎麼辦?
1.不在xml中定義 Webview ,而是在需要的時候在Activity中建立,並且Context使用 getApplicationgContext()
LinearLayout.LayoutParams params = new LinearLayout.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT,
ViewGroup.LayoutParams.MATCH_PARENT);
mWebView = new WebView(getApplicationContext());
mWebView.setLayoutParams(params);
mLayout.addView(mWebView);
2.在 Activity 銷燬( WebView )的時候,先讓 WebView 載入null內容,然後移除 WebView,再銷燬 WebView,最後置空。
@Override
protected void onDestroy() {
if (mWebView != null) {
mWebView.loadDataWithBaseURL(null, "", "text/html", "utf-8", null);
mWebView.clearHistory();
((ViewGroup) mWebView.getParent()).removeView(mWebView);
mWebView.destroy();
mWebView = null;
}
super.onDestroy();
}
⇒ 七、WebView的使用漏洞 及其修復方式
WebView中,主要漏洞有三類:
1.任意程式碼執行漏洞
2.密碼明文儲存漏洞
3.域控制不嚴格漏洞
(一)任意程式碼執行漏洞
- (1)addJavascriptInterface 介面引起遠端程式碼執行漏洞
1. 漏洞產生原因:
js呼叫Android的其中一個方式是通過addJavascriptInterface介面進行物件對映:
webView.addJavascriptInterface(new JSObject(), "myObj");
// 引數1:Android的本地物件
// 引數2:JS的物件
// 通過物件對映將Android中的本地物件和JS中的物件進行關聯,從而實現JS呼叫Android的物件和方法
所以,漏洞產生原因是:當JS拿到android這個物件後,就可以呼叫這個Android物件中所有的方法,包括系統類(Java.lang.Runtime 類),
從而進行任意程式碼執行。(比如**我們可以執行命令獲取本地裝置的SD卡中的檔案等資訊從而造成資訊洩露**)
具體獲取系統類的描述:(結合 Java 反射機制)
-
- Android中的物件有一公共的方法:getClass() ;
-
- 該方法可以獲取到當前類 型別Class
-
- 該類有一關鍵的方法: Class.forName;
-
- 該方法可以載入一個類(可載入 java.lang.Runtime 類)
-
- 而該類是可以執行本地命令的
以下是攻擊的Js核心程式碼:
function execute(cmdArgs) {
// 步驟1:遍歷 window 物件
// 目的是為了找到包含 getClass ()的物件
// 因為Android對映的JS物件也在window中,所以肯定會遍歷到
for (var obj in window) {
if ("getClass" in window[obj]) {
// 步驟2:利用反射呼叫forName()得到Runtime類物件
alert(obj);
return window[obj].getClass().forName("java.lang.Runtime")
// 步驟3:以後,就可以呼叫靜態方法來執行一些命令,比如訪問檔案的命令
getMethod("getRuntime",null).invoke(null,null).exec(cmdArgs);
// 從執行命令後返回的輸入流中得到字串,有很嚴重暴露隱私的危險。
// 如執行完訪問檔案的命令之後,就可以得到檔名的資訊了。
}
}
}
當一些 APP 通過掃描二維碼開啟一個外部網頁時,攻擊者就可以執行這段 js 程式碼進行漏洞攻擊。在微信盛行、掃一掃行為普及的情況下,該漏洞的危險性非常大
2.解決方法
Android 4.2版本之後:Google 在Android 4.2 版本中規定對被呼叫的函式以 @JavascriptInterface進行註解從而避免漏洞攻擊
Android 4.2版本之前:採用攔截prompt()進行漏洞修復。
具體步驟如下:
1.繼承 WebView ,重寫 addJavascriptInterface 方法,然後在內部自己維護一個物件對映關係的 Map ( 將需要新增的 JS 介面放入該Map中 )
2.每次當 WebView 載入頁面前載入一段本地的 JS 程式碼,原理是:
1) 讓JS呼叫一Javascript方法:該方法是通過呼叫prompt()把JS中的資訊(含特定標識,方法名稱等)傳遞到Android端;
2) 在Android的onJsPrompt()中 ,解析傳遞過來的資訊,再通過反射機制呼叫Java物件的方法,這樣實現安全的JS呼叫Android程式碼。
關於Android返回給JS的值:可通過prompt()把Java中方法的處理結果返回到Js中
具體需要載入的JS程式碼如下:
javascript:(function JsAddJavascriptInterface_(){
// window.jsInterface 表示在window上宣告瞭一個Js物件
// jsInterface = 註冊的物件名
// 它註冊了兩個方法,onButtonClick(arg0)和onImageClick(arg0, arg1, arg2)
// 如果有返回值,就新增上return
if (typeof(window.jsInterface)!=`undefined`) {
console.log(`window.jsInterface_js_interface_name is exist!!`);}
else {
window.jsInterface = {
// 宣告方法形式:方法名: function(引數)
onButtonClick:function(arg0) {
// prompt()返回約定的字串
// 該字串可自己定義
// 包含特定的識別符號MyApp和 JSON 字串(方法名,引數,物件名等)
return prompt(`MyApp:`+JSON.stringify({obj:`jsInterface`,func:`onButtonClick`,args:[arg0]}));
},
onImageClick:function(arg0,arg1,arg2) {
return prompt(`MyApp:`+JSON.stringify({obj:`jsInterface`,func:`onImageClick`,
args:[arg0,arg1,arg2]}));
},
};
}
}
)()
// 當JS呼叫 onButtonClick() 或 onImageClick() 時,就會回撥到Android中的 onJsPrompt ()
// 我們解析出方法名,引數,物件名
// 再通過反射機制呼叫Java物件的方法
關於採用攔截prompt()進行漏洞修復需要注意的兩點細節:
細節1:載入上述JS程式碼的時機
由於當 WebView 跳轉到下一個頁面時,之前載入的 JS 可能已經失效,所以,通常需要在以下方法中載入js:
onLoadResource();
doUpdateVisitedHistory();
onPageStarted();
onPageFinished();
onReceivedTitle();
onProgressChanged();
細節2:需要過濾掉 Object 類的方法
由於最終是通過反射得到Android指定物件的方法,所以同時也會得到基類的其他方法(最頂層的基類是 Object類)
為了不把 getClass()等方法注入到 JS 中,我們需要把 Object 的共有方法過濾掉,需要過濾的方法列表如下:
getClass()
hashCode()
notify()
notifyAl()
equals()
toString()
wait()
- (2)searchBoxJavaBridge_介面引起遠端程式碼執行漏洞
1. 產生原因
1) 在Android 3.0以下,Android系統會預設通過searchBoxJavaBridge_的Js介面給 WebView 新增一個JS對映物件:
searchBoxJavaBridge_物件
2) 該介面可能被利用,實現遠端任意程式碼。
2. 解決方法
刪除searchBoxJavaBridge_介面
// 通過呼叫該方法刪除介面removeJavascriptInterface();
- (3)accessibility和 accessibilityTraversal介面引起遠端程式碼執行漏洞
1. 產生原因
1) 在Android 3.0以下,Android系統會預設通過searchBoxJavaBridge_的Js介面給 WebView 新增一個JS對映物件:
searchBoxJavaBridge_物件
2) 該介面可能被利用,實現遠端任意程式碼。
2. 解決方法
刪除searchBoxJavaBridge_介面
// 通過呼叫該方法刪除介面removeJavascriptInterface();
(二)密碼明文儲存漏洞
- (1)問題分析
//WebView預設開啟密碼儲存功能 :
mWebView.setSavePassword(true)
開啟後,在使用者輸入密碼時,會彈出提示框:詢問使用者是否儲存密碼;
如果選擇”是”,密碼會被明文保到 /data/data/com.package.name/databases/webview.db 中,這樣就有被盜取密碼的危險
- (2)解決方案
//關閉密碼儲存提醒
WebSettings.setSavePassword(false)
(三)域控制不嚴格漏洞
先看Android裡的WebViewActivity.java:
public class WebViewActivity extends Activity {
private WebView webView;
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_webview);
webView = (WebView) findViewById(R.id.webView);
//webView.getSettings().setAllowFileAccess(false); (1)
//webView.getSettings().setAllowFileAccessFromFileURLs(true); (2)
//webView.getSettings().setAllowUniversalAccessFromFileURLs(true); (3)
Intent i = getIntent();
String url = i.getData().toString(); //url = file:///data/local/tmp/attack.html
webView.loadUrl(url);
}
}
/**Mainifest.xml**/
// 將該 WebViewActivity 在Mainifest.xml設定exported屬性
// 表示:當前Activity是否可以被另一個Application的元件啟動
android:exported="true"
- (1)問題分析
上述demo中:即 A 應用可以通過 B 應用匯出的 Activity 讓 B 應用載入一個惡意的 file 協議的 url,從而可以獲取 B 應用的內部私有檔案,從而帶來資料洩露威脅
具體:當其他應用啟動此 Activity 時, intent 中的 data 直接被當作 url 來載入(假定傳進來的 url 為 file:///data/local/tmp/attack.html ),其他 APP 通過使用顯式 ComponentName 或者其他類似方式就可以很輕鬆的啟動該 WebViewActivity 並載入惡意url。
下面我們著重分析WebView中getSettings類的方法對 WebView 安全性的影響:
setAllowFileAccess()
setAllowFileAccessFromFileURLs()
setAllowUniversalAccessFromFileURLs()
- (2) setAllowFileAccess()
// 設定是否允許 WebView 使用 File 協議,預設設定為true,即允許在 File 域下執行任意 JavaScript 程式碼
webView.getSettings().setAllowFileAccess(true);
但是同時也限制了 WebView 的功能,使其不能載入本地的 html 檔案,( 移動版的 Chrome 預設禁止載入 file 協議的檔案 ) ,如下圖:
解決方案:
1) 對於不需要使用 file 協議的應用,禁用 file 協議;
setAllowFileAccess(false);
2) 對於需要使用 file 協議的應用,禁止 file 協議載入 JavaScript。
setAllowFileAccess(true);
// 禁止 file 協議載入 JavaScript
if (url.startsWith("file://") {
setJavaScriptEnabled(false);
} else {
setJavaScriptEnabled(true);
}
- (3)setAllowFileAccessFromFileURLs()
設定是否允許通過 file url 載入的 Js程式碼讀取其他的本地檔案 , 在Android 4.1前預設允許 , 在Android 4.1後預設禁止
webView.getSettings().setAllowFileAccessFromFileURLs(true);
當AllowFileAccessFromFileURLs()設定為 true 時,攻擊者的JS程式碼為 ( 通過該程式碼可成功讀取 /etc/hosts 的內容資料 ) :
<script>
function loadXMLDoc(){
var arm = "file:///etc/hosts";
var xmlhttp;
if (window.XMLHttpRequest){
xmlhttp=new XMLHttpRequest();
}
xmlhttp.onreadystatechange=function(){
//alert("status is"+xmlhttp.status);
if (xmlhttp.readyState==4){
console.log(xmlhttp.responseText);
}
}
xmlhttp.open("GET",arm);
xmlhttp.send(null);
}
loadXMLDoc();
</script>
解決方案:
設定setAllowFileAccessFromFileURLs(false);
當設定成為 false 時,上述JS的攻擊程式碼執行會導致錯誤,表示瀏覽器禁止從 file url 中的 JavaScript 讀取其它本地檔案。
- (4) setAllowUniversalAccessFromFileURLs()
設定是否允許通過 file url 載入的 Javascript 可以訪問其他的源(包括http、https等源),在Android 4.1前預設允許(setAllowFileAccessFromFileURLs()不起作用),在Android 4.1後預設禁止
webView.getSettings().setAllowUniversalAccessFromFileURLs(true);
當AllowFileAccessFromFileURLs()被設定成true時,攻擊者的JS程式碼是:
// 通過該程式碼可成功讀取 http://www.so.com 的內容
<script>
function loadXMLDoc(){
var arm = "http://www.so.com";
var xmlhttp;
if (window.XMLHttpRequest){
xmlhttp=new XMLHttpRequest();
}
xmlhttp.onreadystatechange=function(){
//alert("status is"+xmlhttp.status);
if (xmlhttp.readyState==4){
console.log(xmlhttp.responseText);
}
}
xmlhttp.open("GET",arm);
xmlhttp.send(null);
}
loadXMLDoc();
</script>
解決方案:
設定setAllowUniversalAccessFromFileURLs(false);
- (5) setJavaScriptEnabled()
設定是否允許 WebView 使用 JavaScript(預設是不允許),但很多應用(包括移動瀏覽器)為了讓 WebView 執行 http 協議中的 JavaScript,都會主動設定為true,不區別對待是非常危險的,如下程式碼所示:
webView.getSettings().setJavaScriptEnabled(true);
即使把setAllowFileAccessFromFileURLs()和setAllowUniversalAccessFromFileURLs()都設定為 false,通過 file URL 載入的 javascript仍然有方法訪問其他的本地檔案:符號連結跨源攻擊(前提是允許 file URL 執行 javascript,即webView.getSettings().setJavaScriptEnabled(true);)
原因分析:
這一攻擊能奏效的原因是:通過 javascript 的延時執行和將當前檔案替換成指向其它檔案的軟連結就可以讀取到被符號連結所指的檔案。
具體攻擊步驟:(在該命令執行前 xx.html 是不存在的;執行完這條命令之後,就生成了這個檔案,並且將 Cookie 檔案連結到了 xx.html 上。)
1. 把惡意的 js 程式碼輸出到攻擊應用的目錄下,隨機命名為 xx.html,修改該目錄的許可權;
2. 修改後休眠 1s,讓檔案操作完成;
3. 完成後通過系統的 Chrome 應用去開啟該 xx.html 檔案
4. 等待 4s 讓 Chrome 載入完成該 html,最後將該 html 刪除,並且使用 ln -s 命令為 Chrome 的 Cookie 檔案建立軟連線,
於是就可通過連結來訪問 Chrome 的 Cookie
注意事項:
Google 沒有進行修復,只是讓Chrome 最新版本預設禁用 file 協議,所以這一漏洞在最新版的 Chrome 中並不存在。
但是,在日常大量使用 WebView 的App和瀏覽器,都有可能受到此漏洞的影響。通過利用此漏洞,容易出現資料洩露的危險
如果是 file 協議,禁用 javascript 可以很大程度上減小跨源漏洞對 WebView 的威脅。
但並不能完全杜絕跨原始檔洩露。例:應用實現了下載功能,對於無法載入的頁面,會自動下載到 sd 卡中;由於 sd 卡中的檔案所有應用都可以訪問,於是可以通過構造一個 file URL 指向被攻擊應用的私有檔案,然後用此 URL 啟動被攻擊應用的 WebActivity,這樣由於該 WebActivity 無法載入該檔案,就會將該檔案下載到 sd 卡下面,然後就可以從 sd 卡上讀取這個檔案了
- (6) 最終解決方案
1)對於不需要使用 file 協議的應用,禁用 file 協議;
// 禁用 file 協議;
webView.setAllowFileAccess(false);
webView.setAllowFileAccessFromFileURLs(false);
webView.setAllowUniversalAccessFromFileURLs(false);
2)對於需要使用 file 協議的應用,禁止 file 協議載入 JavaScript。
// 需要使用 file 協議
webView.setAllowFileAccess(true);
webView.setAllowFileAccessFromFileURLs(false);
webView. setAllowUniversalAccessFromFileURLs(false);
// 禁止 file 協議載入 JavaScript
if (url.startsWith("file://") {
webView.setJavaScriptEnabled(false);
} else {
webView.setJavaScriptEnabled(true);
}
⇒ 八、WebView 的快取機制 & 資源預載入方案
參考文章:http://blog.csdn.net/carson_ho/article/details/71402764
相關文章
- webView 記憶體洩漏WebView記憶體
- WebView引起的記憶體洩漏WebView記憶體
- Android WebView Memory Leak WebView記憶體洩漏AndroidWebView記憶體
- Android 5.1 WebView記憶體洩漏分析AndroidWebView記憶體
- 2.3.1 (下)WebView 檔案下載、快取、記憶體洩露WebView快取記憶體洩露
- Handler 訊息機制以及記憶體洩漏記憶體
- Handler的使用、記憶體洩漏和解決記憶體
- Android webview的快取機制AndroidWebView快取
- 從WebView快取聊到Http 的快取機制WebView快取HTTP
- Android Handler機制之記憶體洩漏Android記憶體
- WebView深度學習(一)之WebView的基本使用以及Android和js的互動WebView深度學習AndroidJS
- webView快取WebView快取
- 從WebView快取聊到Http 的快取機制 | 掘金技術徵文WebView快取HTTP
- Android 記憶體洩漏案例和解析Android記憶體
- RxJava記憶體洩漏的一種解決方案RxJava記憶體
- Handler記憶體洩漏原因及解決方案記憶體
- 防範JAVA記憶體洩漏解決方案Java記憶體
- WebView快取原理分析和應用WebView快取
- WebView 快取原理分析和應用WebView快取
- WebView深度學習(二)之全面總結WebView遇到的坑及優化WebView深度學習優化
- 深度學習 Caffe 記憶體管理機制理解深度學習記憶體
- JavaScript之記憶體洩漏【四】JavaScript記憶體
- js垃圾回收機制和引起記憶體洩漏的操作JS記憶體
- 記憶體洩漏記憶體
- WebView 設定快取WebView快取
- 深度學習js與安卓的互動以及WebView的那些坑深度學習JS安卓WebView
- handlder引起的記憶體洩漏問題以及解決辦法記憶體
- Android之記憶體洩漏除錯學習與總結Android記憶體除錯
- javascript的記憶體管理以及3種常見的記憶體洩漏JavaScript記憶體
- JavaScript之記憶體溢位和記憶體洩漏JavaScript記憶體溢位
- 如何定位和解決記憶體洩露記憶體洩露
- Java記憶體洩漏解決之道Java記憶體
- 【記憶體洩漏和記憶體溢位】JavaScript之深入淺出理解記憶體洩漏和記憶體溢位記憶體溢位JavaScript
- JavaScript 中的記憶體洩漏以及如何處理JavaScript記憶體
- JavaScript中的記憶體洩漏以及如何處理JavaScript記憶體
- 分析記憶體洩漏和goroutine洩漏記憶體Go
- 【Java面試題】之記憶體洩漏Java面試題記憶體
- 記憶體洩漏的原因記憶體