Podcast -33 – OWASP

El tema del capítulo de hoy fue sugerido por nuestro compañero del grupo de Telegram Fran Andrades (@andradesfran en Twiter). Así que, a petición de los oyentes (al menos de uno), hoy hablaremos de OWASP.

OWASP logo

Logo OWASP. Fuente iamgen: OWASP.org

Empecemos por lo primero: OWASP son las siglas de Open Web Application Security Project, que se traduciría como Proyecto abierto de seguridad en aplicaciones web. Nació en 2001 y su misión es combatir las causas que hacen que el software sea inseguro. Para gestionar este proyecto se creó, ya en 2004, una entidad sin ánimo de lucro: la Fundación OWASP. Si bien dicha fundación es la responsable legal de la gestión del proyecto y de la infraestructura (tanto técnica como humana) necesaria para su funcionamiento, el trabajo es realizado por una comunidad de usuarios, organizaciones educativas y empresas que se coordinan en la denominada Comunidad OWASP.

Así pues, la Comunidad OWASP crea, adapta y traduce documentación, guías y consejos sobre el desarrollo de software seguro, que es la razón de ser del Proyecto, mientras que la Fundación se encarga de gestionar los trabajos administrativos y de infraestructura que permiten que todo funcione. Espero haber aclarado un poco qué hace quién 🙂

Los cuatro pilares del proyecto OWASP son:

  • Abierto: Todo el resultado de la gestión es público
  • Innovación: Se promulga la innovación y experimentación para buscar nuevas soluciones a los problemas del desarrollo seguro
  • Global: Cualquier persona puede participar
  • Integridad: La comunidad OWASP está formada por un gran número de personas y siempre propone soluciones independientes a cualquier fabricante garantizando así su independencia

OWASP busca como objetivo final el desarrollo seguro de aplicaciones, para lo cual desarrolla diferentes proyectos que buscan conseguir la seguridad en diferentes aspectos del desarrollo de aplicaciones web. Se han creado herramientas software que permiten detectar vulnerabilidades en el propio código (como WebScarab, DotNet…), guías sobre cómo programar de forma segura y que comprobaciones hacer; se han creado plataformas de formación (como webGoat), pero el proyecto más conocido de OWASP es Top10: el documento donde se identifican y explican las 10 vulnerabilidades más críticas en las aplicaciones web.

El documento OWASP Top10, que nació en 2003, se actualiza y presenta cada 3 años. Top10 se ha convertido en un estándar de facto utilizado por los desarrolladores para determinar y combatir las causas del software inseguro.

Micro con feed

Fuente imagen:PerfectYourPodcast

Si bien las primeras versiones se daba prioridad a la prevalencia de las vulnerabilidades en 2010 se cambió el enfoque hacia la gestión de riesgos. La última actualización de Top10 aparece en 2017 y no en 2016 como era de esperar ya que se decidió realizar un cambio profundo en los procedimientos de elaboración de dicho documento y en la forma de recolectar la información de múltiples fuentes (voluntarios, empresas, entidades de seguridad oficiales…). Igualmente se ha cambiado el método de clasificación de las vulnerabilidades, por lo que no todas las categorías coinciden con la de los años anteriores.

