Header Ads Widget

Ticker

6/recent/ticker-posts

9 amenazas comunes de API y cómo evitarlas

 

Por su propia naturaleza, las API permiten el acceso a grandes cantidades de datos, datos de clientes potencialmente confidenciales, sin pasar por las precauciones del navegador. Ya no es suficiente centrarse en la inyección SQL y los problemas de XSS. En cambio, debe preocuparse por los malos actores que pueden paginar a través de todos los registros de sus clientes y sus datos asociados.

Los mecanismos de prevención típicos como Captchas y las huellas dactilares del navegador no funcionarán, ya que por diseño, las API deben manejar una gran cantidad de llamadas API para cada consumidor. Entonces, ¿por dónde empiezas? Lo primero es ponerse en la piel de un hacker. Luego, configure sus API para detectar y bloquear ataques comunes junto con incógnitas para exploits de día cero.

A continuación, cubriremos nueve de las amenazas API más comunes y discutiremos cómo evitarlas por completo. Algunos de estos están en la lista de API de seguridad de OWASP , pero no todos.

1. Ataques de paginación

La mayoría de las API brindan acceso a recursos que son listas de entidades como /users/widgetsUn cliente como un navegador normalmente filtraría y paginaría a través de esta lista para limitar la cantidad de elementos devueltos a un cliente de esta manera:

First Call: GET /items?skip=0&take=10

Second Call: GET /items?skip=10&take=10

Sin embargo, si esa entidad tiene PII u otra información, entonces un pirata informático podría raspar ese punto final para obtener un volcado de todas las entidades en su base de datos. Esto podría ser más peligroso si esas entidades expusieron accidentalmente PII u otra información confidencial, pero también podría ser peligroso para proporcionar a la competencia u otras personas estadísticas de adopción y uso para su negocio o brindar a los estafadores una forma de acceder a grandes listas de correo electrónico. Por ejemplo, vea cómo se extrajeron los datos de Venmo aquí .

Un mecanismo de protección ingenuo sería verificar el recuento de tomas y arrojar un error si es mayor que 100 o 1000. El problema con esto es doble:

  1. Para las API de datos, los clientes legítimos pueden necesitar buscar y sincronizar muchos registros a través de trabajos cron. Los límites de paginación artificialmente pequeños pueden obligar a su API a hablar mucho, lo que reduce el rendimiento general. Los límites máximos son para garantizar que se cumplan los requisitos de memoria y escalabilidad (y para prevenir ciertos ataques DDoS), no para garantizar la seguridad.
  2. Esto ofrece protección cero a un hacker que escribe un script simple que duerme un retraso aleatorio entre accesos repetidos.
skip = 0
while True: response = requests.post('https://api.acmeinc.com/widgets?take=10&skip=' + skip), headers={'Authorization': 'Bearer' + ' ' + sys.argv[1]}) print("Fetched 10 items") sleep(randint(100,1000)) skip += 10

Cómo protegerse contra ataques de paginación

Para protegerse contra los ataques de paginación, debe realizar un seguimiento de cuántos elementos de un solo recurso se accede dentro de un período de tiempo determinado para cada usuario o clave de API en lugar de solo a nivel de solicitud. Al rastrear el acceso a los recursos de la API a nivel de usuario , puede bloquear un usuario o una clave de API una vez que alcance un umbral, como "tocó 1,000,000 de elementos en una hora". Esto depende de su caso de uso de API e incluso puede depender de su suscripción con usted. Al igual que un Captcha, esto puede ralentizar la velocidad a la que un hacker puede explotar su API si tiene que crear una nueva cuenta de usuario manualmente para crear una nueva clave de API.

2. Generación de claves API inseguras

La mayoría de las API están protegidas por algún tipo de clave API o JWT (JSON Web Token). Esto proporciona una forma natural de rastrear y proteger su API, ya que las herramientas de seguridad de la API pueden detectar el comportamiento anormal de la API y bloquear el acceso a una clave de API automáticamente. Sin embargo, los piratas informáticos querrán burlar estos mecanismos generando y utilizando una gran cantidad de claves API de una gran cantidad de usuarios, al igual que un pirata informático usaría una gran cantidad de direcciones IP para eludir la protección DDoS.

Cómo protegerse contra grupos de claves API

La forma más fácil de protegerse contra este tipo de ataques es exigir que un humano se registre en su servicio y genere claves API. El tráfico de bot puede evitarse con cosas como Captcha y Autenticación de 2 factores.

