Introduccion Seguridad en Aplicaciones Online

Seguridad en Aplicaciones Online

Material Complementario

Índice

© Universidad Internacional de La Rioja (UNIR)

Ideas clave

3

1.1. Introducción y objetivos

3

1.2. Arquitecturas de las Aplicaciones Online

7

1.3. Protocolo HTTP

12

1.4. Tipos de Vulnerabilidades

17

1.5. Listas oficiales de vulnerabilidades

23

1.6. OWASP Top Ten

24

1.7. Referencias bibliográficas

27

A fondo

29

Ideas clave

1.1. Introducción y objetivos Esta asignatura estudia las medidas de seguridad que son necesarias para implementar la seguridad de las aplicaciones web para que una vez desplegadas online, se comporten de la forma esperada, tanto por los propietarios como por parte de los usuarios de la aplicación y puedan mitigar cualquier ataque.

Las vulnerabilidades de las aplicaciones son debilidades en un sistema que los atacantes pueden aprovechar para obtener alguna ventaja poniendo en peligro los objetivos de seguridad antes mencionados. En el contexto de la seguridad del software las vulnerabilidades son defectos o descuidos específicos en una parte del software. Estos descuidos permiten que los atacantes hagan algo malicioso o que alteren información sensible o que interrumpan o destruyan un sistema o tomar el control de un sistema informático o de un programa. Son errores o descuidos en los programas que dan lugar a un comportamiento inesperado y típicamente indeseable.

Se puede afirmar que para que un ataque aproveche una vulnerabilidad (debilidad en el diseño, código, configuración, protección online de una aplicación) y se materialice en una aplicación generando un impacto de negocio para la organización

© Universidad Internacional de La Rioja (UNIR)

es necesario que intervengan una serie de factores (ver figura 1):

▸ Agente o amenaza: es la persona que realiza el ataque. ▸ Vectores de ataque: medio del que se sirve para llevar a cabo el ataque. ▸ Debilidad: vulnerabilidad de seguridad. ▸ Ausencia o fallo en el control. ▸ Impacto en algún activo de los sistemas de información de la organización.

Seguridad en Aplicaciones Online Material Complementario

3

▸ Impacto en el negocio de la organización.

Figura 1. Materialización de una amenaza: ataque. Fuente: https://wiki.owasp.org/images/5/5e/OWASPTop-10-2017-es.pdf

Las principales vulnerabilidades de seguridad que pueden impedir los objetivos anteriormente citados que las aplicaciones pueden sufrir tienen su origen en las deficiencias y fallos que se produjeron en cada una de las fases del ciclo de vida de desarrollo de software.

Las clases de vulnerabilidades comúnmente aceptadas incluyen vulnerabilidades de diseño, implementación y vulnerabilidades operacionales:

▸ Vulnerabilidades de seguridad en el diseño: por ejemplo, vulnerabilidades funcionales de seguridad como autorización, control de accesos, etc. ▸ Vulnerabilidades de seguridad en el código debidas a fallos de seguridad en la implementación. ▸ Vulnerabilidades de seguridad en la operación debidos a fallos de

© Universidad Internacional de La Rioja (UNIR)

configuración, una vez desplegada la aplicación.

Por tal motivo es necesario convertir el ciclo de vida de desarrollo de aplicaciones en un ciclo de vida de desarrollo seguro (SSDLC). Cuanto más se tarde en solucionar una vulnerabilidad del tipo que sea mayor será el coste de dicha solución. En la figura siguiente se puede observar cómo aumenta el coste con el tiempo de la reparación de una vulnerabilidad según la fase o etapa en que se acomete.

Seguridad en Aplicaciones Online Material Complementario

4

Incremento del coste

Cost

Time Figura 2. Incremento de coste. Fuente: Graff, M. (2001)

Se puede observar que las clases de vulnerabilidades se producen en las fases del de un ciclo de vida de desarrollo de Software.

La derivación de requisitos de seguridad y análisis de las distintas posibilidades de diseño de la arquitectura de las aplicaciones web es el punto de partida en la construcción de una aplicación web. La arquitectura elegida ha de ser la más adecuada y estar diseñada en función de los requisitos de seguridad de una aplicación web. En la fase de análisis de requisitos y en la fase de diseño del ciclo de vida de desarrollo de software y sistemas se derivan los requisitos de seguridad de la © Universidad Internacional de La Rioja (UNIR)

aplicación y en función de estos se define la arquitectura más adecuada para cumplir con el objetivo de seguridad. Todas las partes a desarrollar en una aplicación web (y cualquier otro tipo de software) tienen que diseñarse pensando en la seguridad desde las fases más tempranas del SSDLC.

Seguridad en Aplicaciones Online Material Complementario

5

Aprovechando cualquier tipo de vulnerabilidad pueden darse ataques de diversos tipos según (Sołtysik-Piorunkiewicz et al. 2020):

▸ Stealing Passwords. ▸ Sql injection. ▸ Cross Site Scripting. ▸ Social Engineering. ▸ Bugs and Back Doors. ▸ Authentication Failures. ▸ Protocol Failures. ▸ Information Leakage. ▸ Exponential Attacks Viruses and Worms. ▸ Denial-of-Service Attacks. ▸ Botnets. ▸ Active Attacks. ▸ …

En sentido general un ataque contra un sistema es cualquier acto malévolo previsto contra un sistema o un conjunto de sistemas. Hay dos conceptos muy importantes en esta definición que merece la pena precisar. Primero decimos solamente que el acto está realizado con intención malévola, sin especificar ningunas metas u objetivos. En segundo lugar, algunos ataques se dirigen a un sistema particular, mientras que otros no tienen ningún objetivo en particular. Los ataques pueden ser debidos a defectos, que pueden tener lugar en cualquiera de las fases del ciclo de

© Universidad Internacional de La Rioja (UNIR)