Veamos pues un resumen del listado de las 10 vulnerabilidades más críticas en las aplicaciones web:

  1. En primera posición desde 2010 (en 2007 estaba en segunda posición) se encuentra la vulnerabilidades por inyección de comandos. En los capítulos decimoséptimo y decimoctavo ya hablamos sobre las inyecciones SQL, si bien esta categoría no se limita únicamente a este lenguaje. La vulnerabilidad aparece cuando no se analiza correctamente la información recibida por la aplicación y permite la ejecución de código no deseado.

  2. Las implementaciones incorrectas o incompletas de las funciones de autenticación y gestión de sesiones son las causantes de que en segundo lugar del Top10 tengamos la categoría Pérdida de autenticación. En este caso el riesgo principal es la suplantación de identidad de otro usuario al comprometerse contraseñas, tokens de usuarios o sistemas de recuperación de sesiones.

  3. Si bien en el documento de 2013 la Exposición de datos sensibles se encontraba en sexta posición en la última versión sube hasta la tercera. La gran difusión de aplicaciones web que hacen uso de datos sensibles, hace que la no protección adecuada de esta información se convierta en uno de los riesgos más críticos. Los sistemas web deben asegurar que esta información sensible esté siempre cifrada tanto en almacenamiento como en transmisión.

  4. En cuarta posición aparece una nueva vulnerabilidad: La gestión de Entidades Externas XML. Al parecer mucho procesadores XML antiguos permiten, de forma predeterminada, la llamada a funciones externas, así un atacante malicioso sólo debe enviar un fichero XML que haga referencia a una URL maliciosa para conseguir su ejecución en el servidor.

  5. La categoría de Pérdida de control de acceso incluye todas las ocasiones en las que las restricciones a los usuarios autenticados no se aplican correctamente. Así un usuario podría llegar a ver o modificar información de otros, cambiar permisos de accesos, etc. Si en la posición dos nos centrábamos en debilidades en el acceso al sistema, aquí estaríamos hablando de las funcionalidades disponibles dentro del sistema.

  6. Las aplicaciones web pueden ser vulnerables no por fallos en la programación sino por una Configuración de seguridad incorrecta. La falta de securización de la infraestructura; la permanencia de servicios no necesarios; la no actualización de versiones de aplicaciones vulnerables; o no cambiar las contraseñas por defecto son ejemplos de vulnerabilidades dentro de esta categoría.

  7. En séptima posición nos encontramos las vulnerabilidades de Cross Site Scripting. Esto sucede cuando una aplicación toma datos no confiables y los entrega al navegador del usuario para que los ejecute. Así se permite la ejecución de comandos en el navegador de la víctima pudiendo modificar sitios web, redirigir al usuario a sitios maliciosos o secuestrar una sesión.

  8. Cuando una aplicación debe convertir diferentes objetos de un formato a otro (p.e. de XML a JSON), debe estar preparada para tratar correctamente objetos manipulados, desordenados o repetidos para evitar caer en la deserialización insegura. Este tipo de ataques suelen buscar una ejecución de código en el servidor o la elevación de privilegios.

  9. Teniendo en cuenta que muchos componentes (como bibliotecas, módulos o frameworks) se ejecutan con los mismos permisos que la aplicación a la que sirven, si estos elementos resultan ser vulnerables afectarán directamente a la seguridad de la aplicación. Así pues el uso de componentes con vulnerabilidades conocidas puede debilitar las defensas de las propias aplicaciones.

  10. En la posición 10 se propone una de las vulnerabilidades más comentadas: el registro y monitoreo insuficiente. Los últimos estudios demuestran que el tiempo de detección de una brecha de seguridad es de cerca de 200 días y que generalmente son detectados por terceros y no por los propios sistemas internos. Uno de los motivos de esta alta permanencia de los ataques es la falta de un registro de acciones completo y una revisión y monitorización insuficiente.

Logo TOP10

OWASP Top10 2017. Fuente imagen: Dragonjar

Tras repasar el nuevo Top10 se puede ver que los cambios en la metodología de trabajo y toma de decisiones ha llevado a situaciones no acostumbradas: Por ejemplo podemos ver en la cuarta posición una vulnerabilidad por el uso de procesadores XML antiguos o malconfigurados; mientras que la vulnerabilidad de uso de configuraciones de seguridad incorrectas (más genérica que la específica de XML) se encuentra en sexta posición. Aunque inicialmente puede chocar esta clasificación los autores proponen destacar específicamente la vulnerabilidad de procesadores XML mal configurados por su especial ocurrencia frente a otros sistemas mal configurados. Se busca así destacar un problema específico con la intención de que sea corregido más rápidamente que si simplemente estuviera englobado en la problemática más general.

Igualmente la introducción del monitoreo insuficiente como una vulnerabilidad del Top10, aunque en última posición, genera algunas dudas ya que puede deducirse que no es una vulnerabilidad de las aplicaciones web en sí, sino más bien del entorno de gestión y administración de sistemas.

Aún con todas estas dudas sobre categorías específicas, OWASP Top10 es un estándar de facto para que los desarrolladores de aplicaciones web puedan determinar y combatir las causas que hace que sus aplicaciones sean inseguras.

Si quieres participar en la Comunidad OWASP y ayudar en cualquiera de sus proyectos, sólo debes solicitar una cuenta en www.owasp.org. Si no eres un gran programador siempre puedes ayudar con traducciones, guías de estilo, revisiones de documentos, etc.

Descarga directa.

Podcast – 32 – Protección ante ataques DDoS

Bienvenidos al trigésimo-segundo capítulo del podcast de seguridad informática “Securizando.com”

Soy Andreu Adrover y hoy es viernes 19 de enero de 2018.

