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