Anwendungssicherheit im Zeitalter der agentischen KI

Hallo, ich bin Kristen.

Hallo, ich bin Sabs.

Wir sprechen heute über Sicherheit im Zeitalter der agentischen KI.

Im vergangenen Jahr haben wir im Rahmen des Android Bug Hunters-Programms über 2 Millionen US-Dollar und für Mobilgeräte über 200.000 US-Dollar an Prämien ausgezahlt.

In der heutigen Ära der KI-Agenten entwickelt sich die Anwendungssicherheit ständig weiter.

Sehen wir uns also die Tools an, mit denen wir diese Probleme schnell und effektiv lösen können.

Wenn Sie die Leistung von KI-Agenten im Bereich Android-Sicherheit verbessern möchten, ist ein besserer Prompt nicht die Lösung.

Es handelt sich um Tools und Workflows, die KI-Agenten helfen, unsere Toolchains und die API zu verstehen, um Ihre App zu schützen.

Es ist 16:30 Uhr.

An einem Donnerstag.

Sie erstellen einen Release und die CI wird rot. Es gibt nur einen Fehler: Ein Übertragungsempfänger wurde ohne Export-Flag registriert.

Egal, ob Sie in einem kleinen Team arbeiten und alle Aufgaben selbst erledigen, oder in einem großen Team, in dem Sicherheitsprüfungen erst beim Erstellen des Releases durchgeführt werden – die Realität ist dieselbe.

Wir sind Produktentwickler, die schnell hochwertige Funktionen bereitstellen, und nicht unbedingt Sicherheitsforscher.

Was ist also der natürliche Instinkt?

Wir übergeben diese Warnung also an ein agentenbasiertes Tool und bitten den KI-Agenten um eine Lösung.

Ein agentisches Tool, das ohne Ihren Projektkontext arbeitet, hat jedoch drei blinde Flecken.

Es ist möglicherweise nicht bekannt, dass Ihre App aus dynamischen Funktionsmodulen oder Multi-APK-Bundles besteht.

Es sieht eine Datei, kein ausgeliefertes Artefakt.

Es kann den Datenfluss von Ihrer Kotlin-UI über Ihre freigegebene KMP-Logik bis hin zu den nativen C++-JNI-Aufrufen möglicherweise nicht nachvollziehen.

Es sieht nur eine Ebene.

Außerdem ist es möglicherweise nicht über Ihr Mindest-SDK oder Ihre Gradle-Build-Varianten informiert.

Wir haben einen KI-Agenten auf die App angesetzt und um ein Sicherheitsaudit gebeten.

Es wurden sechs Ergebnisse gefunden.

Und hier ist der Haken:

Jeder einzelne von ihnen hat recht.

Sie sind alle vertretbar, aber nur einer davon ist der Fehler, mit dem wir tatsächlich begonnen haben.

Der Rest ist eine Mischung aus Best Practices, Dingen, die weiter untersucht werden müssen, Spekulationen und Dingen, die möglicherweise gar nicht zutreffen.

Wenn Sie das jetzt auf eine echte Codebasis mit mehr Warnungen übertragen, werden Sie bei jedem Pull-Anfrage versucht sein, die Lint-Warnungen zu unterdrücken.

Sie müssen die Änderung zusammenführen, um sie zu übernehmen, oder übersehen möglicherweise sogar eine Sicherheitslücke.

So können echte Sicherheitslücken unbemerkt bleiben.

Das Tool war nicht unvorsichtig, sondern vorsichtig, aber vorsichtig ist nicht dasselbe wie nützlich.

Machen wir das Ganze konkreter.

Angenommen, Sie bitten Ihren KI-Agenten: „Prüfe jede exportierte Komponente in dieser App auf App-Intent-Weiterleitung.“

Das ist eine echte Sicherheitsaufgabe, die bei einer App mit mehreren Modulen sehr umfangreich ist.

Bei dieser Art von Anfrage fallen tatsächlich Kosten an.

Ohne Android-spezifische Anweisungen hat der Agent keine Strategie für diese Frage.

Es wird also Brute-Force-Angriffen ausgesetzt.

Es kann Module lesen, die überhaupt nichts exportieren.

