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).

El descriptor de implementación de WebLogic debe especificar una longitud de identificador de sesión de al menos 24 bytes. Un identificador de sesión más corto deja la aplicación abierta a ataques por fuerza bruta para adivinar la sesión. Si un atacante puede adivinar el identificador de sesión de un usuario autenticado, puede controlar la sesión del usuario. El resto de esta explicación detallará una justificación aproximada para un identificador de sesión de 24 bytes.

El identificador de sesión está compuesto por una selección pseudoaleatoria de los 62 caracteres alfanuméricos, lo que significa que si la cadena estuviese compuesta de forma realmente aleatoria, cada byte podría producir un máximo de 6 bits de entropía.

El número esperado de segundos necesarios para adivinar un identificador de sesión válido viene dado por la ecuación:

(2^B+1) / (2*A*S)

Donde:

- B es el número de bits de entropía en el identificador de sesión.

- A es el número de intentos que un atacante puede realizar cada segundo.

- S es el número de identificadores de sesión válidos que son válidos y están disponibles para averiguarse en un momento dado.

El número de bits de entropía en el identificador de sesión es siempre menor que el número total de bits en el identificador de sesión. Por ejemplo, si los identificadores de sesión se proporcionaran en orden ascendente, habría cerca de cero bits de entropía en el identificador de sesión cualquiera que sea la longitud del identificador. Suponiendo que los identificadores de sesión se generan utilizando una buena fuente de números aleatorios, estimaremos que el número de bits de entropía en un identificador de sesión es la mitad del número total de bits del identificador de sesión. Para longitudes de identificador realistas esto es posible, aunque quizás optimista.

Si los atacantes utilizan una botnet con cientos o miles de drones, es razonable suponer que podrían intentar decenas de miles de averiguaciones por segundo. Si el sitio web en cuestión es grande y popular, es posible que una gran cantidad de intentos de adivinar pasen desapercibidos durante algún tiempo.

Un límite inferior en el número de identificadores de sesión válidos que están disponibles para adivinar es el número de usuarios que están activos en un sitio en un momento dado. Sin embargo, cualquier usuario que abandone sus sesiones sin cerrar la sesión aumentará este número. (Esta es una de las muchas buenas razones para tener un tiempo de espera de sesión inactivo breve).

Con un identificador de sesión de 64 bits, suponga 32 bits de entropía. Para un sitio web grande, suponga que el atacante puede intentar adivinar 1 000 veces por segundo y que hay 10 000 identificadores de sesión válidos en un momento dado. Dadas estas suposiciones, el tiempo esperado para que un atacante condiga adivinar un identificador de sesión válido es menos de 4 minutos.

Ahora suponga un identificador de sesión de 128 bits que proporciona 64 bits de entropía. En el caso de un sitio web muy grande, un atacante podría intentar adivinar 10 000 veces por segundo con 100 000 identificadores de sesión válidos disponibles para adivinar. Dadas estas suposiciones, el tiempo esperado para que un atacante consiga adivinar un identificador de sesión válido es superior a 292 años.

Trabajando de manera inversa, de bits a bytes, ahora, el identificador de sesión debe ser 128/6, lo que produce aproximadamente 21 bytes. Además, las pruebas empíricas han demostrado que los primeros tres bytes del identificador de sesión no parecen generarse aleatoriamente, lo que significa que para lograr los 64 bits de entropía deseados debemos configurar WebLogic para usar un identificador de sesión de 24 bytes de longitud.

La ausencia de un nombre de servlet o que esté duplicado en web.xml es un error. Cada servlet debe tener un nombre único (servlet-name) y una asignación correspondiente (servlet-mapping).

Ejemplo 1: La siguiente entrada de web.xml muestra varias definiciones de servlet erróneas.

<!-- No <servlet-name> specified: -->
    <servlet>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Empty <servlet-name> node: -->
    <servlet>
        <servlet-name/>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Duplicate <servlet-name> nodes: -->
    <servlet>
        <servlet-name>MyServlet</servlet-name>
        <servlet-name>Servlet</servlet-name>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

