Nociones breves acerca de la necesidad de la protección de los datos (o la trilogía de como ser un desarrollador cuqui sin llamarse Borja Mari…)

Nociones breves acerca de la necesidad de la protección de los datos:

Introducción:

Antes de comenzar a daros la paliza con una de mis infumables chapas de desarrollo seguro y demás, quisiera dedicar unas breves palabras, este año 2018 ha sido un año … interesante podríamos decir. Un año con muchos cambios y movimiento en lo profesional y en lo personal. Los cambios son buenos y el salir de nuestra zona de confort, a pesar del lógico respeto que da, también es bueno. Aprovecho este modesto lugar en internet para desear lo mejor a mi amigo Byt3St0rm, que se fue en busca de su sueño a lejanas tierras allende los mares, si hubiera más soñadores así, posiblemente el mundo sería un lugar mejor.

Continuar leyendo “Nociones breves acerca de la necesidad de la protección de los datos (o la trilogía de como ser un desarrollador cuqui sin llamarse Borja Mari…)”

Controles proactivos en el desarrollo seguro de software (Implementación de Control de Accesos (y como ser un developer “cuqui” y muy pro))

Introducción:

Control de Acceso es el proceso mediante el cual se conceden o deniegan las solicitudes de acceso a una característica o recurso en particular. Cabe señalar que la autorización no equivale a una autenticación (verificación de la identidad). Estos términos y sus definiciones se confunden con frecuencia y no debemos caer en ese error.

El diseño del Control de Acceso puede comenzar de forma sencilla, pero a menudo puede convertirse en un control de seguridad bastante complejo y pesado. Los siguientes requisitos de diseño de control de acceso “positivos” deben ser considerados en las etapas iniciales del desarrollo de la aplicación. Una vez que se ha elegido un patrón de diseño de control de acceso específico, a menudo es difícil y lento rediseñar el control de acceso en su aplicación con un nuevo patrón. El control de acceso es una de las principales áreas del diseño de seguridad de aplicaciones que debe ser muy meditado por adelantado, especialmente cuando se trata de requisitos como el multi-tenancy y el control de acceso horizontal (específico de datos).

Continuar leyendo “Controles proactivos en el desarrollo seguro de software (Implementación de Control de Accesos (y como ser un developer “cuqui” y muy pro))”

Controles de identidad en el desarrollo seguro de software

Indice

Nociones breves acerca de la necesidad de la implementación de controles de identidad y autentificación 2

Reglas generales de autentificación: 2

ID de usuario 2

Dirección de correo electrónico como ID de usuario 3

Validación 3

Normalización 4

Implementar controles adecuados de fortaleza de contraseña 4

Longitud de la contraseña 4

Complejidad de la contraseña 5

Topologías de contraseña 5

Información adicional 5

Recomendación: 6

Implementar un mecanismo seguro de recuperación de contraseña 6

Almacenar contraseñas de forma segura 6

Transmitir contraseñas sólo sobre TLS u otro transporte fuerte 6

Solicitar volver a autentificarse para funciones sensibles 7

Utilizar la autentificación por múltiples factores 7

Autentificación TLS 7

Autentificación y mensajes de error 8

Respuestas de autentificación 8

Códigos de error y URLs 8

Prevenir ataques por fuerza bruta 9

Uso de protocolos de autentificación que no requieren contraseña 9

OAuth 9

OpenId 10

SAML 10

FIDO 10

Directrices generales para el manejo de sesiones 11

Gestión de contraseñas 11

Sesión: Generación y caducidad 11

Requieren autenticación para funciones sensibles 12

Implementar un mecanismo seguro de recuperación de contraseñas 12

Nociones breves acerca de la necesidad de la implementación de controles de identidad y autentificación

¡Bueno! otra vez por aqui, hoy vamos a hablar de uno de los pasos mas importantes a la hora de desarrollar código de manera segura, los controles de identidad y autenficicación. ¿Qué es esto? La autenticación es el proceso de verificar que un individuo o una entidad es quien dice ser. La autenticación se realiza comúnmente enviando un nombre de usuario o ID y uno o más elementos de información privada que sólo un usuario determinado debe conocer.

La gestión de sesiones es un proceso mediante el cual un servidor mantiene el estado de una entidad que interactúa con ella. Esto es necesario para que un servidor recuerde cómo reaccionar a las solicitudes posteriores durante una transacción. Las sesiones se mantienen en el servidor mediante un identificador de sesión que se puede pasar de un lado a otro entre el cliente y el servidor al transmitir y recibir solicitudes. Las sesiones deben ser únicas por usuario y computacionalmente imposibles de predecir.

La gestión de identidades es un tema más amplio que no sólo incluye la autenticación y la gestión de sesiones, sino que también cubre temas avanzados como la federación de identidades, el inicio de sesión único, las herramientas de gestión de contraseñas, la delegación, los repositorios de identidades y mucho más.

Asimismo debemos plantearnos, de ser posible, usar la autentificación multifactor (Multi-Factor Authentication o MFA):

La autenticación multifactorial (MFA) garantiza que los usuarios son quienes dicen ser, exigiéndoles que se identifiquen con una combinación de:

    • Algo que saben – contraseña o PIN
    • Algo que poseen – ficha o teléfono
  • Algo que son – biometría, como una huella dactilar

Reglas generales de autentificación:

ID de usuario

Asegúrese de que sus nombres/identificadores de usuarios no sean sensibles a mayúsculas y minúsculas. El usuario ‘fpalenzuela’ y el usuario ‘Fpalenzuela’ deberían ser el mismo usuario.

Dirección de correo electrónico como ID de usuario

Muchos sitios utilizan la dirección de correo electrónico como identificador de usuario, lo cual es un buen mecanismo para asegurar un identificador único por cada usuario sin agregarle a éstos la carga de tener que recordar un nuevo nombre de usuario. Sin embargo, muchas aplicaciones Web no tratan correctamente las direcciones de correo electrónico, debido a conceptos equivocados sobre lo que constituye una dirección de correo electrónico válida.

