Seguridad de las apps en la era de los agentes

Hola, soy Kristen.

Hola, soy Sabs.

Y estamos aquí para hablarles sobre la seguridad en la era de los agentes.

El año pasado, otorgamos más de USD 2 millones en recompensas por el programa Android Bug Hunters y más de USD 200, 000 por el programa para dispositivos móviles.

En la era de los agentes, la seguridad de las apps evoluciona constantemente.

Por lo tanto, hablemos de las herramientas que nos ayudan a resolver estos problemas de forma rápida y eficaz.

Para mejorar el rendimiento de los agentes en la seguridad de Android, la respuesta no es una mejor instrucción.

Son herramientas y flujos de trabajo que ayudan a los agentes a comprender nuestras cadenas de herramientas y la API para mantener la seguridad de tu app.

Son las 4:30 p.m.

Un jueves.

Estás creando una versión y la CI se pone en rojo, con un solo error: un receptor de transmisiones registrado sin una marca de exportación.

Por lo tanto, ya sea que estés en un equipo pequeño, en el que debas encargarte de todo, o en uno grande, en el que las verificaciones de seguridad se realicen mientras se lanza la versión, la realidad es la misma.

Somos ingenieros de productos, lanzamos funciones de alta calidad con rapidez y no necesariamente somos investigadores de seguridad.

Entonces, ¿cuál es el instinto natural?

Por lo tanto, le pasamos esa advertencia a una herramienta de agentes y le pedimos al agente que la corrija.

Sin embargo, la herramienta de agentes, que funciona sin el contexto de tu proyecto, tiene tres puntos ciegos.

Es posible que no sepa que tu app se compila a partir de módulos de funciones dinámicas o paquetes de varios APKs.

Ve un archivo, no un artefacto enviado.

Es posible que no sepa o no pueda rastrear el flujo de datos desde tu IU de Kotlin hasta tu lógica compartida de KMP en las llamadas nativas de JNI de C++.

Solo ve una capa.

Por último, es posible que no conozca tu SDK mínimo ni tus variantes de compilación de Gradle.

Por lo tanto, dirigimos un agente a la app y le pedimos una auditoría de seguridad.

Se obtuvieron seis hallazgos.

Y aquí está la cuestión.

Ninguno de ellos se equivoca.

Son defendibles, pero solo uno de ellos es el error con el que empezamos.

El resto es una combinación de prácticas recomendadas, aspectos que se deben investigar más, especulaciones y aspectos que tal vez ni siquiera se apliquen.

Por lo tanto, ahora que escalas eso a una base de código real, con más advertencias, y en cada solicitud de extracción, tendrás la tentación de recurrir a la supresión de lint.

Tendrás que cambiar para que se combine ese cambio, o incluso podrías pasar por alto una vulnerabilidad por completo.

Y así es como se filtran las vulnerabilidades reales.

La herramienta no fue descuidada, sino cuidadosa, pero cuidadosa no es lo mismo que útil.

Veamos un ejemplo concreto.

Por ejemplo, le pides a tu agente: "Audita cada componente exportado en esta app para detectar redireccionamientos de intents de la app".

Esa es una tarea de seguridad genuina y, en una app de varios módulos, es una tarea grande.

Ese es el tipo de solicitud en la que realmente se muestra el costo.

Y sin orientación específica para Android, el agente no tiene una estrategia para esa pregunta.

Por lo tanto, usa la fuerza bruta.

Puede leer módulos que no exportan nada.

Es posible que vuelva a derivar del primer principio lo que hace que un redireccionamiento de intents sea explotable.

Puede seguir rutas a las que nunca se pudo acceder.

Estás pagando por la exploración, no por el análisis.

Una habilidad es lo que proporciona la estrategia que falta.

Por ejemplo, las habilidades de seguridad de Android le proporcionan a tu agente instrucciones que siguen la orientación actual, la misma secuencia de pasos que seguiría un investigador de seguridad, y el agente deja de adivinar.

No vuelve a descubrir las reglas porque la habilidad las proporcionó.

Actualmente, lanzamos dos habilidades de seguridad: Seguridad de intents y Permisos.

