Las APIs Rest son componentes habituales en las aplicaciones web modernas y en las infraestructuras basadas en microservicios, se caracterizan por su simplicidad gracias al uso del protocolo HTTP, algo que sin duda representa una ventaja considerable frente a los servicios web tradicionales basados en SOAP. Como ocurre con cualquier aplicación web, si se desea realizar pruebas de pentesting lo primero que se debe hacer es entender para qué se ha diseñado, el “protocolo” que se debe cumplir para invocar a cada endpoint y las restricciones definidas a la hora de acceder a información. No hay que olvidar que al basarse en protocolo HTTP, pueden ser consultadas utilizando cualquier cliente compatible, desde un navegador web hasta una herramienta orientada a este tipo de aplicaciones como PostMan. En cualquier caso, aplican las mismas reglas que se siguen cuando se prueba una aplicación web estándar, aunque hay algunas diferencias y cuestiones que no son tan comunes en las aplicaciones web y precisamente por ese motivo, ha surgido el proyecto OWASP API Security Project. Se trata de un proyecto de la comunidad OWASP reciente (data del 2019) y es muy similar al proyecto OWASP Top 10 ya que define los 10 defectos más peligrosos para la seguridad de este tipo de componentes.
En este post te explicaré en que consiste cada uno de los elementos de la guía, sin embargo recuerda que en la plataforma de THW tienes una formación completa sobre Hacking en APIs Rest en el que se explora en detalle y con un enfoque 100% práctico cómo realizar pruebas de pentesting contra estos componentes tan comunes en infraestructuras web.

Este tipo de vulnerabilidades no son nuevas y de hecho, se encuentran presentes en el OWASP Top 10 desde hace ya varios años adoptando diferentes nombres, probablemente el más conocido y extendido es IDOR (Insecure Direct Object Reference). Se trata de un tipo de vulnerabilidad muy habitual en APIs Rest debido a la falta de validaciones a la hora de acceder a información partiendo de parámetros enviados por el usuario. Normalmente este tipo de problemas generan fugas de información sensible y acceso no autorizado a recursos protegidos. Como en cualquier aplicación web, su solución parte de la buena definición de roles y perfiles, declarando exactamente a qué recursos puede acceder cada usuario autenticado y no autenticado, así como la forma en la que debe  hacerlo.

En la posición 2 se encuentra una de las vulnerabilidades más comunes en aplicaciones web, se trata de mecanismos de autenticación inseguros o poco efectivos. En esta categoría es común encontrarse con mecanismos de autenticación débiles basados en información del usuario, algoritmos criptograficos rotos u obsoletos, tokens de autenticación y/o cookies de sesión predecibles, entre otras cosas. En las APIs Rest es especialmente habitual el uso de tokens JWT y tecnologías similares, las cuales en ocasiones son difíciles de securizar, algo que se suele analizar en detalle cuando se ejecuta un pentest web.

Es posible que la API exponga endpoints que revelan demasiada información sobre los usuarios o el sistema, algo que un atacante puede utilizar para perfilar la aplicación y buscar el mejor vector de ataque. En esta categoría se encuentra la información que se puede extraer de cabeceras HTTP, tokens JWT, información en las estructuras JSON de las respuestas, entre otras cosas.

Es muy común encontrar APIs Rest que no establecen mecanismos de control sobre el número de peticiones que puede realizar un usuario y el tiempo que debe existir entre cada una de ellas. Esta situación en ocasiones pueden afectar el rendimiento general de la aplicación o dar lugar a condiciones de denegación del servicio.

Es una vulnerabilidad muy similar a la API1:2019 pero con la diferencia de que en este caso el atacante cuenta con un nivel de acceso o autorización determinado en la aplicación. Ocurre cuando no se definen y/o implementan adecuadamente las reglas que gobiernan el acceso a recursos. La solución consiste en declarar una matriz de roles y permisos con las reglas que debe seguir la API Rest para impedir que un usuario sin el rol adecuado o con privilegios insuficientes pueda acceder a recursos que no están asignados a su nivel de acceso.

Ocurre cuando en las peticiones HTTP se envía una estructura JSON que corresponde fielmente con el modelo/objeto en el lado del servidor y en dicha petición, es posible especificar atributos que posteriormente y sin ningún tipo de validación por parte del servidor, se asignan a un objeto en el backend. Esto es un problema cuando se utilizan librerías de parseo de estructuras JSON y dicha estructura se convierte a un objeto en el servidor con todos y cada uno de los valores que vengan en la petición. Se trata de una vulnerabilidad muy concreta en APIs Rest y que en ocasiones es difícil de detectar ya que el atacante debe conocer el modelo de datos que hay en el servidor y esto no siempre está a su alcance. Para ello, el atacante puede leer la documentación disponible o analizar cada endpoint y sus respuestas para descubrir cómo se encuentra definido el modelo de datos en el lado del servidor.

Otra de las vulnerabilidades que también se encuentra descrita en el OWASP Top 10, en este caso se refiere principalmente a problemas que se pueden presentar en configuraciones por defecto en los frameworks y librerías utilizados para crear la infraestructura Rest, así como otros problemas relacionados con cabeceras mal configuradas, métodos HTTP que se encuentran habilitados y son innecesarios, una política CORS demasiado permisiva, etc.

Se trata de las vulnerabilidades de inyección clásicas que se encuentran descritas en todas las versiones del OWASP Top 10.  En este caso está prácticamente en la última posición debido a su bajo nivel de incidencia en las aplicaciones modernas.

Una API Rest normalmente suele exponer más puntos de acceso que una aplicación web tradicional, por ese motivo la gestión adecuada de cada uno de esos activos es vital. Este tipo de problema se produce precisamente cuando se pierde el control “de lo que hay”, de los endpoints que se encuentran expuestos en entornos de desarrollo, staging o producción. Cuando se crean demasiados endpoints que luego no se van a utilizar porque eran para hacer pruebas y exponen vulnerabilidades que puede explotar un atacante. Aunque está en prácticamente la última posición, es un problema que puede ser critico en una API Rest, especialmente en la medida en la que va evolucionando y su tamaño aumenta.

Finalmente, este punto hace referencia al mismo problema descrito en el OWASP Top 10, el cual en su versión del 2017 también ocupa esta misma posición. Se refiere a la falta de mecanismos de monitorización o la ausencia de un control y seguimiento de los eventos reportados por dichos mecanismos, haciendo que un ataque activo se lleve a cabo sin ser detectado.

Como se puede ver, el enfoque es diferente al empleado en las aplicaciones web tradicionales, por ese motivo merece la pena aprender a llevar a cabo estas pruebas de la forma más completa y profesional posible ya que si eres pentester web es algo que tarde o temprano tendrás que hacer (o casi seguro ya haces con frecuencia).

Un saludo y Happy Hack!
Adastra.