Heim > Java > javaLernprogramm > Hauptteil

Randfälle, die Sie im Hinterkopf behalten sollten. Teilzeit der Überprüfung bis hin zur Nutzungszeit der Rennbedingungen in der Android-Benutzeroberfläche

WBOY
Freigeben: 2024-08-09 09:45:02
Original
321 Leute haben es durchsucht

In diesem Artikel zeigen wir, wie sich Rennbedingungen auf das Android-Laufzeitberechtigungssystem auswirken.

Wenn Sie Entwickler sind, haben Sie wahrscheinlich schon von Rennbedingungen gehört. Sie sind häufig mit gleichzeitigen Hintergrundoperationen verbunden, die in Sekundenbruchteilen ausgeführt werden. Bestimmte Rennbedingungen können jedoch auch in der Benutzeroberfläche angezeigt werden und unendlich lange andauern. In diesem Artikel zeigen wir, wie sich Rennbedingungen auf das Android-Laufzeitberechtigungssystem auswirken.

Rennbedingungen und Zeitpunkt der Überprüfung bis zum Zeitpunkt der Nutzung – was bedeutet das?

Zuerst müssen wir einige Grundbegriffe erklären.

Race Condition tritt auf, wenn mehrere Vorgänge gleichzeitig ausgeführt werden und ihre Reihenfolge das Ergebnis beeinflusst. Ein Lehrbuchbeispiel sind zwei Threads, die dieselbe Variable erhöhen. Es scheint trivial zu sein, aber normalerweise müssen wir spezielle, threadsichere Elemente verwenden, um es richtig zu implementieren.

Zeit der Prüfung bis zum Zeitpunkt der Nutzung (TOCTTOU oder TOCTOU, ausgesprochen TOCK too) ist eine bestimmte Art von Race Condition, bei der einem durchgeführten Vorgang eine Zustandsprüfung vorausgeht und dieser Zustand wird in der Zeit zwischen einer Prüfung und der tatsächlichen Ausführung geändert. Dies lässt sich häufig dadurch verdeutlichen, dass die Benutzerrechte lediglich beim Anmelden überprüft werden. Wenn Sie beispielsweise zum Zeitpunkt der Anmeldung ein Administrator sind und Ihre Berechtigungen bis zur Abmeldung nutzen können, auch wenn Ihr Administratorzugriff in der Zwischenzeit widerrufen wird.

Android-Laufzeitberechtigungen

Lassen Sie uns auch die Grundlagen der Android-Laufzeitberechtigungen zusammenfassen.

Ab Android 6.0 (API-Level 23) müssen die gefährlichsten Berechtigungen vom Benutzer explizit zur Laufzeit erteilt werden und nicht alle auf einmal bei der App-Installation. Das auffälligste Element hier ist ein Systemdialog mit den Schaltflächen VERWEIGEREN und ZULASSEN, wie in Abbildung 1 dargestellt.

Edge Cases to Keep in Mind. Part  Time of Check to Time of Use Race Conditions in Android UI
Abbildung 1. Laufzeitberechtigungsdialog

Nachdem wir auf die Schaltfläche DENY geklickt haben, erhalten wir PERMISSION_DENIED im onRequestPermissionsResult-Rückruf und wir sollten die Funktionalität deaktivieren, die von dieser Berechtigung abhängt. Laut offiziellem Snippet.

Darüber hinaus kann der Benutzer Berechtigungen auch über den Bildschirm App-Berechtigungen in den Anwendungseinstellungen erteilen oder verweigern. Sie können diesen Bildschirm in Abbildung 2 sehen.

Edge Cases to Keep in Mind. Part  Time of Check to Time of Use Race Conditions in Android UI
Abbildung 2. App-Berechtigungsbildschirm

Randfälle gibt es überall

Die meisten von Ihnen denken vielleicht, dass die Verweigerung von Laufzeitberechtigungen eine supereinfache Funktion ist und es kein Element gibt, das beschädigt werden kann. Nun, nichts könnte weiter von der Wahrheit entfernt sein!

Ein Dialog erscheint nur, wenn keine Erlaubnis erteilt wird. Wir haben also den Zeitpunkt der Überprüfung kurz vor der Anzeige eines Dialogs. Und Nutzungszeit, wenn auf die Schaltfläche „VERWEIGEN“ geklickt wird. Ein Zeitraum zwischen ihnen kann ewig dauern – der Benutzer kann einen Dialog öffnen und dann die Home- oder Letzte-Taste drücken, um die Aufgabe mit der App in den Hintergrund zu verschieben und später jederzeit zurückzukehren.

Überprüfen wir, ob der Laufzeit-Berechtigungsdialog für TOCTTOU anfällig ist. Dazu können wir eine supereinfache Aktivität erstellen, die nach der Rückkehr aus dem Dialog die tatsächlich erteilten Berechtigungen überprüft. Beachten Sie, dass wir neben der Standardüberprüfung der onRequestPermissionsResult-Argumente auch Context#checkSelfPermission() aufrufen, um den aktuellen Berechtigungsgewährungsstatus abzurufen. Vergessen Sie nicht, targetSdkVersion auf 23 oder höher zu setzen. Der Code sollte so aussehen:

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"
    }
}
Nach dem Login kopieren

Jetzt können wir einen Test durchführen. Dazu benötigen wir ein Gerät oder AVD mit Android 6.0 (API 23) oder neuer. Das Testergebnis ist in Abbildung 3 dargestellt.

Edge Cases to Keep in Mind. Part  Time of Check to Time of Use Race Conditions in Android UI
Abbildung 3. Eingefangenes TOCTTOU

Wir können sehen, dass die Ergebnisse unterschiedlich sind. Das Argument „onRequestPermissionsResult“ ist ungültig. Der DENY-Button leugnet also nichts! Es macht einfach nichts mit dem Berechtigungsstatus, sondern gibt verweigerte Ergebnisse an die App zurück.

Einpacken

Bei der Überprüfung verschiedener Dinge im Code ist es wichtig, das Timing zu berücksichtigen. Das Zwischenspeichern von Prüfergebnissen kann zu Fehlern und seltsamen Effekten führen. Die TOCTTOU-Schwachstelle hängt weder von der Plattform noch von der Programmiersprache ab und wurde daher als CWE-367 klassifiziert.

Sie können den vollständigen Quellcode auf GitHub überprüfen.
Das Projekt enthält auch einen automatisierten UI-Test, der das Problem demonstriert.

Ursprünglich veröffentlicht auf www.thedroidsonroids.com am 14. Dezember 2017.

Das obige ist der detaillierte Inhalt vonRandfälle, die Sie im Hinterkopf behalten sollten. Teilzeit der Überprüfung bis hin zur Nutzungszeit der Rennbedingungen in der Android-Benutzeroberfläche. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Quelle:dev.to
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage
Über uns Haftungsausschluss Sitemap
Chinesische PHP-Website:Online-PHP-Schulung für das Gemeinwohl,Helfen Sie PHP-Lernenden, sich schnell weiterzuentwickeln!