NOR_DESARROLLO_SEGURO v01r00

Ámbito de aplicación de la norma

Esta norma es de aplicación tanto para nuevos desarrollos como mantenimientos de productos software que se realicen sobre cualquier lenguaje y cualquier tecnología.

Las directrices que contiene la norma son independientes de la pila tecnológica utilizada para el desarrollo de la solución software.

Al implementar cualquier desarrollo software deben tenerse en cuenta:

• Las directrices y estándares referidos en esta norma.
• Otras normas específicas a la arquitectura o arquitecturas que apliquen a los componentes software del sistema.
• Otras normas específicas referente al lenguaje de programación que se utilice durante el desarrollo

Puedes conocer en esta sección  cómo se marca la obligatoriedad de cumplimiento de las directrices que componen la norma.

Autenticación  (ASVS V2)

DIR_01 Cifrado de las credenciales

OBLIGATORIO Es imprescindible proteger las credenciales de los usuarios mediante el almacenamiento seguro de contraseñas. Esto implica utilizar algoritmos de hashing robustos y únicos para cada usuario, como SHA-256 o bcrypt. Los algoritmos recomendados son:

• SHA-2 Secure Hash Algorithm 2: SHA-2 es una familia de funciones diseñadas por la Agencia de Seguridad Nacional (NSA) de los Estados Unidos de América y publicada por el Instituto Nacional de Estándares y Tecnología (NIST). Incluye varios algoritmos: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 y SHA-512/256. Cada variante difiere en la longitud del valor hash generado y en el tamaño de los bloques de datos que procesan.
• SHA-3: Secure Hash Algorithm 3: SHA-3 es la última incorporación a la familia de funciones hash SHA y fue estandarizada en 2015. SHA-3 se basa en un diseño completamente diferente llamado Keccak, que utiliza una construcción esponja en lugar de la estructura Merkle-Damgård utilizada por SHA-2.

DIR_02 Salting de las credenciales

RECOMENDADO Se recomienda, para mejorar el almacenamiento seguro de contraseñas, además del cifrado aplicar la técnica del salting. La aplicación del salting permite que contraseñas iguales tengan un hash diferente lo que lo que dificulta aún más los intentos de intrusión mediante fuerza bruta o diccionario.

DIR_03 Políticas de contraseña fuerte

OBLIGATORIO Las aplicaciones deben implementar políticas de contraseñas que promuevan la creación de contraseñas fuertes y la actualización periódica de las mismas.

DIR_04 Limitación de los inicios de sesión fallidos

OBLIGATORIO Deben limitarse por un periodo de tiempo específico el número de intentos de inicio de sesión fallidos para evitar los ataques de fuerza bruta o los intentos de denegación de servicio (DoS).

Cuando el sistema detecte que el número de intentos de inicio de sesión en un periodo de tiempo haya superado el recomendado deben realizarse bloqueos temporales o permanentes al usuario. La duración del bloqueo dependerá de la criticidad de la aplicación para la que se detecte el ataque.

DIR_05 Técnicas de reconocimiento de comportamiento

RECOMENDADO Se recomienda, especialmente en las aplicaciones de criticidad elevada, la implementación de técnicas que permitan el reconocimiento de comportamientos para identificar actividad sospechosas.

Por ejemplo: Pueden implementarse mecanismos que detecten intentos de inicio de sesión en horas sospechosas o desde ubicaciones que no sean habituales para el contexto de la aplicación. También puede analizarse las IPs que envían las peticiones y detectar si una IP intenta acceder a múltiples usuarios en un corto periodo de tiempo.

DIR_06 Autenticación multifactor

RECOMENDADO Se recomienda la implementación de mecanismos de Autenticación Multifactor (MFA). Este mecanismo de autenticación requiere que el usuario además de introducir sus credenciales deba insertar un código enviado a su correo electrónico, móvil o proporcionado por alguna aplicación de autenticación como Microsoft Authenticator.

También se considera como un mecanismo de autenticación multifactor la bio autenticación mediante reconocimiento facial o huella dactilar.

Gestión de sesiones

DIR_07 Gestión de sesiones a nivel de tecnología

OBLIGATORIO Deben utilizarse todas las herramientas que un framework o tecnología tengan publicadas para garantizar la seguridad en la gestión de sesiones. El uso de estos mecanismos proporciona las siguientes ventajas:

• Integración directa con la tecnología utilizada, simplificando la implementación y la catidad de código manual generado.
• Control completo sobre la gestión de sesiones y su configuración.

Entre los mecanismos habituales que las tecnologías actuales ofrecen a los desarrolladores para la gestión de las sesiones están:

• Duración de las sesiones: Configurar la duración de las sesiones utilizando las propiedades publicadas por la tecnología.
• Seguridad en las sesiones: Implementar políticas de seguridad como la invalidación de sesiones al cerrar sesión, la protección contra ataques de fijación de sesiones y la utilización de token anti-CSRF para proteger formularios o peticiones.
• Almacenamiento de sesiones: Utilizar tecnologías de almacenamiento como Redis para almacenar sesiones de forma distribuida.
• Persistencia de sesiones: Configurar la persistencia de sesiones para que sean restauradas en caso de reinicios del servidor, asegurando la continuidad de la sesión del usuario.
• Control de Sesiones Concurrentes: Limitar el número de sesiones concurrentes permitidas por usuario para prevenir abusos y mejorar la seguridad. Esto puede incluir configuraciones para bloquear nuevas sesiones si se alcanza un límite o para finalizar sesiones antiguas.

DIR_08 Gestión de sesiones basadas en Tokens 

OBLIGATORIO La aplicaciones basadas en las arquitecturas de referencia publicadas en el portal de desarrollo deben gestionar la autenticación utilizando el protocolo OAuth2 y un Token JWT. Los token son emitidos por un servidor y enviados al cliente después de un proceso de autenticación exitoso. Este token debe incluirse en todas las solicitudes que accedan a información sensible o a recursos protegidos.

