API REST desde 0

Carol12Gory - Oasis
6 min readJul 2, 2023

--

1. ¿Qué es una API?

Una API (Application Programming Interface) es un conjunto de métodos y funciones donde sus respuestas generalmente se devuelven como JSON, XML entre otros. Las APIs pueden usar cualquier tipo de protocolo de comunicación basado en HTTP y no están limitadas de la misma manera que lo es un webservice.

De forma muy breve, un webservice o servicio web es una tecnología que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Por ejemplo, el lenguaje de programación Java puede interactuar con PHP mediante el uso de servicios web. En otras palabras, el servicio web proporciona una manera de lograr la interoperabilidad y la independencia de la plataforma.

La diferencia entre una web y una API, principalmente, es que una web procesa los datos en el lado del servidor y los resultados los manda a los navegadores para que estos sean renderizados (suele estar protegida por un WAF (Web Application Firewall)) y, en cambio, una API se encarga del intercambio de información de los servidores backend para proporcionar las funciones de la aplicación. Para hacer uso de una API no es necesario un entorno gráfico y su securización es ad-hoc para cada API.

Por otro lado, existen las API web que es una forma de comunicación entre dos aplicaciones o servicios que se encuentran en la web. Una aplicación le envía una solicitud a otra aplicación que tiene una API web, y esta le devuelve una respuesta con los datos o la función que le solicitó. Por ejemplo, si se quiere saber el tiempo en una ciudad, se puede usar una aplicación que le envíe una solicitud a la API web del instituto de meteorología y le muestre la información que reciba.

2. Tipos de APIs según su funcionalidad

- REST

REST es una forma simple de organizar interacciones entre sistemas independientes. Permite interactuar con una sobrecarga mínima con clientes como teléfonos móviles y otros sitios web. En teoría, REST no está vinculado a la web, pero casi siempre se implementa como tal y se inspiró en HTTP. Para que una API sea REST debe cumplir unos requisitos:

  • No guardar el estado entre peticiones.
  • Uso correcto de las URIs (Uniform Resource (Identifler)): Las URIs nos permiten identificar de forma única el recurso que queremos modificar, obtener o borrar.
  • Uso correcto de HTTP, indicando el tipo de acción que queremos realizar con el recurso:

> GET: Para consultar y leer recursos

> POST: Para crear recursos

> PUT: Para editar recursos

> DELETE: Para eliminar recursos

> PATCH: Para editar partes concretas de un recurso.

  • Hypermedia: es conectar mediante vínculos las aplicaciones clientes con las APIs, permitiendo a dichos clientes despreocuparse por conocer de antemano de cómo acceder a los recursos. Es decir, cuando devolvemos por ejemplo una lista de usuarios indicaríamos la URL para acceder a cada uno de ellos.

- XML-RPC

XML-RPC (Remote Procedure Call) es un protocolo de llamada a procedimiento remoto que usa XML para codificar los datos y HTTP como protocolo de transmisión de mensajes. Es un protocolo muy simple ya que solo define unos cuantos tipos de datos y comandos útiles, además de una descripción completa de corta extensión. En RPC, sólo usa GET y POST: GET para obtener información y POST para todo lo demás.

- SOAP

SOAP (Simple Object Access Protocol) es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. Tipo de API definida con lo que nos tenemos que basar en lo que está estandarizado.

- GraphQL

GraphQL es un lenguaje de consulta de código abierto desarrollado originalmente por Facebook que puede utilizarse para construir APIs como alternativa a REST y SOAP. Ha ganado popularidad desde su creación en 2012 debido a la flexibilidad nativa que ofrece a quienes construyen y llaman a la API.

3. TOP 10 2019 vs TOP 10 2023

A principios de junio del 2023 se ha liberado el nuevo TOP 10 de API actualizado, tras 4 años desde la anterior versión. El uso de APIs, en todas sus modalidades, ha tenido un aumento de su uso a un nivel exponencial dando así lugar a nuevas vulnerabilidades que han sido explotadas por atacantes comprometiendo este tipo de tecnología.

Muchas de las vulnerabilidades han experimentado un cambio de nombre o incluso la fusión de varias como puede ser API3:2019 - Excessive Data Exposure y API6:2019 - Mass Assignment focalizándolas en la causa raíz de ambas: fallos a la hora de realizar una validación de la autorización a nivel de propiedad de objeto API2:2023 - Broken Authentication. También parecen nuevas vulnerabilidades como son API6:2023 - Unrestricted Access to Sensitive Business Flows y API10:2023 - Unsafe Consumption of APIs.