En concreto, es completamente válido tener una dirección correo electrónico que:

  • Es sensible a mayúsculas y minúsculas en la parte local
  • Tiene caracteres no alfanuméricos en la parte local (incluyendo + y @)
  • Tiene cero o más etiquetas (aunque ciertamente cero no va a ocurrir)

La parte local es la parte de la dirección de correo electrónico que se encuentra a la izquierda del carácter ‘@’. El dominio es la parte de la dirección de correo electrónico que se encuentra a la derecha del carácter ‘@’ y consiste en cero o más etiquetas unidas por el carácter de punto.

Al momento de estar escribir este artículo, el RFC 5321 es el estándar actual que define el protocolo SMTP y lo que constituye una dirección de correo electrónico válida.

Por favor, tenga en cuenta que las direcciones de correo electrónico deberían ser consideradas datos públicos. En aplicaciones de alta seguridad, podrían asignarse los nombres de usuario y ser secretos en lugar de ser datos públicos definidos por el usuario.

Validación

Muchas aplicaciones Web contienen expresiones regulares informáticamente muy costosas e inexactas para intentar validar las direcciones de correo electrónico.

Cambios recientes generaron que el número de falsos negativos se viera incrementado, particularmente debido a:

  • El aumento de popularidad de las subdirecciones de proveedores como Gmail (comúnmente usando + como token en la parte local para afectar a la entrega)
  • Nuevos gTLDs con nombres largos (muchas expresiones regulares comprueban el número y longitud de cada etiqueta en el dominio)

Siguiendo el RFC 5321, las mejores prácticas para la validación de una dirección de correo electrónico deberían ser:

    • Comprobar la presencia de al menos un símbolo de @ en la dirección
    • Asegurarse de que la parte local no es de más de 64 bytes
    • Asegurarse de que el dominio no es de más de 255 bytes
  • Asegurarse que sea una dirección de entrega verídica (se refiere a que el correo pueda ser entregado)

Para asegurarse que una dirección de entrega sea verídica, la única forma es enviar un correo electrónico al usuario y que éste deba tomar alguna acción para confirmar que lo ha recibido. Más allá de confirmar que la dirección de correo electrónico es válida y reciba los mensajes, esto también nos proporciona una confirmación positiva de que el usuario tiene acceso al buzón de correo y es probable que esté autorizado a usarlo. Esto no significa que otros usuarios no tengan acceso al mismo buzón de correo, cuando por ejemplo el usuario utiliza un servicio que genera una dirección de correo electrónico desechable, algo que no debemos dejar de tener en cuenta.

Normalización

Como la parte local de las direcciones de correo electrónico son, de hecho, sensibles a mayúsculas y minúsculas, es importante almacenar y comparar las direcciones de correo electrónico correctamente. Para normalizar la entrada de una dirección de correo electrónico, debería convertirse la parte del dominio SOLO a minúsculas.

Desafortunadamente, esto hace y hará a la entrada, más difícil de normalizar y de coincidir correctamente con los intentos del usuario.

Es razonable aceptar solo una única capitalización de diferentes alternativas para direcciones de correo electrónico idénticas. Sin embargo, en este caso es crítico para:

    • Almacenar la parte del usuario tal y como fue provista y verificada por el usuario en el proceso de verificación
  • Realizar comparaciones lowercase(provista) == lowercase(almacenada)

Implementar controles adecuados de fortaleza de contraseña

Una de las principales preocupaciones cuando se utilizan contraseñas para la autentificación, es la fortaleza de las contraseñas. Una política de contraseñas “fuertes” hace que sea difícil o incluso improbable adivinar la contraseña a través de medios manuales o automatizados. Las siguientes características definen una contraseña fuerte:

Longitud de la contraseña

Las contraseñas más largas proporcionan una mayor combinación de caracteres y en consecuencia hacen que sea más difícil de adivinar para un atacante.

  • La longitud mínima de las contraseñas debería ser forzada por la aplicación.
    • Las contraseñas menores a 10 caracteres son consideradas débiles.

Mientras que la longitud mínima forzada puede causar problemas para la memorización de la contraseña en algunos usuarios, las aplicaciones deberían alentarlos a establecer frases de paso o passphrases (frases o combinaciones de palabras) que pueden ser mucho más largas que las contraseñas típicas y mucho más fáciles de recordar.

  • La longitud máxima de la contraseña no debería establecerse demasiado baja, ya que esto evitará que los usuarios puedan crear frases de paso (passphrases). La longitud máxima típica es de 128 caracteres.
    • Frases de paso de menos de 20 caracteres usualmente son consideradas débiles si solo se emplean letras minúsculas.

Complejidad de la contraseña

Las aplicaciones deberían imponer reglas de complejidad de contraseñas para evitar las contraseñas fáciles de adivinar. Los mecanismos de contraseñas deberían permitir al usuario, poder escribir casi cualquier carácter como parte de su contraseña, incluyendo el carácter de espacio. Las contraseñas deberían, obviamente, ser sensibles a mayúsculas y minúsculas a fin de incrementar la complejidad de las mismas. Ocasionalmente, encontramos sistemas donde las contraseñas no son sensibles a mayúsculas y minúsculas, frecuentemente debido a problemas de sistemas heredados como los viejos ordenadores centrales que no tenían contraseñas sensibles a mayúsculas y minúsculas.

El mecanismo de cambio de contraseña debería requerir un nivel mínimo de complejidad que tenga sentido para la aplicación y su población de usuarios. Por ejemplo:

    • La contraseña debe reunir al menos 3 de las siguientes 4 reglas de complejidad
      • al menos 1 mayúscula (A-Z)
      • al menos 1 minúscula (a-z)
      • al menos 1 dígito (0-9)
      • al menos 1 caracter especial (puntuación) ( no debemos olvidar de tratar también, a los espacios en blanco como un carácter especial).
    • al menos 10 caracteres
    • no más de 128 caracteres
  • no más de 2 caracteres idénticos consecutivos (por ejemplo, 111 no está permitido)