A menos que exista un caso comercial legítimo, los nuevos usuarios que se registren en su servicio no deberían tener la capacidad de generar claves API mediante programación. En cambio, solo los clientes de confianza deben tener la capacidad de generar claves API de forma programática. Vaya un paso más allá y asegúrese de que cualquier detección de anomalías por comportamiento anormal se realice a nivel de usuario y cuenta, no solo para cada clave de API.

3. Exposición accidental de teclas

Las API se utilizan a menudo de una manera que aumenta la probabilidad de que se filtren las credenciales:

  1. Se espera que se acceda a las API durante períodos de tiempo indefinidos, lo que aumenta la probabilidad de que un pirata informático obtenga una clave API válida que no haya expirado. Guarde esa clave de API en una variable de entorno de servidor y olvídese de ella. Este es un contraste drástico con un usuario que inicia sesión en un sitio web interactivo donde la sesión expira después de una corta duración.
  2. El consumidor de una API tiene acceso directo a las credenciales, como cuando depura a través de Postman o CURL. Solo se necesita un único desarrollador para copiar / pegar accidentalmente el comando CURL que contiene la clave API en un foro público como en GitHub Issues o Stack Overflow.
  3. Las claves de API suelen ser tokens de portador sin requerir ninguna otra información de identificación. Las API no pueden aprovechar cosas como tokens de un solo uso o autenticación de 2 factores.

Si una clave está expuesta debido a un error del usuario, uno puede pensar que usted, como proveedor de API, tiene la culpa. Sin embargo, la seguridad se trata de reducir la superficie y el riesgo. Trate los datos de su cliente como si fueran suyos; Ayúdelos agregando protectores que eviten la exposición accidental de llaves.

Cómo prevenir la exposición accidental de llaves

La forma más sencilla de evitar la exposición de claves es aprovechando dos tokens en lugar de uno. Un token de actualización se almacena como una variable de entorno y solo se puede utilizar para generar tokens de acceso de corta duración . A diferencia del token de actualización, estos tokens de corta duración pueden acceder a los recursos, pero tienen un límite de tiempo, como horas o días.

El cliente almacenará el token de actualización con otras claves API. Luego, su SDK generará tokens de acceso en SDK init o cuando expire el último token de acceso. Si un comando CURL se pega en un problema de GitHub, entonces un pirata informático debería usarlo en unas horas para reducir el vector de ataque (a menos que fuera el token de actualización real, que es una probabilidad baja).

4. Exposición a ataques DDoS

Las API abren modelos de negocio completamente nuevos donde los clientes pueden acceder a su plataforma API de forma programática. Sin embargo, esto puede dificultar la protección contra DDoS. La mayor parte de la protección DDoS está diseñada para absorber y rechazar una gran cantidad de solicitudes de malos actores durante los ataques. Sin embargo, todavía necesitan dejar pasar a los buenos. Este proceso requiere tomar las huellas digitales de las solicitudes HTTP para compararlas con lo que parece ser tráfico de bots. Sin embargo, esto es mucho más difícil para los productos API, ya que todo el tráfico parece tráfico de bot y no proviene de un navegador donde hay elementos como cookies.

Detener los ataques DDoS

La parte mágica de las API es que casi todos los accesos requieren una clave API. Supongamos que una solicitud no tiene una clave API. En ese caso, puede rechazarlo automáticamente, lo que es liviano en sus servidores (asegúrese de que la autenticación esté en cortocircuito muy temprano antes de que el middleware posterior, como solicitar el análisis JSON).

Entonces, ¿cómo maneja las solicitudes autenticadas? Lo más fácil es aprovechar los contadores de límite de tasa para cada clave de API, como manejar X solicitudes por minuto y rechazar aquellas por encima del umbral con un 429 HTTP responseHay una variedad de algoritmos para hacer este cubo con fugas y contadores de ventanas fijos.

5. Seguridad del servidor incorrecta

Las API no son diferentes a los servidores web cuando se trata de una buena higiene del servidor. Los datos se pueden filtrar debido a certificados SSL mal configurados o al permitir tráfico no HTTPS. Para las aplicaciones modernas, hay muy pocas razones para aceptar solicitudes que no sean HTTPS, pero un cliente podría emitir por error una solicitud que no sea HTTP desde su aplicación o CURL exponiendo la clave API. Las API no tienen la protección de un navegador, por lo que cosas como HSTS o redireccionar a HTTPS no ofrecen protección.

Cómo garantizar un SSL adecuado

