Acegi Security permite reemplazar temporalmente el objeto Authentication en SecurityContext durante la fase de devolución de llamada del objeto seguro. Esta situación solo ocurre si el objeto Authentication original fue procesado correctamente por AuthenticationManager y AccessDecisionManager. RunAsManager crea este objeto Authentication.
Normalmente, los desarrolladores utilizan RunAsManager para configurar uno o más roles adicionales para un usuario autenticado durante la invocación de un método. Esta opción es útil en el caso de un archivo Bean seguro que necesita acceder a una aplicación remota. Dado que la aplicación remota puede exigir diferentes credenciales, esta posibilidad permite traducir entre los roles de llamada y los que necesita la aplicación remota para que el acceso remoto pueda tener éxito. El nuevo objeto Authentication (llamado RunAsUserToken) simplemente se aceptará como un objeto de autenticación válido sin ninguna comprobación adicional de autenticación o autorización.
Agregar nuevos roles o privilegios al nuevo objeto Authentication tiene el potencial de elevar temporalmente los privilegios del usuario, lo que le permite realizar una acción no autorizada.
La siguiente configuración muestra el uso de RunAsManager para agregar el rol "UBER_BOSS" a un usuario que tiene el rol "ROLE_PEON", de forma que se elevan temporalmente los privilegios de este usuario a administrador, lo que permite a todos los peones obtener datos del PrivateCatalog.

<bean id="bankManagerSecurity" class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor">
...
 <property name="objectDefinitionSource">
   <value>
     com.example.service.PrivateCatalog.getData=ROLE_PEON,RUN_AS_UBER_BOSS
...
   </value>
 </property>
</bean>

Si bien es una buena idea definir permisos de lectura y escritura separados para los proveedores de contenido, definir solo el writePermission podría ser engañoso. Debido a la naturaleza de SQL, generar consultas verdaderas de solo escritura es generalmente imposible: incluso cuando el usuario no tiene acceso directo a los datos, un atacante puede reconstruir los datos almacenados manipulando la cláusula where.

Ejemplo: A continuación aparece un ejemplo de un proveedor de contenido declarado solo con el writePermission.

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

El destinatario registrado sin el permiso del emisor recibirá mensajes de cualquier emisor. Si estos mensajes contienen datos maliciosos o proceden de emisores malintencionados, se podría poner en peligro la aplicación.

Ejemplo 1: el siguiente código registra un destinatario sin especificar el permiso del mismo.

...
context.registerReceiver(broadcastReceiver, intentFilter);
...

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.