Aquellos sistemas que requieran autenticación deben estar preparados para gestionar el ciclo de vida de un token:

• Autenticación del Usuario: El cliente envía las credenciales de autenticación al servidor.
• Generación del Token: Si las credenciales son válidas, el servidor genera un token (JWT u opaco) y lo envía al cliente.
• Almacenamiento del Token: El cliente almacena el token (por ejemplo, en el almacenamiento local o en una cookie segura).
• Uso del Token: En cada solicitud posterior, el cliente incluye el token en los encabezados de autorización (Authorization: Bearer <token>).
• Validación del Token: El servidor valida el token para asegurar que es legítimo y no ha expirado antes de permitir el acceso al recurso solicitado.
• Renovación/Revocación del Token: Los tokens tienen un tiempo de vida limitado. El servidor puede permitir la renovación de tokens o revocarlos en caso de detectar actividades sospechosas.        
   

DIR_09 Gestión de sesiones en aplicaciones Legacy

OBLIGATORIO Las aplicaciones Legacy que no puedan implementar una gestión de sesiones basada en OAuth2 como se indica en la directriz DIR_08 deberán implementar alguno de estos mecanismos para gestionar el acceso y las sesiones:

• Gestión de sesiones basada en Cookies: La gestión de sesiones basada en cookies implica almacenar un identificador de sesión en una cookie en el navegador del usuario. Este identificador se utiliza para mantener la sesión activa entre el cliente y el servidor. El servidor guarda la información de la sesión, mientras que el cliente envía el identificador de sesión con cada solicitud.
• Gestión de sesiones basada en autenticación básica: El cliente envía el nombre de usuario y la contraseña codificados en Base64 en cada solicitud HTTP, en el encabezado Authorization.

Para el caso de la gestión de sesiones basada en cookies el sistema debe estar preparado para gestionar el ciclo de vida de una Cookie:

• Inicio de sesión del Usuario: El cliente envía las credenciales de autenticación al servidor.
• Creación de la sesión: Si las credenciales son válidas, el servidor crea una sesión y genera un identificador de sesión único.
• Envío del ID de sesión: El servidor envía el identificador de sesión al cliente en una cookie.
• Almacenamiento de la cookie: El navegador del cliente almacena la cookie de sesión.
• Uso del ID de sesión: En cada solicitud posterior, el navegador incluye automáticamente la cookie de sesión.
• Validación de la sesión: El servidor valida el identificador de sesión recibido en la cookie para identificar al usuario y gestionar la sesión.
• Expiración de la sesión: El revoca la cookie una vez expirada la sesión

DIR_10 Duración de las sesiones

OBLIGATORIO Las aplicaciones tiene que definir un tiempo de duración de las sesiones que minimicen la ventana de oportunidad que los atacantes tienen disponible para hacerse de forma fraudulenta con los datos de la sesión y utilizarla para acceder al sistema. Para ello las aplicaciones tienen que implementar los siguientes mecanismos:

• Definir un tiempo máximo de sesión acorde al contexto de la aplicación y a la información a la que tiene acceso.
• Verificar que tras un tiempo de inactividad configurable, la aplicación ejecutará un cierre de sesión controlado.

DIR_11 Duración del token de autenticación

OBLIGATORIO Las aplicaciones tiene que definir un tiempo de duración de los token de autenticación que minimicen el riesgo de suplantación en la aplicación por parte de un usuario malintencionado.

• La duración del access-token tiene que ser acorde al contexto de la aplicación y a la información a la que tiene acceso.
• La duración del refresh-token tiene que ser acorde al contexto de la aplicación y a la información a la que tiene acceso.

DIR_12 Cierre de sesión manual

OBLIGATORIO Las aplicaciones deben implementar como parte de su funcionalidad un mecanismo de cierre de sesión manual accesible y fácil de usar para el usuario. El mecanismo de cierre de sesión debe garantizar que al ejecutarse se borran todos los datos de la sesión de un usuario para evitar, de esta forma, el robo de identidades.

DIR_13 Ataques por fijación de sesión

OBLIGATORIO Deben implementarse los mecanismos necesarios para impedir que se produzcan ataques por fijación de sesión.

Un ataque por fijación de sesión (Session Fixation) ocurre cuando un atacante fuerza a un usuario a usar un ID de sesión previamente conocido o controlado por el atacante. Si el usuario inicia sesión con ese ID, el atacante puede secuestrar la sesión.

El mecanismo más fácil para obtener el ID de sesión es que dicho identificador habitualmente se envíe como parámetro en la URL: https://miapp.com/login?sessionid=ABC123 y la aplicación no haya establecido mecanismos que garanticen que la sesión sea de un solo uso.

Para evitar este tipo de ataques se recomiendan implementar las siguientes medidas:

• Regenerar el ID de sesión después de un inicio de sesión exitoso.
• No aceptar IDs de sesión desde la URL (solo desde cookies seguras o un Token JWT).
• Configurar cookies con atributos HttpOnly, Secure, SameSite.
• Establecer tiempos de expiración y validación de IP o User-Agent.

DIR_14 Generación de los identificadores de sesión

OBLIGATORIO Los identificadores de sesión deben generarse utilizando algoritmo que no sean predecibles. Si un atacante puede predecir el identificador de sesión podrá adivinar el ID de sesión de otro usuario o realizar ataques de fuerza bruta para encontrar sesiones activas y de esta forma comprometer la confidencialidad y autenticidad de la sesión.

Debe evitarse que el identificador de sesión se genere utilizando mecanismos como:

• Un contador incremental (sessionID = 1001, 1002, 1003...)
• Marcas de tiempo (sessionID = timestamp + userID)
• Funciones de hash débiles o sin sal (como MD5(userID))

Para la generación de identificadores que no sean predecibles se recomienda:

• Utilizar las librerías que los diferentes lenguajes de programación y frameworks tienen para este tipo de cuestiones: SecureRandom en Java, secrets.token_urlsafe() en Python o crypto.randomBytes() en Node.js
• Establecer una longitud de al menos 128 bits para los identificadores de sesión
• Utilizar UUIDv4 y ULID para la generación de identificadores de sesión aleatorios   
   

DIR_15 Gestión del cierre de sesión al cambiar contraseña

OBLIGATORIO Deben implementarse los mecanismos necesarios para garantizar que al cambiar la contraseña se cierre la sesión abierta del usuario en todos los dispositivos desde donde se haya tenido acceso a la aplicación obligando al usuario a autenticarse nuevamente con la nueva contraseña.

DIR_16 Gestión del tiempo de expiración para las transacciones

OBLIGATORIO Deben implementarse los mecanismos necesarios para controlar el tiempo de expiración asociado a las transacciones.

El tiempo de expiración de transacciones es el límite de tiempo que una transacción tiene para completarse. Si el usuario no finaliza la operación dentro de ese tiempo, la transacción se invalida automáticamente. Debe ponerse especial atención en la correcta gestión del tiempo de expiración en transacciones críticas como pagos, transferencias, cambios de configuración o sesiones de usuario.

Los riesgos a los que se expone un sistema si no gestiona correctamente el tiempo de expiración de las transacciones son:

• Permitir la reutilización de transacciones antiguas (Replay Attacs)
• Mantener sesiones abiertas indefinidamente, permitiendo a un atacante completar una transacción iniciada por otro usuario.
• Incurrir en inconsistencias en el estado del sistema si se procesan transacciones fuera de contexto.
• Provocar problemas de concurrencia o doble ejecución de operaciones.

Control de accesos

DIR_17 Principio de mínimo privilegio

OBLIGATORIO Debe implementarse un sistema de gestión de roles y permisos que garantice el principio de mínimo privilegio. 

El principio de mínimo privilegio establece que los usuarios deben tener los permisos mínimos necesarios para realizar sus tareas. Esto limita el impacto de una cuenta comprometida y reduce las posibilidades de abuso de privilegios.

DIR_18 Segregación de tareas

OBLIGATORIO Debe implementarse un sistema de gestión de roles y permisos que garantice la segregación de tareas

La segregación de tareas implica dividir responsabilidades de manera que ninguna persona tenga control total sobre todas las fases de una operación crítica. Esto previene fraudes y errores no intencionados, asegurando que múltiples personas o sistemas supervisen actividades críticas.

DIR_19 Deshabilitar la exploración de directorios

OBLIGATORIO Se debe garantizar que la exploración de directorios internos de la aplicación no es accesible para un usuario externo. Se deberá diseñar el sistema que garantice que la exploración de directorios no está accesible atendiendo a la tecnología que implemente el sistema de información. Por ejemplo: 

• En aplicaciones implementadas con Node.js puede utilizarse un servidor Express.js para manejar las solicitudes HTTP y personalizar el comportamiento del servidor.
• En aplicaciones Java que usan Spring puede utilizarse el módulo Spring Security para restringir el acceso a los directorios y las rutas publicadas por el servidor.

DIR_20 Mecanismos anti-CSRF

OBLIGATORIO En aquellas aplicaciones donde se utilicen Cookies para gestionar la autenticación y las sesiones deben implementarse mecanismos para prevenir ataques de falsificación de solicitudes entre sitios (CSRF). El uso de un token anti-csrf en formularios y solicitudes ayuda a verificar la legitimidad de las solicitudes, mitigando así el riesgo de manipulación maliciosa de datos por parte de terceros no autorizados. 

La falsificación de petición en sitios cruzados (CSRF) es una vulnerabilidad de seguridad web que permite a un atacante inducir a los usuarios a realizar acciones sin su conocimiento, aprovechando que tienen una sesión abierta en un sitio web. Permite a un atacante eludir parcialmente la política del mismo origen aprovechando el comportamiento legítimo del navegador bajo esa política (como el envío automático de cookies), diseñada para evitar que diferentes sitios web interfieran entre sí. 

Esta técnica radica en el hecho de que un atacante podría hacer llegar una URL con una petición de cambio de estado (es decir, que realice alguna operación sobre los datos almacenados) a la víctima contando con que esta tenga una sesión abierta. Si la aplicación web no valida si esa petición ha llegado desde un enlace o redirección que provenga de la propia aplicación web (mismo origen) y no directamente accediendo a la URL que provoca esa petición, la operación se llevará a cabo sin conocimiento ni intención del usuario.

Para prevenir los ataques CSRF, a la hora de recibir peticiones, el servidor debe generar un token único anti-csrf. Estos tokens serán enviados a al cliente, quien tendrá que devolverlos al servidor para asegurar que es el quien ha realizado la petición y no un actor malicioso que quiera hacerse pasar por el usuario. Por tanto, para protegerse de este tipo de ataque se deben seguir estos pasos:

• Generación de Tokens Anti-CSRF:
  • El servidor genera un token único y lo asocia con la sesión del usuario. La generación de este token puede simplificarse con la ayuda de framework como Spring Security.
  • Este token se envía al cliente y debe ser incluido en cada petición que pueda cambiar el estado en el servidor.
• Validación de Tokens Anti-CSRF:
  • Cuando el servidor recibe una petición que puede cambiar el estado, verifica que el token enviado coincide con el token asociado a la sesión del usuario.
  • Si el token no coincide, la petición se rechaza.

No es necesario utilizar token anti-csrf si el token JWT se manda en la cabecera de autenticación de la petición HTTP siempre que el JWT no se almacene en cookies, sino en almacenamiento local o se maneje manualmente por el cliente, ya que los ataques CSRF dependen de que el navegador envíe automáticamente credenciales en segundo plano utilizando las Cookies de la aplicación para ello.

