La ausencia de registros de auditoría limita la capacidad de detectar y responder a incidentes relacionados con la seguridad e impide la investigación forense.

Los valores de configuración que socavan las capacidades de registro incluyen, entre otros:
- deshabilitar deliberadamente el registro de auditoría
- excluir acciones de usuarios, grupos o procesos específicos del registro
- proteger inadecuadamente la integridad del registro
- no habilitar el registro de auditoría opcional
- reducir la frecuencia de muestreo del registro

La configuración de Terraform establece una subred de máquina virtual sin especificar opciones de registro. Estos registros contienen datos valiosos para el monitoreo de la red, análisis forense, análisis de seguridad en tiempo real y optimización de gastos.

La mala gestión de los permisos aumenta el riesgo de acceso no autorizado o modificación de los datos y socava la disponibilidad del servicio.

Una cuenta de servicio es una cuenta especial de Google utilizada por una aplicación o una VM en lugar de una persona, que utiliza permisos confidenciales para ejecutar procesos automatizados o realizar solicitudes de API en nombre de los usuarios finales. Debe administrarse, controlarse y auditarse cuidadosamente para que se pueda confiar en él. Asignar un rol de cuenta de servicio a un usuario de IAM, que normalmente representa a una persona, debilita el control de seguridad.

Si no se bloquea el tráfico de red no deseado, se amplía la superficie de ataque de un servicio en la nube. Los servicios abiertos a la interacción con el público están sujetos a análisis y sondeos casi continuos por parte de entidades malintencionadas.

Las claves de cifrado administradas por el cliente (CMEK) no están habilitadas para los datos en reposo.

Por defecto, Google Cloud usa claves de cifrado de datos (DEK) generadas aleatoriamente para cifrar los datos en reposo. La función CMEK permite a las organizaciones utilizar claves criptográficas de su elección para cifrar las DEK. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

Como tal, la CMEK suele ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves
- Módulo de seguridad de hardware resistente a manipulaciones

Las claves de cifrado administradas por el cliente (CMEK) no están habilitadas para los datos en reposo.

Por defecto, Google Cloud usa claves de cifrado de datos (DEK) generadas aleatoriamente para cifrar los datos en reposo. La función CMEK permite a las organizaciones utilizar claves criptográficas de su elección para cifrar las DEK. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

Como tal, la CMEK suele ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves
- Módulo de seguridad de hardware resistente a manipulaciones

Un mapa de URL es un conjunto de reglas para enrutar las solicitudes HTTP(S) entrantes a servicios de back-end específicos. Por defecto, un mapa de URL acepta conexiones no cifradas y no seguras. Esto expone los datos a accesos no autorizados, posibles robos y manipulaciones.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que define un mapa de URL que permite a los clientes usar HTTP para la comunicación configurando https_redirect en false.

resource "google_compute_url_map" "urlmap" {
...
  default_url_redirect {
...
    https_redirect = false
...
  }
...
}

DNSSEC evita la falsificación de DNS al proporcionar la capacidad de usar firmas digitales para la validación de respuestas de DNS. Sin embargo, cualquier algoritmo de firma DNSSEC que use SHA-1 es susceptible de un riesgo de ataque cada vez mayor. SHA-1 ya no se considera un algoritmo hash seguro cuando se usa con firmas digitales.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que habilita DNSSEC con el algoritmo de firma inseguro rsasha1.

resource "google_dns_managed_zone" "zone-demo" {
...
  dnssec_config {
    default_key_specs {
      algorithm = "rsasha1"
      ...
    }
  }
...
}

GKE admite dos modos de red de clúster: basado en rutas y nativo de VPC. Los clústeres nativos de VPC usan rangos de direcciones IP de alias para enrutar el tráfico de un pod en un nodo a otro pod. Esto permite políticas precisas basadas en IP y reglas de firewall para pods. Por el contrario, un nodo completo es el nivel de control de granularidad más fino en clústeres basados en rutas.

Ejemplo 1: El siguiente ejemplo de configuración de Terraform no habilita un clúster nativo de VPC configurando networking_mode en ROUTES.

resource "google_container_cluster" "cluster_demo" {
...
  networking_mode = "ROUTES"
..
}

X-XSS-Protection es un encabezado HTTP que Microsoft ha incluido, y que han adoptado otros exploradores. De este modo se pretendía evitar que los ataques Cross-Site Scripting tuvieran éxito, pero, de forma involuntaria, expuso una vulnerabilidad que hacía que sitios web seguros dejaran de serlo[1]. Por este motivo, no se debe usar en versiones anteriores de Internet Explorer y se debe deshabilitar configurando el encabezado como 0.

Ejemplo 1: Esta opción configura el software intermedio Helmet de forma incorrecta en una aplicación Express para habilitar el ajuste en todas las versiones de Internet Explorer:

var express = require('express');
var app = express();
var helmet = require('helmet');

...
app.use(helmet.xssFilter({ setOnOldIE: true}));
...

El ataque de reconocimiento MIME es la práctica de inspeccionar el contenido de una secuencia de bytes con el fin de deducir el formato de archivo de los datos que contiene.

Si el ataque de reconocimiento MIME no se deshabilita de forma explícita, los atacantes pueden manipular algunos exploradores para que interpreten los datos de una manera no deseada y se permitan así ataques Cross-Site Scripting. Para cada página que contenga contenido controlable por el usuario, debe utilizar el encabezado HTTP X-Content-Type-Options: nosniff.