vida de desarrollo del software y sistemas

Objetivos Los principales objetivos de este tema son los siguientes:

▸ Conocer los principales arquitecturas y tecnologías de aplicaciones web. ▸ Repasar la arquitectura y métodos del protocolo HTTP.

Seguridad en Aplicaciones Online Material Complementario

6

▸ Conocer los principales tipos de vulnerabilidades de seguridad y ataques a que dan lugar. ▸ Conocer las principales listas oficiales de categorías de vulnerabilidades y ataques.

Los objetivos de seguridad a alcanzar en los sistemas de información y comunicaciones TIC pasan por:

▸ Identificar a las personas que acceden a la información manejada por un sistema o a los recursos del mismo. ▸ Autenticar a las personas que acceden a la información manejada por un sistema o a los recursos del mismo. ▸ Controlar el acceso a la información manejada por un sistema o a los recursos del mismo. ▸ Proporcionar confidencialidad a la información manejada por un sistema. ▸ Proporcionar integridad a la información manejada por un sistema o a los recursos del mismo. ▸ Mantener la disponibilidad de la información manejada por un sistema o de los recursos del mismo. ▸ No repudio. Proporcionar la prueba de que una determinada transmisión o recepción ha sido realizada, no pudiendo su receptor/transmisor negar que se haya producido. ▸ Trazabilidad. Proporcionar los controles que determinen que en todo momento se podrá determinar quién hizo qué y en qué momento.

© Universidad Internacional de La Rioja (UNIR)

1.2. Arquitecturas de las Aplicaciones Online El extraordinario éxito del modelo Web puede atribuirse a una característica fundamental: es un modelo más débilmente acoplado que los modelos de programación distribuida tradicionales como RPC, RMI, DCOM y CORBA. Las interacciones entre clientes y servidores Web son sencillas: intercambian mensajes que transportan datos de tipo MIME, y la semántica de un mensaje puede modificarse utilizando cabeceras. El

Seguridad en Aplicaciones Online Material Complementario

7

destino de un mensaje se especifica indirectamente utilizando una URL, y este nivel de indirección puede aprovecharse para implementar balance de carga, seguimiento de sesiones y otras funcionalidades.

Las arquitecturas monolíticas son las que utilizan normalmente cuando se desarrolla la aplicación mediante un lenguaje de script como Coldfusion o PHP alojada en un servidor web.

Cuando se necesita una aplicación escalable y que ofrezca mayor rendimiento y seguridad se ha de recurrir a una de las opciones de desarrollo empresarial como las analizadas anteriormente: .Net o J2EE (Padilla and Pérez, 2010). Estas especificaciones proporcionarán mayores posibilidades debidas a las distintas opciones de configuración e implementación de la seguridad que ofrecen como puede ser la utilización de lenguajes más seguros potencialmente como java o C#.

Una arquitectura de aplicación escalable normalmente se divide en niveles y si se utilizan patrones de diseño muchas veces se dividen en porciones reutilizables usando diferentes lineamientos específicos para reforzar su modularidad, requerimientos de interface y la reutilización de objetos. Además, dividir la aplicación en niveles permite que la aplicación se pueda distribuir entre varios servidores mejorando por lo tanto la escalabilidad de la aplicación a expensas de mayor complejidad con controles de acceso y detección avanzados. Existe separación de tareas y responsabilidades.

Arquitectura de aplicación web clásica

© Universidad Internacional de La Rioja (UNIR)

Las capas de que se compone una aplicación web en una arquitectura clásica son:

▸ Capa cliente: Navegador web (Internet Explorer, Chrome, etc.). ▸ Capa de aplicación: servidor de aplicación (weblogic, tomcat, websphere, struts, .NET, coldfusion, etc.). Contiene la lógica de negocio y de presentación. Puede incluir un servidor web para alojar contenido estático y/o aplicación desarrollada con lenguajes interpretados (Apache). Seguridad en Aplicaciones Online Material Complementario

8

▸ Capa de persistencia: Servidor gestor de base de datos (Oracle, MS SQL Server, MySQL, PostgreSQL, etc). ▸ Comunicación. Se lleva a cabo mediante el protocolo HTTP/1.1/2.0. El navegador realiza peticiones y el

servidor

envía las respuestas

correspondientes. Cada petición y su respuesta contienen una parte de cabeceras y otra correspondiente al cuerpo de la petición o respuesta.

Servidor aplicaciones

Servidor base de datos

Aplicación

Navegador

Gestión de sesiones

Seguridad usuario

Seguridad Conexión

Seguridad Conexión

LOPD LSSICE

Autorización

Figura 2. Arquitectura de 3 capas de aplicaciones web.

Arquitectura de aplicaciones RIA Las tecnologías que se usan en las arquitecturas de Aplicaciones Ricas de Internet (RIA) se incluyen en el término AJAX (Asynchronous Javascript and XML), AJAX es un conjunto de tecnologías que incluyen javascript asíncrono junto con XML, XSLT, XHTML, y DOM (Document Obect Model) tecnologías todas ellas ampliamente

© Universidad Internacional de La Rioja (UNIR)

difundidas y utilizadas.

El objetivo principal de las aplicaciones AJAX, es eliminar la naturaleza start-stopstart-stop de la interacción entre el cliente y el servidor de aplicaciones web introduciendo un intermediario: un motor AJAX/JS entre el usuario y el servidor, que intercambia información con el servidor en el backend sin que el usuario lo perciba (como ocurre en la arquitectura web tradicional síncrona):

Seguridad en Aplicaciones Online Material Complementario

9

Figura 3. Modelo de comunicación síncrono. Fuente: https://www.ques10.com/p/29472/explain-in-detail-ajax-web-application-model-wit-1/

