6.

1 Conceptos generales

Un servicio web (en ingls, Web services) es una tecnologa que utiliza un
conjunto de protocolos y estndares que sirven para intercambiar datos entre
aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de
programacin diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar
los servicios web para intercambiar datos en redes de computadoras como
Internet.
La
interoperabilidad se consigue mediante la adopcin de estndares abiertos. Las
organizaciones OASIS y W3C son los comits responsables de la arquitectura y
reglamentacin de los servicios Web. Para mejorar la interoperabilidad entre
distintas implementaciones de servicios Web se ha creado el organismo WS-I,
encargado de desarrollar diversos perfiles para definir de manera ms exhaustiva
estos estndares. Es una mquina que atiende las peticiones de los clientes web y
les enva los recursos solicitados.
Ventajas de los servicios web
Aportan interoperabilidad entre aplicaciones de software independientemente de
sus propiedades o de las plataformas sobre las que se instalen.
Los servicios Web fomentan los estndares y protocolos basados en texto, que
hacen ms fcil acceder a su contenido y entender su funcionamiento.
Permiten que servicios y software de diferentes compaas ubicadas en diferentes
lugares geogrficos puedan ser combinados fcilmente para proveer servicios

integrados.
Inconvenientes de los servicios Web
Para realizar transacciones no pueden compararse en su grado de desarrollo con
los estndares abiertos de computacin distribuida como CORBA (Common
Object Request Broker Architecture). Su rendimiento es bajo si se compara con
otros modelos de computacin distribuida, tales como RMI (Remote Method
Invocation), CORBA o DCOM (Distributed Component Object Model). Es uno de
los inconvenientes derivados de adoptar un formato basado en texto. Y es que
entre los objetivos de XML no se encuentra la concisin ni la eficacia de
procesamiento. Al apoyarse en HTTP, pueden esquivar medidas de seguridad
basadas en firewall cuyas reglas tratan de bloquear o auditar la comunicacin
entre programas a ambos lados de la barrera.
Razones para crear servicios Web
La principal razn para usar servicios Web es que se pueden utilizar con HTTP
sobre TCP (Transmission Control Protocol) en el puerto 80. Dado que las
organizaciones protegen sus redes mediante firewalls -que filtran y bloquean gran
parte del trfico de Internet-, cierran casi todos los puertos TCP salvo el 80, que
es, precisamente, el que usan los navegadores. Los servicios Web utilizan este
puerto, por la simple razn de que no resultan bloqueados. Es importante sealar
que los servicios web se pueden utilizar sobre cualquier protocolo, sin embargo,
TCP es el ms comn.
Otra razn es que, antes de que existiera SOAP, no haba buenas interfaces para
acceder a las funcionalidades de otros ordenadores en red. Las que haba eran ad
hoc y poco conocidas, tales como EDI (Electronic Data Interchange), RPC
(Remote Procedure Call), u otras APIs.
Una tercera razn por la que los servicios Web son muy prcticos es que pueden
aportar gran independencia entre la aplicacin que usa el servicio Web y el propio
servicio. De esta forma, los cambios a lo largo del tiempo en uno no deben afectar
al otro. Esta flexibilidad ser cada vez ms importante, dado que la tendencia a
construir grandes aplicaciones a partir de componentes distribuidos ms pequeos
es cada da ms utilizada.
Se espera que para los prximos aos mejoren la calidad y cantidad de servicios
ofrecidos basados en los nuevos estndares.
Plataformas
Servidores de aplicaciones para servicios Web:
Oracle Fusion Middleware
Axis y el servidor Jakarta Tomcat (de Apache)

 ColdFusion MX de [[Macromedia]httpd ]
Java Web Services Development Pack (JWSDP) de Sun Microsystems (basado
en Jakarta Tomcat)
JOnAS (parte de ObjectWeb una iniciativa de cdigo abierto)
Microsoft .NET
Novell exteNd (basado en la plataforma J2EE)
WebLogic
WebSphere
JAX-WS con GlassFish
Zope es un servidor de aplicaciones Web orientado a objetos desarrollado en el
lenguaje de programacin Python
VERASTREAM de AttachmateWRQ para modernizar o integrar aplicaciones host
IBM y VT
PHP