Es kann sein, dass es noch einmal von Grund auf herleitet, was eine Intent-Weiterleitung ausnutzbar macht.

Es kann Pfaden folgen, die nie erreichbar waren.

Sie bezahlen für die explorative Datenanalyse, nicht für die Analyse.

Eine Fähigkeit ist das, was die fehlende Strategie liefert.

Android-Sicherheits-Skills geben Ihrem Agenten beispielsweise Anweisungen, die den aktuellen Richtlinien entsprechen. Das ist dieselbe Abfolge von Schritten, die ein Sicherheitsforscher tatsächlich befolgen würde. Der Agent muss also nicht mehr raten.

Die Regeln werden nicht neu ermittelt, da sie vom Skill bereitgestellt wurden.

Derzeit haben wir zwei Sicherheits-Skills eingeführt: Intent Security und Permissions.

Bei der Intent-Sicherheit geht es darum, was andere Apps in Ihrer App auslösen können.

Ihre App hat Berechtigungen, eine Anmeldesitzung nicht.

Jede exportierte Komponente und jeder ausstehende Intent, den Sie weitergeben, ist also eine potenzielle Möglichkeit für jemanden, über Sie zu agieren.

Diese Fähigkeit hilft, sich davor zu schützen.

Die Berechtigungsfunktion hilft, die Lücke zwischen einer deklarierten und einer tatsächlich erzwungenen Berechtigung zu schließen.

Sie kann Ihnen helfen, die entsprechende Berechtigungsprüfung zu schreiben.

So lässt sich feststellen, ob ein Anbieter mit einem Platzhalterpfad die gesamte Datenbank anstelle eines einzelnen Verzeichnisses gewährt.

Außerdem werden übermäßige Berechtigungsanfragen erkannt.

Beispiel: Es wird ein allgemeiner Zugriff angefordert, obwohl die Bildauswahl ausreichen würde.

Verwenden Sie es mit der Android-Befehlszeile und fragen Sie dann: „Audit for intent security.“

Keine Konfiguration.

Keine Regeloptimierung.

Die Ausgabe ist also keine Wand aus Warnungen.

Es ist eine Rezension.

Hier ist ein Fehler, hier ist der Grund, warum er für Ihre App wichtig ist, und hier ist die Lösung.

Und hier ist der Profitipp.

Mit der Android-Befehlszeile ist es einfach, die App zu finden und zu installieren.

android skills list
android skills add android-intent-security
android skills add android-permissions-security

Und weil der Skill genau weiß, wonach er in Ihrem Projekt suchen muss, sieht er Ihre App so, wie sie tatsächlich ausgeliefert wird.

Das SDK-Minimum wird berücksichtigt, damit der Fix kompiliert werden kann. Außerdem werden echte Dateipfade und Zeilennummern verwendet.

Hier ist die Rezension, die Sie erhalten.

Es verweist auf die genaue Datei und Zeile und erklärt die tatsächliche Bedrohung und den Grund für die Änderung, nicht nur, dass Lint das so sagt.

Der verwendete Skill wird angegeben.

Es hat die Build-Konfiguration gelesen, die SDK-Mindestversion 26 erkannt und ContextCompat ausgewählt, damit der Fix funktioniert. Außerdem hat es Ihnen ein Diff zur Verfügung gestellt, damit Sie es anwenden können.

Das ist die Warnung, die wir am Anfang gesehen haben, aber jetzt mit einem Lösungsvorschlag und einer Begründung.

Mit den bisherigen Fähigkeiten werden Sicherheitsfehler erkannt.

Kommen wir nun zu einem anderen Bereich: der Einhaltung von App-Richtlinien.

Stellen Sie sich vor, Sie sind ein neuer App-Entwickler und möchten Ihre App im Google Play Store veröffentlichen.

Das Ausfüllen des Formulars zur Datensicherheit ist ein wichtiger Schritt bei der Einführung Ihrer App. Nutzen Sie daher alle verfügbaren Tools, um sicherzustellen, dass Sie es vor dem Einreichen der App richtig ausfüllen.

Der Play-Richtlinien-Skill führt eine statische Analyse Ihrer Codebasis durch.

