Articulo TSI3 - 2014

Efrain Arreche Andres Vera

efrados@gmail.com aveuy90@gmail.com

INTRODUCCION

Los web services son una herramienta muy utilizada
ya que permiten integrar sistemas distintos de
manera sencilla. Esto se debe a que se definen
patrones y protocolos de comunicacin, que sirven
en diferentes plataformas y lenguajes de
programacin. Estos tpicamente funcionan bajo el
conocido protocolo HTTP y extensiones del mismo,
por ende presentan problemas de seguridad
similares.

DESCRIPCIN DEL PROBLEMA

A continuacin se enumeran y describen
brevemente algunos de los problemas de seguridad.
Autenticacin de los participantes. Un
servicio web podra solicitar al demandante
credenciales junto a una demostracin de
que es el propietario de las mismas. Resulta
necesario conseguir una estandarizacin de
los protocolos y en los formatos a utilizar.
Autorizacin. Es necesario definir los usua-
rios que pueden realizar diversas acciones
sobre los diferentes recursos. En combina-
cin con la autenticacin, permite a las iden-
tidades conocidas realizar las acciones para
las que tienen permisos.
Confidencialidad. Es muy habitual emplear
tcnicas de cifrado. Obviamente, la confi-
dencialidad 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 exacta-
mente la misma que se envi desde el clien-
te.
No repudio. En una comunicacin que se
realizan transacciones, es necesario regis-
trar que las mismas se han producido y re-
gistrar el autor que lo ejecut. En el caso de
los servicios Web, trasladamos esta poltica
la uso del servicio.
Disponibilidad. Uno de los ataques ms
frecuentes a las aplicaciones se basa en la
denegacin de servicios. Se lanzan mlti-
ples solicitudes falsas para inundar y saturar
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. Se registran las acciones en
los servicios Web para poder realizar un
anlisis posterior de los datos.

MARCO CONCEPTUAL

Protocolos de implementaciones
Seguridad Servicios REST:

OAuth2
OAuth2 es un protocolo de autorizacin que
permite a terceros (clientes) acceder a conteni-
dos propiedad de un usuario (alojados en apli-
caciones de confianza, servidor de recursos) sin
que stos tengan que manejar ni conocer las
credenciales del usuario. Es decir, aplicaciones
de terceros pueden acceder a contenidos pro-
piedad del usuario, pero estas aplicaciones no
conocen las credenciales de autenticacin.
Actores Involucrados:

Figura 1 - diagrama de los componentes que entran
en juego a la hora de utilizar el protocolo
Propietario de recursos: Es una entidad
capaz de dar acceso a recursos protegidos.
Cliente: Es la aplicacin que hace
peticiones a recursos protegidos en nombre
de un propietario de recursos con la
autorizacin del mismo.
Servidor de recursos: Es la entidad que
tiene los recursos protegidos. Es capaz de
aceptar y responder peticiones usando un
access token que debe venir en el cuerpo
de la peticin.
Servidor de autorizacin: En muchos casos el
servidor de autenticacin es el mismo que el
Servidor de Recursos. En el caso de que se
separen, el servidor de autenticacin es el
responsable de generar tokens de acceso y
validar usuarios y credenciales.

Funcionamiento:

Figura 2 - diagrama de autorizacin y autenticacin de un
servicio.
Implementaciones:

Una de las implementaciones posibles para el pro-
tocolo es OAuth for Spring Security del conocido
framework Spring. Es implementado en el contexto
de Spring Security, subcomponente de spring en-
cargado de protocolos de seguridad para el lengua-
je Java.







Protocolos de implementaciones
Seguridad Servicios SOAP:
WS-Security
Ws-Security Permite que un mensaje SOAP pueda
identificar la persona que llama, firmar el mensaje, y
cifrar el contenido del mensaje. Por lo tanto
proporciona: autenticacin, confidencialidad e
integridad a los Servicios Web.
En lugar de definir un estndar desde cero, resuelve
el problema de la autenticacin mediante el uso
de Kerberos y certificados X.509, se cifra con el
XML Encryption y se firma con la
XML Signature tras preparar los datos mediante el
XML
Funcionamiento:


Figura 3 - diagrama de flujo de mensajes con web security
[4]
WS-Security Addendum
Despus de la evaluacin de WS -Security por un
poco de tiempo, una serie de tems se debieron
agregar tanto para la seguridad como para los
servicios web en general. Un ejemplo de ellos no
son especficos de la seguridad: wsu : Id y wsu :
timestamp. El Addendum especifica exactamente lo
que estos dos elementos hacen y cmo deben ser
utilizados.
Los eventos de inters en la vida de un mensaje son
el momento de su creacin, el momento en que el
emisor quiere que el mensaje de expiracin, y el
momento en que se recibi el mensaje. Al conocer
el tiempo de creacin y expiracin, un receptor
puede decidir si los datos son lo suficientemente
actuales como para su uso y de no ser actuales
deben ser desechados. Los elementos que
transmiten estos datos son:
wsu : Created , wsu : Expired y wsu :Received.

Implementaciones:
El proyecto Apache WSS4J proporciona una
implementacin en Java de las normas de
seguridad para servicios Web, a saber las
especificaciones OASIS Web Services Security
(WS-Security). WSS4J proporciona una
implementacin de los variados estndares de WS-
Security.
T-Check[6]

T-Check es un mtodo dependiente del contexto
utilizado para evaluar tecnologas. En una primer
instancia se formula un conjunto de hiptesis que
debe cumplir la tecnologa, que luego se evaluarn
a la luz de un conjunto de criterios de evaluacin.
Una vez que se formulan los criterios, se procede a
desarrollar e implementar las pruebas sobre esta
tecnologa, que dar como resultado la confirmacin
(total o parcial) o rechazo de determinada hiptesis.

TECNOLOGAS ELEGIDAS

1. Axis2 y Rampart
La plataforma Axis2[9] se basa en java es un
proyecto Open Source de Apache. Es en esencia,
un motor o contenedor de servicios web, es sus
diferentes protocolos (REST, SOAP, etc).
Bsicamente se compone de un archivo war
deployable en un servidor de aplicaciones (Tomcat,
Jetty, etc). Una vez iniciada la aplicacin nos
permite mediante una interfaz web, deployar
servicios empaquetados segn una cierta estructura
predefinida. Lo que ms se destaca en dicha
estructura, es el archivo services.xml que define
las caractersticas del servicio, y por otro lado el
archivo .class que define la implementacin del
mismo.
La plataforma Axis2, es complementada por el
mdulo de seguridad Rampart [10], este es el
mdulo que implementa los mecanismos de
seguridad para servicios web sobre el protocolo
SOAP. En particular implementa el estndar WS-
Security. Para activarlo para se debe de configurar
el archivo services.xml y definir las configuraciones
correspondientes.

2. WCF
Windows Communication Foundation (WCF) es una
plataforma de mensajera, que es principalmente
utilizada en aplicaciones orientadas a servicios.
Forma parte de la API de la Plataforma .NET,
desarrollado por la empresa Microsoft.
Para definir un servicio en WCF se debe definir al
menos un Endpoint. El Endpoint maneja no solo la
ubicacin del servicio sino que tambin provee
acceso a la metadata del mismo. Parte de la
informacin del Endopint se da en el Binding que
define protocolos, codificacin y tipo de transporte
(TCP o HTTP).
Luego los Behaviors proveen informacin importante
tanto del cliente como del servicio ya que afecta
como se maneja la autorizacin
WCF proporciona un entorno rico y configurable
para la creacin de polticas de seguridad y el
establecimiento de comportamientos para poder
controlar las funciones de seguridad.

HIPTESIS

Hiptesis 1: La plataforma es amigable al
usuario desarrollador

Criterio 1: Se puede descargar, instalar y poder
instalar un ejemplo de WS en menos de 10 horas

Rampart
No Aprobado. Se logr realizar en 14 horas (3,5
horas en 4 das).
WCF
Aprobado. Se pudo descargar e instalar en poco
menos de 3 horas. Luego se prob un ejemplo de
un web service sin seguridad asociada en menos de
10 horas.

