Prácticas recomendadas de seguridad de aplicaciones

Esta sección contiene recomendaciones para garantizar la seguridad de las aplicaciones en dispositivos Android.

Revisión del código fuente

La revisión del código fuente puede detectar una amplia gama de problemas de seguridad, incluidos los identificados en este documento. Android recomienda encarecidamente la revisión del código fuente tanto manual como automatizada.

  • Siga una guía de seguridad integral cuando realice revisiones para garantizar la cobertura. Utilice estándares internos o externos relevantes para garantizar revisiones consistentes y completas.
  • Ejecute un linter, como el linter de Android Studio , en todo el código de la aplicación mediante el SDK de Android y corrija los problemas identificados.
  • Analice el código nativo con una herramienta automatizada que puede detectar problemas de gestión de la memoria, como desbordamientos de búfer y errores de uno en uno.
  • El sistema de compilación de Android es compatible con muchos de los desinfectantes LLVM, como AddressSanitizer y UndefinedBehaviorSanitizer , que se pueden usar para el análisis en tiempo de ejecución de problemas relacionados con la memoria. En combinación con fuzzing, compatible con Android a través de libFuzzer , los desinfectantes pueden descubrir casos extremos inusuales que requieren una mayor investigación.
  • Un asesor de seguridad bien informado debe revisar el código de mayor riesgo, como criptografía, procesamiento de pagos y procesamiento de PII.

Pruebas automatizadas

Las pruebas automatizadas pueden ayudar a detectar una amplia gama de problemas de seguridad y deben realizarse con regularidad.

  • Ejecute la última versión de CTS regularmente durante todo el proceso de desarrollo para detectar problemas temprano y reducir el tiempo de corrección. Android usa CTS como parte de la integración continua en nuestro proceso de compilación automatizado, que se compila varias veces al día.
  • Automatice las pruebas de seguridad de las interfaces, incluidas las pruebas con entradas mal formadas (pruebas fuzz). El sistema de compilación de Android es compatible con libFuzzer para escribir pruebas de fuzz.

Escaneo de vulnerabilidades

El análisis de vulnerabilidades puede ayudar a garantizar que las aplicaciones preinstaladas estén libres de vulnerabilidades de seguridad conocidas. La detección avanzada puede reducir el tiempo y el costo necesarios para abordar estas vulnerabilidades y prevenir el riesgo para los usuarios y los dispositivos.

  • Analice todas las aplicaciones preinstaladas con una herramienta de análisis de vulnerabilidades de aplicaciones reconocida en la industria y corrija las vulnerabilidades detectadas.

Aplicaciones potencialmente dañinas

Es importante asegurarse de que las aplicaciones preinstaladas en su dispositivo no sean aplicaciones potencialmente dañinas (PHA). Usted es responsable del comportamiento de todas las aplicaciones que se incluyen en sus dispositivos. Antes del lanzamiento del dispositivo, escanee todas las aplicaciones precargadas en busca de vulnerabilidades.

Para obtener más información sobre las PHA y cómo Google las está combatiendo en Play Store, consulte la documentación para desarrolladores de Google Play Protect .

Instalación y permisos de la aplicación

Los permisos excesivos para aplicaciones preinstaladas pueden crear un riesgo de seguridad. Restrinja las aplicaciones preinstaladas a los permisos mínimos necesarios y asegúrese de que no tengan acceso a permisos o privilegios innecesarios. Los permisos de la aplicación se describen en AndroidManifest.xml .

  • No otorgue permisos o privilegios innecesarios a las aplicaciones preinstaladas. Revise detenidamente las aplicaciones con privilegios del sistema, ya que pueden tener permisos muy confidenciales.
  • Asegúrese de que todos los permisos solicitados sean relevantes y necesarios para la funcionalidad de esa aplicación específica.
  • Asegúrese de que haya una divulgación de usuario para todas las aplicaciones preinstaladas que usan el permiso INSTALL_PACKAGES .
  • Asegúrese de que el desarrollador esté obligado por contrato a no instalar ninguna aplicación como UID 0.
  • Evalúe los permisos declarados en el manifiesto de todas las aplicaciones que se instalarán a través de la red del desarrollador.
  • Asegúrese de que el desarrollador esté obligado por contrato a escanear todas las URL de descarga de las aplicaciones de instalación y actualización automática con la API de navegación segura de Google antes de entregar las aplicaciones en el dispositivo.

