Banner 1

Mostrando entradas con la etiqueta web services. Mostrar todas las entradas
Mostrando entradas con la etiqueta web services. Mostrar todas las entradas

SoapUI: Auditar Seguridad Webservices (WSDL & WADL)

0 comentarios
SoapUI es una herramienta Open Source con soporte para Windows y Mac OS X pensada para testear el funcionamiento de WebServices. De manera sencilla carga todos los interfaces de los ficheros WSDL o WADL y permite que se puedan lanzar tests de funcionalidad, test de carga o test de seguridad automatizados para evaluar el comportamiento de los mismos. 
Desde el punto de vista de una auditoría de seguridad web, hace muy sencillo cargar el interfaz completo de un sitio y empezar a realizar las pruebas al uso, ya que con sólo crear un proyecto con el fichero de interfaz, ya tenemos todo lo listo para empezar a probar.
Figura 1: Creación de un proyecto con SoapUI
Por ejemplo, la Nasa tiene muchos de los ficheros de descripción de interfaz publicados en Google, y con crear un nuevo proyecto ya están listas todas las peticiones, para que solo sea necesario sustituir los valores marcados con un signo de interrogación.
Figura 2: Uno de los interfaces de la Nasa cargados con SoapUI
La herramienta permite muchas opciones, y hay un manual de buena calidad publicado en Español, que puedes utilizar para sacarle el máximo provecho, pero desde el punto de vista de un auditor, lo más cómodo es tener las peticiones, y enchufarlas a través de un proxy a tu herramienta de auditoría manual preferida, como Zap o Burp.
Figura 3: Opción de Proxy en SoapUI
Una vez grabadas las peticiones, ya podrás lanzar tus tests de hacking preferidos, o hacerles fuzzing, pero si lo prefieres, puedes hacer también los tests desde la propia herramienta, tal y como si lo hicieras directamente desde el propio navegador.
Figura 4: Testing manual desde SoapUI

Hay que tener en cuenta que los ficheros de interfaz de WebServices pueden dar acceso a procedimientos que no están en uso en las aplicaciones web, por lo que un proceso de crawling de la web no sacaría todos, por ello, lo mejor es cargar todos los interfaces y probarlos uno a uno.

Si quieres aprender a automatizar pruebas, José Vila en SecurityArtWork ha hecho un artículo genial sobre cómo hacerlo: Automatizando pruebas con SoapUI.

Fuente: SoapUI es una herramienta Open Source con soporte para Windows y Mac OS X pensada para testear el funcionamiento de WebServices. De manera sencilla carga todos los interfaces de los ficheros WSDL o WADL y permite que se puedan lanzar tests de funcionalidad, test de carga o test de seguridad automatizados para evaluar el comportamiento de los mismos. 
Desde el punto de vista de una auditoría de seguridad web, hace muy sencillo cargar el interfaz completo de un sitio y empezar a realizar las pruebas al uso, ya que con sólo crear un proyecto con el fichero de interfaz, ya tenemos todo lo listo para empezar a probar.
Figura 1: Creación de un proyecto con SoapUI
Por ejemplo, la Nasa tiene muchos de los ficheros de descripción de interfaz publicados en Google, y con crear un nuevo proyecto ya están listas todas las peticiones, para que solo sea necesario sustituir los valores marcados con un signo de interrogación.
Figura 2: Uno de los interfaces de la Nasa cargados con SoapUI
La herramienta permite muchas opciones, y hay un manual de buena calidad publicado en Español, que puedes utilizar para sacarle el máximo provecho, pero desde el punto de vista de un auditor, lo más cómodo es tener las peticiones, y enchufarlas a través de un proxy a tu herramienta de auditoría manual preferida, como Zap o Burp.
Figura 3: Opción de Proxy en SoapUI
Una vez grabadas las peticiones, ya podrás lanzar tus tests de hacking preferidos, o hacerles fuzzing, pero si lo prefieres, puedes hacer también los tests desde la propia herramienta, tal y como si lo hicieras directamente desde el propio navegador.
Figura 4: Testing manual desde SoapUI
Hay que tener en cuenta que los ficheros de interfaz de WebServices pueden dar acceso a procedimientos que no están en uso en las aplicaciones web, por lo que un proceso de crawling de la web no sacaría todos, por ello, lo mejor es cargar todos los interfaces y probarlos uno a uno.

Si quieres aprender a automatizar pruebas, José Vila en SecurityArtWork ha hecho un artículo genial sobre cómo hacerlo: Automatizando pruebas con SoapUI.

Pentesting a servicos web: WSDL

0 comentarios

¿Que es WSDL?

“Web Services Description Language” es un lenguaje empleado en páginas web para informar a los clientes que el servidor dispone de una aplicación indicándole en que consiste el servicio que ofrece, mostrando cual es su función y como puede un cliente interactuar con ella. Esto lo hace a través de un archivo XML en donde se describe todo lo anterior.

WSDL esta pensado para facilitar la vida al administrador pudiendo añadir de manera amena nuevos servicios.

El archivo XML contine una serie de etiquetas en donde se refleja la información:

types –> define los tipos de datos utilizados en los mensajes

message –> define los métodos y parametros utilizados por el servicio

porttipe –> define las operaciones permitidas

binding –> define los protocolos de transporte permitidos

services–> define las direcciones y los puertos ha emplear

 Un ejemplo para entenderlo mejor: http://tinyurl.com/knpx95z

Más información : http://di002.edv.uniovi.es/~falvarez/WSDL.pdf

¿Y esto a un pentester que le importa :-p?

La información que ofrece este archivo puede llegar a ser un tesoro. Con él se obtiene información sobre appwebs, su ubicación, como trabaja, puntos de entrada a la aplicación, posibles ataques de sql injection, ataques a paneles de autentificacion, ataques al parámetro SessionId,…

