Acerca de los servicios web RESTful

Los servicios web son una implementación de tecnología web utilizada para la
comunicación de máquina a máquina. Como tal, se utilizan para la
comunicación de aplicaciones Inter, Web 2.0 y Mashups y para aplicaciones
de escritorio y móviles para llamar a un servidor.

Los servicios web RESTful (a menudo llamados simplemente REST) son una
variante ligera de los servicios web basados en el patrón de diseño
RESTful. En la práctica, los servicios web RESTful utilizan solicitudes HTTP
que son similares a las llamadas HTTP normales en contraste con otras
tecnologías de servicios web como SOAP, que utiliza un protocolo complejo.

Propiedades relevantes clave de los

servicios web RESTful
 El uso de HTTP métodos ( GET, POST, PUTy DELETE) como el verbo primario para
la operación solicitada.
 Especificaciones de parámetros no estándar:
o Como parte de la URL.
o En cabeceras.
 Parámetros estructurados y respuestas usando JSON o XML en valores de
parámetros, cuerpo de solicitud o cuerpo de respuesta. Esos son necesarios para
comunicar información útil de la máquina.
 Autenticación personalizada y gestión de sesiones, a menudo utilizando tokens
de seguridad personalizados: esto es necesario ya que la comunicación de
máquina a máquina no permite secuencias de inicio de sesión.
 Falta de documentación formal. Sun Microsystems presentó una norma
propuesta para describir los servicios web RESTful llamada WADL, pero nunca
fue adaptada oficialmente.

El desafío de las pruebas de

seguridad de los servicios web
RESTful
 La inspección de la aplicación no revela la superficie de ataque, es decir, las URL
y la estructura de parámetros utilizados por el servicio web RESTful. Los motivos
son:
o Ninguna aplicación utiliza todas las funciones y parámetros disponibles
expuestos por el servicio.
o Los utilizados a menudo se activan dinámicamente por el código del lado del
cliente y no como enlaces en las páginas.
o La aplicación cliente a menudo no es una aplicación web y no permite la
inspección del enlace de activación o incluso el código relevante.
 Los parámetros son ninguna norma por lo que es difícil determinar lo que es sólo
una parte de la dirección URL o una cabecera constante y lo que es un parámetro
de valor de la formación de pelusa .
 Como interfaz de máquina, el número de parámetros utilizados puede ser muy
grande, por ejemplo, una estructura JSON puede incluir docenas de
parámetros. el difuminar cada uno alarga significativamente el tiempo requerido
para la prueba.
 Los mecanismos de autenticación personalizados requieren ingeniería inversa y
hacen que las herramientas populares no sean útiles, ya que no pueden rastrear
una sesión de inicio de sesión.

¿Cómo pentest un servicio web

RESTful?
Determine la superficie de ataque a través de la documentación: las pruebas
de rotulación RESTful podrían ser mejores si se permite algún nivel de prueba
de caja blanca y puede obtener información sobre el servicio.

Esta información asegurará una cobertura más completa de la superficie de

ataque. Dicha información a buscar:

 Descripción formal del servicio: si bien para otros tipos de servicios web, como
SOAP, una descripción formal, generalmente en WSDL, a menudo está
disponible, rara vez es el caso de REST. Dicho esto, WSDL 2.0 o WADL pueden
describir REST y a veces se usan.
 Una guía para desarrolladores para usar el servicio puede ser menos detallada,
pero se encontrará comúnmente e incluso podría considerarse una caja negra .
 Fuente o configuración de la aplicación: en muchos marcos, incluido dotNet, la
definición del servicio REST puede obtenerse fácilmente de los archivos de
configuración en lugar del código.

Recopile solicitudes completas utilizando un proxy : aunque siempre es un

paso importante para la prueba del lápiz, esto es más importante para las
aplicaciones basadas en REST, ya que la interfaz de usuario de la aplicación
puede no dar pistas sobre la superficie de ataque real.

Tenga en cuenta que el proxy debe poder recopilar solicitudes completas y no

solo URL, ya que los servicios REST utilizan más que solo parámetros GET.

Analice las solicitudes recopiladas para determinar la superficie de ataque:

 Busque parámetros no estándar:

o Busque encabezados HTTP anormales, que muchas veces serían
parámetros basados en encabezados.
o Determine si un segmento de URL tiene un patrón repetitivo en las
URL. Dichos patrones pueden incluir una fecha, un número o una ID como
cadena e indicar que el segmento de URL es un parámetro incrustado de
URL.
 Por ejemplo: http://server/srv/2013-10-21/use.php
o Busque valores de parámetros estructurados, que pueden ser JSON, XML o
una estructura no estándar.
o Si el último elemento de una URL no tiene una extensión, puede ser un
parámetro. Esto es especialmente cierto si la tecnología de la aplicación
normalmente usa extensiones o si un segmento anterior tiene una extensión.
 Por ejemplo: http://server/svc/Grid.asmx/GetRelatedListItems
 o Busque segmentos de URL altamente variables: un solo segmento de URL
que tiene muchos valores puede ser parámetro y no un directorio físico.
 Por ejemplo, si la URL se http://server/src/XXXX/pagerepite con cientos de
valores para XXXX, la posibilidad XXXXes un parámetro.

Verifique los parámetros no estándar: en algunos casos (pero no en todos),

establecer el valor de un segmento de URL sospechoso de ser un parámetro
en un valor que se espera que no sea válido puede ayudar a determinar si se
trata de elementos de ruta de un parámetro. Si se trata de un elemento de ruta,
el servidor web devolverá un mensaje 404, mientras que para un valor no
válido a un parámetro, la respuesta sería un mensaje a nivel de aplicación, ya
que el valor es legal en el nivel del servidor web.

Análisis de las solicitudes recopiladas para optimizar el difuminado : después

de identificar los parámetros potenciales para difuminar, analice los valores
recopilados para cada uno para determinar:

 Valores válidos frente a no válidos, de modo que el difuminado puede centrarse

en valores inválidos marginales
o Por ejemplo, el envío de 0 para un valor encontrado para ser siempre un
entero positivo.
 Secuencias que permiten difuminar más allá del rango presumiblemente
asignado al usuario actual.

Por último, al difuminar , no olvides emular el mecanismo de autenticación

utilizado.