Una introducción a REST Web Services.

Los Web Services (WS) son una implementación de las tecnologías web, utilizadas para la comunicación entre máquinas. En éste caso, nos vamos a centrar en uno de ellos, los servicios RESTful (muchas de las veces lo llaman solo REST). Son una variante de WS mucho más ligeras y en la práctica éstos realizan peticiones HTTP similares a las llamadas HTTP regulares.

Propiedades importantes de los WS REST

  • Uso de métodos HTTP (GET, POST, PUT y DELETE)
  • No existe un estandar que especifique los parámetros que envía. Éstos pueden enviarse desde:
    • La URL, como parte de ella.
    • En las cabeceras
  • Los parámetros y las respuestas se estructuran en formato JSON o XML.
  • Posee un manejo de autenciación y sesión customizado, donde usualmente se utilizan tokens de seguridad: esto es necesario ya que no maneja cookies de sesión.
  • No existe información formal sobre éste mismo, aunque se han propuesto algunos documentos que nunca fueron adaptados oficialmente: Proposed standard for describing RESTful web services called WADL.

El reto de testear la seguridad de los WS REST

  • Inspeccionar la aplicación, no revela la superficie de ataque, por ejemplo, las URLs y la estructura de los parámetros usados por REST. Las razones son:
    • Ninguna aplicación utiliza todas las funcionalidades y parámetros que expone el servicio.
    • Muchas de ellas, son activadas de forma dinámica del lado del cliente y no como links de las páginas.
    • El cliente de la aplicación algunas veces no es una aplicación web y no permite inspección de elementos o del mismo código fuente.
  • Los parámetros no son estándares, haciéndo díficil determinar si son parte de la URl o una cabecera e incluso si vale la pena fuzzearlo.
  • La cantidad de párametros que suelen utilizarse, por ejemplo en estructuras JSON, incluyen decenas de parámetros. Fuzzear cada uno y aplicar una lógica requiere de mucho tiempo.
  • Los mecanismos de autenticación requieren de conocimiento en reversing, haciendo dificil el uso de herramientas automatizadas (ya que no pueden trackear la secuencia de login)

Entonces, ¿cómo realizar un pentest a un WS REST?

Primero, es importante determinar la superficie de ataque a través de la documentación de implementación – para éstos casos es recomendable un pentest del tipo white-box, para así conocer información específica del servicio. Éste tipo de análisis asegurará una mayor cobertura de la superficie de ataque. A continuación, se detallan algunos puntos a tener en cuenta:

  • Descripción formal del servicio – Mientras otros tipos de WS como SOAP poseen una descripción formal, para el caso de REST a menudo existen. Dicho esto, WSDL 2.0 o WADL pueden describir al WS REST.
  • Una guía de desarrollo para el uso del servicio es menos detallada pero suele ser encontrada, incluso cuando se realiza un análisis del tipo black-box.
  • Análisis del código fuente de la aplicación o la configuración – en muchos frameworks, por ejemplo .NET, la definición del WS puede ser fácilmente obtenida desde los archivos de configuración.

NOTA: Recolectar peticiones completas utilizando un proxy es siempre un punto importante en los pentests, pero en éstos casos en particular influye mucho ya que los WS REST hacen mucho más que consultas solo por GET. Todo lo que se haya recolectado, determina distintos puntos de la superficie de ataque:

  • Prestar atención a parámetros no-estándares:
    • Por ejemplo, cabeceras HTTP anormales – muchas veces se basan en parámetros interesantes y fuzzeables.
    • Determinar si los segmentos de la URL tiene un patrón repetitivo. Éstos patrones pueden incorporar una fecha, un número o un ID como string que indica que la URL tiene parámetros embebidos. Por ejemplo: http://server/srv/2017-10-21/use.php
    • Buscar por parámetros estructurados – los cuales pueden ser JSON, XML o alguna estructura no-estándar.
    • Si el último elemento de la URL no tiene extensión, es posible que sea un parámetros. Esto “cobra sentido” cuando la tecnología de la aplicación utiliza en otras pantallas extensiones o si el método anterior la utilizó. Por ejemplo: http://server/svc/Grid.aspx/GetRelatedItems
    • Buscar por segmentos de la URL que varíen con frecuencia – un segmento en particular de la URL que “posee” muchos valores puede ser un parámetro y no un directorio físico. Por ejemplo, si la URL http://server/src/XXXX/page utiliza varios valores diferentes para XXXX, hay muchas probabilidades en que XXXX sea un parámetro.

Analizar las peticiones recolectadas para optimizar el fuzzing – luego de identificar potenciales parámetros a fuzzear, los valores devueltos deben ser analizados para determinar:

  • Valores válidos vs inválidos, para disminuir los falsos positivos y pérdidas de tiempo.
  • Extender la superficie de conocimiento del usuario para también agrandar la superficie de ataque.
  • Recordar que siempre que se esté fuzzeando, emular de forma correcta el mecanismo de autenticación que se utiliza.

Fuente: OWASP

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s