6.2 Estndares
Estndares de servicio Web
Uno de los atributos clave de estndares de Internet es que se centran en
protocolos y no en implementaciones. Internet se compone de tecnologas
heterogneas que operan conjuntamente de modo satisfactorio mediante
protocolos compartidos. Esto impide que los proveedores individuales impongan
un estndar en Internet. El desarrollo del software de cdigo fuente abierto
desempea un rol fundamental para proteger la interoperatividad de
implementaciones
de
estndares
del
proveedor.
Los estndares siguientes desempean roles clave en servicios Web: UDDI
(Universal Description, Discovery and Integration), WSDL (Web Services
Description Language), WSIL (Web Services Inspection Language), SOAP y WS-I
(Web Services Interoperability). La relacin entre estos estndares se describe en
la Figura 2. La especificacin UDDI define estndares abiertos independientes de
la plataforma que permiten a las empresas compartir informacin en un registro de
empresa global, encontrar servicios en el registro y definir cmo actan
conjuntamente en Internet.
WSIL es una especificacin abierta basada en XML que define un mtodo de
descubrimiento de servicios distribuidos que suministra referencias a
descripciones de servicio en el punto de ofertas del proveedor de servicios,
especificando cmo comprobar si hay servicios Web disponibles en un sitio Web.
Un documento WSIL define las ubicaciones en un sitio Web donde se pueden

buscar descripciones del servicio Web. Dado que WSIL se centra en el

descubrimiento de servicios distribuidos, la especificacin WSIL complementa
UDDI facilitando el descubrimiento de servicios que estn disponibles en sitios
Web que quiz no se enumeren an en un registro UDDI. En un tema aparte de
esta documentacin se describe la Relacin entre UDDI y WSIL.
WSDL es una especificacin abierta basada en XML que describe las interfaces y
las instancias de servicios Web en la red. Es ampliable, de modo que se pueden
describir los puntos finales independientemente de los formatos de mensaje o de
los protocolos de red que se utilicen para comunicarse. Las empresas pueden
poner a disposicin de sus servicios Web los documentos WSDL mediante UDDI,
WSIL o divulgando los URL a su WSDL mediante correo electrnico o sitios Web.
WSDL se describe en un tema aparte de esta documentacin.
SOAP es un estndar basado en XML para la transmisin de mensajes en HTTP y
otros protocolos de Internet. Es un protocolo ligero para el intercambio de
informacin en un entorno descentralizado y distribuido. Se basa en XML y consta
de tres partes:
Un sobre que define una infraestructura para describir el contenido del mensaje y
cmo procesarlo.
Un conjunto de normas de codificacin para expresar instancias de tipos de datos
definidos por la aplicacin.
Una convencin para representar llamadas y respuestas a procedimiento remoto.
SOAP permite el enlace y la utilizacin de servicios Web encontrados definiendo
una ruta de mensaje para el direccionamiento de mensajes. Se puede utilizar
SOAP para consultar UDDI para servicios Web.

Relaciones entre SOAP, UDDI, WSIL y WSDL.

Un proveedor de servicios aloja un servicio Web y lo hace accesible con

protocolos como SOAP/HTTP o SOAP/JMS. El servicio Web se describe mediante
un documento WSDL que se almacena en el servidor del proveedor o en un
depsito especial. UDDI Business Registry y sus documentos WSDL pueden
hacer referencia al documento WSDL. Estos contienen punteros a los archivos
WSDL del servicio Web.
Los perfiles WS-I Simple SOAP Binding Profile y WS-I Attachments Profile son
esquemas de requisitos que el trfico de WSDL y de protocolo de servicio Web
(SOAP/HTTP) deben cumplir para afirmar la conformidad WS-I. Las herramientas
de validacin WS-I de servicios Web admiten actualmente WS-I Simple SOAP
Binding Profile 1.0 y Attachment Profile 1.0.
Productos de Rational Developer tambin admiten varios estndares nuevos
de servicios Web. stas son:
JAX-RPC
JAX-RPC son las siglas de Java API for XML-based RPC (API de Java para RPC
basado en XML), tambin conocido como JSR 101. Es una especificacin que
describe las interfaces de programacin de aplicaciones (API) de Java y las
convenciones para crear servicios Web y clientes de servicio Web que utilizan