DIR_21 Gestión del cambio de contraseña

OBLIGATORIO Para evitar el robo de credenciales la funcionalidad de cambio de contraseña debe verificar la identidad del usuario antes de ejecutarse. Entre los mecanismos de verificación de usuarios se encuentran: el uso de certificados digitales, solicitar la contraseña actual, el envío de mensajes al correo electrónico o teléfono móvil que la aplicación ya tiene registrado para ese usuario o la bio autenticación.

DIR_22 Cuentas y usuarios predeterminados

OBLIGATORIO Debe evitarse el uso de cuentas y usuarios predeterminados. Uno de los ataques básicos que puede hacerse sobre una aplicación es probar credenciales como:  admin/admin admin/1234, [nif usuario]/[nif usuario]. La existencia de este tipo de cuentas brindan acceso inmediato al sistema a cualquier atacante que las descubra.

Además, deberá evitarse que los usuarios utilicen como contraseña información personal y ya proporcionada al sistema. Por ejemplo: el nif, la fecha de nacimiento o el número de teléfono.

DIR_23 Registro de los accesos al sistema

OBLIGATORIO La aplicación debe implementar mecanismos que registren el acceso de todos los usuarios. Deberá registrarse como mínimo la siguiente información:

• Usuario
• Fecha y hora del inicio de sesión
• Fecha y hora del fin de sesión

Además se podrá ampliar  este registro con cualquier otra información relevante, como un registro de la url a las que accede y las operaciones que se realizan. El nivel de información almacenada por cada acceso dependerá de la criticidad de la aplicación y de los datos a los que el usuario está teniendo acceso.

DIR_24 Control de usuario no automático

RECOMENDADO Se recomienda implementar mecanismos que permitan establecer controles de seguridad y evaluar si el usuario es humano o es un proceso automático. Entre los métodos disponibles se encuentran: captcha, reCAPTCHA v3, verificación biométrica o validación por SMS o correo electrónico.   
 

Validación y control de entrada y salida

DIR_25 Definición de reglas de validación

OBLIGATORIO Antes de procesarse cualquier entrada de usuario, deben definirse las reglas de validación que deben cumplir los datos de entrada. Estas reglas de validación deben definirse usando expresiones regulares y deben contemplar el formato esperado para el dato y los caracteres permitidos. 

DIR_26 Implementar mecanismos de validación en el Frontend

RECOMENDADO Se recomienda implementar mecanismos de validación en el Frontend para evitar, en la medida de lo posible, el envío de información que no pueda ser procesada por el Backend.

DIR_27 Implementar mecanismos de validación en el Backend

OBLIGATORIO Deben implementarse mecanismos de validación en el Backend que impidan el acceso a información no autorizada o el envío de información corrupta que pueda almacenarse en el sistema. La validación en el servidor es definitiva y previa al acceso de datos, siendo esta validación la última capa de la interfaz de entrada. Se recomienda realizar validaciones de los parámetros de entrada en el servidor, preferiblemente en una capa intermedia entre la interfaz de usuario y la lógica de negocio, para verificar que los datos ingresados cumplan con las reglas establecidas antes de ser procesado.

DIR_28 Informar al usuario sobre errores de validación

OBLIGATORIO Debe informarse al usuario de una forma clara, precisa y que no revele información sensible sobre los errores de validación detectados en los datos de entrada de una petición. 

DIR_29 Establecer límites de longitud

RECOMENDADO Se recomienda definir límites de longitud máxima para los datos de entrada de texto libre. Esta medida ayuda a prevenir ataques de desbordamiento de buffer y asegura que los datos no sean excesivamente largos, lo que podría impactar en la base de datos y afectar negativamente al rendimiento de la aplicación.

DIR_30 Utilizar tipos de datos adecuados

RECOMENDADO Se recomienda utilizar tipos de datos fuertemente tipados en la aplicación para garantizar que los datos se manejen de forma segura, consistente y acorde a su naturaleza.

DIR_31 Validar tipos de datos

OBLIGATORIO Debe validarse antes del procesamiento el tipo de datos de todos los parámetros de entrada para verificar que son del tipo y formato esperado. 

DIR_32 Manejar errores de conversión de datos

OBLIGATORIO Debe informarse al usuario de una forma clara, precisa y que no revele información sensible sobre los errores que puedan producirse en la conversión de datos de un tipo a otro.

DIR_33 Cifrado de datos sensibles

OBLIGATORIO Toda la información sensible debe enviarse y almacenarse en sistemas cifrados. Por sistema cifrado podemos referirnos a:   
 

• Cifrado en tránsito:
  • Hacer uso de protocolos como TLS para proteger los datos transmitidos por redes. Por ejemplo: HTTPS.
  • Cifrado de correos electrónicos mediante S/MIME o PGP.
• Cifrado en reposo:
  • Bases de datos cifradas. Por ejemplo: Usando TDE de Oracle o el cifrado nativo de MongoDB.
  • Archivos o discos duros cifrados. Por ejemplo: BitLocker o LUKS.
• Gestión segura de claves:
  • Mediante HSMs (Hardware Security Modules) o servicios como Vault para almacenar claves criptográficas.
• Autenticación y almacenamiento seguro de credenciales:
  • Mecanismos de Hashing con algoritmos como bycrypt, scrypt o Argon2.
  • Usando tokenJWT con firma y cifrado.

DIR_34 Descifrado de datos sensibles

RECOMENDADO Se recomienda no someter a la información cifrada a un proceso de descifrado para consultar el dato original.

Cuando sea necesario verificar que la información introducida por un usuario concuerda con la información que se ha almacenado cifrada (por ejemplo, la validación de una contraseña en el momento de la autenticación) se recomienda generar el hash de la contraseña introducida y compararla con el hash que ya está almacenado en un sistema cifrado.

