Comprensión de las API: REST

 

Orquestación, automatización y respuesta de seguridad (SOAR) Las plataformas dependen en gran medida de las API (interfaces de programación de aplicaciones) para gestionar diversas herramientas de seguridad (productos) e invocar las respuestas deseadas en forma de acciones. Además de los productos SOAR, las API son comunes en casi todos los servicios, herramientas y productos utilizados por los técnicos.

Aunque las API son extremadamente comunes, es posible que no tengas experiencia usándolas o que ni siquiera sepas que un servicio tiene una al interactuar con él. Por ejemplo, Facebook usa un marco de API llamado API de gráficos.

“La API Graph es la forma principal que tienen las aplicaciones de leer y escribir en el gráfico social de Facebook”.”

Las API se presentan en diversas formas, pero independientemente del marco de API utilizado para un servicio, permiten a los profesionales técnicos interactuar con un sistema o servicio. Las API nos permiten desarrollar y conectar rápidamente un sistema con otro, ya sea estrictamente interno a una sola aplicación o a mayor escala, como Swimlane.

El uso de API ofrece a personas (y organizaciones) de todo el mundo una forma de compartir e interactuar con información de forma rápida, segura (si se implementan correctamente, por supuesto) y en un formato definido (descrito). Sin API, la automatización no existiría tal como es hoy.

En la primera parte de esta serie de dos partes, voy a proporcionar una descripción general de las API REST (Transferencia de estado representable), así como los puntos clave para ayudarlo a comenzar a comprender las API.

Autenticación

Las API REST suelen requerir algún mecanismo de autenticación para interactuar con ellas. Esto es habitual al interactuar con un producto o servicio de pago, pero no necesariamente con herramientas de inteligencia de código abierto (OSINT) u otros servicios gratuitos en internet.

Existen varios métodos de autenticación estándar y personalizados que utilizan las API. Es imposible enumerarlos todos, pero es común ver algunos de estos tipos de métodos de autenticación:

Tipo	Ejemplo	Descripción
Sin autenticación	Consultar la API de ThreatMiner y buscar el dominio google.com	Una API que no requiere que agregues ninguna información adicional al solicitar datos de una API
Nombre de usuario y contraseña	Consulta de la API local de Microsoft Exchange	Una API que requiere autenticación básica utilizando su nombre de usuario y contraseña
Simbólico	Consultar haveibeenpwned.com, lo que requiere que cree una cuenta gratuita y un token API.	Una API que requiere un token único para usar el servicio. Normalmente, este token debe proporcionarse en el encabezado de la solicitud.
Delegación	Uso de la API de Microsoft Graph, que requiere autenticación OAuth2	Una API que funciona junto con un servicio de autenticación que le proporciona tokens temporales para utilizar la API.

Estos son solo algunos ejemplos de los diferentes mecanismos de autenticación que puede utilizar un servicio. Dependiendo del producto y la empresa, pueden elegir un estándar como los mencionados anteriormente o usar uno propio.

El objetivo principal de estos mecanismos de autenticación es garantizar que usted tenga los derechos de acceso correctos para el servicio y también garantizar que se mantenga dentro de los límites de uso prescritos para el servicio.

Si está interesado en profundizar en la implementación de OAuth2 de Microsoft, consulte esta serie de tres partes que escribí que explica más sobre este mecanismo de autenticación específico: Parte 1, Parte 2, y Parte 3.

Versiones

De ahora en adelante, utilizaré un servicio ficticio llamado Servicio de inteligencia de amenazas de Josh y la URL para este servicio es: https://joshsthreatintel.example.

Puede visitar un sitio como este e interactuar con él como lo haría normalmente con cualquier otro sitio web, pero detrás contiene una API que le permite acceder a la información de forma programada para impulsar la automatización.

Una buena API contará con una documentación muy completa que describe los detalles sobre cómo autenticar y usar el servicio. Un estándar común es Pavonearse, pero no necesitamos entender qué es Swagger (es un estándar que permite un desarrollo más rápido de API y la estandarización en lo que respecta a su documentación).

En https://joshsthreatintel.example Nuestra API está versionada y se puede acceder a ella agregando /v1 A nuestra URL. Si accede a esta carpeta en nuestro sitio web, podría estar vacía, recibir una notificación indicando que no está autenticado o ser una página con la documentación de la API. En cualquier caso, accederá a la raíz de nuestra API mediante esta URL: https://joshsthreatintel.example/v1/.

Cada API que encuentre puede tener una o más versiones. Por ejemplo, havibeenpwned.com tiene tres:

1. https://haveibeenpwned.com/API/v1
2. https://haveibeenpwned.com/API/v3

Métodos

Las API basadas en REST están diseñadas para interactuar con métodos específicos definidos en su código fuente. Estos métodos responden de forma diferente según el tipo utilizado y los datos enviados a la API. Los métodos típicos que verá al interactuar con una API se enumeran en la siguiente tabla:

Método	Descripción del término	Descripción
CONSEGUIR	Recuperar o leer	Los métodos GET se utilizan para recuperar información de una API
CORREO	Crear o Agregar o Invocar	Los métodos POST se utilizan para crear o agregar datos, o para invocar una acción.
PONER	Parche o actualización	Los métodos PUT se utilizan para actualizar datos o modificarlos de alguna manera
BORRAR	Destruir o eliminar	Los métodos DELETE se utilizan para eliminar datos o detener una acción.

Los métodos más comunes que encontrará son GET y POST. Dependiendo del tipo de API (REST o SOAP) y del servicio, es posible que deba proporcionar información adicional en los encabezados de la solicitud al realizarla.