A continuación, se muestra una tabla comparativa del TOP 10 de 2019 y el TOP 10 de 2023 y se hace un resumen-comparativo entre ambos TOP 10:

TOP 10 - API 2019 vs TOP 10 - API 2023

API1:2023 - Broken Object Level Authorization

Este punto es el mismo que el API1:2019 - Broken Object Level Authorization, pero con un nombre más específico. Se refiere a la falta o a la validación incorrecta de la autorización a nivel de objeto, lo que permite a los atacantes acceder o modificar recursos que no les pertenecen.

API2:2023 - Broken Authentication

Este punto es el mismo que el API2:2019 - Broken User Authentication, pero con un nombre más genérico. Se refiere a las fallas en los mecanismos de autenticación que permiten a los atacantes comprometer los tokens de autenticación o asumir la identidad de otros usuarios, realizando una suplantación de identidad.

API3:2023 - Broken Object Property Level Authorization

Este punto combina el API3:2019 - Excessive Data Exposure y el API6:2019 - Mass Assignment, centrándose en la causa raíz: la falta o la validación incorrecta de la autorización a nivel de propiedad del objeto. Esto conduce a la exposición o manipulación de información por parte de terceros no autorizados.

API4:2023 - Unrestricted Resource Consumption

Este punto es una actualización de API4:2019 - Lack of Resources & Rate Limiting que refleja el cambio en el panorama de amenazas de las API y aborda nuevos vectores de ataque que han surgido desde la última versión publicada en 2019. La principal diferencia es que API4:2023 amplía el alcance de la vulnerabilidad para incluir no solo los recursos de la API, sino también los recursos del sistema que soporta la API y los recursos de los proveedores de servicios integrados con la API. Además, API4:2023 introduce el concepto de límite de gasto para los proveedores de servicios externos, que puede ser una fuente de pérdida financiera si se abusa de la API.

API5:2023 - Broken Function Level Authorization

Se mantiene el mismo nombre que en 2019. Se refiere a las fallas en el control de acceso a nivel de función (fallos de autorización), lo que permite a los atacantes acceder a funciones administrativas que no deberían estar disponibles para ellos. Al explotar estos problemas, los atacantes pueden acceder a los recursos de otros usuarios y/o a las funciones administrativas.

API6:2023 - Unrestricted Access to Sensitive Business Flows

Este punto es nuevo en el TOP 10 de 2023 y se refiere al abuso de las funcionalidades expuestas por la API que pueden dañar al negocio si se usan excesivamente de forma automatizada, como conseguir descuentos, ganar premios, manipular votaciones o generar spam.

API7:2023 - Server-Side Request Forgery

Este punto hace referencia a API5:2019 - Broken Function Level Authorization, pero con un nombre más genérico. Se refiere a las peticiones maliciosas que una API puede enviar a recursos internos o externos sin validar el URI suministrado por el usuario, lo que puede provocar un acceso no autorizado o una denegación de servicio incluso cuando está protegida por un firewall o una VPN.

API8:2023 - Security Misconfiguration

Este punto es el mismo que el API7:2019 - Security Misconfiguration. Se refiere a las configuraciones inseguras de la API y los componentes relacionados, como los servidores web, las bases de datos, los frameworks o las librerías, que pueden ser explotadas por los atacantes para comprometer la seguridad de la API.

API9:2023 - Improper Inventory Management

Este punto es el mismo que el API9:2019 - Improper Assets Management, pero con un nombre más genérico. Se refiere a la falta o la actualización incorrecta del inventario y la documentación de la API, lo que puede provocar la exposición de endpoints desconocidos, obsoletos o no documentados que pueden ser explotados por los atacantes.

API10:2023 - Unsafe Consumption of APIs

Este punto es el mismo que el API10:2019 - Insufficient Logging & Monitoring, pero con un nombre más específico. Se refiere a la falta o la implementación incorrecta del registro y la monitorización de las peticiones y respuestas de la API, lo que dificulta la detección y el análisis de los incidentes de seguridad. También se refiere al riesgo de filtrar datos sensibles o confidenciales a través de los registros que no debería almacenarse o exponerse.

5. Referencias

En futuras publicaciones se explicará cada uno de los puntos del TOP 10 en detalle y se pondrá en práctica todo lo aprendido en diferentes ejercicios relacionados con API REST.

¡Nos vemos en el próximo! 😊

--

--

Carol12Gory - Oasis

Offensive Security Engineer en Telefónica Tech. Co-autora del libro Social Hunters: Hacking con ingeniería social en el Red Team. carol12gory.com | @Carol12Gory