A parte de lo anterior es posible realizar otra serie de ataques por medio de WSDL:

  • Denegaciones de servicio: mediante aplicaciones de análisis basados en DOM

  • XPath injections

  • parsing attack

  • (xee) xml external entity

  • Spoofing

Auditando:

Para encontrar ficheros WSDL basta con hacer un poco de hacking con buscadores:

filetype:”wsdl”

indexof:”/wsdl”

inurl:wsdl

inurl:”?wsdl”

inurl:”.wsdl”

inurl:”.aspx?wsdl”

inurl:”.ascx?wsdl”

inurl:”.asmx?wsdl”

inurl:”.ashx?wsdl”

inurl:”.jws?wsdl”

inurl:”.svc?wsdl”

filetype:wsdl wsdl

…..Y las que se te vayan ocurriendo

Una de las herramientas para este fin que más me ha sorprendido es WS-ATTACKER, actualizada hace unos meses, incorpora una cantidad de plugins muy interesantes.

Basta con indicar la ruta de un wsdl, configurando los parámetros, seleccionar los plugins que convegan  y comenzar a testear

Web del proyecto: WS-Attacker


menu1menu2menu3

Fuente: http://dominiohacker.com/pentesting-a-servicos-web-wsdl-1880/

SoapUI

0 comentarios

SoapUI es una herramienta de Software Libre gráfica, está basada en Java y sirve para el testeo de Web Service y generación de Clientes De Web Service.
SoapUI permite testear web services de forma facil, ver los resultados. Además, permite facilitar el uso de herramientas comunes para la generación de clientes, como Axis.
Trabajando con web services, y sin interfase gráfica en la aplicación, esta herramienta nos permite automatizar fácilmente las pruebas funcionales y así asegurar la calidad en nuestros proyectos.
Las pruebas funcionales de los web services podrían usarse para más de un propósito:
  • Pruebas unitarias: para validar que cada operación de los servicios funciona como se definió.
  • Prueba de aceptación: para validar que el servicio retorna resultados aceptables según los requerimientos.
  • Pruebas de proceso: para validar que una sucesión de invocaciones del servicio cumple con el proceso de negocio definido.
  • Pruebas de manejo de datos: para validar el comportamiento con las entradas de datos externos al sistema (bases de datos, otros sistemas, uso de otros web services).
  • Pruebas de regresión: para validar el comportamiento post cambios.

Contenido

 [ocultar]

Un paso a paso

1. Tener instalada la última versión bajada de la Web oficial de SoapUI.
2. Crear un nuevo proyecto SoapUI para el proyecto a probar. Donde configurar la url que contiene el WSDL del proyecto.
Creacion de un proyecto
3. Por cada operacion del servicio a probar, crear una peticion. Cada peticion requiere el ingreso de valores para los parámetros definidos. Agregar valores en el XML que nos propone el wizard de la herramienta.
Agregar Peticion
Editar Parametros Peticion
4. El proyecto se persiste en un script XML, que podemos resguardar en el repositorio en el que tengamos el código fuente del proyecto. Y así todo el equipo podrá hacer crecer la prueba funcional automática del proyecto, y de un modo ágil.
5. Con los pasos dados hasta acá, logramos obtener una prueba funcional del proyecto y su documentación.
6. Esta herramienta maneja el concepto de TestSuite, TestCase, TestStep, como lo manejan JUnitJMeter, etc. Un TestSuite sirve para contener un número arbitrario de casos de prueba (TestCases) que pueden ejecutarse secuencialmente o en paralelo. Los TestSteps sirven para ejecutar TestCases secuencialmente. Una vez creadas las peticiones, es posible generar una TestSuite y así automatizar las pruebas funcionales, con el valor agregado de tener pruebas de regresión.
Agregar Peticion a un Caso de Prueba
7. Por cada TestCase es posible hacer validaciones automáticas de los resultados. Entonces, por cada petición, verificar si la respuesta es un fault, o no lo es, o contiene determinado valor, o no lo contiene. Es una buena práctica, en el manejo de web services, que los errores inesperado del sistema (Runtime Exception) viajen en un tag “fault”. Distinto a una respuesta normal del servicio.
Agregar una asercion a la respuesta de una peticion
Tipos de Aserciones
Agregar una asercion de contenido
8. Con las peticiones agregadas a los casos de prueba, se puede realizar una ejecución masiva utilizando la opción Launch TestRunner.
Configurar y Ejecutar Casos de Prueba
Mientras se ejecutan los casos de prueba, se pueden visualizar los pasos de ejecución y un resumen global. En el directorio físico configurado, se genera un archivo por cada caso de prueba con la nomenclatura conteniendo el TestSuite que lo ejecutó, el nombre del caso de prueba, y el resultado de la prueba.

Derechos reservados

Transferencia de datos entre peticiones

En un TestSuite podemos tener un TestCase con Steps, donde cada Step puede ser un request de una operación diferente del web service. Y el valor devuelto en un Step puede ser el valor de entrada en el próximo Step. Más en el tutorial de soapUI
Transferencia de datos entre peticiones

Conclusión

  • Es fácil y rápido crear, ejecutar y guardar los casos de prueba funcional que quieras. Se pueden adaptar y expandir en cualquier momento.
  • Es fácil hacer aserciones. También con expresiones regulares.

Algo más

  • Se puede agregar MockService cuando el web service todavía no está listo.
  • Load Tests permite medir performance sobre los tests funcionales creados.
  • Esta nota está basada en una guia y en un video de la página oficial de SoapUI.

Ver también

Powered by Bad Robot
Helped by Blackubay