Web

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

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

Seguridad en Aplicaciones Online
Ideas clave
5.1. ¿Cómo estudiar este tema?
Para estudiar este tema lee las Ideas clave que encontrarás a continuación.
Los principios de diseño de las aplicaciones distribuidas basadas en servicios web tienen
su origen en lo que se denomina Arquitectura orientada a servicios (SOA). Como
ejemplos de esta arquitectura se pueden nombrar tecnologías tan conocidas como RPC,
RMI, CORBA o DCOM.
Los servicios web se pueden definir como un conjunto de aplicaciones o de tecnologías

con capacidad para interoperar en la web. Estas aplicaciones o tecnologías intercambian
datos entre sí con el objetivo de ofrecer unos servicios. En este tema se analizan las
amenazas y riesgos que pueden sufrir los servicios web y la correcta implementación
de las contramedidas necesarias para contrarrestarlas y tener un funcionamiento lo
más seguro posible. Es necesario, previo al despliegue y en todo momento, conocer el
estado real de la seguridad de los servicios web desplegados en una organización, para lo
cual hay que conocer los métodos y herramientas disponibles para evaluar su
seguridad.
5.2. Introducción a la seguridad de los servicios web
Los servicios web como se estudió en el tema 1 tienen su origen en lo que se denomina
Arquitectura orientada a servicios (SOA). Como ejemplos de esta arquitectura se
pueden nombrar tecnologías tan conocidas como RPC, RMI, CORBA o DCOM. Los
servicios web se pueden definir como un conjunto de aplicaciones o de tecnologías con
capacidad para interoperar en la web. Estas aplicaciones o tecnologías intercambian
datos entre sí con el objetivo de ofrecer unos servicios.
TEMA 5 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios
solicitan un servicio llamando a estos procedimientos a través de la web (ver figura
siguiente).
Figura 1. Procedimientos. Fuente: http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb
Estos servicios proporcionan mecanismos de comunicación estándares entre diferentes

aplicaciones que interactúan entre sí para presentar información dinámica al
usuario.
Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones y que al

mismo tiempo sea posible su combinación para realizar operaciones complejas es
necesaria una arquitectura de referencia estándar.
Para la comunicación entre las diferentes entidades o aplicaciones que actúan como
consumidores de servicios o proveedores de los mismos, los servicios web emplean un
protocolo denominado SOAP que tiene estructura XML (ver figura de abajo):
» Una envoltura.
» Una cabecera con datos descriptivos.
» Un body o contenido.

Figura 2. Estructura de los mensajes

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

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

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

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

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

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

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

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

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

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

requisitos de seguridad y de las especificaciones disponibles más importantes para
implementar dichos requisitos de seguridad.
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 el cuadro de la figura de abajo, a través de las capas de comunicación del
protocolo TCPIP:
» SSL/TLS.
» IPSEC.
» Cifrado XML.
» Firma XML.
» Control de acceso SAML o XACML.
» WS-Security.
» WS-policy.
Figura 6. Especificación de seguridad para servicios web. NIST SP800-95

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

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

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


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

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

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

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-SecurityPolicy. Establece cómo se van a implementar la seguridad de los

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

identidad de las entidades, registrarlas y asignar identificadores digitales.

Posteriormente permite los accesos a los recursos en base a los atributos de las entidades
o política de acceso determinada. Existen varias arquitecturas IDMS (figura siguiente):
Figura 8. Web Service Security. Fuente: https://msdn.microsoft.com/en-

us/library/ff648318.aspx#WSSecurityStandards
» Aisladas (parwise): de poca escalabilidad. Cada servicio deber tener su propia base
de datos de identidades y gestionarla.
Figura 9. Problemas de escalabilidad


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


Federadas para autenticación inter-dominios:
Figura 11. Federadas para autenticación inter-dominios. Fuente: https://msdn.microsoft.com/en-

us/library/ff648318.aspx#WSSecurityStandards
» Distribuidas: Gateways XML (figura siguiente).
Figura 12. Gateware XML: arquitectura distribuida

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fuente: https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

servicios como lo son los servicios web es necesario basarse en soluciones de seguridad
estandarizadas que existen para el protocolo SOAP, protocolo en el que basan su
comunicación muchos de los servicios web implementados en la actualidad.
La lección magistral está disponible en el aula virtual
TEMA 5 – Lo + recomendado © Universidad Internacional de La Rioja (UNIR)

