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