Topologías de contraseña

    • Prohibir topologías de contraseñas de uso común
    • Forzar a varios usuarios a utilizar diferentes topologías de contraseña
  • Exigir un cambio mínimo de topología entre viejas y nuevas contraseñas

Información adicional

  • Asegúrese de que todos los caracteres que el usuario escribe están realmente incluidos en la contraseña. Hemos visto sistemas que truncan la contraseña a una longitud inferior de la que el usuario provee (ej., truncada a los 15 caracteres cuando se han ingresado 20).
    • Esto es manejado usualmente al establecer la longitud de TODOS los campos de contraseña exactamente como la longitud máxima de la contraseña. Esto es particularmente importante si su longitud máxima de contraseña es corta, como 20-30 caracteres.

Si la aplicación requiere políticas de contraseña más complejas, será necesario ser muy claro sobre cuáles son esas políticas.

  • La política requerida necesita ser indicada explícitamente en la página de cambio de contraseña
    • asegúrese de enumerar cada caracter especial que permite, para que sea evidente para el usuario

Recomendación:

  • Lo ideal, sería que la aplicación indicara al usuario cómo escribir su nueva contraseña y cuánto de la directiva de complejidad de su nueva contraseña cumple
    • De hecho, el botón de envío debería verse atenuado hasta que la nueva contraseña reúna los requisitos establecidos en la política de complejidad de contraseña y la segunda copia de la nueva contraseña coincida con la primera. Esto hará que sea mucho más fácil, para el usuario, entender la política de complejidad y cumplirla.

Independientemente de cómo se comporte la UI, cuando un usuario envía su solicitud de cambio de contraseña:

  • Si la nueva contraseña no cumple con la política de complejidad de contraseña, el mensaje de error debería describir TODAS las reglas de complejidad con las cuáles la nueva contraseña no cumple y no sola la primera regla con la que no cumpla.

Implementar un mecanismo seguro de recuperación de contraseña

Es común que una aplicación tenga un mecanismo que provea al usuario un medio para acceder a su cuenta en caso de que olvide su contraseña. Por favor, para más detalles sobre esta característica, vea Forgot Password Cheat Sheet (en inglés).

Almacenar contraseñas de forma segura

Es fundamental para una aplicación, almacenar contraseñas usando la técnica criptográfica correcta. Para conocer más sobre este mecanismo, vea Password Storage Cheat Sheet (en inglés).

Transmitir contraseñas sólo sobre TLS u otro transporte fuerte

La página de inicio de sesión y todas las páginas autentificadas subsiguientes, deberían ser accedidas exclusivamente sobre TLS u otro transporte fuerte. La página de inicio de sesión principal, conocida como “landing page”, debe ser servida sobre TLS u otro transporte fuerte.

Si no se utiliza TLS u otro transporte fuerte para la landing page de inicio de sesión, se permite a un atacante modificar el action del formulario de inicio de sesión, generando que las credenciales del usuario sean enviadas a una ubicación arbitraria.

Si no se utiliza TLS u otro transporte fuerte para las páginas autentificadas que se habilitan luego del inicio de sesión, un atacante puede ver la ID de sesión sin cifrar y comprometer la sesión autentificada del usuario.

Solicitar volver a autentificarse para funciones sensibles

Con el fin de mitigar ataques CSRF y de secuestro de sesión (hijacking), es importante solicitar las credenciales actuales de una cuenta en los siguientes casos:

  • Antes de modificar información sensible (como la contraseña del usuario, la dirección de correo electrónico del usuario)
  • Antes de transacciones sensibles (como enviar una compra a una nueva dirección).

Sin esta contramedida, un atacante puede ser capaz de ejecutar transacciones sensibles a través de un ataque CSRF o XSS sin necesidad de conocer las credenciales actuales del usuario. Adicionalmente, un atacante puede obtener, temporalmente, acceso físico al navegador del usuario o robar su ID de sesión para tomar el control de la sesión del usuario.

Utilizar la autentificación por múltiples factores

La autentificación por múltiples factores (MFA por las siglas en ingles de “Multi-factor authentication”) es el uso de más de un factor de autentificación para iniciar sesión o procesar una transacción, mediante:

  • Algo que se conoce (detalles de la cuenta o contraseñas)
  • Algo que se tiene (tokens o teléfonos móviles)
  • Algo que se es (factores biométricos)

Los esquemas de autentificación como las contraseñas de un solo uso (OTP por las siglas en inglés de “One Time Passwords”) implementadas utilizando un token físico (hardware) también pueden ser un factor clave en la lucha contra ataques tales como los ataques CSRF y malware del lado del cliente. Un considerable número de los token de hardware para MFA disponibles en el mercado, permiten una buena integración con las aplicaciones Web.

Autentificación TLS

La autentificación TLS, también conocida como autentificación TLS mutua, consiste en que ambos, navegador y servidor, envíen sus respectivos certificados TLS durante el proceso de negociación TLS (handshaking). Así como se puede validar la autenticidad de un servidor mediante el certificado y, preguntar a una Autoridad de Certificación conocida (CA, por las siglas en inglés de “Certificate Authority”) si la certificación es válida, el servidor puede autentificar al usuario recibiendo un certificado desde el cliente y validándolo contra una CA o su propia CA. Para hacer esto, el servidor debe proveer al usuario de un certificado generado específicamente para él, asignando valores que puedan ser usados para determinar que el usuario debe validar el certificado. El usuario instala los certificados en el navegador y los usa para el sitio Web.

Es una buena idea hacer esto cuando:

  • Es aceptable (o incluso preferido) que el usuario sólo tenga acceso a la página web desde una sola computadora/navegador.
  • El usuario no se asusta fácilmente por el proceso de instalación de certificados TLS en su navegador o habrá alguien, probablemente de soporte de TI, que hará esto para el usuario.
  • El sitio web requiere un paso adicional de seguridad.
  • El sitio Web es de la intranet de una compañía, empresa u organización.

