Desarrollo seguro: Protección de datos

 La seguridad de los datos debe estar amparada bajo los siguientes preceptos:

• Autenticación. Se verifica la identidad del usuario para poder acceder al dato.
• Autorización. El usuario solo puede realizar las operaciones que le permite los privilegios otorgados a sus roles sobre los datos a los que tiene permiso.
• Confidencialidad. Cuando los datos se almacenan o están en tránsito deben estar protegidos contra la observación o divulgación no autorizada.
• Integridad. Los datos deben estar protegidos contra manipulaciones por parte de posibles atacantes.
• Disponibilidad. Los datos siempre han de estar disponibles para los usuarios autorizados. Esto incluye también las políticas de copias de respaldo.

Posibles riesgos

A continuación se describen algunos de los posibles riesgos relativos a la protección de datos:

• Incumplimiento de normas y leyes relativas al tratamiento de datos personales, lo que supone sanciones legales.
• Pérdida de información sensible.
• Pérdida de información sensible de terceros. Esto puede originar acciones legales y sanciones.
• Pérdida de reputación de la organización.
• Pérdida de certificaciones.

Imagen: public domain pictures 

Mejores prácticas

He aquí algunas recomendaciones para elevar la seguridad en la protección de datos:

• Identificar toda la información relativa a datos personales y aplicar las políticas de tratamiento de datos personales (acceso, procesamiento, almacenamiento, etc), acorde a las leyes y legislaciones del país.
• Los datos confidenciales no pueden viajar en los parámetros de las urls. Deben hacerlo en el cuerpo o en las cabeceras HTTP.
• Los canales de comunicación en los que se transmiten los datos deben utilizar cifrado robusto.
• Los datos confidenciales deben cifrarse de forma segura antes de su almacenamiento.
• Evitar que los datos confidenciales se almacenen en la caché de los navegadores.
• Sobreescribir la memoria con ceros cuando la información confidencial ya no se utilice.
• Aplicar una política de borrado seguro para los datos que alcanzan el final de su ciclo de vida.

Referencias

• CCN-CERT BP/28: Recomendaciones sobre desarrollo seguro

Desarrollo seguro: comunicaciones

La transmisión de información en las aplicaciones es un punto clave de seguridad, por lo que es esencial asegurar la confidencialidad, la integridad y la disponibilidad de las comunicaciones.

Imagen: public domain pictures

Posibles riesgos

A continuación se describen algunos de los posibles riesgos relativos a las comunicaciones:

• Robo de información confidencial.
• Interrupción del servicio.
• Suplantación de identidad.
• Alteración o destrucción de datos.
• Propagación de software malicioso.

Mejores prácticas

He aquí algunas recomendaciones para elevar la seguridad en las comunicaciones:

• Utilizar siempre canales de comunicación cifrados mediante TLS o WebSocket.
• Usar criptografía robusta. 
• Utilizar protocolos seguros, como HTTPS o FTPS

Referencias

• CCN-CERT BP/28: Recomendaciones sobre desarrollo seguro

Desarrollo seguro: transacciones

Las transacciones son operaciones críticas de negocio, como pagos o actividades financieras. Debido a su especial sensibilidad requieren fuertes medidas de seguridad, tales como:

• Autenticación. Uso de contraseñas seguras y MFA para autorizar el acceso a las transacciones.
• Criptografía. Asegurar la confidencialidad de las transacciones.
• Validación. Aseguramiento de la legitimidad de las transacciones, evitando ataques y fraudes.
• Monitorización. Permite detectar y prevenir de ataques y fraudes en tiempo real.
• Copias de seguridad. Permite recuperar la disponibilidad de los datos en caso de ataques, caídas del sistema o pérdidas de datos.

Las transacciones deben cumplir las propiedades ACID: Atomicity, Consistency, Isolation y Durability.

Imagen: linnworks

Posibles riesgos

A continuación se describen algunos de los posibles riesgos relativos a las transacciones:

• Payment Bypass. Vulnerabilidad de configuración que permite a un atacante manipular, en un sistema de pago, los parámetros y la respuesta entre cliente y servidor para eludir el sistema de pago.
• Fraude. El atacante se beneficia de forma ilícita, manipulando las transacciones o usando información falsa.
• Robo de información confidencial.  Para ser usada en futuros ataques.
• Interrupción de las transacciones. Con ataques DoS/DDoS.
• Pérdida de datos. Puede afectar a la confidencialidad y a la integridad de la información.

Mejores prácticas

He aquí algunas recomendaciones para elevar la seguridad en las transacciones:

• Evitar un Payment Bypass:
• Toda compra ha de autorizarse y confirmarse en el servidor.
• Validar la autenticidad de las firmas durante la comunicación con la pasarela de pago.
• Verificar el precio correcto en el servidor.
• Asegurar que los pagos no se reutilizan.
• Comprobar la fase actual de la transacción en el servidor de pago.
• Para cada transacción, configurar un tiempo corto de expiración.
• Llevar una trazabilidad fehaciente de las transacciones.
• Utilizar comunicaciones con cifrado asimétrico.
• Registrar el detalle de cada operación, anonimizando los datos sensibles.

