OWASP – Seguridad en la web

Cada vez es más común encontrar aplicaciones desarrolladas por empresas que usan servidores web o servidores de aplicaciones y que funcionan dentro del navegador. Este nuevo enfoque en el desarrollo de aplicaciones aporta importantes características tanto para los desarrolladores como para los usuarios.

Entre estas ventajas, cabe destacar que no importa la plataforma del cliente, mientras esta disponga de un navegador web:

• No importa si ejecuta Windows, Linux o Mac
• Si es un teléfono móvil o una PDA
• La aplicación no falla por errores en el sistema de los clientes
• Las nuevas actualizaciones del software no hay que instalarlas en todos los clientes.

Otra característica importante es que permite el acceso remoto de los usuarios a las aplicaciones.

El desarrollo de aplicaciones se ha convertido en una opción muy útil para aplicar soluciones. Pero es habitual encontrar desarrolladores poco cualificados trabajando en el diseño y programación de estos sistemas de información. Esto origina riesgos en las aplicaciones, sobre todo en el ámbito de la seguridad.

Los ataques a las aplicaciones web de una empresa son los más importantes que estas pueden sufrir. Atacantes de todo el mundo se enteran en unos minutos de cualquier problema que la página web de una empresa esté sufriendo.

Estos ataques tienen éxito gracias a:

• Una configuración incorrecta del servidor o errores de diseño del mismo.
• Complejidad alta de los servidores de las grandes empresas que hace que sean difíciles de administrar correctamente.
• Uso de servidores de fácil instalación con configuración genérica que no ofrecen garantías de seguridad.
• Uso de cantidad de herramientas que ofrecen gran potencia a la aplicación pero también aumentan las puertas de entrada a la misma.

Vamos a analizar aquí la seguridad en las aplicaciones web basada en el método OWASP.

¿Qué es OWASP?

El proyecto OWASP Application Security Verification Standard (ASVS) proporciona una base para probar los controles técnicos de seguridad de las aplicaciones web y también proporciona a los desarrolladores una lista de requisitos para un desarrollo seguro.

El objetivo principal del proyecto OWASP Application Security Verification Standard (ASVS) es normalizar el rango de cobertura y nivel de rigor disponible en el mercado a la hora de realizar la verificación de seguridad de aplicaciones web utilizando un estándar abierto comercialmente viable.

El estándar proporciona una base para probar los controles técnicos de seguridad de la aplicación, así como cualquier control técnico de seguridad en el entorno, en el que se confía para proteger contra vulnerabilidades como Cross-Site Scripting (XSS) e inyección SQL. Este estándar se puede utilizar para establecer un nivel de confianza en la seguridad de las aplicaciones web.

Los requisitos se desarrollaron con los siguientes objetivos en mente:

• Uso como métrica: proporciona a los desarrolladores y propietarios de aplicaciones un criterio con el que evaluar el grado de confianza que se puede depositar en sus aplicaciones web,
• Utilización como guía: brinda orientación a los desarrolladores de control de seguridad sobre qué incorporar en los controles de seguridad para satisfacer los requisitos de seguridad de la aplicación, y
• Uso durante la adquisición: proporciona una base para especificar los requisitos de verificación de seguridad de la aplicación en los contratos.

El Proyecto de Guía de Pruebas de Seguridad Web produce el principal recurso de pruebas de seguridad cibernética para desarrolladores de aplicaciones web y profesionales de seguridad.

Es una guía completa para probar la seguridad de las aplicaciones web y los servicios web. Creado por los esfuerzos de colaboración de profesionales de ciberseguridad y voluntarios dedicados, proporciona un marco de las mejores prácticas utilizadas por los probadores de penetración y las organizaciones de todo el mundo.

Principales vulnerabilidades

OWASP establece y explica las diez vulnerabilidades más importantes que pueden aparecer en un sitio web.

Los atacantes pueden usar diferentes rutas a través de la aplicación de un negocio para causar importantes daños al mismo.

El riesgo total para una empresa viene dado por la unión de:

