首頁 >Java >java教程 >要記住的邊緣情況。 Android UI 中的部分時間檢查使用時間競爭條件

要記住的邊緣情況。 Android UI 中的部分時間檢查使用時間競爭條件

WBOY
WBOY原創
2024-08-09 09:45:02361瀏覽

在本文中,我們將展示競爭條件如何影響 Android 執行時間權限系統。

如果您是開發人員,您可能聽說過競爭條件。它們通常與在幾分之一秒內執行的並發後台操作相關。然而,某些競爭條件也可能出現在 UI 中並持續無限時間。在本文中,我們將展示競爭條件如何影響 Android 運行時權限系統。

競態條件和檢查時間到使用時間-這是什麼意思?

首先,我們需要解釋一些基本術語。

競爭條件 如果同時發生多個操作並且它們的順序影響結果,則會發生競爭條件。一個教科書的例子是兩個線程遞增同一個變數。這看起來很簡單,但是,通常我們需要使用特殊的、線程安全的元素來正確實現它。

檢查時間到使用時間(TOCTTOU 或TOCTOU,發音為TOCK )是一種特定類型的競爭條件,其中執行的操作之前是狀態檢查並且此狀態在檢查和實際執行之間的時間內被修改。通常僅在登入時檢查使用者權限來說明。例如,如果您在登入時是管理員,則可以使用您的權限直到您登出,即使您的管理員存取權限同時被撤銷。

Android運行時權限

我們也總結一下 Android 運行時權限基礎。

從 Android 6.0(API 等級 23)開始,最危險的權限必須由使用者在運行時明確授予,而不是在應用程式安裝時一次性授予。這裡最引人注目的元素是帶有 DENY 和 ALLOW 按鈕的系統對話,如圖 1 所示。

Edge Cases to Keep in Mind. Part  Time of Check to Time of Use Race Conditions in Android UI
圖 1. 運行時權限對話框

點擊 DENY 按鈕後,我們會在 onRequestPermissionsResult 回呼中收到 PERMISSION_DENIED,我們應該停用依賴於此權限的功能。根據官方片段。

此外,用戶還可以透過使用應用程式設定中的應用程式權限螢幕來授予或拒絕權限。您可以在圖 2 中看到該畫面。

Edge Cases to Keep in Mind. Part  Time of Check to Time of Use Race Conditions in Android UI
圖 2. 應用程式權限畫面

邊緣案例無所不在

大多數人可能認為運行時權限拒絕是一個超級簡單的功能,沒有任何元素可以被破壞。好吧,事實並非如此!

只有在未經許可的情況下才會出現對話。所以我們在顯示對話之前有檢查時間。以及點選「拒絕」按鈕時的使用時間。它們之間的一段時間可以永遠持續 - 用戶可以打開一個對話,然後按主頁或最近按鈕將任務與應用程式移至後台,並在以後隨時返回。

讓我們檢查一下執行時間權限對話是否容易受到 TOCTTOU 的攻擊。為此,我們可以創建一個超級簡單的活動,在從對話方塊返回後檢查實際授予的權限。請注意,除了標準的 onRequestPermissionsResult 參數檢查之外,我們還將呼叫 Context#checkSelfPermission() 來取得 目前 權限授予狀態。不要忘記將 targetSdkVersion 設定為 23 或更高。程式碼應如下圖所示:

class MainActivity : Activity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.main)
        requestPermissions(arrayOf(WRITE_EXTERNAL_STORAGE), 1)
    }

    override fun onRequestPermissionsResult(requestCode: Int, permissions: Array<out String>, grantResults: IntArray) {
        super.onRequestPermissionsResult(requestCode, permissions, grantResults)
        val checkResultTextView = findViewById<TextView>(R.id.grantResultTextView)
        val grantResultTextView = findViewById<TextView>(R.id.checkResultTextView)

        val checkPermissionResult = checkSelfPermission(WRITE_EXTERNAL_STORAGE).toPermissionResult()
        val grantPermissionResult = grantResults.firstOrNull()?.toPermissionResult()
        checkResultTextView.text = "checkSelfPermission: $checkPermissionResult"
        grantResultTextView.text = "onRequestPermissionsResult: $grantPermissionResult"
    }

    private fun Int.toPermissionResult() = when (this) {
        PERMISSION_GRANTED -> "granted"
        PERMISSION_DENIED -> "denied"
        else -> "unknown"
    }
}

現在我們可以進行測試了。為此,我們需要配備 Android 6.0 (API 23) 或更高版本的裝置或 AVD。測試結果如圖3所示。

Edge Cases to Keep in Mind. Part  Time of Check to Time of Use Race Conditions in Android UI
圖3.捕獲的TOCTTOU

我們可以看到結果不同。 onRequestPermissionsResult 參數無效。所以「拒絕」按鈕不否認任何事情!它只是對權限狀態不執行任何操作,而是將拒絕的結果傳回給應用程式。

包起來

在檢查程式碼中的各種內容時,考慮時間很重要。快取檢查結果可能會導致錯誤和奇怪的效果。 TOCTTOU 漏洞不依賴平台或程式語言,因此它被分類為 CWE-367。

您可以在 GitHub 上查看完整的原始碼。
該專案還包含演示該問題的自動化 UI 測試。

最初於 2017 年 12 月 14 日發佈於 www.thedroidsonroids.com。

以上是要記住的邊緣情況。 Android UI 中的部分時間檢查使用時間競爭條件的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn