一、前臺(tái)服務(wù)類型

targetSdkVersion 34 的情況下，必須為應(yīng)用內(nèi)的每個(gè)前臺(tái)服務(wù)(foreground-services) 指定至少一種前臺(tái)服務(wù)類型。

前臺(tái)服務(wù)類型是在Android10引入的，通過(guò)android:foregroundServiceType 可以指定 的服務(wù)類型，可供選擇的前臺(tái)服務(wù)類型有：

camera
connectedDevice
dataSync
health
location
mediaPlayback
mediaProjection
microphone
phoneCall
remoteMessaging
shortService
specialUse
systemExempted

二、Android14應(yīng)用安全

1.對(duì)pending/implicit intent的限制

對(duì)于面向Android14的應(yīng)用，Android通過(guò)以下方式限制應(yīng)用向內(nèi)部應(yīng)用組件發(fā)送隱式intent：

(1).隱式intent僅傳遞給導(dǎo)出的組件，應(yīng)用必須使用明確的intent來(lái)交付給未導(dǎo)出的組件，或者將組件標(biāo)記為已導(dǎo)出(exported)。

(2).如果應(yīng)用創(chuàng)建一個(gè)mutable pending intent，但intent未指定組件或包，系統(tǒng)現(xiàn)在會(huì)拋出異常。

這些更改可防止惡意應(yīng)用攔截只供給用內(nèi)部組件使用的隱式intent，例如：

如果應(yīng)用嘗試使用隱式intent啟動(dòng)該 activity，則會(huì)拋出異常：

//Throws an exception when targeting Android 14.
context.startActivity(Intent("com.example.action.APP_ACTION"))

要啟動(dòng)未導(dǎo)出的Activity，應(yīng)用應(yīng)改用顯式Intent：

//This makes the intent explicit.
val explicitIntent =
       Intent("com.example.action.APP_ACTION")
explicitIntent.apply {
   package = context.packageName
}
context.startActivity(explicitIntent)

2.運(yùn)行時(shí)注冊(cè)的廣播接收器必須指定導(dǎo)出行為

以Android14為目標(biāo)，并使用context-registered

receivers(ContextCompat.registerReceiver)應(yīng)用和服務(wù)的需要指定一個(gè)標(biāo)志，以指示接收器是否應(yīng)導(dǎo)出到設(shè)備上的所有其他應(yīng)用:分別為RECEIVER_EXPORTED或RECEIVER_NOT_EXPORTED。

val filter = IntentFilter(APP_SPECIFIC_BROADCAST)
val listenToBroadcastsFromOtherApps = false
val receiverFlags = if (listenToBroadcastsFromOtherApps) {
   ContextCompat.RECEIVER_EXPORTED
} else {
   ContextCompat.RECEIVER_NOT_EXPORTED
}
ContextCompat.registerReceiver(context, br, filter, receiverFlags)

3.僅接收系統(tǒng)廣播的接收器例外

如果應(yīng)用僅通過(guò)Context#registerReceiver方法為系統(tǒng)廣播注冊(cè)接收器時(shí)，那么它可以不在注冊(cè)接收器時(shí)指定標(biāo)志,例如 android.intent.action.AIRPLANE_MODE。

4.更安全的動(dòng)態(tài)代碼加載

如果應(yīng)用以Android14為目標(biāo)平臺(tái)并使用動(dòng)態(tài)代碼加載(DCL)，則所有動(dòng)態(tài)加載的文件都必須標(biāo)記為只讀，否則，系統(tǒng)會(huì)拋出異常。

建議應(yīng)用盡可能避免動(dòng)態(tài)加載代碼，因?yàn)檫@樣做會(huì)大大增加應(yīng)用因代碼注入或代碼篡改而受到危害的風(fēng)險(xiǎn)。

如果必須動(dòng)態(tài)加載代碼，請(qǐng)使用以下方法將動(dòng)態(tài)加載的文件(例如:DEX、JAR或APK文件)在文件打開(kāi)后和寫(xiě)入任何內(nèi)容之前立即設(shè)置為只讀：

val jar = File("DYNAMICALLY_LOADED_FILE.jar")
val os = FileOutputStream(jar)
os.use {
   // Set the file to read-only first to prevent race conditions
   jar.setReadOnly()
   // Then write the actual file content
}
val cl = PathClassLoader(jar, parentClassLoader)

5.處理已存在的動(dòng)態(tài)加載文件

為防止現(xiàn)有動(dòng)態(tài)加載文件拋出異常，我們建議可以嘗試在應(yīng)用中再次動(dòng)態(tài)加載文件之前，刪除并重新創(chuàng)建這些文件。

重新創(chuàng)建文件時(shí)，請(qǐng)按照前面的指導(dǎo)在寫(xiě)入時(shí)將文件標(biāo)記為只讀，或者將現(xiàn)有文件重新標(biāo)記為只讀，但在這種情況下，強(qiáng)烈建議首先驗(yàn)證文件的完整性(例如，通過(guò)根據(jù)可信值檢查文件的簽名)，以幫助保護(hù)應(yīng)用免受惡意操作。