Ejemplo 1: El siguiente código configura una aplicación protegida con Spring Security para deshabilitar la protección contra reconocimiento MIME:

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-type-options disabled="true"/>
        </headers>
	</http>

Los errores de optimización del compilador se producen cuando:

1. Los datos secretos se almacenan en la memoria.

2. Los datos secretos se limpian de la memoria sobrescribiendo su contenido.



3. El código de origen se compila mediante un compilador de optimización, que identifica y elimina la función que sobrescribe el contenido como un almacén no alcanzado porque la memoria no se utiliza posteriormente.
Ejemplo 1: El siguiente código lee una contraseña del usuario, utiliza esta para conectarse a un gran sistema (mainframe) back-end y, a continuación, intenta limpiar la contraseña de la memoria mediante memset().

  void GetData(char *MFAddr) {
  char pwd[64];
  if (GetPasswordFromUser(pwd, sizeof(pwd))) {
   if (ConnectToMainframe(MFAddr, pwd)) {
		 // Interaction with mainframe
	 }
  }
  memset(pwd, 0, sizeof(pwd));
}

El código del ejemplo se comporta correctamente si se ejecuta de forma literal, pero si este se compila mediante un compilador de optimización como, por ejemplo, Microsoft Visual C++(R) .NET o GCC 3.x, se eliminará la llamada a memset() como almacén no alcanzado porque no se ha utilizado el búfer pwd una vez sobrescrito su valor [2]. Como el búfer pwd contiene un valor confidencial, es posible que la aplicación sea vulnerable a un ataque si se dejan datos en la memoria. Si los usuarios malintencionados pueden acceder a la región correcta de la memoria, es posible que usen la contraseña recuperada para obtener acceso al sistema.

Es práctica habitual sobrescribir datos confidenciales manipulados en la memoria como, por ejemplo, contraseñas o claves criptográficas, para impedir que los usuarios malintencionados averigüen secretos del sistema. Sin embargo, con la introducción de los compiladores de optimización, los programas no siempre se comportan como podría sugerir solo su código fuente. En el ejemplo, el compilador interpreta la llamada a memset() como código no alcanzado porque la memoria en la que se está escribiendo no se utiliza posteriormente, a pesar del hecho de que hay claramente una motivación de seguridad para que se realice la operación. El problema aquí es que muchos compiladores y, de hecho, muchos lenguajes de programación, no tienen en cuenta esta u otras inquietudes acerca de la seguridad en su esfuerzo por mejorar la eficacia.

Por lo general, los usuarios malintencionados explotan este tipo de vulnerabilidad mediante un mecanismo de volcado del núcleo o de tiempo de ejecución para acceder a la memoria utilizada por una aplicación específica y recuperar la información secreta. Una vez que el usuario malintencionado tiene acceso a la información secreta, es relativamente sencillo explotar aún más el sistema y poner en peligro posiblemente otros recursos con los que interactúa la aplicación.

Si la comprobación de un límite de matriz implica computar un puntero no válido y luego determinar que el puntero está fuera de los límites, algunos compiladores optimizarán la salida, suponiendo que el programador nunca haya creado de forma intencionada un puntero no válido.

Ejemplo 1:

  char *buf;
  int len;
  ...
  len = 1<<30;

  if (buf+len < buf)  //wrap check
    [handle overflow]

La operación buf + len es mayor que 2^32, de modo que el valor resultante es menor que buf. Como el desbordamiento aritmético en un puntero no es un comportamiento definido, algunos compiladores asumirán buf + len >= buf y optimizarán la comprobación de encapsulación. El resultado de esta optimización es que el código que sigue a este bloque podría ser vulnerable al buffer overflow.

La aplicación de Django expone la vista de serve de la aplicación static files que no está diseñada para implementarse en un entorno de producción. Según la documentación de Django:

"Las herramientas static files están diseñadas en su mayoría para ayudar a obtener archivos estáticos correctamente implementados en la producción. En general, esto significa un servidor de archivo estático, dedicado e independiente que significa mucha sobrecarga al implementarlo de forma local. Por lo tanto, la aplicación de archivos estáticos se envía con una vista auxiliar rápida y modificada que puede utilizar para facilitar archivos de forma local en el desarrollo.

Esta vista funcionará únicamente si DEBUG está definido como True.

Eso se debe a que esta vista es sumamente ineficiente y probablemente insegura. Esto solo está destinado al desarrollo local y nunca se debe utilizar el producción".

Los recursos de aplicaciones que contienen información confidencial o que proporcionan funcionalidad con privilegios generalmente tienen mayor riesgo de vulnerabilidad. Durante la fase de reconocimiento, un usuario malintencionado intentará descubrir esos archivos y directorios. El uso de esquemas de nombres predecibles para esos recursos facilita que el usuario malintencionado los localice. Todos los recursos de aplicaciones que tratan funciones confidenciales como autenticación, tareas administrativas o administración de información privada se deben proteger lo suficiente contra la detección.

Ejemplo 1: En el siguiente ejemplo, la aplicación admin se implementa en una dirección URL predecible:

from django.conf.urls import patterns
from django.contrib import admin

admin.autodiscover()

urlpatterns = patterns('',
    ...
    url(r'^admin/', include(admin.site.urls)),
    ...

Los recursos responsables de almacenar datos se deben separar de aquellos que implementan funcionalidad de las aplicaciones. Los programadores deben tener precaución al crear recursos temporales o de respaldo.

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>