Aunque la idea inicial de este capítulo era ser la continuación del podcast 31 y hablar sobre las defensas específicas para los ataques DDoS vía el protocolo HTTP, creo que lo preferible será hacer un capítulo explicando las defensas generales que podemos activar ante ataques DDoS para posteriormente ya centrarme, en otro capítulo, en las técnicas de defensa específicas de HTTP, DNS y demás protocolos. Así pues hoy hablaremos de técnicas genéricas de defensa frente ataques de denegación de servicio. Hay que tener en cuenta que todas estas técnicas (y cualquier en la seguridad informática en general) requieren de una preparación previa: improvisar durante un incidente (un ataque de denegación en este caso) suele ser la receta perfecta para liar más la situación.

  1. Capacidad de crecimiento

    Con el desarrollo de los entornos virtuales las posibilidades de adaptación de los sistemas a los requerimientos de los usuarios se ha visto potenciada. Ahora es normal que las aplicaciones modifiquen sus capacidades en función de la necesidad y del coste asociado: ya no es extraño que durante las horas valle de uso se reduzca el número de servidores mientras que en las horas punta la capacidad del sistema aumente. El hecho de que los entornos virtuales en la nube tenga un coste por uso, ha fomentando en gran medida esta variabilidad del entorno.

    1. Número servidores (crecimiento horizontal)

      Actualmente, la primera opción que nos suele venir a la cabeza en caso de necesitar tratar más conexiones de las habituales es ampliar el número de servidores. Los sistemas virtuales permiten añadir nuevos servidores a la granja de forma rápida y relativamente sencilla. Aumentando el número de servidores se consigue dar servicio a más conexiones, aunque como todo en la vida, siempre hay un límite que no podremos superar (capacidad de transacciones de la base de datos, capacidad de escritora en discos, capacidad de ancho de banda, etc…). Esta crecimiento se denomina horizontal ya que lo que se hace ganar capacidades añadiendo nuevos servidores a la granja y es ampliamente utilizada en las aplicaciones web o distribuidas.

    2. Capacidad sistema (crecimiento vertical)

      En contraposición al sistema anterior, el crecimiento vertical consiste en aumentar la capacidad de los propios nodos del sistema: aumentar la memoria o velocidad de CPU, aumentar la capacidad de disco (ya sea ampliando los filesystems o creando nuevos). Esta estrategia suele tener un mayor coste de aplicación (muchas veces implica reiniciar el servidor para que el sistema operativo tome en cuenta las nuevas capacidades). Así pues se trata de una estrategia más pesada, pero que sería necesaria cuando el cuello de botella se encuentra en sistemas únicos (bases de datos, aplicaciones mainframe, etc.).

    3. Capacidad línea comunicaciones

      Otro punto donde un ataque de denegación de servicio suele ser las propias líneas de comunicaciones. Así aunque el servicio esté operativo si los clientes no pueden llegar a él ya se ha conseguido la denegación de servicio. En los grandes servicios en la nube (AKAMAI, Amazon, Azure, etc.) es un punto que ya está resuelto en su infraestructura propia, pero para aquellos servicios de hosting más pequeños es algo a tener en cuenta. Para aquellas empresas que tienen sus servicios alojados en su propio centro, las operadoras ofrecen líneas de comunicaciones con diferentes capacidades de crecimiento que hay que evaluar: no es extraño contratar una línea de fibra óptica con capacidad de de 1Gbps pero de los que se usan (y pagan) 400Mbps. Así en caso de problemas, simplemente se amplía la capacidad de la línea. Obviamente esta ampliación rápida debe estar acordada previamente con la operadora (cómo se solicita la ampliación, quién está autorizado a solicitarla, y cómo se pagará después ;))

  2. Sistemas IPS – WAF

    Como ya vimos en los capítulos 4 y 29 los sistemas IPS y WAF permiten detectar y bloquear tráfico anómalo mediante el análisis del tráfico que pasa por sus interfaces. Las firmas de detección pueden ser múltiples y dependerán del protocolo utilizado para el ataque: por ejemplo si suponemos un ataque web donde se envía a través de formulario un archivo adjunto grande para saturar las capacidades del sistema, un WAF podría detectar que los usuarios no han seguido el camino normal (acceso a portada, clic en opción de envío, etc.) y que sólo envían directamente el formulario. En este caso el sistema podría descartar el tráfico que no haya seguido el cauce habitual con lo que se descartarían los ataques con mínima afectación a los usuarios habituales.

  3. Listas negras (Direcciones IP de botnet, nodos Tor…)

    Actualmente muchos proveedores de sistemas de seguridad mantienen una serie de listas con direcciones IP de baja o mala reputación que pueden utilizarse para descartar tráfico proveniente de ellas. Estas listas de direcciones IP incluyen equipos que se ha descubierto que pertenece a una botnet (y por ello es probable que en caso de ataque de denegación de servicio sean una de las causantes), que han sido utilizadas en ataques previos o, por ejemplo que son nodos de salida de la red Tor. La red Tor no es intrísicamente maliciosa, pero hay que entender que utilizar este servicio de anonimato para acceder a una aplicación web que debe autenticarse (pago con tarjeta, acceso mediante usuario/contraseña…) no parece una opción muy lógica. Así pues si estamos ante un ataque de denegación de servicio una opción rápida es bloquear el tráfico proveniente de estas direcciones IP de dudosa reputación. Es posible que perdamos algún cliente (porque desconoce que sus equipos formen parte de una botnet), así que no siempre es aconsejable tener estos filtros activados siempre.

  4. Bloqueo por ubicación geográfica

    Los rangos de direcciones IP son asignados por la IANA (Internet Assigned Numbers Authority), en base a unos cálculos de necesidades previstas, de forma distribuida por países. Así pues es posible conocer el supuesto país de origen de una conexión por Internet por esta asociación. Si bien hay un cierto mercadeo de direcciones donde una empresa multinacional compra direcciones de un país donde tengan libres (actualmente principalmente de países africanos) para luego utilizarlas en otras ubicaciones, esta ubicación geográfica es aún bastante correcta.

    Por ello una posible estrategia en caso de sufrir un ataque de denegación de servicio sería bloquear el tráfico proveniente de países donde nuestra empresa no tenga mercado. Por ejemplo si nuestra empresa alquila coches en España es poco probable que nuestro servicio reciba demasiadas peticiones legítimas desde Laos o Tanzania, mientras que sí es muy probable que reciba peticiones desde los principales clientes turísticos (Alemania, Reino Unido…). En cambio si nuestra empresa se dedica al transporte internacional por carretera no será extraño recibir peticiones desde Polonia o Ucrania. En caso de ataque el hecho de descartar todo el tráfico salvo el que provenga de los principales mercados de nuestra empresa mitigará en gran medida el ataque con una afectación mínima a nuestros principales clientes.

  5. Modificación parámetros de protocolos

    Casi los primeros ataques de denegación de servicio que aparecieron tratan de aprovechar los tiempos de espera entre transacciones definidos en los distintos protocolos. Así cuando, por ejemplo, establecemos una conexión TCP (que son necesarias para la mayoría de protocolos usados para navegar, enviar correos electrónicos, etc.), los estándares indican un tiempo máximo en la negociación de dicha conexión. Un usuario malicioso pueden intentar alargar al máximo el tiempo de envío entre paquetes para asegurar así que el receptor reserva durante el máximo tiempo posible sus capacidades (espacio de memoria, tiempo procesador…). Igualmente puede iniciar una conexión pero sin finalizar el proceso de establecimiento por lo que nuestro servidor se quedaría a la escucha (usando recursos) para, pasado el tiempo, descartar ese paquete inicial. Una estrategia para liberar recursos rápidamente es acortar estos tiempos de espera y descartar tráfico posiblemente malicioso antes, de tal forma que se pueda seguir recibiendo nuevas peticiones. Igualmente el sistema podría simplemente descartar paquetes malformados, con errores de transmisión, con un excesivo desorden, etc. en vez de solicitar retransmisiones, evitando así tener que realizar reservas de recursos.

    Actualmente estos ataques no suelen verse de forma independiente sino que suelen acompañar a otros ataques usando protocolos de mayor nivel, pero aún así el hecho de mitigarlos permite a la infraestructura liberar recursos más rápidamente.

    Aunque como teleco ‘me duela’ romper los estándares, hay que tener en cuenta que se trataría de una medida de mitigación de un ataque. El hecho de reducir estos tiempo podría influir negativamente a nuestros clientes con menores capacidades (ancho de banda más limitado, etc.) pero claro, ante un ataque de denegación de servicio hay que elegir el mal menor.

  6. Servicios anti DDoS:

    Actualmente se pueden contratar servicios “en la nube” que mitiguen estos ataques de denegación de servicio gracias a sus mayores capacidades. En este punto existen dos enfoques principales: tener el servicio activo siempre de forma que todo el tráfico pasa por los sistemas del proveedor o bien activarlo únicamente en caso de necesidad. Por obvios motivos esta activación según necesidad requiere de una planificación y acuerdo previo, ya que no se puede improvisar sobre la marcha durante un ataque (aunque los comerciales de estas empresas estarán encantados de decirte que sí que es posible).

    Aunque más adelante le dedicaremos un capítulo a qué ofrecen estos servicios, cómo funcionan, cómo puede realizarse la derivación del tráfico, etc. podemos resumir su función como una de estas dos opciones:

    1. Filtrado de paquetes (firewall): permiten que sólo el tráfico del protocolo elegido llegue a nuestros servidores. Así nuestra infraestructura no recibe los ataques siplementarios (tráfico UDP, inundaciones SYN, malformación de paquetes, etc.).

    2. Actúan como proxy: Los clientes se conectan a su infraestructura y es ésta la que se conecta a nuestros servidores. Así todas aquellas conexiones fraudulentas son descartadas por el proveedor y no llegan a nuestros servidores (evitando la denegación de servicio).