Normalmente, en una solicitud GET, se envía una solicitud http a un punto final (ruta en una URL) para recuperar información específica de la API. Por ejemplo, imaginemos que nuestro servicio de inteligencia de amenazas ficticio tiene un punto final llamado IP y requiere que proporciones una dirección IP a este punto final. Este punto final puede verse así: /ip/123.123.123.123, que agregamos a nuestra URL raíz: https://joshsthreatintel.example/v1/ip/123.123.123.123.

Como parte de nuestra solicitud, especificamos en nuestra llamada a este punto final que estamos realizando una CONSEGUIR solicitud, y queremos información sobre la dirección IP 123.123.123.123.

A continuación se muestran dos ejemplos de cómo hacer esto en Python y PowerShell Core:

• Pitón:
  • solicitudes de importación
  • respuesta = solicitudes.get('https://joshsthreatintel.example/v1/ip/123.123.123.123')
• Potencia Shell:

   

  • $response = Invocar-RestMethod -Uri '‘https://joshsthreatintel.example/v1/ip/123.123.123.123’' -Método GET

Es posible que esté disponible un punto final diferente que le permita CORREO una URL específica a nuestro servicio ficticio (Servicio de Inteligencia de Amenazas de Josh) para que pueda analizarse en busca de actividad maliciosa. Este punto final se llama URL y se añadiría a nuestra URL raíz: https://joshsthreatintel.example/v1/url.

Además de la solicitud http normal, cuando publicamos en este servicio falso para escanear una URL, debemos proporcionar en el cuerpo de nuestra solicitud la URL que queremos Servicio de inteligencia de amenazas de Josh Para escanear. Un ejemplo de esto en Python es:

cuerpo de la solicitud de importación = { 'url': 'http://some.malicious.website.com' } respuesta = solicitudes.post('https://joshsthreatintel.example/v1/url', datos=cuerpo}

Descubrirá que el ejemplo anterior es común y preferido por la mayoría de las API, pero este punto final también podría permitirle CONSEGUIR una URL que utiliza parámetros de consulta.

Un parámetro de consulta, en su nivel básico, es una forma de filtrar o seleccionar información de una API. Los parámetros de consulta se utilizan comúnmente cuando un servicio permite al usuario influir en los resultados devueltos por una llamada a la API, pero también pueden usarse para invocar una acción; por ejemplo, escanear una URL en lugar de proporcionar atributos en el cuerpo de una solicitud HTTP.

Los parámetros de consulta suelen añadirse entre sí, lo que reduce la legibilidad (en mi opinión). Aquí tienes un ejemplo que puedes ver al usar parámetros de consulta con API:

https://joshsthreatintel.example/v1/url?url=some.malicious.website.com {ruta del sitio web a la API}/{punto final}?{parámetro=valor}

Como puede ver en el ejemplo anterior, tenemos la ruta raíz de nuestra API y luego el punto final, que es el URL En este caso. Después de la URL punto final, podemos ver nuestro parámetro de consulta. Nuestro parámetro de consulta comienza con un ? y luego va seguido de un nombre de parámetro y el valor que estamos usando para ese parámetro.

Un punto final de API puede permitirle especificar varios parámetros de consulta. Por ejemplo, esta es la sintaxis de URL para recuperar información de la API REST de RIPE (Redes IP Europeas) para una dirección IP específica:

https://rest.db.ripe.net/search?source=ripe&query-string={querystring} {ruta del sitio web a la API}/{punto final}?{param=value}&{param=value}

Quizás hayas notado la adición de un &, Esto indica que hay otro parámetro de consulta. Este también contiene el nombre del parámetro y el valor que usamos para él. Una API podría permitirle añadir varios de estos parámetros. Deberá consultar la documentación de las API para ver qué se permite para un endpoint específico.

Descubrirá que las API de la vida real optarán por utilizar parámetros de consulta o requerirán que proporcione un par de datos clave-valor en el cuerpo de una solicitud.

Encabezados

Al utilizar API, es posible que se le solicite agregar información adicional a una CONSEGUIR o CORREO u otro método para el encabezados de una solicitud HTTP. Puede ser un token de autenticación, que especifica el tipo de contenido o proporciona otra información.

En términos básicos, una encabezamiento El valor son metadatos utilizados para establecer una conexión con una API. La API utiliza estos metadatos para autenticar o configurar el entorno para el tipo de acción/solicitud que se va a realizar.

Es muy común que las API que requieren autenticación exijan que se proporcione un token en los encabezados de las solicitudes HTTP. Este token puede ser a largo plazo o, en el caso de un esquema de autenticación basado en delegación (por ejemplo, OAuth2), un token temporal que debe actualizarse después de un tiempo. En cualquier caso, proporcionar esta autenticación es común en las API.

Es posible que también necesites especificar Aceptar o Tipo de contenido encabezados junto con un Autorización Encabezado. En pocas palabras, un encabezado suele tener el formato de un par clave-valor. Aquí hay un ejemplo en Python de cómo podrían verse estos dos encabezados:

custom_headers = { 'Aceptar': 'application/json', 'Autorización': 'Portador {SOME_AUTHENTICATION_TOKEN}' }

Estos encabezados se envían junto con nuestra solicitud HTTP al servidor. Los encabezados pueden ser necesarios o no al usar una API, y si una API los requiere, normalmente serán necesarios para todos los métodos utilizados en sus solicitudes HTTP.

Espero que esto les ayude a comprender los fundamentos de las API REST. En la próxima publicación, analizaré las API SOAP (Protocolo Simple de Acceso a Objetos), que son mucho más complejas que las API REST.