Wenn Sie eine vorhandene Google Play Store-App veröffentlichen, kann die statische Codeanalyse auch mit Google Play Store-Erklärungen abgeglichen werden.

Wenn Sie diesen Skill ausführen, können Sie potenzielle Probleme mit den Google Play-Richtlinien vor und nicht erst nach dem Einreichen der App erkennen und den Einreichungsprozess beschleunigen.

Der Workflow ist ähnlich wie bei den anderen Skills, die wir besprochen haben: Importieren Sie die App und fragen Sie dann: „Prüfe diese App auf Einhaltung der Google Play-Richtlinien, bevor ich sie einreiche.“

Rechts sehen Sie einen Screenshot eines Beispielberichts und darunter die Android-CLI-Befehle für die Installation.

android skills list
android skills add play-policy-insights

Alles, worüber wir bisher gesprochen haben, passiert also vor der Veröffentlichung: Intents prüfen, Berechtigungen prüfen, Compliance validieren.

Das ist die Sicherheit während der Build-Zeit und sie ist unerlässlich.

Es gibt jedoch eine ganze Reihe von Bedrohungen, die erst auftreten, wenn Ihr APK auf Geräten ausgeführt wird, die Sie möglicherweise nicht kontrollieren.

Die Play Integrity API beantwortet zur Laufzeit drei Fragen, die Ihr eigener Code nicht über sich selbst beantworten kann: Handelt es sich um einen echten, unveränderten Build Ihrer App?

Wird die App auf einem echten Android-Gerät ausgeführt?

Und ist das ein Google Play-Nutzerkonto?

Mit der Play Integrity API können Sie Ergebnisse zur App-Integrität, Geräteintegrität und mehr erhalten.

Wir machen es nicht nur schneller und einfacher, Ihre App sicherer zu veröffentlichen, sondern auch, den Umsatz und den Ruf Ihrer App zu schützen.

Schützen Sie Ihr Unternehmen also vor Betrug und Missbrauch.

Im neuen Dashboard „Mit Google Play geschützt“ können Sie die Schutzmaßnahmen für Integrität, Bereitstellung und Monetarisierung an einem Ort überwachen und konfigurieren.

Außerdem reduzieren wir die Aufwärmlatenz für die Play Integrity API, damit Sie diese Prüfungen bei zeitkritischen User Journeys verwenden können, um Bedrohungen und riskante Geräte schneller zu blockieren.

Wir haben gerade über die Android-Funktionen und ‑Tools gesprochen, die zum Schutz von Apps beitragen. Aber wie sieht es mit Ihren Nutzern aus?

Sehen wir uns zuerst den SMS-OTP-Schutz an.

Angenommen, Sie möchten eine SMS-basierte Nutzerbestätigung für Ihre App implementieren und Bestätigungscodes senden.

Die SMS-Berechtigung gewährt der App Zugriff auf Messaging-Daten, einschließlich sensibler Daten wie OTPs.

Wir haben einige APIs in Ihrer App eingeführt, mit denen Sie das implementieren können. So müssen Sie keine umfassenden SMS-Berechtigungen anfordern, können aber trotzdem SMS-OTP-Codes zur Bestätigung abrufen.

Mit der SMS Retriever API kann Ihre App OTPs automatisch bestätigen, ohne dass umfassende SMS-Berechtigungen erforderlich sind.

Sie hängen einen 11-stelligen Hash an die Nachricht an, der Ihre App identifiziert, und das System übergibt Ihnen nur diese eine Nachricht.

Wenn Sie das Nachrichtenformat nicht steuern können, verwenden Sie die SMS User Consent API.

Das System zeigt eine einmalige Aufforderung an.

Der Nutzer tippt auf „Zulassen“ oder „Ablehnen“. Wenn er „Zulassen“ auswählt, erhalten Sie diese eine Nachricht.

Eine allgemeine SMS-Berechtigung ist weiterhin nicht erforderlich.

Einige Apps benötigen den genauen Standort möglicherweise nur einmal, um Aufgaben auszuführen.

Die bestehende einmalige Berechtigung ist für Nutzer umständlich, weshalb Entwickler manchmal stattdessen eine umfassendere Berechtigung für den genauen Standort anfordern.