Referencias

• CCN-CERT BP/28: Recomendaciones sobre desarrollo seguro

Desarrollo seguro: gestión de archivos

Los archivos son activos esenciales en la seguridad de un sistema de información, pues contiene y persiste gran parte de la información. Por ello, la gestión de archivos debe contemplarse desde la fase de diseño, identificando los archivos internos, los archivos que se cargan, su ubicación, el control de acceso, la copia de seguridad, el flujo de la información, los datos que contiene, etc.

Imagen: imageapi

Posibles riesgos

A continuación se describen algunos de los posibles riesgos relativos a la gestión de archivos:

• Acceso no autorizado. Implicaría la revelación, manipulación, pérdida o borrado de datos.
• Carga de archivos maliciosos. Podría ejecutar archivos de forma remota, provocar una infección de malware o realizar un ataque de denegación de servicio.
• Carencia de copias de seguridad. Provocaría la pérdida de datos a la organización, la pérdida de datos de usuario o la falta de disponibilidad del servicio. 

Mejores prácticas

He aquí algunas recomendaciones para elevar la seguridad en la gestión de archivos:

• Exigir la autenticación y la autorización de cada usuario al acceder a un archivo.
• El nombrado de archivos y directorios no puede ser realizado con entradas de usuario.
• Validar el tipo de contenido por encima de la extensión del archivo.
• Verificar el tipo MIME del archivo.
• Impedir la subida de archivos ejecutables.
• Para evitar problemas de disponibilidad y de impacto en el servidor, limitar el tamaño del archivo.
• Procesar los archivos mediante un antivirus y antimalwares.
• En el directorio de subida de archivos de usuarios, desactivar los privilegios de ejecución.
• Al proporcionar un enlace de descarga a un usuario, no facilita rutas absolutas (canonización de path).
• Evitar el nombrado secuencial de archivos.
• En el nombre de un archivo, no utilizar datos sensibles.
• El acceso al archivo debe ser de sólo lectura.
• Poner límite al número de archivos que puede subir un usuario.
• Para asegurar su integridad, almacenar los hashes de cada archivo subido.

Referencias

• CCN-CERT BP/28: Recomendaciones sobre desarrollo seguro

Desarrollo seguro: criptografía

 La criptografía protege la información, garantizando la:

• Autenticidad.  Se verifica la identidad de las personas y sistemas que acceden a la información.
• Confidencialidad. Solamente las personas autorizadas pueden acceder a la información.
• Integridad. Solamente las personas autorizadas podrán alterar la información.

Imagen: Cripto Tendencia

La criptografía se puede usar para generar firmas digitales que aseguren la integridad de los datos, o también para cifrar datos sensibles.

Cifrado

Funciones hash

Un hash se obtiene a través de una función matemática, dando como resultado un resumen de datos de una cantidad siempre fija, independientemente del número de datos de entrada. La probabilidad de que se genere el mismo hash con diferentes datos de entrada (colisión) es muy improbable, lo que ofrece un alto nivel de seguridad. 

Un hash concreto solamente puede obtenerse con la misma función, los mismos datos de entrada y en el mismo orden, lo que es idóneo para almacenar contraseñas o para verificar la integridad (no alteración) de los datos. 

Cifrado simétrico

En este tipo de cifrado protege la confidencialidad en la transmisión y el almacenamiento de los datos, utilizando la misma clave para cifrar y descifrar la información. La ventaja es que fácil y rápido de implementar, pero, por contra, tanto el emisor como el receptor deben compartir la clave, lo que se convierte en un punto débil, especialmente en entornos distribuidos.

Cifrado asimétrico

Este cifrado requiere dos claves diferentes. La clave pública es compartida públicamente y se utiliza para cifrar la información, mientras que la clave privada se mantiene en secreto, y solo puede ser usada para descifrar.

La ventaja de este cifrado es que no es necesario compartir la clave privada para establecer una comunicación segura. La desventaja es que es más lento y difícil de implementar que el cifrado simétrico.

Posibles riesgos

A continuación se describen algunos de los posibles riesgos relativos al uso de información que no esté suficientemente encriptada:

• Exposición de información sensible. Disponibilidad de esta información para usuarios no autorizados.
• Robo de credenciales y suplantación de identidad. El acceso a contraseñas permitirían a un atacante suplantar a un usuario.
• Fuga de datos personales. El robo de datos personales son punibles y sancionables según las regulaciones de cada país.
• Ataques Man in the Middle (MitM). Se pueden interceptar comunicaciones poco aseguradas y descubrir el flujo de datos que lleve a información útil y valiosa para realizar ataques.
• Reputación para la organización.

Mejores prácticas