Este elemento arquitectónico adicional del lado cliente, es lo más característico de AJAX, y tendrá algún inconveniente de seguridad, como veremos más adelante. El navegador, cargará el motor Ajax usualmente escondido en un frame oculto, y éste será responsable de procesamiento tanto de la interfaz que el usuario ve, como de la comunicación con el servidor en nombre del usuario. Permitirá la interacción del usuario con la aplicación de forma asincrónica independientemente de la

© Universidad Internacional de La Rioja (UNIR)

comunicación con el servidor:

Figura 4. Modelo de comunicación asíncrono (AJAX). Fuente: https://www.ques10.com/p/29472/explain-in-detail-ajax-web-application-model-wit-1/

De esta forma, el usuario no queda esperando la respuesta del servidor, que tiene la percepción de que no hay tiempos de recarga. Los toolkits AJAX, han permitido a los desarrolladores web construir aplicaciones web 2.0 de forma rápida y relativamente

Seguridad en Aplicaciones Online Material Complementario

10

poco esfuerzo, generando un nuevo nivel de interactividad con los usuarios, como el que otorga por ejemplo Google Maps, Google Docs, Flickr… arquitectura en sí, se observa en la figura 7.

En cuanto a la

Cada acción del usuario que

normalmente generaría una petición HTTP se convierte en una llamada JS al motor AJAX en su lugar. Cualquier respuesta a una acción del usuario que no requiere un viaje de vuelta al servidor, tales como la validación de datos simple, edición de datos en la memoria, e incluso un poco de navegación: el motor se encarga por sí solo de servir el código HTML, CSS y JS. Si el motor necesita algo del servidor con el fin de responder al cliente web, se encarga de realizar esas peticiones de forma asíncrona (HTTP request), normalmente, usando XML, de modo transparente y sin penalizar a

© Universidad Internacional de La Rioja (UNIR)

priori la experiencia del usuario del navegador (Asadullah et al. 2013; AJAX, 2020).

Figura 5. Modelo de aplicación AJAX web Fuente: https://www.ques10.com/p/29472/explain-in-detail-ajax-web-application-model-wit-1/

Seguridad en Aplicaciones Online Material Complementario

11

1.3. Protocolo HTTP El protocolo HTTP no fue diseñado para aplicaciones y seguramente no para usos seguros. HTTP crea oportunidades para tener vulnerabilidades de seguridad de la misma manera que en las funciones de string de la biblioteca estándar de C crean oportunidades para el desbordamiento de buffer: Los programadores tienen que aprender a desarrollar de forma segura.

El protocolo HTTP implementa una serie de métodos especificados en HTTP 1.1 rfc 2616 (HTTP 1.1, 2020), son los siguientes:

▸ HEAD: pide una respuesta idéntica a la que correspondería a una petición GET pero sin el cuerpo de la respuesta. Esto es útil para la recuperación de metainformación escrita en los encabezados de respuesta, sin tener que transportar todo el contenido.

▸ GET: pide una representación del recurso especificado. Por seguridad no debería ser usado por aplicaciones que causen efectos ya que transmite información a través de la URI agregando parámetros a la URL.

Ejemplo: GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png. Ejemplo con parámetros: GET /index.php?page=main&lang=es

▸ POST: envía los datos para que sean procesados por el recurso identificado (url). Los datos se incluirán en el cuerpo de la petición. Esto puede resultar en © Universidad Internacional de La Rioja (UNIR)

la creación de un nuevo recurso o de las actualizaciones de los recursos existentes o ambas cosas.

▸ PUT: sube, carga o realiza un upload de un recurso especificado (archivo). Es el camino más eficiente para subir archivos a un servidor. Esto es porque en POST utiliza un mensaje multiparte y el mensaje es decodificado por el

Seguridad en Aplicaciones Online Material Complementario

12

servidor. En contraste, el método PUT te permite escribir un archivo en una conexión socket establecida con el servidor. La desventaja del método PUT es que los servidores de hosting compartido no lo tienen habilitado.

Ejemplo: PUT /path/filename.html HTTP/1.1

▸ DELETE: borra el recurso especificado.

▸ TRACE: este método solicita al servidor que envíe de vuelta en un mensaje de respuesta. Se utiliza con fines de comprobación y diagnóstico. El método trace da lugar a la vulnerabilidad Cross Site Tracing (XST) debido a que copia las cabeceras de la petición en el cuerpo de la respuesta haciendo inútil la protección mediante el parámetro HTTPONLY (ver tema 2) que impide acceso a la cookie que protege. XST se puede combinar con un ataque XSS para robo

© Universidad Internacional de La Rioja (UNIR)

de un identificador de sesión contenido en una cookie.

Seguridad en Aplicaciones Online Material Complementario

13

Figura 6. XST Fuente: https://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf

▸ OPTIONS: devuelve los métodos HTTP que el servidor soporta para un URL específico. Este método puede ser utilizado para comprobar la funcionalidad de un servidor web.

▸ CONNECT: se utiliza para saber si se tiene acceso a un host no necesariamente la petición llega al servidor. Este método se utiliza principalmente para saber si un proxy nos da acceso a un host.

© Universidad Internacional de La Rioja (UNIR)

En la siguiente figura se observa cómo se puede especificar un método http.

Figura 7. Métodos http

Seguridad en Aplicaciones Online Material Complementario

14

En una petición GET los parámetros que se incluyen en la cadena de la URL pueden ser rutinariamente escritos a LOG,s cache del navegador y almacenados en el historial del navegador revelando información sensible como passwords, etc. Es más sencillo prevenir XSS deshabilitando GET en las aplicaciones. Es más fácil para un atacante enviando emails con una URL con parámetros maliciosos:

Figura 8. Método HTTP GET

Sin embargo, con el método POST los parámetros se especifican en el cuerpo de la petición. Siendo más seguro se debe de utilizar POST en lugar de GET:

Figura 9. Método HTTP POST