Por lo general, no es una buena idea utilizar este método para la mayor parte de los sitios Web de acceso público que tendrán un usuario promedio. Por ejemplo, no será una buena idea implementar esto en un sitio Web como Facebook. Si bien esta técnica puede evitar que el usuario tenga que escribir una contraseña (protegiéndola así contra el robo desde un keylogger promedio), aún se considera una buena idea emplear el uso de una contraseña combinada con la autentificación TLS.

Para más información, puedes ver: Client-authenticated TLS handshake

Autentificación y mensajes de error

En el caso de las funcionalidades de autentificación, los mensajes de error implementados de forma incorrecta pueden ser utilizados con el propósito de obtener y almacenar identificadores de usuario y contraseñas. Una aplicación, debería responder (tanto en los encabezados HTTP como en el contenido HTML) de forma genérica.

Respuestas de autentificación

Una aplicación debería responder mensajes de error genéricos independientemente de si era incorrecto el identificador de usuario o la contraseña. Tampoco debería dar información sobre el estado de una cuenta existente.

Ejemplo de respuestas incorrectas

  • “Inicio de sesión para el usuario foo: contraseña incorrecta”
  • “Falló el inicio de sesión: usuario no válido”
  • “Falló el inicio de sesión: cuenta deshabilitada”
  • “Falló el inicio de sesión: usuario inactivo”

Ejemplo de respuestas correctas

  • “Falló el inicio de sesión: Usuario o contraseña incorrectos”

La respuesta correcta no debería indicar si el identificador de usuario o la contraseña es el parámetro incorrecto y por lo tanto, inferir un identificador de usuario válido.

Códigos de error y URLs

La aplicación puede retornar un código de error HTTP diferente dependiendo del resultado del intento de autentificación. Puede responder con un 200 para un resultado positivo y con un 403 para un resultado negativo. Aunque una página de error genérico sea mostrada al usuario, el código de respuesta HTTP puede ser diferente, permitiendo filtrar la información sobre si la cuenta es válida o no.

Prevenir ataques por fuerza bruta

Si un atacante es capaz de adivinar una contraseña sin ser deshabilitada debido a intentos de autentificación fallidos, el atacante tiene la oportunidad de continuar con un ataque de fuerza bruta hasta que la cuenta se vea comprometida. La automatización de los ataques de fuerza bruta para adivinar contraseñas en aplicaciones Web son un desafío muy usual.

Los mecanismos de bloqueo de contraseña deberían ser empleados para bloquear una cuenta si se realiza más de un número predeterminado de intentos fallidos de autentificación.

Los mecanismos de bloqueo de contraseña tienen una debilidad lógica. Un atacante que emprende un gran número de intentos de autentificación sobre nombres de cuentas conocidas puede producir como resultado, el bloqueo de bloques enteros de cuentas de usuario. Teniendo en cuenta que la intención de un sistema de bloqueo de contraseña es proteger de ataques por fuerza bruta, una estrategia sensata es bloquear las cuentas por un período de tiempo (ej., 20 minutos). Esto ralentiza considerablemente a los atacantes mientras que permite automáticamente, reabrir las cuentas para los usuarios legítimos.

Además, la autenticación de múltiples factores es un muy poderoso elemento de disuasión cuando se trata de prevenir los ataques de fuerza bruta ya que las credenciales son un blanco móvil. Cuando la autenticación de múltiples factores se implementa y activa, el bloqueo de cuentas ya no es necesario.

Uso de protocolos de autentificación que no requieren contraseña

Mientras que la autentificación a través de una combinación usuario/contraseña y el uso de la autentificación de factores múltiples es generalmente considerada segura, hay casos de uso en los que no se considera la mejor opción o incluso seguro. Un ejemplo de esto son las aplicaciones de terceros que desean conectarse a la aplicación Web, ya sean desde un dispositivo móvil, algún otro sitio web, aplicaciones de escritorio u otras situaciones. Cuando esto sucede, NO es considerado seguro permitir a la aplicación de terceros almacenar la combinación de usuario/contraseña, ya que se amplía la superficie de ataque a sus manos, donde queda fuera de su control. Por esto y por otros casos de uso, hay varios protocolos de autentificación que pueden protegerlo de exponer los datos de sus usuarios a los atacantes.

OAuth

Open Authorization (OAuth) es un protocolo que permite a una aplicación autentificar a un usuario contra un servidor, sin requerir contraseñas o algún servidor externo que actúe como proveedor de identidad. Utiliza un token generado por el servidor, ofreciendo un flujo de autorización sostenido, para que un cliente tal como una aplicación móvil, pueda llamar al servidor que el usuario está utilizando el servicio.

La recomendación es usar e implementar OAuth 1.0a o OAuth 2.0, ya que a la primera versión (OAuth1.0) se la ha encontrado vulnerable a los ataques de fijación de sesión (session fixation).

OAuth 2.0 se basa en HTTPS para la seguridad y actualmente es usado e implementado por las API de empresas como Facebook, Google, Twitter y Microsoft. OAuth1.0a es más difícil de usar porque requiere de bibliotecas criptográficas para las firmas digitales. Sin embargo, no se basa en HTTPS para la seguridad y, por lo tanto, puede ser más adecuado para las transacciones de mayor riesgo.

OpenId

OpenId un protocolo basado en HTTP que utiliza proveedores de identidad para validar que un usuario es quien dice ser. Es un protocolo muy simple que permite a un proveedor de servicios de identidad un camino para el inicio de sesión único (SSO, por las siglas en inglés de “single sign-on”). Esto permite a los usuarios reutilizar una sola identidad dada a un proveedor de identidad OpenId de confianza y ser el mismo usuario en múltiples sitios web, sin la necesidad de proveer la contraseña a ningún sitio Web, exceptuando al proveedor de identidad OpenId.