He aquí algunas recomendaciones para elevar la seguridad en la criptografía:

• Evitar el uso de algoritmos criptográficos antiguos u obsoletos, como DES, MD5 o SHA-1.
• Usar librerías criptográficas reputadas.
• Toda información sensible y confidencial debe estar fuertemente cifrada para asegurar la confidencialidad.
• Los números aleatorios utilizados en ids, códigos, nombres de archivos y cadenas se generan a través de un generador de números aleatorios disponible en una librería criptográfica reputada.
• Los números aleatorios se deben generar con un nivel entropía adecuado.
• Aplicar políticas de gestión de claves criptográficas para la generación, distribución, revocación y desactualización.
• Para evitar ataques de volcado de memoria, sobreescribir con ceros la información crítica que deje de utilizarse.

Referencias

• CCN-CERT BP/28: Recomendaciones sobre desarrollo seguro

Desarrollo seguro: el registro de seguridad

Es imprescindible tener un registro (o log) en un entorno protegido, el cual registre toda actividad o evento del sistema o de las aplicaciones, en lo concerniente a la seguridad. Este registro es vital para un posible análisis forense en un futuro.

Imagen: goodfreephotos.com

El registro de seguridad ha de cumplir los siguientes requisitos:

• Trazabilidad. Debe tener un formato temporal que facilite la trazabilidad de los eventos.
• Auditabilidad. Ha de almacenarse de forma segura y durante un tiempo mínimo de retención, a efectos de auditoría.
• Autenticación/autorización. El acceso a este registro sólo estará disponible para personas autenticadas y autorizadas.
• Confidencialidad. El registro ha de asegurar que no puede ser accedido por medios distintos a la autenticación y autorización. Los datos sensibles deben ser cifrados.
• Integridad. El registro debe asegurar que no hay manipulaciones a nivel de registro ni de entradas. Para ello, se recomienda el uso de firmas de integridad que se actualicen con cada nueva entrada.
• Disponibilidad. Su almacenamiento debe ser redundante y contar con copias de respaldo.

Posibles riesgos

A continuación se describen algunos de los posibles riesgos relativos al registro de seguridad:

• Fuga de información. Si hubiera vulnerabilidad en la autorización, un atacante podría acceder a la información sensible del registro.
• Falsificación de registros. Una falta de integridad permitiría a un usuario no autorizado a manipular las entradas del registro, con lo que rompería la trazabilidad. Esto también podría llegar a provocar la ejecución de código malicioso.
• Eliminación de registros. Un atacante podría eliminar sus propias entradas en el registro, para eliminar su actividad.

Mejores prácticas

He aquí algunas recomendaciones para elevar la seguridad en el registro de seguridad:

• Evitar registrar datos sensibles (como datos personales, contraseñas, tarjetas de crédito, información financiera, etc). Si se registra, cifrar esta información mediante criptografía, tokens o anonimización.
• Validar los datos antes de registrar la entrada, a fin de garantizar la información y evitar inyecciones.
• Registrar el detalle de cada entrada:
• Intentos de autenticación, sobre todo, los fallidos.
• Accesos concedidos con roles, incluyendo el usuario.
• Acceso a datos sensibles: qué usuario, qué roles, qué acciones se han realizado.
• Errores de validación de las entradas.
• Excepciones del sistema.
• Amenazas e intentos de amenazas detectados.
• Usar funciones hash para verificar la integridad de las entradas.
• Mantener el registro de seguridad en un entorno protegido e independiente de otros registros.

Referencias

• CCN-CERT BP/28: Recomendaciones sobre desarrollo seguro

Desarrollo seguro: gestión de errores

La gestión de errores se refiere, por una parte, al control de la información que se expone cuando ocurre un error, y, por otra parte, a cómo controlar los errores no controlados en una aplicación.

Cuidado con la información mostrada

Hay que tener especial cuidado a la hora de mostrar la información de un error, pues podemos revelar inconscientemente información que podría ser aprovechada por un atacante. Esta información podría ser, por ejemplo, parte de la configuración de la aplicación, algún estado, mensajes de depuración, datos sensibles o confidenciales, el tiempo que tarda en ejecutarse algunas operaciones, códigos importantes, usuarios y/o contraseñas, ids de sesión, elementos de la infraestructura o de la arquitectura, versiones, etc. Esta información promueve algunos riesgos tales como:

• Fuga de información sensible: estructura de archivos, documentos sensibles, motor de base de datos, versión del servidor, etc.
• Denegación de servicio. Ciertos errores forzados podrían provocar la caída del sistema.
• Cross-Site Scripting. Un mensaje de error podría revelar parámetros de entrada sin validación de caracteres de escape.

Control de errores

Es de vital importancia controlar que todas las operaciones prevean y gestionen todas las excepciones posibles, pues una excepción no controlada podría provocar una salida inesperada de la lógica de negocio que exponga vulnerabilidades que puedan ser aprovechadas por un atacante.