DIR_35 Gestión de los parámetros de una petición

RECOMENDADO Los parámetros de una petición que se envían directamente en la URL (utilizando la operación GET) pueden dar información al usuario que la intercepte y la sepa interpretar.

Para minimizar este riesgo de exposición se recomienda evitar el envío de parámetros dentro de una petición, especialmente si la información que se envía puede ser interpretada para conocer características internas del sistema que no deban ser del dominio público.

DIR_36 Gestión de información sensible en los parámetros de una petición

OBLIGATORIO Toda información sensible que se envía en una petición no puede ser accesible de forma directa a través de la URL. Si una petición manda información sensible, dicha información debe enviarse manteniendo las siguientes características:

• Se recomienda, siempre que sea posible, mandar la información sensible en el body de la petición. Para ello no podrá utilizarse la operación GET de HTPP. Se recomienda utilizar POST, PUT u otra operación equivalente que permita el envío del body en la petición.
• Si por el contexto de la aplicación es necesario enviar la petición utilizado la operación GET y por lo tanto será accesible desde la URL, toda la información sensible deberá estar cifrada y enviarse siempre bajo un protocolo de comunicación seguro como HTTPS. 

DIR_37 Gestión de campos duplicados en las peticiones

OBLIGATORIO Deben implementarse los mecanismos necesarios para verificar que una petición no incluye contenidos duplicados. Para ello debe validarse que si un cliente envía una solicitud con parámetros, encabezados o elementos repetidos, el sistema lo detecta y es capaz de gestionarlo correctamente evitando que la aplicación sea vulnerable a ataques ataques de inyección de código, manipulación de lógica o bypass de validaciones.

DIR_38 Gestión de elementos omitidos

OBLIGATORIO Deben implementarse los mecanismos necesarios para verificar que si una petición HTTP no incluye uno o más campos esperados (por ejemplo, parámetros, cabeceras o propiedades JSON), el sistema es capaz de gestionarlo correctamente. 

Si el campo que se omite es obligatorio la aplicación debe informar al usuario generando el correspondiente mensaje de error, si el campo omitido no es obligatorio debe validarse que la aplicación continúa su ejecución sin errores y sin generar un comportamiento inesperado.

DIR_39 Gestión de sobrecarga de las peticiones

OBLIGATORIO Deben implementarse los mecanismos necesarios para verificar que si se sobrecarga una petición HTTP no se produce un comportamiento inesperado en la aplicación.

Por "sobrecargar elementos" nos referimos a enviar una petición HTTP que incluya campos con alguna de las siguientes características:

• Cadenas de texto extremadamente largas.
• Listas con miles de elementos.
• Archivos muy grandes.
• Campos repetidos en exceso.

Este tipo de peticiones se envían en ataques de denegación de servicio (DoS) que pueden llevar al agotamiento de los recursos del sistema.   
 

DIR_40 Sanitización de datos

OBLIGATORIO Debe eliminarse de un dato de entrada cualquier carácter potencialmente peligroso y especialmente código como scripts o etiquetas HTML para evitar que el dato introducido pueda ser utilizado en ataques de inyección de código, como SQL Inyection o Cross-Site Scripting (XSS). 

Se recomienda utilizar librerías especializadas y adaptadas a la tecnología sobre la que se esté implementando la solución para realizar la sanitización de datos. En tecnología Java puede usarse, por ejemplo, la librería ESAPI (Enterprise Security API).

DIR_41 Consultas parametrizadas

OBLIGATORIO En lugar de concatenar directamente valores de entrada en una SQL, las consultas parametrizadas deben utilizar marcadores de posición que luego serán reemplazados por los valores proporcionados por el usuario. Esta técnica evita que los datos de entrada modifiquen la estructura de la consulta y la interpreten como código SQL malicioso. 

Muchos lenguajes de programación y framework como Spring Boot JPA en Java, implementan ya librerías y mecanismos para garantizar que todas las consultas se envíen parametrizadas.

DIR_42 Mapeadores Objeto-Relacional (ORM)

RECOMENDADO Los ORM son herramientas que permiten a los desarrolladores trabajar con objetos en el código fuente de la aplicación en lugar de escribir directamente consultas SQL. Si la tecnología que se está utilizando lo permite, se recomienda utilizar estos objetos que se encargan de traducir las operaciones realizadas sobre estos objetos en consultas SQL seguras que protegen al sistema contra el SQL Inyection. En Java  Hibernate y por extensión JPA proporcionan mapeadores ORM.

DIR_43 Filtrado de URL

OBLIGATORIO Se deben validar y filtrar las URLs ingresadas por los usuarios para asegurarse de que solo puedan acceder a recursos permitidos y seguros. Para implementar esta medida pueden incluirse restricciones sobre los esquemas de URL (permitiendo solo HTTP o HTTPS) y elaborar listas blancas de dominios permitidos.

El filtrado de URL permite evitar ataques de falsificación de solicitudes desde sitios remotos donde los atacantes puedan intentar manipular las solicitudes HTTP para acceder a recursos internos del sistema o realizar acciones maliciosas en nombre del usuario. Implementar mecanismos anti-SSRF ayuda a proteger al sistema contra este tipo de amenazas y garantiza su seguridad.

DIR_44 Limitar destinos permitidos

OBLIGATORIO Se deben restringir las solicitudes HTTP solo a los destinos permitidos y necesarios para el funcionamiento de la aplicación. Esta restricción ayuda a prevenir que los atacantes utilicen la aplicación para acceder a recursos no autorizados.

Para implementar esta restricción se deben configurar reglas en el cortafuegos para bloquear o permitir solicitudes HTTP en base a políticas de seguridad predefinidas e implementar listas blancas de direcciones IP o dominios permitidos.

DIR_45 Prevención de inyección XSS

