Tema 3

Seguridad de los servicios web
[3.1] ¿Cómo estudiar este tema?
[3.2] Introducción a la seguridad de los servicios web
[3.3] Funciones y tecnologías de la seguridad de los servicios web
[3.4] Evaluación de la seguridad de los servicios web
[3.5] Protección online. Firewalls y Gateways XML
[3.6] Referencias bibliográficas
3 TEMA
Seguridad de los servicios web
Esquema
TEMA 3 – Esquema
SERVICIOS WEB:
Arquitectura
Dimensiones seguridad
Requisitos de seguridad
Amenazas y riesgos
FUNCIONES DE SEGURIDAD
2
Autenticación SEGURIDAD ONLINE:
Gestión de identidad y relación de TEST Monitorización y auditoría
confianza Evaluación de la Disponibilidad
Autorización y control de acceso seguridad SW Seguridad servicio
Confidencialidad e integridad descubrimiento
Protección online:
Seguridad SOA
Firewalls XML
Seguridad en Aplicaciones en Línea
Ideas clave
3.1. ¿Cómo estudiar este tema?
Para el estudio de los diferentes apartados, se ha de seguir el documento elaborado por el

profesor para este tema 3: Seguridad de los Servicios Web.
Los principios de diseño de las aplicaciones distribuidas basadas en servicios web

tienen su origen en lo que se denomina Arquitectura Orientada a Servicios (SOA,
Service-Oriented Architecture). Como ejemplos de esta arquitectura se pueden
nombrar tecnologías tan conocidas como RPC, RMI, CORBA o DCOM. 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.
3.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, Service-Oriented Architecture). 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.
Figura 1.
TEMA 3 – Ideas clave 3

Figura 1. 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 tienen, (figura 2):
Una envoltura.
Una cabecera con datos descriptivos.
Un body o contenido.

Figura 2. Estructura de los mensajes. http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb
Arquitectura servicios web
La arquitectura más simple de los servicios web se representa en la figura 3, 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.

SERVICIO
REGISTRO
UDDI (BROKER) UDDI
question register
SERVICIO SERVICIO
CONSUMIDOR PROVEEDOR
CLIENTE SERVICIO
SOAP (XML)
Figura 3. Arquitectura 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 que 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 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 seguro son la corrección y la disponibilidad. En la figura 4, 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 4, 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 como.
» 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 que se configure por debajo de la capa de aplicación y
se garantiza los servicios de seguridad. (ver figura 4).

Figura 4. Seguridad extremo a extremo.

Fuente: https://msdn.microsoft.com/en-us/library/ff648318.aspx#WSSecurityStandards
En la figura 5, 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.
Figura 5. 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 cuadro de la figura 6, 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
Figura 6. Estándares de seguridad para servicios web. NIST SP-800-95
Organizaciones y estándares de seguridad SW
» Consorcio World Wide Web (W3C) [1]. 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 [4] (Organization for the Advancement of Structured Information

Standards). OASIS, es un organismo global muy centrado en temas de comercio
electrónico. Es un organismo sin ánimo de lucro. Oasis 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 (consultar el proyecto web security threat classification de WASC:
http://projects.webappsec.org/w/page/13246978/Threat%20Classification) 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
» XML ENTITY EXPANSION
3.3. Funciones y tecnologías de 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.
3.1. Política de seguridad
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-Privacy. Establece como se van a implementar la seguridad de los servicios

web de acuerdo con la política de seguridad establecida, mediante 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.
» 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.
» WS-Federation. 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.
» 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 el sí 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.
Puedes acceder a las Especificaciones de seguridad en Servicios Web: Conceptos de

seguridad de servicios web de la Junta de Andalucía, a través del siguiente enlace:
http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/211

3.2. 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, como
hemos visto, 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 firmado 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. 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 a 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.

3.3. Control de acceso: Gestión de identidad y relación de confianza
El control de acceso tiene dos fases:

1. Identificación y autenticación.
2. 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.
» …
Figura 7. Sistema de gestión de identidades. NIST SP-800-95
La gestión de la identidad en arquitecturas, figura 7, 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
8):
Figura 8.
» Aisladas (parwise), de poca escalabilidad, cada servicio deber tener su propia

base de datos de identidades y gestionarla (figura 9).
Figura 9.
» Centralizadas (Single Sign On, brokered). (Figura 10).

Figura 10.
» Federadas para autenticación inter-dominios (figura 11).
Figura 11.

» Distribuidas: GATEWAYS XML (figura 12).
Figura 12. Gateways 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.
» 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.
Se puede utilizar la especificación XACML, para implementar ABAC.
» 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 del 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).
» 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 13, 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.

Figura 13. 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). 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 la 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 SubjectStatement: una declaración del sujeto de la afirmación realizada mediante
una extensión del esquema.
o AuthenticationStatement: una afirmación de autenticación.
o AuthorizationDecisionStatement: una afirmación que contiene la información
relacionada con la decisión resultado de una evaluación de autorización.
o AttributeStatement: 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.
Figura 14. Esquema de SAML.

Fuente: https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
La especificación SAML permite especificar como parte del elemento conditions el

parámetro OneTimeUse que implica, como sugiere su traducción del inglés, que el
assertion/afirmación va a ser para un solo uso y que dicho uso debe ser inmediato. Este
ajuste ayudará junto con otros parámetros como identificador de la petición y del sujeto
a evitar ataques de repetición/suplantación en el caso de esnifar el tráfico.
En la figura 15, el identificador de la petición se identifica a continuación de

InResponseTo y el identificador del sujeto es el parámetro transient. Una medida de
seguridad adicional, tiene que ver con la fortaleza de los identificadores, que no
deberían tener significado alguno y generarse de forma aleatoria mediante algoritmos
de tipo criptográficos y no de tipo estadístico, cuestión ésta que los haría fácilmente
predecibles. El identificador ha de ser lo suficientemente largo, de más de 128 bits.
Todas estas medidas, contribuirán a la evitación/prevención de ataques de repetición.
A continuación, se presenta un ejemplo de validación de un assertion SAML, por parte

de un proveedor de un SW (figura 15):

Figura 15. 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.
o En un escenario centralizado, un conjunto de políticas único se utiliza para
referirse al control de acceso sobre distintos tipos de recursos.
o 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.
3.4. 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.
3.5. 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 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.
3.6. 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 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 especifica 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.
3.4. 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

sería analizar la seguridad durante el ciclo de vida de desarrollo de software, que sería
la más deseable, y 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 [5] (ver figura 16). El grado de importancia de cada actividad, se
muestra en los círculos negros.

Figura 16. Modelo de SSDLC de McGraw.
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.
4.1. 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:
» ¿En qué consiste?
» ¿Cuándo se debe llevar a cabo?
» ¿Quién la debe llevar a cabo?
» ¿Cómo se debe realizar?
Modelado de amenazas y casos de abuso
» ¿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, pueden dar lugar a que se materialicen ataques concretos. Los casos
de abuso son lo contrario que 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.
» ¿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.
» ¿Quién las debe llevar a cabo? En el caso de estar en SSDLC, el personal

desarrollador si tiene experiencia en seguridad únicamente, el personal del
departamento de seguridad o de forma mixta. En el caso de ser una auditoría, puede
ser el departamento de seguridad de la organización o personal externo contratado.
» ¿Cómo se debe realizar? Para la actividad de modelado de amenazas se puede

seguir la metodología STRIDE [7] 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 [5], resumida
en el siguiente esquema de la figura 17:

Figura 17. Metodología de derivación de casos de abuso.
En la tabla 1, se muestra un ejemplo de caso de abuso en comparación a un caso de uso.

Tabla 1. Casos de abuso.
Análisis de los requisitos de seguridad
» ¿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.
» ¿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.
» ¿Quién las debe llevar a cabo? En el caso de estar en SSDLC, el personal

desarrollador, si tiene experiencia en seguridad únicamente, el personal del
departamento de seguridad o de forma mixta. En el caso de ser una auditoría, puede
ser el departamento de seguridad de la organización o personal externo contratado.
» ¿Cómo se debe realizar? Para derivar los requisitos de seguridad se pueden

emplear metodologías de ingenierías de requisitos como SQUARE [6]

http://resources.sei.cmu.edu/asset_files/TechnicalReport/2005_005_001_14594.
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 figura 18, en las fases de análisis y
diseño del SSDLC.
Figura 18. Metodología de ingeniería de requisitos SQUARE.

Resumiendo, el proceso de derivación de requisitos de seguridad:

» 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.
» En una segunda fase se identifican los requisitos de seguridad, se revisan y se
verifican.
» Si son factibles los requisitos de seguridad se validan frente a los objetivos de
seguridad.
» Se construye, revisa y se verifica la arquitectura del sistema.
» Si es factible la arquitectura del sistema se valida su seguridad frente a los requisitos
de seguridad.
Análisis de riesgos de la arquitectura
» ¿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:

o Activo. Los objetos de los esfuerzos de protección. Pueden ser componentes del
sistema, datos o el sistema en su totalidad.
o Impacto. Degradación causada por una amenaza concreta en un activo.
o 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.
o 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.
o 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.

Figura 19. Elementos de un análisis de riesgos.
» ¿Cuándo se debe llevar a cabo? Como se puede observar en la figura 20, 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. Posteriormente,
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.
Figura 20. Fases del análisis de riesgo.
» ¿Quién las debe llevar a cabo? Personal del departamento de seguridad o

externo en el caso de una auditoría externa.

» ¿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, pero 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, se derivan los requisitos de
seguridad y 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.

o MAGERIT [7].
o ASSET [8] (Automated Security Self-Evaluation Tool). National Institute on
Standards and Technology (NIST).
o OCTAVE [9] (Operationally Critical Threat, Asset, and Vulnerability Evaluation).
SEI de la Universidad Carnegie Mellon.
o COBIT [10] (Control Objectives for Information and Related Technology) from
Information Systems Audit and Control Association (ISACA).
Pruebas funcionales de seguridad
» ¿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.
» ¿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.
» ¿Quién las debe llevar a cabo? Personal del departamento de seguridad o

externo en el caso de una auditoría externa.
» ¿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:
o 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.
o 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.
o Simulación de las acciones de los proveedores y clientes.
Revisión del código (ver tema 2)
» ¿En qué consiste? Esta actividad se trata en el tema 2, de esta asignatura, 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. Revisa el tema 2, donde se explica la arquitectura y funcionamiento.
Es una actividad fundamental, 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 21, se puede ver un esquema de la arquitectura de las
herramientas SAST.
Figura 21. Arquitectura SAST.
» ¿Cuándo se debe llevar a cabo? En la fase de desarrollo o en fase de producción

si es una auditoría.

» ¿Quién las debe llevar a cabo? El personal de desarrollo si está formado en la

actividad, el departamento de seguridad o de forma mixta.
» ¿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 2)
» ¿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:

o Informando de la existencia de vulnerabilidades.
o Bloqueando el ataque.
o Saneando la petición, eliminando la posibilidad de ataque.
» ¿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.

» ¿Quién las debe llevar a cabo? Personal de seguridad especializado interno o

externo si es el caso de una auditoría externa.
» ¿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
» ¿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.
» ¿Cuándo se deben llevar a cabo? En fase de producción.
» ¿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.
4.2. 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 HIBRIDAS, 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 Tools

• 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 figuras 22 y 23 se muestran varias pantallas de las herramientas SOAPUI, donde

se aprecian los tipos de pruebas que se pueden llevar a cabo.

Figura 22. SoapUI

Fuente: http://resources.infosecinstitute.com/web-services-penetration-testing-part-2-automated-
approach-soapui-pro/
Figura 33. SoapUI

Fuente: http://resources.infosecinstitute.com/web-services-penetration-testing-part-2-automated-
approach-soapui-pro/

3.5. 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 servidores de seguridad perimetrales. Además, con la
llegada de Liberty y SAML v2.0 's, 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 24).
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.
Figura 24. 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. 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 25).
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.

Figura 25. Gateways XML+firewall XML.
En la figura 26, 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.
Figura 26. 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.
3.6. Referencias bibliográficas
W3c, guías breves de seguridad en Servicios Web. Recuperado de

http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb

Microsoft WS security standars. Recueprado de https://msdn.microsoft.com/en-

us/library/ff648318.aspx#WSSecurityStandards
Guía de seguridad en Servicios Web del NIST. Recuperado de

http://csrc.nist.gov/publications/nistpubs/800-95/SP800-95.pdf
OASIS, Organization for the Advancement of Structured Information Standards.

Recuperado de https://www.oasis-open.org/
McGraw, G. (2006). Software Security: Building Security. Addison Wesley

Professional.
Metodología SQUARE de ingeniería de requisitos. Recuperado de

http://resources.sei.cmu.edu/asset_files/TechnicalReport/2005_005_001_14594.pdf
Metodología de análisis de riesgos MAGERIT. Recuperado de

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

National Institute on Standards and Technology (NIST). Recuperado de
http://csrc.nist.gov/archive/asset/
Metodología de análisis de riesgos OCTAVE (Operationally Critical Threat, Asset, and

Vulnerability Evaluation). SEI de la Universidad Carnegie Mellon. Recuperado de
http://www.cert.org/resilience/products-services/octave/
Metodología de análisis de riesgos COBIT 5 (Control Objectives for Information and

Related Technology) from Information Systems Audit and Control Association
(ISACA). Recuperado de
http://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metod
olog/pae_Magerit.html#.VZFplk3z74g
Firewalls arquitectura practices configuration auditing. Recuperado de

http://www.sans.org/reading_room/whitepapers/firewalls/xml-firewall-architecture-
practices-configuration-auditing_1766

Material complementario
Lecciones magistrales
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
El vídeo está disponible en el aula virtual.
No dejes de leer…
Security for Web Services and Service-Oriented Architectures
Bertino, E., Martino, L. D., Paci, F.& Squicciarini, A. C. (2010). Security for Web
Services and Service-Oriented Architectures. Springer.
Es recomendable la lectura de los capítulos 4: Standars for Web Services Security y 9

sobre Emerging Research Trends en aspectos de la seguidad de los Servicios Web.
TEMA 3 – Material complementario 51

Introducción a SOA gateways: best practices, benefits & requirements
Este artículo sobre SOA (XML) Gateways trata las mejores prácticas de
implementación, beneficios y requisitos con un enfoque en la virtualización de
servicios, cofidencialidad e integridad de mensajes y de la auditoría de mensajes. Un
Gateway de este tipo controla sin problemas acceso a los servicios, protege la
información a través de cifrado de nivel de datos, se asegura la integridad de un
mensaje a través de firmas, y controla el flujo de información corporativo.
Accede al documento desde el aula virtual o a través de la siguiente dirección web:

https://www.forumsys.com/wp-content/uploads/2014/01/Best-Practices-in-
Deploying-SOA-Gateways.pdf
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.

https://www.gartner.com/doc/reprints?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.
SQL Injection
XPath Injection
XML Attribute Blowup
XML External Entities
XML Entity Expansion
XML Injection
XQuery Injection

http://projects.webappsec.org/w/page/13246978/Threat%20Classification
A fondo
XML Technology
Ampliación de la tecnología XML, que incluye XML Namespaces, XML Schema, XSLT,
Efficient XML Interchange (EXI).

http://www.w3.org/standards/xml/
Security Design Guidelines for Web Services
En esta página web se pueden consultar un 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 (y servicios web) del
Consorcio para la seguridad de las aplicaciones web WASC.

http://projects.webappsec.org/w/page/13246985/Web%20Application%20Firewall%2
0Evaluation%20Criteria
Webgrafía
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 web del estándar abierto de seguridad de los Servicios Web.
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

National Institute of Standars and Technology: information Technology

Laboratory
Página web 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

Bibliografía
Bibliografía básica
Guía de seguridad de servicios web del NIST SP.800-95. Recuperado el 9 de mayo de

2013 de: https://www.nist.gov/publications/guide-secure-web-services
Firewalls arquitecture practices configuration auiting. Recuperado el 9 de mayo de

2013 de: http://www.sans.org/reading_room/whitepapers/firewalls/xml-firewall-
architecture-practices-configuration-auditing_1766
Bibliografía complementaria
Ws Security Challenges, Threats and Countermeasures Version 1.0 Final Material.

Web Services Interoperability Organization. Recuperado el 9 de mayo de 2013 de:
http://www.ws-i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf
Bertino, E., Martino, L.D., Paci, F., y Squicciarini, A.C. (2010). Security for Web
Services and Service-Oriented Architectures. SPRINGER.

Actividades
Trabajo: Configurar la seguridad de servicios web
Descripción de la actividad
Esta actividad consiste en configurar 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.
Pautas de elaboración
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,
TEMA 3 – Actividades 57
autenticación, integridad y cifrado. Además, debe conocer los conceptos y

arquitectura de diseño de los servicios web.
Descripción. 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.
Seguridad de servicios web con soluciones open source
Instalación. Para su instalación en plataforma con Windows, hay que seguir los
pasos siguientes:
Asegurarse de que los puertos 80, 443, 8080 están libres.
Descargar SOA Demonstrator desde:

https://www.dropbox.com/s/emlnz3ufl2aak83/SOA-DEMO.zip luego
descomprimir. 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:

https://www.dropbox.com/s/pp9ntpxqgrdvy6g/ROOT.war 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 XMLGATEWAY y arranca TCPMONITOR.
IMPORTANTE: Después de arrancar el servidor hay que descargar el fichero

config.xml de:
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:

http://localhost:8080/consumer/
http://localhost:8080/provider/
http://localhost:8080/payment/
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, p.e.:
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.
1. Conector de seguridad de CONSUMER.
Se accede mediante la url http://localhost:8080/consumer/ (se puede utilizar también

https). Se deben configurar las siguientes funciones de autenticación, firma y cifrado de
la petición a enviar en menú WORFLOW de consumer:
SetsecRTEntity
EctractFromRequest
WSSecurityAddSAMLToken (SAML 1.1)
EncryptXPathForCertificate, para cifrar el elemento paymentInformation de la
petición XML.
SignSOAPEnvelope
EncryptXPathForCertificate, para cifrar el elemento Order de la petición XML
EnvelopeInRequest
Proxy para redirigir la petición al servicio web provider a través del puerto 2100 del
tcpmonitor.
En la respuesta se debe configurar:

ExtractFromResponse
DecryptXPath para descifrar el resultado de la petición
EnvelopeInResponse
2. 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.
SetsecRTEntity
EctractFromRequest
DecryptXPath, para descifrar el elemento Order de la petición XML
WSSecurityCheckSAMLToken (SAML 1.1)
VerifySOAPEnvelope
EnvelopeInRequest
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:

ExtractFromResponse
EncryptXPathForCertificate para cifrar el resultado de la petición: Elemento

OrderingResult
EnvelopeInResponse
3. 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:
SetsecRTEntity
EctractFromRequest
DecryptXPath, para descifrar el elemento paymentInformation de la petición
XML
EnvelopeInRequest
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.
4. XMLGATEWAY. (OPCIONAL).
Se accede mediante la url http://localhost:8080/XMLGATEWAY/

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):
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)
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 (ver referencia [4]) la
envoltura de los mensajes. Se ve también en los propios mensajes en el tráfico de la
aplicación.
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 necesitará 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 de: https://www.dropbox.com/sh/cgkzwq2z6qyy1kd/viPuZUC2ln
Debes entregar una memoria 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 debes 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.
Extensión máxima: 15 páginas (Georgia 11 e interlineado 1,5).
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. Regular Expression Library. http://regexlib.com
3. Symantec. http://www.symantec.com/connect/articles/detection-sql-injection-
and-cross-site-scripting-attacks
4. SOAP Messages. http://soapuser.com/basics3.html
Apéndice
1. 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, veréis que la validación 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 encontrar 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 (ver referencia [4]), 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… (ver [4]), 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 dos entradas en log (mismo timestamp) por cada petición de
acceso: un warning y un Acceso con éxito:
2. X-QUERY INJECTION
En la página http://projects.webappsec.org/w/page/13247006/XQuery%20Injection
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 XMLGATEWAY 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.
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.
D. A y B son correctas.
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.
D. Ninguna de las anteriores.
4. Señala las afirmaciones correctas en cuanto a herramientas de análisis de la

seguridad SAST.
A. IPSEC es un protocolo de seguridad de la capa de red.
B. SSL es un protocolo de seguridad de la capa de transporte.
C. SOAP es un protocolo de seguridad.
D. Todas las anteriores son falsas.
5. Señala la afirmación falsa.

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.
TEMA 3 – Test 70

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 DASD o SAST para testear la
seguridad de los servicios web.
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. En encadenamiento de peticiones, en escenarios donde un proveedor de servicio
reencamina la petición a un tercer servicio, el servicio puede usar mecanismos
de autenticación como SAML assertion.
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. Las relaciones de confianza y la concesión de privilegios son dos conceptos
sinónimos.
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 modelo de gestión de la autorización.
TEMA 3 – Test 71
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. Incluye tanto la seguridad de sesión / nivel de transporte (es decir, SSL / TLS),
así como la seguridad a nivel de aplicación, como la proporcionada a través de
WS-Message.
10. Respecto a la evaluación de la seguridad de los servicios web, señala las

afirmaciones correctas:
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 tipo SAST.
D. Ninguna de las anteriores.
TEMA 3 – Test 72

Tema 3

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

Tema 3

Cargado por

Copyright:

Formatos disponibles

Seguridad de los servicios web

[3.1] ¿Cómo estudiar este tema?

[3.2] Introducción a la seguridad de los servicios web

[3.3] Funciones y tecnologías de la seguridad de los servicios web

[3.4] Evaluación de la seguridad de los servicios web

[3.5] Protección online. Firewalls y Gateways XML

[3.6] Referencias bibliográficas

3.1. ¿Cómo estudiar este tema?

Para el estudio de los diferentes apartados, se ha de seguir el documento elaborado por el

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

3.2. Introducción a la seguridad de los servicios web

TEMA 3 – Ideas clave 3

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

TEMA 3 – Ideas clave 4

Figura 2. Estructura de los mensajes. http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb

Arquitectura servicios web

La arquitectura más simple de los servicios web se representa en la figura 3, donde

Este protocolo permite realizar intercambios de información entre diversas

TEMA 3 – Ideas clave 5

Figura 3. Arquitectura servicios web.

Elementos y dimensiones de la seguridad SW

Los mensajes que se intercambian entre entidades.

TEMA 3 – Ideas clave 6

Relaciones de confianza entre entidades para establecimiento de los servicios de

Requisitos y especificaciones de seguridad SW

En la figura 4, se muestran las dimensiones de seguridad relacionadas con los

» Implementar una política de seguridad que determine qué requisitos de

TEMA 3 – Ideas clave 7

Figura 4. Seguridad extremo a extremo.

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

Figura 5. Dimensiones, requisitos y especificaciones de seguridad de SW. NIST SP-800-95.

TEMA 3 – Ideas clave 8

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

Figura 6. Estándares de seguridad para servicios web. NIST SP-800-95

Organizaciones y estándares de seguridad SW

TEMA 3 – Ideas clave 9

han generado más de cincuenta especificaciones técnicas que están orientadas a la

» OASIS [4] (Organization for the Advancement of Structured Information

» IBM/Microsoft/Verisign/RSA Security. Mediante un proceso de colaboración

Amenazas, riesgos y vulnerabilidades SW

Alteración de mensajes. Un atacante inserta, elimina o modifica la información

TEMA 3 – Ideas clave 10

Forged claims. Un atacante construye un mensaje con credenciales falsas que

3.3. Funciones y tecnologías de seguridad de los servicios web

TEMA 3 – Ideas clave 11

3.1. Política de seguridad

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

» WS-Policy. Es la especificación encargada de delimitar las diferentes políticas de

» WS-Privacy. Establece como se van a implementar la seguridad de los servicios

» WS-Trust. En esta especificación se incluye el proceso de solicitud, emisión y

TEMA 3 – Ideas clave 12

WS-Federation es la especificación que describe la forma de llevar a cabo la

» P3P (Platform for Privacy Preferences). Es una especificación propuesta por el

Puedes acceder a las Especificaciones de seguridad en Servicios Web: Conceptos de

TEMA 3 – Ideas clave 13

3.2. Confidencialidad e integridad

Aunque los mecanismos de seguridad de capa de transporte se proporcionan mediante

A continuación, se describen las tecnologías que pueden ser aprovechadas para

TEMA 3 – Ideas clave 14

de los datos, el no repudio de las transacciones y criterios de autenticación sobre la

» XML Encryption. Esta especificación de W3C, permite cifrar el mensaje entero o

» XKMS. Desarrollado por el W3C, está orientado a la obtención de información

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