Sicurezza delle app nell'era agentica

Ciao, sono Kristen.

Ciao, io sono Sabs.

Oggi siamo qui per parlarvi della sicurezza nell'era agentica.

Nell'ultimo anno, abbiamo assegnato oltre 2 milioni di dollari in premi per il programma Android Bug Hunters e oltre 200.000 $per i dispositivi mobili.

Nell'era agentica di oggi, la sicurezza delle app è in continua evoluzione.

Parliamo quindi degli strumenti che ci aiutano a risolvere questi problemi in modo rapido ed efficace.

Per migliorare le prestazioni degli agenti per la sicurezza di Android, la risposta non è un prompt migliore.

Si tratta di strumenti e workflow per aiutare gli agenti a comprendere le nostre toolchain e API per contribuire a proteggere la tua app.

Sono le 16:30.

Di giovedì.

Stai creando una release e l'integrazione continua diventa rossa, con un solo errore: un broadcast receiver registrato senza un flag di esportazione.

Quindi, che tu faccia parte di un team di piccole dimensioni, in cui ti occupi di tutto, o di un team di grandi dimensioni, in cui i controlli di sicurezza vengono eseguiti mentre stai preparando la release, la realtà è la stessa.

Siamo ingegneri di prodotto, spediamo rapidamente funzionalità di alta qualità e non siamo necessariamente ricercatori di sicurezza.

Quindi, qual è l'istinto naturale?

Quindi, passiamo l'avviso a uno strumento agentico e chiediamo all'agente di correggere l'errore.

Tuttavia, lo strumento agentico, che opera senza il contesto del tuo progetto, ha tre punti ciechi.

Potrebbe non sapere che la tua app è creata da moduli della funzionalità dinamiche o bundle di APK multipli.

Vede un file, non un artefatto spedito.

Potrebbe non sapere o non essere in grado di tracciare il flusso di dati dalla UI Kotlin alla logica condivisa KMP nelle chiamate JNI C++ native.

Vede un solo livello.

Infine, potrebbe non essere a conoscenza dell'SDK minimo o delle versioni di build di Gradle.

Abbiamo quindi indirizzato un agente all'app e chiesto un audit della sicurezza.

Sono stati restituiti sei risultati.

E qui sta il punto.

Nessuno di questi è sbagliato.

Sono tutte difendibili, ma solo una è il bug da cui siamo partiti.

Il resto è un mix di best practice, aspetti da approfondire, speculazioni e cose che potrebbero non essere applicabili.

Quindi, ora che hai scalato questo approccio in una codebase reale, con più avvisi e in ogni richiesta di pull, sarai tentato di utilizzare l'annotazione suppress lint.

Dovrai apportare una modifica per unire la modifica o potresti persino perdere del tutto una vulnerabilità.

È così che le vulnerabilità reali passano inosservate.

Lo strumento non è stato negligente, è stato attento, ma attento non è la stessa cosa di utile.

Facciamo un esempio concreto.

Ad esempio, chiedi all'agente: "Controlla ogni componente esportato in questa app per il reindirizzamento degli intent dell'app".

Si tratta di un'attività di sicurezza autentica e, in un'app multimodulo, è un'attività di grandi dimensioni.

Questo è il tipo di richiesta in cui viene effettivamente mostrato il costo.

Senza indicazioni specifiche per Android, l'agente non ha una strategia per questa domanda.

Quindi, utilizza la forza bruta.

Potrebbe leggere moduli che non esportano nulla.

Potrebbe derivare nuovamente dal primo principio ciò che rende sfruttabile un reindirizzamento di intent.

Potrebbe seguire percorsi che non erano mai stati raggiungibili.

Stai pagando per l'esplorazione, non per l'analisi.

Una skill è ciò che fornisce la strategia mancante.

Ad esempio, le competenze di sicurezza di Android forniscono all'agente istruzioni che seguono le indicazioni attuali, la stessa sequenza di passaggi che un ricercatore di sicurezza seguirebbe effettivamente, e l'agente smette di fare supposizioni.

Non rileva nuovamente le regole perché sono state fornite dalla skill.

Al momento, abbiamo lanciato due competenze di sicurezza: Intent Security e Permissions.

