Un Intent interno utiliza una acción personalizada definida por un componente interno. Los intents implícitos pueden facilitar la llamada de intenciones desde cualquier componente externo determinado sin conocimiento del componente específico. La combinación de ambos permite que una aplicación acceda a intenciones especificadas para un uso interno específico desde fuera del contexto de la aplicación deseada.

La capacidad de procesar un Intent desde una aplicación externa puede permitir una amplia variedad de explotaciones de intermediario que varían en gravedad. desde fuga de información y denegación de servicio hasta ejecución remota de código, dependiendo de la capacidad de acción interna especificada por el Intent.

Ejemplo 1: El siguiente código utiliza un Intent interno implícito.

...
val imp_internal_intent_action = Intent("INTERNAL_ACTION_HERE")
startActivity(imp_internal_intent_action)
...

Los intents de Android se utilizan para vincular aplicaciones y componentes de aplicaciones proporcionando instrucciones sobre las acciones que realiza un componente determinado. Los intents pendientes se crean para entregar el Intent más adelante. Los intents implícitos facilitan la llamada de intents desde cualquier componente externo determinado, utilizando un nombre general y un filtro para determinar la ejecución.

Cuando se crea un Intent implícito como PendingIntent, esto podría permitir que el Intent se envíe a un componente no deseado que se ejecuta fuera del contexto temporal previsto, dejando al sistema vulnerable para explotar vectores como la denegación de servicio, la fuga de información privada y del sistema y la escalada de privilegios.

Ejemplo 1: El código siguiente utiliza un PendingIntent implícito.

...
val imp_intent = Intent()
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable_impintintent = PendingIntent.getService(
    this,
    0,
    imp_intent,
    flag_mut
)
...

Permitir la modificación del Intent subyacente de un PendingIntent después de su creación puede dejar un sistema abierto a ataques. Esto depende principalmente de la capacidad general del Intent subyacente. En la mayoría de los casos, se recomienda evitar posibles problemas configurando la marca PendingIntent en FLAG_IMMUTABLE.

Ejemplo 1: El siguiente incluye un PendingIntent creado con un valor de marca de FLAG_MUTABLE.

...
val intent_flag_mut = Intent(Intent.ACTION_GTALK_SERVICE_DISCONNECTED, Uri.EMPTY, this, DownloadService::class.java)
val flag_mut = PendingIntent.FLAG_MUTABLE

val pi_flagmutable = PendingIntent.getService(
    this,
    0,
    intent_flag_mut,
    flag_mut
)
...

Se produce un problema manipulación de intento de redireccionamiento cuando se cumplen las condiciones siguientes:
1. Un componente exportado acepta un Intent arbitrario anidado en el paquete de extras de un Intent proporcionado externamente.

2. El componente exportado utiliza el Intent arbitrario para iniciar un componente llamando a startActivity, startService o sendBroadcast.

Un atacante posiblemente pueda obtener una capacidad que de otro modo no estaría permitida cuando existen estas condiciones.
Ejemplo 1: El siguiente código acepta un Intent anidado de una fuente externa y usa ese Intent para iniciar una actividad.

...
Intent nextIntent = (Intent) getIntent().getParcelableExtra("next-intent");
startActivity(nextIntent);
...

El estándar J2EE requiere que las aplicaciones usen las utilidades de administración de recursos del contenedor para obtener conexiones a los recursos.

Por ejemplo, una aplicación J2EE debe obtener una conexión de base de datos, como se indica a continuación:

ctx = new InitialContext();
datasource = (DataSource)ctx.lookup(DB_DATASRC_REF);
conn = datasource.getConnection();

y debe evitar obtener una conexión de la siguiente forma:

conn = DriverManager.getConnection(CONNECT_STRING);

Todos los contenedores de aplicaciones web principales ofrecen administración de conexiones de base de datos agrupadas en conjuntos como parte de su estructura de administración de recursos. La duplicación de esta funcionalidad en una aplicación es difícil y susceptible a errores, que es parte del motivo por el que está prohibida en virtud de la norma de J2EE.

Cuanto más tiempo permanezca una sesión abierta, más oportunidades tendrá un atacante para poner en peligros las cuentas de los usuarios. Durante el tiempo que una sesión permanece activa, un usuario malintencionado puede ser capaz de forzar el robo de la contraseña de un usuario, descifrar la clave de cifrado inalámbrico de un usuario o dirigir una sesión desde un explorador abierto. Los tiempos de expiración de sesión largos pueden, además, impedir que se libere memoria y que se produzca al final una denegación de servicio si se crea un número de sesiones suficientemente largo.

Ejemplo 1: el código del siguiente ejemplo establece un valor negativo para el intervalo inactivo máximo producido en una sesión que permanece activa indefinidamente.

...
HttpSession sesssion = request.getSession(true);
sesssion.setMaxInactiveInterval(-1);
...

Nunca es recomendable que una aplicación web intente cerrar el contenedor de aplicaciones. Una llamada a un método de finalización es probablemente parte de un código de depuración sobrante o un código importado de una aplicación que no es de J2EE.