Der Button „Standort“ ist also ein Tool, mit dem der App auf einfache Weise einmaliger Zugriff auf den genauen Standort gewährt werden kann.

Es ist ein Android-UI-Element, das von App-Entwicklern angepasst und eingebettet werden kann.

Im Juni haben wir die erste Version der Alpha-Jetpack-Bibliothek für den Button „Standort“ veröffentlicht.

Hier sehen Sie die Berechtigungen, die erforderlich sind, um den Button „Standort“ in Ihrem Android-Manifest zu aktivieren.

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
    android:usesPermissionFlags="onlyForLocationButton"/>

<uses-permission android:name="android.permission.USE_LOCATION_BUTTON" />

    <application
        android:icon="@mipmap/ic_launcher"
        android:label="LocationButtonSample"
        android:theme="@style/Theme.PinPoint">
        <activity
            android:name=".MainActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>

Sie müssen die Standardberechtigung zur Standortermittlung deklarieren, indem Sie das Berechtigungs-Flag onlyForLocationButton zusammen mit der dedizierten Berechtigung USE_LOCATION_BUTTON hinzufügen, die für den Remote-Rendering-Dienst des Systems erforderlich ist.

Rechts sehen Sie den Jetpack-Code, um sie zu implementieren.

...
import androidx.core.locationbutton.compose.LocationButton

@Composable
fun LocationPermissionScreen(onPermissionGranted: () -> Unit, onPermissionDenied: () -> Unit) {
    // Renders the secure system-trusted Location Button composable
    LocationButton(
        // Callback triggered when the user taps the secure button and makes a decision on the permission dialog
        onPermissionResult = { isGranted ->
            if (isGranted) {
                onPermissionGranted()
            } else {
                onPermissionDenied()
            }
        },
...

Hier sehen Sie, dass wir einen Button „Standort“ erstellen und einen Callback initialisieren.

Dieser Callback wird ausgelöst, wenn der Nutzer auf den Button „Standort“ tippt, um die Berechtigung zu erteilen oder zu verweigern.

Der erweiterte Sicherheitsmodus ist eine Funktion, die für Nutzer mit hohem Sicherheitsrisiko oder sicherheitsbewusste Nutzer gedacht ist. Er kann aber von jedem aktiviert werden.

Wenn Sie beispielsweise eine Banking-App anbieten, sollten Sie die zusätzliche Multi-Faktor-Authentifizierung nicht bei jeder Überweisung erzwingen, da Nutzer diese zusätzliche Reibung nicht mögen.

Wenn der erweiterte Schutzmodus aktiviert ist, weiß deine App, dass dieser Nutzer den maximalen Schutz möchte. Du kannst also automatisch bei jeder Überweisung eine biometrische Authentifizierung verlangen.

Im erweiterten Sicherheitsmodus werden vordefinierte Konfigurationen implementiert, die den Geräteschutz verbessern sollen.

Hier erfahren Sie, wie Sie die Funktion in Ihre App einbinden.

Sie müssen die Berechtigung anfordern, den Modus „Erweiterte Sicherheit“ abfragen und prüfen, ob der Nutzer den Modus „Erweiterte Sicherheit“ aktiviert hat. Dazu rufen Sie auf dem Gerät den Systemdienst „Advanced Protection Mode Manager“ auf.

class AdvancedProtectionManager() {
  // Check the current status
  fun isAdvancedProtectionEnabled(): Boolean

  // Be alerted when status changes
  fun registerAdvancedProtectionCallback(executor: Executor,
                                         callback: Callback)

  fun unregisterAdvancedProtectionCallback(callback: Callback)
}

interface Callback() {
  // Called when advanced protection state changes
  fun onAdvancedProtectionChanged(enabled: Boolean)
}

Anschließend können Sie auf Laufzeitänderungen warten, indem Sie den Callback registrieren.

Wir sind heute viele Themen durchgegangen.

Hier finden Sie Links zu weiteren Informationen.

Wir machen hier eine kurze Pause, damit Sie sich die benötigten URLs notieren können.

Vielen Dank.

Vielen Dank.