No dejes de leer…
Magic quadrant for SOA governance technologies
Este artículo es una comparativa sobre las prestaciones en cuanto a servicios web y
arquitecturas SOA ofrecidas por las compañías más importantes, estableciendo un
ranking entre ellas en base a varios criterios incluida la seguridad de los mismos.
Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

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

amenazas que pueden sufrir las aplicaciones web, las cuales algunas de ellas pueden
materializarse en servicios web.

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

WS-ATTACK
WS-ATTACK.org aporta una clasificación detallada de los ataques que pueden sufrir los
servicios web, las cuales algunas de ellas pueden materializarse en servicios web.

http://www.ws-attacks.org/Welcome_to_WS-Attacks
Web Srevice Haccking (SOAPUI)
En este artículo encontraremos algunas pruebas simples que podemos realizar para
hacer la prueba del servicio web.

https://www.soapui.org/soap-and-wsdl/tips---tricks/web-service-hacking.html

+ Información
A fondo
XML Technology
Ampliación de la tecnología XML que incluye, XML Namespaces, XML Schema, XSLT,
Efficient XML Interchange (EXI).

https://www.w3.org/standards/xml/
Security design guidelines for web services
En esta página se pueden consultar una guía que puede servir de chacklist para cubrir
todos los aspectos y funciones de seguridad de los servicios web para su protección.

https://msdn.microsoft.com/en-us/library/ff649737.aspx
TEMA 5 – + Información © Universidad Internacional de La Rioja (UNIR)

Especificaciones de seguridad para SW
La Junta de Andalucía provee de un sitio web que resume las especificaciones más
importantes para implementar la seguridad de un servicio web.

http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/211
Enlaces relacionados
OWASP
Página del proyecto abierto para seguridad de las aplicaciones web.
Accede a la página desde el aula virtual o a través de la siguiente dirección web:

https://www.owasp.org/index.php/Web_Services
OASIS web services security (WSS) TC
Página del estándar abierto de seguridad de los servicios web.

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

National institute os standars and technology
Página del Instituto de estándares y tecnología americano.

Cgisecutity
Cgisecurity proporciona información sobre seguridad web. Este sitio cubre aspectos de
seguridad de Bases de datos, Servidores web, Web application security, HTTP, Web
services security y más.

http://www.cgisecurity.com/ws.html
Bibliografía
Bertino, E., Martino, L., Paci, F. y Squicciarini, A. (2010). Security for Web Services and
Service-Oriented Architectures. Berlin: Springer-Verlag Berlin and Heidelberg GmbH &
Co. KG.
Guía de seguridad de servicios web del NIST SP 800-95. Recuperado el 24 de agosto de

2017 de http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-95.pdf
Firewalls app. web practices configuration auditing. 2007. Recuperado el 24 de agosto

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

OASIS Web Services Security (WSS) TC. Recuperado el 24 de agosto de 2017 de:
Owasp Web Service Security. Recuperado el 24 de agosto de 2017 de:
https://www.owasp.org/index.php/Web_Services
Owasp Web Service Security Project. Recuperado el 24 de agosto de 2017 de:

https://www.owasp.org/index.php/Category:OWASP_Web_Services_Security_Project
Owasp Web Service Security cheat seat. 2015. Recuperado el 24 de agosto de 2017 de:
https://www.owasp.org/index.php/Web_Service_Security_Cheat_Sheet
Seguridad en servicios web. Junta de Andalucía. 2017. Recuperado el 24 de agosto de

2017 de: http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/211
Web Services Interoperability Organization. Recuperado el 24 de agosto de 2017 de:

http://www.ws-i.org/deliverables/matrix.aspx
Web services architecture W3C. Recuperado el 24 de agosto de 2017 en

http://www.w3.org/TR/ws-arch/#id2260892
Ws Security Challenges, Threats and Countermeasures Version 1.0 Final Material. Web
Services Interoperability Organization. Disponible en: http://www.ws-
i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf

Actividades
Trabajo: Configurar la seguridad de servicios web
Descripción
En esta actividad configuraremos la seguridad de servicios web mediante

soluciones de seguridad de open source.
Corisecio Corporate Information Security

