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.

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>

La ausencia de una asignación de servlets válida impide todo acceso al servlet sin asignar.

Ejemplo 1: La siguiente entrada de web.xml define ExampleServlet pero no puede definir una asignación de servlets correspondiente.

<web-app
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">

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

</web-app>

Los beans de entidad que exponen una interfaz remota se convierten en parte de la superficie de ataque de una aplicación. Por motivos de rendimiento, una aplicación rara vez debería utilizar beans de entidad remota, por lo que es muy probable que la declaración de un bean de entidad remota sea un error.

Ejemplo 1: La siguiente declaración de bean de entidad incluye una interfaz remota:

<ejb-jar>
<enterprise-beans>
<entity>
<ejb-name>EmployeeRecord</ejb-name>
<home>com.wombat.empl.EmployeeRecordHome</home>
<remote>com.wombat.empl.EmployeeRecord</remote>
...
</entity>
...
</enterprise-beans>
</ejb-jar>

Si el descriptor de implementación de EJB contiene uno o más permisos de método que otorgan acceso al rol ANYONE, esto indica que el control de acceso para la aplicación no se ha pensado totalmente o que la aplicación está estructurada de manera que las restricciones razonables de control de acceso son imposibles.

Ejemplo 1: El siguiente descriptor de implementación otorga permiso ANYONE para invocar el método Employee de EJB denominado getSalary().

<ejb-jar>
	...
	<assembly-descriptor>
		<method-permission>
			<role-name>ANYONE</role-name>
			<method>
				<ejb-name>Employee</ejb-name>
				<method-name>getSalary</method-name>
		</method-permission>
	</assembly-descriptor>
	...
</ejb-jar>

Los servidores API de Kubernetes aceptan solicitudes anónimas de forma predeterminada si otros métodos de autenticación configurados no rechazan las solicitudes. Debido a que un servidor API es la entidad de administración central de un clúster, los atacantes pueden usar solicitudes anónimas para obtener acceso a las API de servicios sensibles a la seguridad y con protección insuficiente.

Ejemplo 1: La siguiente configuración inicia un servidor API de Kubernetes y permite solicitudes anónimas configurando la marca --anonymous-auth=true.

...
spec:
  containers:
    - command:
      - kube-apiserver
...
      - --anonymous-auth=true
...

Un servidor API de Kubernetes escribe eventos de auditoría en la salida estándar de forma predeterminada. Los eventos de auditoría deben registrarse en un almacenamiento persistente. Los eventos de auditoría contienen datos valiosos que se utilizan para identificar incidentes de seguridad, supervisar infracciones de directivas y ayudar con los controles de no repudio.

Ejemplo 1: La siguiente configuración inicia un servidor API de Kubernetes sin la marca --audit-log-path.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --authorization-mode=RBAC
  image: example.domain/kube-apiserver-amd64:v1.6.0
...

Un servidor API de Kubernetes, la entidad de administración central de un clúster, acepta la autenticación HTTP básica para autenticar a los usuarios. La autenticación HTTP básica está en desuso y es susceptible a ataques por fuerza bruta y filtra las credenciales de usuario a los atacantes en un entorno mal configurado.

Ejemplo 1: La siguiente configuración inicia un servidor API de Kubernetes y establece la marca --basic-auth-file=<filename>> para utilizar la autenticación HTTP básica.

...
kind: Pod
...
spec:
  containers:
    - command:
      - kube-apiserver
      - --basic-auth-file=<filename>
    image: example.domain/kube-apiserver-amd64:v1.6.0
    livenessProbe:
...

Las configuraciones de acceso dinámico pueden exponer los sistemas y amplían la superficie de ataque de una organización. Los servicios abiertos a la interacción con el público suelen estar sujetos a análisis y sondeos casi continuos por parte de entidades malintencionadas.

Esto es especialmente problemático cuando se descubre y publica una vulnerabilidad de día cero para un servicio expuesto, como Heartbleed. Los atacantes pueden perseguir y buscar activamente sistemas expuestos y sin revisión que puedan aprovechar.

El acceso no controlado a recursos críticos o confidenciales puede afectar significativamente a una organización de varias maneras, incluida la divulgación o manipulación de datos críticos.

El acceso no controlado a recursos críticos o confidenciales puede afectar significativamente a una organización de varias maneras, incluida la divulgación o manipulación de datos críticos.

El acceso no controlado a recursos críticos o confidenciales puede afectar significativamente a una organización de varias maneras, incluida la divulgación o manipulación de datos críticos.