RPC (llamadas a procedimiento remoto) y XML. Estandariza las correlaciones de

Java con WSDL y de WSDL con Java, asimismo proporciona las API principales
para el desarrollo de servicios Web y clientes de servicio Web en la plataforma
Java.
JSR-109 y JSR-921
JSR-109 y JSR-921 (implementacin de Enterprise Web Services) definen el
modelo de programacin y la arquitectura de ejecucin para desplegar y buscar
servicios Web en el entorno J2EE; ms especficamente, en los contenedores
Web, EJB y de aplicaciones cliente. Uno de los objetivos principales es asegurar
que las implementaciones operen conjuntamente.
WS-S
Estas herramientas admiten el estndar OASIS Web Services Security 1.0.
Las herramientas de servicios Web admiten las siguientes especificaciones:

WSDL (Web Services Description Language)

WSDL (Web Services Description Language) es una especificacin estndar para

describir servicios basados en XML de red. Proporciona a los proveedores de
servicios un modo sencillo de describir el formato bsico de las peticiones a sus
sistemas independientemente de la implementacin del motor de ejecucin
subyacente.
SOAP
SOAP (anteriormente conocido como Simple Object Access Protocol) es un
protocolo ligero para el intercambio de informacin en entornos descentralizados y
distribuidos. Los mensajes SOAP son las transmisiones de informacin de
remitentes a destinatarios. Los mensajes SOAP se pueden combinar para crear
patrones de peticin/respuesta.
UDDI (Universal Description, Discovery, and Integration)
WSIL (Web Services Inspection Language)
WSIL (Web Services Inspection Language) es un mecanismo de descubrimiento
de servicios que es una alternativa a UDDI adems de ser complementario a
UDDI. Cuando encuentra servicios Web con UDDI, se dirige a un registro
centralizado. WSIL es un mtodo alternativo al descubrimiento de servicios Web.
WSIL le permite dirigirse directamente al proveedor de servicios y solicitar los
servicios que proporciona.
JAX-RPC
JAX-RPC son las siglas de Java API for XML-based RPC (API de Java para RPC
basado en XML), tambin conocido como JSR 101. Es una especificacin que
describe las interfaces de programacin de aplicaciones (API) de Java y las
convenciones para crear servicios Web y clientes de servicio Web que utilizan
RPC (llamadas a procedimiento remoto) y XML. Estandariza las correlaciones de
Java con WSDL y de WSDL con Java, asimismo proporciona las API principales
para el desarrollo de servicios Web y clientes de servicio Web en la plataforma
Java. El mecanismo de RPC, a menudo utilizado en modelos de cliente/servidor
distribuido, permite que los clientes ejecuten procedimientos en otros sistemas.
JSR 109 y JSR 921: implementacin de servicios Web de empresa
JSR 109 y JSR 921 (implementacin de servicios Web de empresa) definen el
modelo de programacin y la arquitectura de ejecucin para desplegar y buscar
servicios Web en el entorno J2EE; ms especficamente, en los contenedores
Web, EJB y de aplicaciones cliente. Uno de los objetivos principales es asegurar
que las implementaciones operen conjuntamente.

6.3 Seguridad e interoperabilidad

Seguridad

Siguiendo el modelo W3C, vamos a realizar un pequeo estudio sobre los

requisitos de seguridad que se encuentran enumerados dentro de la arquitectura
de referencia de los servicios web y sealando las diferentes tentativas de ataque
que tambin aparecen dentro de la especificacin. Se ofrecern soluciones para
las
mismas.
Servicios de seguridad bsicos
La seguridad es un concepto considerado clave dentro de los que comprenden el
aseguramiento de calidad dentro del servicio Web. Si se realiza una catalogacin
bsica de los servicios de seguridad son la confidencialidad, integridad,
autenticidad de origen, no repudio y control de acceso. A continuacin se explica
brevemente cada uno de ellos:
Autenticacin de los participantes. Los servicios Web por definicin tienen
mucha heterogeneidad, lo que provoca que los sistema de autenticacin tengan
que ser flexibles. Si imaginamos un servicio Web que necesita comunicarse con
otro servicio, este podra solicitar al demandante credenciales junto a una
demostracin de que es el propietario de las mismas. Resulta necesario conseguir
un estandarizacin de los protocolos y en los formatos a utilizar. Otro problema
remanente es definir un modelo de autenticacin Single Sign-On de forma que un

