Cualquier aplicación puede acceder a componentes públicos a los que no se les haya asignado explícitamente un permiso de acceso en su definición de manifiesto.

El valor predeterminado del atributo exported de los componentes de actividad, receptor y servicio de una aplicación Android depende de la presencia o ausencia de un intent-filter. La presencia de un intent-filter implica que el componente ha sido diseñado para uso externo, por lo que define el atributo exported como verdadero. Este componente es ahora accesible a cualquier otra aplicación de la plataforma Android.

Ejemplo 1: A continuación se muestra un ejemplo de actividad Android con un intent-filter y sin permiso de acceso explícito definido.

 <activity android:name=".AndroidActivity"/> 

   <intent-filter android:label="activityName"/> 

    <action android:name=".someFunAction"/> 

   </intent-filter> 

    ... 

 </activity> 

Aplicaciones malintencionadas podrían aprovechar esta actividad.

Cualquier aplicación puede acceder a componentes públicos a los que no se les haya asignado explícitamente un permiso de acceso en su definición de manifiesto. El proveedor de contenido de Android se exporta de forma predeterminada para las aplicaciones que configuran android: minSdkVersion o android: targetSdkVersion en "16" o anteriores. Para las aplicaciones que establecen cualquiera de estos atributos en "17" o posterior, el valor predeterminado es "falso".

Ejemplo 1: A continuación aparece un ejemplo de un proveedor de contenido de Android declarado sin un permiso de acceso explícito o marca exportada.

 <provider android:name=".ContentProvider"/> 

Android depende de un proveedor de seguridad para proporcionar comunicaciones de red seguras. Sin embargo, de vez en cuando, se encuentran vulnerabilidades en el proveedor de seguridad predeterminado. Para protegerse contra estas vulnerabilidades, los servicios de Google Play proporcionan una forma de actualizar automáticamente el proveedor de seguridad de un dispositivo para protegerse contra vulnerabilidades conocidas. Mediante la llamada a los métodos de los servicios de Google Play, su aplicación puede estar segura de que se ejecuta en un dispositivo que cuenta con las últimas actualizaciones para protegerse contra vulnerabilidades conocidas.

La característica Network Security Configuration permite a las aplicaciones personalizar su configuración de seguridad de red en un archivo de configuración declarativo y seguro sin modificar el código de la aplicación. Estas opciones se pueden configurar para dominios específicos y para una aplicación específica. Las funcionalidades más importantes de esta característica son las siguientes:
- Delimitadores de confianza personalizados: personalice qué entidades de certificación (CA) son de confianza para las conexiones seguras de una aplicación. Por ejemplo, confiar en determinados certificados autofirmados o restringir el conjunto de CA públicas en las que confía la aplicación.
- Anulaciones solo de depuración: depure las conexiones seguras de una aplicación sin riesgo adicional para la base instalada.
- Exclusión de tráfico de texto sin cifrar: proteja las aplicaciones del uso accidental de tráfico de texto sin cifrar.
- Asignación de certificados: restrinja la conexión segura de una aplicación a determinados certificados.

Las difusiones enviadas sin el permiso del destinatario están accesibles para todos los usuarios. Si estas difusiones contienen datos confidenciales o son interceptadas por un destinatario malintencionado, podría ponerse en peligro la aplicación.

Ejemplo 1: el siguiente código envía una difusión sin especificar el permiso del destinatario.

...
context.sendBroadcast(intent);
...

Las difusiones del sistema se pueden enviar a componentes privados. Los componentes deben ser públicos para recibir transmisiones de terceros que no pertenecen al sistema. Al registrarse para recibir transmisiones del sistema y fuera del sistema en un solo componente, parte de la funcionalidad del componente (la parte del sistema) queda innecesariamente expuesta a terceros.

Al declarar un permiso personalizado, hay cuatro opciones para especificar el nivel de protección del permiso: normal, dangerous, signature, y signature or system. Los permisos Normal se otorgan a cualquier aplicación que los solicite. Los permisos Dangerous se otorgan solo después de la confirmación del usuario. Los permisos Signature se otorgan solo a las aplicaciones firmadas por la misma clave de desarrollador que el paquete que define el permiso. Los permisos Signature or system son similares a permisos signature, pero también se otorgan a paquetes en la imagen del sistema Android.

