Tema1 PDF

Aplicaciones y servicios web y bases de
datos
[1.1] ¿Cómo estudiar este tema?
[1.2] Introducción
[1.3] Ciclo de vida de desarrollo seguro de software (SSDLC)
[1.4] Vulnerabilidades de seguridad en las aplicaciones

web
[1.5] Arquitecturas y tecnologías de desarrollo de las

aplicaciones web
1
[1.6] Arquitecturas y tecnologías de desarrollo de los
servicios web
[1.7] Arquitecturas de almacenes de datos
[1.8] Referencias bibliográficas TEMA

Seguridad en Aplicaciones Online y Bases de Datos
Esquema
TEMA 1 – Esquema 2 © Universidad Internacional de La Rioja (UNIR)

Ideas clave
1.1. ¿Cómo estudiar este tema?
Para estudiar este tema lee las Ideas clave que encontrarás a continuación.
En este tema analizaremos, de forma introductoria desde el punto de vista de la

seguridad.
1.2. Introducción
En este capítulo se van a resumir los objetivos de seguridad de las aplicaciones y

servicios web para abordar un diseño seguro.
Objetivos de seguridad
Los objetivos de seguridad a alcanzar en los sistemas de información y comunicaciones

TIC son:
» Identificar a las personas que acceden a la información manejada por un sistema y

a cualquiera de los recursos de sus capas.
» Autenticar a las personas que acceden a la información manejada por un sistema y
a cualquiera de los recursos de sus capas.
» Controlar el acceso a la información manejada por un sistema.
» Proporcionar confidencialidad a la información manejada por un sistema.
» Proporcionar integridad a la información manejada por un sistema.
» Mantener la disponibilidad de la información manejada por un sistema y de sus
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.
TEMA 1 – Ideas clave 3 © Universidad Internacional de La Rioja (UNIR)

Vulnerabilidades y ataques
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. Existen, por tanto:
» Vulnerabilidades de seguridad en el de diseño.

» Problemas funcionales de seguridad como autorización, control de accesos, etc.
» Vulnerabilidades de seguridad debidos a fallos de configuración.
» Vulnerabilidades de seguridad en el código.
» Problemas de seguridad debidos a la gestión de la seguridad 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. Cuanto más se tarde en solucionar una
vulnerabilidad del tipo que sea, mayor será el coste de dicha solución en la figura 1, 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.
Figura 1. Incremento del coste. Fuente: Graff (2001).
Por tanto, se pueden definir las clases de vulnerabilidades en función de las fases del
SSDLC. Las clases de vulnerabilidades comúnmente aceptadas incluyen
vulnerabilidades de diseño, implementación y vulnerabilidades operacionales.

La comunidad de seguridad generalmente acepta vulnerabilidades de diseño como

defectos en la arquitectura del sistema de software y datos específicos, podemos
encontrarlas en los requisitos de la fase de análisis o en las especificaciones de la fase
de diseño. La categoría de vulnerabilidades de implementación se refiere lógicamente a
errores de seguridad cometidos por los desarrolladores cuando están desarrollando los
módulos u objetos del sistema para cumplir con sus especificaciones. La categoría de
vulnerabilidades operacionales se refiere a los defectos que surgen en el despliegue y la
configuración del sistema desarrollado en un ambiente particular.
Aprovechando cualquier tipo de vulnerabilidad de las mencionadas anteriormente,

pueden darse ataques de diversos tipos:
» Stealing Passwords
» 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 vida de desarrollo del software
y sistemas.
A continuación, se presentan unos cuantos ejemplos de ataques debidos a defectos de

seguridad en el diseño, en la implementación y en la operación.

» Nivel de diseño
o Ataque de hombre en medio. Este ataque ocurre cuando el atacante

intercepta la comunicación entre dos hosts, entonces suplanta la identidad de una
de las dos partes. Su defensa consistiría en el uso de autenticación basada en
criptografía, por ejemplo, utilizando ssh en lugar de telnet.
o Ataque de condiciones de carrera. TOCTOU. En un sistema operativo

multiusuario, se conceden ventanas de tiempo a las distintas tareas de los
procesos y a veces entre estas tareas se intercala en una de esas ventanas un
atacante que puede comprometer la seguridad. En este ejemplo, puede haber una
ventana muy breve que dé la oportunidad para que un atacante substituya un
archivo nuevo (que contiene código del ataque) por el archivo previamente
comprobado.
Tal substitución puede implicar el uso del software malicioso del atacante.
Defensa: hay que evitar operaciones no-atómicas si pueden tener implicaciones
de seguridad, si no se está seguro de sí una operación es atómica, se asume que el
sistema operativo puede ejecutarla en dos pasos o más pasos interrumpibles.
o Ataque con sniffer. Un sniffer es un software que captura los paquetes del
tráfico de la red con el objetivo de capturar nombres de usuario y passwords que
se transmiten en claro. Defensa: hay que usar protocolos seguros de
autenticación en la validación de los usuarios de las aplicaciones. Secuestro de
sesiones. Este tipo de ataque explota las debilidades del protocolo TCPIP
secuestrando una conexión establecida.
» Nivel de implementación
o Ataque de buffer overflow. No hacer comprobaciones de la longitud de los

campos de entrada de una aplicación puede dar lugar a un desbordamiento de la
memoria y redirigir la ejecución a código malicioso que se puede contener en los
datos de entrada mismos. La defensa consiste en hacer comprobaciones de código
fuente para asegurarse que no se van a producir esos desbordamientos.
o Ataque de inyección de SQL. Los ataques de inyección de SQL muy comunes

en aplicaciones WEB, aprovechan la categoría de vulnerabilidades de entradas
invalidadas y consiguen extraer o incluso borrar información de la base de datos

alterando la sentencia de la consulta, porque los campos de entrada no se han

validado y no se diferencian las palabras clave que forman parte de la consulta
SQL de lo que son puramente datos de entrada. La defensa consiste en hacer
comprobaciones de los datos de entrada para asegurarse de que ese contenido no
altera el formato de la consulta.
o Ataques de puerta-atrás. Hay que establecer un adecuado proceso de

aseguramiento de la calidad de código que impida que algún programador
malintencionadamente escriba código que permita que se pueda saltar el control
de entrada como por ejemplo, sería la creación de un usuario que fuera súper-
privilegiado y que por su puesto solo él conoce y que en un futuro podría
aprovechar con el fin de hacerse con el control de la aplicación o cedérselos a
terceros por motivos que pueden ser diversos (económicos, políticos, etc.).
» Nivel de operación
o Ataques de denegación de servicio. Un sistema, un equipo o una red pueden

verse afectados por una cascada de solicitudes de servicio por ejemplo de
peticiones de conexión telnet, ftp, http a tan alta frecuencia, que, pasado un
tiempo debido al consumo de memoria de cada intento de conexión, se puede
llegar a la caída del sistema. Por ello hay que activar sistemas de monitorización
que alerten de esos intentos de conexión masivos y limitar el uso de los recursos.
o Ataque aprovechando configuraciones por defecto. Al comienzo cuando

se instalan sistemas operativos, servicios o aplicaciones hay que deshabilitar las
cuentas de usuario por defecto o también servicios como servidores web en
encaminadores, conmutadores, también servidores tftp, etc. De esta forma se
evitan muchos ataques por configuraciones por defecto conocidas por ser
estándar por diseño.
o Ataque por descubrimiento de contraseñas. También ataque por craking

de passwords, debido a malas elecciones de las passwords y utilización de
programas que utilizan algoritmos y diccionarios que terminan por crackear las
passwords almacenadas como hash en los ficheros shadow de unix o sam de
Windows. Para protegerse de estos ataques hay que diseñar las aplicaciones de tal
manera que se exijan contraseñas robustas con combinaciones de números,
letras, mayúsculas, minúsculas que no tengan sentido alguno y si es posible aún

mejor utilizar tarjetas PKI con certificados digitales que permitan utilizar una
autenticación de cliente con el protocolo SSL u otro similar.
Pilares para la seguridad de las aplicaciones online
Esta asignatura pretendemos introducir los pilares de la seguridad de las aplicaciones y

adentrar un poco más en las actividades de seguridad que se realizan una vez
desplegada la aplicación en online, como son los test y análisis de seguridad y las
operaciones de seguridad.
Como base para acometer la seguridad online se abordarán los diseños seguros de los
servicios de autenticación, gestión de sesiones seguras y autorización. Otras actividades
como la derivación de requisitos de seguridad, modelado de amenazas, análisis y
gestión del riesgo y revisión de la seguridad del código se estudiarán en otras
asignaturas como puede ser seguridad en el software.
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 implantación de una política de
seguridad que define un Sistema de Gestión de Seguridad de la Información
(SGSI). Una política de seguridad bien definida e implantada en una organización
gestionada por procesos regula y gobierna los procesos y procedimientos que han de
implementarse en toda organización y que 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 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 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 producción que debe ser otro de los pilares
fundamentales.

Por tanto, se puede considerar que los pilares fundamentales para el diseño e
implementación de la seguridad de las aplicaciones son tres:
» Política de seguridad.
» Sistema de Gestión de Seguridad de la Información.
» Ciclo de vida de desarrollo seguro de software.
» Monitorización continua.
1.3. Ciclo de vida de desarrollo seguro de software
La seguridad de la aplicación tiene que tratarse obligatoriamente, desde el principio, en

todas las fases de del ciclo de vida 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 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.
Actividades de seguridad en el SSDLC:
» La primera actividad es derivar los requisitos de seguridad y casos de abuso

de la aplicación que modelan las amenazas que esta pueda sufrir junto con el
análisis de riesgos de los sistemas de la organización teniendo en cuenta la
ubicación específica de la aplicación.
» Hay que diseñar la seguridad de la aplicación en base a los requisitos de seguridad y
casos de abuso de la fase 1 y de los principios de seguridad: 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.
También en esta fase se tienen en cuenta los requisitos de seguridad resultado del
análisis de riesgos que se realiza a través de las fases de análisis y diseño.
» Se planifican las pruebas funcionales de seguridad basadas en el nivel del
riesgo obtenido.
» 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 realiza un análisis de seguridad del código fuente con la ayuda
de herramientas de análisis estático de código fuente.

» Se prueba la seguridad del código y funcional de seguridad de la aplicación