Criterio 2: Cuenta con documentacin y guas de
uso rpido las cuales permiten utilizar
funcionalidades bsicas en menos de 1 hora.
Rampart
No Aprobado. Si bien existe documentacin para
algunos ejemplos con las funcionalidades bsicas,
estos no estn actualizados para las versiones
actuales del producto. Esto genera, que ante
problemas en la ejecucin de los ejemplos, no haya
documentacin o guas para poder recurrir.
En cuanto a las pruebas realizadas, la ejecucin de
un ejemplo llev aproximadamente 3 horas.
WCF
No Aprobado. Tiene una documentacin muy
extensa lo cual permite entender a fondo cmo
funciona la herramienta. Los ejemplos encontrados
en la pgina oficial de Microsoft [13] resultaron muy
tiles para probar las diversas funcionalidades de la
herramienta pero para poder ejecutarlos hay que
seguir determinados pasos [14] que llevaron
aproximadamente 2 horas.

Criterio 3: Cuenta con una comunidad activa en
la cual el tiempo mximo entre posts nuevos es
de 2 das.
Rampart
No Aprobado. La mayora de los posts que pueden
encontrarse en la web sobre los usuarios, son
antiguos y de versiones muy viejas.
WCF
No Aprobado. Haciendo diversas bsquedas en
foros de la herramienta, los post ms recientes
encontrados tenan al menos un ao de antigedad.

Criterio 4: Existen ejemplos claros y fcilmente
reproducibles.
Rampart
No Aprobado. Existen ejemplos, pero no se
encontr un proyecto completo, por esto se necesito
recopilar informacin de diversos ejemplos para
poder generar un caso funcional.
WCF
Aprobado. Como se mencion anteriormente
existen ejemplos de Microsoft y los mismos fueron
utilizados para probar diversos criterios. Al ser
ejemplos que incluyen el cdigo y el proyecto en su
totalidad, pudieron reproducirse en relativamente
poco tiempo.

Resultado
No se aprueba la hiptesis para Rampart, ya que no
se cumpli ningn criterio. Por otro lado para WCF
se cumple parcialmente la hiptesis.

Hiptesis 2: La plataforma permite solicitar
autenticacin al momento de invocar al WS

Criterio 1: Permite la autenticacin enviando los
datos en texto plano.
Rampart
Aprobado. Para esta prueba se implement un
servicio se saludo. Del lado del cliente se invoca con
usuario y contrasea. En el services.xml del
servicio se define una policy y se configura la clase
que chequea los datos del lado del servidor. Esta
realiza el chequeo, en caso de ser incorrecto lanza
una excepcin al cliente.
WCF
Aprobado. No se puede realizar de manera nativa,
lo cual es lgico ya que usar texto plano no es
generalmente recomendado en cuestiones de
seguridad. Sin embargo a veces es requerido (como
en F5 BIG-IP) [16]. Mediante un ejemplo encontrado
en la web [16] se logr probar que es posible
implementar un sistema de seguridad personalizado
permitiendo autenticar enviando datos en texto
plano.

Criterio 2: Permite la autenticacin mediante un
mtodo seguro (encriptacin).
Rampart
Aprobado. Se implement un servicio de suma con
clave asimtrica. Se utilizaron 2 keystore: client.jks
con la clave privada del cliente y service.jks con el
certificado de la clave pblica del cliente.
WCF
Aprobado. Mediante el uso de Token SAML[15]
para autenticar, se logro una autenticacin con
encriptacin asimtrica mediante el uso de clave
pblica y privada.

Criterio 3: Permite la autenticacin del servidor
frente al cliente (a la inversa de los criterios
anteriores).
Rampart
Aprobado. Se utiliz el mismo ejemplo que el
criterio 2. Las keystores utilizadas fueron las
mismas. En primer lugar client.jks con clave
privada de cliente y certificados para clave pblica
del servidor y service.jks con clave privada del
servicio y certificados de la clave pblica del cliente.
De esta manera se obtiene la mutua autenticacin,
aplicando el procedimiento del criterio 2 para el
request y el response del mensaje.
WCF
Aprobado. Siguiendo indicaciones [4] se logr
comprobar que Windows Communication
Foundation utiliza WS-Security con certificacion
mutua mediante certificados X-509. Lo que
significa que permite la autenticacin del cliente y
del servidor (inversa).








