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”

Controles Proactivos en el Desarrollo Seguro de Software

Introducción a los controles Proactivos en Desarrollo de Software

Muy buenas amigos míos, pido disculpas por el retraso en volver a escribir, en verdad se hecha en falta estas charlas, pero ya sabéis como es este mundo, basta que uno quiera escribir para que los jefes, esos horribles seres que usan el excel como arma de destrucción masiva, no te dejen tiempo/ganas.

En fin, voy a iniciar una serie de escritos sobre el desarrollo de software, sobre unas pautas para desarrollar software seguro siguiendo para ello las indicaciones de OWASP acerca de unos controles proactivos en el desarrollo de software.

Continuar leyendo “Controles Proactivos en el Desarrollo Seguro de Software”

TIPS VERANIEGOS (o cómo yo también tengo un cuñado)

 ¡Muy buenas amigos míos! Ya lo siento, pero hoy me toca a mi dar un poco la lata, de modo que como hace muuuucho calor, vamos a ir a uno de mis ya clásicos “Tips Veraniegos” (imaginaos la música de Verano Azul de fondo…), bueno no, mejor no… 😉

Podríamos hablar de la implementación de la LOPD con miras al Reglamento Europeo de Proteción de Datos (RGPD) pero como que paso bastante.

Así que una cosa ligerita, cómoda para leer mientras tomas una cañita y poco más. ¿Y qué os puedo contar? A ver, os contaré la última que me pasó ayer… Continuar leyendo “TIPS VERANIEGOS (o cómo yo también tengo un cuñado)”