http://opensource.corisecio.com/index.php?id=get_started y Eperi
http://eperi.de/en/open-source/eperi-xml-gateway/ ponen conjuntamente a libre
disposición varias soluciones diferentes para dar seguridad a servicios web.
Una vez revisada la documentación de la última y reciente versión (de abril de 2104) del
software para seguridad de servicios web (Corisecio y Eperi) no está adecuadamente
actualizada por EPERI y puede llevar a confusiones. Por tal motivo, se va a utilizar la
versión inmediatamente anterior cuya documentación está bastante bien ajustada a las
capacidades del software correspondiente a la versión inmediatamente anterior.
Todo el material está disponible en Internet en un alojamiento Dropbox
En esta actividad se van a utilizar conjuntamente dos soluciones de seguridad:
» SOA Security Demostrator para implementar servicios de autenticación, firma digital

y cifrado con una aplicación de compra de libros ejemplo. (8 de 10 puntos), diseñada
para aprendizaje.
» XML Gateway (opcional) para validación de esquemas y prevención de ataques SQLI
entre otros. (2 de 10 puntos).
Requisitos
El alumno debe manejar los conceptos de certificados digitales y su uso, uso de

algoritmos de claves públicas, uso de la firma digital, no repudio, autenticación,
integridad y cifrado. Además, debe conocer los conceptos y arquitectura de diseño de los
servicios web.
TEMA 5 – Actividades © Universidad Internacional de La Rioja (UNIR)

Metodología
En la figura 1, se presenta un esquema de lo que se pretende con esta actividad. Es una

demostración de lo que se puede conseguir con las soluciones anteriores siguiendo el
documento de ayuda Tutorial secRT demostrator y los documentos auxiliares de
referencia además de estas instrucciones.

» Se dispone de un servicio de tienda web de libros (consumer), otro servicio de
suministro de los libros (provider) y un tercer servicio que se encarga de posibilitar el
pago de los libros solicitados por un usuario (payment).
» Se dispone de tres conectores de seguridad (SOA Security Gateway), en la figura en

rojo que realizan las acciones de seguridad de autenticación, integridad, no repudio y
confidencialidad, descritas en la figura y detalladas más adelante.
» Cuando se despliegan los tres servicios se arranca una aplicación de monitorización

que intercala puertos (en amarillo) para poder ver tráfico de mensajes entre servicios
para comprender mejor las acciones que realizan los conectores de seguridad (en
rojo).
» Por último se intercala antes del servicio de pago un firewall XML (OPEN XML
GATEWAY) para implementar validación de esquemas y protección de ataques SQL-
XQUERY INJECTION.


Figura 1. Seguridad de servicios web con soluciones open source

Instalación
Para su instalación en plataforma con S.O. Windows, hay que seguir los pasos siguientes:

» Asegurarse de que los puertos 80, 443, 8080 están libres.

» Descargar SOA Demonstrator
Descarga SOA Demostrator a través de la siguiente dirección web:

https://www.dropbox.com/s/emlnz3ufl2aak83/SOA-DEMO.zip
El directorio resultante contiene las versiones de apache TOMCAT y de JAVA

necesarias. A continuación ejecutar startDemostrator.cmd (donde hay que
actualizar las rutas de instalación del producto para un correcto arranque
de TOMCAT con la versión de JAVA que trae consigo). Una vez actualizado el
script, se ejecuta para desplegar los tres servicios web sobre Apache Tomcat y
arrancar la aplicación de monitorización del tráfico XML.


» Ejemplo de script startDemostrator.cmd (actualizar las rutas convenientemente):

set JAVA_HOME= C:\...\SOA-DEMO\Java\
set CATALINA_HOME= C:\...\SOA-DEMO\SOA-DEMO\Tomcat
set PATH=%JAVA_HOME%\bin;%PATH%
cd "C:\...\SOA-DEMO\Tomcat\bin"
start cmd /ccall C:\... \SOA-DEMO\Tomcat\bin\startup.bat
cd "C:\...\SOA-DEMO"
cd TCPMonitor
start tcpmon.bat
cd C:\...\SOA-DEMO

» Se recomienda crear y alojar en el mismo subdirectorio que startDemostrator.cmd
un script (parar.cmd) para parar el servidor Apache, con el siguiente contenido
actualizando las rutas a vuestra particular configuración:

Contenido de Parar.cmd:
set JAVA_HOME=C:\Users\...\SOA-DEMO\Java\
set CATALINA_HOME=C:\Users\...\SOA-DEMO\Tomcat
set PATH=%JAVA_HOME%\bin;%PATH%