Un procedimiento habitual de desarrollo consiste en añadir un código de "puerta trasera" diseñado específicamente para fines de depuración o pruebas que no se vaya a enviar o implementar con la aplicación. Cuando este tipo de código de depuración se deja accidentalmente en la aplicación, este se abre en modos de interacción no previstos. Estos puntos de entrada de "puerta trasera" conllevan riesgos de seguridad porque no se tienen en cuenta durante las fases de diseño y pruebas, y no se incluyen en las condiciones de funcionamiento previstas de la aplicación.

El ejemplo más habitual de código de depuración que se ha dejado olvidado es un método main() que aparece en una aplicación web. Aunque se trata de una práctica aceptable durante el desarrollo de productos, las clases que forman parte de una aplicación J2EE de producción no deben definir uno main().

Una aplicación J2EE puede utilizar varios JVM a fin de mejorar la confiabilidad y el rendimiento de la aplicación. A fin de hacer que varios JVM aparezcan como una única aplicación para el usuario final, el contenedor J2EE puede replicar un objeto HttpSession entre varios JVM. De este modo, si un JVM deja de estar disponible otro puede intervenir y ocupar su lugar sin deteriorar el flujo de la aplicación.

Para que la replicación de sesión funcione, los valores que almacena a aplicación como atributos en la sesión deben implementar la interfaz Serializable.

Ejemplo 1: la clase siguiente se agrega a la sesión, pero como no es serializable, la sesión ya no puede replicarse.

public class DataGlob {
   String globName;
   String globValue;

   public void addToSession(HttpSession session) {
     session.setAttribute("glob", this);
   }
}

El estándar J2EE permite el uso de sockets solo para la comunicación con sistemas existentes cuando no hay ningún protocolo de nivel superior disponible. Para que pueda crear su propio protocolo de comunicación, debe hacer frente a complejos problemas de seguridad, entre los que se incluyen:

- Señalización en banda frente a fuera de banda

- Compatibilidad entre versiones del protocolo

- Seguridad de canal

- Administración de errores

- Restricciones de red (firewalls)

- Administración de sesiones

Sin un análisis importante por parte de un experto en seguridad, lo más probable es que un protocolo de comunicación personalizado presente problemas de seguridad.

Muchos de los mismos problemas se aplican a la implementación personalizada de un protocolo estándar. Aunque, por lo general, hay más recursos disponibles que solucionan los problemas de seguridad relacionados con la implementación de un protocolo estándar, estos recursos también están disponibles para los usuarios malintencionados.

La administración de subprocesos en una aplicación web está prohibida por el estándar J2EE en algunas circunstancias y siempre es susceptible a errores. La administración de subprocesos es una tarea complicada y es muy probable que esta interfiera de forma impredecible en el comportamiento del contenedor de aplicaciones. Incluso aunque no interfiera en el contenedor, la administración de subprocesos suele provocar errores difíciles de detectar y diagnosticar, como interbloqueos, condiciones de carrera y otros errores de sincronización.

La mayoría de las aplicaciones web utilizan un identificador de sesión para identificar de forma exclusiva a los usuarios, que normalmente se almacena en una cookie y se transmite de forma transparente entre el servidor y el explorador web.


Las aplicaciones que no almacenan identificadores de sesión en cookies a veces los transmiten como un parámetro de solicitud HTTP o como parte de la dirección URL. La aceptación de identificadores de sesión especificados en las direcciones URL facilita que los atacantes realicen ataques de fijación de sesión.

La colocación de identificadores de sesión en las direcciones URL también puede aumentar las posibilidades de que se produzcan ataques de suplantación de sesión con éxito contra la aplicación. La suplantación de sesión ocurre cuando un atacante toma el control de la sesión activa o del identificador de sesión de una víctima. Es una práctica común que los servidores web, los servidores de aplicaciones y los servidores proxy web almacenen las direcciones URL solicitadas. Si se incluyen identificadores de sesión en las direcciones URL, también se registran. Aumentar el número de lugares en los que se ven y almacenan los identificadores de sesión aumenta las posibilidades de que un atacante los ponga en peligro.

Si está utilizando Tomcat para llevar a cabo una autenticación, el archivo del descriptor de implementación de Tomcat especifica un "Realm" (Dominio) utilizado para la autenticación. Tiene un formato similar al siguiente:

Ejemplo 1:

  <Realm className="org.apache.catalina.realm.JAASRealm"
         appName="SRN"
         userClassNames="com.srn.security.UserPrincipal"
         roleClassNames="com.srn.security.RolePrincipal"/>

Esta etiqueta Realm toma un atributo opcional que se llama debug, el cual indica el nivel de registro. Cuanto mayor sea el número, más detallados serán los mensajes de registro. Si el nivel de depuración está configurado demasiado alto, Tomcat escribirá todos los nombres de usuario y las contraseñas en texto sin formato en el archivo de registro. El límite de depuración de mensajes relacionados con JAASRealm de Tomcat es de 3 (3 o más está mal, 2 o menos está bien), pero este límite puede variar para el resto de dominios que proporciona Tomcat.