Un punto probable de errores inesperados puede surgir cuando no se cierran correctamente los recursos, por lo que se recomiendo el cierre de estos dentro de un bloque try/catch/finally.

Algunos posibles riesgos producidos por un deficiente control de errores podrían ser:

• Denegación de servicio. El abuso de ciertas operaciones no controladas podrían causar la caída del sistema.
• Saltarse la lógica de negocio. Se podrían forzar excepciones o errores no controlados, los cuales producirían salidas inesperadas de la lógica de negocio.

Mejores prácticas

He aquí algunas recomendaciones para elevar la seguridad en la gestión de errores:

• Usar mensajes genéricos en los errores, para no dar pistas sobre datos sensibles.
• Usar un control de excepciones centralizado.
• Manejar los errores sin depender de los mensajes de error del servidor mostrados al usuario.
• Por defecto, denegar el acceso en caso de un error en el control de acceso.
• Estudiar en profundidad todas las excepciones de una librería para su correcto tratamiento e implementación.
• Asegurar el cierre de todos los recursos dentro de bloques try/catch/finally.
• Registrar en detalle todas las excepciones en un registro específico dentro de un entorno seguro.

Referencias

• CCN-CERT BP/28: Recomendaciones sobre desarrollo seguro

 

Desarrollo seguro: validación de datos

Lo más crítico en la seguridad de un sistema de información son los datos, por lo que hay que asegurar que el tratamiento de los mismos no exponen vulnerabilidades, y por ello, para evitar ataques, es indispensable una correcta validación, tanto en la entrada como en la salida.

Imagen: maxpixel

Técnicas de validación

Sanitización

Consiste en normalizar toda posible representación de un dato a un formato único o estándar, reduciendo los problemas de validación y el número de ataques.

Existen varios métodos de sanitización, algunos de los cuales pueden encontrarse en librerías o paquetes. Los métodos más comunes son:

• Rutas: Se normalizan rutas a directorios (por ejemplo en Unix), lo que evita que un atacante navegue a un directorio sensible y obtenga información no autorizada.
• Espacios: Se eliminan espacios, tabulaciones y otros caracteres blancos del dato.
• Charset: Se normalizan los caracteres del datos a un charset en concreto, tratando de forma concreta aquellos caracteres que no pertenecen a dicho charset.
• Case: Se convierten los caracteres a mayúsculas o minúsculas.

Tipos de datos

Se verifica que el dato sea de un tipo concreto. El tipo puede ser simple (entero, decimal, carácter, boolean, string) o complejo (email, nif, código postal, url, etc).

Formato

Dentro de los tipos complejos, permite validar el formato de éstos mediante patrones o expresiones regulares. 

Importante: Una expresión regular compleja puede ser vulnerable a un ataque ReDoS, por lo que es aconsejable validar previamente la expresión con herramientas como RegEx Testing o RegEx 101.

Tamaños mínimos y máximos

Controlando un umbral de tamaños (longitud) se evitan cuelgues en el procesamiento del dato.

Valores mínimos y máximos

Ejerce un control sobre un umbral de valores para un dato.

Lista blanca

El dato se encuentra dentro de una lista o conjunto de datos prefijados, como una enumeración.

Lista negra

El dato no se debe encontrar dentro de una lista o conjunto de datos prefijados.

Posibles riesgos

A continuación se describen algunos de los posibles riesgos relativos a la validación de datos:

• Cross-Site Scripting: Un atacante podría inyectar código a través de un dato, por ejemplo en un navegador web.
• Inyección SQL: Un atacante inyectaría código SQL a través de los datos, siendo ejecutado por la base de datos.
• Inyección LDAP: Un atacante inyectaría consultas LDAP para obtener más privilegios o para acceder a datos restringidos.
• Inyección de Log: Un atacante podría inyectar comandos de ejecución en el sistema usando los logs que registran los datos.
• Inyección XEE: Un atacante podría acceder a datos restringidos o la información de la estructura de un árbol XML a través de una inyección XPATH.
• Bomba XML: Un atacante podría provocar un ataque de denegación de servicio sobrecargando el XML y agotando los recursos de la memoria de la aplicación.
• DoS, DDoS y ReDoS: Un atacante podría provocar una denegación de servicio del sistema o de la aplicación si no hay una validación adecuada de las entradas. 

Mejores prácticas

He aquí algunas recomendaciones para elevar la seguridad en la validación de datos:

• Las validaciones son siempre obligatorias en el servidor y recomendadas en el cliente.
• Utilizar esquemas de validación de datos y mecanismos estándar que aseguren la validación de datos mediante las técnicas de validación vistas anteriormente.
• Realizar las validaciones utilizando librerías estandarizadas.
• Los datos estructurados han de estar bien tipificados y validados por un esquema definido.
• Los datos no estructurados deben ser sanitizados, utilizando alguna librería de sanitización.
• No mostrar información sensible ante un error de validación.
• En las entradas de datos, solamente aceptar aquellos datos que sean los esperados. Si alguno de los datos de entrada no es el esperado, rechazarlo.
• El servidor debe rechazar cualquier petición en la que exista algún error de validación de entrada.
• Las consultas a bases de datos deben estar parametrizadas, para así evitar la inyección SQL.
• Los frameworks ORM no están exentos de vulnerabilidades de inyección SQL. Consultar la documentación del ORM y utilizar consultas parametrizadas siempre que sea posible.
• Verificar si la aplicación es vulnerable a inyección de comandos.
• Asegurar que las páginas web utilizan plantillas que automaticen las variables dentro del código HTML, para evitar XSS (Cross-Site Scripting)
• Utilizar la configuración más restrictiva posible para el análisis XML, desactivando funciones peligrosas, como la resolución de entidades externas.
• Evitar la deserialización de datos no confiables o protegerse contra éstos.

Referencias

• CCN-CERT BP/28: Recomendaciones sobre desarrollo seguro

Desarrollo seguro: gestión de sesiones

Cuando un usuario se autentica en el sistema y obtiene la autorización en el mismo, se crea una nueva sesión identificada mediante un id, la cual crea una conexión activa usuario-sistema, almacenando información temporal sobre las operaciones y la lógica de negocio exclusivas de ese usuario mientras dure dicha sesión.

Imagen: Wallpaperflare

Una vez establecida la sesión, para poder llevar a cabo las operaciones, el usuario se identificará con el servidor mediante cookies o mediante tokens. En el caso de las cookies, éstas se almacenan en el navegador del cliente, lo que es un sistema poco seguro y no recomendable. Los tokens, sin embargo, se asocian al id de la sesión y viajan en la cabecera de las peticiones, y pueden modificarse por intercambio cada cierto tiempo sin necesidad de cambiar el id de la sesión, la cual permanece en el lado del servidor, lo que es un método mucho más seguro que el de las cookies.

Aspectos de seguridad

Aspectos básicos

• Asegurar que la autenticación sólo permite acceder a las personas acreditadas.
• Asegurar las autorizaciones correctas para las personas autenticadas.
• Asegurar la comunicación cliente-servidor mediante cifrado fuerte.

Sesión del lado cliente

• La información persistente del id de sesión del cliente quedará asociada a la pestaña, y si ésta se cierra o desaparece, desaparecerá toda esa información. Esto se logra mediante código en la propia página o mediante el objeto sessionStorage.
• La información persistente de la sesión del cliente se ha de borrar en la pantalla de login y generarse una vez creada la sesión en el servidor.
• En pantallas que puedan necesitar mucho tiempo (por ejemplo, un formulario), permitir que la sesión de cliente realice transacciones vacías contra el servidor, para indicar que la sesión sigue activa y no expire.
• El cliente también debe controlar el tiempo de inactividad, lanzando una petición al servidor para que cierre la sesión, tras lo cual se redirigirá a la pantalla de login.
• La información de la sesión del cliente ha de ser mínima para la lógica de navegación. No debe contener información sensible. A lo sumo, puede contener el token de acceso para no arrastrarlo en todas las peticiones.
• Evitar ataques de fijación de sesión mediante un tiempo de espera de inicio de sesión.
• Capturar los eventos de cierre de pestaña o de la ventana del navegador, a fin de forzar tanto el cierre de la sesión de cliente como del servidor.

ID de sesión

• El id de sesión ha de ser único, aleatorio y con una longitud muy grande, como un hash criptográfico seguro.
• El id ha de ser validado por el servidor, verificando su formato y que está presente en una sesión válida y activa.
• En los registros no usar nunca el id de sesión.
• Para evitar ataques de fijación de sesión, cambiar el id de sesión en cada inicio de sesión o en un cambio de privilegios de usuario.
• Al monitorizar y almacenar los ids de sesión activos, asegurarse de que no pueden ser consultados por usuarios no autorizados.

Cierre de sesión

• Redirección a la pantalla de login en cada cierre.
• Eliminación de toda la información de la cookie o del token de acceso.
• Eliminación de toda la información de la sesión cliente.
• Registro del cierre (registro de seguridad).

Caducidad de la sesión

• Definir un tiempo máximo de vida, para que no esté permanentemente activa.
• Definir un tiempo máximo absoluto de duración para la sesión.
• Toda la información de la sesión debe eliminarse del servidor cuando caduca.
• Registrar (registro de seguridad) cada vez que una sesión expira.

En aplicaciones móviles:

• Usar tokens, con el fin de que no sean usados en caso de que el dispositivo se pierda o se sustraiga.
• El token de sesión no puede contener el id del dispositivo.
• La caducidad de la sesión ha de configurarse según la sensibilidad de la app.
• Para utilizar la sesión en varias páginas apoyarse en un repositorio de datos basado en servidor.

Posibles riesgos

