Sécurité des applications à l'ère agentique

Bonjour, je m'appelle Kristen.

Bonjour, je m'appelle Sabs.

Nous sommes ici aujourd'hui pour vous parler de la sécurité à l'ère agentique.

L'année dernière, nous avons versé plus de 2 millions de dollars de récompenses pour le programme Android Bug Hunters et plus de 200 000 dollars pour les applications mobiles.

À l'ère agentique, la sécurité des applications évolue constamment.

Parlons donc des outils qui nous aident à résoudre ces problèmes rapidement et efficacement.

Pour améliorer les performances des agents pour la sécurité Android, la solution n'est pas d'améliorer le prompt.

Il s'agit d'outils et de workflows qui aident les agents à comprendre nos chaînes d'outils et notre API pour assurer la sécurité de votre application.

Il est 16h30.

Un jeudi.

Vous êtes en train de publier une version, et l'intégration continue passe au rouge. Une seule erreur s'affiche : un broadcast receiver a été enregistré sans flag d'exportation.

Que vous fassiez partie d'une petite équipe où vous devez tout gérer ou d'une grande équipe où les contrôles de sécurité interviennent au moment de la publication, la réalité est la même.

Nous sommes des ingénieurs produit, nous déployons rapidement des fonctionnalités de haute qualité, et nous ne sommes pas nécessairement des chercheurs en sécurité.

Alors, quel est l'instinct naturel ?

Nous transmettons donc cet avertissement à un outil agentif et demandons à l'agent de le corriger.

Mais l'outil agentique, qui fonctionne sans le contexte de votre projet, présente trois angles morts.

Il se peut qu'il ne sache pas que votre application est créée à partir de modules de fonctionnalités dynamiques ou de bundles multi-APK.

Il voit un fichier, pas un artefact livré.

Il se peut qu'il ne sache pas ou ne puisse pas tracer le flux de données de votre UI Kotlin vers votre logique partagée KMP dans les appels JNI C++ natifs.

Il ne voit qu'une seule couche.

Enfin, il se peut qu'il ne connaisse pas votre SDK minimal ni vos types de compilation Gradle.

Nous avons donc demandé à un agent d'examiner l'application et d'effectuer un audit de sécurité.

Six résultats ont été renvoyés.

Et voici le problème.

Chacun d'entre eux est correct.

Elles sont toutes défendables, mais une seule d'entre elles correspond au bug que nous avons rencontré au départ.

Le reste est un mélange de bonnes pratiques, de points à approfondir, de spéculations et d'éléments qui ne s'appliquent peut-être même pas.

Maintenant, vous appliquez cela à une véritable base de code, avec plus d'avertissements, et dans chaque demande d'extraction, vous serez tenté d'utiliser l'annotation "suppress lint".

Vous devrez modifier le code pour que la modification soit fusionnée, ou vous risquez même de passer complètement à côté d'une faille.

C'est ainsi que de véritables failles passent entre les mailles du filet.

L'outil n'a pas été négligent, il a été prudent, mais la prudence n'est pas synonyme d'utilité.

Prenons un exemple concret.