utilizando las pruebas funcionales de seguridad planificados previamente
basado en el nivel de riesgo obtenido con técnicas de caja blanca y de caja negra.
Estás pruebas pueden conducir a un ciclo volviendo a la primera fase para definir
nuevos requisitos o redefinir los existentes para solucionar problemas encontrados.
» Se despliega la aplicación aplicando configuraciones de seguridad obtenidas de
estándares y se prueba la aplicación mediante pruebas de penetración,
utilizando herramientas de caja negra, caja blanca o híbridas.
» En la fase de producción de la aplicación online, objetivo principal de esta
asignatura, las prácticas de seguridad que se llevan a cabo corresponden con las
operaciones de seguridad del ciclo de vida de desarrollo de aplicaciones
mencionado anteriormente.
Tienen que ver con continuar asegurando una correcta configuración de todos los
elementos y partes que intervienen en la aplicación como son:
o Administración de las configuraciones de los parámetros que afectan a la
seguridad de toda la aplicación, contenidos en los archivos correspondientes al
servidor de aplicaciones, aplicación y base de datos.
o Gestión y administración de la autenticación, autorización y control de accesos.
o PKI para gestión de certificados digitales: Establecimiento de conexiones seguras.
o Política de gestión de contraseñas. Monitorización continua, auditoría y gestión
de logs: SIEM, IDS, IPS, Firewall de red, etc.
o Mecanismos de protección externos como firewall de aplicaciones web (WAF), de
bases de datos, firewalls XML o herramientas de protección de vulnerabilidades
en tiempo real (RASP) que ofrecen ya varias empresas como Fortify HP
(SecuirtyScope) o IBM (Appscan standard editon IAST).
o Gestión de backups y de desastres. Centro de respaldo.
o Gestión de incidentes de seguridad.
Normalmente, se supone que se está inmerso en una organización, que tiene definida
una política de seguridad con lo que esto implica y que se tienen 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
de esta manera se planifica y gestiona adecuadamente y se sigue un modelo de ciclo de
vida adaptado a las características del proyecto. Se tiene el apoyo también de un equipo
de seguridad que puede asesorar en todas y realizar incluso algunas de las actividades y

procedimientos relacionadas con la seguridad en el ciclo de vida y a continuación se

presentan varios modelos de ciclo de vida que se pueden aplicar igualmente a modelos
de ciclo de vida en espiral, extreme programming, proceso unificado de rational, etc.
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.
Figura 2. Modelo de SSDLC. Fuente: Chess y West, (2007).
La figura, muestra un ejemplo de ciclo de vida de desarrollo de software SSDLC donde

se especifican las actividades y pruebas de seguridad a efectuar en cada fase del mismo.
A continuación, se enumeran esas actividades, mejores prácticas o touchpoints en
orden de eficacia e importancia según el autor:
» Revisión de código
» Análisis de riesgo arquitectónico
» Pruebas de penetración
» Pruebas de seguridad basados en riesgo
» Casos de abuso
» Requisitos de Seguridad
» Operaciones de Seguridad
» 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 software. Por esa razón, la revisión de código
viene antes de análisis de riesgos arquitectónico.
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 implica 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.
» Nuevos defectos de implementación de partes que se modifican con arreglo a
nuevas especificaciones o cambios en las mismas implican nueva revisión de código
y nuevas pruebas de seguridad en operación del sistema.
Por supuesto, siempre hay que continuar con la formación en seguridad, que
proporciona un mecanismo de prevención por ejemplo si los desarrolladores de código
se forman en como validar los campos de entrada salida de la aplicación. Documentar,
realizando cuantificación y análisis de métricas de seguridad que se puedan emplear en
futuros proyectos para mejorar.
1.4. Vulnerabilidades de seguridad en aplicaciones web
Las vulnerabilidades del software son simplemente debilidades en un sistema que los
atacantes pueden aprovechar para obtener alguna ventaja. En el contexto de la
seguridad del software, las vulnerabilidades son defectos o descuidos específicos en
una parte del software que 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 comportamiento inesperado y típicamente indeseable. Se
puede afirmar que para que una vulnerabilidad (debilidad en el diseño, código,
configuración, protección online de una aplicación) se materialice en una aplicación y

se genere un impacto de negocio para la organización, es necesario que intervengan una

serie de factores, ver figura siguiente:
» 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.
» Impacto en el negocio de la organización.
Figura 3. Materialización de una amenaza: Ataque.

Fuente: https://www.owasp.org/index.php/File:Top_10_2013-appsec-risks.png
En este apartado se van a referir 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.
Owasp Top Ten 2017
Según el proyecto Owasp Top Ten 2017

(https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project), los
problemas 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 pérdida de
autenticación y gestión de sesiones. La lista enumera los 10 problemas de seguridad
más comunes 2017 (ver figura siguiente), 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 ataques sufridos en los últimos años.

Figura 4. OWASP TOP TEN 2017 versus 2013.

Fuente: https://www.owasp.org/images/5/5e/OWASP-Top-10-2017-es.pdf
A continuación, se describen los problemas más importantes de seguridad OWASP TOP

TEN 2017 según su sitio web.
» 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
la URI o archivos internos en servidores no actualizados, escanear puertos de la
LAN, ejecutar código de forma remota y realizar ataques de 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.
» 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 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 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 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.
En la cima del top 10 se encuentran aquellas vulnerabilidades que son del tipo
inyección. Estas vulnerabilidades suelen explotarse por errores en la
programación de las consultas. En segundo lugar, y subiendo desde la tercera
posición, se encuentran las vulnerabilidades de pérdida de autenticación. En este caso
se apunta a errores en el diseño donde los atacantes pueden comprometer tokens y
contraseñas o incluso explotar vulnerabilidades dentro de la aplicación.
El caso de XSS sigue permaneciendo dentro de las vulnerabilidades más comunes.

Suelen verse ataques web XSS que aprovechan la falta de controles en la validación de
los datos ingresados por el usuario.
El resto de las vulnerabilidades que componen el ranking incluyen tanto fallas en el

diseño de aplicaciones como también errores netamente de las personas que
administran las mismas. Uno de los puntos que vale pena destacar es el referido a las
malas configuraciones ubicada en la posición 6. En muchos casos, existen
configuraciones inadecuadas por parte de los administradores, o incluso,
configuraciones por defecto que no se adecuan al contexto de los sistemas y pueden
derivar en el compromiso del sistema.

1.5. Arquitecturas y tecnologías de desarrollo de las aplicaciones

web
Las tecnologías más comúnmente empleadas en el desarrollo de

aplicaciones web, incluyen diferentes lenguajes y plataformas como son C/C++,
J2EE, ColdFusion, PHP y .NET, que se encuentran entre las más utilizadas hoy en día.
Según Tiobe (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html),
los 10 lenguajes de programación más utilizados, en general, hasta diciembre de 2018
son los referenciados en la tabla. Dentro de esta tabla, se encuentran tres de los
lenguajes mencionados más utilizados en el desarrollo de aplicaciones web.
Dec 2018 Dec 2017 Change Programming Language Ratings Change

1 1 Java 15.932% +2.66%
2 2 C 14.282% +4.12%
3 4 Python 8.376% +4.60%
4 3 C++ 7.562% +2.84%
5 7 Visual Basic .NET 7.127% +4.66%
6 5 C# 3.455% +0.63%
7 6 JavaScript 3.063% +0.59%
8 9 PHP 2.442% +0.85%
9 - SQL 2.184% +2.18%
10 12 Objective-C 1.477% -0.02%
Tabla 1. Indicador de popularidad de los lenguajes de programación. TIOBE. Fuente: Basado en
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Teniendo en cuenta solo los lenguajes utilizados en el desarrollo de aplicaciones web,

en Veracode report volumen 9, en su publicación sobre el estado de la seguridad del
software, se observa que el 53 % de los lenguajes utilizados en las aplicaciones web que
esta empresa analizó durante año y medio hasta abril de 2011, fue JAVA, seguido de
.NET con un 26 %. En el mismo informe se desprende que del total de las aplicaciones
analizadas el 75 % fueron aplicaciones web.
Esto da una idea de la magnitud del auge del desarrollo de este tipo de aplicaciones y
del volumen de negocio que suponen y que hace que sean principal objetivo con ánimo
de lucro. La motivación de este trabajo parte de esta estadística como base que
demuestra la trascendencia que tiene poner gran esfuerzo en estudiar como securizar el
gran volumen de aplicaciones web que se desarrollan. En la figura 4, se representan las
ratios de utilización de aplicaciones web y los lenguajes más empleados en su

desarrollo. Veracode es una empresa que ofrece sus servicios para análisis de seguridad
de aplicaciones.
Figura 5. Lenguajes empleados desarrollo web. Fuente: Veracode SOSS, Volume 9.
En la figura 5, como resultado del informe del estado de la seguridad del software,
volumen 9, publicado por Veracode, se presenta la distribución del desarrollo de
software atendiendo a su suministrador, interno, open-source, Commercial,
Outsourced. Interesante la observación de que casi la tercera parte del volumen de
desarrollo procede de terceras partes, comercial y open source. Hay que tener en
cuenta que en algunos de estos casos no se dispondrá del código fuente y hay que tener
en cuenta que la comprobación de seguridad de ese código pasa por disponer de
determinadas herramientas o servicios que sean capaces de analizar código binario de
forma estática o dinámica. La elección o combinación de las mismas se analizará en un
tema posterior.
Figura 6. Tipos de suministradores de software. Fuente: Veracode SOSS, Volume 9.

En la figura siguiente, se observa el porcentaje de aplicaciones analizadas que pasaron

el análisis de seguridad teniendo como referencia SANS TOP 25 y OWASP TOP TEN en
resultado del informe del estado de la seguridad del software, volumen 9, publicado
por Veracode, solamente un 22,5 % pasan el primer scan con OWASP TOP TEN como
referencia base.
Figura 7. Porcentaje de aplicaciones vulnerables. Fuente: Veracode SOSS, Volume 9.
Tecnologías de desarrollo web. Evolución
La evolución de las tecnologías web ha estado fundamentalmente marcada por la

aparición sucesiva de las siguientes tecnologías: 1)Http, 2)Common Geteway interface
(CGI), 3)lenguajes de Scripts, especificaciones y 4)marcos de desarrollo de aplicaciones
web.
1. Http
El protocolo HTTP no fue diseñado para aplicaciones y seguramente no para usos

seguros. HTTP tiene vulnerabilidades de seguridad de la misma forma que funciones de
string de la biblioteca estándar de C permiten el desbordamiento de buffer: Los
programadores tienen que tener su modo de asegurarse de que lo que hacen es seguro.
El protocolo HTTP implementa una serie de métodos especificados en HTTP 1.1 rfc
2616. 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 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 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.
» 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.
En la siguiente figura se observa cómo se puede especificar un método http.

Figura 8. Métodos http
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 9. Métodos 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 10. Métodos HTTP POST

Figura 11. Métodos POST vs GET
Procedencia de peticiones: si la aplicación usa un identificador de sesión (cookie)

con un formulario (administración) para crear un usuario:
Figura 12. Procedencia de peticiones CSRF.
Un atacante podría tener un sitio web con:
Figura 13. 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 14. Procedencia de peticiones. Protección CSRF.
Otras vulnerabilidades que se pueden presentar en el protocolo HTTP es la