Debido a su simplicidad y a que proporciona protección de contraseñas, OpenId ha sido bien aceptado. Algunos de los proveedores de identidad OpenId bien conocidos son Stack Exchange, Google, Facebook y Yahoo!

Para entornos no empresariales, OpenId es considerado seguro y frecuentemente, la mejor opción, siempre y cuando el proveedor de identidad sea de confianza.

SAML

El lenguaje de marcado para confirmaciones de seguridad (SAML, siglas en inglés de “Security Assertion Markup Language”) a menudo se considera la competencia de OpenId. La versión más recomendada es la 2.0, ya que posee características muy completas y proporciona gran seguridad. Como con OpenId, SAML utiliza proveedores de identidad, pero a diferencia de éste, está basado en XML y proporciona mayor flexibilidad. SAML está basado en redirecciones del navegador las cuales envían los datos en formato XML. A diferencia de SAML, OpenId no solo es iniciado por un proveedor de servicios, sino que también puede ser iniciado desde el proveedor de identidad. Esto permite al usuario navegar entre diferentes portales mientras que se mantienen autentificado sin tener que hacer nada, haciendo que el proceso sea transparente.

Mientras que OpenId ha tomado la mayor parte del mercado de consumo, SAML es a menudo la opción para aplicaciones empresariales. La razón de esto, frecuentemente, es que hay pocos proveedores OpenId que son considerados de clase empresarial (lo que significa que la forma en la que validan la identidad del usuario no tiene los altos estándares requeridos para la identidad de la empresa). Es más común ver SAML siendo usado dentro de la intranet de un sitio Web, a veces incluso, utilizando un servidor desde la internet como el proveedor de identidad.

En los últimos años, las aplicaciones como SAP ERP y SharePoint (SharePoint utilizando Active Directory Federation Services 2.0) deciden usar la autentificación SAML 2.0, a menudo como un método preferido para las implementaciones de inicios de sesión únicos siempre que se requiera la federación empresarial para servicios Web y aplicaciones.

Ver también si se desea ampliar: SAML Security Cheat Sheet

FIDO

La Fast Identity Online (FIDO) Alliance ha creado dos protocolos para facilitar la autentificación online: los protocolos Universal Authentication Framework (UAF) y Universal Second Factor (U2F). Mientras que el protocolo UAF se enfoca en la autentificación sin contraseña, U2F permite la adición de un segundo factor de autenticación basado en contraseñas existentes. Ambos protocolos están basados en una llave pública de modelo criptográfico desafío-respuesta.

UAF toma ventaja de las tecnologías de seguridad existentes presentes en los dispositivos de autenticación, incluyendo sensores de huellas digitales, cámaras (biométrica fácil), micrófonos (biométrica de voz), Entornos de ejecución de confianza (TEE, siglas en inglés de Trusted Execution Environment), Elementos seguros (SE, siglas en inglés de Secure Elements) y otros. El protocolo está diseñado para conectar las capacidades de este dispositivo en un marco de autenticación común. UAF trabaja con ambas aplicaciones nativas y Web.

U2F aumenta la autenticación basada en contraseñas mediante un token de hardware (típicamente un USB) que almacena llaves de autenticación criptográficas y las utiliza para firmar. El usuario puede utilizar el mismo token como un segundo factor para múltiples aplicaciones. U2F trabaja con aplicaciones Web. Provee protección contra phishing utilizando la URL del sitio Web para buscar la llave de autentificación almacenada.

Directrices generales para el manejo de sesiones

El manejo de sesiones está directamente relacionado a la autentificación. Las Directrices generales para el manejo de sesiones previamente disponibles en esta Hoja de referencias de Autentificación de OWASP han sido integradas en Session Management Cheat Sheet.

Gestión de contraseñas

Los gestores de contraseñas son programas, complementos para el navegador o servicios Web que automatizan el manejo de un gran número de diferentes credenciales, incluyendo la memorización y rellenado automático, generando contraseñas aleatorias en diferentes sitios, etc. La aplicación Web puede ayudar a los administradores de contraseñas:

  • Usando formularios HTML estándar para los campos de ingreso de nombres de usuario y contraseñas,
  • No deshabilitando el “copy & paste” en los campos de los formularios HTML,
  • Permitiendo contraseñas muy largas.
  • No usando esquemas de inicio de sesión en múltiples etapas (nombre de usuario en la primera pantalla, luego la contraseña).
  • No usando esquemas de autentificación con largos scripts (JavaScript).

Sesión: Generación y caducidad

En cualquier autenticación y reautenticación exitosa, el software debe generar una nueva sesión e identificación de sesión.

Para minimizar el período de tiempo que un atacante puede lanzar ataques sobre sesiones activas y secuestrarlas, es obligatorio establecer tiempos de expiración para cada sesión, después de un período de inactividad especificado. La duración del tiempo de espera debe ser inversamente proporcional al valor de los datos protegidos.

Requieren autenticación para funciones sensibles

En el caso de transacciones sensibles, tales como cambiar la contraseña o la dirección de envío para una compra, es muy importante solicitar al usuario que vuelva a autenticarse y, si es posible, que genere un nuevo ID de sesión tras una autenticación satisfactoria.

Implementar un mecanismo seguro de recuperación de contraseñas

Es común que una aplicación tenga un mecanismo para que un usuario acceda a su cuenta en caso de que olvide su contraseña. Un buen flujo de trabajo de diseño para una función de recuperación de contraseñas utilizará elementos de autenticación multi-factor (por ejemplo, hacer una pregunta de seguridad – algo que saben, y luego enviar un token generado a un dispositivo – algo que poseen).

Controles proactivos en el desarrollo Seguro de Software (RC 1.01)

(La amenaza de las cárnicas….)

 

Introducción y medidas paliativas en desarrollo de software seguro

 

 

 

 

Indice

Nociones breves acerca de la necesidad de la validación de los datos: 2

Nociones breves acerca de Validación de Entradas: 2

¿Cómo paliarlo/solucionarlo? 3