• La probabilidad asociada con cada agente de amenaza
• Vector de ataque
• Debilidad de seguridad
• Estimación del impacto técnico
• Estimación del impacto para el negocio

Cada aplicación y cada empresa son diferentes por lo que habrá que evaluar el riesgo en cada caso enfocándonos en:

• Agentes amenazantes
• Controles de seguridad
• Impacto de negocio

Las diez vulnerabilidades más importantes y comunes de las aplicaciones web son:

Inyección SQL

Esto ocurre cuando la aplicación envía datos no confiables a un intérprete. Estas son fáciles de descubrir cuando se examina el código, pero más difíciles mediante test de intrusiones. Las aplicaciones más susceptibles de sufrir inyecciones son las diseñadas de forma pobre y que carecen de validación de entradas. Pero, no es solo código lo que puede inyectarse en una aplicación web. También pueden detectarse llamadas al sistema que usen órdenes de comandos para ejecutar procesos e inyectar peticiones de ejecución de otros procesos.

Secuencia de comandos en sitios cruzados (XSS)

Esto se produce cuando la aplicación incluye datos suministrados por el usuario en una página enviada al navegador sin validar apropiadamente el contenido.

Hay tres tipos:

• Almacenados: el código se almacena en una base de datos y se produce cada vez que se recupera la información.
• Reflejados: el código se refleja desde el servidor como mensaje de error o resultado de una petición, pero no se almacena.
• Basados en DOM: el ataque se ejecuta como resultado de la modificación del DOM del entorno del navegador de la víctima. El código se ejecuta de forma inesperada.

Pérdida de autenticación y gestión de sesiones

La autenticación y establecimiento de sesión permite que un usuario se identifique como usuario de la aplicación y sea reconocido como tal por los mecanismos de control de acceso. A menudo estos esquemas de autenticación y gestión de las sesiones contienen vulnerabilidades en las secciones de:

• Cierre de sesión
• Gestión de contraseñas
• Tiempo de desconexión
• Función de recordar contraseña
• Pregunta secreta
• Actualización de la cuenta

Puede ser difícil encontrar estas vulnerabilidades. Por ejemplo, si un sistema permite cambiar la clave con una función de recuperar contraseña, un usuario no legítimo podría usar esa función para hacerse pasar por usuario legítimo de la aplicación.

Es necesario proveer un par de atributos (usuario y contraseña) que identifiquen únicamente al usuario. Mediante entradas no validadas es posible conseguir el acceso sin conocer ninguno de esos dos atributos para la autenticación.

Si las credenciales de autenticación, identificación y sesión no se protegen mediante técnicas de cifrado, un usuario malintencionado podría suplantar la identidad del usuario legítimo.

Referencia directa insegura a objetos

Las aplicaciones comprueban siempre que el usuario disponga de permisos sobre el objetivo. Un análisis de código mostraría si la autorización se verifica correctamente.

Para prevenir las referencias inseguras a objetos directos debe seleccionarse una forma de proteger el acceso:

• Usar referencias indirectas por usuario o sesión: esto impediría el acceso a recursos no autorizados directamente por los atacantes.
• Comprobar el acceso: debe asegurarse que el usuario está autorizado para acceder al objeto solicitado.

Falsificación de peticiones en sitios cruzados

Cuando los navegadores envían credenciales de autenticación automáticamente, como en el caso de las cookies de sesión, los atacantes pueden crear páginas web que generan peticiones falsas indistinguibles de las auténticas.

La forma más sencilla de revisar la vulnerabilidad en una aplicación es verificar si cada enlace y formulario contiene un testigo (token) no predecible para cada usuario. Si no lo tiene, los atacantes pueden falsificar peticiones.

El análisis debe realizarse en enlaces y formularios que invoquen funciones que permitan cambiar estados. Estos son los principales objetivos de los ataques.

Configuración de seguridad defectuosa

Una aplicación puede ser segura pero pueden encontrarse problemas de seguridad en ella debido a una configuración deficiente del servidor. Debemos cuestionar los siguientes aspectos de seguridad en el servidor:

• Errores de seguridad no parcheados en el software del servidor.
• Errores de seguridad en el software del servidor o malas configuraciones que permiten ataques de listado de directorio.
• Existencia de archivos por defecto, de respaldo o de ejemplo.
• Permisos inadecuados en archivos y directorios.
• Servicios innecesarios habilitados, como manejo de contenido y administración remota.
• Cuentas por defecto con contraseñas por defecto.
• Funciones administrativas o de depuración habilitadas o accesibles.
• Mensajes de error demasiado informativos.
• Certificados SSL y opciones de encriptación mal configurados.
• Uso de certificados auto firmados para la autenticación.
• Uso de certificados por defecto.
• Autenticación inadecuada con sistemas externos.

Almacenamiento criptográfico inseguro

En muchas aplicaciones es necesario almacenar información con seguridad. Para ello, se recurre a bases de datos u otros soportes usando en muchos casos técnicas de cifrado. Pero se cometen errores al aplicar esas técnicas de cifrado.

Las áreas donde los errores son más comunes son:

• Al cifrar la información esencial
• Almacenamiento inseguro de claves, certificados y contraseñas
• Almacenamiento incorrecto de secretos en memoria
• Fuentes pobres de aleatorización
• Elección pobre de algoritmo
• Inventar el nuevo algoritmo de encriptación
• Fallo al incluir soporte para cambios en las claves de encriptación y otros procedimientos de mantenimiento requeridos.

La encriptación se utiliza para proteger los activos más sensibles del sitio, que pueden ser comprometidos por una debilidad.

Para protegernos de ese problema, debemos:

• Identificar las amenazas existentes y asegurar que los datos están cifrados de forma que se defiendan de las amenazas.
• Asegurarnos de que las copias de seguridad almacenadas externamente están cifradas, con las claves gestionadas y almacenadas de forma separada.
• Asegurarnos del uso adecuado de algoritmos y claves fuertes.
• Garantizar que las contraseñas se almacenan en forma de hash con un algoritmo estándar robusto.
• Garantizar que todas las claves y contraseñs son protegidas contra accesos no autorizados.

Fallo de restricción de acceso a URL

Control de acceso es el mecanismo que, una vez autenticado el usuario, decide si puede acceder o no a un conjunto de información o si puede realizar determinadas tareas.

Los desarrolladores tienden a menospreciar la dificultad en la creación de los controles de acceso. Incluso, en muchas ocasiones, se crean como un aspecto evolutivo de la propia aplicación, sin un plan de implantación fuerte.

Una vez obtenido un error en la validación de permisos, se pueden realizar operaciones para las que no se ha dado permiso: borrar o añadir información e incluso tomar el control administrativo de la aplicación.

Para evitar esto se recomienda:

• Basar la autenticación y la autorización en roles para minimizar el esfuerzo necesario para mantener esas políticas.
• Las políticas deben ser configurables.
• Debe negarse por defecto todo acceso, y requerir el establecimiento explícito de permisos a usuarios y roles por cada página.
• Si la página forma parte de un proceso de varios pasos, debe verificarse que las condiciones de la misma se encuentren en el estado apropiado para permitir el acceso.

Protección insuficiente en la capa de transporte

Un problema muy común en los sitios web es que usan HTTPS para la autentificación y luego continúan el resto de navegación mediante HTTP.

En otros casos, aunque la web realiza toda la comunicación vía HTTPS, responde igualmente si las peticiones se le realizan mediante HTTP. Esto permite ataques Man in The Middle.

La mejor forma de averiguar si una aplicación se encuentra protegida es comprobar si:

• Se utiliza SSL para proteger la aplicación.
• Se sigue usando SSL para todos los recursos de páginas y servicios privados.
• Solo se aportan algoritmos considerados fuertes.
• Todas las cookies de sesión tiene el atributo secure activado.
• El certificado del servidor es legítimo y está correctamente configurado para ese servidor. Para ello debe:
  • Emitirse por una entidad autorizada
  • No haber expirado
  • No haber sido revocado