vulnerabilidad http response spliting
(https://www.acunetix.com/websitesecurity/crlf-injection/) que consiste en incluir
caracteres \r\n de retorno de carro y de línea para generar una respuesta doble que se
ejecutarán en el navegador del usuario permitiendo lanzar otros ataques como XSS:
Figura 15. HTTP Response Spliting. Fuente: https://www.acunetix.com/websitesecurity/crlf-injection/
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 16. HTTP Response Spliting. Fuente: https://www.acunetix.com/websitesecurity/crlf-injection/
El problema de 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.
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.
Esto quiere decir que la seguridad de la aplicación depende de ello siendo muy difícil
para un atacante aprovechar el identificador de sesión para un usuario autenticado.
2. Common Geteway interface (CGI)
Las aplicaciones web en un principio se diseñaban con contenido estático, lo cual no

permitía al usuario interactuar con el cliente. Para solucionar este problema se
comenzaron a diseñar las aplicaciones web de forma que pudieran llamar a un
programa externo y que devolvía a su vez la respuesta. Common Gateway
interface (CGI) ches9] es un ejemplo de marco de desarrollo de programas externos
escritos en C/C++ que pueden ser llamados por las aplicaciones web. Con esta
tecnología el tiempo de desarrollo es mayor, rendimiento menor, no tiene controles de
sesión ni de autorización y, sobre todo, hay que tener en cuenta que C/C++ es lenguaje
no seguro, que no comprueba implícitamente tamaños de variables y tipos, sufriendo
desbordamientos de memoria y otros problemas de seguridad. Como consecuencia de
esto, el programador habría de tener formación en seguridad para evitar cometer
vulnerabilidades de seguridad.
3. Lenguajes de Scripts
La siguiente evolución en el desarrollo de aplicaciones web conduce a los lenguajes de

script que son interpretados en tiempo de ejecución ahorrando tiempo de desarrollo al
no tener que ser compilados. Tienen la ventaja en comparación con los CGI, de
tener menos problemas de seguridad debido a desbordamientos de memoria.
Sin embargo, encontramos que el tiempo de ejecución aumenta en relación a lenguajes

compilados y las aplicaciones desarrolladas con lenguajes de script tienen menos
escalabilidad, seguridad y resultan más difíciles de mantener.

Por ejemplo, estos son algunos de los ejemplos de tecnologías de script más utilizadas
hoy en día.
» ASP (http://msdn.microsoft.com/en-us/library/aa286483.aspx).
» Perl (http://www.perl.org/).
» ColdFusion (http://www.adobe.com/es/products/coldfusion/).
» Y PHP (http://www.php.net/).
» JavaScript (http://es.wikipedia.org/wiki/JavaScript)
JavaScript es un lenguaje de programación interpretado orientado a objetos,

imperativo, débilmente tipado y dinámico. Se utiliza principalmente en el lado del
cliente, por tanto, los navegadores web tienen normalmente soporte para interpretar y
ejecutar código javascript. Principalmente introduce mayores capacidades en la
interfaz de usuario mediante la creación de páginas web de tipo dinámico en
contrapartida a las páginas HTML de las aplicaciones web de primera generación cuyo
contenido era estático. JavaScript tiene una sintaxis similar al lenguaje C, aunque
adopta nombres y convenciones del lenguaje de programación Java.
Para interactuar con una página web JavaScript dispone de una implementación del
Document Object Model (DOM). JavaScript, normalmente, se interpreta en el lado del
cliente por el navegador incluido en código HTML que se descarga del servidor de
forma síncrona. En arquitecturas más recientes, como AJAX, se carga un motor de
javascript que interactúa por un lado con el usuario para modificar dinámicamente la
interfaz del usuario y por otro lado de forma asíncrona con el servidor para obtener
datos necesarios para presentación permitiendo hacer otras tareas mientras se sirve la
petición y evitando tiempos muertos y páginas de espera que sufre el usuario con
las tradicionales aplicaciones web.
4. Especificaciones y marcos de desarrollo de aplicaciones web
Actualmente, para implementar aplicaciones web es necesario usar una plataforma de

desarrollo capaz de proporcionar ciertos servicios a los diseñadores de soluciones y a
los programadores. Estas plataformas de desarrollo deben facilitar y automatizar lo
más posible el ciclo de vida completo de las aplicaciones y deben tener en cuenta que
los usuarios finales, no solo son los clientes de las aplicaciones desarrolladas, sino
además otros desarrolladores de soluciones que pueden usar los componentes
modulares generados por el desarrollo distribuido y que puede ofrecer a los clientes.

Esta última característica se engloba dentro del llamado B2B (Business To Business),
del cual el máximo exponente son los llamados servicios Web. En otra sección de estos
apuntes se analiza con más profundidad esta tecnología.
Los requisitos de estas plataformas de desarrollo deben ser:
» Escalabilidad: Ha de ofrecer una buena escalabilidad tanto horizontal como

vertical de modo que si aumenta la carga del sistema podamos añadir servidores o
ampliar los existentes sin que sea necesario realizar modificaciones.
» Mantenibilidad: Ha de permitir añadir, modificar o eliminar componentes

existentes sin que se modifique el comportamiento del sistema.
» Fiabilidad: Debe ser capaz de seguir ofreciendo servicios a sus clientes a pesar de
posibles fallos de los componentes del sistema.
» Disponibilidad: Debe tener el soporte de arquitecturas tolerantes a fallos,

sistemas de redundancia, etc., que aseguren que los sistemas estarán siempre
disponibles.
» Extensibilidad: Ha de ser posible añadir nuevos componentes y capacidades al

sistema sin que se vean afectados el resto de los componentes.
» Manejabilidad: Los sistemas han de ser fácilmente manejables y configurables.
» Seguridad: Se han de proporcionar buenos sistemas de seguridad tanto a nivel de

autenticación, como de autorización y como de transporte.
» Rendimiento: Se ha de ofrecer automáticamente soporte de clustering, balanceo

de carga, pools de objetos, pools de conexiones, caches, y en general mecanismos
que permitan aumentar el rendimiento de manera transparente al usuario.
En la actualidad las plataformas más importantes son aquellas que disponen del
apoyo de gran cantidad de empresas, entidades o asociaciones y que disponen de
grupos de estandarización que aseguren su futuro. Ahora mismo las plataformas más
importantes son:

» .NET. La plataforma de desarrollo empresarial de Microsoft tiene algunas ventajas

importantes:
o Soporte de múltiples lenguajes: Aunque no soporte todas sus características,
lo cierto es que con .NET es posible desarrollar aplicaciones utilizando
simultáneamente varios lenguajes de programación.
o Ideal para entornos Microsoft: Si en nuestra empresa disponemos de gran
cantidad de software y hardware dependiente de Microsoft, probablemente la
mejor opción para continuar desarrollando sea esta plataforma, ya que su
integración con los productos de la empresa es perfecta.
o Visual Studio .NET: La plataforma .NET dispone de esta gran herramienta que
además de su potencia ofrece un entorno homogéneo de desarrollo.
o Requiere desarrolladores poco experimentados: Bajo la plataforma de
desarrollo de Microsoft es posible utilizar lenguajes como VB .NET que hacen
muy sencilla la creación de aplicaciones empresariales. De este modo es posible
tener un equipo de desarrolladores poco experimentados y sin embargo que estos
puedan crear fácilmente aplicaciones.
Pero también posee algunas desventajas como:

o No soporta múltiples sistemas operativos: El mundo de .NET gira en torno
al sistema operativo Windows y aunque se están intentando trasladar partes
importantes de la plataforma, como el CLR (Common Language Runtime) o C#, a
otros sistemas operativos, lo cierto es que estas partes forman una parte ínfima
de la totalidad de la plataforma de Microsoft.
o Un único dueño: La plataforma .NET está dominada única y exclusivamente
por Microsoft. Esto supone un grave problema ya que es una única empresa la
que puede añadir y quitar características según crea conveniente. Además, esto
hace que la competencia sea nula y no se estimula la evolución de la plataforma.
o Es una tecnología inmadura: Con tan poco tiempo en el mercado, apenas ha
salido algún proyecto importante desarrollado con esta tecnología. Su inmadurez
hace que probablemente deba pasar algún tiempo hasta que sea realmente
productiva.
o Pocas soluciones libres: No existe una correspondencia exacta entre las partes
de la plataforma .NET y soluciones libres. Existen proyectos como Microsoft
Linux core .Net, Mono [14] o dotGNU que están portando algunas de sus partes.

» J2EE. J2EE (http://www.jcp.org/en/jsr/detail?id=151), plataforma creada por SUN

en el año 1997, ofrece entre otras las siguientes ventajas:
o Soporte de múltiples sistemas operativos: Al ser una plataforma basada en
el lenguaje Java, es posible desarrollar arquitecturas basadas en J2EE utilizando
cualquier sistema operativo donde se pueda ejecutar una máquina virtual Java.
o Organismo de control: La plataforma J2EE está controlada por el Java
Community Process (http://www.jcp.org) que es un organismo formado por más
de 500 empresas.
o Entre las empresas que lo forman están todas las más importantes del mundo
informático (SUN, IBM, Oracle, SAP, HP, AOL, etc.) lo que garantiza la evolución
de la tecnología.
o Competitividad: Muchas empresas crean soluciones basadas en J2EE y ofrecen
características como rendimiento, precio, etc., muy diferentes. De este modo el
cliente tiene una gran cantidad de opciones a elegir.
o Madurez: Creada en el año 1997 como respuesta a la tecnología MTS de
Microsoft, J2EE tiene ya varios años de vida y una gran cantidad de proyectos
importantes a sus espaldas.
o Soluciones libres: En la plataforma J2EE es posible crear arquitecturas
completas basadas única y exclusivamente en productos de software libre. No
solo eso, sino que los arquitectos normalmente disponen de varias soluciones
libres para cada una de las partes de su arquitectura.
La plataforma de J2EE también tiene desventajas, algunas importantes:

o Depende de un único lenguaje: La plataforma J2EE depende exclusivamente
del lenguaje Java. Solo se puede utilizar este lenguaje para desarrollar
aplicaciones lo que puede suponer un gran problema si nuestro equipo no
dispone de los conocimientos suficientes o tiene otras preferencias.
o Complejidad: no existe un VB .NET en Java. La creación de aplicaciones bajo
J2EE requiere normalmente desarrolladores más experimentados que los
necesarios para desarrollar bajo .NET
o Heterogeneidad: Existe una gran heterogeneidad en las soluciones de
desarrollo. No existe en J2EE un símil a Visual Studio .NET. La gran cantidad de
herramientas disponibles causa confusión dentro de los desarrolladores y puede
crear dependencias dentro de las empresas.
o Hay muchas implementaciones de J2EE disponibles
(http://java.sun.com/javaee/overview/compatibility.jsp)

La plataforma es un factor determinante a la hora de elegir entre J2EE y .NET

(Garrido, 2006). Las aplicaciones J2EE teóricamente pueden ser ejecutadas en muchas
plataformas de Linux, AIX, MacOS X, o Windows. .NET se encuentra disponible
principalmente en plataformas Microsoft Windows. El proyecto Mono
(http://www.go-mono.com/) tiene como objetivo extender .NET a otras plataformas
como Solaris o Linux.
Construcción de aplicaciones seguras con J2EE y .NET
Existen pocas razones para elegir J2EE o .NET desde la perspectiva de la seguridad o
de rendimiento en general. De entre los muchos estudios comparativos entre ambas
tecnologías se puede citar el trabajo de J. Padilla y J. Pérez (2009-2010) o la tesis de
Manuel Garrido (2006), donde se pueden encontrar detalles más concretos relativos a
seguridad. J2EE y .NET tienen diferentes enfoques para implementación de la
seguridad.
» .NET proporciona servicios de autenticación y autorización a través del sistema

operativo.
» J2EE proporciona los servicios de autenticación y autorización mediante la
especificación JAAS (Java Authentication and Authorization Service).
Independientemente de las facilidades que proporcionan las tecnologías existentes en

cuanto a aspectos de seguridad como la autenticación, autorización y accesos a
los recursos, el aspecto de seguridad que se aborda en este trabajo es el estudio de las
vulnerabilidades existentes en el código y su detección automática antes del despliegue
de una aplicación en producción incluyendo las tareas de detección de vulnerabilidades
en el ciclo de vida de desarrollo de software transformándose un ciclo de vida de
desarrollo seguro como el modelo descrito en Building Security In (Chess y West,
2007).
Se abordarán estos problemas de seguridad debido a vulnerabilidades existentes en el

código derivadas de validaciones y mecanismos de autorización deficientes o
inexistentes. Las diferencias en este sentido, que puedan inducir en la elección de una
tecnología u otra, las pueden marcar las características inherentes al lenguaje utilizado
por una especificación concreta. Conviene utilizar un lenguaje de programación que
fuerce la comprobación de tipos y de memoria de forma que su gestión sea segura. C#,

Java, Python, Ruby o dialectos de C como CCured y Cyclone son lenguajes de

este tipo.
Se usa el término safe 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. 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.
Java es un lenguaje esencialmente seguro, según afirma Long (2005):
» No tiene explícita manipulación de punteros.

» Límites de arrays, strings se comprueban automáticamente.
» Intentos de referencias a un objeto null se capturan.
» Las operaciones aritméticas están bien definidas.
» Control de acceso a ficheros, sockets mediante JVM -> Security Manager.
La frecuencia de vulnerabilidades encontradas en análisis de seguridad de

aplicaciones web (>28k) según el informe de VERACODE volumen 9, se reflejan en la
figura:

Figura 17. Vulnerabilidades: frecuencia. Fuente: https://info.veracode.com/report-state-of-software-

security-volume-9.html
Arquitecturas y patrones de diseño de aplicaciones web
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
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.
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. Estas 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 las
interfaces y la reutilización de objetos. El 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.
Las capas de que se compone una aplicación web (figura 18) son:
» Clientes Web: Navegador.

» Capa de presentación, capa de aplicación (lógica de negocio): servidores web
(Apache, IIS, etc.), Servidor de aplicaciones web (Weblogic, Tomcat, WebSphere,
Struts, .NET, ColdFusion, etc.).
» Capa de persistencia: base de datos (Oracle, MS SQL Server, MySQL,
PostgreSQL, etc.).
Figura 18. Arquitectura de 3 capas de aplicaciones web.
Una arquitectura de navegador modular es la que implementa Google

Chrome, si un navegador tiene una estructura modular, cada aplicación es ejecutada

en su propia sandbox (caja o módulo) con privilegios restringidos a medida (Windows

restricted security token) no afecta a las demás aplicaciones en otros procesos y se
comprueban intentos de acceso al esquema file:///... como se puede ver en la
arquitectura de Chrome, figura 19.
Figura 19. Arquitectura Modular de Chrome.
Uno de los patrones de diseño de las aplicaciones web más comunes es el Modelo-
Vista-Controlador (MVC), http://www.jtech.ua.es/j2ee/publico/spring-2012-
13/sesion03-apuntes.html
MVC se implementa por ejemplo en:
» Las arquitecturas de aplicaciones J2EE comoApache Foundation Jakarta Struts.

» WACT [22] para PHP. https://www.comentum.com/guide-to-web-application-
development.html
» .NET, rubí, phyton disponen de frameworks para implementación de MVC.
http://es.wikipedia.org/wiki/Modelo_Vista_Controlador
MVC posee tres capas: Vista – Modelo – Controlador.
» Vista. Es la capa que se ocupa de generar la presentación al usuario, en aplicaciones

web, la vista se compone de páginas HTML que componen la interface de usuario.
Como se señaló anteriormente pueden incluir código javascript que interpretará el
navegador. Los usuarios a través de la interfaz de la aplicación web 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, sobre todo, la

información de autenticación que se puede enviar dentro de las peticiones o
cualquier otra información que pueda comprometer la seguridad de la aplicación y
todos los aspectos que conciernen a la interpretación de lenguajes de script por parte
del navegador que, si se permiten, hay que validar, ya que constituyen una potencial
fuente de ataque; ver Kirda et Ku. 2006. En la figura siguiente, se representa un
esquema del patrón MVC para J2EE.
Figura 20. Esquema del patrón MVC para J2EE.

Fuente: http://www.programacion.com/articulo/manual_basico_de_struts_156
» Controlador. Recoge las peticiones de los usuarios (servlet) para seleccionar el

código de aplicación o lógica de negocio encargado de servir las peticiones de los
usuarios. En tecnología J2EE, son JSP,s (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.
En cuanto al apartado de seguridad, es necesario realizar aquí 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 forgering, 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, test de penetración y otras actividades.
Al final, por si acaso, quedará la opción de la protección online que se aplique y
también tiene que ser diseñada desde el principio.
» Modelo. El modelo es la capa de la aplicación que se ocupa de los datos que

necesita la aplicación y los accesos a los mismos. 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
encargan de la llamada al sistema gestor de base de datos para extraer, insertar,
actualizar o borrado de información.
En el apartado de seguridad es necesario aquí comprobar las cadenas de datos que

conforman las consultas de datos y escapar aquellos caracteres que puedan
conducir a la materialización de ataques de inyección de SQL o de Cross Site
Scripting persistente, es decir, se puede extraer información que reside en la base de
datos que puede derivar en un ataque XSS.
Si se accede a un repositorio o fichero XML, es necesaria igualmente la validación

para comprobar su correspondiente DTD o esquema y también para evitar inyección
XML. La formación de las consultas de datos a través de sentencias parametrizadas
que poseen los entornos de desarrollo es preferible, porque separan las palabras
clave de los datos de la consulta evitando inyección de SQL. Por tanto, hay evitar que
se puedan crear consultas de forma dinámica que tienen alta probabilidad de ser
inseguras. Estas formas de ataque se verán más adelante y en otras asignaturas.

Web 2.0: Ajax, JSON, flash
Las tecnologías (J2EE, .NET, PHP…) comentadas para el desarrollo de aplicaciones

web incorporan constantemente nuevas especificaciones que tienen que ser estudiadas
y analizadas exhaustivamente para comprender como pueden afectar a la seguridad y
que nuevas vulnerabilidades o modalidades de ellas pueden introducir a la aplicación
que se está desarrollando. Especificaciones RIA (Rich Internet Applications) como
AJAX (ver Connolly, 2008, JSON, http://json.org/json-es.html, FLASH) son algunas
de estas tecnologías cuyo uso está incrementándose y consecuentemente suponen una
nueva fuente de problemas de seguridad en forma de vulnerabilidades en el código y
que hay que detectar y corregir a tiempo. En Cannings 2008 [28], Scambray 2011 [29]
se tratan las debilidades de la nueva generación de aplicaciones web: WEB 2.0
centrándose en los tipos de ataques en aplicaciones que utilizan AJAX o FLASH.
AJAX, es un conjunto de tecnologías que incluyen javascript asíncrono junto con

XML, XSLT, XHTML, DOM. Una aplicación AJAX elimina 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 entre el usuario y el servidor.
Parecería que sumar una capa a la aplicación la haría menos reactiva, pero es todo lo
contrario.En lugar de cargar una página web, en el inicio de la sesión, el navegador
carga un motor Ajax escrito en JavaScript y usualmente escondido en un frame oculto.
Este motor es responsable de procesamiento tanto de la interfaz que el usuario ve y la
comunicación con el servidor en nombre del usuario El motor de Ajax permite la
interacción del usuario con la aplicación de forma asincrónica independientemente de
la comunicación con el servidor. De esta forma el usuario no queda esperando la
respuesta del servidor.
Cada acción del usuario que normalmente generaría una petición HTTP toma la forma
de una llamada JavaScript 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. Si el motor necesita algo del servidor con el fin de
responder-si se trata de comunicación de datos para el procesamiento, la carga de
código de interfaz adicional, o recuperación de nuevos datos, el motor hace esas
peticiones de forma asíncrona, normalmente, usando XML, sin que se cale interacción
de un usuario con la aplicación (figura siguiente).

Figura 21. Ajax frente al esquema tradicional de aplicaciones web.

Fuente: http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications
Las aplicaciones AJAX son vulnerables al rango completo de vulnerabilidades de las

aplicaciones web tradicionales. Las prácticas de programación insegura pueden llevar a
vulnerabilidades de inyección SQL, la confianza en la entrada de datos por el usuario
puede llevar a vulnerabilidades de manipulación de parámetros y un fallo al requerir
una autenticación y autorización apropiadas puede llevarnos a problemas de
confidencialidad e integridad.
Además, las aplicaciones AJAX pueden ser vulnerables a nuevas clases de ataques
como la suplantación cruzada de peticiones entre sitios web (Cross Site Request
Forgery (CSRF)).
» JSON. (Notación de Objetos de JavaScript) [26]. Es un formato de intercambio de

datos que se utiliza para comunicación entre las capas de cliente y servidor de una
aplicación web entre otros. La simplicidad de JSON ha dado lugar a la
generalización de su uso, especialmente como alternativa a XML en AJAX. Una de
las supuestas ventajas de JSON sobre XML como formato de intercambio de datos
en este contexto es que es mucho más sencillo escribir un analizador sintáctico
(parser) de JSON. En JavaScript, un texto JSON se puede analizar fácilmente
usando la función eval(), lo cual ha sido fundamental para que JSON haya sido

aceptado por parte de la comunidad de desarrolladores AJAX, debido a la ubicuidad

de JavaScript en casi cualquier navegador web.
» FLASH. Una de las tecnologías emergentes en los últimos tiempos enfocadas al

enriquecimiento de las interfaces de clientes de las aplicaciones web es FLASH de
Macromedia. Esta tecnología incorpora novedades como:
o Animaciones con gráficos vectoriales que permiten un aumento del
rendimiento por la menor carga de procesamiento que añaden en comparación
con otro tipo de animaciones.
o Incorpora la posibilidad de streaming multimedia que permite visualizar
animaciones en tiempo real descargadas desde otra ubicación.
o Incorpora un lenguaje de programación orientado a objetos, ActionScript
para permitir desarrollar las interfaces de usuario enriquecidas con las
posibilidades multimedia mencionadas anteriormente.
Por defecto, el modelo de seguridad de FLASH es similar a la política del mismo

origen origen, es decir, FLASH puede leer las respuestas solo desde el mismo
dominio en el que la aplicación FLASH se originó. FLASH también se asegura de que
todo el envío de peticiones HTTP, pero se suelen hacer de peticiones GET entre
dominios a través getURL() FLASH función. Además, FLASH no permite que las
aplicaciones FLASH que se cargan a través de HTTP, respuestas HTTPS. FLASH
permite la comunicación entre dominios, si una política de seguridad de otro
dominio permite la comunicación con el dominio en el que reside la aplicación
FLASH.
La política de seguridad en un archivo XML suele denominarse crossdomain.xml y

se encuentra normalmente en el directorio raíz del otro dominio. La peor política
archivo desde una perspectiva de seguridad sería:
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
Esta configuración sería una política de seguridad de comunicación abierta.

Las políticas abiertas de seguridad permiten que las aplicaciones maliciosas FLASH
puedan hacer lo siguiente:

o La carga de páginas en el dominio vulnerable anfitrión de la política de seguridad

abierta a través de la Objeto XML. Esto permite al atacante leer datos
confidenciales de los sitios vulnerables, incluyendo tokens de protección CSRF, y
posiblemente cookies concatenados a URL,s (como jsessionid).
o Realizar HTTP GET y POST basados en los ataques CSRF mediante getURL () y el
objeto XML, incluso en presencia de protección CSRF.
1.6. Arquitecturas y tecnologías de desarrollo de los servicios

web
Los principios de diseño de las aplicaciones distribuidas basadas en servicios web

tienen su origen en lo que se denomina Arquitectura Orientada a Servicios (SOA,
Service-Oriented Architecture). Como ejemplos de esta arquitectura se pueden
nombrar tecnologías tan conocidas como RPC, RMI, CORBA o DCOM. En la tabla 3, se
proporciona una comparativa de los servicios y formatos de datos soportados por
distintas tecnologías SOA.
Comparativa Java RMI CORBA Web Services

Mecanismo de
Java RMI CORBA RMI JAX-RPC, .NET,
invocación
Formato de los datos Serialización Java CDR XML
Formato de
Flujo de bits GIOP SOAP
comunicación
Protocolo de
JRMP IIOP HTTP. SMTP, JMS
transferencia
Descripción de la
Interfaces Java CORBA IDL WSDL
Interfaz
Servicio de
Mecanismo de Registro Java
nombres UDDI
descubrimiento RegistroRmi
(COS naming)
Tabla 2. Comparativa de tecnologías SOA.
Protocolo SOAP
Los servicios web (http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb), se

pueden definir como un conjunto de aplicaciones o de tecnologías con capacidad para
interoperar en la web. Estas aplicaciones o tecnologías intercambian datos entre sí con
el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como
procedimientos remotos y los usuarios solicitan un servicio llamando a estos
procedimientos a través de la web (ver figura siguiente).

Estos servicios proporcionan mecanismos de comunicación estándares entre diferentes

aplicaciones, que interactúan entre sí para presentar información dinámica al
usuario. Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones,
y que al mismo tiempo sea posible su combinación para realizar operaciones complejas,
es necesaria una arquitectura de referencia estándar.
Figura 22 Aplicación de cliente. Fuente: http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb
Para la comunicación entre las diferentes entidades o aplicaciones que actúan como
consumidores de servicios o proveedores de los mismos, los servicios web emplean un
protocolo denominado SOAP que tiene la estructura reflejada en la figura siguiente. Los
mensajes SOAP con estructura XML tienen:
» Una envoltura.
» Una cabecera con datos descriptivos.
» Un body o contenido.

Figura 23. Estructura de los mensajes.

Fuente: http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb
WSDL (Lenguaje de Descripción de Servicios Web), es un vocabulario XML

para describir un servicio Web. Un documento WSDL describe qué funcionalidad
ofrece un servicio Web, cómo se comunica y dónde es accesible (es decir, indica el
punto de acceso). WSDL proporciona un mecanismo estructurado que describe:
» Las operaciones que un servicio Web puede realizar.

» Los formatos de los mensajes que puede procesar.
» Los protocolos que soporta.
» El punto de acceso al servicio.
Normalmente cualquier herramienta de desarrollo SOAP puede usar una descripción

WSDL de forma automática para generar un interfaz que se pueda usar (y enlazar) en
una aplicación cliente. Una descripción WSDL define una colección de puntos de acceso
de red o puertos. Cada puerto se define de forma abstracta con su tipo, que soporta
un conjunto de operaciones. Cada operación procesa un conjunto particular de
mensajes. Un enlace (binding) relaciona un tipo de puerto con un protocolo y un
formato de datos.
UDDI. Se necesita un servicio de descripción universal, descubrimiento e

integración, UDDI que proporciona un mecanismo estándar para registrar y
encontrar servicios web. Un registro UDDI contiene la información sobre los negocios

(empresas) y servicios que ofrecen. La información se puede organizar de la siguiente

manera:
» Entidad de negocio. Contiene información sobre el negocio incluyendo su

nombre, una descripción corta y alguna información básica de contacto. Cada
negocio tiene asociado un identificador único y una lista de categorías que describen
el negocio y es posible además añadir nuevas categorías.
» Servicio de negocio. Asociado a la entidad de negocio existe una lista de servicios

ofertados por dicha entidad. Cada servicio de negocio contiene una descripción del
servicio, una lista con las categorías asociadas y una lista de patrones de enlace
contienen información técnica sobre el servicio.
» Patrones de enlace. Proporcionan información sobre cómo usar el servicio y

dónde encontrarlo (por ejemplo, un patrón de enlace puede contener el punto de
acceso a la implementación del servicio). Además, el patrón de enlace asocia el
servicio de negocio con un tipo de servicio.
» Tipo de servicio. Define un servicio de forma abstracta, a través de una estructura

llamada tModel. Varias entidades de negocio pueden ofrecer el mismo tipo de
servicio, soportando la misma interfaz de servicio. Una estructura tModel especifica
información como el nombre del tModel, el nombre de la organización que publica la
estructura tModel, la lista de categorías que describen el tModel y los punteros a las
especificaciones técnicas del tModel. Por ejemplo, un tModel puede apuntar al
documento WSDL que describe el tipo de servicio de forma abstracta.
El proceso de estandarización de UDDI es gestionado por OASIS,

(http://www.oasisopen.org/home/index.php) siendo la versión 3 la última aceptada.
En esta última versión se ha añadido la capacidad de notificación y suscripción, de tal
manera que aquellos clientes que se suscribieron para el uso de un servicio web
recibirán notificaciones de cualquier cambio en el servicio web que usan. Finalmente
hay que decir que UDDI es un registro de propósito general, que puede ser usado para
registrar cualquier tipo de servicio, no solo los servicios Web. UDDI no requiere que los
servicios definan interfaces de tipo SOAP o que estén descritos por documentos WSDL.
De hecho, no existen dependencias entre las tres tecnologías, aunque
funcionan mejor si se utilizan conjuntamente.

El proceso de acceso a un servicio web SOAP es el siguiente:
1. El proveedor de servicios web pública sus operaciones (funcionalidad) en el Servicio

Broker mediante comandos de registro UDDI.
2. El usuario (aplicación consumidora), una vez registrado y autenticado, accede al
Servicio Broker para descubrir las operaciones ofrecidas por el Servicio Web
proveedor, mediante consultas UDDI.
3. Cuando el usuario (aplicación consumidora), decide acceder a cualquiera de las
operaciones del Servicio Web proveedor, obtiene el fichero de descripción de
servicios web WSDL para construir las peticiones SOAP apropiadas para ejecutar las
operaciones.
Servicio
UDDI UDDI
que stion registro re giste r
(broker)
Servicio Servicio
consumidor proveedor
Cliente SOAP (XML) Servicio
Figura 24. Arquitectura Servicios Web.
1.7. Arquitecturas de almacenes de datos
Las aplicaciones web en casi todos los casos necesitarán almacenar datos en más o
menos grandes cantidades. Para proporcionar este servicio normalmente, como ya se
ha visto anteriormente, se añade otra capa a la arquitectura de la aplicación web que
soporta el servicio de almacén de datos como puede ser un Sistema Gestor de Bases
de Datos (SGBD) como Oracle, Sql Server o DB2. También se pueden utilizar
repositorios de datos en formato XML en un fichero de datos que puede ser accedido
por la aplicación o un Directorio LDAP (Lightweight Directory Access Protocol).
Un directorio es un conjunto de objetos con atributos organizados en una manera

lógica y jerárquica. El ejemplo más común es el directorio telefónico, que consiste
en una serie de nombres (personas u organizaciones) que están ordenados

alfabéticamente, con cada nombre teniendo una dirección y un número de teléfono

adjuntos. Para entender mejor, es un libro o carpeta, en la cual se escriben nombres de
personas, teléfonos y direcciones, y se ordena alfabéticamente.
Así como un Sistema de Gestión de Base de Datos como Sybase, Oracle, Informix
o Microsoft se utiliza para procesar consultas y actualizaciones a una base de datos
relacional, un servidor LDAP es utilizado para procesar consultas y actualizaciones a un
directorio de información LDAP. En otras palabras, un directorio de información
LDAP es un tipo de base de datos, pero no es una base de datos relacional y a diferencia de
una base de datos que está diseñada para procesar cientos o miles de cambios por minuto
como los sistemas de procesamiento de transacciones en línea a menudo utilizados en el e-
commerce los directorios LDAP están fuertemente optimizados para el rendimiento en
accesos de lectura.
Sistemas de gestión de bases de datos
Existen varias arquitecturas de Sistema Gestor de Bases de Datos, relacional, de red,

transaccionales, orientadas a objetos, documentales NoSql, jerárquicas, etc. Todas
tienen en común que almacenan datos, difieren en la forma de organizarlos y menos en
los componentes de la arquitectura física, archivos, memoria, procesos. Para
comprender mejor una base de datos necesitamos conocer una arquitectura relacional
muy extendida, como es la de Oracle (https://www.oracle.com/es/index.html). Cuando
se habla de una base de datos no solo nos estamos refiriendo a los datos físicos, sino
también a la combinación de objetos físicos, de memoria y de proceso que se describen
a continuación y que realmente conforman un Sistema Gestor de Bases de Datos
(SGBD).

Figura 25. Arquitectura SGBD Oracle
1. Archivos de datos
Contienen toda la información de la base de datos: datos de usuario y datos de sistema.

Antes de introducir datos en la base de datos, es necesario crear un espacio para las
tablas (tablespace) y después crear una tabla, dentro de ese espacio, en la que
introducir los datos. Los tablespaces nos ayudan a organizar la información contenida
en la base de datos; así, podemos tener un tablespace para almacenar los datos de la
aplicación de almacén, otro para almacenar los datos de la aplicación de nóminas,
etcétera. Cada tablespace consta de uno o más archivos en disco. Un archivo de datos
solo puede pertenecer a un único tablespace. Al instalar Oracle se crean varios
tablespaces, seguón Ramos, Ramos y Montero (2006) algunos son:
» SYSTEM. En él se almacena toda la información que Oracle necesita para

gestionarse a sí misma, por ejemplo: el diccionario de datos. Se almacena en el
archivo SYSTEM01.DBF. En la versión 10g existe el tablespace SYSAUX, que es un
espacio de tablas auxiliar a SYSTEM, y se crea automáticamente. Su misión es
descargar de trabajo a SYSTEM.
» USERS. Contiene información personal de los usuarios. Normalmente, es el lugar

en el que el DBA nos deja almacenar las tablas para realizar pruebas. Se almacena en
el archivo USERS01.DBF.
» TEMP. Aquí Oracle almacena las tablas temporales (para gestionar sus
transacciones). Se almacena en el archivo TEMP01.DBF.

» UNDOTBS1. En él es donde Oracle guarda la información de deshacer. Se utiliza

para almacenar la imagen anterior de los datos antes de permitir actualizaciones.
Esto permite recuperar los datos cuando no se completa una transacción. Se
almacena en el archivo UNDOTBS01.DBF. Este tablespace contiene los segmentos
de Rollback. Sin estos no se podrían realizar transacciones. Cuando se realiza una
transacción se asigna un segmento por defecto.
2. Registros de rehacer o Redo Log: el registro de las transacciones
Se trata de archivos de datos en los que Oracle registra todos los cambios que se
efectúan sobre los datos (INSERT, UPDATE y DELETE) de la base de datos dentro de
la caché de buffers de la base de datos. Estos archivos se utilizan en situaciones de fallo
para recuperar datos validados que no se han escrito en los archivos de datos. Suele
haber varios registros de rehacer y conviene almacenarlos en discos diferentes para
evitar pérdidas debido a fallos en el disco. Normalmente se crean varios grupos de Redo
Log online, formado cada uno de ellos por varios miembros, los miembros de un grupo
contienen copias idénticas.
El proceso en segundo plano LGWR escribe simultáneamente la misma información en

todos los archivos de Redo Log de un grupo. Oracle crea un mínimo de dos grupos de
Redo Log online, los miembros se llaman REDO01.LOG, REDO02.LOG y
REDO03.LOG. Un registro de Redo Log contiene: identificación de la transacción,
dirección de bloque, número de fila, número de columna y valor anterior y nuevo del
dato modificado. Cuando se está utilizando un grupo de archivos de Redo Log el
servidor Oracle le asigna un número de secuencia para identificarlo. Este número de
secuencia se almacena en el archivo de control y en la cabecera de todos los archivos de
datos. Esto se hace para en situaciones de fallo recuperar los datos a partir de un
número de Redo Log determinado.
3. Archivos de control
Contienen información sobre los archivos asociados con una base de datos Oracle.
Todas las modificaciones importantes que se hagan en la estructura de la base de datos
se registran en el archivo de control. Estos archivos mantienen la integridad de la base
de datos. Oracle recomienda que la base de datos tenga un mínimo de dos archivos de
control en discos diferentes. Si se daña un archivo de control debido a un fallo en disco,
se podría restaurar utilizando la copia intacta del archivo de control del otro disco. La

información del archivo de control solo la puede modificar el servidor Oracle. Si se

dañan los archivos la base de datos no funcionará correctamente. Es aconsejable
realizar copias de seguridad de estos archivos cada vez que se produzca un cambio en la
estructura física de la base de datos. Los archivos de control que se crean en la
instalación son: CONTROL01.CTL, CONTROL02.CTL y CONTROL03.CTL y contienen
la siguiente información:
» El nombre y el identificador de la base de datos.

» Registro de la hora y fecha de creación de la base de datos.
» Los nombres y ubicaciones de los archivos de datos asociados y los archivos de Redo
Logs.
» El historial de los Redo Log, que se registra durante los cambios de logs.
» La ubicación y el estado de los Redo Logs archivados.
» La ubicación y el estado de las copias de seguridad.
» Número de secuencia de log actual, que se registra cuando se producen los cambios
de log.
» Información sobre checkpoints (puntos de control que se dan cuando se llena el
Redo Log, cuando se detiene la base de datos, etcétera).
» Estado on-line y off-line de los archivos de datos.
4. Área global del sistema SGA
Es un grupo de estructuras de memoria que sirven para almacenar los datos de la base
de datos que se han consultado más recientemente. Contiene información de datos y de
control para el servidor Oracle. Se descompone en las siguientes zonas:
» Conjunto Compartido o área SQL compartida: formada por la caché de

diccionario de datos y la caché de biblioteca. La caché de diccionario de datos
contiene información acerca de las últimas definiciones utilizadas en la base de
datos: archivos de bases de datos, columnas, usuarios, privilegios y otros objetos
(por ejemplo, si un usuario puede acceder o no a una tabla). La caché de
biblioteca contiene información sobre las instrucciones SQL ejecutadas sobre la
base de datos: el texto de la sentencia, el código analizado y el plan de ejecución. La
segunda vez que un usuario ejecuta una sentencia idéntica SQL ya ejecutada puede
aprovecharse del análisis disponible en esta área para acelerar su ejecución.

» Caché de Buffers: contiene copias de los últimos bloques de datos leídos y

utilizados de los archivos de datos. Los usuarios acceden a los datos en esta zona de
la memoria. También se le conoce como buffer del bloque de datos o buffer de datos.
» Conjunto Grande: es un área de memoria opcional. Se utiliza para almacenar

estructuras grandes de la memoria que no están directamente relacionadas con el
procesamiento de sentencias SQL. Por ejemplo, los bloques de datos que se copian
durante las operaciones de copia de seguridad y restauración. Se define cuando se
utiliza la opción de servidor compartido o cuando se realizan con frecuencia
operaciones de copias de seguridad y restauración.
» Conjunto Java: especifica el tamaño para satisfacer los requisitos de análisis de los
comandos Java y almacena el código Java.
» Buffer del registro de rehacer: en esta área se registran las transacciones

(INSERT, UPDATE, DELETE) o cambios en la base de datos antes de escribirse en
los archivos de registro de rehacer. Se utiliza por los procesos en segundo plano y
servidor para hacer un seguimiento de los cambios realizados en la base de datos.
5. Procesos de soporte de la base de datos
Las relaciones entre las estructuras físicas y de memoria de la base de datos se

mantienen y aplican mediante una serie de procesos soporte (de segundo plano,
background o de fondo). El número de estos procesos varía en función de la
configuración de la base de datos. La base de datos gestiona estos procesos y necesita
poco trabajo administrativo.
Hay un conjunto de procesos del servidor que ayuda a la base de datos a funcionar:
sonlos procesos soporte o de segundo plano. En la figura, se puede observar una visión
general de una arquitectura Oracle. Los procesos en segundo plano son los siguientes:
» Escritor de bases de datos DBWR. Este proceso es el responsable de gestionar

el contenido del buffer de datos de la SGA. Lee los bloques de los archivos de datos,
los almacena en la SGA y realiza escrituras de los bloques modificados en los
archivos de datos y de Rollback. Cuando un usuario solicita una petición cuyos datos
no están en el buffer de datos, el DBWR se encargará de llevar al buffer un nuevo
bloque de información del archivo de datos. El DBWR escribe en los archivos de

datos cuando: el número de bloques sucios (cualquier bloque de datos que se cambie
en la caché de buffers de datos) alcanza el 90 % de ocupación, o cuando se produce
un timeout (cada tres segundos), o cuando se produce un punto de control o
checkpoint.
» Punto de control o comprobación CKPT. Estos puntos provocan que el DBWR

escriba en los archivos de datos todos los bloques del buffer de datos que se hayan
modificado desde el último punto de control, y que actualice las cabeceras de los
archivos de datos, de Redo Logs y de los archivos de control para registrar el punto
de control y reflejar que se ha completado con éxito la escritura. El checkpoint es un
medio de sincronizar la caché de buffer de base de datos con el archivo de datos. El
número de punto de control actúa como marcador de sincronización, si los archivos
de datos, de Redo Logs y de control tienen el mismo número de punto de control se
considera que el estado de la base de datos es consistente. El archivo de control
confirma en el inicio de la base de datos que todos los archivos están en el mismo
punto de control. La no coincidencia en las cabeceras provocará un fallo y la base de
datos no se podrá abrir, con lo que será necesario realizar una recuperación.
» Escritor de registros LGWR. Gestiona la escritura del contenido del buffer del
registro de rehacer de la SGA a los archivos de Redo Log online. Es el único proceso
que escribe en los archivos de registro de rehacer y el único que lee los buffers de
este registro. Los registros de Redo se escriben en uno de los grupos, a los que el
proceso LGWR denomina grupo Redo Log online actual, en las siguientes
situaciones:
o Cuando se valida una transacción.
o Cuando el buffer Redo Log se llena a un tercio de su capacidad.
o Cuando hay más de un mega de registros cambiados en el buffer de Redo Log.
o Cuando se produce un timeout (cada tres segundos).
o Antes que el DBWR escriba los bloques modificados de la caché de buffers de la
base de datos a los archivos de datos. Esta operación permite que Oracle pueda
recuperarse en cualquier momento si hay fallos. El proceso DBWR debe esperar
al escritor de registros antes de escribir los bloques modificados desde los buffers
del bloque de datos a los archivos de datos; es decir, en primer lugar, se escribe la
transacción en los registros de rehacer y luego se escribe en la base de datos.

LGWR escribe en los archivos de Redo Log de forma secuencial, cuando se llena un
grupo, comienza a escribir en el siguiente, si se llena el último grupo volverá a escribir
en el primero.
» Supervisor del sistema SMON. Comprueba la consistencia de la base de datos.

El supervisor del sistema es un proceso obligatorio que se ocupa de todas las
recuperaciones que sean precisas durante el arranque de la base de datos. La limpia
eliminando datos de las transacciones que el sistema ya no necesita y compacta los
huecos libres en los archivos de datos. Se activa de forma periódica para comprobar
si es necesaria su intervención.
» Supervisor de proceso PMON. Realiza una limpieza de recursos al terminar la

ejecución de los procesos. Restaura las transacciones no validadas de los procesos de
usuario que abortan, liberando los bloques y los recursos de la SGA. Cuando hay
procesos fallidos el PMON deshace los cambios de la transacción actual de usuario,
libera los bloqueos de tablas y filas actuales, y libera otros recursos que el usuario
necesita en ese momento. Al igual que SMON, se activa de forma periódica para
comprobar si es necesaria su intervención.
» Archivador ARCH. Es opcional, y archiva en disco o cinta una copia de los Redo
Log cuando están llenos para una posible recuperación por fallo de disco. Para que
se produzca el archivado, la base de datos tiene que estar abierta en modo
ARCHIVELOG, esto se decide al crear la base de datos. El proceso ARCH se inicia
haciendo una copia de seguridad del grupo de logs llenos en cada cambio de log.
Archiva automáticamente los Redo Log online antes de que se puedan volver a
utilizar, con el fin de proteger los cambios realizados en la base de datos. La copia
automática se activa con el parámetro LOG_ARCHIVE_START = TRUE.
» Recuperador RECO. Es opcional. Recupera transacciones distribuidas dudosas;

se usa en bases de datos Oracle distribuidas.

»
Figura 26. Resumen componentes Oracle.
1.8. Referencias bibliográficas
Adobe Cold fusión framework. Recuperado de:

http://www.adobe.com/es/products/coldfusion/
Ajax frente al esquema tradicional de aplicaciones web. Recuperado de:

http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications
Bray, T. et al. (1998). El lenguaje extensible de marcas (XML) 1.0. Recomendación del
W3C. Recuperado de: http://www.w3.org/TR/1998/REC-xml-19980210
Chess, B. y West, J. (2007). Secure Programming with Static Analysis. Massachusetts:

Addison-Wesley Software Security Series.
Cheswick, W. R., Bellovin S. M. y Aviel, R. (2003). Firewalls And Internet Security

Repelling The Wily Hacker. 2 Rev. Massachusetts: Pearson Education.
Cannings, R., Dwivedi, H, y Lackey, Z. (2008). Hacking exposed web applications.

Web 2.0. Nueva York: Mcgraw Hill. Recuperado de:
https://doc.lagout.org/security/Hacking%20Exposed-Web%202.0%20-
%20Web%202.0%20Security%20Secrets%20%26%20Solutions.pdf

Connolly, G. M., Akin, M., Goyal, A., Howlett, R. y Perrins, M. (2008). Building
Dynamic Ajax Applications Using WebSphere Feature Pack for Web 2.0. IBM
Redbooks
Cover pages. XML. Recuperado de: http://xml.coverpages.org/xml.html
Dowd, M., McDonald, J. y Schuh, J. (2006). The Art of Software Security Assessment:
Identifying and Preventing Software Vulnerabilities. Massachusetts: Addison Wesley
Professional. Print.
Especificación J2EE. Recuperado de: http://www.jcp.org/en/jsr/detail?id=151
FLASH. Recuperado de: http://www.adobe.com/es/products/flash-builder.html,

http://www.adobe.com/es/products/flash.html
Garrido, M. (2006). Evaluación Comparativa de aplicaciones Web entre J2EE y

Microsoft.NET. Chile: Universidad Católica de Temuco. Recuperado de:
http://www.issi.uned.es/pea/programacion-c/downloads/tesis.pdf
Garrido, M. A. (2006). Comparativas J2EE. Vs .NET. Recuperado de:

http://www.issi.uned.es/pea/programacion-c/downloads/tesis.pdf
http://www.javahispano.org/contenidos/es/comparativa-j2ee-net.html/
http://www.javahispano.org/antiguo_javahispano_org/2002/10/29/nueva-
comparativa-j2ee-vs-net.html
Graff, M. (2001). Secure Coding. The State of the Practice. Recuperado de:
http://codecraft.lk/wp-content/uploads/2018/09/Secure-Coding-Principles-and-
Practices.pdf
Guide to Web Application Development. Recuperado de:

https://www.comentum.com/guide-to-web-application-development.html
Gutiérrez, E. (2001) XML en 10 puntos. Recuperado de:

https://www.sidar.org/recur/desdi/traduc/es/xml/xml10p/xml10p.htm
Hypertext preprocessor. PHP. Recuperado de http://www.php.net/

Implementaciones y compatibilidad J2EE. Recuperado de:

http://java.sun.com/javaee/overview/compatibility.jsp
Introducción a MVC en Spring. Recuperado de:

http://www.jtech.ua.es/j2ee/publico/spring-2012-13/sesion03-apuntes.html
Javascript Language. Recuperado de: http://es.wikipedia.org/wiki/JavaScript
JSON. Recuperado de: http://json.org/json-es.html
Kirda, E., Kruegel, C. Vigna, G. y Jovanovic, N. (2006). Noxes: a client-side solution for
mitigating cross-site scripting attacks. In Proceedings of the Symposium on Applied
Computing.
Long F. (2005). Software Vulnerabilities in Java. Recuperado de

https://resources.sei.cmu.edu/asset_files/TechnicalNote/2005_004_001_14564.pdf
Mc Graw, G. (2006). Software Security: Building Security. Massachusetts: Addison

Wesley Professional.
Microsoft Active Server Pages. ASP. Recuperado de: http://msdn.microsoft.com/en-

us/library/aa286483.aspx
MVC. Recuperado de: http://es.wikipedia.org/wiki/Modelo_Vista_Controlador
OWASP TOP TEN. Recuperado de:

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
Padilla, J. y Pérez, J. (2009-2010). Comparativa J2EE/.NET EVOLUCIÓN 2 - Máster

para la Formación del Profesorado 2009-2010. Recuperado de:
http://joseperezlozano.com/wp-
content/uploads/2010/05/J2EEOPuntoNetVersionWeb.pdf
Perl. Lenguaje de programación. Recuperado de: http://www.perl.org/
Proyecto mono: cross platform open source .NET development framework.

Recuperado de: http://www.go-mono.com/

Ramos, Mª. J., Ramos, A., y Montero, F. (2006). Sistemas gestores de bases de datos.
Madrid: McGraw-Hill. Recuperado de:
http://allmastersolutions.com/shared/Sistemas%20Gestores%20de%20Bases%20de%
20Datos.pdf
Scambray, J., Liu, V. y Sima, C. (2010). Hacking Exposed Web Applications 3. Nueva
York: McGraw-Hill/Osborne.
Servicios web. Recuperado de:

http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb
Silic, M., Krolo, J. y Delac, G. (2010). Security Vulnerabilities in Modern Web Browser
Architecture. Faculty of Electrical Engineering and Computing. Zagreb: University of
Zagreb. Recuperado de:
https://bib.irb.hr/datoteka/473776.SecurityVulnerabilitiesInModernWebBrowserArch
itecture.pdf
TIOBE. Recuperado de:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Veracode report volumen 9. Recuperado de: https://info.veracode.com/report-state-of-

software-security-volume-9.html

Lo + recomendado
Lecciones magistrales
Aplicaciones AJAX (Rich Client Internet Applications)
Repaso de una de las tecnologías más actuales de implementación de aplicaciones de

cliente enriquecido, se revisa la arquitectura de este tipo de aplicaciones y los
problemas de seguridad que introducen.
El vídeo está disponible en el aula virtual.
No dejes de leer…
Política de seguridad
Alonso, M., Díaz, G., Mur, F., Peire, J. y Sancristóbal, E. (2004). Seguridad en las
comunicaciones y en la información. Madrid: UNED.
Trata de la implantación de la política de seguridad en una organización. Explica en las

páginas 144 a 164 concepto, principios y fases que debe tener para su
implementación.
Accede al libro a través de la Biblioteca Virtual de UNIR
TEMA 1 – Lo + recomendado 55 © Universidad Internacional de La Rioja (UNIR)

Sistema de gestión de seguridad
El propósito de esta publicación es proporcionar pautas para seleccionar y especificar

controles de seguridad para organizaciones y sistemas de información que apoyan a las
agencias ejecutivas del gobierno federal para cumplir con los requisitos de la
Publicación 200 de FIPS.
Accede al artículo a través del aula virtual o desde la siguiente dirección web:
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
Building Scalable Web Sites
Henderson, C. (2006). Building Scalable Web Sites. (pp. 6-26). O'Reilly Media, Inc.
Es recomendable la lectura del capítulo 2 sobre características de las arquitecturas de

las Aplicaciones.
Accede al capítulo desde el aula virtual o a través de la siguiente dirección web:

http://books.google.es/books?id=wIWU94zKEtYC&printsec=frontcover&dq=Building
+Scalable+Web+Sites&hl=

Características de los servicios web
Guía breve de servicios web. Estos servicios proporcionan mecanismos de comunicación

entre diferentes aplicaciones, que interactúan entre sí para presentar información dinámica
al usuario. Para ello, es necesaria una arquitectura de referencia estándar.
Accede al artículo desde el aula virtual o a través la siguiente dirección web:

http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb
Seguridad en AJAX
Ajax Security Basics y Book excerpt: Jump into AJAX development. Se revisan aspectos
de seguridad de este tipo de aplicaciones y se introduce la forma de solucionarlos.
Accede a los documentos desde el aula virtual o a través de las siguientes direcciones web:
http://www.symantec.com/connect/articles/ajax-security-basics
http://www.javaworld.com/javaworld/jw-08-2006/jw-0807-ajax.html

Arquitectura y seguridad en navegadores web
Implementación y seguridad de Google Chrome en una guía de Windows Enterprise y

Securing Explorer 11, dos de los navegadores más extendidos.
Accede a los documentos desde el aula virtual o a través de las siguientes direcciones web:
https://www.cisecurity.org/cis-benchmarks/
https://www.veracode.com/blog/2013/03/browser-security-settings-for-chrome-
firefox-and-internet-explorer
https://www.stigviewer.com/stig/microsoft_internet_explorer_11/
https://bib.irb.hr/datoteka/473776.SecurityVulnerabilitiesInModernWebBrowserArch
itecture.pdf
No dejes de ver…
OWASP Appsec Tutorial Series sobre vulnerabilidades de seguridad-

Episodes 1, 2, 3 y 4: Basics-SQLI-STS-Cross Site Scripting (XSS)
Tutoriales sobre vulnerabilidades web.
Accede al vídeo desde el aula virtual o a través de la siguiente dirección web:

https://www.youtube.com/channel/UC5xIEA6L0C2IG3iWgs8M2cA

+ Información
A fondo
Arquitectura J2EE
En este artículo se describen cuáles son las características, de la tecnología de

desarrollo J2EE para abordar el desarrollo e implantación de grandes aplicaciones
escalables sobre redes globales dirigidas a entornos empresariales o industriales.

https://www.bilib.es/documentos/apuntesjava/Tema_1.pdf
JSON
Introducción a JSON (JavaScript Object Notation - Notación de Objetos de JavaScript).

Es un formato ligero de intercambio de datos. Está basado en un subconjunto del
lenguaje programación Javascript y se utiliza como forma de intercambio de datos en
aplicaciones AJAX.

http://json.org/json-es.html
TEMA 1 – + Información 59 © Universidad Internacional de La Rioja (UNIR)

Ajax
Ajax frente al esquema tradicional de aplicaciones web. En este artículo se describe el

nuevo enfoque de la arquitectura AJAX frente a las arquitecturas web tradicionales
para conseguir clientes más enriquecidos.

http://www.jesusda.com/docs/ebooks/introduccion_ajax.pdf
Arquitectura de servicios web
Este enlace es una ampliación sobre la Arquitectura de Servicios Web, describiendo los
protocolos y servicios que los componen: SOAP, UDDI, WSDL.
Accede al documento desde el aula virtual o a través de la siguiente dirección web:

http://msdn.microsoft.com/en-us/library/ms996507.aspx
Administración de sistemas gestores de bases de datos
Huseo-Ibañez, L. (2015). Administración de sistemas gestores de bases de datos.

Madrid: Ra-Ma.
Los contenidos incluidos en este libro abarcan conceptos relacionados con la

administración de sistemas orientados a datos, como son los sistemas gestores de bases
de datos.

Webgrafía
Open Web Application Security Project
Página web del proyecto abierto para Seguridad de las Aplicaciones Web. En su página
web se menciona su propósito:
Accede a la
página web
a través del aula virtual o desde la siguiente dirección:
https://www.owasp.org/index.php/Main_Page
WASC
Página de WASC, asociación sin ánimo de libro formada por un grupo internacional de
expertos profesionales de la industria y representantes de organizaciones que producen
software libre y ampliamente acordados estándares de seguridad de mejores prácticas
para la world wide web.
Accede a la página a través del aula virtual o desde la siguiente dirección web:
http://www.webappsec.org/

SANS
En esta página web podrás ver el propósito de SANS.
https://www.sans.org/
https://www.sans.org/top25-software-errors/
Veracode
Veracode ofrece servicio on demand para análisis de la seguridad de las aplicaciones

web.
http://www.veracode.com/security/
Bibliografía
Apuntes profesor JUAN RAMON BERMEJO HIGUERA
Ajax applications. Recuperado el 24 de agosto de 2017 en W3C.

https://www.w3schools.com/xml/ajax_intro.asp
Ashmore, D. (2014). The Java EE Architect’s Handbook, Second Edition: How to be a

successful application architect for Java EE applications.

Brock, J. y Gupta, A. (2014). Java EE and HTML5 Enterprise Application Development.

Nueva York: McGraw-Hill Education.
Category: OWASP Top Ten Project. Recuperado de:

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
Hueso-Ibañez, L. (2011). Administración de Sistemas Gestores de Bases de Datos.

Madrid: Ra-Ma.
IBM X-Force 2011 Trend Report. Recuperado el 21 de marzo de

https://www.ibm.com/security/resources/xforce/research.html
Purewal, S. (2014). Learning Web App Development 3. California: Ed. O´Reilly.
Sarasa, A. (2016). Introducción a las bases de datos NoSQL usando MongoDB.

Barcelona: Editorial UOC.

Actividades
Trabajo: Seguridad en aplicaciones Ajax
Objetivo
Realizar un trabajo para investigar sobre la arquitectura de la tecnología WEB 2.0

AJAX y los problemas de seguridad que presenta, así como sus posibles soluciones.
Descripción de la actividad
Investigar:
La arquitectura de las aplicaciones web ricas de Internet (RIA) AJAX: tecnologías,

características, funcionamiento.
Principales vulnerabilidades de seguridad.
Principales mecanismos de defensa a implementar en toda la arquitectura de una
aplicación web AJAX.
Rúbrica
Seguridad Puntuación
en Peso
Descripción máxima
aplicaciones %
Ajax (puntos)
Criterio 1 Descripción de la tecnología 1 10%

Investigación sobre vulnerabilidades
Criterio 2 4 40%
de seguridad
Investigación sobre defensas de
Criterio 3 4 40%
seguridad
Criterio 4 Calidad de la memoria 1 10%
10 100 %
Extensión máxima de la actividad
15 páginas en un documento de Word: letra Calibri 12, interlineado 1,5, margen

superior e inferior 2,5 cm y margen izquierdo y derecho 3,25 cm.
TEMA 1 – Actividades 64 © 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, integridad.
B. No repudio, trazabilidad, autenticación, autorización y control de acceso,
confidencialidad, disponibilidad, integridad.
C. No repudio, autenticación, autorización y control de acceso, confidencialidad,
disponibilidad, integridad.
D. A y B son correctas.
2. ¿Cuáles son los tipos de vulnerabilidades que un sistema puede tener?

A. Calidad, diseño, operación.
B. Calidad, implementación, diseño.
C. Diseño, implementación, operación.
D. Ninguna de las anteriores.
3. Señala la afirmación correcta.

A. Con CGI, El ciclo escritura – compilación – implementación – ejecución es
más rápido que en la mayoría de las tecnologías más recientes (pero no
demasiado).
B. La mayoría de los lenguajes de script no se encuentran sólidamente tipificados
y no promueven buenas prácticas de programación.
C. Entre los marcos de lenguajes de script se incluyen .NET y J2EE.
D. Todas las anteriores son falsas.
4. Señala la afirmación correcta.

A. C#, Java, Python, Ruby o dialectos de C como CCured y Cyclone son lenguajes
que fuerzan la comprobación de tipos y de memoria de forma que su gestión sea
segura.
B. C y C++ son lenguajes seguros y ampliamente utilizados.
C. Con lenguajes de programación «seguros» el programador no ha de
preocuparse.
D. Todas las anteriores son falsas.
TEMA 1 – Test 65 © Universidad Internacional de La Rioja (UNIR)

5. Señala la afirmación falsa.

A. La seguridad de una aplicación debe aplicarse a todas las capas de la misma.
B. Las capas de una aplicación web son: cliente-presentación-aplicación-
persistencia (Base de datos).
C. El patrón de diseño MVC tiene tres capas: vista-controlador-modelo.
D. Google Chrome tiene una arquitectura monolítica.
6. Señala la afirmación falsa.

A. AJAX, JSON son tecnologías WEB 2.0.
B. La comunicación entre el motor AJAX y el servidor de aplicaciones es síncrona.
C. Los principios de diseño de las aplicaciones distribuidas basadas en servicios
web tienen su origen en lo que se denomina Arquitectura Orientada a Servicios.
D. WDSL es un lenguaje de descripción de servicios.
7. El proceso que se encarga de volcar los datos del buffer de redo log de un SGBD se
llama:
A. DBWR.
B. LGWR.
C. SMON.
D. PMON.
8. ¿Dónde se guarda la información de los elementos físicos de la arquitectura de

Oracle?
A. Archivos de Redo log.
B. Archivos de control.
C. Tablespace de control.
D. No se guarda.
9. ¿Qué métodos http hay que permitir en un servidor web para que sean más seguras
las peticiones?
A. GET.
B. TRACE.
C. POST.
D. OPTIONS.

10. Señala cuál es una vulnerabilidad de diseño:

A. XSS.
B. SQLI.
C. TOCTOU.
D. LFI.

Tema1 PDF

Cargado por

Información del documentohacer clic para expandir la información del documento

Información del documentohacer clic para expandir la información del documento

Copyright:

Formatos disponibles

Tema1 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema1 PDF

Cargado por

Copyright:

Formatos disponibles

Aplicaciones y servicios web y bases de

[1.3] Ciclo de vida de desarrollo seguro de software (SSDLC)

[1.4] Vulnerabilidades de seguridad en las aplicaciones

[1.5] Arquitecturas y tecnologías de desarrollo de las

[1.7] Arquitecturas de almacenes de datos

[1.8] Referencias bibliográficas TEMA

TEMA 1 – Esquema 2 © Universidad Internacional de La Rioja (UNIR)

1.1. ¿Cómo estudiar este tema?

En este tema analizaremos, de forma introductoria desde el punto de vista de la

En este capítulo se van a resumir los objetivos de seguridad de las aplicaciones y

Los objetivos de seguridad a alcanzar en los sistemas de información y comunicaciones

» Identificar a las personas que acceden a la información manejada por un sistema y

TEMA 1 – Ideas clave 3 © Universidad Internacional de La Rioja (UNIR)

Las principales vulnerabilidades de seguridad que pueden impedir los objetivos

» Vulnerabilidades de seguridad en el de diseño.

Por tal motivo es necesario convertir el ciclo de vida de desarrollo de aplicaciones en un

Figura 1. Incremento del coste. Fuente: Graff (2001).

TEMA 1 – Ideas clave 4 © Universidad Internacional de La Rioja (UNIR)

La comunidad de seguridad generalmente acepta vulnerabilidades de diseño como

Aprovechando cualquier tipo de vulnerabilidad de las mencionadas anteriormente,

En sentido general, un ataque contra un sistema es cualquier acto malévolo previsto

A continuación, se presentan unos cuantos ejemplos de ataques debidos a defectos de

TEMA 1 – Ideas clave 5 © Universidad Internacional de La Rioja (UNIR)

o Ataque de hombre en medio. Este ataque ocurre cuando el atacante

o Ataque de condiciones de carrera. TOCTOU. En un sistema operativo

o Ataque de buffer overflow. No hacer comprobaciones de la longitud de los

o Ataque de inyección de SQL. Los ataques de inyección de SQL muy comunes

TEMA 1 – Ideas clave 6 © Universidad Internacional de La Rioja (UNIR)

alterando la sentencia de la consulta, porque los campos de entrada no se han

o Ataques de puerta-atrás. Hay que establecer un adecuado proceso de

o Ataques de denegación de servicio. Un sistema, un equipo o una red pueden

o Ataque aprovechando configuraciones por defecto. Al comienzo cuando

o Ataque por descubrimiento de contraseñas. También ataque por craking

TEMA 1 – Ideas clave 7 © Universidad Internacional de La Rioja (UNIR)

Pilares para la seguridad de las aplicaciones online

Esta asignatura pretendemos introducir los pilares de la seguridad de las aplicaciones y

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

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

TEMA 1 – Ideas clave 8 © Universidad Internacional de La Rioja (UNIR)

1.3. Ciclo de vida de desarrollo seguro de software

La seguridad de la aplicación tiene que tratarse obligatoriamente, desde el principio, en

Actividades de seguridad en el SSDLC:

» La primera actividad es derivar los requisitos de seguridad y casos de abuso

TEMA 1 – Ideas clave 9 © Universidad Internacional de La Rioja (UNIR)

» Se prueba la seguridad del código y funcional de seguridad de la aplicación

TEMA 1 – Ideas clave 10 © Universidad Internacional de La Rioja (UNIR)

procedimientos relacionadas con la seguridad en el ciclo de vida y a continuación se

Figura 2. Modelo de SSDLC. Fuente: Chess y West, (2007).

La figura, muestra un ejemplo de ciclo de vida de desarrollo de software SSDLC donde

TEMA 1 – Ideas clave 11 © Universidad Internacional de La Rioja (UNIR)

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

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

1.4. Vulnerabilidades de seguridad en aplicaciones web

TEMA 1 – Ideas clave 12 © Universidad Internacional de La Rioja (UNIR)

se genere un impacto de negocio para la organización, es necesario que intervengan una

» Agente o amenaza, es la persona que realiza el ataque.

Figura 3. Materialización de una amenaza: Ataque.