Patrones regulares 3

1. Desinfección de marcas HTML con una biblioteca diseñada para el trabajo 4

2. HtmlSanitizer – https://github.com/mganss/HtmlSanitizer 4

3. OWASP Java HTML Sanitizer – OWASP Java HTML Sanitizer Project 5

4. Ruby on Rail SanitizeHelper – http://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html 5

5. Otras librerías que realizan Sanitización HTML 5

Validación del Texto Unicode de formato libre 5

Validación de la subida de archivos 5

Almacenaje de datos 6

Precauciones con archivos en formatos “Especiales” 6

Validación de Email 6

Conclusiones finales 7

Referencias extras: 8

Prevención de vulnerabilidades 8

Otras referencias: 8

Herramientas: 8

Nociones breves acerca de la necesidad de la validación de los datos:

¡Bueno! Otra vez por aquí, parece que fue ayer y ya ni recuerdo la última vez que escribí en esta, la casa de todos nosotros (y la tuya , si tu deseas…). Esto es como lo que dice el célebre vídeo de: “¿Esto que es lo que es…?”. Pues para eso estoy aquí, para que lo sepas.

La validación de la entrada se realiza para garantizar que sólo los datos formados correctamente están introduciendo el flujo de trabajo en un sistema de información, evitando que los datos malformados persistan en la base de datos y provoquen el mal funcionamiento de varios componentes posteriores. La validación de la entrada debe producirse lo antes posible en el flujo de datos, preferiblemente tan pronto como se reciban los datos de la parte externa.

Cualquier dato que sea introducido directamente o influenciado por los usuarios debe ser tratado como no confiable. Una aplicación debe comprobar que estos datos son válidos tanto sintáctica, como semánticamente (en ese orden) antes de utilizarlos de cualquier manera (incluida la visualización de nuevo al usuario). Además, las aplicaciones más seguras tratan todas las variables como no confiables y proporcionan controles de seguridad independientemente del origen de los datos.

La validez de sintaxis significa que los datos están en la forma esperada. Por ejemplo, una aplicación puede permitir que un usuario seleccione un “ID de cuenta” de cuatro dígitos para realizar algún tipo de operación. La aplicación debe asumir que el usuario está ingresando una carga útil de inyección SQL, y debe verificar que los datos ingresados por el usuario son exactamente de cuatro dígitos de longitud, y consisten sólo en números (además de utilizar la parametrización de consulta apropiada).

La validez semántica significa que los datos son significativos: En el ejemplo anterior, la aplicación debe asumir que el usuario está introduciendo maliciosamente un ID de cuenta al que no se le permite el acceso. La aplicación debe comprobar que el usuario tiene permiso para acceder a dicho ID de cuenta.

La validación de las entradas debe ser totalmente del lado del servidor: los controles del lado del cliente se pueden utilizar según la conveniencia de cada momento. Por ejemplo, la validación JavaScript puede alertar al usuario de que un campo en particular debe consistir en números, pero el servidor debe validar que el campo realmente consiste en números. Por otro lado, no debemos olvidar que la validación de entrada no debe utilizarse como el método principal para prevenir XSS, SQL pero pueden contribuir significativamente a reducir su impacto si se implementan correctamente.

Nociones breves acerca de Validación de Entradas:

Una gran mayoría de las vulnerabilidades de la aplicación web surgen por no validar correctamente la entrada, o por no validar completamente la entrada. Los usuarios que utilizan una interfaz de usuario no necesariamente introducen esta “entrada” directamente. En el contexto de aplicaciones web (y servicios web), esto podría incluir, pero no está limitado a:

  • Cabeceras HTTP
  • Cookies
  • Parámetros GET y POST (incluyendo campos ocultos)
  • Subidas de archivos (incluyendo información como el nombre del archivo)

Del mismo modo, en aplicaciones móviles, esto puede incluir:

  • Comunicación entre procesos (IPC – por ejemplo, Android Intents)
  • Datos recuperados de los servicios web back-end
  • Datos recuperados del sistema de archivos del dispositivo

Hay dos enfoques generales para realizar la validación de la sintaxis de entrada, comúnmente conocida como lista negra y lista blanca:

  • La lista negra (o blacklist) intenta comprobar que una entrada de usuario determinada no contiene contenido “conocido como malicioso”. Esto es similar a cómo funcionará un programa antivirus: como primera línea de defensa, un antivirus comprueba si un archivo coincide exactamente con el contenido malicioso conocido y, si lo hace, lo rechaza. Esta tiende a ser la estrategia de seguridad más débil.
  • La lista blanca (o Whitelist) intenta comprobar que una entrada de usuario determinada coincide con un conjunto de entradas “bien conocido”. Por ejemplo, una aplicación web puede permitirle seleccionar una de las tres ciudades: la aplicación comprobará que una de ellas ha sido seleccionada y rechazará todas las demás entradas posibles. La lista blanca basada en caracteres es una forma de lista blanca donde una aplicación comprobará que la entrada del usuario contiene sólo caracteres “conocidos buenos”, o coincide con un formato conocido. Por ejemplo, esto puede implicar comprobar que un nombre de usuario contiene sólo caracteres alfanuméricos, y contiene exactamente dos números.

Cuando se construye software seguro, la lista blanca es el enfoque generalmente preferido. Las listas negras son propensas a errores y se pueden pasar por alto con varias técnicas de evasión (y necesitan ser actualizadas con nuevas “firmas” cuando se crean nuevos ataques).

¿Cómo paliarlo/solucionarlo?

Patrones regulares

Las expresiones regulares ofrecen una manera de comprobar si los datos coinciden con un patrón específico – esta es una gran manera de implementar la validación de listas blancas.

Cuando un usuario se registra por primera vez para una cuenta en una aplicación web hipotética, algunas de las primeras piezas de datos requeridos son un nombre de usuario, contraseña y dirección de correo electrónico. Si esta entrada proviene de un usuario malicioso, la entrada podría contener cadenas de ataque. Al validar la entrada del usuario para asegurarnos de que cada dato contiene sólo el conjunto válido de caracteres y cumple con las expectativas de la longitud de los datos, podemos dificultar el ataque a esta aplicación web.

