Google se compromete a promover la equidad racial para las comunidades negras. Ver cómo.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Mejores prácticas 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 manual y automática del código fuente.

  • 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 utilizando el SDK de Android y corrija los problemas identificados.
  • Analice el código nativo utilizando una herramienta automatizada que puede detectar problemas de administración de memoria, como desbordamientos de búfer y errores de uno por uno.
  • El sistema de compilación de Android es compatible con muchos de los desinfectantes LLVM, como AddressSanitizer y UndefinedBehaviorSanitizer , que pueden usarse 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 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 construye varias veces al día.
  • Automatice las pruebas de seguridad de las interfaces, incluidas las pruebas con entradas con formato incorrecto (pruebas fuzz). El sistema de compilación de Android admite libFuzzer para escribir pruebas fuzz.

Escaneo de vulnerabilidades

El escaneo 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 riesgos para los usuarios y dispositivos.

  • Escanee todas las aplicaciones preinstaladas utilizando una herramienta de escaneo de vulnerabilidades de aplicaciones reconocida en la industria y aborde 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 inicio 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 combate en Play Store, consulte la documentación para desarrolladores de Google Play Protect .

Instalación de aplicaciones y permisos

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 a fondo las aplicaciones con privilegios del sistema, ya que pueden tener permisos muy sensibles.
  • 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 del usuario para todas las aplicaciones preinstaladas que usan el permiso INSTALL_PACKAGES .
  • Asegúrese de que el desarrollador tiene la obligación contractual de 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 tenga la obligación contractual de escanear todas las URL de descarga de las aplicaciones de actualización e instalación automáticas con la API de navegación segura de Google antes de enviar aplicaciones al dispositivo.

Firma de la aplicación

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

  • Asegúrese de que las aplicaciones no estén firmadas con una clave conocida públicamente, como la clave de desarrollador AOSP.
  • Asegúrese de que las claves utilizadas para firmar aplicaciones se administren de manera coherente con las prácticas estándar de la industria para el manejo de claves sensibles, 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. Al hacerlo, la aplicación tiene acceso a los permisos de firma de la plataforma, que son muy potentes y solo están destinados a ser utilizados por 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 ocurre a menudo al crear una aplicación para diferentes dispositivos, especialmente cuando se usa la tecla 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 del dispositivo, cree nombres de paquete únicos por dispositivo y clave.

Aislar aplicaciones y procesos

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

Aislar procesos de raíz

Los procesos raíz son el objetivo más frecuente de los ataques de escalada de privilegios; La reducción de la cantidad 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 root. Siempre que sea posible, use un proceso normal de Android en lugar de un proceso raíz. Si un proceso debe ejecutarse como root en un dispositivo, documente el proceso en una solicitud de función AOSP para que pueda ser revisado públicamente.
  • Siempre que sea posible, el código raíz debe aislarse de los datos no confiables y acceder 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 pocos o ningún privilegio 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 máquina virtual 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, use 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 el 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

Android Application Sandbox 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 documentado de depuración de Android.
  • Asegúrese de que los procesos raíz no accedan a la memoria de las aplicaciones, a menos que utilice un método documentado de depuración de Android.
  • Asegúrese de que los dispositivos no incluyan ninguna aplicación que acceda a los datos o la memoria de otras aplicaciones o procesos.