Micro con feed

Fuente imagen: PerfectYourPodcast

Como podéis observar muchas de estas protecciones (tener capacidades de crecimiento no usadas, contratar los servicios de anti-DDoS, mantenimiento de sistemas IPS o WAF,…) implican un coste económico, por lo que una empresa debe evaluar hasta que punto quiere llevar la protección de sus sistemas. Teniendo en cuenta que por temas legales hay una serie de sistemas defensivos que deben estar activos, desde el punto de vista económico hay que evaluar los riesgos y actuar en consecuencia: no sería lógico gastarse miles de euros al mes en un sistema para defender una pequeña tienda de camisetas online cuya caída durante un día completo implique unas pérdidas menores al coste del sistema de defensa. Las grandes empresas deben tener en cuenta los costes intangibles (daño a la imagen de marca, cumplimiento de SLA con proveedores, etc.).

Descarga directa.

Podcast – 31 – Denegación de servicio vía HTTP

En el capítulo de hoy hablaremos de las diferentes maneras en la que se puede producir un ataque de denegación de servicio a una página o servicio web usando el propio protocolo HTTP/HTTPS. Aunque es muy probable que en un ataque real se utilicen diferentes técnicas de forma simultánea, incluyendo diferentes protocolos con el objetivo de evitar las diferentes medidas de protección, en este capítulo hablaremos de un ataque puramente web.