cd "C:\Users\...\SOA-DEMO\Tomcat\bin"
start cmd /ccall C:\Users\...\SOA-DEMO\Tomcat\bin\shutdown.bat
» Descargar XML Gateway desde:
Descarga XML Gateway a través de la siguiente dirección web:

https://www.dropbox.com/s/pp9ntpxqgrdvy6g/ROOT.war
o La solución es una aplicación desplegable en Apache denominada ROOT. Hay que

copiar ROOT.war en el directorio webapps del servidor Apache Tomcat de SOA
Demonstrator instalado en el paso anterior. De esta forma, al arrancar TOMCAT se
despliegan SOA SECURITY DEMOSTRATOR y XMLGATEWAY en la figura 1, para
poder configurar seguidamente la seguridad de los servicios web como se indica en la
figura 1.


Arranque de Tomcat con las soluciones de seguridad y la aplicación

tpcmonitor:
» Ejecutar  startDemonstrator.cmd arranca Tomcat, despliega SOA Demostrator

y XML Gateway y arranca Tcpmonitor.
» Importante: después de arrancar el servidor hay que descargar el fichero config.xml
de:
Descárgalo a través de la siguiente dirección web:

https://www.dropbox.com/sh/cgkzwq2z6qyy1kd/viPuZUC2ln
» Una vez descargado, hay que sustituir el fichero config.xml que viene por defecto en
la instalación en la ubicación:
C:\Users\...\SOA-DEMO\Tomcat\webapps\WSDemo\config.xml
por el descargado previamente de Dropbox, que tiene la parametrización correcta de

puertos para navegar a través de los puertos de Tcpmonitor.
» Parar y arrancar Apache Tomcat para que se cargue la nueva configuración.

Acceso a los conectores de seguridad de SOA Demostrator y Gateway XML:
Se accede mediante las URL,s siguientes:
o http://localhost:8080/consumer/
o http://localhost:8080/provider/
o http://localhost:8080/payment/
o http://localhost:8080/XMLGATEWAY/
La contraseña de acceso inicial es secRT.

Seguidamente se muestra una pantalla, donde hay que configurar la ubicación de la

base de datos derby que utiliza cada conector (ver apartado 4.4.3 Data store de la
UserGuide secRT):
» Hay que especificar una ruta con un subdirectorio final que no exista,
fuera del directorio WEBAPPS de aplicaciones de APACHE, por ejemplo:
C:\Users\...\SOA-DEMO\...
» Se configura un usuario/password.
» La clave de encriptación viene predefinida y se deja como está.
A continuación la aplicación del conector de seguridad redirige a la pantalla inicial y

ya se puede comenzar a configurar.

Configuración
Seguidamente, hay que configurar las funciones de seguridad de autenticación, firma y

cifrado de la petición-respuesta en cada conector de seguridad (en rojo) desplegados en
el servidor de aplicaciones Apache Tomcat donde también están desplegados los
servicios web, según la figura 1. (ver documentación que viene con el producto: Tutorial
secRT demostrator y otros de referencia para consultar la correcta parametrización de
las funciones). En cuanto a las funciones de cifrado, se aplican dos veces, una para los
datos de pago que son una parte de la orden de petición y la otra para toda la orden de
petición. Se deben cifrar por tanto, los datos de pago en primer lugar, porque van
incluidos dentro de la orden de pedido y deben viajar a través de provider cifrados hasta
payment que es quién solamente debe poder descifrarlos.
» Conector de seguridad de Consumer. Se accede mediante la url

http://localhost:8080/consumer/ (se puede utilizar también https). Se deben de
configurar las siguientes funciones de autenticación, firma y cifrado de la petición a
enviar en menú WORFLOW de Consumer:
o SetsecRTEntity.
o EctractFromRequest.
o WSSecurityAddSAMLToken (SAML 1.1).
o EncryptXPathForCertificate, para cifrar el elemento paymentInformation de la
petición XML.
o SignSOAPEnvelope.

o EncryptXPathForCertificate, para cifrar el elemento Order de la petición XML.

o EnvelopeInRequest.
o Proxy para redirigir la petición al servicio web provider a través del puerto 2100
del tcpmonitor.
En la respuesta se debe configurar:
o ExtractFromResponse.
o DecryptXPath para descifrar el resultado de la petición.
o EnvelopeInResponse.
» Conector de seguridad de Provider. Se accede mediante la url