El acceso directo a Java Server Pages (JSP) en aplicaciones creadas con marcos web, como Struts o Spring, que utilizan acciones o servlets para delegar solicitudes en JSP, puede generar excepciones no controladas y fugas de información del sistema. Los servidores de aplicaciones mal configurados o implementados han sido convencidos para filtrar los detalles del código fuente mediante solicitudes especialmente diseñadas, como http://host/page.jsp%00 o http://host/page.js%2570. Peor aún, si una aplicación permite a los usuarios cargar archivos arbitrarios, los atacantes pueden usar este mecanismo para cargar código malintencionado en forma de una JSP y solicitar que la página cargada haga que este código se ejecute en el servidor.

Ejemplo 1: En el siguiente ejemplo se muestra una restricción de seguridad mal construida que permite explícitamente el acceso directo a las JSP con un '*' en el nombre del rol, lo que indica que todos los usuarios pueden acceder a los recursos web correspondientes.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>JSP Access for Everyone!</web-resource-name>
        <description>Allow any user/role access to JSP</description>
        <url-pattern>*.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>*</role-name>
    </auth-constraint>
</security-constraint>

Los roles de seguridad duplicados no sirven para nada, ya que solo se aplicará la última definición de un rol de seguridad determinado.
Ejemplo 1: La entrada de un archivo web.xml define dos roles admin.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>AdminPage</web-resource-name>
        <description>Admin only pages</description>
        <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>
</security-constraint>
...
<security-role>
    <description>Administrator</description>
    <role-name>admin</role-name>
</security-role>

<security-role>
    <description>Non-Administrator</description>
    <role-name>admin</role-name>
</security-role>

Las asignaciones de servlets duplicadas no sirven para nada, ya que solo se aplicará la última entrada cuando se utilice el mismo patrón de dirección URL en varias asignaciones de servlet.

Ejemplo 1: En el siguiente ejemplo, el patrón de dirección URL /servletA/* se utiliza en dos asignaciones de servlets diferentes.

<servlet-mapping>
    <servlet-name>ServletA</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>ServletB</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>

La asignación de varios patrones de dirección URL a un solo servlet podrían ser una señal de que el servlet realiza demasiadas funciones.

Ejemplo 1: En el siguiente ejemplo se asignan cinco patrones de dirección URL a un solo servlet.

<servlet>
    <servlet-class>com.class.MyServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/myservlet</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/helloworld*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/servlet*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/mservlet*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>

Cuanto más tiempo permanece abierta una sesión, mayor es la ventana de oportunidad que tiene un atacante para comprometer las cuentas de usuario. Mientras una sesión permanece activa, un atacante puede forzar la contraseña de un usuario, descifrar su clave de cifrado inalámbrica o controlar una sesión desde un explorador abierto. Los tiempos de espera de sesión más prolongados también pueden evitar que se libere la memoria y acabar en una denegación de servicio si se crea una cantidad suficientemente grande de sesiones.

Ejemplo 1: Si el tiempo de espera de la sesión es cero o menor que cero, la sesión nunca caduca. El siguiente ejemplo muestra un tiempo de espera de sesión establecido en -1, lo que hará que la sesión permanezca activa indefinidamente.

<session-config>
    <session-timeout>-1</session-timeout>
</session-config>

La etiqueta <session-timeout> define el intervalo de tiempo de espera de sesión predeterminado para todas las sesiones de la aplicación web. Si falta la etiqueta <session-timeout>, queda en manos del contenedor establecer el tiempo de espera predeterminado.

Cuando un atacante explora un sitio web en busca de vulnerabilidades, la cantidad de información que el sitio proporciona es fundamental para el éxito o fracaso final de cualquier intento de ataque. Si la aplicación muestra al atacante un seguimiento de pila, la aplicación cede información que facilita significativamente el trabajo del atacante. Por ejemplo, un seguimiento de pila podría mostrar al atacante una cadena de consulta SQL mal formada, el tipo de base de datos que se está utilizando y la versión del contenedor de la aplicación. Esta información permite al atacante apuntar a vulnerabilidades conocidas de estos componentes.

La configuración de la aplicación debe especificar una página de error predeterminada para garantizar que la aplicación nunca filtre mensajes de error a un atacante. La gestión de códigos de error HTTP estándar es útil y fácil de usar, además de ser una buena práctica de seguridad, y una buena configuración también definirá un controlador de error de último recurso que detecta cualquier excepción que la aplicación pueda lanzar.

Si una aplicación utiliza SSL para garantizar la comunicación confidencial con los navegadores del cliente, la configuración de la aplicación debería hacer imposible ver cualquier página de acceso controlado sin SSL.

Hay tres formas habituales de eludir SSL:

- Un usuario ingresa manualmente la URL y escribe "HTTP" en lugar de "HTTPS".

- Los atacantes envían intencionalmente a un usuario a una URL insegura.

- Un programador crea erróneamente un enlace relativo a una página en la aplicación, sin poder cambiar de HTTP a HTTPS. (Esto es particularmente fácil de hacer cuando el vínculo se mueve entre áreas públicas y seguras en un sitio web).