Criterio 4: Permite la autenticacin mediante el
uso de tokens
Rampart
Aprobado. Para la veracidad de dicho criterio se
toma en cuenta, que la firma del mensaje tiene
implcito el token encriptado de la propia firma.
WCF
Aprobado. Se utiliza el ejemplo descrito en el
criterio 2, que provee encriptacin y se probo una
autenticacin con tokens pero sin encriptacin.

Resultado
Se aprueba la hiptesis para ambas tecnologas ya
que todos los criterios fueron aprobados.

Hiptesis 3: La plataforma soporta
encriptacin

Criterio 1: Soporta la encriptacin de los datos a
enviar
Rampart
Aprobado. Se utilizo el ejemplo de la hiptesis 2,
con claves pblico-privada. Se agreg
adicionalmente en el archivo services.xml que no
slo se firme el mensaje, sino que baje el par de
claves configuradas se encripte el cuerpo del
mensaje.
WCF
Aprobado. Se utilizo el ejemplo de Microsoft [17]
con el certificado X.509, el cual se utiliza para
encriptar el mensaje.

Criterio 2: Soporta la encriptacin del cabezal del
mensaje
Rampart
Aprobado Parcialmente. Siguiendo con el ejemplo
mencionado anteriormente, simplemente se agreg
en la configuracin de encriptar el cabezal del
mensaje adems del cuerpo en la seccin del
services.xml que define que partes se encriptan.
Cabe destacar que es posible solamente encriptar
partes del cabezal.
WCF
No Aprobado. La encriptacin del cabezal del
mensaje no es posible en su totalidad en WCF. Lo
que se puede hacer es codificar la totalidad del
cabezal pero aunque no es legible directamente,
fcilmente se puede decodificar porque la
codificacin no est pensada como herramienta de
seguridad

Criterio 3: Soporta ms de un algoritmo de
encriptacin
Rampart
Aprobado. Se utiliz el ejemplo descrito en el
anterior criterio, cambiando el algoritmo utilizado
para la encriptacin. Para la prueba se utilizaron los
algoritmos Basic y TripleDesRsa.
WCF
Aprobado. Se puede utilizar encriptacin TripleDES,
AES,etc. Tambin puede utilizarse encriptacin
totalmente personalizable.

Resultado
Aunque no se cumplan enteramente los criterios, se
da por aprobada la hiptesis ya que se aprobaron
los criterios que se consideraron ms importantes.

Hiptesis 4: Web Service seguro Criterios
avanzados

Criterio 1: Confidencialidad: solo la persona a la
cual es dirigido un mensaje puede leerlo
Aprobado. Si se encripta un mensaje con la clave
pblica solo se podr desencriptar con la clave
privada, que como solo la persona a la cual es
dirigido el mensaje tiene, cumple con la
confidencialidad del mensaje.
Tanto Rampart como WCF cumplen este criterio por
soportar encriptacin asimtrica.

Criterio 2: No repudio: se puede verificar el
origen del mensaje
Aprobado. Si se encripta un mensaje con la clave
privada el mensaje se puede desencriptar con la
clave pblica pero el hecho de que el mensaje
desencriptado sea vlido implica que en el origen
del mensaje tena acceso a la clave privada por lo
que se puede tomar esto como una verificacin del
origen del mensaje
Tanto Rampart como WCF cumplen este criterio por
soportar encriptacin asimtrica.

Criterio 3: No se modifica la integridad de los
datos
Aprobado.[] Si se encripta un mensaje con la clave
privada, aunque se pudiera interceptar el mensaje y
se modificara la integridad de los datos de alguna
manera no podra encriptarlo de vuelta como para
hacerlo pasar por el mismo mensaje por lo que si un
mensaje llega y es vlido el contenido podemos
asegurar que la integridad de los datos no se vi
modificada.
Tanto Rampart como WCF cumplen este criterio por
soportar encriptacin asimtrica.

