Tres ataques que no se pueden detener con la codificación segura

Cuando se trata de violaciones que involucran aplicaciones y exposición de datos, casi siempre se apunta a los desarrolladores. Muchas veces, esta es la dirección correcta. Los ataques de inyección y los exploits basados en pilas casi siempre son el resultado de código inseguro. Generalmente porque se violó la Regla de Seguridad Cero .

Pero no podemos culpar a los desarrolladores de todas las infracciones. La verdad es que incluso si los desarrolladores pudieran producir código perfectamente seguro, aún necesitarían servicios de aplicação para protegerse contra muchos otros ataques.

Esto se debe a que la seguridad de las aplicação es una pila . Hay ataques que explotan protocolos y principios de red que no se pueden eliminar simplemente "codificando de forma segura". Lo que complica aún más la seguridad es que estos ataques a menudo son indetectables para las aplicações porque carecen de la visibilidad para distinguir las solicitudes maliciosas de las legítimas.

En particular, hay tres ataques que los desarrolladores simplemente no deberían ser responsables de manejar. En cambio, estos ataques se detectan y mitigan mejor mediante servicios de aplicação implementados en sentido ascendente, donde la visibilidad y el contexto están disponibles para ayudar a detenerlos.

DDoS volumétricos

Usamos el término volumétrico para describir un ataque tradicional de denegación de servicio distribuido para distinguir los ataques basados ​​en sobrecarga de la red de aquellos que se han movido "hacia arriba en la pila" para atacar la capa de aplicação . Son clases diferentes de ataques y por lo tanto necesitamos poder defendernos contra ambos, pero la forma en que lo hacemos requiere soluciones muy diferentes.

Un ataque volumétrico es simplemente un bombardeo. Se dirige un aluvión de tráfico a un servicio particular con la intención de saturar cualquier dispositivo, infraestructura o software que esté manejando las solicitudes. El principio en juego es que todos los dispositivos, ya sean hardware o software, locales o en la nube, tienen recursos limitados. De esta manera, al enviar suficientes solicitudes, el dispositivo puede verse sobrecargado y cerrar el acceso a todo lo que está detrás de él.

La razón por la que los desarrolladores no pueden prevenir eficazmente este ataque es porque las aplicações dependen de plataformas y sistemas operativos host para administrar la red. Un ataque DDoS volumétrico tiene como objetivo esa pila de red y es capaz de consumir gran parte de los recursos compartidos, por lo que la aplicação apenas puede procesar las solicitudes necesarias para determinar que está siendo atacada.

La codificación segura no puede evitar esto: no es una explotación debido a una vulnerabilidad. Y realmente no es culpa del código en ninguna parte del sistema. Lo que ocurre es que, por mucho que intentemos fingir que no existe hardware, de ahí provienen los recursos, que son limitados.

Los ataques DDoS volumétricos se detectan y mitigan mejor mediante servicios de aplicação de alto rendimiento y alta capacidad que residen aguas arriba de una aplicação. Cuanto más cerca de la fuente del ataque, mejor.

Sin exploit, no hay solución de codificación segura.

DDoS de capa 7

Subiendo por la pila hasta la capa de aplicação encontramos una forma insidiosa de denegación de servicio llamada DDoS de capa 7 (o HTTP). Estos ataques son exasperantes porque son exploits, pero no se deben a una vulnerabilidad o a una codificación insegura. Estos ataques funcionan debido a la naturaleza de HTTP y los sistemas que lo implementan.

Generalmente hay dos tipos de ataques DDoS de capa 7: lentos y rápidos. Los ataques DDoS de capa 7 lentos consumen recursos simulando tener una conexión de red terrible y desviando lentamente las respuestas de las solicitudes legítimas. Esto consume recursos porque las aplicaciones web se basan en conexión y, una vez más, los recursos para mantener esas conexiones son limitados. Al conectarse con suficientes clientes y realizar solicitudes legítimas solo para recibir respuestas lentamente, los atacantes pueden bloquear los recursos de la aplicação . Esto tiene el efecto de hacer que sea casi imposible que clientes legítimos se conecten, lo que en realidad lleva a cabo un ataque de denegación de servicio.

Este ataque es particularmente nefasto y difícil de detectar, a menos que estés comparando las velocidades de la red con las velocidades de recepción. Es decir, los servicios de aplicação ascendentes tienen visibilidad de las características de red de los clientes y pueden determinar con mayor precisión si esos clientes están tardando deliberadamente en recibir o si realmente tienen un problema de red.  Determinar la legitimidad es fundamental para acabar con este tipo de ataques.

Básicamente, estos ataques explotan la capa de protocolo (HTTP) y no hay nada que la codificación segura pueda hacer para solucionarlo.

Sin vulnerabilidad no hay solución de codificación segura.

Credential Stuffing

Por último, pero no menos importante, está el credential stuffing . La increíble cantidad de credenciales expuestas a través de violaciones en los últimos años hace que este ataque sea importante para defenderse.

Los ataques de credential stuffing generalmente dependen de bots o herramientas, porque se basan en principios de fuerza bruta que aprovechan los grandes conjuntos de volcados de nombres de usuario y contraseñas existentes. Es raro encontrar ataques de credential stuffing realizados manualmente. Un ataque de credential stuffing exitoso no es el resultado de una codificación insegura*.  Los atacantes no intentan explotar nada más que malas prácticas en el uso de contraseñas y la incapacidad de reconocer un ataque en curso.

Para detectar estos ataques, es necesario poder determinar que el cliente no es un ser humano válido. Entonces, en una especie de prueba de Turing inversa, necesitarás presentar desafíos y usar CAPTCHAs de maneras que estos sistemas automatizados no pueden responder.

Ninguna cantidad de codificación segura puede evitar que este ataque tenga éxito. Mejorar las prácticas de uso de contraseñas y detectar intentos de ataques son las mejores formas de evitar sucumbir a este creciente flagelo de Internet.

Sin código explotable no hay solución de codificación segura.

* Los ataques de credential stuffing pueden ser posibles debido a una codificación insegura. Después de todo, una cantidad significativa de infracciones ocurren debido a vulnerabilidades basadas en código que dan lugar a listas masivas de credenciales disponibles para este ataque.

Diferenciar para detectar y defender

Es importante reconocer cuándo se puede utilizar codificación segura para prevenir un ataque y cuándo no. Es importante porque no podemos seguir señalando a los desarrolladores por cada ataque exitoso. La seguridad requiere un pensamiento a nivel de sistema; necesitamos múltiples soluciones porque hay muchos tipos de ataques contra los que debemos defendernos.

Es importante diferenciar para poder defenderse de manera eficaz y exitosa contra la variedad de ataques a los que estarán sujetas la mayoría de las organizaciones en el futuro cercano. No pierda el tiempo intentando obligar a los desarrolladores a defenderse de ataques cuando (1) no es un exploit debido a una codificación insegura o (2) no es posible debido a una falta de visibilidad.

Necesitamos abordar la seguridad estratégicamente desde un sistema de servicios que brinden la seguridad adecuada en los lugares adecuados, sin importar cuál sea la fuente o la superficie de ataque.

Mantenerse seguro.