Las API son canales de comunicación a través de los cuales las aplicaciones pueden “hablar”. Para crear una conexión entre aplicaciones, las API REST usan HTTPS. Las solicitudes HTTP pasan a través del canal de comunicación API y transportan mensajes entre aplicaciones.

Los actores de amenazas se dirigen a las API REST porque buscan los datos almacenados en las solicitudes HTTP. Los actores de amenazas también usan API para iniciar ataques como:

  • Man in the Middle (MitM): manipula la comunicación contenida en un mensaje API.
  • Inyecciones API (XSS y SQLi): inyecta código malicioso (malware o ransomware) en la base de código API o en un mensaje API.
  • Denegación de servicio distribuida (DDoS): llamadas repetidas que solicitan conexiones API en rápida sucesión, que es un intento de abrumar al servidor y crear una interrupción. En este artículo, proporcionaremos una descripción general de los conceptos de API y una tabla que resume las recomendaciones OWASP más esenciales para la seguridad de la API REST

¿Qué es OWASP?

El Open Web Application Security Project (OWASP) es una organización sin fines de lucro comprometida a mejorar el fortalecimiento de la seguridad del software. Logran este objetivo al proporcionar recursos educativos imparciales, de forma gratuita, en su sitio web.

El sitio web de OWASP tiene una gran cantidad de información, incluidos foros comunitarios, documentación, videos y herramientas gratuitas. 

El top 10 de OWASP se publicó inicialmente en 2004 (y se actualizó en 2017), nacido de la necesidad de identificar las vulnerabilidades más críticas y priorizar la corrección en consecuencia. Si bien la lista de los 10 principales es una herramienta esencial para la seguridad del software, no es suficiente para mantener las redes protegidas.

Una idea errónea desafortunada es que adherirse a la lista de los 10 principales de OWASP es toda la seguridad que requiere una pieza de software. En realidad, el software de hoy está diseñado para la conectividad y, por lo tanto, se viola fácilmente, por lo que OWASP ha creado una hoja de trucos para la seguridad REST.

¿Qué es una interfaz de programación de aplicaciones (API)?

La conectividad entre aplicaciones se logra a través de una interfaz de programación de aplicaciones (API), que es un software que abre y cierra canales de comunicación. La API se compone de protocolos, herramientas y rutinas que permiten la extracción y distribución de datos.

Los dispositivos de Internet de las cosas (IoT) usan API para comunicarse entre ellos, la red, las aplicaciones que controlan y las aplicaciones que los controlan. Un interruptor inteligente del calentador de agua, por ejemplo, no podrá controlar de forma remota el calentador de agua sin el uso de una API. Las aplicaciones web usan API web para comunicarse entre sí, la red y los dispositivos IoT.

Conectar una cuenta de redes sociales, por ejemplo, a una aplicación de juego, requiere el uso de una API, otro ejemplo son las extensiones de Chrome que, para trabajar con el navegador, necesitan conectarse a la API de los navegadores.

¿Qué es una API REST?

Representational State Transfer (REST) ​​es un enfoque de implementación de API que utiliza el Protocolo de transferencia de hipertexto (HTTP) para crear conexiones. La API REST utiliza HTTP para recopilar datos, transferir datos y coordinar la ejecución de tareas entre sistemas remotos.

Las API REST utilizan principalmente archivos de notación de objetos JavaScript (JSON) para comprimir y transferir datos de una aplicación web a otra. Los archivos JSON son pequeños y, por lo tanto, más fáciles de transferir, y también son un archivo web estándar, lo que significa que los navegadores receptores podrían leer el archivo sin la ayuda de la API.

¿Qué es la seguridad REST?

Para lograr una comunicación segura, las API REST usan el Protocolo seguro de transferencia de hipertexto (HTTPS). Un protocolo de Seguridad de la capa de transporte (TLS) garantiza que la conexión sea privada (mediante el cifrado de los datos), autenticada (mediante criptografía de clave pública) y confiable (mediante el uso de un código de autenticación de mensaje).

Las API REST no tienen estado. Para completar una conexión, una API REST no necesita el cliente o el servidor. La solicitud HTTP se encarga de eso al recopilar y guardar la información solicitada. Esto significa que si los actores de la amenaza obtienen acceso a la solicitud HTTP, obtienen acceso a los datos.

Las prácticas y soluciones de seguridad REST se encargan de garantizar que cualquier conexión lograda a través de las API REST esté asegurada. Las prácticas de seguridad REST proporcionan una guía para desarrollar y asegurar el APIS (como se explica a continuación), y las soluciones de seguridad respaldan estos esfuerzos.

¿Qué es la hoja de trucos de seguridad OWASP REST?

La hoja de trucos de seguridad REST de OWASP es un documento que contiene las mejores prácticas para asegurar la API REST. Cada sección aborda un componente dentro de la arquitectura REST y explica cómo debe lograrse de manera segura.

La siguiente tabla resume las mejores prácticas clave de la hoja de trucos de seguridad OWASP REST. Para obtener más información, consulte la documentación oficial .