Resultado
Se investigaron maneras de poder explotar alguna
vulnerabilidad de los mtodos de firma x.509 pero
no hay demasiada informacin al respecto. Se
aprueba la hiptesis dado que tericamente todos
los criterios fueron aprobados para ambas
tecnologas.

Hiptesis 5: Es interoperable entre distintas
plataformas de programacin
Criterio 3: Un servicio implementado en el
lenguaje JAVA puede ser consumido por una
aplicacin implementada en .NET
Inconcluso. Se intento hacer la integracin
mediante un ejemplo encontrado en la web, el
mismo inclua proyectos enteros y certificados a
instalar; por los comentarios de los usuarios
funcionaba.
Luego de varias horas de intentos y pruebas se
desisti del intento, quizs por diferentes versiones
de software del ejemplo encontrado o algn otro
problema que no se logro encontrar por falta de
tiempo.

Resultado
En teora es posible realizar la integracin, pero hay
muy poca informacin al respecto y por falta de
tiempo no se pudo dedicar ms tiempo a poder
terminar al menos un criterio.

Hiptesis 6: Ante un agregado de
dispositivo de seguridad, la performance no
se ve afectada de gran manera
No pudo llegar a ser probado por falta de tiempo

Hiptesis 7: El uso de protocolos no afecta
el rendimiento del servidor ni del cliente
No pudo llegar a ser probado por falta de tiempo



Hiptesis 8: La plataforma utiliza WSREST
over SSL y brinda mecanismos para la
confidencialidad de datos
No pudo llegar a ser probado por falta de tiempo

Hiptesis 9: La plataforma utiliza WSREST
over SSL y brinda mecanismos para las
integridad de datos No pudo llegar a ser probado
por falta de tiempo

Hiptesis 10: La plataforma provee
mecanismos de administracin y
configuracin
Criterio 1: Se brinda una interfaz para realizar
configuraciones y administrar los servicios
Rampart
Aprobado. Axis 2, brinda una interfaz web donde
cargar los empaquetados de los servicios que se
quieren deployar, as como los mdulos que se
quieren utilizar (Rampart, etc). Cabe destacar que
no es posible desde esta herramienta, cambiar
parmetros de seguridad del servicio, como ser
partes que se firman o encriptan, keystores, etc.
WCF
No Aprobado. No se provee una interfaz para
realizar la configuracin de los servicios ya que
estos solo pueden ser dados por los archivos de
configuracin o por cdigo.

Criterio 2: Se pueden realizar configuracin
utilizando un archivo .config
Rampart
No Aprobado. Las configuraciones que se deban
realizar, deben hacerse sobre cdigo java o
archivos xml.
WCF
Aprobado. Como fue mencionado anteriormente se
puede configurar tanto el servicio como el cliente
por archivo de configuracin.
Resultado
Para Rampart se aprueba la hiptesis pero cabe
destacar que es muy bsica la interfaz brindada.
Para WCF en cambio se aprueba parcialmente la
hiptesis ya que solo soporta configurarse por
archivos de configuracin y no provee mecanismos
de administracin.


PROBLEMAS ENCONTRADOS

A continuacin se describen y enumeran algunos de
los problemas encontrados en el correr del proyecto.

Gran curva de aprendizaje tanto en seguridad
en general como en las distintas herramientas
Falta de documentacin sobre el funcionamiento
de las tecnologas
Ejemplos antiguos y desactualizados.
Poco conocimiento previo acerca de
funcionamiento de claves.
Incompatibilidad de versiones.
Poca participacin de compaeros en el foro de
EVA.

La mayor dificultad general para poder satisfacer las
hiptesis fue entender el funcionamiento de las
claves pblicas y privadas y los certificados sobre
las mismas as como su funcionamiento para el
firmado o encriptado de mensajes SOAP.

Por otro lado, el hecho de tener pocos ejemplos, y
ser mayoritariamente antiguos (al menos mas de 2
aos), de versiones no actuales y desactualizados,
dificult la tarea de poderlos hacer funcionar. Para
poder sortear este problema por ejemplo en
Rampart nos vimos obligados a basarnos en varios
ejemplos encontrados en la web [7] [8] [11], y
combinndolos entre s se logro hacer funcionar un
caso.
Cabe destacar que fue muy til el intercambio
realizado con los compaeros que optaron por
utilizar el foro del EVA [12].