Pruebe su implementación de SSL en Qualys SSL Test o con una herramienta similar. También debe bloquear todas las solicitudes que no sean HTTP que se pueden realizar dentro de su balanceador de carga. También debe eliminar los encabezados HTTP y eliminar los mensajes de error que filtran detalles de implementación. Si su API es utilizada solo por sus propias aplicaciones o solo se puede acceder a ella desde el lado del servidor, revise la guía autorizada para el intercambio de recursos entre orígenes para las API REST .

6. Encabezados de almacenamiento en caché incorrectos

Las API brindan acceso a datos dinámicos que están dentro del alcance de cada clave de API. Cualquier implementación de almacenamiento en caché debe tener la capacidad de utilizar una clave API para evitar la contaminación cruzada. Incluso si no almacena en caché nada en su infraestructura, podría exponer a sus clientes a agujeros de seguridad. Si un cliente con un servidor proxy estaba usando varias claves de API, como una para desarrollo y otra para producción, podría ver datos de polinización cruzada.

¿Qué tan grave es esto? Vea la divulgación de Twitter de una filtración de información de facturación después de un incidente de seguridad de datos .

Cómo garantizar que no haya almacenamiento en caché

Debe asegurarse de que los encabezados de Cache-Control estén configurados correctamente.

Un gran problema para las API es que muchas no usan el Authorizationencabezado estándar En su lugar, utilizan un encabezado personalizado como X-Api-KeyLos servidores de almacenamiento en caché no tienen conocimiento de que esta solicitud se esté autenticando y, por lo tanto, elige almacenar en caché la solicitud.

app.use((req, res, next) => {
  res.setHeader('Cache-Control', 'no-store, no-cache, must-revalidate');
  res.setHeader('Pragma', 'no-cache');
  // ...
});

7. Registro y supervisión insuficientes

El registro y la supervisión insuficientes es un elemento de seguridad de las 10 API principales de OWASP. La mayoría de los estudios de violación demuestran que el tiempo para detectar una violación de datos es de más de 200 días. Si no cuenta con el registro y la supervisión de API adecuados, los atacantes pueden seguir utilizando la misma vulnerabilidad o incluso
buscar más vulnerabilidades.

Cómo agregar correctamente el registro de API

Debe asegurarse de que su registro de API no solo rastree las solicitudes de API en sí, sino que también esté vinculado a los usuarios para el análisis del comportamiento del usuario y se almacene durante al menos un año. Estos sistemas deben protegerse para garantizar que los datos no se eliminen accidentalmente o se retiren anticipadamente.

GDPR y CCPA proporcionan excepciones para los registros de auditoría de API por motivos de seguridad. Las soluciones de algunas empresas proporcionan un conjunto completo de análisis y supervisión de API para productos de API y pueden comenzar en solo unos minutos:

8. Puntos finales internos inseguros

El mismo servicio de API puede tener puntos finales que se utilizan tanto externa como externamente. El hecho de que un punto final no esté documentado no significa que un hacker no pueda llamarlo. Además de asegurar con un esquema de autenticación y autorización, debe asegurarse de que estos puntos finales no estén expuestos a la Internet pública en absoluto, lo que se puede hacer dentro de su balanceador de carga o puerta de enlace API. Esto ayuda al proporcionar múltiples niveles de seguridad, una estrategia común en la prevención.

9. Autorización de no manipulación

Si bien la mayoría de los desarrolladores de API agregarán un esquema de autenticación global , como claves de API u OAuth, para verificar quién es la persona, es más difícil implementar la autorización . También es obligatorio y separado de la autenticación. La autorización implica verificar si esta persona (que ya está identificada) puede acceder a un recurso en particular. Esto se puede hacer a través de los ámbitos de la API, comprobando una identificación de inquilino o una identificación de usuario, entre otras cosas.

Debido a que es específico para la lógica de su aplicación y no siempre es transversal, la autorización puede ser un área que los desarrolladores olvidan. A menos que sus identificadores de objetos tengan suficiente entropía, un pirata informático podría probar fácilmente diferentes identificadores a través de la iteración. Esto es especialmente cierto para las bases de datos SQL que incrementan la identificación en la inserción.

Cómo arreglar la autorización

Asegúrese de que el usuario autenticado esté autorizado para acceder a todos los recursos necesarios para generar la respuesta de la API. Esto puede implicar la verificación con una identificación de usuario o listas de control de acceso (ACL) que están vinculadas a los objetos en cuestión. Puede encontrar más información sobre cómo manejar la autorización aquí: Pasos para crear autenticación y autorización para API RESTful

Publicar un comentario

0 Comentarios