• Se ajusta a todos los dominios utilizados por la aplicación.
• El servidor no admite conexiones sin SSL para los recursos privados.
• El servidor tiene implantada la política HSTS que obliga a los navegadores a comunicarse con el servidor exclusivamente mediante HTTPS.

Redirecciones y reenvíos no validados

Las aplicaciones redirigen a los usuarios a otras páginas. Detectar redirecciones sin validar es fácil. Es necesario buscar redirecciones donde el usuario puede establecer la dirección URL completa.

Existen diversas maneras para efectuar un uso seguro de redirecciones y reenvíos:

• Evitando el uso de redirecciones y reenvíos.
• Si usamos no involucrar parámetros manipulables por el usuario.
• Si los parámetros de destino no pueden evitarse, comprueba el valor facilitado y que el usuario esté autorizado.
• Se recomienda que el valor de cualquier parámetro de destino sea un valor de mapeo, en lugar de la dirección real y traducir en el servidor el destino real.

Otros problemas de seguridad

Aparte de los analizados anteriormente, existen otros problemas de seguridad importantes y extendidos en la actualidad.

Entradas no validadas

Las aplicaciones web usan como medio de interacción con los usuarios diferentes tipos de peticiones HTTP para presentar la información deseada o realizar las operaciones para las que fueron diseñadas.

Un atacante puede modificar cualquier elemento de las peticiones HTTP para burlar los mecanismos de seguridad implementados por los sitios.

La no comprobación de las entradas a una aplicación web ha originado distintos tipos de ataques:

• Navegación forzada
• Inserción de comandos
• Cross Site Scripting
• Desbordamientos de buffer
• Ataques de formato de cadena de caracteres
• Inyección SQL
• Manipulación de cookies y campos escondidos.

La validación de entradas debe realizarse en el formato más sencillo que podamos manejar. Es necesario decodificar las peticiones completamente antes de aplicar los filtros pertinentes.

Una aplicación robusta debe validar todas las entradas que recibe antes de procesarlas para trabajar con ellas.

Toda entrada debería ser validada contra un patrón que permita el paso y compruebe los siguientes atributos:

• Tipos de datos
• Conjunto de caracteres permitidos
• Longitud mínima y máxima
• Si nulo es permitido
• Se requiere el parámetro o no
• Si los duplicados son permitidos
• El rango numérico
• Valores específicos permitidos
• Patrones específicos

Manejo incorrecto de errores

Esto causa que, cuando un usuario ilegítimo de la aplicación intente forzar un fallo, reciba excesivos detalles de la implementación de la aplicación y pueda hacerse una idea más detallada de esa implementación para poder perfilar mejor su ataque.

Una gestión efectiva de errores debe informar de los errores detalladamente a los desarrolladores o a los encargados de mantener la aplicación. Y no revelar nunca ningún dato al usuario de la misma.

La gestión de errores no solo debe limitarse a informar al usuario del error, sino que debe registrarlo. No solo debe reflejar las entradas erróneas de los usuarios, sino que debe registrar también cualquier otra función interna que realice la aplicación.

Denegación de servicios

Una aplicación web puede presentar problemas a la hora de atender todas las peticiones de sus usuarios.

En condiciones normales, un servidor web es capaz de atender las peticiones de varios cientos de usuarios. Sin embargo, un usuario malintencionado puede ser capaz de dificultar el acceso a una aplicación mediante un consumo desmesurado de recursos.

Un ataque de denegación de servicio aprovecha las políticas de bloqueo de cuentas de una aplicación para introducir intencionadamente credenciales falsas de usuarios, con la intención de forzar el bloqueo de una cuenta.

¿Por dónde empezar a aplicar seguridad?

Las aplicaciones web poseen dos categorías diferentes:

• Vulnerabilidades de la plataforma donde se encuentra la aplicación: Sistema operativo, servidores y base de datos.
• Vulnerabilidades propias de la aplicación: errores de programación o de diseño.

Hay aplicaciones para verificar esas vulnerabilidad y también para explotarlas. Muchos de los errores pueden ser explotados por cualquier persona sin conocimientos en la materia.

