Header Ads Widget

Ticker

6/recent/ticker-posts

5 formas de piratear una API (y cómo defenderla)

 


La piratería de API es, desafortunadamente, parte del panorama moderno de API. Siempre que tenga recursos expuestos a Internet, esos recursos serán atacados de alguna manera.

Afortunadamente, la mitad de la lucha es estar al tanto de las amenazas contra su API. Saber que existe una amenaza y preparar sus soluciones con anticipación puede anular la amenaza cuando asoma su fea cabeza.

Con ese fin, hoy vamos a discutir 4 métodos comunes de pirateo de API , cómo funcionan y cómo puede prepararse para manejarlos.

1: Ingeniería inversa

A menudo vemos nuestras API en términos de la experiencia del desarrollador : de principio a fin, cómo el desarrollador promedio experimentará la oferta. El hecho es que esta vista es defectuosa: solo considera la API como está destinada  a ser utilizada.

Por supuesto, no siempre será así la interacción de la API; en experiencias de usuario defectuosas, la API podría funcionar de formas inesperadas. En el caso de la ingeniería inversa , eso es exactamente lo que intenta hacer el pirata informático. Llaman a la API de manera inversa para descubrir debilidades en la API que de otro modo podrían ocultarse durante el uso normal.

Por ejemplo, supongamos que tenemos una API en la que se pueden solicitar los datos de la cuenta de usuario cuando se realiza un pedido repetido. Para el usuario y para el desarrollador, el flujo se parece a lo siguiente:

  1. Pedido solicitado
  2. Pedido asociado a la cuenta
  3. Pedido cumplido.

Para alguien con ingeniería inversa de la API, por supuesto, este flujo tiene algunos puntos posibles para un mal uso. Si el sistema de cumplimiento de pedidos se ingresa al revés , es posible que la API interna que vincula los pedidos a las cuentas se pueda dividir, lo que permite la navegación y exposición de los datos de la cuenta del usuario .

Si bien es posible que el flujo de uso típico no exponga esta falla, los problemas específicos con el proceso pueden ser más fáciles de ver al mirar al revés. Por supuesto, cuando la mayoría de los desarrolladores ven esto, a menudo es demasiado tarde y ya se ha producido una exposición.

Leer más aquí: Ingeniería inversa de la API de Pokemon Go

Cómo combatirlo

Una solución a este problema es el cifrado de nivel básico . Al cifrar los datos en tránsito y en reposo, está ocultando la naturaleza y la relación de los datos que maneja cualquier llamada. Esencialmente, está permitiendo que la funcionalidad funcione como se espera, pero está oscureciendo las relaciones entre esos datos. Es esta información de relación la que impulsa la mayor parte de la ingeniería inversa; El simple hecho de tener los datos no significa mucho si no sabe cómo descifrarlos o utilizarlos.

El principal problema con este tipo de defensa es que un atacante a menudo puede hacerse pasar por un agente de confianza . Por lo tanto, la ofuscación no es exactamente efectiva, ya que cualquiera de los extremos de la ecuación es propenso a la falsificación y la suplantación. En consecuencia, si bien es útil cifrar datos (y, para decirlo sin rodeos, debería ser tan bueno como un requisito para la mayoría de las API), sus defensas no pueden limitarse a "cifrar y esperar lo mejor".

Una solución más es cambiar la forma en que se estructuran realmente sus URI . Si un URI tiene información codificada en la llamada, como formatos de directorio específicos que exponen dónde se encuentra el recurso y el almacenamiento organizacional para los recursos relacionados, entonces los URI en sí mismos podrían estar regalando una tonelada de información valiosa. Cambiarlos para que sean menos obvios puede contribuir en gran medida a negar tal descubrimiento.

El aprendizaje automático y la heurística han hecho que la detección de este tipo de ataques sea mucho más fácil, y hay una cierta cantidad de defensa que se puede encontrar en dicha tecnología. Aprovechar los datos aprendidos del comportamiento del usuario y agregar estos datos puede ayudar a identificar comportamientos atípicos . Por ejemplo, al realizar un seguimiento de las interacciones del usuario promedio en su API, puede establecer una línea de base que puede ayudar a identificar las desviaciones extremas. Si su API normalmente tiene una o dos llamadas normales por sesión, pero un solo usuario envía sondas constantes al sistema de inicio de sesión de su servidor de medios con credenciales aleatorias, puede estar relativamente seguro de que esta actividad no es válida.

Estos sistemas también pueden combinarse con sistemas de ofuscación en vivo ; enrutar el tráfico a un punto final establecido que enruta aleatoriamente a un conjunto de puntos finales con nombres aleatorios. Esto puede ayudar a combatir y disuadir estos ataques, y cuando combina esto con la detección basada en heurística , puede mitigar los ataques en gran medida.

Por supuesto, se podría argumentar que el mejor enfoque es separar la funcionalidad que no desea que se realice ingeniería inversa de las funciones comunes que desea exponer. Al separarlos en microservicios , puede eliminar el vector de amenazas a sus servicios normales y proteger en gran medida sus puntos de servicio principales de este tipo de ataques.

Spoofing

En el contexto de una API, la suplantación de identidad es cuando una parte se hace pasar por alguien que no es. Esto puede tomar una variedad de formas, que detallamos a continuación.

2. Suplantación de usuarios

La suplantación de identidad del usuario es cuando un atacante finge ser alguien que no es. A menudo, el atacante intentará presentarse a sí mismo como un usuario de confianza para pasar a usuarios adicionales, permitiéndoles acceso libre a los datos y la capacidad de causar más daño sin ser descubierto fácilmente. Estos ataques a menudo utilizan datos descubiertos a través de phishing u otras filtraciones de credenciales similares para evitar que se activen otras alarmas, como las que se encuentran en la ingeniería inversa.

Una vez que el atacante ha abordado el sistema, el ataque a menudo intenta inyectar algún tipo de ataque de escalada de privilegios al dirigir las funciones de URI a otras URI (como es el caso de las API de codificación de medios), insertando código que actúa como texto (como en el caso de la traducción API), o simplemente inundando las API con más datos que puede manejar, lo que fuerza una falla de desbordamiento.

Lea también: Su API es vulnerable si estos 4 riesgos no se mitigan

3. Ataque del hombre en el medio

En este tipo de ataque, el atacante se hará pasar por un elemento en la cadena de comunicación con el servidor o el propio servidor. El objetivo del atacante aquí es actuar como si fuera un enlace confiable en la cadena de API, interceptando datos para transformarlos o descargarlos.

A veces, este ataque se puede realizar ocupando un dominio que es similar al esquema de URI de API y copiando el formato de la solicitud de API / ubicación de recursos (o al menos, haciéndolo parecer igual). En este caso, un usuario podría estar solicitando una llamada utilizando un recurso ubicado en , y un ocupante ilegal podría sentarse La diferencia de un solo carácter podría marcar la diferencia en el mundo y abrir al solicitante a la realidad de enviar sus credenciales al servidor equivocado .API.io/media/functionAPO.io/media/function

Otras veces, el ataque podría manifestarse en forma de establecimiento de un nodo entre el usuario y los datos solicitados. Si se infringe el servicio de resolución, entonces se podría agregar fácilmente una llamada secundaria a la función del servidor, enviando automáticamente los datos recibidos a un servicio externo .

Los proveedores deben tener en cuenta que este ataque suele ser transparente : el atacante quiere aparecer como una parte válida de la cadena, por lo que aún podría responder con los datos correctos, pasando los datos a la API y respondiendo con el paquete de respuesta. Esto se hace para que el usuario no tenga idea de que ha sido comprometido. Las versiones avanzadas de este ataque podrían ver cambios en los datos a mitad de la transferencia, lo que obligaría a que tu depósito se colocara en una cuenta bancaria diferente o que tu compra se enviara a una dirección diferente.

Cómo combatirlo

Una solución a este problema es la fijación de certificados . La fijación de certificados consiste básicamente en configurar un certificado de servidor preconfigurado en el que confía la API. Cuando se inicia el proceso de protocolo de enlace, el certificado recibido se compara con el certificado de confianza; si no coinciden, la comunicación se invalida y la conexión del servidor se rechaza.

Por supuesto, esto depende de confiar en la autoridad de certificación y, por lo tanto, asumir que la autoridad no es parte del bucle falso. Dicho esto, exigir un certificado preconfigurado muy específico hace que cada parte de la cadena tenga que corromperse para que se produzca una falsificación perjudicial.

Otra solución es cifrar todo el tráfico en tránsito . Si bien el ataque aún puede capturar datos, los datos deberían volverse inútiles con el cifrado adecuado, asegurando que lo que se captura sea esencialmente "ruido". También puede agregar sal al flujo de datos para hacer que estos datos sean aún más difíciles de usar. El problema aquí es que los datos aún se están capturando y el sistema asume que todo el cifrado permanecerá en el estado actual. La historia nos dice, por supuesto, que esto no es la realidad, ya que los principales y sólidos estándares de cifrado de antaño ahora se consideran en gran parte inseguros. La criptografía de clave pública ayuda un poco en esto, pero en última instancia, necesitará un grupo de soluciones para mitigar eficazmente su fin de esta amenaza.

También puede utilizar servicios como la autenticación de dos factores para prevenir este tipo de ataques desde la perspectiva del usuario. Si se requiere que un usuario use la autenticación de dos factores y un ataque de intermediario intenta ser transparente, las llamadas se separarán entre sí. Incluso si se capturan las llamadas, se cifrarán y separarán; si aplica el saneamiento de la sesión correctamente, esta autenticación de dos factores evitará que se produzcan daños importantes y, en el momento en que, en teoría, podría romperse, la ventana de transacción tendrá mucho tiempo. pasado.

4: Repeticiones de sesiones

