En este artículo, el primero de tres, analizaremos las amenazas a la seguridad web y también hablaremos sobre cómo las herramientas de seguridad del lado del cliente manejan la clase de ataques cibernéticos que a menudo se pasa por alto, un ejemplo del cual es Magecart . Describe formas tradicionales de protección contra amenazas de seguridad web que se basan en estándares del lado del cliente, como las políticas de seguridad de contenido y la integridad de los recursos secundarios. Estos enfoques en evolución se ven en el contexto de una plataforma de seguridad representativa del lado del cliente.
Introducción
Quizás la piedra angular de la ciberseguridad como disciplina profesional es su continua variabilidad. Es decir, en cuanto surgen ciberataques que afectan aspectos de la confidencialidad, integridad o disponibilidad de algunos recursos de Internet, se desarrollan soluciones apropiadas para eliminarlos. Tan pronto como estas soluciones se integran en la infraestructura del recurso comprometido, aparecen nuevos ataques cibernéticos, se inventan nuevas soluciones y se cierra el ciclo.
En algunos casos, las soluciones de defensa cibernética tienen mecanismos que anticipan nuevas formas de ataques maliciosos, y cuando esto funciona, los riesgos de seguridad se pueden evitar en una variedad de escenarios. Por ejemplo, la autenticación de dos factores se creó como una medida contra la adivinación de la contraseña, y ahora es un componente importante para aumentar el nivel de seguridad en el desarrollo de nuevos protocolos de comunicación entre dispositivos de Internet de las cosas .
En ninguna parte es más evidente el proceso de amenazas emergentes y de superación que en el área de seguridad web, también llamada seguridad de aplicaciones web. Dado que los activos valiosos se procesan y gestionan con mayor frecuencia a través de interfaces web, el valor de los exploits web continúa creciendo. Una de las consecuencias de este crecimiento es que, a pesar de las numerosas tecnologías para proteger los recursos web, la brecha entre el número de ataques y el nivel de protección está creciendo.
La premisa principal para crear esta serie técnica de artículos es una brecha en el campo de la seguridad web, que aparece debido al hecho de que la mayoría de las aplicaciones se ejecutan en navegadores modernos. La comunidad de seguridad web reconoce desde hace tiempo la necesidad de implementar elementos funcionales para proteger contra vulnerabilidades del lado del servidor que distribuyen contenido estático y a los clientes. Sin embargo, se ha prestado muy poca atención a la seguridad del lado del cliente, que es igualmente atractiva para los atacantes pero que la infraestructura de seguridad actual ignora en gran medida.
En esta serie de tres partes, queremos cerrar esta brecha. En la primera parte, hablaremos sobre los ciberataques más comunes en los sitios web. En la segunda parte, consideraremos las soluciones de seguridad web que se implementan con mayor frecuencia en la producción actual. Y en la Parte 3, exploraremos cómo una solución de seguridad representativa del lado del cliente puede ayudar a encontrar vulnerabilidades en su infraestructura que podrían ser explotadas por los atacantes.
Ataques comunes a sitios web
A mediados de los 90 del siglo pasado, simultáneamente con las ideas de Tim Berners-Lee desde el nivel de los protocolos de transferencia de hipertexto y los lenguajes de marcado hasta el protocolo de Internet (IP), también hubo medios para atacar las infraestructuras, sistemas y aplicaciones que conforman la llamada red o red (web). Fue entonces cuando nació la disciplina de la seguridad web, que puede definirse como el conjunto de medidas de protección necesarias para gestionar los riesgos de seguridad de la informática en red.
Como es de esperar, la taxonomía de los problemas de seguridad web ha evolucionado rápidamente en diferentes direcciones, pero las primeras etapas se centraron en prevenir ataques de denegación de servicio, asegurar la infraestructura de alojamiento y garantizar el libre flujo de contenido web a los usuarios. Dicha atención a los problemas de accesibilidad fue dictada por el hecho de que si el sitio web no funciona o no funciona como debería, las transacciones electrónicas no podrán realizarse de manera segura, lo que tiene consecuencias obvias para obtener ganancias.
Además de los problemas a nivel de infraestructura, se ha desarrollado la consideración de que los problemas a nivel de aplicación también pueden tener serias consecuencias, en particular para los clientes que visitan un sitio web. Así nació el llamadoamenaza en el campo de la seguridad de la red , que ha evolucionado desde un pequeño problema a un gran problema de seguridad. Incluso hoy, encontrar una aplicación web vulnerable es bastante fácil.
En los últimos años, ha surgido un conjunto estándar de estrategias de ataque que son extremadamente difíciles de suprimir. La persistencia de estos problemas se debe a la complejidad del desarrollo de muchas aplicaciones web, así como a la relativa inexperiencia e ignorancia de muchos administradores de red. A continuación, describimos cuatro estrategias que generan vulnerabilidades en la infraestructura de comercio electrónico y crean problemas para muchas empresas y sus equipos de seguridad.
Cross Site Scripting (XSS)
El ataque de capa de aplicación más común es la secuencia de comandos entre sitios, o simplemente XSS . En esencia, un ataque entre sitios es una técnica llamada inyección, que es cuando un atacante encuentra la manera de inyectar un script de terceros en un sitio y hacerlo funcionar. El objetivo final es que la aplicación web de destino envíe el código del atacante al navegador del usuario sin el conocimiento de este último. Un ataque XSS funciona mejor cuando un sitio web acepta, procesa y consume datos sin mucha validación.
El objetivo final es inyectar código en el navegador de otra persona. Un usuario comprometido espera que todos los scripts entrantes sean seguros, ya que todo el contenido dinámico proviene de un sitio web visitado y supuestamente confiable. El navegador del usuario ejecutará este código, a menudo en JavaScript, exponiendo así información confidencial como tokens de sesión o cookies a un atacante. El código XSS también puede redirigir al usuario a un sitio infectado.
Figura 1. Diagrama de ataque XSS
Organizaciones como el Proyecto de seguridad de aplicaciones web abiertas ( OWASP)) ofrecen diversos medios de protección contra ataques XSS. Sus recomendaciones, muchas de las cuales aún son ignoradas por los profesionales, incluyen codificación significativa y procedimientos de administración web que mejoran el manejo de la entrada del usuario. La mayoría de ellos sugieren una mejor validación de entrada del lado del servidor, que es una medida de seguridad bienvenida y debería estar presente en cualquier ecosistema de red.
Inyección de contenido y publicidad.
En los últimos años, los ataques de contenido y de inyección de anuncios conocidos como malvertising se han vuelto cada vez más comunes . Sin embargo, esta tendencia no debería sorprender, dado el creciente ecosistema de la publicidad en línea como una fuerza impulsora para los negocios modernos. Según algunas estimaciones, el volumen de publicidad en línea actualmente alcanza los $ 100 mil millones. Los piratas informáticos y los delincuentes son conscientes de esta tendencia y aprovechan las vulnerabilidades disponibles.
El principio de funcionamiento del malvertisingSimilar a XSS: los atacantes encuentran una manera de inyectar su código en sitios web a través de redes publicitarias legítimas. El objetivo también es similar a XSS, ya que es redirigir a los visitantes de un sitio a otro sitio objetivo con código malicioso, que es el pilar de cualquier ataque, como, por ejemplo, el robo de credenciales.
Algunas personas hablan sobre el proceso de inyección como una descarga automática . Este término se refiere a un usuario que ve anuncios en un navegador con una vulnerabilidad (que, desafortunadamente, es un escenario muy común). Cuando un usuario interactúa con un anuncio, se produce una redirección, lo que hace que el malware llegue a un visitante desprevenido.
Figura 2. Descarga automática mediante Malvertising
La solución tradicional a este problema es usar un control como un firewall de aplicación web (WAF). WAF se configurará para usar firmas o análisis de comportamiento para evitar que el código malicioso se ejecute desde fuentes no confiables. Al igual que con XSS, esta protección del lado del servidor se usa comúnmente en los ecosistemas publicitarios como un elemento de control primario. El enfoque descrito es aplicable a la publicidad maliciosa , pero no funcionará contra todas las formas de ataques.
Carro de mago
El grupo de hackers Magecart surgió hace varios años, después de haber comenzado a aterrorizar a los sitios web con un ataque como el robo de tarjetas. Por lo general, los grupos de hackers aparecen y desaparecen con bastante rapidez, pero Magecart ha puesto nerviosos a los sitios web y las aplicaciones web de las compañías. Un gran número de organizaciones fueron pirateadas, y las soluciones de seguridad no eran obvias para la mayoría de las víctimas.
Ataque al hombre en el mediode Magicart es bastante simple: primero, el código malicioso se agrega al código JavaScript que se envía desde el servidor al cliente. Luego, el código malicioso rastrea y recopila datos confidenciales, como información sobre las tarjetas de crédito de los usuarios que acceden al sitio a través de su navegador. Los datos se envían a un sitio malicioso y se cargan ilegalmente. Todo es muy simple.
Figura 3. Tarjetas de descremado de Magicart
Sin embargo, el problema principal es que la seguridad convencional del lado del servidor no tiene en cuenta un ataque de hombre en el navegador ( MITB ) como ocurre en el lado del cliente. Por ejemplo, firewalls de aplicaciones web ( WAF) no veo acciones de JavaScript y no tengo herramientas de escaneo de biblioteca para inyecciones de código. Cuando el ataque proviene de sitios de terceros, el resultado es en cascada, y lo que sucede se llama respaldo .
Aprende más sobre el curso.