http://localhost:8080/provider/ Descifra el elemento Order de la petición del
Consumer y verifica la firma. Se deben configurar para ello las siguientes funciones
en el menú WORKFLOW de provider.
o SetsecRTEntity.
o DecryptXPath, para descifrar el elemento Order de la petición XML.
o WSSecurityCheckSAMLToken (SAML 1.1).
o VerifySOAPEnvelope.
o Proxy para redirigir la petición al servicio web payment a través del puerto 2300
del tcpmonitor.
Para asegurar la respuesta se debe configurar:
o ExtractFromResponse.
o EncryptXPathForCertificate para cifrar el resultado de la petición: Elemento
OrderingResult.
o EnvelopeInResponse.

» Conector de seguridad de Payment. Se accede mediante la url

http://localhost:8080/payment/ Descifra la información de pago. Se deben
configurar para ello las siguientes funciones en el menú WORKFLOW de Payment:
o SetsecRTEntity.
o DecryptXPath, para descifrar el elemento paymentInformation de la petición
XML.
o Proxy para redirigir la petición al XMLGATEGAY (puerto 80) o al puerto 2600 del
TCPMonitor si se opta por no intercalar y configurar XMLGATEWAY.
» XML Gateway. (opcional) Se accede mediante la url

http://localhost:8080/XMLGATEWAY/. Está prácticamente configurado con
el nivel de seguridad en su nivel1 según se descarga y solamente hay que
configurar y habilitar las protecciones siguientes (ver apéndice):
o Ataques XQUERY INJECTION - SQLI. Para ello hay que diseñar una
expresión regular [1][2][3], que elimine caracteres y secuencias malignas sin
perjudicar el funcionamiento de los servicios. (ver vulnerabilidad sqli).
o Validación de Schema. Por defecto valida contra the standard schema for
SOAP 1.1 messages, por tanto, añadiendo la función de validación valida por
defecto. No obstante lo ideal es averiguar contra que esquema se valida
(http://soapuser.com/basics3.html) la envoltura de los mensajes. Se ve también
en los propios mensajes en el tráfico de la aplicación..
o Configurar la entidad provider del XmlGateway para que redirigir las peticiones
al puerto 2600 del TCPMonitor.
Recomendaciones

» Seguir la documentación para entender las funciones de seguridad a implementar. El
tutorial de SOA Demonstrator es el primer documento que deberíais consultar
aunque en las funciones implementadas en su ejemplo no son exactamente las
mismas que las de la práctica.


» Implementar primero la parte de los conectores de seguridad sin XMLGATEWAY.

Una vez instalados los conectores CONSUMER, PROVIDER y PAYMENT intercalar
XMLGATEWAY como en la figura y luego configurar las protecciones pedidas.

» Implementar las funciones de autenticación, firmado y cifrado de forma
escalonada no a la vez. Cuando se va superando una fase con una función
comprobando que funciona la aplicación se pasa a la siguiente.

» Se necesitara generar la clave pública de cada una de las tres entidades desde la
aplicación correspondiente a cada conector de cada una de las entidades Consumer,
Provider y Payment. Recordar el concepto de que para cifrar algo que se envía
(ORDER de petición por ejemplo) se usa la clave pública del destinatario. Tener esto
en cuenta a la hora de configurar las funciones de cifrado.

» Mediante TCPMONITOR se puede ver en cada paso el tráfico XML de las peticiones
y respuestas entre las entidades.

Documentación
Descargar desde la siguiente dirección:

https://www.dropbox.com/sh/cgkzwq2z6qyy1kd/viPuZUC2ln
Entrega
El alumno deberá entregar una memoria (máx 15 pag.) explicando la configuración de

las funciones, expresiones regulares utilizadas en la prevención de ataques SQLI,
certificados digitales y claves necesarios para su correcto funcionamiento y deberá
demostrarlo con los LOG descargables (opción salvar) desde cada puerto de la
aplicación TCPMONITOR (2100, 2300, 2400, 2600), copias de pantallas de la
aplicación TCPMonitor (con la fecha-hora visibles de las peticiones) y de los conectores
de seguridad y proporcionando el último archivo de log cada uno de los conectores de
seguridad: (ej. C:\..\.. \Tomcat\webapps\consumer\log\conector.2013-04-17.log) y del
XmlGateway.

Referencias
[1] SANS. Detecting Attacks on Web Applications from Log Files.

https://www.sans.org/reading-room/whitepapers/logging/detecting-attacks-web-
applications-log-files-2074
[2] http://regexlib.com
[3] http://www.symantec.com/connect/articles/detection-sql-injection-and-cross-site-
scripting-attacks
[4] SOAP Messages. Soapuser.com. http://soapuser.com/basics3.html
Apéndice
Validación de esquema
Añadiendo la función de validación de esquema, sin configurar ningún parámetro, se

valida por defecto contra el standard schema forSOAP 1.1 messages (Modeling
reference_SOASecurity.pdf). No obstante la validación veréis que da un warning En
cuanto al log de salida, dado que no se ha configurado con ninguna función, considera
exitosa la respuesta al no encuentran ningún problema de seguridad (ver pantallas
subsiguientes).
Se debe investigar contra qué esquema validar. Si en el fichero del esquema añadimos la
dirección del esquema XML que se va a validar, en este caso la correspondiente al
envoltorio SOAP (http://soapuser.com/basics3.html) la validación la realiza
correctamente al identificar un esquema correcto en el mensaje enviado. En este caso la
envoltura, etiqueta Envelope del mensaje de un mensaje SOAP, se valida y se
comprueba que está codificada según el esquema (http://soapuser.com/basics3.html)
por lo que al añadirlo en la configuración de la validación va a ser identificado como un
mensaje correctamente codificado.

En la práctica, aparecen 2 entradas en log (mismo timestamp) por cada petición de

acceso: un warning y un Acceso con éxito:

X-Query Injection
Accede a más información en la siguiente dirección web:

http://projects.webappsec.org/w/page/13247006/XQuery%20Injection
En esta página se describe muy bien este tipo vulnerabilidad  ataque:
XQuery Injection is a variant of the classic SQL injection attack against the XML
XQuery Language. XQuery Injection uses improperly validated data that is passed
to XQuery commands. This inturn will execute commands on behalf of the attacker
that the XQuery routines have access to. XQuery injection can be used to enumerate
elements on the victim's environment, inject commands to the local host, or execute
queries to remote files and data sources. Like SQL injection attacks, the attacker
tunnels through the application entry point to target the resource access layer.
Using the example XML document below, users.xml.
<?xml version="1.0" encoding="ISO-8859-1"?>
<userlist>
<user category="group1">
<uname>jpublic</uname>
<fname>john</fname>
<lname>public</lname>
<status>good</status>
</user>
<user category="admin">
<uname>jdoe</uname>
<fname>john</fname>
<lname>doe</lname>
</user>
<uname>mjane</uname>
<fname>mary</fname>
<lname>jane</lname>
</user>
<uname>anormal</uname>

<fname>abby</fname>
<lname>normal</lname>
<status>revoked</status>
</user>
</userlist>
An typical XQuery of this document for the user mjane:

doc("users.xml")/userlist/user[uname="mjane"]
Would return:
<uname>mjane</uname>
<fname>mary</fname>
<lname>jane</lname>
</user>
Assuming that the XQuery gets its user name string from the input, an
attacker can manipulate this query into returning the set of all users. By
providing the input string:
something" or ""="
the XQuery becomes:
doc("users.xml")/userlist/user[uname="something" or ""=""]
» En XML Gateway podemos especificar una regla para impedir el string or.
» XMLGateway en su documentación (Modeling reference_SOA Security), con respecto
a la función CheckForSQLInjection (En realidad es la función Prevent SQL-
XQuery Injection en XMLGateway), nos dice como añadir una regla (todas las
que queramos), es una validación tipo blacklist. Cada regla consta de una pareja
nombre-valor (expresión regular). Este valor lo buscará XMLGateway en el body de
las peticiones y si lo encuentra bloqueará.
» A continuación, para comprobar un ataque, ponemos el string or en cualquier campo
de una petición de libros y veremos que el Gateway bloquea.

» ¡OJO! En las referencias de expresiones regulares aportadas veréis que las

expresiones vienen con una / al principio y final. En esta herramienta no hay que
ponerlas, ejemplo:
/((\%27)|(\'))(select|union|insert|update|delete|replace| truncate)/ix
sería
((\%27)|(\'))(select|union|insert|update|delete|replace| truncate)

Test
1. Los servicios web son un ejemplo de la arquitectura orientada a servicios SOA. ¿Cuáles
son las entidades que intervienen en una arquitectura más básica?
A. Consumer-provider.
B. Provider-consumer-uddi.
C. Consumer-broker-provider.
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 la afirmación correcta en cuanto a protocolos relacionados con SW.

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

A. XACML es un mecanismo de seguridad para control de acceso.
B. SAML es un mecanismo de seguridad para control de acceso.
C. IPSEC es un protocolo de seguridad de la capa de transporte.
D. La A y la B son correctas.
TEMA 5 – Test © Universidad Internacional de La Rioja (UNIR)

6. Señala la afirmación falsa:

A. Los servicios web pueden tener los mismos tipos de vulnerabilidades que tienen
las aplicaciones web.
B. Los servicios web pueden sufrir ataques XSS, SQLI, XMLM Injection entre
otros.
C. XACML es una especificación para implementar el control de acceso.
D. Los servicios web no pueden tener ataques de escalada de privilegios.
7. Señala la afirmación falsa:

A. WS security message es un mecanismo de seguridad usado para proporcionar
un mecanismo seguro de autenticación en los servicios web.
B. Los métodos de autenticación que se utilizan en los servicios web se basan en
HTTP-based token authentication, SSL/TLS-certificate based authentication y
mediante tokens en la petición SOAP.
C. SAML es una especificación para implementar el control de acceso.
D. Un sistema de gestión de identidad (IDMS) es responsable de verificar la
identidad de las entidades, registrarlas y asignar identificadores digitales.
8. Autorización en los SW señala la afirmación falsa:

A. SAML y XACML son dos de las especificaciones que se pueden utilizar para
implementación de los modelos de gestión de la autorización.
B. XACML es una especificación de seguridad para cifrado de mensajes en SW.
C. El principio de mínimos privilegios debe aplicarse siempre independientemente
de la metodología de control de acceso en uso.
D. Role based Access control es uno de los modelos de gestión de la autorización.
9. Para tener confidencialidad e integridad en servicios web señala la afirmación falsa:

A. Los protocolos de transporte seguros pueden asegurar la seguridad de los
mensajes solo durante la transmisión.
B. Es importante hacer frente a los problemas de seguridad en la capa de aplicación
de forma independiente de las capas de transporte.
C. En situaciones en las que se almacenan los mensajes y luego son remitidos es
necesaria seguridad de la capa de aplicación.
D. Es suficiente con la seguridad a nivel de transporte que suministra SSL-TLS.

10. ¿Cuáles de los siguientes son modelos de autorización en SW?

A. Modelo basado en roles.
B. Modelo basado en el riesgo adaptativo.
C. Modelo basado en atributos.
D. Todas las anteriores son ciertas.

Web

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Web

Încărcat de

Drepturi de autor:

Formate disponibile

Seguridad de los servicios web

[5.1] ¿Cómo estudiar este tema?

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

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

Autenticación SEGURIDAD ONLINE

© Universidad Internacional de La Rioja (UNIR)

5.1. ¿Cómo estudiar este tema?

Los servicios web se pueden definir como un conjunto de aplicaciones o de tecnologías

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

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

Figura 1. Procedimientos. Fuente: http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb

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

Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones y que al

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

Figura 2. Estructura de los mensajes

Arquitectura servicios web

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

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

Figura 3. Arquitectura de servicios web

Elementos y dimensiones de la seguridad SW

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

» Los mensajes que se intercambian entre entidades.

Requisitos y especificaciones de seguridad SW

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

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

Se deben cumplir requisitos como:

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

Figura 4. Seguridad extremo a extremo

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

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

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

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

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

Figura 6. Especificación de seguridad para servicios web. NIST SP800-95

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

Organización y estándares de seguridad SW

» OASIS (Organization for the advancement of structured information standards).

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

Amenazas, riesgos y vulnerabilidades SW

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

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

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

5.3. Funciones y tecnologías de la seguridad de los servicios web

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

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-SecurityPolicy. Establece cómo se van a implementar la seguridad de los

» P3P (Platform for privacy preferences). Es una especificación propuesta por el

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

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

» Seguridad end-to-end. Los protocolos de transporte seguro pueden asegurar la

» Independencia de transporte. Incluso si todos los enlaces de comunicación son

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

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

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

» 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 acerca

o XML Key information service specification (X-KISS). Tiene como

o XML Key registration service specification (X-KRSS). Esta especificación

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

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

Por ejemplo un gran número de organizaciones implementan un corta fuegos

El estándar WS-Security se basa en estándares y certificaciones digitales para dotar a

WS-Security define la forma de conseguir integridad, confidencialidad y