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 del código fuente tanto manual como automatizada.

  • Siga una guía de seguridad integral al realizar revisiones para garantizar la cobertura. Utilice estándares internos o externos relevantes para garantizar revisiones consistentes y completas.
  • Ejecute un linter, como Android Studio linter , en todo el código de la aplicación utilizando el SDK de Android y corrija cualquier problema identificado.
  • Analice el código nativo utilizando una herramienta automatizada que pueda detectar problemas de administración de memoria, como desbordamientos del búfer y errores uno por uno.
  • El sistema de compilación de Android admite muchos de los desinfectantes LLVM, como AddressSanitizer y UndefinedBehaviorSanitizer , que se pueden utilizar para el análisis en tiempo de ejecución de problemas relacionados con la memoria. Combinados con fuzzing, soportados en Android a través de libFuzzer , los desinfectantes pueden descubrir casos extremos inusuales que requieren una mayor investigación.
  • Un evaluador de seguridad con conocimientos debe revisar los códigos de mayor riesgo, como las criptomonedas, el procesamiento de pagos y el 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 periódicamente durante todo el proceso de desarrollo para detectar problemas tempranamente y reducir el tiempo de corrección. Android utiliza 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 con formato incorrecto (pruebas difusas). El sistema de compilación de Android admite libFuzzer para escribir pruebas 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 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 incluidas en sus dispositivos. Antes de iniciar el 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 aplicaciones preinstaladas. Revise minuciosamente 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 divulgación del usuario para todas las aplicaciones preinstaladas que utilizan el permiso INSTALL_PACKAGES .
  • Asegúrese de que el desarrollador esté obligado contractualmente a no instalar ninguna aplicación como UID 0.
  • Evaluar 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 contractualmente a escanear todas las URL de descarga de aplicaciones de instalación y actualización automática con la API de navegación segura de Google antes de entregar aplicaciones al dispositivo.

firma de aplicaciones

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

  • Asegúrese de que las aplicaciones no estén firmadas con una clave públicamente conocida, como la clave de desarrollador 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 plataforma. Al hacerlo, la aplicación accede 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 utilizar permisos privilegiados.
  • Asegúrese de que las aplicaciones con el mismo nombre de paquete no estén firmadas con claves diferentes. Esto suele ocurrir al crear una aplicación para diferentes dispositivos, especialmente cuando se utiliza 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 del dispositivo, cree nombres de paquetes únicos por dispositivo y clave.

Aislar aplicaciones y procesos

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

Aislar procesos raíz

Los procesos raíz son el objetivo más frecuente de los ataques de escalada de privilegios; Reducir el 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 root. Siempre que sea posible, utilice 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 revisarse públicamente.
  • Siempre que sea posible, el código raíz debe aislarse de los datos que no sean de confianza y accederse a él mediante 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 máquina virtual Java).

Aislar aplicaciones del sistema

En general, las aplicaciones preinstaladas no deben ejecutarse con el identificador único del sistema (UID) compartido. Si es necesario que una aplicación utilice el UID compartido del sistema u otro servicio privilegiado (por ejemplo, un teléfono), la aplicación no debe exportar ningún servicio, receptor de transmisión o proveedor de contenido al que puedan acceder las 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 que no son de confianza y exponer IPC sólo 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 la 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 utilicen un método de depuración documentado 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 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.