La seguridad de los intents se relaciona con lo que otras apps pueden hacer que haga tu app.

Tu app tiene permisos y una sesión de acceso que ellos no tienen.

Por lo tanto, cada componente exportado y cada intent pendiente que entregas es una forma potencial de que alguien actúe a través de ti.

La habilidad ayuda a protegerse de esto.

La habilidad de permisos ayuda a cerrar la brecha entre un permiso que se declara y uno que se aplica de forma efectiva.

Puede ayudarte a escribir la verificación de permisos adecuada.

Ayuda a identificar si un proveedor con una ruta de acceso con comodín otorga acceso a toda la base de datos en lugar de a un directorio.

También detecta solicitudes excesivas de permisos.

Por ejemplo, solicitar un acceso amplio cuando el selector de fotos sería suficiente.

Úsala con la CLI de Android y, luego, pregunta "Audit for intent security".

Sin configuración.

No se ajustan las reglas.

Por lo tanto, el resultado no es un muro de advertencias.

Es una opinión.

Aquí hay un error, aquí se explica por qué es importante para tu app y aquí está la solución.

Y aquí tienes una sugerencia avanzada.

Usar la CLI de Android facilita la búsqueda y la instalación.

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

Y, como la habilidad sabe exactamente qué buscar en tu proyecto, ve tu app tal como se envía.

Respeta tu SDK mínimo para que la corrección se compile, las rutas de acceso de archivos reales y los números de línea reales.

Esta es la opinión que recibes.

Señala el archivo y la línea exactos, explica la amenaza real y el motivo del cambio, no solo que Lint lo dice.

Cita qué habilidad usó.

Leyó la configuración de compilación, vio que el SDK mínimo era el 26 y eligió ContextCompat para que la corrección funcione, y te entrega una diferencia para que puedas aplicarla.

Esa es la advertencia con la que abrimos, pero ahora con una corrección sugerida y un razonamiento adicional.

Por lo tanto, las habilidades anteriores detectan errores de seguridad.

Ahora, hablemos de otra área: el cumplimiento de las políticas de la app.

Por ejemplo, imagina que eres un nuevo desarrollador de apps que quiere lanzar su producto en Play Store.

Completar el formulario de seguridad de los datos es un paso importante para lanzar tu app, así que usemos todas las herramientas que podamos para asegurarnos de que lo hacemos bien antes de enviar la app.

La habilidad de políticas de Play realiza un análisis estático de tu base de código.

Si publicas una app existente de Play Store, también puedes comparar datos mediante referencia cruzada ese análisis de código estático con las declaraciones de Play Store.

Ejecutar esta habilidad puede ayudarte a detectar posibles problemas relacionados con las políticas de Play antes de enviar la app, no después, y a acelerar el proceso de envío.

El flujo de trabajo es similar al de las otras habilidades que estuvimos analizando: impórtala y, luego, pídele que audite la app para verificar que cumpla con las políticas de Google Play antes de enviarla.

A la derecha, verás una captura de pantalla de un informe de ejemplo y, debajo, los comandos de la Android CLI para instalarlo.

android skills list
android skills add play-policy-insights

Todo lo que hemos hablado hasta ahora ocurre antes de que envíes la app: auditar intents, verificar permisos y validar el cumplimiento.

Esa es la seguridad en el momento de la compilación, y es esencial.

Sin embargo, existe toda una clase de amenazas que solo se presentan una vez que el APK está disponible para el público y se ejecuta en dispositivos que tal vez no controles.

La API de Play Integrity responde tres preguntas en el tiempo de ejecución que tu propio código no puede responder sobre sí mismo: ¿Se trata de una compilación original y sin modificar de tu app?

¿Se está ejecutando en un dispositivo Android auténtico?

¿Y es una cuenta de usuario de Play?

Por lo tanto, puedes usar la API de Play Integrity para obtener veredictos sobre la integridad de la app, la integridad del dispositivo y mucho más.

Además de hacer que sea más rápido y fácil publicar tu app de forma más segura, también facilitamos la protección de los ingresos y la reputación de tu app.