CONCLUSIONES Y TRABAJO A FUTURO

Tanto para .NET como para Java existen posibles
implementaciones de WS-Security que cumplen
algunas de las funcionalidades bsicas como
autenticacin, encriptado, no repudio, etc. Las
principales funcionalidades han podido ser
corroboradas casi en su totalidad. Pese a esto
destacamos la poca informacin encontrada sobre
todo por el lado de Apache Rampart y Axis2.

Por otro lado, WS-Security intenta ser un estndar
de seguridad para el protocolo SOAP pero a la hora
de integrar mismo a la hora de integrarnos entre los
distintos lenguajes y frameworks que fueron
utilizados en el proyecto, en particular WCF y
Rampart.

Como trabajo futuro se plantea trabajar en la
hiptesis, que por falta de tiempo del proyecto no se
han podido intentar probar, y las cuales no se tiene
certeza de que puedan cumplirse o no. Adems,
para aquellas hiptesis que no se han probado
prcticamente pero si de manera terica, queda
pendiente la prueba, para comprobar efectivamente
que esa teora es correcta en la prctica.

REFERENCIAS

[1] Problemas de seguridad en la web
http://www.juntadeandalucia.es/servicios/madeja/contenido/recu
rso/211#La_Seguridad_en_la_Arquitectura_de_Referencia_de_l
os_Servicios_We ltima visita: 11/04/14
[2] WS- Security
http://blogs.salleurl.edu/networking-and-internet-
technologies/ws-security-wss/ ltima visita: 11/04/14
[3] ACM Proceedings Templates
http://www.acm.org/chapters/policy/toolkit/template.html
ltima visita: 11/04/14
[4] Ws-security
http://msdn.microsoft.com/en-us/library/ms977327.aspx
ltima visita: 11/04/14
[5] WSS4J
https://ws.apache.org/wss4j/ ltima visita: 11/04/14
[6] TCheck
http://www.fing.edu.uy/inco/cursos/tsi/TSI4/2013/T-Check.pdf
[7] Ejemplo Apache Rampart 1
http://crishantha.com/wp/?p=667TCheck ltima visita 28/6/14
[8] Ejemplo Apache Rampart 2
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina
=wss_usertoken ltima visita 28/6/14
[9] Apache Rampart Page
http://axis.apache.org/axis2/java/rampart/
ltima visita 21/6/14
[10] Apache Axis2 Page
http://axis.apache.org/axis2/java/core/
ltima visita 21/6/14
[11] Ejemplo Apache Rampart 3
http://wso2.com/library/3415/
[12] EVA Fing / TSI3
https://eva.fing.edu.uy/mod/forum/view.php?id=37079
[13] Ejemplos de Extension en seguridad de
Microsoft para WCF http://msdn.microsoft.com/en-
us/library/ee960142(v=vs.110).aspx
[14] Procedimiento para poder ejecutar los ejemplos
de la pgina de Microsoft http://msdn.microsoft.com/en-
us/library/ms751527(v=vs.110).aspx
[15] Token Saml
http://msdn.microsoft.com/en-
us/library/aa355062(v=vs.110).aspx
[16] Mutua Autenticacin
http://msdn.microsoft.com/en-
us/library/ms733102(v=vs.110).aspx
[17] Integridad de los datos
http://www.oracle.com/technetwork/issue-archive/2005/05-
mar/o25web-092925.html


ANEXO

En este anexo pueden encontrarse algunas capturas y archivos de configuracin utilizados para las distintas
tecnologas a modo de ilustrar un poco lo explicado de las diferentes hiptesis.

Axis2/Rampart:





















Figura 1: descriptor services.xml para Axis2 (Sin seguridad)


Figura 2: descriptor services.xml para Axis2, con configuracin para autenticar con texto plano



Figura 3: request con autenticacin en texto plano




Figura 4: configuracin agregada en services.xml para el encriptado y firmado con claves


Figura 5: secciones de services.xml donde se configura encriptacin y firmado


Figura 6: secciones de services.xml donde se configura el algoritmo de encriptacin