6.Zip path traversal

對(duì)于針對(duì)Android14的應(yīng)用，Android通過(guò)以下方式防止Zip路徑遍歷漏洞

如果zip文件條目名稱包含".."或以"/"開(kāi)頭，則ZipFile(String)和ZipInputStream.getNextEntry()會(huì)拋出一個(gè)ZipException。

應(yīng)用可以通過(guò)調(diào)用dalvik.system.ZipPathValidator.clearCallback()選擇退出驗(yàn)證。

7.從后臺(tái)啟動(dòng)活動(dòng)的附加限制

針對(duì)Android14的應(yīng)用，系統(tǒng)進(jìn)一步限制了應(yīng)用在后臺(tái)啟動(dòng)Activity的時(shí)間

(1).當(dāng)應(yīng)用使用PendingIntent#send()發(fā)送PendingIntent以及類似行為時(shí)，如果應(yīng)用想要授予其自己的后臺(tái)service啟動(dòng)權(quán)限以啟動(dòng)pending intent，則該應(yīng)用現(xiàn)在必須選擇加入一個(gè) ActivityOptions，具體為帶有

setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)

(2).當(dāng)一個(gè)可見(jiàn)應(yīng)用使用bindService()綁定另一個(gè)在后臺(tái)運(yùn)行的應(yīng)用的服務(wù)時(shí)，如果該可見(jiàn)應(yīng)用想要將其自己的后臺(tái)activity啟動(dòng)權(quán)限授予綁定服務(wù)，則它現(xiàn)在必須選擇加入 BIND_ALLOW_ACTIVITY_STARTS 標(biāo)志。

這些更改擴(kuò)展了現(xiàn)有的一組限制 ，通過(guò)防止惡意應(yīng)用濫用 API 從后臺(tái)啟動(dòng)破壞性活動(dòng)來(lái)保護(hù)用戶。

8.Android14將禁止修改系統(tǒng)內(nèi)置根證書(shū)

Android14不再允許開(kāi)發(fā)者修改系統(tǒng)內(nèi)置根證書(shū)進(jìn)行調(diào)試，這意味著開(kāi)發(fā)者無(wú)法通過(guò)諸如替換證書(shū)或中間人劫持的方式來(lái)檢測(cè)某些流量。

Android系統(tǒng)的證書(shū)存儲(chǔ)庫(kù)位于/system/etc/security/cacerts/，盡管從Android7.0開(kāi)始開(kāi)發(fā)者無(wú)法直接修改證書(shū)庫(kù)，但如果root了那么還可以修改證書(shū)庫(kù)路徑，直接注入自己需要的證書(shū)，比如自簽名的泛證書(shū)。

而在Android14中，谷歌做了一項(xiàng)可以快速反應(yīng)的安全措施：通過(guò)Google Play更新安卓系統(tǒng)的證書(shū)庫(kù)。

這樣做也不是沒(méi)有原因，以前證書(shū)綁定在系統(tǒng)里，谷歌無(wú)法直接更新，這導(dǎo)致有些證書(shū)被吊銷后谷歌也無(wú)法及時(shí)操作，這也導(dǎo)致注入Let's Encrypt 因?yàn)樾枰嫒菖f版安卓系統(tǒng)，不得不推遲證書(shū)更新，因?yàn)樾伦C書(shū)不受舊版安卓系統(tǒng)的信任。

后續(xù)谷歌可以隨時(shí)通過(guò)Google Play更新證書(shū)庫(kù)，包括加載新的ROOT CA和吊銷某些ROOT CA，這讓谷歌可以快速應(yīng)對(duì)CA行業(yè)的某些問(wèn)題。

然而問(wèn)題在于這種新的更新方法不再?gòu)?system/etc/security/cacerts/讀取證書(shū)，而是從另一個(gè)路徑/apex/com.android.conscrypt/cacerts/讀取證書(shū)。

而APEX容器背后確切的機(jī)制很難完全理解，因?yàn)榇嬖诤芏嗉?xì)節(jié)沒(méi)有公布出來(lái)，而在測(cè)試的時(shí)候開(kāi)發(fā)者也發(fā)現(xiàn)嘗試修改這個(gè)目錄是沒(méi)用的，系統(tǒng)會(huì)直接忽略修改。

因此即便注入自簽名的證書(shū)也無(wú)法被系統(tǒng)讀取，所以也沒(méi)法再使用中間人之類的手段進(jìn)行劫持，來(lái)達(dá)到調(diào)試某些TLS流量的目的。

好消息是Android14的這項(xiàng)變化有助于大幅度提高Android對(duì)CA行業(yè)的響應(yīng)速度，例如快速吊銷或信任證書(shū)，這將有助于提高Android設(shè)備的安全性。 ?
?
壞消息就是對(duì)開(kāi)發(fā)者和安全研究人員來(lái)說(shuō)這就很難受了，因?yàn)闊o(wú)法讓系統(tǒng)信任自簽名證書(shū)，這將對(duì)調(diào)試和安全分析工作產(chǎn)生嚴(yán)重影響。

審核編輯：湯梓紅