servicio que necesita comunicarse con otros servicios Web,no tenga la necesidad
de estar continuamente autenticndose y logre completar el proceso de negocio
en un tiempo de respuesta aceptable.

Autorizacin. Con frecuencia , es necesario aplicar unos criterios que permitan

controlar el acceso a los diferentes recursos. Es necesario definir los usuarios que
pueden realizar diversas acciones sobre los diferentes recursos. En combinacin
con la autenticacin, permite a las identidades conocidas realizar las acciones
para las que tienen permisos. Con frecuencia se definen polticas de acceso en
base a jerarquas.

Confidencialidad. Es necesario asegurar que el contenido incluido en los

mensajes que se intercambian se mantiene como informacin confidencial. Es
muy habitual emplear tcnicas de cifrado, ya muy extendidas. Obviamente, la
confidencialidad del mensaje va ms all que el canal por el que es transmitido.

Integridad. Esta propiedad garantiza que la informacin que se ha recibido , es

exactamente la misma que se envi desde el cliente.

No repudio. En una comunicacin que se realizan transacciones, es necesario

registrar que las mismas se han producido y registrar el autor que lo ejecut. En el
caso de los servicios Web, trasladamos esta poltica la uso del servicio. Se
comprueba que cierto cliente hizo uso de un servicio a pesar de que ste lo niegue
(no repudio del solicitante) as como probar la ejecucin se llev a cabo (no
repudio del receptor).

Disponibilidad. Uno de los ataques mas frecuentes a las aplicaciones se basa en

la denegacin de servicios. Se lanzan mltiples solicitudes falsas para inundar el
servicio y provocar su cada. Es necesario contemplar la disponibilidad, como
punto muy importante en el diseo de servicio web, ya que permiten cierta
redundancia de los sistemas.

Auditabilidad. El registro de las acciones en los servicios Web permite mantener

una traza de las mismas de manera que se puedan realizar anlisis posteriores de
los datos.

Seguridad extremo-a-extremo. Cuando se ejecuta un servicio es necesario

garantizar la seguridad durante todo el recorrido que efectan los mensajes. Dado
que normalmente existen routers como intermediarios de la comunicacin, esto
provoca un aumento de la poltica de seguridad que garantice que se realiza el
transporte de forma segura y confirme la seguridad de los intermediarios. Es
importante disponer de un contexto de seguridad nico y que incluya el canal de
comunicacin. Para conseguirlo, es necesario aplicar diversas operaciones de
carcter criptogrfico sobre la informacin en el origen. De esta manera se evita
una dependencia con la seguridad que se configure por debajo de la capa de
aplicacin y se garantiza los servicios de seguridad
Requisitos de Seguridad
Si realizamos una abstraccin sobre la problemtica, el objetivo principal es
conseguir un entorno para las transacciones y los procesos que sea seguro para
todo el canal de comunicacin. Obviamente, es necesario garantizar la seguridad
durante el trnsito de la comunicacin, ya sea con intermediarios o sin ellos
durante la misma. Pro otra parte, se necesita asegurar la seguridad de la
informacin en los procesos de almacenamiento: A continuacin se ofrece una
revisin breve de los principales requisitos para asegurar la seguridad en la
comunicacin.
Mecanismos de autenticacin
La autenticacin es obligatoria para mantener control y verificar la identidad de
solicitantes y proveedores. En algunas ocasiones, resultar necesario realizar una
autenticacin tanto del solicitante como del proveedor, ya que puede producirse
que los participantes no estn en conexin directa. Pueden existir intermediarios
que
retransmitan
la
comunicacin
En funcin de la poltica de seguridad que se adopte, ser necesario autenticar
tanto al proveedor como al solicitante o simplemente a alguno de ellos. Se pueden
emplear mtodos basados en contraseas, certificados , etc.. para formalizar la
autenticacin. Si se basan en contraseas, es necesario aplicar una poltica que
aporte robustez a las mismas.
Se pueden emplear mecanismos basados en protocolos de transporte como
el Http Autentication y SSL/TLS X509 Certificate. Estos mecanismos slo son
vlidos cuando existe una conexin directa entre el consumidor y el proveedor de
servicio, ya que si un mensaje SOAP viaja entre varios endpoints antes de llegar a
su destino, las credenciales del consumidor original se pierden en el primer
endpoint.
Tambin se pueden emplear mecanismos basados en tokens que se incluye
dentro del mensaje. El estndar WS-Security incorpora un gran nmero de tokens
que pueden ser empleados en este caso; Username Token, X509 Certificate,