La sicurezza degli intent riguarda ciò che altre app possono far fare alla tua app.

La tua app dispone di autorizzazioni e di una sessione di accesso che non sono disponibili per l'utente.

Pertanto, ogni componente esportato e ogni pending intent che distribuisci è un potenziale modo per consentire a qualcuno di agire tramite te.

La skill aiuta a evitare che questo succeda.

La skill Permissions aiuta a colmare il divario tra un'autorizzazione dichiarata e una effettivamente applicata.

Può aiutarti a scrivere il controllo delle autorizzazioni appropriato.

Aiuta a identificare se un provider con un percorso con caratteri jolly concede l'intero database anziché una directory.

Inoltre, rileva le richieste di autorizzazioni eccessive.

Ad esempio, richiedere un accesso ampio quando sarebbe sufficiente il selettore di foto.

Utilizzalo con la CLI Android, quindi chiedi "Controlla la sicurezza degli intent".

Nessuna configurazione.

Nessuna ottimizzazione delle regole.

In questo modo, l'output non è un muro di avvisi.

È una recensione.

Ecco un bug, ecco perché è importante per la tua app ed ecco la correzione.

Ecco un consiglio da pro.

Utilizza la CLI Android per trovare e installare facilmente l'app.

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

Inoltre, poiché la skill sa esattamente cosa cercare nel tuo progetto, vede la tua app così come viene effettivamente distribuita.

Rispetta l'SDK minimo in modo che la correzione venga compilata, i percorsi dei file reali e i numeri di riga reali.

Ecco la recensione che ricevi.

Indica il file e la riga esatti, spiega la minaccia reale e il motivo della modifica, non si limita a dire che lo dice Lint.

Cita la skill utilizzata.

Ha letto la configurazione di build, ha visto l'SDK minimo 26 e ha scelto ContextCompat in modo che la correzione funzioni, quindi ti fornisce un diff per applicarla.

Questo è l'avviso con cui abbiamo iniziato, ma ora con una correzione suggerita e un ragionamento aggiuntivo.

Quindi, le competenze precedenti rilevano i bug di sicurezza.

Ora parliamo di un altro aspetto: la conformità alle norme relative alle app.

Ad esempio, immaginiamo che tu sia un nuovo sviluppatore di app che vuole lanciare un'app sul Play Store.

La compilazione del modulo Sicurezza dei dati è un passaggio importante per il lancio della tua app, quindi utilizziamo tutti gli strumenti possibili per assicurarci di farlo correttamente prima dell'invio dell'app.

La skill relativa alle norme di Google Play esegue un'analisi statica del tuo codebase.

Se pubblichi un'app del Play Store esistente, può anche fare un controllo incrociato dell'analisi del codice statico con le dichiarazioni del Play Store.

L'esecuzione di questa skill può aiutarti a individuare potenziali problemi relativi alle norme di Google Play prima, non dopo, l'invio dell'app e contribuisce ad accelerare la procedura di invio.

Il flusso di lavoro è simile a quello delle altre skill di cui abbiamo parlato: importala e poi chiedi "Controlla la conformità di questa app alle norme di Google Play prima che la invii".

A destra vedrai uno screenshot di un report di esempio e di seguito i comandi della CLI Android per installarlo.

android skills list
android skills add play-policy-insights

Quindi, tutto ciò di cui abbiamo parlato finora avviene prima della pubblicazione: controllo degli intent, verifica delle autorizzazioni, convalida della conformità.

Questa è la sicurezza in fase di build, ed è essenziale.

Tuttavia, esiste un'intera classe di minacce che si manifesta solo quando l'APK è disponibile pubblicamente e viene eseguito su dispositivi che potresti non controllare.

L'API Play Integrity risponde in fase di runtime a tre domande a cui il tuo codice non può rispondere: si tratta di una build originale e non modificata della tua app?

L'app è in esecuzione su un dispositivo Android originale?

Si tratta di un account utente Play?

Puoi quindi utilizzare l'API Play Integrity per restituire esiti sull'integrità dell'app, del dispositivo e altro ancora.

Oltre a rendere più rapida e semplice la pubblicazione della tua app in modo più sicuro, stiamo anche semplificando la protezione delle entrate e della reputazione della tua app.

Quindi, proteggi la tua attività da attività fraudolente e illecite.