Micro con feed

Fuente imagen:PerfectYourPodcast

Empecemos por las bases. El protocolo HTTP (HyperText Transfer Protocol) tiene tres métodos de solicitud de información en las peticiones del cliente al servidor:

  1. El método HEAD (cabecera) sirve para el cliente solicite información básica sobre una web en concreto, pero no la página en sí. Se pensó en una época de recursos muy limitados para que el cliente supiera a qué atenerse (tamaño, velocidad, etc.) antes de descargar realmente el contenido. Hoy en día es el método menos usado. Tanto las peticiones como las respuestas son ligeras.
  2. El método GET es el más habitual en la navegación: el cliente solicita un recurso y el servidor se lo entrega. El cliente envía una petición pequeña (tan sólo una cadena de texto con el URI del recurso que solicita) mientras que el servidor puede enviar una gran cantidad de información (texto HTML, imágenes. audios o incluso vídeos). La aparición de las aplicaciones web dinámicas ha hecho que en las URL de las peticiones se puedan añadir variables y parámetros que el servidor debe analizar y gestionar para modificar su respuesta en función de estos. Así nos encontramos con una petición ligera, pero con una respuesta por parte del servidor que puede, o no, ser muy pesada (tanto por tamaño de la información como por los recursos de memoria y cálculo necesarios para generarla). Se trata del método de petición más habitual.
  3. El método POST permite el envío de información desde el cliente al servidor. Sería el método utilizado para enviar la información rellenada en un formulario hacia el servidor: un ejemplo sería que al escribir un comentario en un blog el texto es enviado mediante este tipo de petición a una dirección concreta del blog para que lo trate. Lo mismo pasa cuando adjuntamos un archivo a nuestro webcorreo: el archivo adjunto viaja en una petición POST desde nuestro navegador al servidor web. En esta comunicación nos encontramos con una petición que puede ser pesada (dependerá de la información que queramos enviar) y cuya respuesta directa suele ser ligera (una confirmación de la recepción) pero que puede implicar un procesamiento elevado en la parte del servidor (pensad en los conversores de formatos de audio, vídeo, etc. que hay en Internet).