firma de aplicaciones

Las firmas de aplicaciones juegan un papel importante en la seguridad del dispositivo y se utilizan para verificar permisos y actualizaciones de software. Al seleccionar una clave para usar para firmar aplicaciones, es importante considerar si una aplicación estará disponible solo en un solo dispositivo o será común en varios dispositivos.

  • Asegúrese de que las aplicaciones no estén firmadas con una clave conocida públicamente, como la clave de desarrollador de AOSP.
  • Asegúrese de que las claves utilizadas para firmar aplicaciones se administren de manera consistente con las prácticas estándar de la industria para el manejo de claves confidenciales, incluido un módulo de seguridad de hardware (HSM) que proporciona acceso limitado y auditable.
  • Asegúrese de que las aplicaciones no estén firmadas con la clave de la plataforma. Si lo hace, le da a la aplicación acceso a los permisos de firma de la plataforma, que son muy potentes y solo están destinados a ser utilizados por los componentes del sistema operativo. Las aplicaciones del sistema deben usar permisos privilegiados.
  • Asegúrese de que las aplicaciones con el mismo nombre de paquete no estén firmadas con claves diferentes. Esto suele ocurrir cuando se crea una aplicación para diferentes dispositivos, especialmente cuando se usa la clave de plataforma. Si la aplicación es independiente del dispositivo, use la misma clave en todos los dispositivos. Si la aplicación es específica para un dispositivo, cree nombres de paquetes únicos por dispositivo y clave.

Aislamiento de aplicaciones y procesos

El modelo de sandboxing de Android brinda seguridad adicional en torno a las aplicaciones y los procesos cuando se usa correctamente.

Aislamiento de procesos raíz

Los procesos raíz son el objetivo más frecuente de los ataques de escalada de privilegios; la reducción del número de procesos raíz reduce el riesgo de escalada de privilegios.

  • Asegúrese de que los dispositivos ejecuten el código mínimo necesario como raíz. Siempre que sea posible, use un proceso normal de Android en lugar de un proceso raíz. Si un proceso debe ejecutarse como raíz en un dispositivo, documente el proceso en una solicitud de función AOSP para que pueda revisarse públicamente.
  • Siempre que sea posible, el código raíz debe aislarse de los datos que no son de confianza y se debe acceder a ellos a través de la comunicación entre procesos (IPC). Por ejemplo, reduzca la funcionalidad raíz a un pequeño Servicio accesible a través de Binder y exponga el Servicio con permiso de firma a una aplicación con privilegios bajos o nulos para manejar el tráfico de red.
  • Los procesos raíz no deben escuchar en un socket de red.
  • Los procesos raíz no deben incluir un tiempo de ejecución de propósito general, como una VM de Java).

Aislamiento de aplicaciones del sistema

En general, las aplicaciones preinstaladas no deben ejecutarse con el identificador único (UID) del sistema compartido. Si es necesario que una aplicación use el UID compartido del sistema u otro servicio privilegiado (por ejemplo, teléfono), la aplicación no debe exportar ningún servicio, receptor de transmisión o proveedor de contenido al que puedan acceder aplicaciones de terceros instaladas por los usuarios. .

  • Asegúrese de que los dispositivos ejecuten el código mínimo necesario como sistema. Siempre que sea posible, utilice un proceso de Android con su propio UID en lugar de reutilizar el UID del sistema.
  • Siempre que sea posible, el código del sistema debe aislarse de los datos no confiables y exponer IPC solo a otros procesos confiables.
  • Los procesos del sistema no deben escuchar en un socket de red. Este es un requisito de CTS.

Procesos de aislamiento

El Sandbox de aplicaciones de Android proporciona aplicaciones con una expectativa de aislamiento de otros procesos en el sistema, incluidos los procesos raíz y los depuradores. A menos que la aplicación y el usuario habiliten específicamente la depuración, ninguna aplicación debe violar esa expectativa.

  • Asegúrese de que los procesos raíz no accedan a los datos dentro de las carpetas de datos de aplicaciones individuales, a menos que utilice un método de depuración de Android documentado.
  • Asegúrese de que los procesos raíz no accedan a la memoria de las aplicaciones, a menos que utilice un método de depuración de Android documentado.
  • Asegúrese de que los dispositivos no incluyan ninguna aplicación que acceda a datos o memoria de otras aplicaciones o procesos.