SAML assertions, etc. Este mecanismo de autenticacin no tiene los problemas de

los mecanismos basados en el transporte, ya que las credenciales pueden viajar
entre los distintos endpoints hasta llegar a su destino. Si usamos este mecanismo,
es necesario que estos sean transmitidos de forma segura para evitar ataques de
replay. Esto puede se consigue mediante la firma del token dentro del mensaje
SOAP, junto a un TimeStamp o IDMessage, por lo que se recomienda incluir en la
firma la cabecera de WS-Addressing. En entornos cerrados tambin se puede
emplear SSL para transmitir los mensajes con Tokens de forma segura, aunque
esta aproximacin es menos segura que la anterior.
Autorizacin
La autorizacin resulta necesaria para efectuar un control sobre el acceso a los
recursos. Una vez se ha realizado la autenticacin sobre el participante y se
conoce su identidad, se utilizarn los mecanismos de autorizacin para realizar las
comprobaciones pertinentes y asegurar el acceso adecuado al recurso por parte
del
participante.
Se crean polticas que determinan los privilegios de los participantes. Mediante la
gestin de la confianza, se permite la interaccin entre un solicitante y un
proveedor sin referencias previas pero que atendiendo a las credenciales que se
intercambian determinen un nivel de confianza asumible por ambos. De esta
manera se permite un proceso de autenticacin sin que haya existido la necesidad
de desvelar las identidades de los participantes en el proceso
Integridad y confidencialidad de los datos
El proceso que mantiene la integridad de los datos, garantiza que la informacin
que se ha enviada no ha sufrido ninguna transformacin sin que se haya
detectado. La confidencialidad, asegura los principios de intimidad de la
informacin. Es decir solo se permite el acceso a la informacin a aquellos
participantes con permisos para hacerlo. Con frecuencia, se usan tcnicas de
cifrado para conceptos de confidencialidad y la firma digital para temas de
integridad.
No repudio
El objeto de las tcnicas de no repudio ya se han comentado anteriormente, es
registrar la participacin y el grado de la misma de los diferentes interlocutores en
una transaccin para protegerlo de una posible denegacin, posiblemente por
parte de algn interlocutor de la misma, negando de que la transaccin ocurri o
de su participacin en la misma.
Las tcnicas de no repudio permiten proporcionar evidencias sobre lo sucedido en
la transaccin, de manera que una tercera parte resuelve el desacuerdo
producido.

Para garantizar el no repudio dentro de las comunicaciones por Servicios Webs,

