不多講，開始吧，嗯
一 Activity漏洞挖掘
設置了exported=”true”，或者添加了屬性，但是並沒有顯示的設置爲exported=”false”，此時Activity是導出的, 不合理的Activity組件導出導致的問題：
1 基於Android Brower Intent Scheme URLs攻擊手段
利用了瀏覽器保護措施的不足，通過瀏覽器去調用應用自定義的scheme規範的鏈接啓動Activity,把瀏覽器作爲橋樑間接實現Intend-Based攻擊，相比於普通Intend-Based攻擊，這種方式更具隱蔽性，而且惡意代碼隱藏WebPage中，傳統的特徵匹配完全不起作用；
2 拒絕服務
通過Intent給Activity傳輸畸形數據使得程序崩潰從而影響用戶體驗；
3 越權繞過
Activity用戶界面繞過會造成用戶的信息竊取，Activity界面被劫持產生欺詐等安全事件。比如在業務過程中會有一些敏感的界面是需要用戶輸入密碼才能查看的，但是如果沒有對調起此Activity的組件進行權限驗證，那麼就會造成驗證的越權問題，導致惡意的攻擊者不需要輸入密碼等信息也可以打開這個界面。
對於越權繞過的防護：私有Activity不應被其他應用啓動，創建Activity時：設置exported屬性爲false；公開暴露的Activity組件，可以被任意應用啓動，創建Activity：設置exported屬性爲true；謹慎處理接收的intent，有返回數據時不應包含敏感信息；不應發送敏感信息；當收到返回數據時謹慎處理。
組件導出導致釣魚欺詐 ：原理Activity棧，當新的Activity啓動時，前一個Activity就會停止，壓入歷史棧，當用戶按下back鍵時，頂部Activity彈出，恢復前一個Activity，棧頂指向當前的Activity。由於Activity的這種特性，如果啓動一個Activity時，給它加入一個標誌位FLAGACTIVITYNEW_TASK ,就能使它置於棧頂並立馬呈現給用戶，如果這個Activity是用與盜號的僞裝Activity ,那麼就會產生釣魚安全事件或者是一個 Activity中有webview加載，如果允許加載任意網頁也有可能會產生釣魚事件。防護：可在onStop（）及時提醒用戶；
拒絕服務攻擊：攻擊者通過intent發送空數據，異常或畸形數據給受害者應用導致其崩潰。本地拒絕服務漏洞不僅可以導致安全防護等應用的防護功能被繞過或失效，而且也可被競爭方應用利用來攻擊，使得自己的應用崩潰，造成不同程度的經濟利益損失。防護：常見異常處理：空指針異常處理，類型轉換異常（序列化），數組越界訪問異常，類未定義異常等。
Android Intent Scheme URLs攻擊原理及防護措施：這裏就借鑑一篇博客。Android Intent Scheme URLs攻擊
二 Service 漏洞挖掘
如果一個導出的Service沒有做嚴格的限制，任何應用可以去啓動並且綁定到這個Service上，取決於被暴露的功能這有可能使得一個應用去執行未授權的行爲，獲取敏感信息或者污染修改內部應用的狀態造成威脅。Service漏洞分類：權限提升，services劫持，消息僞造，拒絕服務。
1 權限提升
當一個Service配置了Intent-filter默認是被導出的，如果沒有對這個Service進行權限限制或者是沒有對調用者身份進行有效的驗證，那麼構造惡意構造的App都可以對次Service傳入恰當的參數進行調用，導致惡意行爲。
2 services劫持
隱式啓動serviece，當存在同名service，先安裝應用的service優先級高。
3 消息僞造
暴露的Service對外接收Intent，如果構造惡意的消息放在Intent中傳輸，被調用的Service接受可能產生安全隱患。
4 拒絕服務
主要來源於Service啓動時對接收的Intent等沒有做異常情況下的處理，導致的程序崩潰。
主要體現的方面如給Service傳輸未null的Intent或者傳輸序列化對象導致接收時的類型轉化異常。
安全防護
1. 私有service不定義intent-filter並且設置exported爲false；
2. 公開的service設置exported爲true，intent-filter可以定義或者不定義。
3. 合作service需對合作方的app簽名做校驗。
4. Service接收到的數據需謹慎處理。
5. 內部Service需使用簽名級別的protectionLevel來判斷是否來自內部應用的調用。
6. 不應該在Service創建（onCreate方法調用）的時候決定是否提供服務，應在onStartCommand/onBind/onHandleIntent等方法調用的時候做判斷。
7. 當Service有返回數據的時候，應判斷數據接受app是否有信息泄露的風險。
8. 有明確的服務需調用時使用顯示意圖。
9. 儘量不發送敏感信息。
10. 啓動Service時不設置Intent的FLAG_ ACTIVITY_NEW_TASK標籤。
三 Broadcast Receiver 漏洞挖掘
當發送一個廣播時，系統會將發送的廣播（Intent）與系統中所有註冊符合條件的接收者的IntentFilter進行匹配，若匹配成功，將執行相應接收者的onReceiver函數。發送廣播時如果處理不當，惡意應用便可以嗅探，攔截廣播，致使敏感數據泄漏等；如果接收廣播時處理不當，便可導致拒絕服務攻擊，僞造消息，越權操作等。Broadcast Receiver漏洞分類：1. 敏感信息泄漏2. 權限繞過3. 消息僞造4. 拒絕服務
1 敏感信息泄漏
發送的Intent沒有明確指定接收者，而是簡單的通過action進行匹配。惡意應用便可以註冊一個廣播接收者嗅探攔截到這個廣播，如果這個廣播裏存在敏感數據，就被惡意應用竊取了。
2 權限繞過漏洞
可以通過兩種方式註冊廣播接收器，一種是在AndroidManifest.xml文件中通過<receiver/>標籤靜態註冊。另一種是通過Context.registerReceiver()動態註冊，指定相應的IntentFilter參數。然後動態註冊的廣播是默認導出的。如果導出的BroadcastReceiver沒有做權限控制，導致BroadcastReceiver組件可以接受一個外部可控的url,或者其他命令，導致攻擊者可以越權利用應用的一些特定功能，比如發送惡意廣播，僞造消息，任意應用下載安裝，打開釣魚網張等。
3 消息僞造
暴露的Receiver對外接受Intent，如果構造惡意的消息放在Intent總傳輸，被調用的Receiver接收有可能產生安全隱患。
4 拒絕服務
如果敏感的BroadcastReceiver沒有設置相應的權限保護，很容易收到攻擊。傳遞惡意畸形的Intent數據給廣播接收器，造成crash。
安全防護
1 修復代碼，使用LocalBroadcastManager.sendBroadcast(…)發出廣播只能被app自身廣播接收器接收。
LocalBroadcastManager lbm = LocalBroadcastManager.getInstance(this);
lbm.sendBroadcast(new Intent(LOCAL_ACTION));2 推薦使用LocalBroadcastManager類來進行動態註冊。
lbm.registerReceiver(new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
// TODO Handle the received local broadcast
}
}, new IntentFilter(LOCAL_ACTION));
3 如果Receiver設置導出，則可以設置android：protectionLevel = “signature”
4 拒絕服務攻擊防護如上
四 Content Provider漏洞挖掘
Content Provider起到在應用程序間共享數據的作用，通過Binder進程間通信機制以及匿名共享內存機制來實現。Content Provider組件本身提供讀寫權限控制，但是它的控制粒度是比較粗的。漏洞分類：1. 信息泄漏2. Sql注入3. 目錄遍歷
1 信息泄漏
content URI是一個標誌Provider數據的URI。Content URI中包含了整個Provider的以符號表示的名字（authority）和指向一個表的名字（一個路徑）。如果對Content Provider的權限沒有做好控制，就有可能導致惡意程序通過這種方式讀取app的敏感數據。
所有聯繫人的Uri：content://contacts/people
某個聯繫人的Uri：content://contacts/people/5
所有圖片Uri：content：//media/external
某個圖片的Uri：content：//media/external/images/media/4
2 SQL注入漏洞
對Content Provider進行增刪改查時，程序沒有對用戶的輸入進行過濾，未採用參數滑查詢的方式，可能導致sql注入攻擊。所謂的Sql注入攻擊指的是攻擊者可以精心構造selection參數，projection參數以及其他有效的SQL語句組成部分，實現未授權的情況下從Content Provider獲取更多信息。
3 目錄遍歷漏洞
Android Content Provider存在文件目錄遍歷安全漏洞，該漏洞源於對外暴露Content Provider組件的應用，沒有對Content Provider組件的訪問進行權限控制和對訪問的目標文件的Content Query Uri進行有效判斷，攻擊者利用該應用暴露的Content Provider的openFile()接口進行文件目錄遍歷以達到訪問任意可讀文件的目的；
漏洞位置： ContentProvider.openFile(Uri uri, String mode)
漏洞觸發前提條件：
1. 對外暴露的Content Provider組件實現了openFile()接口；
2. 沒有對所訪問的目標文件Uri進行有效判斷，如沒有過濾限制如“../”可實現任意可讀文件的訪問的Content Query Uri；
漏洞原理:對外暴露的Content Provider實現了openFile()接口，因此其他有相應調用該Content Provider權限的應用即可調用Content Provider的openFile()接口進行文件數據訪問。但是如果沒有進行Content Provider訪問權限控制和對訪問的目標文件的Uri進行有效判斷，攻擊者利用文件目錄遍歷訪問任意可讀文件。
安全防護
1. 不向外部app提供數據的私有content provider顯示設置exported = “false”，避免組件暴露。
2. 內部app通過content provider交換數據時，設置protectionLevel = “signature”驗證簽名。
3.公開的content provier確保不存儲敏感數據。
4.應避免SQLiteDatabase.rawQuery()進行查詢，而應該使用編譯好的參數化語句。
使用預編譯好的語句比如SQLiteStatement，不僅可以避免SQL注入，而且操作性能上也大幅提高，因爲不用每次都進行解析。另一個方法是使用query(),insert(),update()和delete()方法，因爲這些函數也提供了參數化的語句。
5.去除沒有必要的openFile()接口
6.過濾限制跨域訪問，對訪問的目標文件的路徑進行有效判斷
7. 設置權限來進行內部應用通過Content Provider的數據共享
使用簽名驗證來控制Content Provider共享數據的訪問權限：設置protectionLevel=”signature”；