Android應用安全開發之淺談網頁打開APP

1、網頁打開APP簡介

Android有一個特性，能夠經過點擊網頁內的某個連接打開APP，或者在其餘APP中經過點擊某個連接打開另一個APP（AppLink），一些用戶量比較大的APP，已經經過發佈其AppLink SDK，開發者須要申請相應的資格，配置相關內容才能使用。這些都是經過用戶自定義的URI scheme實現的，不過背後仍是Android的Intent機制。Google的官方文檔《Android Intents with Chrome》一文，介紹了在Android Chrome瀏覽器中網頁打開APP的兩種方法，一種是用戶自定義的URI scheme（Custom URI scheme），另外一種是「intent:」語法（Intent-based URI）。

 

第一種用戶自定義的URI scheme形式以下：

 

第二種的Intent-based URI的語法形式以下：

由於第二種形式大致是第一種形式的特例，因此不少文章又將第二種形式叫Intent Scheme URL，可是在Google的官方文檔並無這樣的說法。

 

注意：使用Custom URI scheme給APP傳遞數據，只能使用相關參數來傳遞數據，不能想固然的使用scheme://host#intent;參數;end的形式來構造傳給APP的intent數據。詳見3.1節的說明。

此外，還必須在APP的Androidmanifest文件中配置相關的選項才能產生網頁打開APP的效果，具體在下面講。

 

2、Custom Scheme URI打開APP

2.1 基本用法

需求：使用網頁打開一個APP，並經過URL的參數給APP傳遞一些數據。 

如自定義的Scheme爲：

注意： uri要用UTF-8編碼和URI編碼。

 

網頁端的寫法以下：

 

APP端接收來自網頁信息的Activity，要在Androidmanifest.xml文件中Activity的intent-filter中聲明相應action、category和data的scheme等。 

如在MainActivity中接收從網頁來的信息，其在AndroidManifest.xml中的內容以下：

 

在MainActivity中接收intent而且獲取相應參數的代碼：

另外還有如下幾個API來獲取相關信息： 

getIntent().getScheme(); //得到Scheme名稱 

getIntent().getDataString(); //得到Uri所有路徑 

getIntent().getHost(); //得到host

 

2.2 風險示例

常見的用法是在APP獲取到來自網頁的數據後，從新生成一個intent，而後發送給別的組件使用這些數據。好比使用Webview相關的Activity來加載一個來自網頁的url，若是此url來自url scheme中的參數，如：jaq://jaq.alibaba.com?load_url=http://www.taobao.com。

 

若是在APP中，沒有檢查獲取到的load_url的值，攻擊者能夠構造釣魚網站，誘導用戶點擊加載，就能夠盜取用戶信息。

 

接2.1的示例，新建一個WebviewActivity組件，從intent裏面獲取load_url，而後使用Webview加載url：

 

修改MainActivity組件，從網頁端的URL中獲取load_url參數的值，生成新的intent，並傳給WebviewActivity：

 

網頁端：

 

釣魚頁面：

 

點擊「打開釣魚網站」，進入APP，而且APP加載了釣魚網站：

 

本例建議： 

在Webview加載load_url時，結合APP的自身業務採用白名單機制過濾網頁端傳過來的數據，黑名單容易被繞過。

 

2.3 阿里聚安全對開發者建議

一、APP中任何接收外部輸入數據的地方都是潛在的攻擊點，過濾檢查來自網頁的參數。

 

二、不要經過網頁傳輸敏感信息，有的網站爲了引導已經登陸的用戶到APP上使用，會使用腳本動態的生成URL Scheme的參數，其中包括了用戶名、密碼或者登陸態token等敏感信息，讓用戶打開APP直接就登陸了。惡意應用也能夠註冊相同的URL Sechme來截取這些敏感信息。Android系統會讓用戶選擇使用哪一個應用打開連接，可是若是用戶不注意，就會使用惡意應用打開，致使敏感信息泄露或者其餘風險。

 

3、Intent-based URI打開APP

3.1基本用法

Intent-based URI語法：

 

注意：第二個Intent的第一個字母必定要大寫，否則不會成功調用APP。

 

如何正確快速的構造網頁端的intent？ 

能夠先建個Android demo app，按正常的方法構造本身想打開某個組件的Intent對象，而後使用Intent的toUri()方法，會獲得Intent對象的Uri字符串表示，而且已經用UTF-8和Uri編碼好，直接複製放到網頁端便可，切記前面要加上「intent:」。 

 

如：

 

結果：

S.load_url是跟的是intent對象的putExtra()方法中的數據。其餘類型的數據能夠一個個試。若是在demo中的Intent對象不能傳遞給目標APP的Activity或其餘組件，則其Uri形式放在網頁端也不可能打開APP的，這樣寫個demo容易排查錯誤。

 

APP端中的Androidmanifest.xml的聲明寫法同2.1節中的APP端寫法徹底同樣。對於接收到的uri形式的intent，通常使用Intent的parseUri()方法來解析產生新的intent對象，若是處理不當會產生Intent Scheme URL攻擊。

 

爲什麼不能用scheme://host#intent;參數;end的形式來構造傳給APP的intent數據？ 

這種形式的intent不會直接被Android正確解析爲intent，整個scheme字符串數據可使用Intent的getDataSting()方法獲取到。 

如對於：

 

在APP中獲取數據：

 

結果是：

 

由上圖可知Android系統自動爲Custom URI scheme添加了默認的intent。 

 

要想正確的解析，還需使用Intent的parseUri()方法對getDataString()獲取到的數據進行解析，如：

 

3.2 風險示例

關於Intent-based URI的風險我以爲《Android Intent Scheme URLs攻擊》和《Intent Scheme URL attack》這兩篇文章寫的很是好，基本把該說的都都說了，我就很少說了，你們看這兩篇文章吧。

 

3.3 阿里聚安全對開發者建議

上面兩篇文章中都給出了安全使用Intent Scheme URL的方法：

 

除了以上的作法，仍是不要信任來自網頁端的任何intent，爲了安全起見，使用網頁傳過來的intent時，仍是要進行過濾和檢查。

 

4、參考

[1] Android Intents with Chrome，https://developer.chrome.com/multidevice/android/intents 

[2] Intent scheme URL attack，http://drops.wooyun.org/papers/2893 

[3] Android Appliaction Secure Design/Secure Coding Guidebook，http://www.jssec.org/dl/android_securecoding_en.pdf 

[4] Handling App Links，http://developer.android.com/intl/zh-cn/training/app-links/index.html 

[5] Android M App Links: 實現, 缺陷以及解決辦法，http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0718/3200.html 

[6] Android Intent Scheme URLs攻擊，http://blog.csdn.net/l173864930/article/details/36951805

 

做者：伊樵，呆狐，舟海@阿里移動安全，更多技術文章，請點擊阿里聚安全博客