Cualquier analizador de vulnerabilidades que podamos ejecutar en nuestros sistemas es capaz de revelar información sobre nuestros servidores e incluso existen analizadores diseñados para auditar automáticamente ese servicio.

El servidor nos proporciona excesiva información sobre su configuración y pueden obtenerse algunos archivos y directorios interesantes para un atacante.

Las medidas básicas para conseguir una mínima seguridad son:

• Eliminar cualquier directorio, CGI o ejemplo instalado por defecto. Algunos CGIs y programas de ejemplos incorporan funciones que no son necesarias para el correcto funcionamiento del software y abren enormes agujeros de seguridad:
  • Acceso al código fuente de algunos archivos
  • Lectura de ficheros fuera de directorio raíz
  • Ejecución remota de comandos bajo la identidad del usuario con que se ejecuta el servidor.
• Deshabilitar el listado de directorio. Muchos servidores, cuando no saben qué fichero mostrar al usuario, muestran los que existen en el directorio activo. Todo lo que esté bajo el documento base del servidor ha de ser público, ya que para eso se ubica ahí. Entre los ficheros de cualquier servidor podemos encontrar:
  • Archivos de log del cliente FTP que los usuarios usan para actualizar sus páginas remotamente.
  • Ficheros de backup con el contenido de subdirectorios completos.
• Usuario que ejecuta el servidor. Ese usuario no debe ser nunca el administrador del sistema, pero tampoco un usuario genérico. Debe ser un usuario dedicado y sin acceso real al sistema. Además, las páginas HTML nunca deben ser de su propiedad ni debe tener permiso de escritura sobre ellas. Si el usuario que ejecuta el servidor puede escribir en las páginas web y un pirata consigue, a través de cualquier tipo de error, ejecutar órdenes bajo la identidad de dicho usuario, podrá modificar las páginas web sin ningún problema.

Perfilado de la aplicación web

El perfilado de una aplicación web consiste en descargar toda la web que queremos auditar, usando para ello software de descarga masiva.

Una vez finalizado el proceso, tendremos el árbol de directorios de la web en nuestra propia máquina y podremos examinarlos con calma.

Metodología de ataque

Debemos examinar los ficheros en busca de determinadas características que permitan aplicar alguna de las siguientes técnicas:

• Hidden manipulation
• Cookie poisoning
• Backdoor and debug options
• Buffer overflow
• Problemas de configuración
• Vulnerabilidades conocidas
• Parameter tampering

Analicemos cada una de ellas.

Hidden Manipulation

Consiste en manipular los valores que se guardan en un formulario web, que además de ser visibles, no ofrecen ninguna protección contra modificaciones. Por eso es una mala idea usarlo para obtener seguridad.

Podemos acceder a ellos mirando el código fuente de la página web y manipularlos de diversas maneras:

• Descargando el código fuente a nuestra máquina, modificando ese importe y pinchando el botón que hace el post.
• Mediante el uso de un proxy podemos recoger la petición HTTP originada hacia el servidor y modificar a nuestro gusto los parámetros post de la misma.

Cookie poisoning

Consiste en manipular valores que se guardan en cookies del navegador que cualquiera puede ver y manipular.

Al almacenarse las cookies en nuestra máquina, tenemos acceso a ellas y podemos modificiarlas a nuestro antojo.

Parameter tampering

Si, tras el proceso de autenticación, todas las actividades se llevan a cabo basándose en la ID del usuario, este parámetro se envía en un formulario que es fácilmente modificable.

Backdoor y debug options

Aplicaciones con opciones ocultas o utilidades usadas durante el desarrollo de las mismas por los implementadores y que olvidaron eliminar.

Buffer overflow

Consiste en enviar más datos de los que la aplicación espera recibir y conseguir que esta falle.

Problemas de configuración

El problema es de las instalaciones o configuraciones por defecto de software popular. Accedemos al panel de control de una base de datos en la que no necesitamos autentificarnos.

Vulnerabilidades conocidas

Los programas tienen errores. Si nuestra máquina no está actualizada, alguien que conozca qué hemos instalado, puede averiguar fácilmente cómo atacar.