La nuova dashboard Protetto con Play, che puoi vedere qui, ti aiuta a monitorare e configurare le difese di integrità, distribuzione e monetizzazione in un unico posto.

Stiamo anche riducendo la latenza di preparazione per l'API Play Integrity, in modo che tu possa utilizzare questi controlli durante i percorsi utente in cui la velocità è fondamentale per bloccare più rapidamente le minacce e i dispositivi rischiosi.

Abbiamo appena parlato delle funzionalità e degli strumenti di Android per contribuire a mantenere le app al sicuro, ma che dire degli utenti?

Diamo innanzitutto un'occhiata alla protezione OTP via SMS.

Supponiamo che tu voglia implementare la verifica utente basata su SMS per la tua app e inviare codici di verifica.

L'autorizzazione SMS consente all'app di accedere ai dati dei messaggi, inclusi i dati sensibili come le OTP.

Per questo motivo, abbiamo introdotto alcune API nella tua app per consentirti di implementare questa funzionalità, in modo da non dover richiedere autorizzazioni SMS generiche, ma di poter comunque ricevere i codici OTP via SMS per la verifica.

L'API SMS Retriever consente alla tua app di verificare automaticamente le OTP senza autorizzazioni SMS estese.

Aggiungi al messaggio un hash di 11 caratteri che identifica la tua app e il sistema ti consegna solo quel messaggio.

Se non puoi controllare il formato del messaggio, utilizza l'API per il consenso dell'utente SMS.

Il sistema mostra un singolo prompt una tantum.

L'utente tocca Consenti o Nega e, se consente, ricevi il singolo messaggio.

Non è ancora necessaria un'autorizzazione generica per gli SMS.

Alcune app potrebbero richiedere la posizione esatta una sola volta per completare le attività.

L'autorizzazione esistente Solo questa volta ha un attrito elevato per gli utenti, quindi a volte gli sviluppatori chiedono un'autorizzazione più ampia e precisa.

Il pulsante posizione è uno strumento che offre un modo semplice per concedere all'app l'accesso una tantum alla posizione esatta.

Si tratta di un elemento UI di Android che può essere personalizzato e incorporato dagli sviluppatori di app.

A giugno abbiamo lanciato la prima versione della libreria Jetpack alpha del pulsante posizione.

Qui puoi vedere le autorizzazioni necessarie per attivare il pulsante posizione nel file manifest di 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>

Devi dichiarare l'autorizzazione di accesso alla posizione standard aggiungendo il flag di autorizzazione onlyForLocationButton, insieme all'autorizzazione USE_LOCATION_BUTTON dedicata richiesta dal servizio di rendering remoto del sistema.

A destra, il codice Jetpack per implementarlo.

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

Come puoi vedere, stiamo creando un pulsante posizione e inizializzando un callback.

Questo callback viene attivato quando l'utente tocca il pulsante posizione per decidere se concedere o negare l'autorizzazione.

La modalità di protezione avanzata è una funzionalità rivolta agli utenti a rischio o attenti alla sicurezza, ma chiunque può attivarla.

Ad esempio, se hai un'app bancaria, non forzi l'autenticazione a più fattori aggiuntiva per ogni trasferimento perché gli utenti comuni non amano questo attrito aggiuntivo.

Tuttavia, quando la modalità di protezione avanzata è attiva, l'app sa che l'utente vuole il massimo livello di protezione, quindi puoi richiedere automaticamente l'autenticazione biometrica per ogni trasferimento.

La modalità di protezione avanzata implementa un insieme di configurazioni predefinite progettate per rafforzare la protezione del dispositivo.

Qui ti mostriamo come eseguire l'integrazione nella tua app.

Devi richiedere l'autorizzazione, eseguire una query sulla modalità di protezione avanzata e verificare se l'utente ha attivato la modalità di protezione avanzata utilizzando il servizio di sistema Advanced Protection Mode Manager sul dispositivo.

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

Poi, puoi ascoltare le modifiche di runtime registrando il callback.

Oggi abbiamo trattato molti argomenti.

Ecco alcuni link rapidi per saperne di più.

Facciamo una breve pausa per darti il tempo di annotare gli URL che ti servono.

Grazie.

Grazie.