Por lo tanto, defiende tu empresa contra fraudes y abusos.

El nuevo panel Protegido con Play, que puedes ver aquí, te ayuda a supervisar y configurar tus defensas de integridad, distribución y monetización en un solo lugar.

También reduciremos la latencia de preparación de la API de Play Integrity para que puedas usar estas verificaciones durante los recorridos críticos del usuario en los que la velocidad es un factor clave para bloquear amenazas y dispositivos riesgosos con mayor rapidez.

Acabamos de analizar las funciones y herramientas de Android para ayudar a mantener la seguridad de las apps, pero ¿qué pasa con los usuarios?

Primero, veamos la protección de OTP por SMS.

Supongamos que quieres implementar la verificación de usuarios basada en SMS para tu app y enviar códigos de verificación.

El permiso de SMS proporciona acceso de la app a los datos de mensajería, incluidos los datos sensibles, como las OTP.

Por lo tanto, introdujimos algunas APIs en tu app para que puedas implementar eso, de modo que no necesites solicitar permisos de SMS amplios, pero aún puedas obtener códigos de OTP de SMS para la verificación.

La API de SMS Retriever permite que tu app verifique automáticamente las OTP sin permisos de SMS amplios.

Agregas un hash de 11 caracteres que identifica tu app al mensaje, y el sistema te entrega solo ese mensaje.

Si no puedes controlar el formato del mensaje, usa la API de SMS User Consent.

El sistema muestra un solo mensaje único.

El usuario presiona Permitir o Denegar y, si permite, recibes ese único mensaje.

Aún no es necesario un permiso de SMS amplio.

Es posible que algunas apps solo necesiten la ubicación precisa una vez para completar tareas.

El permiso de un solo uso existente tiene una alta fricción para el usuario, por lo que, a veces, los desarrolladores solicitan un permiso preciso más amplio.

Por lo tanto, el botón de ubicación es una herramienta que proporciona una forma sencilla de otorgar a la app acceso único a la ubicación precisa.

Es un elemento de la IU de Android que los desarrolladores de apps pueden personalizar e incorporar.

En junio, lanzamos la primera versión alfa de la biblioteca de Jetpack del botón de ubicación.

Aquí, puedes ver los permisos necesarios para habilitar el botón de ubicación en tu manifiesto de 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>

Debes declarar el permiso de ubicación estándar agregando la marca de permiso onlyForLocationButton, junto con el permiso USE_LOCATION_BUTTON dedicado que requiere el servicio de renderización remota del sistema.

A la derecha, se encuentra el código de Jetpack para 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()
            }
        },
...

Aquí puedes ver que estamos creando un botón de ubicación y, luego, inicializando una devolución de llamada.

Esta devolución de llamada se activa cuando el usuario presiona el botón de ubicación para decidir si se otorga o se rechaza el permiso.

El modo de Protección avanzada es una función dirigida a los usuarios en riesgo o que se preocupan por la seguridad, pero cualquier persona puede habilitarla.

Por ejemplo, si tienes una app bancaria, no exiges la autenticación de varios factores adicional en cada transferencia porque a los usuarios habituales no les gusta esa fricción adicional.

Sin embargo, cuando el Modo de protección avanzada está activado, tu app sabe que este usuario quiere la máxima protección, por lo que puedes requerir automáticamente la autenticación biométrica en cada transferencia.

El modo de Protección avanzada implementa un conjunto de parámetros de configuración predefinidos diseñados para reforzar la protección del dispositivo.

Aquí te mostramos cómo integrarla en tu app.

Debes solicitar el permiso, consultar el modo de Protección avanzada y verificar si el usuario lo activó llamando al servicio del sistema del administrador del modo de Protección avanzada integrado en el 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)
}

Luego, puedes detectar los cambios en el entorno de ejecución registrando la devolución de llamada.

Hoy abordamos muchos temas.

Aquí tienes vínculos rápidos por si quieres obtener más información sobre ellos.

Haremos una pausa aquí por un momento para que puedas anotar las URLs que necesitas.

Gracias.

Gracias.