Procedencia de peticiones: si la aplicación usa un identificador de sesión (cookie) con

© Universidad Internacional de La Rioja (UNIR)

un formulario (administración) para crear un usuario:

Figura 10. Procedencia de peticiones CSRF

Un atacante podría tener un sitio web con:

Seguridad en Aplicaciones Online Material Complementario

15

Figura 11. Procedencia de peticiones CSRF

Si el administrador visita el sitio controlado por el atacante se puede dar un ataque Cross site request forguery (CSRF). Para prevenirlo se puede incluir algún campo que la aplicación pueda validar:

Figura 12. Procedencia de peticiones. Protección CSRF

Otras vulnerabilidades que se pueden presentar en el protocolo HTTP es la vulnerabilidad http response spliting que consiste en incluir caracteres \r\n de retorno

de

carro

y

de

línea

para

generar

una

respuesta

doble

(https://www.acunetix.com/websitesecurity/crlf-injection/) que se ejecutarán en el navegador del usuario permitiendo lanzar otros ataques como XSS:

© Universidad Internacional de La Rioja (UNIR)

Figura 13. HTTP Response Splitting

Si el atacante suministra una cadena como Wiley Hacker\r\n\r\nHTTP/1.1 200 OK\r\n..., la respuesta se convierte en doble permitiendo inyectar código HTML:

Seguridad en Aplicaciones Online Material Complementario

16

Figura 14. HTTP Response Splitting

El problema del protocolo HTTP es más agudo cuando se maneja el estado de sesión que es necesario en la mayor parte de aplicaciones porque el protocolo en sí mismo es sin estado. Como HTTP es sin estado, construir casi cualquier tipo de aplicación sofisticada requiere un identificador de sesión que sirva para ambos sentidos de la comunicación para asociar las peticiones previas de un usuario con las siguientes. Los identificadores de sesión pueden ser pasados hacia adelante y hacia atrás como parámetros URL pero hoy la mayor parte de las aplicaciones manejan cookies, que es un mecanismo que el protocolo incorporó posteriormente para almacenar datos en la memoria del navegador con un espacio de 4096 bytes. La razón más común de usar un identificador de sesión es permitir a un usuario autenticarse solo una vez para continuar con una serie de interacciones con la aplicación. Se puede utilizar una cookie, además de otros métodos, una cookie para almacenar el identificador de sesión.

Esto quiere decir que la seguridad de la aplicación depende de ello y debe ser muy difícil para un atacante averiguar u obtener el identificador de sesión para un usuario autenticado. Una buena gestión de sesión HTTP escoge identificadores de sesión fuertes y se asegura de que son publicados y revocados en puntos apropiados en el programa. Es importante tener en cuenta los puntos siguientes:

© Universidad Internacional de La Rioja (UNIR)

1.4. Tipos de Vulnerabilidades Las clases de vulnerabilidades comúnmente aceptadas incluyen vulnerabilidades de diseño, implementación y vulnerabilidades operacionales.

Seguridad en Aplicaciones Online Material Complementario

17

Vulnerabilidades de diseño Las vulnerabilidades de diseño de una aplicación web se producen durante las fases de análisis y diseño del ciclo de vida de desarrollo. Cualquier ausencia, deficiencia o debilidad de algún requisito de seguridad será una vulnerabilidad de diseño en la aplicación web aprovechable por cualquier atacante. Ejemplos de vulnerabilidades de diseño son: ▸ Uso de protocolos de cifrado de comunicación obsoletos o no actualizados, SSL 2.0, 3.0; etc. ▸ Uso de métodos de autenticación inseguros del protocolo HTTP, como Basic o débilmente configurados que permiten ataques de fuerza bruta o de captura de credenciales. ▸ Identificador de sesión no protegido frente a ataques de repetición, adivinación, etc. ▸ Diseño inseguro de la lista o matriz de control de accesos de la aplicación que especifica los permisos que los usuarios y grupos de la aplicación tienen sobre los recursos de la aplicación. ▸ Vulnerabilidades en la política de gestión de contraseñas, servicio de PKI para gestión de certificados digitales. ▸ Vulnerabilidades en el diseño de los procedimientos de backup y recuperación. Se debe contar con un centro de respaldo que proporcione el grado de redundancia necesario de forma transparente para los usuarios. ▸ Vulnerabilidades en el diseño del proceso de respuesta ante incidentes de seguridad. Se debe contar con un centro de respuesta ante incidentes de seguridad. ▸ Vulnerabilidades en el diseño la seguridad física, seguridad del personal y de

© Universidad Internacional de La Rioja (UNIR)

la documentación. La seguridad relativa al personal debe estar clasificada en niveles de acuerdo con su puesto y la «necesidad de conocer» que tenga en función de aquel. Igualmente la información y sus sistemas deben tener distintos niveles de clasificación. Una persona podrá acceder a un documento o a un sistema si tiene el grado de clasificación requerido para acceder al documento con un determinado grado de clasificación y si tiene la necesidad de conocer la información contenida en el documento o en el sistema. Seguridad en Aplicaciones Online Material Complementario

18

Vulnerabilidades de implementación Las principales vulnerabilidades de seguridad en la implementación en las aplicaciones son: ▸ Vulnerabilidades de implementación en la validación de la entrada en el código del lado del servidor. Ejemplos de este tipo de vulnerabilidades que se pueden consultar en Mitre CWE2015 son: sql injection, cross site request forgery, path traversal, http response splitting o remote file inclusión. ▸ Vulnerabilidades de implementación de la validación de la entrada y de la salida en el código del lado de cliente (acceso al DOM) y del servidor en aplicaciones web 2.0 de cliente enriquecido que utilizan motor AJAX. Json Hijacking (CAPEC 111) 2015, es una de las vulnerabilidades específicas de las aplicaciones AJAX que utilizan JSON (JSON, 2020). ▸ Vulnerabilidades de implementación de la validación de la salida en el código del lado del servidor que pueden causar redirecciones a servidores controlados por el atacante y que estos aprovechan para conseguir acceso a datos personales. XSS es una vulnerabilidad que requiere codificación de la salida para escapar caracteres como . El medio más natural y conveniente para evitar vulnerabilidades en el código de aplicación web es la prevención. Los desarrolladores deberían haber sido formados en la programación de la seguridad web para no cometer errores que implican las vulnerabilidades de programación. No obstante, aunque sea muy buena la formación de los programadores siempre quedarán vulnerabilidades en el código como SQLI, XSS o CSRF y si existen vulnerabilidades, una vez desarrollada la primera versión de

© Universidad Internacional de La Rioja (UNIR)

la aplicación, el coste de eliminarlas es muy alto.

La formación en seguridad de los programadores pasa por realizar validación de campos de entrada y de salida del código para evitar cadenas de datos malignas que puedan constituir un payload y llegar a materializar un ataque real a la aplicación aprovechando una vulnerabilidad.

Seguridad en Aplicaciones Online Material Complementario

19

En la fase de implementación del código es necesario realizar la validación de todas las entradas a la aplicación para evitar cadenas de datos con contenidos maliciosos que puedan aprovechar las posibles vulnerabilidades que pueda tener la aplicación, tanto la lógica de negocio como el modelo (se estudia a continuación) o la vista.

También se ha de aplicar validación de las salidas para escapar caracteres que puedan ocasionar redireccionamientos a sitios no deseados y que pueden conducir a la materialización de vulnerabilidades como cross-site-scripting, cross site request forgery, SQLI, etc. Para realizar este tipo de validaciones es necesario conocer técnicas de programación segura (se analizan en otra asignatura) y la naturaleza de las posibles vulnerabilidades que se analizan en un tema posterior y más profundamente en otra asignatura.

Además en esta capa de software hay que aplicar un correcto y seguro servicio de autenticación y autorización para acceso a cualquier recurso de la aplicación o sistema.

Como se verá más adelante, para conseguir una aplicación segura hay que partir de una derivación acertada de los requisitos de seguridad y casos de abuso, siguiendo con el diseño de la seguridad mediante análisis de riesgos, implementación con técnicas de programación segura y posterior revisión de código y por último, aplicar pruebas funcionales, análisis estático y dinámico de seguridad y otras actividades.

Finalmente, por si acaso, se deben aplicar medidas de protección online que también

© Universidad Internacional de La Rioja (UNIR)

tiene que ser diseñada desde el principio del ciclo de vida de desarrollo.

Todos los datos de una petición HTTP han de ser validados. También se pueden modificar cookies, campos ocultos y parámetros post usando un cliente de ataque que permite modificar el aspecto de cualquier petición HTTP (ver figura siguiente). Es importante la elección del framework de desarrollo y utilizar un lenguaje de programación que fuerce la comprobación de tipos y de memoria de forma que su

Seguridad en Aplicaciones Online Material Complementario

20

gestión sea segura. C#,Java, Python, Ruby o dialectos de C como CCured y Cyclone son lenguajes de este tipo.

Figura 15. Cliente de ataque suplantado e interponiéndose a un navegador web

. Se usa el término secure para referirse a lenguajes que automáticamente realizan comprobaciones en tiempo de ejecución para impedir a los programas violar los límites de la memoria asignada. Los lenguajes seguros deben proporcionar dos propiedades para asegurar que los programas respetan los límites de asignación: seguridad de memoria y seguridad de tipo.

La seguridad de memoria es el verdadero objetivo, esto quiere decir que el programa no leerá o escribirá datos fuera de los límites de la memoria asignada. Para alcanzar la seguridad de memoria un lenguaje también debe hacer cumplir la seguridad de tipo de modo que pueda seguir la pista de los límites de asignación de memoria.

© Universidad Internacional de La Rioja (UNIR)

Sin la seguridad de tipo cualquier valor arbitrario podría usarse como una referencia en la memoria. C y C++ son lenguajes inseguros y ampliamente utilizados y por tanto el programador es el responsable de prevenir que las operaciones que manipulan la memoria puedan resultar en desbordamientos de buffer. Las operaciones que conducen a desbordamientos se reducen a un pequeño conjunto. Por ejemplo, Java es un lenguaje esencialmente seguro, según afirma (Long et al. 2014):

Seguridad en Aplicaciones Online Material Complementario

21

▸ No tiene explícita manipulación de punteros. ▸ Los límites de arrays, strings se comprueban automáticamente. ▸ Los intentos de referencias a un objeto null se capturan. ▸ Las operaciones aritméticas están bien definidas. ▸ Se controla el acceso a ficheros, sockets mediante JVM -> security manager.

Vulnerabilidades de operación Las vulnerabilidades en la operación de las aplicaciones pueden ser de varios tipos:

▸ Vulnerabilidades en el desempeño de los procedimientos de monitorización, auditoría y de gestión de logs. Se debe contar con un sistema de gestión de eventos de seguridad que corre con toda la información de ataques a los sistemas de la organización. ▸ Vulnerabilidades debidas a la mala gestión en la seguridad de las configuraciones, de la aplicación, de los servidores de aplicaciones, de gestión de bases de datos, de los sistemas operativos o la gestión de la autorización de acceso de los usuarios a los recursos de la aplicación, servidores y sistemas operativos subyacentes, así como de la gestión segura de las configuraciones de las comunicaciones entre todas las capas de la aplicación. ▸ Vulnerabilidades debidas a la mala gestión de los permisos de los recursos de la aplicación. ▸ Vulnerabilidades debidas a la mala gestión los usuarios y grupos de la aplicación ▸ Vulnerabilidades en el desempeño de los procedimientos de backup:

© Universidad Internacional de La Rioja (UNIR)

recuperación. Se debe contar con un centro de respaldo que proporcione el grado de redundancia necesario de forma transparente para los usuarios. ▸ Vulnerabilidades en la puesta en práctica del proceso de respuesta ante incidentes de seguridad. Se debe contar con un centro de respuesta ante incidentes de seguridad.

Seguridad en Aplicaciones Online Material Complementario

22

▸ Vulnerabilidades en la puesta en práctica la política de gestión de contraseñas, servicio de PKI para gestión de certificados digitales. ▸ Vulnerabilidades en la operativa de la seguridad física, seguridad del personal y de la información. La seguridad relativa al personal debe estar clasificada en niveles de acuerdo con su puesto y la «necesidad de conocer» que tenga en función de aquel. Igualmente la información y sus sistemas deben tener distintos niveles de clasificación. Una persona podrá acceder a un documento o a un sistema si tiene el grado de clasificación requerido para acceder al documento con un determinado grado de clasificación y si tiene la necesidad de conocer la información contenida en el documento o en el sistema.

1.5. Listas oficiales de vulnerabilidades En este apartado se relacionan las publicaciones online de las vulnerabilidades de seguridad más importantes y frecuentes que tienen lugar en las aplicaciones y más concretamente en las aplicaciones web. Para ello se van a tomar como referencia varias clasificaciones que dan varias organizaciones en función de su importancia por su peligrosidad y frecuencia con la que se dan en las aplicaciones.

Algunas de las clasificaciones de vulnerabilidades de seguridad en el diseño, implementación y operación más importantes son:

▸ OWASP Top Ten 2017 (OWASP, 2020). ▸ SANS Top 25 (SANS, 2020). ▸ WASC (Web application security consortium) (WASC, 2020), definiciones © Universidad Internacional de La Rioja (UNIR)

genéricas de vulnerabilidades, estadísticas de vulnerabilidades encontradas. ▸ CWE (Common weakness enumeration) (MITRE CWE, 2020), definiciones genéricas de vulnerabilidades. ▸ CVE (Common vulnerability exposure) (MITRE CVE, 2020), publicaciones de vulnerabilidades reales en aplicaciones conocidas.

Seguridad en Aplicaciones Online Material Complementario

23

▸ CAPEC (Common attack pattern enumeration) (MITRE CAPEC, 2020), definiciones genéricas de ataques.

1.6. OWASP Top Ten El estándar más seguido actualmente es el proyecto OWASP TOP TEN 2107 (Owasp Top Ten, 2017) las vulnerabilidades más frecuentes en las aplicaciones web en los últimos tres años son las vulnerabilidades relativas a inyección de código, de autenticación y gestión de sesiones y XSS (cross site scripting). En este tema se trata de asentar los conocimientos necesarios para evitar cometer las vulnerabilidades contenidas en las categorías OWASP Top Ten. La lista enumera las 10 categorías de vulnerabilidades de seguridad más comunes desde 2017 (figura 16), comparada con la misma lista de OWASP 2013, mostrando su evolución desde entonces en función de las vulnerabilidades detectadas en las aplicaciones y los

© Universidad Internacional de La Rioja (UNIR)

ataques sufridos en los tres años.

Figura 16. OWASP TOP TEN 2017 vs 2013 Fuente: https://www.owasp.org/images/5/5e/OWASP-Top-10

A continuación, se describen los problemas más importantes de seguridad OWASP TOP TEN 2017 según su sitio web (OWASP TOP TEN 2017 (Owasp Top Ten, 2017):

Seguridad en Aplicaciones Online Material Complementario

24

▸ A1:2017 Inyección. Las fallas de inyección SQL, NoSQL, OS o LDAP ocurren cuando se envían datos no confiables a un intérprete, como parte de un comando o consulta. Las cadenas de ataque pueden engañar al intérprete para que ejecutar sentencias que permiten alterar, borrar o acceder a los datos sin la debida autorización.

▸ A2:2017 Pérdida de Autenticación. Las funciones de la aplicación relacionadas con la autenticación y gestión de sesiones se implementan incorrectamente, permitiendo a los atacantes comprometer usuarios y contraseñas, token de sesiones, o explotar otras fallas de implementación para asumir la identidad de otros usuarios (temporal o permanentemente).

▸ A3:2017 Exposición de datos sensibles. Muchas aplicaciones web y APIs no protegen adecuadamente datos sensibles, tales como información financiera, de salud o Información Personalmente Identificable (PII). Los atacantes pueden robar o modificar estos datos protegidos inadecuadamente para llevar a cabo fraudes con tarjetas de crédito, robos de identidad u otros delitos. Los datos sensibles requieren métodos de protección adicionales, como el cifrado en almacenamiento y tránsito.

▸ A4:2017 Entidades Externas XML (XXE). Muchos procesadores XML antiguos o mal configurados evalúan referencias a entidades externas en documentos XML. Las entidades externas pueden utilizarse para revelar archivos internos o mediante uan URL archivos internos en servidores no actualizados, escanear puertos de la LAN, ejecutar código de forma remota y realizar ataques de

© Universidad Internacional de La Rioja (UNIR)

denegación de servicio (DoS).

▸ A5:2017 Pérdida de Control de acceso. Las restricciones sobre lo que los usuarios autenticados pueden hacer no se aplican correctamente. Los atacantes pueden explotar estos defectos para acceder, de forma no autorizada, a funcionalidades y/o datos, cuentas de otros usuarios, ver archivos sensibles, modificar datos, cambiar derechos de acceso y permisos, etc. Seguridad en Aplicaciones Online Material Complementario

25

▸ A6:2017 Configuración de Seguridad Incorrecta. Una configuración de seguridad incorrecta es un problema muy común y se debe en parte a establecer la configuración de forma manual, ad hoc o por omisión (o directamente por la falta de configuración). Son ejemplos: S3 buckets abiertos, cabeceras HTTP mal configuradas, mensajes de error con contenido sensible, componentes desactualizados, etc.

▸ A7:2017 Secuencia de Comandos en Sitios Cruzados (XSS). Los XSS ocurren cuando una aplicación toma datos maliciosos de un servidor remoto y los envía al navegador web sin una validación y codificación apropiada; o actualiza una página web existente con datos suministrados por el usuario utilizando una API que ejecuta JavaScript en el navegador. Permiten ejecutar código en el navegador de la víctima y el atacante puede secuestrar una sesión, modificar (defacement) los sitios web, o redireccionar al usuario hacia un sitio malicioso.

▸ A8:2017 Deserialización Insegura. Estos defectos ocurren cuando una aplicación recibe objetos serializados maliciosos y pueden ser manipulados o borrados por el atacante para realizar ataques de repetición, inyecciones o elevar sus privilegios de ejecución. En el peor de los casos, la deserialización insegura puede conducir a la ejecución remota de código en el servidor.

▸ A9:2017 Componentes con vulnerabilidades conocidas. Los componentes como bibliotecas, frameworks y otros módulos se ejecutan con los mismos privilegios que la aplicación. Si se explota un componente vulnerable, el ataque puede

© Universidad Internacional de La Rioja (UNIR)

provocar una pérdida de datos o tomar el control del servidor. Las aplicaciones y API que utilizan componentes con vulnerabilidades conocidas pueden debilitar las defensas de las aplicaciones y permitir diversos ataques e impactos.

▸ A10:2017 Registro y Monitorización. El registro y monitorización insuficiente, junto a la falta de respuesta ante incidentes de seguridad permiten a los atacantes mantener el ataque en el tiempo, pivotear a otros sistemas y Seguridad en Aplicaciones Online Material Complementario

26

manipular, extraer o destruir datos. Los estudios muestran que el tiempo de detección de una brecha de seguridad es mayor a 200 días, siendo típicamente detectado por terceros en lugar de por procesos internos.

1.7. Referencias bibliográficas Ajax frente al esquema tradicional de aplicaciones web. Recuperado (1 de abril de 2020) en http://librosweb.es/libro/ajax/capitulo_1.html AJAX: Explain in detail AJAX Web Application Model with neat diagram. Recuperado el 21 de marzo de 2020 de https://www.ques10.com/p/29472/explain-in-detail-ajaxweb-application-model-wit-1/ Asadullah, S., Hussaini, S. y Khader, M. (2020). International Journal of Engineering Research and Applications (IJERA) 3.2, 111-117. Recuperado el 21 de marzo de 2020 de https://www.ijera.com/papers/Vol3_issue2/O32111117.pdf CNN-CERT.CNI. Sitio web del CERT del CCN-CNI. Recuperado (08 de mayo de 2020) en https://www.ccn-cert.cni.es/ HTTP

1.1

protocol.

Recuperado

(30

de

abril

de

2020)

en,

https://tools.ietf.org/html/rfc2616 INCIBE. Sitio web del INCIBE. Recuperado (08 de mayo de 2020) en, https://www.incibe.es/ JSON. Official site. Recuperado (30 de abril de 2020) en, http://json.org/json-es.html

© Universidad Internacional de La Rioja (UNIR)

Laravel PHP framework. Official site. Recuperado (30 de abril de 2020) en https://laravel.com/ MVC

Frameworks.

Recuperado

el

30

de

agosto

de

2020:

http://es.wikipedia.org/wiki/Modelo_Vista_Controlador

Seguridad en Aplicaciones Online Material Complementario

27

MVC. Spring Framework. Universidad de Alicante. Recuperado el 30 de agosto de 2020: http://www.jtech.ua.es/j2ee/publico/spring-2012-13/sesion03-apuntes.html Padilla J., Pérez J. Comparativa J2EE vs .NET. Recuperado el 30 de agosto de 2020 https://joseperezlozano.com/wpcontent/uploads/2010/05/J2EEOPuntoNetVersionWeb.pdf SANS Institute. Recuperado (08 de mayo de 2020) en, https://www.sans.org/ https://www.sans.org/reading-room/whitepapers/webappsec/

https://software-

security.sans.org/resources/swat https://www.newnettechnologies.com/posters/sans-securing-web-applications.pdf SANS TOP 25 most dangerous errors. Recuperado (08 de mayo de 2020) en, https://www.sans.org/top25-software-errors/ Spring

framework.

MVC.

Recuperado

(30

de

abril

de

2020)

en,

© Universidad Internacional de La Rioja (UNIR)

http://openaccess.uoc.edu/webapps/o2/bitstream/10609/669/1/00848tfc.pdf

Seguridad en Aplicaciones Online Material Complementario

28

A fondo Arquitectura clásica de aplicaciones Web

Sergio

Luján

Mora.

Arquitectura

clásica

de

aplicaciones

web.

https://www.youtube.com/watch?v=5rBlxXHOJh4

Descripción del modelo de arquitectura de aplicaciones web clásica.

Ejecución de una aplicación web: modelo clásico

Sergio

Luján

Mora.

Arquitectura

clásica

de

aplicaciones

web.

© Universidad Internacional de La Rioja (UNIR)

https://www.youtube.com/watch?v=TkNrOJLaUHI

Seguridad en Aplicaciones Online Tema 0. A fondo

29

Descripción de la ejecución de una aplicación web: modelo clásico

Arquitectura Web AJAX

Sergio

Luján

Mora.

Arquitectura

AJAX.

© Universidad Internacional de La Rioja (UNIR)

https://www.youtube.com/watch?v=I3dmjFMefaE

Descripción

del

modelo

de

arquitectura

de

aplicaciones

web

AJAX.

(https://www.ques10.com/p/29472/explain-in-detail-ajax-web-application-model-wit-1/)

Seguridad en Aplicaciones Online Tema 0. A fondo

30

Mean stack

Introducción al framework "MEAN STACK" https://www.youtube.com/watch?v=F_Mi3WHPrDw

MEAN.JS es una solución JavaScript completa que ayuda a construir aplicaciones web de producción rápidas, robustas y mantenibles usando MongoDB, Express, AngularJS y Node.js (http://meanjs.org/)

Node Js

Introducción al framework "NODE js"

© Universidad Internacional de La Rioja (UNIR)

https://www.youtube.com/watch?v=9U8EaVjuq6U

Seguridad en Aplicaciones Online Tema 0. A fondo

31

El objetivo de este tutorial es iniciarse en el desarrollo de programas utilizando la plataforma de Node.js. Se requieren coneptos previos de Javascript y se hace una introducción

gradual

de

esta

plataforma

de

desarrollo.

Se presentan una serie de temas donde Node.js pretende disputar terreno a lenguajes

de

servidor

como

PHP,

Java,

C#

etc.

Aprender Node.js es una herramienta muy buena si queremos seguir aprendiendo de las bondades de Javascript. https://www.tutorialesprogramacionya.com/javascriptya/nodejsya/

Spring framework

Introducción al framework SPRING

© Universidad Internacional de La Rioja (UNIR)

https://www.youtube.com/watch?v=r4kqcSs4F7I&list=PLvimn1Ins40CImsffjCkv_TrKzYiB1gb

Seguridad en Aplicaciones Online Tema 0. A fondo

32

Spring tiene un historial probado de tratar los aspectos de seguridad de forma rápida y responsable. Los responsables de Spring trabajan con profesionales de la seguridad para parchear y probar cualquier vulnerabilidad reportada. Las dependencias de terceros también se supervisan de cerca, y se emiten actualizaciones regulares para ayudar a mantener sus datos y aplicaciones tan seguros como sea posible. Además, Spring Security le facilita la integración con los esquemas de seguridad estándar del sector y ofrece soluciones fiables que son seguras de forma predeterminada. (https://spring.io/quickstart)

Core .NET

Introducción al framework CORE .NET https://www.youtube.com/watch?v=ss61x5HLBYo&list=PLLJJqiFt6VPrSzPakVEy1_Wpw

© Universidad Internacional de La Rioja (UNIR)

qcWD1vAc

Seguridad en Aplicaciones Online Tema 0. A fondo

33

Habrá un solo .NET en el futuro, y podrás usarlo para apuntar a Windows, Linux, macOS, iOS, Android, tvOS, watchOS y WebAssembly y más. Introduciremos nuevas APIs de .NET, capacidades de tiempo de ejecución y características de lenguaje como parte de .NET 5. (https://devblogs.microsoft.com/dotnet/introducing-net-5/)

Patrón de diseño MVC

Modelo-Vista-Controlador

© Universidad Internacional de La Rioja (UNIR)

https://www.youtube.com/watch?v=ANQDmqBYwns

Seguridad en Aplicaciones Online Tema 0. A fondo

34

Modelo-vista-controlador (MVC) es un patrón de arquitectura de software, que separa los datos y principalmente lo que es la lógica de negocio de una aplicación de su representación y el módulo encargado de gestionar los eventos y las comunicaciones.

Para

ello

MVC

propone

la

construcción

de

tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define componentes para la representación de la información, y por otro lado para la interacción del usuario.12 Este patrón de arquitectura de software se basa en las ideas de reutilización de código y la separación de conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento

Tecnologías web

© Universidad Internacional de La Rioja (UNIR)

Tecnologías web repaso: Arquitecturas de las Aplicaciones Web: http://informatica.uv.es/iiguia/IST/Tema1.pdf https://programacionwebisc.wordpress.com/2-1-arquitectura-de-las-aplicacionesweb/ https://docs.microsoft.com/es-es/dotnet/architecture/modern-web-appsazure/common-web-application-architectures Seguridad en Aplicaciones Online Tema 0. A fondo

35

Introducción a tecnologías comúnmente usadas en las aplicaciones y servicios web (completo): http://laurel.datsi.fi.upm.es/_media/docencia/asignaturas/daw/pub/2015_2016/dawtema1.2.pdf Introducción HTML (apartado de introducción) https://www.w3schools.com/html/html_intro.asp Introducción CSS https://www.w3schools.com/css/css_intro.asp Introducción HTTP 1.0 1.1 (completo) http://informatica.uv.es/iiguia/IST/Tema2.pdf Introducción HTTP 2 (completo) https://es.wikipedia.org/wiki/HTTP/2 Introducción XML (apartado de introducción) https://www.w3schools.com/xml/xml_whatis.asp Introducción JSON (apartado de introducción) https://www.w3schools.com/js/js_json_intro.asp (apartado JSON) http://json.org/json-es.html Introducción Javascript (apartado de introducción) https://www.w3schools.com/js/js_intro.asp Introducción SQL (apartado de introducción) https://www.w3schools.com/sql/sql_intro.asp Introducción AJAX (apartado de introducción) https://www.w3schools.com/xml/ajax_intro.asp Política del mismo origen (completo)

© Universidad Internacional de La Rioja (UNIR)

http://notasjs.blogspot.com/2013/09/politica-del-mismo-origen-same-origin.html

Seguridad en Aplicaciones Online Tema 0. A fondo

36

OWASP Top Ten 2017

Listas oficiales de vulnerabilidades de seguridad Las páginas 6 a 17 del proyecto OWASP TOP Ten 2017:

© Universidad Internacional de La Rioja (UNIR)

https://www.owasp.org/images/5/5e/OWASP-Top-10-2017-es.pdf

Seguridad en Aplicaciones Online Tema 0. A fondo

37