Par exemple, vous demandez à votre agent : "Audit every exported component in this app for app intent intent redirection." (Audite chaque composant exporté dans cette application pour la redirection d'intent d'intent d'application).

Il s'agit d'une véritable tâche de sécurité, et sur une application multimodule, elle est de taille.

C'est le genre de requête où le coût apparaît réellement.

Sans instructions spécifiques à Android, l'agent n'a pas de stratégie pour répondre à cette question.

Il utilise donc la force brute.

Il peut lire des modules qui n'exportent rien du tout.

Il peut redéduire à partir du premier principe ce qui rend une redirection d'intent exploitable.

Il peut suivre des chemins qui n'étaient pas accessibles.

Vous payez pour l'exploration, pas pour l'analyse.

Une compétence est ce qui fournit la stratégie manquante.

Par exemple, les compétences de sécurité Android fournissent à votre agent des instructions qui suivent les conseils actuels, la même séquence d'étapes qu'un chercheur en sécurité suivrait réellement, et l'agent arrête de deviner.

Il ne redécouvre pas les règles, car elles ont été fournies par la compétence.

Nous avons actuellement lancé deux compétences de sécurité : Intent Security et Permissions.

La sécurité des intents concerne ce que d'autres applications peuvent faire faire à votre application.

Votre application dispose d'autorisations et d'une session de connexion que les autres n'ont pas.

Ainsi, chaque composant exporté et chaque intent en attente que vous distribuez sont un moyen potentiel pour quelqu'un d'agir par votre intermédiaire.

Cette compétence permet d'éviter ce problème.

La compétence "Autorisations" permet de combler l'écart entre une autorisation déclarée et une autorisation réellement appliquée.

Il peut vous aider à rédiger la vérification des autorisations appropriée.

Il permet d'identifier si un fournisseur avec un chemin d'accès générique accorde l'accès à l'ensemble de la base de données au lieu d'un seul répertoire.

Il détecte également les demandes d'autorisations excessives.

Par exemple, demander un accès étendu alors que le sélecteur de photos suffirait.

Utilisez-le avec la CLI Android, puis demandez "Audit for intent security" (Auditer la sécurité des intents).

Aucune configuration.

Aucun réglage de règle.

Ainsi, la sortie n'est pas une liste d'avertissements.

C'est un avis.

Voici un bug, voici pourquoi il est important pour votre application et voici comment le corriger.

Voici un conseil de pro.

La CLI Android facilite la recherche et l'installation.

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

Et comme la compétence sait exactement ce qu'elle doit chercher dans votre projet, elle voit votre application telle qu'elle est réellement livrée.

Il respecte votre SDK minimal pour que le correctif se compile, les chemins d'accès aux fichiers réels et les numéros de ligne réels.

Voici l'avis que vous recevez.

Il pointe vers le fichier et la ligne exacts, explique la menace réelle et la raison de la modification, et ne se contente pas de dire que Lint l'a dit.

Il indique la compétence qu'il a utilisée.

Il a lu la configuration de compilation, a vu que le SDK minimum était 26 et a choisi ContextCompat pour que le correctif fonctionne. Il vous fournit ensuite un diff pour que vous puissiez l'appliquer.

Il s'agit de l'avertissement que nous avons vu au début, mais avec une suggestion de correction et un raisonnement supplémentaire.

Les compétences précédentes permettent donc de détecter les bugs de sécurité.

Parlons maintenant d'un autre domaine : la conformité aux règles relatives aux applications.

Par exemple, imaginons que vous soyez un nouveau développeur d'applications et que vous souhaitiez lancer votre application sur le Play Store.

Remplir le formulaire Sécurité des données est une étape importante du lancement de votre application. Nous allons donc utiliser tous les outils à notre disposition pour nous assurer que tout est correct avant d'envoyer l'application.

La compétence "Règles Play" effectue une analyse statique de votre codebase.

Si vous publiez une application Play Store existante, il peut également croiser cette analyse de code statique avec les déclarations du Play Store.

Cette compétence peut vous aider à détecter les problèmes potentiels liés aux règles Play avant l'envoi de l'application, et non après, et à accélérer le processus d'envoi.

Le workflow est semblable à celui des autres compétences que nous avons abordées : importez l'application, puis demandez "Audit this app for Google Play policy compliance before I submit it" (Audite cette application pour vérifier sa conformité avec le règlement de Google Play avant que je ne l'envoie).

Vous verrez une capture d'écran d'un exemple de rapport à droite, ainsi que les commandes de la CLI Android pour l'installer ci-dessous.

android skills list
android skills add play-policy-insights

Tout ce dont nous avons parlé jusqu'à présent se passe avant la livraison : audit des intents, vérification des autorisations et validation de la conformité.

C'est la sécurité au moment de la compilation, et elle est essentielle.

Cependant, il existe toute une catégorie de menaces qui n'apparaissent qu'une fois que votre APK est déployé et qu'il s'exécute sur des appareils que vous ne contrôlez peut-être pas.

L'API Play Integrity répond à trois questions au moment de l'exécution auxquelles votre propre code ne peut pas répondre : s'agit-il d'un build authentique et non modifié de votre application ?

L'application s'exécute-t-elle sur un appareil Android authentique ?

S'agit-il d'un compte utilisateur Play ?

Vous pouvez donc utiliser l'API Play Integrity pour obtenir des évaluations sur l'intégrité de l'application, de l'appareil et plus encore.

En plus de vous permettre de publier votre application de manière plus rapide, plus simple et plus sécurisée, nous vous aidons également à protéger les revenus et la réputation de votre application.

Protégez donc votre entreprise contre les fraudes et les utilisations abusives.