Ejemplo 1: A continuación aparece un ejemplo de permiso personalizado declarado con el nivel de protección normal.

 <permission android:name="custom.PERMISSION"
                     android:label="@string/label_permission"
                     android:description="@string/desc_permission"
                     android:protectionLevel="normal">
      </permission>

Un proveedor de contenido declarado con atributo permission de lectura y escritura combinadas estará accesible para las entidades que soliciten acceso de lectura o escritura al proveedor. Sin embargo, en muchos casos, al igual que en el caso de los archivos en un sistema de archivos, las entidades que necesitan acceso de lectura a los datos almacenados por el proveedor no deberían poder modificar los datos. Establecer el atributo permission no permite distinguir entre usuarios de datos e interacciones que afectan la integridad de los datos.

Ejemplo 1: A continuación aparece un ejemplo de proveedor de contenido declarado con el permission (permiso) de acceso combinado de lectura y escritura.

 <provider android:name=".ContentProvider" android:permission="content.permission.READ_AND_WRITE_CONTENT"/> 

Las difusiones persistentes no se pueden proteger con un permiso, por lo que están accesibles para cualquier destinatario. Si estas difusiones contienen datos confidenciales o son interceptadas por un destinatario malintencionado, podría ponerse en peligro la aplicación.

Ejemplo 1: el programa envía una difusión persistente.

...
context.sendStickyBroadcast(intent);
...

La definición de nuevos permisos en el espacio de nombres android.permission puede tener consecuencias inesperadas cuando se actualiza el sistema operativo. Si la versión más reciente del sistema operativo define exactamente el mismo permiso, el Servicio de administración de paquetes de Android (PMS) otorgará silenciosamente el permiso a la aplicación sin pedirle al usuario que permita los ataques de elevación de privilegios.

Como solo espera recibir mensajes de difusión del sistema y no de otros componentes, este componente debe ser privado (inaccesible para otros componentes).

Las cookies son un mecanismo exclusivo de HTTP según RFC 2109. No se debe pretender que funcionen con protocolos diferentes de HTTP, incluido file://. No está claro cuál debería ser su comportamiento, ni qué reglas se deben aplicar para compartimentar la seguridad. Por ejemplo, ¿los archivos HTML que se descargan en el disco local desde Internet deben compartir las mismas cookies que cualquier código HTML instalado localmente?

No se recomienda a los desarrolladores crear las aplicaciones con API no documentadas u ocultas. No hay garantía de que Google no quite o cambie dichas API en el futuro y, por lo tanto, estas se deben evitar. También se debe evitar el uso de estos métodos o campos porque constituyen un riesgo y podrían dañar la aplicación.

El código intenta usar el objeto Camera una vez que se ha liberado. Todas las referencias adicionales al objeto Camera sin que se vuelva a adquirir el recurso generarán una excepción y pueden provocar que se bloquee la aplicación si no se detecta la excepción.

Ejemplo: el siguiente código utiliza un botón de conmutación para activar o desactivar la vista previa de la cámara. Después de que el usuario pulse el botón una vez, la vista previa de la cámara se detiene y el recurso de cámara se libera. Sin embargo, si este pulsa de nuevo el botón, se llamará a startPreview() en el objeto Camera liberado anteriormente.

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

El código intenta usar el objeto multimedia una vez que se ha liberado. Todas las referencias adicionales al objeto multimedia sin que se vuelva a adquirir el recurso generarán una excepción y pueden provocar que se bloquee la aplicación si no se detecta la excepción.

Ejemplo: el siguiente código usa un botón de pausa para activar o desactivar la reproducción multimedia. Después de que el usuario pulse el botón una vez, la canción o el video actuales se detendrán temporalmente y se liberará el recurso de cámara. Sin embargo, si este pulsa de nuevo el botón, se llamará a start() en el recurso multimedia liberado anteriormente.

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

El código intenta usar el controlador de base de datos SQLite de Android una vez que se ha cerrado. Todas las referencias adicionales al controlador sin que se restablezca la conexión a la base de datos generarán una excepción y pueden provocar que se bloquee la aplicación si no se detecta la excepción.