los mensajes SOAPs intercambiados debern ser identificados de forma nica
mediante el uso de la especificacin WS-Addressing. Los mensajes SOAP junto a
sus cabeceras "relevantes", debern ser firmadas segn los procedimientos
recogidos en la especificacin WS-Security. Por ltimo, los mensajes debern ser
almacenados en ficheros de logs, para su posterior consulta.
Rastreabilidad
Es necesario ajustar trazas que aseguren poder conocer informacin del acceso
una vez se haya producido este, y comprobar el comportamiento que ha tenido el
usuario que ha realizado el acceso. Son de especial importancia para verificar la
integridad del sistema. Normalmente las trazas las generen los determinados
"agentes de auditoria" que pueden realizar monitoreo, observar recursos y el
comportamiento de otros agentes, y validar el cumplimiento de las polticas
establecidas. Con frecuencia , no es posible prevenir la violacin de las diferentes
obligaciones pero si un agente de auditoria detecta una brecha podra activar un
plan de repulsa o determinar otro tipo de actividades.
Aplicacin distribuida de las polticas de seguridad
Si se han definido arquitecturas que estn basadas en Servicios Web, estn
deben permitir la definicin de polticas de seguridad y comprobar su cumplimiento
en las diversas plataformas y con las diversas variaciones de acceso al servicio.
Uso de polticas
Los mensajes que se envan en la comunicacin de los servicios Web atraviesan
los cortafuegos y pueden ser modificados a travs de los diferentes puertos y
protocolos existentes. Es necesario, para asegurar la calidad de seguridad en los
servicios Web, crear polticas corporativas para integrarse con las diversas
polticas de los proveedores y con la gestin de la confianza planificada.
Polticas distribuidas
Con frecuencia, se asocian las polticas de seguridad a los proveedores o a los
clientes o a un mecanismo de descubrimiento. Se utilizan para controlar y definir la
metodologa de acceso de las peticiones y las respuestas a las mismas, dadas por
los involucrados en la comunicacin. Estas polticas son validadas en ejecucin
dentro del contexto de la comunicacin. Cada parte involucrada debe realizar la
validacin de sus polticas.
Polticas de confianza
Defiendo de manera simple una poltica de confianza como una poltica distribuida
que asegura a dos entidades que afrontan una interaccin sin conocerse
previamente. Mediante el uso de credenciales, asumen el nivel de seguridad que

pueden soportar. En ocasiones, la definicin de estas polticas implica a terceras

entidades de forma recursiva, que influyen en la decisin. Un ejemplo, "yo confi
en esta entidad, si mis dos compaeros confan en ti y tu confas en mis dos
compaeros"
Mecanismo de Descubrimiento Seguro
El mecanismo de descubrimiento seguro controla las publicaciones y apariciones
de un servicio. Cuando aparece un servicio, es necesario realizar una evaluacin
de las polticas de publicacin del servicio, exceptuando las situaciones que
supongan un servicio de descubrimiento entre nodos. Si el descubrimiento lo
realiza un cliente, puede dotar de identidad o no drsela al servicio. En esta
segunda situacin hablamos de un descubrimiento annimo.

Confianza y Descubrimiento
Si imaginamos una situacin donde un cliente descubre que existe un servicio
Web muy necesario para l, y el proveedor del mismo, es una entidad
desconocida hay que preguntarse que nivel de confianza puede otorgar el
solicitante a ese servicio. Esta situacin es especialmente importante en el caso
que se este manejando informacin muy sensible, ya que se esta corrigiendo un
riesgo grave.
Privacidad
La privacidad se expresa mediante las diferentes polticas definidas por los
diferentes propietarios de los datos. Con frecuencia, los propietarios son los
usuarios de los servicios Web. Es necesario asegurar que los privilegios y
derechos de los usuarios son respetados
Fiabilidad de los servicios Web
La aparicin de errores es inevitable, especialmente si consideramos que el
contexto engloba a multitud de servicios interconectados por una red global que
pertenecen a todo tipo de personas y entidades. La eliminacin de errores no
puede ser completa, as que el objetivo principal es reducir la tasa de errores que
aparecen al nivel mximo posible.
Si hablamos de fiabilidad dentro de los servicios Web, podemos realizar una
clasificacin en funcin de la predecibilidad y la fiabilidad de:
Los servicios de la infraestructura, como un mecanismo de transporte de los
mensajes o un servicio de descubrimiento.
Las interacciones entre los servicios.
El comportamiento individual del solicitante y del proveedor.

Amenazas de seguridad
Si analizamos el concepto de amenaza de seguridad, tendemos a asumir que
existir un intento de acceso y mal uso de los servicios. Por lo tanto hay que
realizar un esfuerzo para controlar los accesos no permitidos. Si realizamos una
clasificacin de las principales amenazas, tenemos lo siguiente:
Acceso no permitido llevado a cabo por entidades sin identificar. Es necesario
poder identificar de forma confiable la identidad de proveedores, servicios, etc...