Empecemos con la siguiente expresión regular para el nombre de usuario.

^[a-z0-9_]{3,16}$

Esta expresión regular, validación de entrada, lista blanca de buenos caracteres sólo permite letras minúsculas, números y el carácter de subrayado. El tamaño del nombre de usuario también se está limitando a 3-16 caracteres en este ejemplo.

Aquí hay un ejemplo de expresión regular para el campo de contraseña:

^(?=.*[a-z])(?=.*[A-Z]) (?=.*\d) (?=.*[@#$%]).{10,4000}$

Esta expresión regular asegura que una contraseña tiene de 10 a 4000 caracteres de longitud e incluye una letra mayúscula, una letra minúscula, un número y un carácter especial (uno o más usos de @, #, $, o %).

Aquí hay un ejemplo de expresión regular para una dirección de correo electrónico:

^[a-zA-Z0-9.!#$%&’*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$

Se debe tener cuidado al crear expresiones regulares. Las expresiones mal diseñadas pueden resultar en condiciones potenciales de negación de servicio (también conocidas como ReDDoS). Un buen análisis estático o una herramienta de tester de expresión regular puede ayudar a los equipos de desarrollo de productos a encontrar casos de este caso de forma proactiva.

También hay casos especiales de validación en los que las expresiones regulares no son suficientes. Si su aplicación maneja marcas de revisión — entradas no confiables que se supone que contienen HTML — puede ser muy difícil de validar. La codificación también es difícil, ya que rompería todas las etiquetas que se supone que están en la entrada. Por lo tanto, necesita una biblioteca que pueda analizar y limpiar el texto formateado en HTML. i Una expresión regular no es la herramienta adecuada para analizar y desinfectar HTML no confiable.

A continuación unos pequeños tips para ayudarte en la validación de entradas:

Desinfección de marcas HTML con una biblioteca diseñada para el trabajo

Si su aplicación maneja marcas de revisión — entradas no confiables que se supone que contienen HTML puede ser muy difícil de lograr una validación de entradas correcta validar. La codificación también es difícil, ya que rompería todas las etiquetas que se supone que están en la entrada. Por lo tanto necesitaremos una biblioteca que pueda analizar y limpiar texto con formato HTML. Hay varios disponibles en OWASP que son fáciles de usar:

HtmlSanitizer – https://github.com/mganss/HtmlSanitizer

Una biblioteca de código abierto. Net. El HTML se limpia con un enfoque de lista blanca (White list). Se pueden configurar todas las etiquetas y atributos permitidos. La biblioteca está probada con la hoja de trucos de evasión OWASP de XSS.

OWASP Java HTML Sanitizer – OWASP Java HTML Sanitizer Project

import org.owasp.html.Sanitizers;

import org.owasp.html.PolicyFactory;

PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);

String cleanResults = sanitizer.sanitize(“<p>Hello, <b>World!</b>”);

Ruby on Rail SanitizeHelper – http://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html

El módulo SanitizeHelper proporciona un conjunto de métodos para borrar texto de elementos HTML no deseados.

<%= sanitize @comment.body, tags: %w(strong em a), attributes: %w(href) %>

Otras librerías que realizan Sanitización HTML

PHP HTML Purifier – http://htmlpurifier.org/
JavaScript/Node.js Bleach – https://github.com/ecto/bleach
Python Bleach – https://pypi.python.org/pypi/bleach

Validación del Texto Unicode de formato libre

El texto de formato libre, especialmente con caracteres Unicode, es muy difícil de validar debido a un espacio relativamente grande de caracteres que necesitan ser incluidos en la lista blanca. Es una entrada de texto de forma libre que destaca la importancia de una codificación de salida adecuada, consciente del contexto, y demuestra claramente que la validación de entrada no es la principal protección contra Cross-Site Scripting – si sus usuarios quieren escribir apostrofa (‘) o menos que (<) en su campo de comentarios, pueden tener una razón perfectamente legítima para ello y el trabajo de la aplicación es manejarlo adecuadamente durante todo el ciclo de vida de los datos.

El medio principal de validación de entrada para la entrada de texto libre debe ser:

  • Normalización – asegurar que la codificación canónica se utiliza en todo el texto y que no hay caracteres inválidos presentes.
  • Categoría de carácter whitelisting – Unicode permite la lista blanca de categorías como “dígitos decimales” o “letras” que no sólo cubre el alfabeto latino sino también varios otros scripts usados globalmente (p. ej. árabe, cirílico, CJK ideografías etc)
  • Lista blanca de caracteres individuales – si usted permite letras e ideografías en los nombres y también quiere permitir el apóstrofe (‘) para los nombres irlandeses, pero no quiere permitir la categoría de puntuación completa.

Validación de la subida de archivos

En el caso de que se produzca subida de archivos a la aplicación, debemos tener en cuenta:

  • Utilizar la validación de entrada para asegurarnos de que el nombre de archivo cargado utiliza el tipo de extensión previsto.
  • Asegurarnos de que el archivo cargado no sea mayor que un tamaño máximo definido.
  • Si el sitio web soporta la carga de archivos ZIP, comprobar la validación antes de descomprimir el archivo. La comprobación incluye la ruta de destino, el nivel de compresión y el tamaño estimado de descompresión.

Almacenaje de datos

  • Debemos utilizar un nuevo nombre de archivo para guardar el archivo en el sistema operativo. No utilicemos ningún texto controlado por el usuario para este nombre de archivo o para el nombre de archivo temporal.
  • Cuando el archivo se sube a la web, se debe cambiar el nombre del archivo en el almacenamiento. Por ejemplo, el nombre de archivo cargado es prueba.JPG, renombrarlo a JAI1287uaisdjhf.JPG con un nombre de archivo aleatorio. El propósito de hacerlo para prevenir los riesgos de acceso directo a archivos y nombre de archivo ambiguo para evaluar el filtro, como por ejemplo prueba. jpg;. asp o /… /… /… /… /… /… /prueba.jpg.
  • Los archivos cargados deben analizarse en busca de contenido malicioso (anti-malware, análisis estático, etc.).
  • La ruta del archivo no debería poderse especificar por el lado del cliente. Debe ser especificado por el lado del servidor.

Precauciones con archivos en formatos “Especiales”

  • La función de carga del archivo debe utilizar un enfoque de lista blanca para permitir únicamente tipos de archivo y extensiones específicas. Sin embargo, es importante tener en cuenta los siguientes tipos de archivos que, si se permiten, pueden resultar en vulnerabilidades de seguridad.
  • crossdomain. xml” permite la carga de datos entre dominios en Flash, Java y Silverlight. Si se permite en sitios con autenticación, esto puede permitir el robo de datos entre dominios y ataques CSRF. Tengamos en cuenta que esto puede ser bastante complicado dependiendo de la versión específica del plugin en cuestión, así que lo mejor es prohibir los archivos llamados “crossdomain. xml” o “clientaccesspolicy.xml“.
  • “.htaccess” y “.htpasswd” proporciona opciones de configuración del servidor por directorio, y no debe permitirse. Véase http://en.wikipedia.org/wiki/Htaccess
  • Te sugiero que no se permitan archivos de script ejecutables en la web como aspx, css, swf, xhtml, rhtml, shtml, jsp, js, js, pl, php, cgi.

Validación de Email

Muchas aplicaciones web no tratan correctamente las direcciones de correo electrónico debido a los conceptos erróneos habituales sobre lo que constituye una dirección válida. Específicamente, es completamente válido tener una dirección de buzón de correo electrónico que:

  • Es sensible a mayúsculas y minúsculas en la parte local de la dirección (izquierda del carácter @ más a la derecha)
  • Tiene caracteres no alfanuméricos en la parte local (incluyendo + y @)
  • Tiene cero o más etiquetas

En el momento de la escritura, RFC 5321 es el estándar actual que define SMTP y lo que constituye una dirección de buzón de correo válida. Debemos en cuenta que las direcciones de correo electrónico deben considerarse datos públicos.

Muchas aplicaciones web contienen expresiones regulares computacionalmente caras e inexactas que intentan validar direcciones de correo electrónico. Los cambios recientes en el paisaje significan que el número de falsos negativos aumentará, particularmente debido a:

  • Mayor popularidad de la subdirección por parte de proveedores como Gmail (comúnmente se utiliza + como un símbolo en la parte local para afectar a la entrega)
  • Nuevos gTLDs con nombres largos (muchas expresiones regulares verifican el número y la longitud de cada etiqueta en el dominio)

Siguiendo el RFC 5321, la mejor práctica para validar una dirección de correo electrónico sería a:

  • Comprobar la presencia de al menos un símbolo @ en la dirección
  • Asegurarnos de que la pieza local no exceda los 64 octetos.
  • Asegurarnos de que el dominio no tiene más de 255 octetos.
  • Asegurarnos de que la dirección es entregable

Para asegurarnos de que una dirección es entregable, la única manera de comprobar esto es enviar un correo electrónico al usuario y hacer que éste tome medidas para confirmar la recepción. Además de confirmar que la dirección de correo electrónico es válida, esto también proporciona un reconocimiento positivo de que el usuario tiene acceso al buzón de correo electrónico y es probable que esté autorizado a utilizarlo. Esto no significa que otros usuarios no puedan acceder a este buzón de correo, por ejemplo, cuando el usuario hace uso de un servicio que genera una dirección de correo electrónico desechable.

Los enlaces de verificación de correo electrónico sólo deben satisfacer el requisito de verificar la propiedad de la dirección de correo electrónico y no deben proporcionar al usuario una sesión autenticada (p. ej., el usuario debe autenticarse de forma normal para acceder a la aplicación).

Los códigos de verificación de correo electrónico deben expirar después del primer uso o después de 8 horas si no se usan.

Conclusiones finales

Siempre debemos tener en cuenta y nunca olvidar que la validación de entrada no necesariamente hace que la entrada no confiable sea “segura”, ya que puede ser necesario aceptar caracteres potencialmente peligrosos como entrada válida. La seguridad de la aplicación debe ser reforzada cuando se utiliza esa entrada, por ejemplo, si la entrada se usa para construir una respuesta HTML, entonces se debe realizar la codificación HTML apropiada para prevenir ataques de cross-site scripting . Además, si se utiliza la entrada para crear una sentencia SQL, se debe utilizar la Parametrización de consulta. En estos dos casos (y otros) NO se debe confiar en la validación de entrada para la seguridad.

Referencias extras:

Prevención de vulnerabilidades

Otras referencias:

Herramientas:

Parametrización de las consultas

Controles proactivos en el desarrollo seguro de software, Parte 2

Siguiendo con nuestra serie de posts relacionados con el desarrollo seguro de software integrando los controles proactivos de OWASP, vamos a hablar hoy del segundo punto de dichos controles proactivos: la parametrización de las consultas.

Indice

Nociones breves acerca de la necesidad de la parametrización de las queries:

Nociones breves acerca de SQL Injection:

¿Cómo funciona?

¿Qué problemas pueden causar este tipo de ataques?

Ejemplo de explotación:

¿Cómo se explota?

¿Cómo paliar o anular esta amenaza?

1. Escapar los caracteres especiales utilizados en las consultas SQL

2. Delimitar los valores de las consultas

3. Verificar siempre los datos que introduce el usuario

4. Asignar mínimos privilegios al usuario que conectará con la base de datos

5. Programar bien

6. Uso de sentencias preparadas parametrizadas.

Ejemplos en varios lenguajes

7. Uso de procedimientos almacenados.

Ejemplos en varios lenguajes

Continuar leyendo “Parametrización de las consultas”