A continuación se describen algunos de los posibles riesgos relativos a la gestión de sesiones:

• Predicción de sesión. El id de sesión podría adivinarse y así evitar la autenticación.
• Secuestro de sesión. Aprovecha el mecanismos de control de la sesión web, normalmente mediante un token de sesión.
• Fijación de sesión. Mediante la obtención de un id de sesión correcto, permitiría a un usuario autenticarse y secuestrar la sesión.
• Suplantación de sesión. Ejemplo: mediante phishing, se engaña a una víctima para entrar en un sitio web malicioso que suplante un sitio legítimo.

Mejores prácticas

He aquí algunas recomendaciones para elevar la seguridad en la gestión de sesiones:

• El id de sesión nunca debe exponerse bajo tráfico no cifrado.
• Implementar cabeceras seguras, como strict-transport security ó cache-control.
• La sesión ha de expirar pasado un tiempo de inactividad.
• Las páginas que necesiten autenticación han de tener la opción de cierre de sesión.
• El id de sesión nunca debe aparecer en urls, registros o mensajes de error.
• Cada autenticación y re-autenticación ha de destruir la sesión anterior y crear una nueva.
• El id de sesión almacenado en cookies se define mediante los atributos HttpOnly y Secure.
• Para evitar el acceso a otros dominios, configurar el atributo Path de las cookies.
• La aplicación debe realizar seguimiento de las sesiones activas, así como permitir al usuario finalizar éstas de forma selectiva o global desde su cuenta.
• Al cambiar una contraseña, se deben cerrar todas las sesiones activas.
• Asegurarse de que sólo los usuarios autorizados acceden a recursos protegidos: urls, funciones, datos de la aplicación, atributos de usuario y datos de configuración de acceso.
• Registrar (registro de seguridad) todas la actividades (o eventos) de las sesiones, tanto del cliente como del servidor.

 

Referencias

• CCN-CERT BP/28: Recomendaciones sobre desarrollo seguro

Desarrollo seguro: la autorización

La autorización determina qué puede hacer un usuario o un sistema en nuestra aplicación.

Si la autenticación gestiona el acceso de un usuario, la autorización gestiona los permisos de ese usuario a las diferentes funciones, operaciones y recursos de la aplicación.

Imagen: CPO Magazine

Posibles riesgos

A continuación se describen algunos de los posibles riesgos relativos a la autorización:

• Acceso no autorizado. Un usuario no autorizado podría acceder a recursos no permitidos.
• Escalada vertical de privilegios. Acceso a los recursos de otro usuario con un nivel más alto de permisos.
• Escalada horizontal de privilegios. Acceso a los recursos de otro usuario con el mismo nivel de acceso.
• Revelación de información sensible. La aplicación podría dar más información de la necesaria, lo cual podría ser usada de forma perniciosa.
• Violación de la privacidad. Un atacante accede a datos privados de otros usuarios.
• Robo de identidad. Un atacante obtiene la identidad de un usuario y la usa para acceder a la aplicación y realizar acciones con sus permisos.
• Robo de datos. Un atacante obtiene datos de forma ilícita.
• Disponibilidad del servicio. Un atacante podría interrumpir o dañar el servicio o la ejecución de la aplicación.
• Manipulación de datos. Un atacante podría interceptar datos entre cliente y servidor y manipular éstos.
• Modificación de registros. Acceso a los registros de la aplicación o del sistema y modificación de éstos alterando su integridad.
• Path transversal. Acceso fuera del contexto autorizado en el sistema de archivos del servidor.
• Lógica de negocio. Un mal diseño de la aplicación podría permitir a un usuario realizar operaciones no permitidas, debido a que no sigue una lógica de negocio controlada.

Mejores prácticas

He aquí algunas recomendaciones para elevar la seguridad en la autorización:

• Principio de privilegio mínimo. El usuario solo tiene permitido lo mínimo para realizar su trabajo.
• Roles de aplicación. El usuario solo tiene roles, y los privilegios son tomados de dichos roles.
• El acceso a los registros ha de estar protegido.
• Cada usuario sólo puede acceder a los datos y recursos que le son autorizados.
• Acceso al sistema de archivos esté deshabilitado. Este acceso solo puede ser habilitado de forma excepcional, justificada y expresa.
• Las reglas de control de acceso solamente se han de aplicar en el servidor.
• La gestión de acceso a datos, atributos, información, roles, políticas, etc. de los usuarios no pueden ser manipulados por usuarios no autorizados.
• Uso de un servicio centralizado que proteja el acceso a cada recurso.
• Uso de tokens aleatorios robustos anti-CSRF.
• Registro de todo intento de control de acceso (registro de seguridad).
• Registro específico y detallado (registro de seguridad) de todas las operaciones sobre datos sensibles.
• Uso de captchas en operaciones sensibles.

Referencias

• CCN-CERT BP/28: Recomendaciones sobre desarrollo seguro