Las repeticiones de sesiones son específicamente contra sitios web y otros sistemas que generan y almacenan sesiones. Si bien el diseño RESTful adecuado no debe ocuparse del estado, esa no siempre es la realidad de la situación: muchas API, ya sea por razones válidas o no, tienen el estado como parte de su flujo central, incluso si se llaman a sí mismas "RESTful". Cuando las sesiones son parte de la ecuación, este tipo de ataque está diseñado para capturar la sesión y reproducirla en el servidor. En efecto, el atacante está rebobinando el tiempo y obligando al servidor a divulgar datos como si la misma interacción estuviera ocurriendo una vez más.

En muchos casos, si este tipo de ataque no se detiene, puede permitir que el atacante actúe como el usuario y podría dar lugar a ataques adicionales, especialmente aquellos que dependen de la pivotación con las credenciales del usuario. Si esta es solo una sesión de usuario normal, el ataque puede ser malo; sin embargo, si la sesión es de un administrador o de un usuario elevado, podría ser catastrófico.

Cómo combatirlo

La gestión adecuada de la sesión es la clave aquí. En primer lugar, es posible que el estado del servidor y la sesión no siempre sean lo mismo, pero si realiza una comunicación de API RESTful, la diferencia no es realmente tan importante; debería evitar las sesiones en general. Las sesiones y los estados en muchas aplicaciones tienen exactamente los mismos propósitos y abren la API a un gran riesgo.

Si tiene que usar sesiones, asegúrese de que esas sesiones se invaliden una vez que pase un período de inactividad o el usuario cierre la sesión. También puede configurar la duración de la sesión para que finalice en un punto determinado, lo que invalidará la sesión y evitará este tipo de ataque.

También puede cifrar los datos de la sesión si se requiere una sesión. Asegúrese de que una vez que se conecta una sesión, se utiliza algún fragmento de código cifrado como una especie de token para esa sesión. Sin él, si la sesión se vuelve a reproducir en el futuro, es esencialmente inútil, ya que el token en sí es lo que hace que la sesión sea válida.

5: Ingeniería social

Si bien esto no es en sí mismo técnicamente un "truco de API", afecta directamente a la API. La ingeniería social no está atacando el código de la máquina y la API en sí, sino el elemento más débil de todos: el elemento humano . Los humanos son falibles y pueden ser engañados, a menudo con mucha facilidad. La ingeniería social se aprovecha de esto de muchas formas.

El phishing es el proceso de enviar un contacto masivo a usuarios conocidos, a menudo utilizando correos electrónicos inteligentemente diseñados que proporcionan enlaces para restablecer una contraseña o validar un incidente de seguridad. El problema es que estos enlaces no son reales y, en cambio, hacen que el atacante obtenga las credenciales. El spear phishing es muy similar, pero se centra en un objetivo de alto valor, a menudo proporcionando datos adicionales, generalmente robados en algún tipo de incidente de seguridad, para infundir confianza en el usuario de que la comunicación es realmente válida.

Una vez que el atacante tiene acceso a estos recursos, puede cometer cualquiera de los ataques anteriores mucho más fácilmente y con mayor éxito. Es difícil detectar a un atacante cuando ingresa a la red con credenciales legítimas.

Cómo combatirlo

Si bien podría argumentar que esto se puede resolver a través de la educación e inculcando el sentido común en sus usuarios, eso es solo un sueño en muchos sentidos. No se puede aplicar el sentido común, y tratar de hacerlo es realmente una tontería.

El mejor método que puede hacer para detener la ingeniería social es aplicar la seguridad a nivel de API . Puede utilizar sistemas heurísticos de inclusión voluntaria para determinar cuándo un usuario proviene de una máquina desconocida, una ubicación desconocida u otra variación en el comportamiento conocido. De esta manera, está tratando el síntoma, no la causa, pero el efecto sigue siendo protector.

También puede utilizar la autenticación de dos factores en este caso. Este tipo de autenticación detendría cualquier intento de ingeniería social en seco al requerir que el atacante tenga algo que no tiene, generalmente una aplicación de autenticación en el teléfono de alguien. Si bien esto no hace que un ataque de este tipo sea imposible en sí mismo, lo hace muy costoso en términos de tiempo y esfuerzo y, al hacerlo, disminuye el valor inmediato y hace que este tipo de ataque sea más costoso de lo que vale.

Conclusión

En última instancia, la seguridad de la API siempre será un juego del gato y el ratón. Las soluciones que se ofrecen aquí son en gran medida un punto de partida; Será necesario implementar una combinación de estas soluciones para obtener una protección significativa. También tenga en cuenta que esta lista no es exhaustiva: hay tantas formas de piratear una API como hackers para utilizarlas. En consecuencia, lo mejor que puede hacer es simplemente estar al tanto y ser consciente de sus elecciones de diseño.

¿Cuáles crees que son las formas más comunes de piratear una API? ¿Crees que las API se enfrentan a diferentes tipos de amenazas que otros recursos en línea? Háganos saber a continuación.



Publicar un comentario

0 Comentarios