Alteracin de la informacin en el canal de comunicacin. Es necesario garantizar

la integridad de la informacin que se enva.

Debe asegurarse el acceso a la informacin. Solo pueden acceder las partes

deseadas. Debe de mantenerse una certeza del contenido y de que la
comunicacin tuvo lugar.
El acceso inapropiado a los recursos. Debera ser posible garantizar que los
recursos y las acciones no son accesibles por aquellas partes que no estn
autorizadas. De nuevo, este hecho se podra extender al mero conocimiento de
que cierto recurso existe, es decir, de alguna forma se debera poder impedir que
personas no autorizadas no puedan conocer la existencia de ciertos recursos o
ciertos servicios.

Denegacin de servicio. No debera ser posible que los clientes de los servicios no
puedan acceder a l.
Tipos de ataques
Los tipos de ataques que se listan a continuacin estn extrados de la
especificacin W3C.
Alteracin de los mensajes
Es un tipo de ataque centrado sobre la integridad de los mensajes. Se busca
modificar el contenido del mensaje (ya sea parcialmente o totalmente). En el caso
que el atacante tuviera controlado un canal de comunicaciones entre servicios
podra modificar los mismos, eliminarlos, capturarlos y reenviarlos.
La integridad de los mensajes se proporciona mediante la firma digital del fichero
XML junto con tokens de seguridad para asegurar que el mensaje es transmitido
sin modificaciones. El mecanismo de integridad est diseado para soportar
mltiples firmas por diferentes actores y se puede extender para soportar nuevos

mecanismo de firma. Integrando XMLSignature, segn lo establecido por la

especificacin WS-Security se minimiza la repercusin de estos ataques.
Ataques a la confidencialidad
Centrados en la captacin de la informacin contenida dentro de los mensajes. En
ocasiones puede existir informacin muy sensible (datos mdicos, datos
econmicos, etc...)
Hombre en el medio o man- in-the-middle.
Es la infiltracin por parte de un atacante entre los participantes de una
comunicacin. Normalmente, intercepta la comunicacin y suplanta a los
participantes de manera que estos creen que se comunican entre si cuando lo
hacen
con
el
atacante.
La posibilidad de un ataque de intermediario sigue siendo un problema potencial
de seguridad serio, incluso para muchos sistemas criptogrficos basados en clave
pblica. Existen varios tipos de defensa contra estos ataques que emplean
tcnicas de autenticacin basadas en:
Claves pblicas
Autenticacin mutua fuerte
Claves secretas (secretos con alta entropa)
Passwords (secretos con baja entropa)
Otros criterios, como el reconocimiento de voz u otras caractersticas biomtricas
La integridad de las claves pblicas debe asegurarse de alguna manera, pero
stas no exigen ser secretas, mientras que los passwords y las claves de secreto
compartido tienen el requerimiento adicional de la confidencialidad. Las claves
pblicas pueden ser verificadas por una autoridad de certificacin (CA), cuya clave
pblica sea distribuida a travs de un canal seguro (por ejemplo, integrada en el
navegador
web
o
en
la
instalacin
del
sistema
operativo).
Suplantacin de identidad (Spoofing)
Es un ataque orientado a los niveles de confianza que se establecen en la
comunicacin. El atacante suplanta la identidad de uno de los participantes en una
relacin de confianza, usualmente trata de comprometer al destinatario de la
comunicacin. Es muy til utilizar una robusta autenticacin para fortalecer el
servicio
ante
estos
ataques.
Para evitar ataques de spoofing exitosos contra nuestros sistemas podemos tomar
diferentes medidas preventivas; en primer lugar, parece evidente que una gran
ayuda es reforzar la secuencia de prediccin de nmeros de secuencia TCP. Otra
medida sencilla es eliminar las relaciones de confianza basadas en la direccin IP

o el nombre de las mquinas, sustituyndolas por relaciones basadas en claves

