Tema 2

Seguridad en Sistemas, Aplicaciones y Datos Masivos

introducción
Índice
Esquema

Ideas clave

2.1. Introducción y objetivos

2.2. Ciclo de vida de desarrollo seguro de software

(SSDLC)

2.3. Arquitecturas de las aplicaciones web

2.4. Protocolo HTTP

2.5. Referencias bibliográficas

Test

A fondo

Arquitectura clásica de aplicaciones web

Descripción del modelo de arquitectura de aplicaciones

web clásica

The Application of a New Secure Software Development

Life Cycle (S-SDLC) with Agile Methodologies

Mean stack

Patrón de diseño MVC

 Esquema

Seguridad en Sistemas, Aplicaciones y Datos Masivos 3

Tema 2. Esquema
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

2.1. Introducción y objetivos

Estudiaremos las medidas 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

que así puedan mitigar cualquier ataque.

Se pretende sentar las bases de la seguridad de las aplicaciones online e

introducir las actividades de seguridad que se realizan antes y una vez desplegada

la aplicación online, como; por ejemplo: los distintos tipos de análisis de seguridad y

las operaciones de seguridad. Las actividades de seguridad se deben llevar a cabo

de forma ordenada y procedimental por personal experto en seguridad.

El pilar fundamental en el que ha de basarse la seguridad de la información de toda

organización ya sea pública o privada, es la definición de la política de seguridad.

Una política de seguridad bien definida e implantada en una organización gestionada

por procesos es la base para implantar un sistema de gestión de seguridad de la

información (SGSI) que regule y gobierne los procesos y procedimientos que han

de implementarse en toda organización. Además, todo el personal, cada uno a su

nivel, debe seguir de forma coordinada para conseguir el objetivo de seguridad

requerido por la organización para la protección ante cualquier tipo de amenaza

interna o externa.

A nivel de seguridad en las aplicaciones y más concretamente en el apartado del

desarrollo, el sistema de gestión de seguridad de la información debe implantar un

ciclo de vida de desarrollo seguro de software (SSDLC) que permita acometer el

diseño e implementación de la seguridad desde las primeras fases del ciclo de vida

de desarrollo de aplicaciones.

El SSDLC incluye una serie de actividades de seguridad a implementar en cada una

Seguridad en Sistemas, Aplicaciones y Datos Masivos 4

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

de sus fases, como pueden ser el análisis y gestión del riesgo de forma dinámica, la

revisión de seguridad del código, las pruebas de seguridad o la monitorización

continua en fase de despliegue.

Las aplicaciones web son por excelencia el principal tipo de aplicación online

accesibles desde Internet, las Intranets de organizaciones, mediante una PC, una

Tablet o un móvil, características que también posibilitan que sean accesibles por

posibles atacantes que quieren obtener algún beneficio económico, información, etc.

Por tanto, es necesario introducir las características de las principales arquitecturas

de aplicaciones web y de su protocolo HTTP empleado en la comunicación.

En el vídeo Proyectos de seguridad web repasaremos los principales proyectos que

se ocupan de la seguridad de las aplicaciones web.

Accede al vídeo:
https://unir.cloud.panopto.eu/Panopto/Pages/Embed.aspx?id=4e7f4317-2882-

46f2-a383-adbf010b1f48

Los principales objetivos son los siguientes:

Seguridad en Sistemas, Aplicaciones y Datos Masivos 5

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

▸ Analizar las actividades que se desarrollan en cada fase del Ciclo de Vida de

Desarrollo Seguro de Software (SSDLC).

▸ Conocer los principales tipos de arquitecturas de aplicaciones web.

▸ Estudiar el protocolo HTTP y sus métodos.

Los objetivos de seguridad que 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 de este.

▸ Autenticar a las personas que acceden a la información manejada por un sistema o a

los recursos de este.

▸ Controlar el acceso a la información manejada por un sistema o a los recursos de

este.

▸ Proporcionar confidencialidad a la información manejada por un sistema.

▸ Proporcionar integridad a la información manejada por un sistema o a los recursos

de este.

▸ Mantener la disponibilidad de la información manejada por un sistema o por los

recursos de este.

▸ No repudio. Proporcionar la prueba de que una determinada transmisión o recepción

ha sido realizada, sin que su receptor/transmisor pueda negar que se haya

producido.

▸ Trazabilidad. Proporcionar los controles que señalen que en todo momento se podrá

determinar quién hizo qué y en qué momento.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 6

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

2.2. Ciclo de vida de desarrollo seguro de software

(SSDLC)

En el vídeo SSDLC veremos qué es el ciclo de vida de desarrollo seguro de software

(SSDLC), sus fases y actividades.

Accede al vídeo:

https://unir.cloud.panopto.eu/Panopto/Pages/Embed.aspx?id=6c1c2155-6150-
4195-bda5-adbf010de7a9

La seguridad de la aplicación tiene que tratarse obligatoriamente en todas las fases

del ciclo de vida de desarrollo seguro (SSDLC) de aplicaciones. En cada una de las

fases, como veremos más adelante, se han de realizar prácticas que tienen que ver

con el diseño, la implementación y pruebas de la seguridad de la aplicación tratando

y cubriendo todos los aspectos y principios de la seguridad.

El ciclo de vida SSDLC contempla también las operaciones y

Seguridad en Sistemas, Aplicaciones y Datos Masivos 7

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

actividades de seguridad online en fase de producción con la aplicación

desplegada, la cual ya puede entonces ser objetivo de ataques de

cualquier naturaleza.

En un proceso SSDLC hay que llevar a cabo las siguientes actividades:

▸ En primer lugar, hay que derivar los requisitos de seguridad en función del resultado

obtenido en la actividad de modelado de amenazas o derivación de casos de abuso

de la aplicación y del análisis de riesgos de todos los activos de la organización.

▸ Hay que diseñar la seguridad de la aplicación en base a los requisitos de

seguridad y teniendo en cuenta sus dimensiones: autenticación, autorización, control

de accesos a recursos, cifrado de datos, seguridad en profundidad para asegurar el

no repudio, confidencialidad e integridad de datos, etc. Además, se deben tener

presentes los principios de seguridad contemplados en la política de seguridad.

▸ Se diseñan los casos de test funcionales de seguridad basados en el riesgo.

▸ Se implementa el código de la aplicación siguiendo buenas prácticas de

desarrollo seguro, como son la validación de las entradas y salidas de la aplicación,

gestión de errores, etc. Se analiza la seguridad del código fuente mediante la ayuda
de herramientas de análisis estático de código (caja blanca).

▸ En fase de despliegue o de pruebas, se ejecutan los casos de test para prueba del

diseño funcional de la seguridad en cada una de sus dimensiones. Estas

pruebas pueden conducir a un ciclo volviendo a la primera fase para definir nuevos

requisitos, redefinir los existentes o para solucionar las vulnerabilidades encontradas.

Luego, se lleva a cabo un test de penetración a la aplicación con la ayuda de
herramientas de análisis dinámico de caja negra y de caja blanca.

▸ En la fase de producción se ejecutan operaciones de seguridad como

monitorización, cambio de configuraciones, permisos, auditoría, gestión de backups,

centro de respaldo, gestión de incidentes de seguridad, etc.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 8

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

Como en cualquier otro modelo de SDLC, en un SSDLC se deben tener procesos

definidos en todo lo que se refiere a desarrollo de software, gestión de configuración,

gestión y aseguramiento de la calidad con sus correspondientes procedimientos y

actividades, donde un proyecto de software tiene una dirección de proyecto, equipo

de desarrollo y, además, un equipo de expertos en seguridad (que pueden

pertenecer al área o unidad de seguridad) que apoyan para la realización de las

actividades de esta última.

De esta manera, se planifica y gestiona adecuadamente y se sigue un modelo de

ciclo de vida adaptado a las características del proyecto. Partiendo de la política

de seguridad y dentro del sistema de gestión de seguridad de la información, se debe

contar con un equipo de seguridad que permita implantar el ciclo de vida de

desarrollo seguro de software, asesorando y realizando las actividades relacionadas

con la seguridad en el ciclo de vida.

Cualquier modelo de ciclo de vida SDLC (ciclo de vida en espiral, extreme

programming, proceso unificado de rational) o metodología de tipo SCRUM, se

puede adaptar y convertir en un SSDLC. Si no se tuviera una estructura por procesos

dentro de la organización sería muy difícil pensar en aplicar diseño e implementación

de la seguridad durante el ciclo de vida de software correctamente. Una propuesta de

ciclo de vida de desarrollo seguro de software SSDLC sería la que se observa en la

Figura 1.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 9

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

Figura 1. Modelo de SSDLC de MacGraw (Seven Touchpoints for Software Security). Fuente: McGraw,

2006.

La Figura 1 muestra un ejemplo de ciclo de vida donde se especifican las actividades

y pruebas de seguridad a efectuar en cada una de sus fases.

A continuación, se enumeran esas actividades, mejores prácticas o touchpoints, en

orden de eficacia e importancia según el autor Gary McGraw:

▸ Revisión de código.

▸ Análisis de riesgo arquitectónico.

▸ Pruebas de penetración.

▸ Pruebas de seguridad basadas en riesgo.

▸ Casos de abuso.

▸ Requisitos de seguridad.

▸ Operaciones de seguridad.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 10

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

▸ Revisión externa.

Este orden descrito no se adecuará perfectamente a todas las organizaciones. De

hecho, el orden refleja el trabajo desarrollado en años de experiencia de aplicar estas

prácticas en empresas que tienen gran cantidad de softwares. Por esa razón, la

revisión de código viene antes del análisis de riesgos arquitectónicos.

Hay que resaltar que estas actividades hay que repetirlas a lo largo del ciclo de vida,

lo que supone un ciclo continuo en la ejecución de las distintas actividades de

seguridad.

Según se van descubriendo nuevas amenazas se tienen nuevos casos de abuso

que implican nuevos riesgos, lo que conlleva rehacer el análisis de riesgos.

Si se introducen cambios o se introducen nuevos componentes de software o de

hardware en el sistema hay que rehacer el análisis de riesgos y revisar el código

de nuevos componentes de software.

Los nuevos defectos de implementación de partes, que se modifican con arreglo a

nuevas especificaciones o cambios en las mismas, implican una nueva revisión de

código y nuevas pruebas de seguridad en operación del sistema.

Por supuesto, siempre hay que incidir en la prevención y formación en seguridad,

documentando y realizando cuantificación y análisis de métricas de seguridad que se

puedan emplear en futuros proyectos para mejorar.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 11

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

2.3. Arquitecturas de las aplicaciones web

El extraordinario éxito del modelo web puede atribuirse a una característica

fundamental: es un modelo que se acopla más débilmente 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 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.

L a s arquitecturas monolíticas son las que se 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, por

ejemplo, la utilización de lenguajes potencialmente más seguros 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 interfaz y la reutilización de objetos.

Además, dividir la aplicación en niveles permite que esta se pueda distribuir entre

varios servidores, mejorando, por lo tanto, su escalabilidad a expensas de mayor

complejidad con controles de acceso y detección avanzados. Existe separación

Seguridad en Sistemas, Aplicaciones y Datos Masivos 12

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

de tareas y responsabilidades.

Arquitectura de una aplicación web clásica

Las capas de las 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 (Apache, Niginx, etc.) para alojar contenido estático o

aplicación desarrollada con lenguajes interpretados (PHP, Python, etc.).

▸ 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.

Figura 2. Arquitectura de tres capas de aplicaciones web. Fuente: elaboración propia.

Arquitectura de aplicaciones RIA

Seguridad en Sistemas, Aplicaciones y Datos Masivos 13

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

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

difundidas y utilizadas (Mayekar, 2018).

El objetivo principal de las aplicaciones AJAX es eliminar la naturaleza start-stop-

start-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).

Figura 3. Modelo de comunicación síncrono. Fuente: Mayekar, 2018.

Este elemento arquitectónico adicional del lado del 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 este

será responsable del 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

comunicación con el servidor.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 14

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

Figura 4. Modelo de comunicación asíncrono (AJAX). Fuente: Mayekar, 2018.

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 con,

relativamente, poco esfuerzo, generando un nuevo nivel de interactividad con los

usuarios como el que otorgan, por ejemplo: Google Maps, Google Docs, Flickr, etc.

En cuanto a la arquitectura en sí, se puede observar en la Figura 5. Cada acción del

usuario que normalmente generaría una petición HTTP se convierte en una llamada

JS al motor AJAX. El motor se encarga por sí solo de servir el código HTML, CSS y

JS, ante 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, la edición de datos en la

memoria e incluso un poco de navegación. Si el motor necesita algo del servidor con

el fin de responderle 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 priori la experiencia del usuario del navegador (Asadullah et al. 2020).

Seguridad en Sistemas, Aplicaciones y Datos Masivos 15

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

Figura 5. Modelo de aplicación AJAX web. Mayekar, 2018.

Patrón de diseño lógico MVC

Uno de los patrones de diseño lógico de las aplicaciones web más comunes es el de

modelo-vista-controlador (MVC), este se puede implementar en muy diversos

frameworks, como, por ejemplo:

▸ Las arquitecturas de aplicaciones J2EE como Apache Foundation Jakarta Struts.

▸ PHP.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 16

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

▸ .NET, Rubí, Phyton disponen de frameworks para implementación de MVC.

▸ Meteor, Tesla.js, Node.Js.

MVC articula el código de una aplicación web en tres capas diferenciadas:

▸ Modelo.

▸ Vista.

▸ Controlador.

Modelo

El modelo es la capa de la aplicación que se ocupa de los datos que esta necesita y
de los accesos a dichos datos. En una aplicación J2EE los componentes de la lógica

de negocio necesitan acceder a los datos de la aplicación (SGBD, repositorio XML) y

para ello solicitan el servicio a un Javabean o EJB que se encarga de la llamada al

sistema gestor de base de datos para extraer, insertar, actualizar o borrar

información.

Vista

Es la capa que se ocupa de generar la presentación al usuario en aplicaciones web.

La vista se conforma de páginas HTML que componen la interfaz de usuario. Como

se señaló anteriormente pueden incluir código Javascript que interpretará el

navegador.

A través de la interfaz de la aplicación web los usuarios pueden rellenar un formulario

y enviarlo al servidor de aplicación que en tecnología J2EE dispone de un

controlador (servlet) que se encarga de seleccionar la lógica de aplicación que se

ocupará de servir la petición del usuario.

En cuanto a cuestiones de seguridad, hay que tener en cuenta la información de

Seguridad en Sistemas, Aplicaciones y Datos Masivos 17

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

autenticación que se puede enviar dentro de las peticiones o cualquier otra

información que pueda comprometer la seguridad de la aplicación con ataques de

sniffing y repetición, fuerza bruta basada en diccionario de descubrimiento de

contraseñas y todos los aspectos que conciernen a la interpretación de lenguajes de

script por parte del navegador.

Si se permite, hay que validar por qué constituyen una potencial fuente de ataque

(Scambray et al. 2010; Sullivan et al. 2012; Mueller, 2016). Lo más deseable para

implementar los servicios de autenticación es utilizar los proporcionados por el

framework de desarrollo. Los mecanismos de autenticación Http Basic y Http

Digest tienen vulnerabilidades de seguridad. A continuación, se representa un

esquema del patrón MVC para J2EE.

Figura 6. Esquema del patrón MVC para J2EE. Fuente: página de Programación.net

Controlador

Recoge las peticiones de los usuarios (servlet) para seleccionar el código de

aplicación o lógica de negocio encargado de servírselas. En tecnología J2EE son

JSPs (Java Server Pages), que integran código HTML y código Java, los encargados

de llevar a cabo este cometido de ejecutar la lógica de negocio correspondiente a la

petición.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 18

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

En cuanto al apartado de seguridad, las vulnerabilidades en el servicio de

autorización a los recursos de la aplicación y sistema operativo pueden dar lugar a

ataques de fuga de información. Es conveniente, desde el punto de vista de la

seguridad, implementar la lógica de autorización en el sistema gestor de bases de

datos a través del uso de procedimientos almacenados e implementar los servicios

de autenticación utilizando los proporcionados por el framework de desarrollo.

En el apartado de seguridad puede haber vulnerabilidades en el aseguramiento del

control de acceso, integridad y confidencialidad de la información de los datos

alojados en la aplicación y en la base de datos. Para ello, es necesario diseñar

mecanismos que aseguren la integridad y confidencialidad mediante servicios

PKI de firma digital y cifrado de datos. Asimismo, hay que prestar atención al servicio

de logging (los mensajes que deben aparecer deben ser los que realmente aportan

información útil) y manejo de errores y excepciones, de forma que no aporten más

información de la necesaria en cada caso, ya que podría ser útil a los atacantes para

sacar provecho de ella.

En resumen, las vulnerabilidades de seguridad debidas a la arquitectura

de diseño física y lógica son causadas por defectos en los servicios de

autenticación, autorización, sesiones, integridad y confidencialidad de

datos, trazabilidad, gestión de errores y excepciones y comunicación

entre capas.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 19

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

2.4. Protocolo HTTP

El protocolo HTTP no fue diseñado para aplicaciones y probablemente tampoco para

usos seguros. HTTP crea oportunidades para generar vulnerabilidades de seguridad,

de la misma manera que en las funciones de string, de la biblioteca estándar de C,

crea 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, según la página web de datatracker (2020), que 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).

Estos se incluirán en el cuerpo de la petición. Esto puede resultar en la creación de

un nuevo recurso o de las actualizaciones de los recursos existentes o en ambas
cosas.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 20

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

▸ 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 es decodificado por el 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 que impide acceso a la cookie que protege. XST se puede
combinar con un ataque XSS para robo de un identificador de sesión contenido en
una cookie.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 21

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

Figura 7. XST. Fuente: adaptado de Grossman, 2003.

▸ 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.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 22

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

En la Figura 8 se observa cómo se puede especificar un método HTTP.

Figura 8. Métodos HTTP. Fuente: elaboración propia.

En una petición GET los parámetros que se incluyen en la cadena de la URL pueden

ser rutinariamente escritos a LOG cache del navegador y almacenados en el historial

revelando información sensible, como passwords, entre otras. Es más sencillo

prevenir XSS deshabilitando GET en las aplicaciones. Para un atacante es más fácil

enviar correos con una URL con parámetros maliciosos:

Figura 9. Método HTTP GET. Fuente: elaboración propia.

Sin embargo, con el método POST los parámetros se especifican en el cuerpo de la

petición. Para que sea más seguro se debe de utilizar POST en lugar de GET.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 23

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

Figura 10. Método HTTP POST. Fuente: elaboración propia.

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

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

Figura 11. Procedencia de peticiones CSRF. Fuente: Chess y West, 2007.

Un atacante podría tener un sitio web con:

Figura 12. Procedencia de peticiones CSRF. Fuente: Chess y West, 2007.

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:

Seguridad en Sistemas, Aplicaciones y Datos Masivos 24

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

Figura 13. Procedencia de peticiones. Protección CSRF. Fuente: Chess y West, 2007.

Otra vulnerabilidad que se puede presentar en el protocolo HTTP es la 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, que puede verse
en la Figura 14.

Figura 14. HTTP Response Splitting. Fuente: Chess y West, 2007.

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:

Figura 15. HTTP Response Splitting. Fuente: Chess y West, 2007.

El problema del protocolo HTTP es más agudo cuando se maneja el estado de

Seguridad en Sistemas, Aplicaciones y Datos Masivos 25

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

sesión, que es necesario en la mayoría de las 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, 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 sean publicados y revocados en los puntos

apropiados del programa.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 26

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

2.5. Referencias bibliográficas

Asadullah, S., Hussaini, S. y Khader, M. (2020). AJAX Architecture Implementation

Techniques. International Journal of Engineering Research and Applications (IJERA),

3(2), 111-117. https://www.ijera.com/papers/Vol3_issue2/O32111117.pdf

Chess, B. y West, J. (2007). Secure programming with static analysis. Addison-

Wesley

Grossman, J. (2003). XST [imagen]. https://www.cgisecurity.com/whitehat-mirror/WH-

WhitePaper_XST_ebook.pdf

Mayekar, B. (2018). Explain in detail AJAX Web Application Model with neat diagram.

Q u e s 1 0 . https://www.ques10.com/p/29472/explain-in-detail-ajax-web-application-

model-wit-1/

Mcgraw, G. (2006). Seven Touchpoints for Software Security [figura].

http://www.swsec.com/resources/touchpoints/

Mueller, J. P. (2016). Security for web developers: using javascript, HTML and CSS.

O’Reilly Media.

Página de Datacracker (https://www.ques10.com/p/29472/explain-in-detail-ajax-web-

application-model-wit-1/).

Programación.net. (2021). Esquema del patrón MVC para J2EE [imagen].

Programación.net. https://programacion.net/articulo/manual_basico_de_struts_156

Scambray, J., Liu, V y Sima, C. (2010). Hacking exposed web applications 3.

McGraw Hill.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 27

Tema 2. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 A fondo

Arquitectura clásica de aplicaciones web

iDESWEB UA. (2014). Arquitectura de una aplicación web [Vídeo]. YouTube.

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

Seguridad en Sistemas, Aplicaciones y Datos Masivos 28

Tema 2. A fondo
© Universidad Internacional de La Rioja (UNIR)
 A fondo

Descripción del modelo de arquitectura de

aplicaciones web clásica

iDESWEB UA. (2014). Ejecución de una aplicación web: modelo moderno (AJAX)

[Vídeo]. YouTube. https://www.youtube.com/watch?v=I3dmjFMefaE

Descripción del modelo de arquitectura de aplicaciones web AJAX.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 29

Tema 2. A fondo
© Universidad Internacional de La Rioja (UNIR)
 A fondo

The Application of a New Secure Software

Development Life Cycle (S-SDLC) with Agile
Methodologies

Página de MDPI.

Hoy en día los modelos ágiles están en auge. Se definen por la forma en que logran

la interacción e integración de todos los involucrados en el ciclo de vida del software,

las ventajas de la rápida reacción al cambio y la implementación de artefactos o

entregables que muestran el nivel de progreso alcanzado en cualquier momento. En

este contexto, parece claramente necesario definir un nuevo modelo de desarrollo de

software que dé prioridad a los aspectos de seguridad en cualquier fase del ciclo de

vida de este y aproveche los beneficios de los modelos ágiles. La metodología

propuesta muestra que si se considera la seguridad desde el principio, las

vulnerabilidades se detectan y resuelven fácilmente durante el tiempo previsto para

el proyecto, sin tiempo ni costos adicionales para el cliente.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 30

Tema 2. A fondo
© Universidad Internacional de La Rioja (UNIR)
 A fondo

Mean stack

Conde, J. (2015). 48.- Curso de AngularJS. Introducción al trabajo con el "MEAN

STACK" [Vídeo]. YouTube. 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

Seguridad en Sistemas, Aplicaciones y Datos Masivos 31

Tema 2. A fondo
© Universidad Internacional de La Rioja (UNIR)
 A fondo

Patrón de diseño MVC

Fatz. (2017). ¿Qué es el Patron Modelo Vista Controlador?, Explicación Simple

[Vídeo]. YouTube. https://www.youtube.com/watch?v=ANQDmqBYwns

El Modelo-vista-controlador (MVC) es un patrón de arquitectura de software, que

separa los datos y 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 en la separación de conceptos y características

que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior

mantenimiento.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 32

Tema 2. A fondo
© Universidad Internacional de La Rioja (UNIR)
 Test

1. ¿Cuáles son los objetivos de seguridad de los sistemas TIC?

A. No repudio, funcionamiento correcto, trazabilidad, confidencialidad,

disponibilidad e integridad.

B. No repudio, trazabilidad, autenticación, autorización y control de acceso,

confidencialidad, disponibilidad e integridad.

C. No repudio, autenticación, autorización y control de acceso,

confidencialidad, disponibilidad e integridad.

D. A y B son correctas.

2. ¿Cuál de los siguientes es un modelo de desarrollo de software seguro?

A. SDL.

B. CLASP.

C. TOUCHPOINTS.

D. Todos las anteriores son ciertas.

3. ¿En qué fase se le debe realizar un test de penetración a una aplicación web?

A. Diseño.

B. Desarrollo.

C. Pruebas.

D. Producción.

4. ¿De qué depende la derivación de requisitos de seguridad?

A. El modelado de amenazas o casos de abuso.

B. Del análisis de riesgos.

C. Análisis de seguridad del código fuente.

D. La A y la B.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 33

Tema 2. Test
© Universidad Internacional de La Rioja (UNIR)
 Test

5. Antes del test de penetración, ¿qué actividades de seguridad hay que llevar a

cabo?

A. Derivación de requisitos de seguridad.

B. Modelado de amenazas.

C. Análisis de seguridad del código fuente.

D. Todas las anteriores son ciertas.

6. ¿Cuál es el pilar de la seguridad que debe adoptarse para implementar la

seguridad de una aplicación web desde el principio del desarrollo?

A. SSDLC.

B. SGSI.

C. SQLI.

D. OWASP.

7. ¿Qué método HTTP permite conectarse a un servicio situado detrás de un proxy?

A. PUT.

B. GET.

C. POST.

D. CONNECT.

8. ¿Qué método HTTP permite obtener solo las cabeceras de la aplicación web?

A. PUT

B. HEAD

C. POST

D. GET

Seguridad en Sistemas, Aplicaciones y Datos Masivos 34

Tema 2. Test
© Universidad Internacional de La Rioja (UNIR)
 Test

9. ¿Qué método HTTP envía los parámetros en la URL?

A. GET.

B. POST

C. PUT

D. Todas las anteriores.

10. ¿Qué puede suponer la vulnerabilidad de HTTP response splitting?

A. La B y la D son correctas.

B. La inyección de código JAVASCRIPT.

C. La inyección de código SQL.

D. La inyección de código HTML.

Seguridad en Sistemas, Aplicaciones y Datos Masivos 35

Tema 2. Test
© Universidad Internacional de La Rioja (UNIR)