Ejemplo: el siguiente código puede proceder de un programa que almacena temporalmente valores de usuario en la memoria caché, pero puede llamar a flushUpdates() para confirmar los cambios en el disco. El método cierra correctamente el controlador de base de datos tras escribir las actualizaciones en la base de datos. Sin embargo, cuando se llama de nuevo a flushUpdates(), se hace referencia de nuevo al objeto de base de datos sin reinicializarlo.

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

Los identificadores específicos del hardware y del dispositivo se conservarán incluso tras las operaciones de borrado de datos y restablecimiento de fábrica. No se deberían utilizar estos para generar identificadores exclusivos que permitan autorizar o autenticar usuarios.

Además, la pérdida de identificadores universalmente exclusivos, que se puede asociar a la información personal, constituyen un riesgo para la privacidad y la seguridad del usuario.

Las vulnerabilidades de secuestro al cargar clases de Android se presentan de dos formas:

- Un usuario malintencionado puede cambiar el nombre de los directorios que busca el programa para cargar clases, de modo que la ruta señale a un directorio que controla: este controla de forma explícita las rutas en las que se buscarán las clases.

- Un usuario malintencionado puede cambiar el entorno donde se carga la clase: este controla de forma implícita lo que significa el nombre de la ruta.

En este caso, nos preocupa principalmente el primer caso, la posibilidad de que un usuario malintencionado pueda controlar los directorios donde se buscan las clases para cargar. Las vulnerabilidades de secuestro al cargar clases de Android de este tipo tienen lugar cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.



2. Los datos se utilizan como una cadena, o parte de ella, que representa un directorio de biblioteca donde buscar las clases para cargar.



3. Al ejecutar el código desde la ruta de la biblioteca, la aplicación concede al usuario malintencionado un privilegio o capacidad que, de lo contrario, no tendría.

Ejemplo 1: el siguiente código utiliza la userClassPath modificable por el usuario para determinar el directorio donde buscar las clases para cargar.

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

Este código permite a un usuario malintencionado cargar una biblioteca y posiblemente ejecutar código arbitrario con el privilegio elevado de la aplicación mediante la modificación de userClassPath para que señale a una ruta diferente que controla este. Como el programa no valida el valor leído del entorno, si un usuario malintencionado puede controlar el valor de userClassPath, podría engañar a la aplicación para que señalara un directorio controlado por él y, por lo tanto, cargar las clases que hubiera definido, utilizando los mismos privilegios que la aplicación original.

Ejemplo 2: el siguiente código utiliza la userOutput modificable por el usuario para determinar el directorio donde deberían escribirse los archivos DEX optimizados.

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

Este código permite a un usuario malintencionado especificar el directorio de salida para los archivos DEX optimizados (ODEX). Esto permite a un usuario malintencionado cambiar el valor de userOutput por un directorio que controle, como por ejemplo almacenamiento externo. Una vez logrado esto, basta con reemplazar el archivo ODEX producido con un archivo ODEX malintencionado para ejecutar este con los mismos privilegios que la aplicación original.

Las aplicaciones para Android se pueden configurar para producir archivos binarios de depuración. Estos binarios proporcionan mensajes de depuración detallados y no deben usarse en entornos de producción. El atributo debuggable de la etiqueta <application> define si los binarios compilados deben incluir información de depuración.

El uso de binarios de depuración hace que una aplicación proporcione al usuario tanta información sobre sí misma como sea posible. Los binarios de depuración están diseñados para usarse en un entorno de desarrollo o prueba y pueden suponer un riesgo de seguridad si se implementan en producción. Los atacantes pueden valerse de información adicional que obtengan del resultado de seguimiento para planear ataques contra el marco de trabajo, la base de datos o cualquier otro recurso que la aplicación utilice.

Apache Axis 2 proporciona a los desarrolladores una utilidad para supervisar los mensajes SOAP entrantes y salientes mediante un applet de Java. SOAP Monitor mostrará todos los mensajes SOAP utilizados para invocar un servicio web. Los atacantes pueden emplear la utilidad para espiar el tráfico entre un servicio web y sus clientes.