Tras este rápido repaso a los métodos de petición definidos en el protocolo HTTP y, teniendo en cuenta que lo que queremos es saturar una aplicación web de tal forma que la dejemos inaccesible de cara a los usuarios legítimos veremos qué tipos de ataques de denegación de servicio, puramente web, podemos realizar.

Tipos de ataques de denegación de servicio usando HTTP

Saturación de su línea de datos

Se trataría del ataque de denegación de servicio más tradicional y que requiere menos conocimientos técnicos.
Uno de los recursos limitados que tiene cualquier servicio web es su ancho de banda disponible para sus usuarios. Cualquier petición debe llegar desde los clientes hasta los servidores web utilizando una línea de comunicaciones, por lo que el envío de peticiones HTTP de gran tamaño o bien que generen un gran tamaño en su respuesta puede hacer que el servicio quede inaccesible.
Tradicionalmente se solía lanzar múltiples conexiones de tipo POST con una gran cantidad de información de tal forma que se pudiera saturar la conexión a Internet de los servidores. Otra forma sería realizar peticiones GET a un recurso muy pesado (un vídeo, por ejemplo) de forma que se envié muchas veces llegando a saturar su propia línea.
Como veis se trata de conseguir atascar la conexión a Internet de la aplicación web a base de generar un gran volumen de tráfico. Las tecnologías “cloud” dificultan la posibilidad de saturación de un punto único por lo que son una gran defensa frente a este tipo de ataques de fuerza bruta. Los sistemas de caché permiten la distribución de elementos no dinámicos de forma eficiente y distribuida por lo que se reducirían las posibilidades de saturación.

Saturación de los servidores

Error de servidor no disponible.

Error de servidor no disponible. Fuente imagen: eHost.com

Cambiamos el enfoque a intentar dejar inoperativos los propios servidores web. Para ello intentaremos realizar peticiones, ya sean GET o POST, que impliquen una gran carga de trabajo en el servidor. Se trata de dejarlos sin memoria o capacidad de cálculo de forma que dejen de responder a peticiones legítimas. Probablemente el ejemplo que hemos indicado antes de los conversores de formato de audio online que hemos comentado antes sea perfecto para este punto: un atacante podría solicitar muchas veces la conversión de un audio muy largo (para maximizar el consumo de su petición) de tal forma que llegue a dejar sin recursos al sistema que se verá forzado a ignorar peticiones legítimas. Este tipo de ataque requiere un mínimo de análisis de la aplicación web a atacar para descubrir cuál sería el proceso que más consume y actuar sobre él.
El reparto de trabajo entre diferentes servidores web de una misma granja permite minimizar la exposición de este tipo de ataques (ya que al aumentar la capacidad de cálculo obliga al atacante a incrementar su esfuerzo) y hoy en día la capacidad de crecimiento dinámico, y automatizado, de las plataformas cloud dificultan seriamente este tipo de ataques, aunque el hecho de que luego haya que pagar al proveedor “cloud” por el número de servidores, memoria o CPU usadas puede hacer que el hecho de aguantar el ataque y dar servicio a sus clientes no sea económicamente rentable a corto plazo. Por esto generalmente las aplicaciones web tienen una capacidad de crecimiento limitadas.

Saturación de sus propias defensas

En este escenario buscaríamos que al activar las propias defensas antidenegación (anti-DDoS, IPS, etc.) se agravara el problema o, en el caso más elaborado, se enmascarase el verdadero ataque a la aplicación web. Los sistemas IPS que analizan el tráfico HTTP deben mantener una serie de sesiones para confirmar el correcto funcionamiento y la legitimidad del tráfico por lo que también son susceptibles de ser saturados. Cuando un IPS es saturado puede generar una sobrereacción que bloquee todo el tráfico web (consiguiendo una denegación de servicio autoinflingida) o bien activar un modo pasivo donde el sistema deja de analizar el tráfico al no poder gestionarlo. Si se llega a este segundo comportamiento un atacante malicioso podría utilizar esta ventana para lanzar inyecciones SQL o exfiltrar información sin ser detectado entre todo el tráfico malicioso ‘común’. Este comportamiento puede agravarse si tratamos con tráfico seguro (HTTPS) donde el servidor IPS deba descifrar y recifrar el tráfico para poder analizarlo, consumiendo una mayor cantidad de recursos propios. Así pues, un correcto dimensionamiento de estos sistemas de defensa es muy importante.

Descarga directa.