Aunque cada vez más en desuso, todavía podemos encontrar bastantes
servicios web desarrollados en .
NET utilizando
ASMX, y curioseando en nuestra plataforma
Tacyt en búsqueda de posibles servicios web expuestos que implementen esta tecnología uno puede descubrir un buen número de aplicaciones que hacen uso de ellos, tal y como se puede ver en la
Figura 2.
|
Figura 1: Exposición insegura de servicios web .NET en apps Android |
Una de las curiosidades de este tipo de servicios es que, dependiendo de la versión utilizada de
.NET y de la configuración establecida en el fichero
web.config bajo el elemento
<WebServices>, se puede proveer cómodamente una forma de testear un
webservice a través de un simple botón.
|
Figura 2: Aplicaciones Android en Tacyt con links que apuntan a webservices |
Para conseguir esta ejecución, basta con pulsar el botón Invoke, tal y como se puede ver en la Figura 3. Esta facilidad de botón gordo (habilitada por defecto sólo para pruebas locales en sus últimas versiones) no supone un riesgo mayor que la exposición de un servicio que no disponga de las medidas de seguridad adecuadas, ya que si encontramos dicho botón deshabilitado podremos suscribirnos al servicio igualmente e invocar a los servicios web a través de un cliente.
|
Figura 3: Botón de Invoke para ejecutar un webservice |
Sin embargo esta facilidad puede llegar a suponer un riesgo doble al facilitar un posible abuso por parte de un usuario malintencionado que esté inspeccionando, por ejemplo, aplicaciones
Android. La siguiente imagen muestra cómo en los enlaces de una
app se puede llegar a localizar información de
webservices fácilmente.
|
Figura 4: enlaces de una app de Android con links a webservices |
Entre los ejemplos de servicios web expuestos que me han llamado la atención por su
falta de seguridad destacaría por ejemplo el siguiente listado de información de usuarios basado en un
ID que se le puede facilitar e incluso por el que se podría iterar para obtener un
volcado de cuentas de correo y passwords (en este caso pasadas por una función
hash):
|
Figura 5: Un Webservice descubierto en una app de Android que devuelve los datos de las cuentas |
Curiosamente bajo ese mismo servicio web existe otro método web que sin solicitar ningún tipo de credenciales de forma adicional permiten el
borrado dado un ID… ¿peligroso verdad?:
|
Figura 6: Webservice para borrar una cuenta de usuario |
Otro ejemplo interesante lo he encontrado en un
conocido juego de billar que nos permitirá listar todas las partidas en curso que están realizando los jugadores:
|
Figura 7: Webservice para acceder a los datos de las partidas |
Y por el mismo precio, eliminarlas:
|
Figura 8: Webservice para eliminar todas las partidas del juego |
Podemos llegar incluso a encontrar servicios que, por el mero hecho de ser invocados, provoquen errores devolviendo información como nombres de bases de datos, tablas, columnas, relaciones…
|
Figura 9: Leaks de información conseguidos a través de un webservice inseguro |
O como explicábamos en un principio, servicios que no disponen de ese botón gordo
Invoke…
|
Figura 10: Webservices sin botón "Invoke" |
… pero que igualmente nos permitirán realizar una suscripción al servicio:
|
Figura 11: Invocación del webservice. Se puede hacer también con SoapUI. |
Reflexiones finales
Finalmente y sacando algunas conclusiones sobre estas líneas:
- Todo servicio expuesto debe implementar los mecanismos de seguridad que le apliquen según su criticidad y funcionalidad. Cifrado, autenticación y autorización son nuestros aliados cuando tenemos información sensible, contenido al que sólo se puede acceder si se es reconocido como un usuario válido del sistema o cuando necesitamos una granularidad fina como para que un determinado método web sólo lo ejecute un usuario concreto.
- Recordar que cualquier código entregado al cliente (como lo es una app Android) es susceptible de ser analizado de forma estática y dinámica, de modo que cualquier servicio externo finalmente quedará expuesto.
- Y esto último ya más como un apunte curioso, es interesante ver como aunque Microsoft recomienda utilizar WCF frente a ASMX, si buscamos las apps publicadas desde hace 3 meses encontraremos bastantes más servicios ASMX:
|
Figura 12: Los WebServices con ASM siguen siendo más usados que en WCF |
Autor: Miguel Ángel García (@nodoraiz)
Software Engineer en Eleven Paths
Aunque cada vez más en desuso, todavía podemos encontrar bastantes servicios web desarrollados en .NET utilizando ASMX
ResponderEliminarMe confunde esa afirmación: ¿Lo que está cada vez más en desuso son los servicios web o su implementación en ASMX?
Hola Anónimo,
ResponderEliminarComo imaginas por la duda que planteas, los servicios web son un básico y hoy día prácticamente cualquier app se soporta sobre ellos de una u otra forma.
Me refería a su implementación en ASMX, este tipo de servicio web ha evolucionado a WCF, e incluso se dispone de otras alternativas como Web Api.
Un saludo!
Conozco que es un ws, he implementado unos cuantos.
ResponderEliminarMe había sorprendido la afirmación porque hoy cada día se usan más.
La solucion es filtrar la llamada al servicio.
ResponderEliminarY no comprendi como lo has llamado!