Un Web Service es una aplicación que reside en un servidor centralizado y que utiliza una serie de protocolos estándares controlados por las organizaciones W3C, OASIS y el organismo WS-I como, por ejemplo, Simple Object Access Protocol (SOAP), Web Service Definition Language (WSDL) y Universal Description Discovery and Integration (UDDI), para intercambiar datos e información entre otras aplicaciones, independientemente del lenguaje de programación en el que estén desarrolladas y de la plataforma dónde se ejecuten.
W3C (World Wide Web Consortium) y OASIS (Organization for the Advancement of Structured Information Standards) son los comités responsables de la arquitectura y reglamentación de los Web Services y WS-I es el organismo creado para mejorar la interacción y operatividad entre diferentes implementaciones de Web Services.
Un Web Service dispone de un interfaz público (API) descrito en un formato procesable por cualquier equipo o sistema llamado WSDL. WSDL es, además, el lenguaje de programación de ese interfaz público que está basado en XML y contiene los requisitos funcionales necesarios para establecer una comunicación con el Web Service.
Un equipo cliente que se conecta a un Web Service puede leer ese fichero WSDL para determinar qué funciones están disponibles en el servidor. Los tipos de datos especiales se incluyen dentro del archivo WSDL en forma de XML Schema y el cliente utiliza SOAP para hacer la llamada a una de las funciones listadas en el WSDL.
SOAP es el protocolo que define cómo se establece el intercambio de información mediante XML, y UDDI es el protocolo empleado para publicar la información del Web Service y que permite comprobar qué Web Services están disponibles.
Los Web Services se utilizan normalmente bajo el protocolo HTTP o HTTPS en los puertos TCP 80 y 443, respectivamente, ya que los firewalls y sistemas de seguridad perimetral que protegen las redes cierran la totalidad de los puertos TCP a excepción de dichos puertos de navegación Web tal y como se puede observar en el siguiente gráfico:
Fig 1. Esquema de un Web Service estándar
Un usuario necesita convertir una cantidad de euros a dólares. Se conecta a la página Web que proporciona este servicio para hacer la conversión (paso 1), la página contiene un sencillo formulario donde poder seleccionar la moneda de partida, en este caso, euros. El usuario envía estos datos y el servidor donde reside la página Web, y que hace de frontal Web, envía una solicitud UDDI para buscar el servicio requerido que pueda realizar dicha conversión de euros a dólares. El proveedor UDDI asocia los datos enviados con el servicio solicitado y su ubicación, dentro del servidor de aplicaciones, y devuelve al usuario un fichero WSDL (paso 2) con toda la información del Web Service. Dicha información se completa con un mensaje SOAP. Una vez que el usuario tiene todos los datos, envía al servidor de aplicaciones donde reside el Web Service el mensaje SOAP con la información necesaria para ejecutar la conversión de euros a dólares (paso 3), el servidor de aplicaciones ejecuta el Web Service según los parámetros que se le pasaron y facilita el resultado de la conversión solicitada (paso 4).
Desde el punto de vista de la seguridad, un Web Service presenta los mismos problemas que cualquier otra aplicación Web presente y accesible por Internet: robo de sesiones, SQL Injection, XML Injection, XPATH Injection, Denegación de Servicio (DoS), Cross Site Scripting (XSS), errores de configuración, etc. Los archivos XML que conforman la estructura de los ficheros WSDL y mensajes SOAP que se utilizan en el funcionamiento de un Web Service se intercambian entre el equipo cliente del usuario y el servidor frontal Web y el servidor de aplicaciones en forma de formularios en una petición SOAP. Incluso se ejecutan en el servidor Web y son una puerta de entrada para diferentes ataques y vulnerabilidades Web. Es importante destacar que casi todos los Web Services están conectados a bases de datos.
Enumeración WSDL
La primera fase en cualquier ataque web es el descubrimiento y la identificación (fingerprinting) de la tecnología y programas utilizados. La información recopilada en esta primera etapa es fundamental para encontrar posibles puntos de entrada. El archivo WSDL es una descripción muy completa del Web Service que no sólo detalla la funcionalidad del mismo, sino también su ubicación, su forma de autenticación y, en general, cómo se anuncia al resto de Internet.
El método de entrada de un Web Service (autenticación) requiere de un nombre de usuario y una contraseña de entrada, por lo que suele ser habitual emplear ataques de fuerza bruta e, incluso, de inyección SQL. Otra forma común es revisar la etiqueta "service" dentro del archivo WSDL público que informa de la ubicación del Web Service directamente y sin pasar por la validación.
Es normal que el fichero WSDL esté accesible públicamente para permitir su uso con otras aplicaciones a modo de frontend, para descubrirlo basta añadir la entrada ?WSDL o .WSDL (dependiendo de la plataforma utilizada) al final de la dirección Web:
http://www.hacktimes.com:8080/Services/Gestor?wsdlLa estructura de cualquier fichero WSDL como mínimo siempre recoge las etiguetas o tags "type" que define el tipo de datos usado por el Web Service, "message" para el tipo de mensajes, "portType" que incluye el tipo de mensajes que definen una comunicación, "binding" para ver cómo está implementado el Web Service con SOAP y "service" que como se veía anteriormente, que indica la localización del Web Service.
El servidor UDDI proporciona un repositorio centralizado para los Web Services y sus archivos WSDL. Es bastante común que se publique información sensible acerca del Web Service en servidores UDDI que pueden ser fácilmente descubiertos por un posible atacante.
Para evitar facilitar información detallada acerca del Web Service es recomendable utilizar el fichero robots.txt para que ningún buscador indexe dónde se encuentran los ficheros WSDL. También es importante no publicar los archivos WSDL en el servidor UDDI o, incluso, bloquear el acceso mediante las funciones de control de acceso integradas en las versiones 3.0.2 o superiores de UDDI. Además, es preciso desactivar la documentación del contenedor WSDL de la siguiente forma, en función de si se trata de un Web Service montado con .NET o con J2EE:
- .NET: eliminar el siguiente apartado del archivo web.config
<WebServices>
<protocols>
<remove name="Documentation"/></protocols></webServices>
- J2EE borrar la siguiente línea del archivo de propiedades de la aplicación:
(wsdl.location=/WEB-INF/
Manejo de errores
Como siempre los mensajes de error que proporciona cualquier aplicación, revelan demasiada información sensible sobre el estado y el funcionamiento de la misma. Por ejemplo, el siguiente mensaje es la respuesta que se produce al introducir una comilla simple (la prueba más común para detectar una vulnerabilidad de Inyección SQL) en la entrada del campo password durante la autenticación:
XMLns:soapenv=http://schemas.XMLsoap.org/soap/envelope/>
soapenv:Server.userException
java.sql.SQLException : you have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near "'" at line
1
etc. Un Web Service tiende a revelar más información sensible que una aplicación Web regular ya que, carecen de una gestión de errores correctamente configurada. Es necesario asegurarse que de cualquier excepción proporcione un mensaje de error genérico dentro de la respuesta SOAP.
Además, muchos motores SOAP pueden ser configurados para eliminar los detalles incluidos en cualquier petición Web que resulte incorrecta, así, por ejemplo, con Web Services basados en AXIS (basado en Apache Tomcat) es preciso modificar el parámetro "axis.development.system" dentro del fichero server-config.wsdl para indicar un valor "false".
XPath Injection
Xpath es el lenguaje usado para consultar ciertas partes de un documento XML. Se puede comparar con el lenguaje SQL utilizado para consultar bases de datos. XPath, como SQL, es susceptible a una inyección que puede provocar la ejecución arbitraria de consultas en el servidor porque, como el lenguaje SQL, utiliza demilitadores para separar el código y la información, es decir, la comilla simple "'".
Una consulta XPath se crea de forma dinámica en combinación con los datos introducidos por el usuario por lo que puede ser modificada de alguna manera que el desarrollador no tenía prevista. A modo de ejemplo, la siguiente consulta XPath es usada dentro del método de autenticación de un Web Service, los valores en negrita son introducidos por el usuario:
http://www.hacktimes.com:8080/Services/Gestor/users/userid[123]Un usuario malintencionado puede intentar eludir la autenticación modificando la consulta XPATH para devolver todos los usuarios existentes en la base de datos que, en este caso, son mayores de edad:
http://www.hacktimes.com:8080/Services/Gestor/users/userid[./age > 18]
http://www.hacktimes.com:8080/Services/Gestor/users/userid[name=‘hacktimes’ or 1=1 or ‘’=‘’ and pass=‘hacktimes’]proporciona todo el listado de usuarios existentes en la base de datos a partir de un usuario con mismo login y password que existe (hacktimes).
Al igual que en un ataque de Inyección SQL o Cross Site Scripting (XSS), lo fundamental para evitar este tipos de ataque es validad los datos de entrada por parte del usuario.
Existen otro tipo de ataques como los de Denegación de Servicio (DoS) o los que se sirven de explotar XML Parsers (analizadores) y Validadores de XML pero son más difíciles de implementar y de llevar a cabo. Para más información acerca de los diferentes ataques existentes en un Web Service se puede recurrir a la siguiente dirección:
http://clawslab.nds.rub.de/wiki/index.php/Main_Page
Herramientas
Todos los analizadores de vulnerabilidades Web comerciales, es decir, Acunetix, Webinspect, Appscan, etc. ya incluyen un módulo específico para analizar Web Services. Además, existen otras herramientas que permiten revisar la seguridad de un Web Service como, por ejemplo:
- WS-Attacker que es una aplicación con licencia GNU que proporciona diversos plugins para revisar la configuración de un Web Service y que es bastante actual (enero de 2011). La dirección de descarga es http://ws-attacker.sourceforge.net
- WSfuzzer que es otra herramienta escrita en python también bastante actualizada (octubre de 2010 de la versión 1.9.5) que se engloba dentro de los proyectos OWASP. La dirección del proyecto donde encontrar más información es https://www.owasp.org/index.php/Category:OWASP_WSFuzzer_Project#Current_Version
- wsScanner es un conjunto de herramientas para explorar y detectar vulnerabilidades en Web Services. Permite buscar Web Services que se ejecuten en un dominio concreto o en un servidor determinado y enumerar vulnerabilidades. Únicamente soporta aquellos Web Services creados con .NET y puede encontrar vulnerabilidades del tipo inyección de SQL y LDAP, vulnerabilidades del tipo de datos, fuerza bruta contra SOAP, fuzzing para localizar diferentes Web Services y posibilidad de escanear los servidores UDDI. Más información en http://www.blueinfy.com/wsscanner.html.
Comentarios
Excelente aporte al medio y muy completo.
Edgar: gracias por tu comentario, son cosas como estas las que nos animan a seguir escribiendo y a compartir el conocimiento, un saludo.
Excelente este Articulo empiezo a realizar WS y algo fundamental en el inicio de cualquier tecnología es entender las vulnerabilidades de la misma. GRACIAS... SALUDOS
Muy interesante el artículo, la verdad es que cada vez más se ven Web Services desplegados por ahí y es fundamental conocer un poco los aspectos de seguridad que les afectan. A Seguir así!!!!
Añadir comentario