criptogrficas; el cifrado y el filtrado de las conexiones que pueden aceptar
nuestras mquinas tambin son unas medidas de seguridad importantes de cara a
evitar
el
spoofing.
Denegacin de servicio
El objetivo es mantener un servicio activo para que los usuarios legtimos puedan
acceder a l. Los ataques se centran en destruir la disponibilidad de un servicio.
Su objetivo es interrumpir las operaciones de un servicio dejndolo desconectado.
Es necesario adaptar la configuracin del servidor a las necesidades de
autenticacin, seguir recomendaciones con respecto al tamao de mensajes
aceptadas, controlar la distribucin de mensajes para minimizar este tipo de
ataques.
Ataque de repeticin
En este caso un atacante es capaz de interceptar un mensaje vlido pudiendo
reenviarlo ms tarde todas las veces que quiera al servicio para el que era
destinatario. Para poder solventar este problema se deben utilizar tcnicas de
autenticacin apropiadas conjuntamente con tcnicas de sellado de tiempos y
nmeros de secuencia.

Interoperabilidad
La interoperabilidad entre los servicio web de ASP.NET y los servicio web de
Windows Communication Foundation (WCF) se puede lograr asegurando que los
servicios implementados usen ambas tecnologas de acuerdo con la
especificacin WS-I Basic Profile 1.1. Los servicio web de ASP.NET que cumplen
con WS-I Basic Profile 1.1 son interoperables con clientes de WCF mediante el
uso de enlace proporcionado por el sistema de WCF, BasicHttpBinding.
Utilice la opcin de ASP.NET 2.0 de agregar los atributos WebService y
WebMethodAttribute a una interfaz en lugar de a una clase y escribir una clase
para implementar la interfaz, como se muestra en el siguiente cdigo de ejemplo.

[WebService]
public interface IEcho
{
[WebMethod]
string Echo(string input);
}
public class Service : IEcho
{
public string Echo(string input)
{
return input;
}
}
El uso de esta opcin es preferible, porque la interfaz con el atributo WebService
constituye un contrato para las operaciones realizadas por el servicio, que puede
reutilizarse con diferentes clases que podran implementar ese mismo contrato de
distintas maneras.
Evite usar el atributo SoapDocumentServiceAttribute para que los mensajes se
enruten a mtodos en funcin del nombre completo del elemento de cuerpo del
mensaje SOAP en lugar del encabezado HTTP SOAPAction.WCF usa el
encabezado HTTP SOAPAction para enrutar mensajes.
El XML en el que XmlSerializer serializa de forma predeterminada un tipo es
semnticamente idntico al XML en el que DataContractSerializer serializa un tipo,
dando por hecho que el espacio de nombres para el XML se define
explcitamente.Cuando defina un tipo de datos para su uso con los servicios web
de ASP.NETy en previsin de que se adoptar WCF, haga lo siguiente:
Defina el tipo mediante las clases de .NET Framework en lugar de mediante el
Esquema XML.
Agregue solo SerializableAttribute y XmlRootAttribute a la clase, utilizando el
ltimo para definir explcitamente el espacio de nombres del tipo.No agregue
atributos adicionales del espacio de nombres System.Xml.Serialization para
controlar cmo se traducir la clase de .NET Framework a XML.
Mediante el uso de este enfoque, debera ser capaz de convertir ms adelante las
clases .NET en contratos de datos agregando DataContractAttribute y
DataMemberAttribute sin modificar significativamente el XML en el que las clases
se serializan para la transmisin.Los tipos utilizados en los mensajes por los

servicios web de ASP.NET se pueden procesar como contratos de datos a travs

de aplicaciones WCF, lo que produce, entre otras ventajas, un mejor rendimiento
en las aplicaciones WCF.
Evite usar las opciones de autenticacin proporcionadas por Internet Information
Services (IIS).Los clientes de WCF no las admiten.Si es necesario proteger un
servicio, utilice las opciones proporcionadas por WCF, porque estas opciones son
robustas y se basan en protocolos estndar.

Repercusin en el rendimiento de la carga de ServiceModel HttpModule

En .NET Framework 3.0, se instal el HttpModule de WCF en el archivo raz

Web.config, de modo que cada aplicacin ASP.NET sea compatible con WCF. Esto
puede afectar al rendimiento, por lo que es posible quitar ServiceModel del archivo
Web.config, como se muestra en el siguiente ejemplo.

<httpModules>
<remove name=ServiceModel />
<httpModules/>