Estos errores pueden provocar una denegación involuntaria de acceso al servlet.

El elemento <login-config> se utiliza para configurar cómo los usuarios se autentican en una aplicación. La ausencia de un método de autenticación significa que la aplicación no sabe cómo aplicar restricciones de autorización ya que nadie puede iniciar sesión. El método de autenticación se especifica mediante la etiqueta <auth-method>, que es un elemento secundario de <login-config>.

Hay cuatro métodos de autenticación: BASIC, FORM, DIGEST, y CLIENT_CERT.

BASIC indica autenticación HTTP básica.
FORM indica autenticación basada en formularios.
DIGEST es como la autenticación BASIC; sin embargo, en DIGEST la contraseña está cifrada.
CLIENT_CERT requiere que los clientes tengan certificados de clave pública y utilicen SSL/TLS.

Ejemplo 1: La siguiente configuración no especifica una configuración de inicio de sesión.

<web-app>

    <!-- servlet declarations -->
    <servlet>...</servlet>

    <!-- servlet mappings-->
    <servlet-mapping>...</servlet-mapping>

    <!-- security-constraints-->
    <security-constraint>...</security-constraint>

    <!-- login-config goes here -->

    <!-- security-roles -->
    <security-role>...</security-role>

</web-app>

Las restricciones de seguridad de web.xml se utilizan normalmente para el control de acceso basado en roles, pero el elemento user-data-constraint opcional especifica una garantía de transporte que evita que el contenido se transmita de forma poco segura.

Dentro de la etiqueta <user-data-constraint>, la etiqueta <transport-guarantee> define cómo se debe controlar la comunicación. Hay tres niveles de garantía de transporte:

1) NONE significa que la aplicación no requiere ninguna garantía de transporte.
2) INTEGRAL significa que la aplicación requiere que los datos enviados entre el cliente y el servidor se envíen de tal manera que no se puedan cambiar en tránsito.
3) CONFIDENTIAL significa que la aplicación requiere que los datos se transmitan de una manera que impida que otras entidades observen el contenido de la transmisión.



En la mayoría de circunstancias, el uso de INTEGRAL o CONFIDENTIAL significa que se requiere SSL/TLS. Si se omiten las etiquetas <user-data-constraint> y<transport-guarantee>, la garantía de transporte predeterminada es NONE.

Ejemplo 1: La siguiente restricción de seguridad no especifica una garantía de transporte.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Storefront</web-resource-name>
        <description>Allow Customers and Employees access to online store front</description>
        <url-pattern>/store/shop/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Anyone</description>
        <role-name>anyone</role-name>
    </auth-constraint>
</security-constraint>

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.

Cada asignación de filtros debe corresponder a una definición de filtro válida para que se aplique.

Ejemplo 1: En el siguiente ejemplo se muestra una asignación de filtros que hace referencia al filtro inexistente AuthenticationFilter. Como falta la definición, el filtro AuthenticationFilter no se aplicará al patrón de dirección URL designado /secure/* y puede causar una excepción en tiempo de ejecución.

<filter>
    <description>Compresses images to 64x64</description>
    <filter-name>ImageFilter</filter-name>
    <filter-class>com.ImageFilter</filter-class>
</filter>

<!-- AuthenticationFilter is not defined -->
<filter-mapping>
    <filter-name>AuthenticationFilter</filter-name>
    <url-pattern>/secure/*</url-pattern>
</filter-mapping>

<filter-mapping>
    <filter-name>ImageFilter</filter-name>
    <servlet-name>ImageServlet</servlet-name>
</filter-mapping>

La falta de un elemento security-role para un elemento role-name definido en un elemento auth-constraint podría indicar una configuración desactualizada.

Ejemplo 1: En el siguiente ejemplo se especifica un elemento role-name, pero no se define en un elemento security-role.

<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>

    <user-data-constraint>
        <transport-guarantee>INTEGRAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>