Le nouveau tableau de bord "Protégé avec Play", que vous pouvez voir ici, vous aide à surveiller et à configurer vos défenses d'intégrité, de distribution et de monétisation au même endroit.

Nous réduisons également la latence de préchauffage de l'API Play Integrity afin que vous puissiez utiliser ces vérifications lors des parcours utilisateur où la vitesse est essentielle pour bloquer plus rapidement les menaces et les appareils à risque.

Nous venons de parler des fonctionnalités et des outils Android qui permettent de sécuriser les applications, mais qu'en est-il de vos utilisateurs ?

Commençons par examiner la protection par OTP par SMS.

Imaginons que vous souhaitiez implémenter la validation des utilisateurs par SMS pour votre application et envoyer des codes de validation.

L'autorisation SMS permet à l'application d'accéder aux données de messagerie, y compris aux données sensibles telles que les mots de passe à usage unique.

Nous avons donc introduit quelques API dans votre application pour que vous puissiez l'implémenter. Vous n'avez donc pas besoin de demander des autorisations SMS étendues, mais vous pouvez toujours récupérer les codes OTP par SMS pour la validation.

L'API SMS Retriever permet à votre application de valider automatiquement les OTP sans autorisations SMS étendues.

Vous ajoutez au message un hachage de 11 caractères identifiant votre application, et le système ne vous transmet que ce message.

Si vous ne pouvez pas contrôler le format du message, utilisez l'API SMS User Consent.

Le système affiche une seule invite ponctuelle.

L'utilisateur appuie sur "Autoriser" ou "Refuser". S'il autorise, vous recevez ce message unique.

Il n'est toujours pas nécessaire de demander une autorisation d'accès aux SMS générale.

Certaines applications peuvent n'avoir besoin de votre position exacte qu'une seule fois pour effectuer des tâches.

L'autorisation ponctuelle existante est très contraignante pour l'utilisateur. C'est pourquoi les développeurs demandent parfois une autorisation plus large pour accéder à la position exacte.

Le bouton de localisation est donc un outil qui permet d'accorder facilement à l'application un accès unique à la position exacte.

Il s'agit d'un élément d'interface utilisateur Android qui peut être personnalisé et intégré par les développeurs d'applications.

Nous avons lancé la première version de la bibliothèque Jetpack du bouton de localisation en version alpha en juin.

Vous pouvez voir ici les autorisations requises pour activer le bouton de localisation dans votre fichier manifeste Android.

<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>

Vous devez déclarer l'autorisation d'accéder à la position standard en ajoutant l'indicateur d'autorisation onlyForLocationButton, ainsi que l'autorisation USE_LOCATION_BUTTON dédiée requise par le service de rendu à distance du système.

À droite, vous trouverez le code Jetpack permettant de l'implémenter.

...
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()
            }
        },
...

Ici, nous créons un bouton de localisation et initialisons un rappel.

Ce rappel est déclenché lorsque l'utilisateur appuie sur le bouton de localisation pour décider d'accorder ou de refuser l'autorisation.

Le mode Protection Avancée est une fonctionnalité destinée aux utilisateurs à risque ou soucieux de la sécurité, mais tout le monde peut l'activer.

Par exemple, si vous proposez une application bancaire, vous n'imposez pas l'authentification multifacteur supplémentaire pour chaque virement, car les utilisateurs n'apprécient pas cette étape supplémentaire au quotidien.

En revanche, lorsque le mode Protection Avancée est activé, votre application sait que cet utilisateur souhaite bénéficier d'une protection maximale. Vous pouvez donc exiger automatiquement une authentification biométrique pour chaque transfert.

Le mode Protection Avancée implémente un ensemble de configurations prédéfinies conçues pour renforcer la protection des appareils.

Nous allons vous montrer comment l'intégrer à votre application.

Vous devez demander l'autorisation, interroger le mode Protection Avancée et vérifier si l'utilisateur a activé le mode Protection Avancée en appelant le service système Advanced Protection Mode Manager sur l'appareil.

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)
}

Vous pouvez ensuite écouter les modifications d'exécution en enregistrant le rappel.

Nous avons abordé de nombreux sujets aujourd'hui.

Voici donc des liens rapides si vous souhaitez en savoir plus.

Nous allons faire une courte pause pour que vous puissiez noter les URL dont vous avez besoin.

Merci.

Merci.