Desarrollo seguro: la autenticación

La autenticación determina el acceso a los recursos de un sistema de información, a través de la verificación de la identidad de un usuario o de un dispositivo. Dada su relevancia, la autenticación debe estar presente en el diseño.

Fuente: OptimalIdm

Existen diferentes tipos de autenticación:

• Autenticación de red: Se utilizan unas credenciales de red (como el usuario+contraseña, un certificado digital, etc.) para acceder al sistema.
• Autenticación basada en contraseñas: El usuario debe proporcionar su nombre de usuario y su contraseña.
• Autenticación basada en tokens: Un token único permite acceder al sistema. Dicho token puede ser físico o digital.
• Autenticación basada en algo poseído: Mediante un soporte que solamente el usuario pueda tener físicamente, como un código QR, una tarjeta de identidad, un smartcard, un USB, un token físico, una tarjeta de coordenadas, etc.
• Autenticación de dos o más factores: La identidad es requerida mediante varios métodos de identificación, como por ejemplo la contraseña y un SMS. También se lo conoce como 2FA (2 Factor Authentication) y MFA (Multi-Factor Authentication).
• Autenticación biométrica: La identidad se obtiene a partir de características físicas, tales como la huella dactilar, el iris del ojo, la voz, el reconocimiento facial, etc.
• Autenticación basada en comportamientos: Uso de patrones de dibujo sobre una pantalla táctil, movimientos de alguna parte del cuerpo, etc.
• Autenticación basada en ubicación: Por ejemplo, mediante una IP específica.

Posibles riesgos

A continuación se exponen algunas de las amenazas y riesgos posibles relativos a la autenticación:

• Ataques de diccionario. Pruebas de contraseñas mediante combinaciones comunes y predefinidas de letras y números.
• Ataques de fuerza bruta. Pruebas de contraseñas generadas mediante combinaciones de caracteres.
• Ataques Man in the Middle (MitM). Interviniendo las comunicaciones se pueden obtener las credenciales de acceso (contraseñas, tokens, tickets de acceso).
• Ataques de replay. Si se obtiene un ticket de acceso, éste puede ser reutilizado.
• Vulnerabilidades de software. Aplicaciones y sistemas operativos con vulnerabilidades.
• Enumeración de usuarios. Es posible encontrar usuarios registrados probando identidades y analizando las respuestas del servidor (mensajes, tiempos de respuesta, etc).
• Suplantación de identidad. Se suplanta al servidor de autenticación para engañar al usuario y obtener así sus credenciales.
• Robo de identidad. Se obtiene la identidad de un usuario, por ejemplo, robando una cookie.

Mejores prácticas

He aquí algunas recomendaciones para tener un alto nivel de seguridad en la autenticación:

• Las contraseñas han de guardarse en un formato no legible, a ser posible, que la operación de obtener la contraseña en plano sea irreversible, como el uso de hashes fuertes.
• Proporcionar opciones y enlaces para la desconexión del usuario en la aplicación.
• Automatizar la desconexión pasado un tiempo de inactividad.
• No exponer las credenciales en las urls.
• Los formularios de petición de credenciales deben usar métodos POST.
• Uso de la autenticación multi-factor en aplicaciones sensibles (múltiples capas de seguridad).
• Uso del doble factor de autenticación en operaciones críticas, como el cambio de contraseña o el acceso a recursos sensibles.
• Implementar el bloqueo de una cuenta tras varios intentos de autenticación fallidos.
• Implementar CAPTCHA para limitar los ataques de fuerza bruta.
• Usar errores genéricos para evitar la enumeración de usuarios. Por ejemplo: "El usuario y/o la contraseña son incorrectos".
• Implementar tiempos de espera aleatorios en respuestas a intentos fallidos de autenticación, con lo que se evita la enumeración de usuarios.
• En la funcionalidad de recuperación de contraseñas, evitar la enumeración de usuarios.
• El campo de contraseña debe tener desactivado la opción de "autocompletar".
• Utilizar una buena política de contraseñas:
• Uso de caracteres alfabéticos, números y caracteres especiales, con distinción de mayúsculas y minúsculas).
• Longitud amplia (por ejemplo, 16 caracteres).
• Una contraseña distinta por cada sitio.
• Establecimiento de una caducidad de contraseña (por ejemplo cada mes). Una vez transcurrido ese tiempo será necesario cambiarla.
• No almacenar la cookie de autenticación en el navegador del cliente.
• Cada vez que el usuario se conecte con éxito, la sesión debe ser diferente.
• Registrar todas las operaciones que afecten a datos sensibles.

Tipos de autenticación más comunes

Autenticación basada en claves

Una autenticación basada en claves (por ejemplo, mediante nombre de usuario y contraseña), es bastante débil en términos de seguridad, se utilice en texto claro, en base64, cifrado o mediante formularios. Sus principales riesgos son:

• Ingeniería social. 
• Ataques Man in the Middle (MitM). Un usuario con acceso a la red podría interceptar la información de autenticación.
• Reutilización de claves. Si se utiliza la misma clave en varios sitios, si se intercepta en uno, el resto queda comprometido.
• Ataque de fuerza bruta o diccionario. 
• Autenticación débil. No permite la implementación de medidas de autenticación más seguras, como el MFA o los certificados digitales.

Las mejores recomendaciones son las siguientes:

• Buena política de contraseñas
• Uso de autenticación multifactor. Por ejemplo, añadir a la contraseña una verificación de código que se envíe por email, SMS o por aplicaciones externas de autenticación, tales como Google Authenticator o oneLogin Protect.

Autenticación implícita

En este caso, la autenticación no se basa en credenciales proporcionadas por el usuario, si no que la identificación se obtiene automáticamente mediante la dirección IP del usuario, la información de una cookie, un token, etc. Aunque puede ser seguro, existen ciertos riesgos:

• Acceso no autorizado. Es posible falsificar la ip de un usuario para obtener el acceso. También es posible acceder a la cookie de un usuario y utilizarla para obtener el acceso. 
• Ataque de fuerza bruta o diccionario. Es vulnerable a este ataque si no usa algoritmos de cifrado robustos. 
• Autenticación débil. No permite la implementación de medidas de autenticación más seguras, como el MFA o los certificados digitales.

La mejor recomendación es utilizar una contraseña basada en un hash criptográfico lo bastante largo y robusto que haga inútil un ataque de fuerza bruta.

Autenticación de cliente HTTP

Este tipo de autenticación utiliza un par de claves criptográficas para verificar la identidad del usuario o del dispositivo: una clave pública (usada para cifrar la información) y una clave privada (usada para descrifrar la información). Este sistema es bastante seguro y se utiliza para comunicaciones HTTPS, pero su implementación es más compleja y costosa, además de existir otro tipo de riesgos:

• Acceso no autorizado. Si se obtiene la clave privada del usuario, podemos utilizarla para acceder a los recursos de ese usuario. Por otra parte, si se emite un certificado falso con una clave pública falsa, es posible acceder a recursos protegidos de forma no autorizada.
• Ataque Man in the Middle (MitM). Es posible interceptar un certificado en tránsito y usarlo para acceder de forma no autorizada.
• Manipulación de un certificado SSL. En el caso de implementar certificados auto-firmados o certificados no verificados por una CA (Certification Authority).

Referencias

• CCN-CERT BP/28: Recomendaciones sobre desarrollo seguro

Desarrollo seguro: todo empieza en la arquitectura

La arquitectura constituye los cimientos sobre los cuales se erigirán nuestras aplicaciones. 

Fuente: open stand

Posibles riesgos

El desarrollo seguro comienza con el diseño y la definición de nuestra arquitectura, teniendo en mente las posibles amenazas que pudieran poner en riesgo nuestro sistema, especialmente aquellas derivadas por el uso de componentes que:

• no estén identificados.
• sean antiguos o incompatibles, que estén obsoletos o hayan dejado de ser soportados.
• posean vulnerabilidades conocidas.
• tengan puertos abiertos no indispensables.

Mejores prácticas

A continuación se detallan las mejores prácticas a la hora de diseñar, definir y mantener una arquitectura segura:

• Inventario que identifique cada componente de la arquitectura. Todo componente debe estar identificado, o de lo contrario se incurrirá en riesgos de seguridad.
• Revisión del bastionado de componentes:
• Identificación de dependencias internas:
• Módulos.
• Librerías.
• Frameworks.
• Plugins o complementos.
• Servicios.
• Otras.
• Estado de actualización.
• Configuraciones:
• Puertos activados (solo los indispensables).
• Usuarios y contraseñas personalizados (no por defecto).
• Modo de depuración desactivado.
• Otras configuraciones de seguridad (ajustadas a una mayor seguridad).
• Identificación de vulnerabilidades y sus parches de seguridad. En caso de no existir parche:
• analizar el riesgo y su impacto
• proponer y adoptar:
• un plan de vigilancia.
• un plan de contingencias.
• realizar un estudio de viabilidad de componentes alternativos.
• Asegurar la seguridad perimetral lógica mediante la segmentación de red, firewalls, dispositivos IDS, etc.
• Asegurar la protección de datos mediante:
• autorización entre entornos.
• copias de seguridad.
• Proporcionar un entorno virtual como zona de trabajo, a ser posible, por lenguaje de programación.
• Mantener las actualizaciones más recientes de:
• lenguajes de programación
• paquetes instalados
• frameworks y librerías
• herramientas de análisis y seguridad de los IDEs
• En caso de trabajar con DevSecOps, dotar de herramientas de análisis de seguridad a lo largo del ciclo de vida del software, antes del despliegue en cada entorno.

Referencias

• CCN-CERT BP/28: Recomendaciones sobre desarrollo seguro