OBLIGATORIO Debe prepararse los sistemas para la posible eventualidad de que un atacante externo haya logrado introducir información maliciosa en la base de datos y esta información navegue a través del sistema de información como respuesta a una petición realizada sobre el recurso que tiene almacenado el código peligroso.

Para implementar esta medida de protección pueden utilizarse frameworks y bibliotecas seguras que incorporen medidas de seguridad contra XSS. Por ejemplo, muchos frameworks modernos de JavaScript incluyen automáticamente medidas de protección XSS como el escapado automático de datos.

DIR_46 Uso de encabezados de seguridad

OBLIGATORIO Se debe configurar en el servidor encabezados de seguridad HTTP adecuados como Content-Security-Policy (CSP) para controlar qué recursos externos pueden ser cargados y ejecutados en el sitio web. CSP permite limitar la ejecución de scripts solo a fuentes de confianza lo que ayuda a prevenir ataques XSS.

DIR_47 Validación y escapados de datos en el servidor

OBLIGATORIO Antes de insertar los datos en la respuesta generadas por el servidor, al igual que se hace con los datos de entrada, deben validarse y sanitizarse esos datos adecuadamente. Esta acción ayuda a prevenir que los datos maliciosos se interpreten como código en el navegador del usuario.

DIR_48 Prevención de inyección en JSON

OBLIGATORIO Deben utilizarse la bibliotecas de serialización disponibles para cada tecnología para evitar insertando código malicioso en un JSON que posteriormente pueda utilizarse en otro proceso volviéndolo vulnerable. Estas bibliotecas especializadas manejan la codificación y el análisis sintáctico del dato reduciendo el riego de inyección de código. 

También se debe evitar concatenar información sin validad ni sanitizar en cadenas JSON.

DIR_49 Validaciones contra inyección LDAP

OBLIGATORIO Deben validarse y sanitizarse las consultas LDAP para evitar ataques de inyección LDAP.

La inyección LDAP surge cuando los datos enviados por el usuario se utilizan de forma insegura en una consulta LDAP realizada por la aplicación. Si un atacante puede inyectar meta caracteres LDAP en la consulta, entonces puede interferir en la lógica de la consulta. Dependiendo de la función para la que se utilice la consulta, el atacante puede ser capaz de recuperar datos sensibles para los que no esté autorizado o subvertir la lógica de la aplicación para realizar alguna acción no permitida.

DIR_50 Validaciones contra inyecciones de comando de sistema operativo

OBLIGATORIO Se debe validar y codificar las entradas de usuario para prevenir ataques de inyección de comandos del sistema operativo.

Este tipo de inyección viene dado cuando una entrada proporcionada por le usuario acaba siendo ejecutada en un comando del sistema operativo, pudiendo desembocar en la toma de control del servidor.

Para evitar este tipo de inyección, es necesario validar y sanitizar toda entrada del usuario, crear una lista blanca de parámetros permitidos y en le mejor de los casos, evitar ejecutar comandos del sistema operativo.

DIR_51 Protección XPath contra ataques XPath e inyección XML

OBLIGATORIO Se debe validar y codificar las consultar XPath y XML para prevenir ataques de inyección XML.

El ataque de inyección XPath ocurre cuando el servidor no valida correctamente la entrada del usuario y ejecuta operaciones XPath con dicha entrada de datos siendo potencialmente maliciosa. Pudiendo desembocar en una filtración de información indeseada del fichero que está siendo consultado.

DIR_52 Gestión de referencias cruzadas entre páginas

OBLIGATORIO Las referencias cruzadas de páginas no deben contener información de direcciones IP físicas. Por referencias cruzadas nos referimos a:

• Una página que enlaza a otra y transmite información en la URL, encabezados HTTP o parámetros.
• El uso de mecanismos como referer headers, redirecciones, o enlaces que incluyen datos técnicos del usuario.

Una gestión inapropiada de las IP físicas durante el ciclo de vida de una petición puede proporcionar a un atacante información valiosa como:

• Revelar la ubicación geográfica del usuario, su proveedor de servicios, o incluso su red interna.
• Si se incluyen en URLs o encabezados, pueden ser registradas en logs, compartidas con terceros, o indexadas por buscadores.
• Un atacante o tercero podría usar la IP para rastrear la actividad del usuario entre páginas o servicios.

DIR_53 Referencias a objetos inseguras

OBLIGATORIO Deben implementarse los mecanismos necesarios para impedir a un atacante acceder a objetos internos como archivos, registros o información privada de los usuarios mediante identificadores insertados como parámetros en una petición. Toda petición debe ir securizada con unas credenciales y validarse dichas credenciales antes de acceder a cualquier información almacenada en la aplicación.

DIR_54 Prevención ante ataques por Transversal Path

OBLIGATORIO Deben implementarse los mecanismos necesarios para impedir  que pueda manipularse la url de una petición para acceder a ubicaciones fuera del directorio permitido, usando secuencias como ../. Entre los mecanismos implementados deberá incluirse:

• Sanitizar y validar las rutas de entrada
• Usar funciones seguras para manejar rutas (como realpath())
• Restringir el acceso a directorios específicos
• Evitar concatenar rutas manualmente
• Configurar el servidor para bloquear accesos fuera del directorio permitido

Ejemplo de url vulnerable a Transversal Path: https://miapp.com/descargar?archivo=../../etc/passwd

DIR_55 Prevención antes ataques de manipulación de proxys o caches

OBLIGATORIO Deben implementarse los mecanismos necesarios para impedir la ejecución de ataques de manipulación de "proxys" o "caches".

El http response splitting es un tipo de ataque que permite un usuario malintencionado inyectar caracteres de control como CR y LF (retorno de carro y salto de línea) en los encabezados HTTP para dividir la respuesta del servidor en dos, permitiéndole:

• Inyectar contenido malicioso en la respuesta.
• Envenenamiento de caché (Cache Poisoning).
• Manipulación de proxies o balanceadores para alterar el comportamiento de otros usuarios (HTTP Request Smuggling).

DIR_56 Gestión de protocolos con niveles de seguridad diferentes

OBLIGATORIO Debe verificarse que toda la comunicación entre el  cliente y el servidor se realice exclusivamente a través de canales seguros como HTTPS y que no es posible manipular el envío de una petición utilizando para ellos protocolos de seguridad diferentes al esperado. Por ejemplo: que una aplicación acepte y procese una petición HTTP cuando solo espera recibir peticiones HTTPS.

DIR_57 Gestión del atributos html en los formularios

OBLIGATORIO Deben implementarse los mecanismos necesarios para garantizar que los atributos definidos en los campos de formularios HTML no supongan un riesgo a la seguridad del sistema ni expongan información sensible.

Para evitar que estos atributos sean explotados, deben validarse las credenciales y los permisos del usuario que envía el formulario y realizar siempre una validación del campo y sus atributos en servidor, incluso si el campo está oculto o no se tiene previsto que el valor de este campo cambie.

A continuación se listan algunos atributos problemáticos sobre los que se debe tener especial cuidado:

• Autocomplete: Este atributos permite al navegador rellenar automáticamente un campo del formulario. Debe asegurarse que este atributo está desactivado en campos que gestionan datos sensibles como contraseñas o tarjetas de crédito
• Value definido con un valor por defecto: Este atributo proporciona un valor por defecto a un campo. Este valor por defecto no debe dar información que un atacante pueda usar para acceder irregularmente al sistema. 
• Name e id predecibles: Los nombres e id predecibles pueden proporcionar indirectamente información sobre el sistema que puede ser explotado manual o automáticamente en un ataque.
• Campos ocultos: Debe ponerse especial atención en los campos de tipo "hidden" ya que no se espera que su valor cambie y pueden manipularse fácilmente. Se recomienda siempre hacer una validación en servidor de todos los campos, incluidos los campos de tipo "hidden" y otros que no se espera que sean cambiados por el usuario.
• Accept en campos de tipo fichero: El atributo "accept" es un atributo de los campos de tipo file que especifica qué tipos de archivos puede seleccionar el usuario al subir un archivo. Este campo, si no se configura correctamente, puede usarse para introducir en el sistema ficheros maliciosos, por lo que se recomienda validar todos los ficheros que se introducen en el sistema y someterlos al análisis de un antivirus. 

DIR_58 Prevención antes ataques por desbordamiento de buffer

OBLIGATORIO Deben implementarse los mecanismos necesarios para impedir los ataques por desbordamiento de buffer.

Un buffer es un espacio de memoria reservado para almacenar datos temporales. El ataque por desbordamiento de buffer (Buffer Overflow) se produce cuando un programa escribe más datos en el espacio de memoria reservado para el buffer del que puede contener, sobrescribiendo otras partes de la memoria. Este tipo de ataques se aprovechan de errores en el manejo de la memoria, especialmente de una mala gestión durante el proceso de escritura.

DIR_59 Escaneo periódico de vulnerabilidades en productos y librerías de terceros

OBLIGATORIO Debe someterse periódicamente a un escaneo tanto a la propia aplicación, las librerías externas que utilice y a todos los componentes que intervienen en el conjunto del sistema. 

DIR_60 Correcta utilización de los métodos HTTP

OBLIGATORIO Deben implementarse los mecanismos necesarios para garantizar que el envío de peticiones HTTP se utilicen los métodos más apropiados para el contexto de la petición. En concreto, para las operaciones más habituales se recomienda utilizar:

• GET - Para operaciones de consulta o lectura
• POST - Para la creación de elementos. Se permite también el uso de POST en consultas donde los parámetros de búsqueda no puedan mandarse  por GET como atributos en la URL por referenciar información sensible o que pueda ser explotada de algún modo.
• PUT - Para la edición de un elemento ya existente
• DELETE - Para eliminar un elemento ya existente.

DIR_61 Prevención ante ataques de inyección HTTP

OBLIGATORIO Deben implementarse los mecanismos necesarios para garantizar que la aplicación no sea vulnerable a ataques de inyección HTTP (HTTP Injection).

La inyección HTTP ocurre cuando un atacante inyecta datos maliciosos en las cabeceras o cuerpos de las solicitudes HTTP, con el objetivo de:

• Manipular la respuesta del servidor.
• Realizar ataques de HTTP Response Splitting.
• Bypassear controles de autenticación o autorización.
• Redirigir a usuarios a sitios maliciosos.
• Inyectar contenido en la respuesta (como scripts maliciosos).

Para evitar este tipo de ataques se recomienda, entre otras acciones, realizar una correcta sanitización de los valores de entrada de las peticiones, aprovechar las características de seguridad que implementan frameworks modernos como Spring Boot y revisar y validar las cabeceras de los mensajes, en especial las cabeceras personalizadas.

DIR_62 Gestión de la información almacenada en caché

OBLIGATORIO Deben implementarse los mecanismos necesarios para gestionar adecuadamente la información almacenada en caché. Una gestión inapropiada de la caché podría:

• Exponer información sensible del usuario.
• Permitir el reintento de sesiones si se han cacheado token de sesión o cookies.
• Inyección de contenido a través de la manipulación de la caché.

Criptografía

DIR_63 Algoritmos seguros para el cifrado en reposo

RECOMENDADO Se recomienda utilizar los siguientes algoritmos para el cifrado en reposo:

• AES (Advanced Encryption Standard): AES es un estándar de cifrado asimétrico que utiliza una clave compartida para cifrar y descifrar datos. Es uno de los algoritmos más usados y seguros en la actualidad. AEs ofrece una alta seguridad y eficiencia en el cifrado de grandes volúmenes de datos y se utiliza en una variedad de aplicaciones, desde la protección de datos en redes informáticas hasta el cifrado de archivos y comunicaciones en sistemas de seguridad.
• RSA (Rivest Shanir Adleman): RSA es un algoritmo de cifrado asimétrico que utiliza un par de claves pública y privada para cifrar y descifrar datos. Es ampliamente utilizado en la protección de comunicación segura a través de Internet, como el cifrado de correos electrónicos y la autenticación de usuarios en protocolos como TLS 1.2 o superior. Para garantizar la seguridad es crucial utilizar versiones actualizadas de estos protocolos y evitar versiones anteriores que puedan ser inseguras. RSA es especialmente adecuado para aplicaciones donde se necesita una fuerte autenticación y firma digital, además del cifrado de datos. Aunque RSA es mas lento que AES para cifrar grandes volúmenes de datos sigue siendo una opción sólida para aplicaciones que requieren seguridad asimétrica.

DIR_64 Algoritmos de cifrado para la seguridad en comunicaciones TLS 1.2 y 1.3

RECOMENDADO Se recomienda para el cifrado de las comunicaciones los siguientes algoritmos:

• Para TLS 1.2: 
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 
  • TLS_ECDHE_ECDSA_WITH_AES_256_CCM 
  • TLS_ECDHE_ECDSA_WITH_AES_128_CCM 
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• Para TLS 1.3: TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_CCM_SHA256
  • TLS_AES_128_CCM_8_SHA256        
     

En todo caso se prohíbe la utilización de algoritmos que no empleen mecanismos criptográficos para elementos fundamentales como el acuerdo de clave, autenticación, cifrado, integridad y autenticidad en el origen. Los algoritmos como TLS_RSA_WITH_NULL_SHA o TLS_DH_anon_WITH_AES_128_CBC_SHA no están permitidos.

Además se desaconsejan los algoritnos que utilicen claves compartidas (PKS) para la autenticación, ya que se considera más seguro el uso de certificados X.509v3 para la autenticación. Los algoritmos TLS_*_PSK_WITH_* o TLS_PSK_WITH_* entran en esta categoría y deben evitarse. Esto se debe a que las claves compartidas pueden ser vulnerables a ataques de diccionario y pueden comprometer la seguridad de la conexión.

DIR_65 Uso de funciones o generadores de semilla seguros

RECOMENDADO Se recomienda usar funciones criptográficamente seguras o generadores de números aleatorios certificados para garantizar la aleatoriedad y la entropía de los valores generados en aplicaciones que requiere de seguridad criptográfica. Estas funciones están diseñadas específicamente para resistir ataques predictivos y garantizar la imprevisibilidad de los valores generados, lo que fortalece la seguridad de las claves criptográficas y la integridad de los datos almacenados. 

En concreto se recomienda usar SHA-256 y SHA-512 ya que estas funciones general un hash de valor único a partir de una entrada. La longitud del hadh que generan estas funciones se considera lo suficientemente largo como para evitar que dos datos diferentes generen el mismo hash y de esta forma ofrecer una resistencia considerable ante ataques de fuerza bruta.

Manejo de registro de errores

DIR_66 Control de errores y excepciones

OBLIGATORIO Se deben registrar y manejar los errores de forma segura, evitando la exposición de detalles técnicos que puedan ser aprovechados por posibles atacantes para comprometer la seguridad de la aplicación.  

Archivos y recursos

DIR_67 Carga de archivos

OBLIGATORIO Se deben implementar medidas para proteger la aplicación contra ataques de carga de archivos maliciosos, como la ejecución de código arbitrario o la revelación de información sensible. Para ello se seben implementar medidas de seguridad que incluyan la validación y filtrado riguroso de los archivos cargados. Esto implica verificar el tipo de archivo, el tamaño, la extensión y cualquier otra característica relevante para asegurar que solo se permitan archivos seguros y legítimos en el sistema.

Al validar y filtrar adecuadamente los archivos cargados, se reduce significativamente el riesgo de explotación de vulnerabilidades y se garantiza la integridad y seguridad de la aplicación en su conjunto. Es crucial establecer políticas y controles claros para la carga de archivos y educar a los usuarios sobre las mejores prácticas para garantizar un ambiente seguro y confiable.

DIR_68 Gestión del acceso a ficheros de configuración

OBLIGATORIO Deben implementarse los mecanismos necesarios para impedir el acceso no autorizado a ficheros de configuración de una aplicación.

Los ficheros de configuración y en especial los "secretos" exponen información crítica de un sistema como: las credenciales de acceso a las bases de datos, claves de api, variables de entorno y detalles de configuración que podrían poner en peligro el sistema completo.

DIR_69 Gestión de archivos obsoletos

OBLIGATORIO Debe hacerse una revisión periódica de los ficheros y librerías almacenados en los directorios de la aplicación para eliminar aquellos que se hayan quedado obsoletos o ya no se utilicen.

Técnicas como el Software BOM pueden ayudar a tener un catálogo actualizado de las dependencias externas de una aplicación para identificar fácilmente aquellas que deben ser purgadas.

DIR_70 Gestión de los metadatos de documentos

OBLIGATORIO Deben implementarse los mecanismos necesarios para garantizar que los ficheros publicados en una aplicación no contengan metadatos que puedan contener información sensible o confidencial.

Se recomienda, antes de su publicación, escanear todos los ficheros con herramientas especializadas para garantizar que no se publiquen metadatos relevantes.

DIR_71 Renombrado de archivos

OBLIGATORIO Deben implementarse los mecanismos necesarios para evitar el renombrado de archivos por parte de los usuarios. El renombrado de archivos podría permitir a un atacante:

• Manipular datos sensibles, configuraciones o recursos. 
• Evitar los controles de acceso y las validaciones por tipo de archivo.
• Confundir o suplantar ficheros legítimos.
• Ejecutar código malicioso en el sistema.