Componente API REST Definición Mejores prácticas
HTTPS Un protocolo de seguridad para la comunicación entre aplicaciones web. Proteja las credenciales de autenticación en tránsito proporcionando solo puntos finales HTTPS y agregue seguridad adicional a través de certificados del lado del cliente autenticados mutuamente
Control de acceso Un método de seguridad para regular qué usuarios o sistemas acceden a un dispositivo, software o recurso Use un proveedor de identidad (IdP) para generar tokens de autenticación y localice las decisiones de control de acceso a los puntos finales REST
Tokens web JSON (JWT) Un formato estándar para tokens de seguridad que llevan notificaciones de autenticación Siempre proteja la integridad del JWT con firmas criptográficas o MAC. Prefiera firmas cuando sea posible, y siempre use reclamos estandarizados
Claves API Una secuencia única de Solicitar una clave API para cada solicitud, usar caracteres que autentiquen las solicitudes API y luego responda o deniegue la llamada Solicite una clave API para cada solicitud, use el código de retorno 429 HTTP para demasiadas solicitudes y retire las claves API de los clientes que violen el acuerdo de uso
Métodos HTTP Un conjunto de métodos de solicitud (también conocidos como verbos) que implementa la acción que satisface una solicitud HTTP Restrinja los métodos HTTP mediante el uso de listas blancas de métodos, aplique el código de retorno 405 para los métodos rechazados y autentique los privilegios de los métodos de la persona que llama.

Implementación de la hoja de trucos de seguridad OWASP REST

Asegurar su API REST no tiene que ser difícil o incluso requerir mucho tiempo. A veces, solo es cuestión de evaluar su situación y luego aplicar las soluciones adecuadas. En la sección anterior, revisamos las mejores prácticas clave de seguridad REST. Ahora, le proporcionaremos algunos consejos profesionales para ayudarlo a proteger sus API.

1. Aplicando el estándar solo HTTPS

HTTPS se habilita mediante el uso de certificados SSL (Secure Socket Layer). El primer paso es comprar un certificado de su proveedor de host. A continuación, deberá instalar el certificado. Esto se realiza a través del panel de hosting, y es tan simple como seguir los pasos proporcionados por el host.

Hacer que su sitio sea solo HTTPS significa revisar sus directorios (como bibliotecas de clientes, ejemplos de código y aplicaciones de muestra) y reemplazar las llamadas de HTTP con HTTPS. Puede hacerlo manualmente, lo que lleva tiempo, o puede usar una herramienta gratuita de búsqueda y reemplazo .

2. Uso de un proveedor de identidad (IdP) para tokens

Un IdP es un sistema que controla el proceso de creación y gestión de información de identidad y proporciona servicios de autenticación como la generación de tokens. Una ficha es una secuencia de caracteres sin sentido que reemplaza la información sensible y financiera.

El IdP recibe una solicitud del sitio web para tokenizar la información. Luego, el sistema guarda la información en una ubicación segura y la reemplaza con un token. El IdP media entre el usuario y el sitio web, manteniendo la información segura en un repositorio de terceros. Puede encontrar una lista de IdP aquí .

3. Firmas criptográficas para JWT

Las firmas digitales proporcionan integridad, autenticación y no repudio, lo que las hace ideales para emitir tokens. Puede delegar la tarea de generar tokens a un IdP (como se explicó anteriormente) o puede hacerlo manualmente mediante el uso de un servidor OAuth 2.0 verificado.

Puede construir su propio servidor OAuth, usar el servidor OAuth patrocinado por OKTA y puede usar una solución de código abierto. Antes de comprometerse con un camino, evalúe su situación con honestidad y asegúrese de tener las habilidades y los recursos para hacerlo por su cuenta.

4. Agregue el código de retorno 429 HTTP para demasiadas solicitudes

El propósito del código de retorno 429 es evitar repetidas solicitudes de API. Depende de usted determinar cuántas solicitudes son demasiadas en un momento dado, pero este código de retorno es obligatorio. Le proporciona un mecanismo para proporcionar ataques DDoS, que podrían causar una interrupción del sistema.

Aquí hay un ejemplo de código 429 de la documentación de RFC :

Ejemplo de código 429 de la documentación de RFC

Recuerde: nunca use un caché para almacenar 429 códigos de estado (!)

5. Use Cross-Origin Resource Sharing (CORS) para restringir los métodos HTTP

CORS es una técnica que proporciona controles para compartir recursos. Eso significa que puede usar CORS para configurar cuándo se debe otorgar o denegar el acceso a los métodos HTTP cuando se debe restringir, y qué credenciales y orígenes están autorizados.

Recomendaciones

El control de acceso sólo es efectivo si es aplicado del lado del servidor o en Server-less API, donde el atacante no puede modificar la verificación de control de acceso o los metadatos.

Con la excepción de los recursos públicos, la política debe ser denegar de forma predeterminada.


Implemente los mecanismos de control de acceso una vez y reutilícelo en toda la aplicación, incluyendo minimizar el control de acceso HTTP (CORS).


Los controles de acceso al modelo deben imponer la propiedad (dueño) de los registros, en lugar de aceptar que el usuario puede crear, leer, actualizar o eliminar cualquier registro.


Los modelos de dominio deben hacer cumplir los requisitos exclusivos de los límites de negocio de las aplicaciones.


Deshabilite el listado de directorios del servidor web y asegúrese que los metadatos/fuentes de archivos (por ejemplo de GIT) y copia de seguridad no estén presentes en las carpetas públicas.

fuente:https://blog.restcase.com/top-5-owasp-security-tips-for-designing-secured-rest-apis/

¡Haz clic para puntuar esta entrada!
(Votos: 1 Promedio: 5)

compartir en ....
Avatar

Acerca de Brian Alexander Diaz

Brian Alexander Diaz Investigador en temas de seguridad y Devops Mi nombre es Brian Alexander Diaz. El objetivo de este blog es promover la cultura y mentalidad en seguridad por todo el Internet y que la gente aprenda a facilitar su vida y crear  sistemas mas seguros .

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *