HackedGPT: Cómo explotar "Weaknesses" en ChatGPT para hacer Phishing o Exfiltrar Datos

Esta semana el equipo de Tenable ha publicado un artículo llamado "HackedGPT: Novel AI Vulnerabilities Open the Door for Private Data Leakage" donde se detallan una serie de "Weaknesses" o debilidades de seguridad de la implementación de los servicios de ChatGPT que, unidas a las debilidades por diseño de los LLM de las que tanto hemos hablado, dan como resultado una serie de escenarios de ataques bastante curiosos. 

Figura 1: HackedGPT: Cómo explotar "Weaknesses" en ChatGPT

para hacer Phishing o Exfiltrar datos

A esta investigación, llamada HackedGPT, hay que sumar todas las que se van publicando diariamente, donde, os garantizo, que me cuesta seguir el ritmo de publicación de todas ellas, a pesar de que todas las semanas caen dos o tres artículos dedicados a ellas, porque el mundo del Hacking & Pentesting con Inteligencia Artificial se está convirtiendo en un todo en la profesión de ciberseguridad, y ya he compilado en mi blog más de 300 referencias a artículos, blog posts, libros y charlas dedicadas a este tema.

Figura 2: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso, 

En el caso de HackedGPT, los investigadores comienzan publicando las debilidades. Estas deben ser tenidas en cuenta sabiendo que los modelos LLM no tienen protección por diseño contra Prompt Injection, Jailbreak, Hallucinations o Un-Aligment, por lo que basta con encontrar las protecciones de la implementaciones y saltárselas para crear un escenario de ataque.

Figura 3: Memory, Conversation, LLM, SearchGPT y Browsing

La más evidente es la se conseguir que el punto de entrada para un inyección de Prompt Injection esté en una web, así que para eso primero la investigación analiza la arquitectura de ChatGPT donde cómo se puede ver tenemos varias herramientas, como son la Memory o Bio Tool, la Conversación con sus Prompts, el core LLM del modelo controlado por su System Prompt, la herramienta de búsqueda SearchGPT Tool, y la de Navegación y lectura de webs o Browsing Tool.

Figura 4: Leaked System Prompt de GPT5

Si miramos en el System Prompt de ChatGPT con GPT5 que fue publicado en Agosto de este año, podéis ver cómo están definidas estas herramientas,  y cada una de ellas lleva una serie de mitigaciones, basadas muchas de ellas en la reputación del sitio, por lo que los investigadores van a tener que ir saltándoselas usando estas debilidades.

Figura 5: Prompt de ataque en una web

Meter un Prompt en la sesión de la víctima tiene un primer punto que es la opción de usar la Browsing Tool en un dominio pedido por el usuario donde se oculta un Prompt de Ataque en el contenido o en los comentarios, consiguiendo, como se ve en la imagen anterior que pedir el resumen de un sitio ejecute el Prompt del atacante.

Figura 6: Indirect Prompt Injection via Blog & Comments

Este Prompt Injection se puede utilizar para envenenar el contexto de la Bio, haciendo que guarde información en la Memory para que haga lo que el atacante quiera. En este caso, se pide que guarde en la Memory que quiere que se usen Emojis.

Figura 7: El Prompt de Ataque envenena el contexto de la Memory

Y como vemos, cuando este contexto se utiliza con la Browsing Tool, vemos la respuesta con Emojis. En la primera respuesta no los usa porque está tirando de los datos de entrenamiento del modelo, por lo que no está pasando por la SearchGPT Tool ni la Browsing Tool donde está usando ese Contexto para generar la respuesta.

Figura 8: Emojis como parte del envenenamiento de la Memory

La arquitectura es tan simple como la que podéis ver en el diagrama siguiente, donde con generar el contenido con el Prompt, y forzar que venga  la Tool de SearchGPT, y genere una Memory con el ataque de Conversación que se quiera. 

Figura 9: Arquitectura del proceso

Y el resultado lo tienes en el siguiente ejemplo, donde se puede ver que está haciendo lo que se le pide en la web que podéis ver en la captura.

Figura 10: Ejemplo de envenenamiento de conversación

Además de poder hacer el Indirect Prompt Injection a través de una web que es invocada por la víctima, también se puede crear el Prompt en una Web que sea indexada por Bing, que es el buscador de referencia que está usando OpenAI para la Search Tool, así que si se genera un dominio con contenido y se indexa con Bing, los datos llegarán a la víctima vía Search con un enlace al sitio.

Figura 11: Contenido envenenado vía Search Tool con Bing

Lo que se ve en la Figura 11 es relevante, pues los usuarios no "buscan contenido en Internet", sino que "buscan respuestas en los modelos de IA", y por supuesto esto esto no tiene porque ser así, ya que se puede envenenar fácilmente una repuesta vía una web indexada por Bing.

Figura 12: Static Links en Bing

El caso de Bing es bastante curioso porque siempre pasa el control de seguridad de URL_safe que hace ChatGPT antes de navegar a ella. Para exfiltrar información, hay que conseguir que envíe datos en la URL, pero no es posible con las URLs de BING, así que los investigadores hicieron dos cosas. La primera indexaron webs en Bing y descubrieron que existe una URL estática para redirección a cada web, con lo que se pueden usar esos enlaces para saber a qué página navegan. 

Después, crearon un enlace para cada letra del abecedario, de tal manera que si quieres que se exfiltre la letra "A", haces navegar a SearchGPT a la URL estática de BING que representa la "A", y lo mismo para el resto de las letras. Muy interesante.

Figura 13: No hay protección para CSRF

Las últimas dos debilidades para aprovecharlas en ataques se basan en que la URL de ChatGPT lleva el Prompt a ejecutar, así que si le pasas un enlace malicioso a una víctima, y está hace clic en él, puede acabar ejecutando el Prompt que tú quieras.

Figura 14: Hacking Web Applications: Client-Side Attacks
de Enrique Rando en 0xWord

La última es que, usando este truco de links, se puede generar cualquier respuesta en formato Markdown, con lo que se pueden inyectar respuestas como códigos o textos creados por el motor de ChatGPT en un Client-Side Attack.

Figura 15: Respuesta inyectada en Markdown

Todo esto lo podéis ver en los siguientes PoC publicados en la investigación de HackedGPT, donde por ejemplo un comentario en una Web que es resumida por ChatGPT con GPT4o acaba generando un enlace seguro a Bing que lleva a una web de Phishing. 

Figura 16: PoC 1 en ChatGPT4 - Phishing con las debilidades descritas

En esta siguiente PoC en ChatGPT con GPT5 vemos como la víctima pide visitar una web desde su cliente de ChatGPT al que está llamando TEN. Cuando visita esa web el atacante ha inyectado un Prompt malicioso en un comentario que usando la posibilidad de escribir código en Markdown, y de poder forzar a navegar a diferentes sitios con los enlaces estáticos de Bing, es capaz de exfiltrar el nombre configurado en el cliente. Chulísimo.

Figura 17: Exfiltración de datos con static links de Bing

En esta tercera PoC lo que los atacantes hacen es indexar una Web en Bing, y luego cuando llegue el módulo de SearchGPT a la web, usando "Cloacking" detectan el USER-Angent y le inyectan el Prompt malicioso a ejecutar.

Figura 18: PoC de Cloacking con indexación en Bing

con ChatGPT usando GPT4o

Y aquí la misma PoC con GPT5 donde se puede ver que el contenido que muestra ChatGPT en la respuesta no está en la web, ya que se ha hecho "Cloacking" por USER-Agent para que sólo lo vea SearchGPT  - y por lo tanto solo los que accedan al contenido vía ChatGPT -.

Figura 19: PoC de Cloacking con indexación en Bing

con ChatGPT usando GPT5

Y la última, que me he enganchado y no he podido parar de leerme la investigación y escribir este artículo hasta el final. En este caso se visita una web, y se inyecta un Prompt malicioso en la Memory para que exfiltre el nombre que se le ha guardado usando enlaces estáticos de BING. Perfecto.

Figura 20: Exfiltración con Evenenamiento de Memory

Estamos en un mundo donde la seguridad de estas tecnologías aún está muy en entredicho. Da un poco de miedito. Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

ChatGPT Atlas: Client-Side Attack CSRF para Contaminar la Memoria con un Prompt Injection que te hackea tu Windows con Vibe Coding

Parece que no hay un día sin un Prompt Injection explotado en un Agentic AI o en un AI-First Web Browser, y la verdad es que tengo que buscar huecos para publicar otros temas en mi blog, porque a la velocidad que son descubiertos dan un poco de miedo. En este caso un ataque de CSRF sobre ChatGPT para "Contaminar" la Memory de la sesión y ejecutar un Prompt Injection que ataque al usuario. Mola todo.

Figura 1: ChatGPT Atlas: Client-Side Attack CSRF para Contaminar la Memoria

con un Prompt Injection que te hackea tu Windows con Vibe Coding

El ataque ha sido publicado por los investigadores de LayerX y lo tienes publicado en el artículo: "ChatGPT Tainted Memories: LayerX Discovers The First Vulnerability in OpenAI Atlas Browser, Allowing Injection of Malicious Instructions into ChatGPT". En él se explica cómo se enlazan varios pasos para conseguir el objetivo final, ejecutar código directamente en la máquina de la víctima.

Figura 2: Un enlace en una web maliciosa con un CSRF y...

El ataque comienza con un ataque de ingeniería social, basado un Client Attack de Cross-Site Request Forgery (CSRF) que la víctima se encuentra en una web cualquiera, por ejemplo en un foro de Discord como podéis ver aquí en la demostración.

Figura 3: Hacking Web Applications: Client-Side Attacks
de Enrique Rando en 0xWord

Lo que hace ese enlace es "Contaminar" la Memory de ChatGPT con un Prompt malicioso, enviando información no protegida contra CSRF en el servidor, ya que la URL con la que se consigue la actualización de la Memory de ChatGPT es predecible (Recomiendo que te estudies el libro de Hacking Web Applications: Client-Side Attacks de Enrique Rando que lo explica de maravilla).

Figura 4: Arquitectura del ataque

Una vez que la Memory de ChatGPT ha sido contaminada, cuando el usuario ejecuta cualquier cosa en ChatGPT este Prompt Malicioso es ejecutado, llevando a que en la sesión del usuario, con sus credenciales se ejecuten los comandos que definió el atacante en el enlace.

Figura 5: El Vibe Coding generado por el Prompt Malicioso

La magia es que gracias al Vide Coding, el Prompt Injection puede crear un programa ejecutable en la máquina del cliente, por ejemplo para crear un script malicioso que ejecute programas, ponga música o abra fotografías. 

Figura 6: El ataque completo con el Prompt Malicioso

¿Cómo conseguir esto? Pues gracias a las capacidades de ChatGPT Atlas que permiten la ejecución de acciones en forma de script en el sistema donde están instalados para que el Agentic AI haga "cosas", como podéis ver en el siguiente vídeo publicado por los investigadores.

Figura 7: PoC Completa del "ChatGPT Tainted Memory" Attack

Una vez más, una forma sencilla e imaginativa de conectar los puntos para hacer Hacking & Pentesting con Inteligencia Artificial de una manera sencilla, en este caso, a víctimas elegidas del servicio de ChatGPT que explota una serie debilidades encadenadas para conseguir un ataque completo.

Figura 8: Hacking & Pentesting con Inteligencia Artificial.

En 0xWord, escrito por Pablo González, Fran Ramírez,

Rafael Troncoso, Javier del Pino y Chema Alonso, 

Al final, el ataque son unos segundos, y el Agentic AI hace todas estas acciones en nombre del usuario, así que si te roban cuentas de banco, cuentas de servicios digitales, redes sociales, etcétera, no vengas luego diciendo que tú no sabías, porque como os dije, queda claro en el disclaimer de ChatGPT Atlas.

Figura 9: ChatGPT Atlas Disclaimer en Español

Si quieres más ejemplos de esto, aquí tienes otros casos similares en AI First Web Browsers, Agentes AI en plataformas, y de grandes fabricantes de software:

• EchoLeak: Un Cross Prompt Injection Attack (XPIA) para Microsoft Office 365 Copilot
• Google Gemini para Gmail: Cross-Domain Prompt Injection Attack (XPIA) para hacer Phishing
• Hacking Gitlab Duo: Remote Prompt Injection, Malicious Prompt Smuggling, Client-Side Attacks & Private Code Stealing
• Hacking IA: Indirect Prompt Injection en Perplexity Comet
• ShadowLeak Attack para Agentes IA de Deep Research en ChatGPT
• ForcedLeak: Indired Prompt Injection en Salesforce AgentForce
• AgentFlayer exploit para ChatGPT: Prompt Injection para exfiltrar datos de tus almacenes conectados
• Indirect Prompt Injection en Perplexity Comet para atacar tu Stripe y el riesgo de los AI-First Web Browsers con ChatGPT Atlas
• Perplexity Comet: Indirect Prompt Injection con textos invisibles in imágenes

Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: +300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Safari Leaks: Apple Safari tiene un bug en IndexDB API que se salta Same-Origin Policy y deja tus datos de navegación abiertos a cualquier sitio web

La medida de seguridad de Same-Origin Policy en los sitios web hace que, los datos de un sitio que se almacenan en local en un navegador de Internet solo puedan ser accesibles por Scripts descargados desde URLs que están en el mismo dominio. Es decir, que están en el Same-Origin. Esto permite proteger cookies, información de Referer y datos cacheados en local. 

Figura 1: Apple Safari tiene un bug en IndexDB API que

se salta Same-Origin Policy y deja tus datos de

navegación abiertos a cualquier sitio web

Apple Safari, como todos los navegadores de Internet implementa esta medida de seguridad, que debe ser forzada por el navegador en todos los componentes para garantizar que no hay ninguna forma de acceder a datos que han sido definidos por un sitio web como accesibles solo para "Same-Origin". Esta es una de las principales medidas de seguridad que cualquier atacante debe saltarse en un Client-Side Attack, así que su impacto en la seguridad y privacidad de los usuarios en Internet es muy alta.

Figura 2: Libro de "Hacking Web Applications: Client-Side Attacks"
de Enrique Rando en la editorial 0xWord.

Pero como ha demostrado un investigador, una mala implementación del API de IndexDB en Apple Safari, se puede saber a qué sitios estás navegando en otras pestañas e información extra, como qué usuario de Google es el que has utilizado en local.

Figura 3: Demo en vídeo de Safari Leaks

La demo de Safari Leaks la puedes hacer tu mismo. Vete a la demo en una instancia nueva de Apple Safari y comienza a probarlo. Para ello, deja la pestaña de la demo abierta todo el tiempo.

Figura 4: Demo de Safari Leaks

Después, abre otra pestaña en la misma instancia de Apple Safari, abre la web de Youtube y no inicies sesión con tu usuario de Google.

Figura 5: Abrimos Youtube en otra pestaña

Vuelve a la pestaña de Apple Safari donde tienes abierta la demo y verás que esta pestaña, accediendo a la API de IndexDB local del navegador ya sabe que has navegado por Youtube, pero no sabe qué usuario estás utilizando.

Figura 6: Safari Leaks detecta que has ido a Youtube

Regresa a la pestaña de Youtube e inicia sesión con tu cuenta de Google, para que entres dentro de tu sesión en la plataforma de vídeos. Si vas luego a la pestaña de la demo, verás que no solo ha sido capaz de acceder a qué URL estás navegando sino con qué usuario lo estás haciendo.

Figura 7: Iniciamos sesión en Youtube

Esto permite a sitios que quieran espiar tu navegación para poder perfilarte mejor, saber qué te gusta, dónde tienes cuenta, cuál es tu usuario de Google, etcétera, espiarte desde una pestaña de otro navegador. Así que, cualquier script cargado en cualquier página podría sacar información personal de ti solo por usar Apple Safari. 

Figura 8: URL e ID del usuario de Google que usas

Apple debe arreglar esto lo más rápido que se pueda, así que por el momento, si no quieres que te espíen los datos de navegación, ten mucho cuidado por dónde navegas si lo haces con Apple Safari, porque esto abre infinidad de ataques efectivos de Client-Side. 

Figura 9: Repo de Github de Safari Leaks

Estas políticas de seguridad son mucho más importantes de lo que te imaginas y se usan en muchos rincones, como vimos en los plugins tiempo atrás, así que tómate en serio tener cuidado. Tienes el código de la demo en el repositorio de GitHub.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Algunos consejos de seguridad para desarrollar un frontend web (Y son muchos los que se necesitan)

El mundo de las aplicaciones web está en constante renovación, se desarrollan nuevos frameworks y herramientas, se implementan nuevos patrones arquitectónicos como los MicroFrontEnds, de los que hemos hablado en un artículo anterior. Además, el usuario está tomando una interacción mayor y más compleja con la parte frontal, esta complejidad puede llegar a suponer una brecha de seguridad si no se tiene el suficiente cuidado al desarrollar los proyectos.

Figura 1: Algunos consejos de seguridad para desarrollar un frontend web
(Y son muchos los que se necesitan)

En este artículo os hablaré de las distintas amenazas que se pueden dar en nuestra estructura frontal y de cómo prevenirlas. Es decir, vamos a ver un resumen de cuáles son las técnicas de Hacking Web Applications desde el punto de vista de los Client-Side Attacks: XSS, CSRF, SSRF, XSPA o SSJS - para lo que os recomiendo que leáis el libro de Enrique Rando - y también contaré algunos consejos para desarrollar FrontEnds de forma segura para evitarlos.

Figura 2: Libro de "Hacking Web Applications: Client-Side Attacks"
de Enrique Rando en la editorial 0xWord.

En primer lugar, para conocer los puntos débiles más comunes que se pueden dar en nuestra aplicación, debemos conocer los tipos de ataques que se realizan sobre estas y como prevenirlos.

Resumen ligero de Client-Side Attacks

- XSS Cross-Site Scripting: Es un vector de ataque dirigido a una aplicación web o página web que puede permitir a un atacante inyectar código sin que este sea validado y así, conseguir acceso a información sensible, secuestro de sesiones de usuario o subyugar la integridad del sistema. Gracias a ataques XSS se pueden hacer ataques de Session Hijacking, ataques de Click-Jacking, Cross-Site Request Forgery, etcétera, todos aprovechándose de la posibilidad de inyectar código que se va a ejecutar en el cliente. Si dejamos de lado los XSS Google-Persistentes, existen tres tipos de XSS.

Figura 3: Conferencia de "Ataques XSS Google Persistentes" por Chema Alonso

- XSS Directo: Es conocido como XSS Persistente, se da en los formularios y se ejecuta cuando un usuario accede a la ruta donde se ha inyectado el código. Estos XSS Persistentes o Stored-XSS son muy peligrosos y aparecen periódicamente en plataformas de eCommerce, CMS, LMS, etcétera, sobre todo en plugins.

Figura 4: Esquema de una ataque XSS Directo

- XSS Indirecto: Es conocido como XXS Reflejado, la inyección de código se da en formularios, URLs o vídeos, entre otros. Su objetivo radica en modificar los valores que la aplicación web utiliza para comunicarse a nivel interno con dos de sus rutas.

Figura 5: Esquema de una ataque XSS Indirecto o XSS Reflejado

 

Evidentemente, para prevenir estos dos tipos de ataques de Cross-Site Scripting, al igual que para prevenir cualquier tipo de ataque de inyección, como son también los ataque de SQL Injection, se debe aplicar un filtro para validar todos los campos que utilicemos como input, ya sean por GET o por POST.  Como dijo Michael Howard en su libro de Writing Secure Code:

"All input is evil until it proves otherwise"

Para evitar estos ataques es importante que tu servidor web también haga uso de los Security Headers para utilizar todas las capacidades de los navegadores de hoy en día en la fortificación contra ataques XSS, para ello hay que configurar:

- X-XSS-Protection

- Content-Type

- X-Content-Type-Options

- X-FrameOptions

- Acces-Control-Allow-Origin

Para verificar las políticas de fortificación de tu web, y cómo están configurados los HTTP Security Headers, puedes usar la web de SecurityHeaders.io que te dará un informe de cómo está de bien configurada tu aplicación web.

- XSS DOM Based: Este tipo de XSS, en vez de darse en la parte HTML se da en el Document Object Model. En los dos tipos anteriores el payload se puede observar en la respuesta de la página o ruta. Sin embargo, en este tipo de XSS el código HTML y la respuesta serán exactamente iguales. El payload solo se podrá observar en tiempo de ejecución o investigando el DOM de la página. 

Figura 6: Esquema de ataque XSS DOM-Based

Para evitar los ataques XSS DOM Based en nuestra aplicación es recomendable utilizar un método de salida adecuado. Es decir, imagina que quieres que el usuario escriba un input en una etiqueta <Div>. En este caso en vez de utilizar innerHTML, utiliza innerText o textContent. De esta forma el usuario puede ejecutar la misma acción, pero evitando una vulnerabilidad XSS DOM Based.

- Ataques DoS/DDoS: Uno de los ataques de XSS, además de los citados en los párrafos anteriores, se basa en la capacidad de forzar al navegador a pedir una determinada URL si somos capaces de inyectar código en la página de respuesta. Esto se puede utilizar para llevar a un cliente con un navegador vulnerable a una web con un Kit de Exploits en un ataque de Watering Hole, o para hacer un ataque de DoS (Denial of Service). 

En este último caso el objetivo es dejar sin recursos el servidor para evitar que los usuarios se conecten a este. Funciona sobrecargando el servidor con un gran número de peticiones en intervalos muy pequeños gracias a que muchos clientes le van a pedir recursos pesados de manera involuntaria desde sitios vulnerables a XSS.

Figura 7: Esquema de ataque DDoS. El atacante inyecta el XSS en el servidor web vulnerable y conecta los visitantes a su XSS-Botnet o JavaScript Botnet para hacer un DDoS. 

Estos ataques, cuando se basan en exploits XSS almacenados en sitios de gran cantidad de usuarios a los que se fuerza a pedir recursos pesados en el servidor de la víctima, da como consecuencia ataques DDoS (Distributed Denial of Service). Para el servidor atacado por las peticiones masivas es un problema, y por eso se utilizan soluciones como Cloudflare, AntiDDOS o captchas para proteger los recursos "pesados" para evitar estos ataques. Cada visitante del sitio con el exploit XSS se convierte en un bot de una XSS-Botnet, que funcionan de forma similar a las Javascript Botnets.

Figura 8: Owning bad guys {and mafia} with Javascript Botnets

- Ataques Cross-Site Request Forgery (CSRF): Este ataque se suele utilizar para realizar estafas. Consiste en intentar engañar a la víctima para envíe una solicitud HTTP maliciosa que el cliente no controla. Esto se puede hacer con un simple ataque de Phishing con un e-mail o haciendo un ataque de XSS. En cualquier caso, cuando esto ocurre, el atacante consigue que la víctima haga algo involuntario a ella en una plataforma a la que el atacante no tiene acceso.  Las posibilidades de estos ataques son muchas. Desde crearse un usuario, hasta borrar un contenido, forzar el cierre de sesión en una red social como Facebook o darse permisos desde la sesión de un administrador, o, como hemos visto muchas veces, conseguir votos involuntarios en concursos vulnerables a CSRF.

Figura 9: Esquema de ataque CSRF

La forma de prevenir un ataque CSRF es que la URL solo pueda ser llamada desde una web previa que tiene unos tokens que le autorizan como punto de llamada válido. Es decir, el servidor web protege la URL2 enviándole a la URL1 un token aleatorio Anti-CSRF. Cuando el usuario hace clic en un enlace de la web en la URL1 para navegar a la URL2 debe enviar los tokens AntiCSRF. La URL2 comprueba que son correctos y permite que se ejecute. Como el atacante no puede saber cuáles son los tokens AntiCSRF que genera el servidor web, entonces no puede hacer "a ciegas" que la víctima haga algo mediante una inyección de un exploit XSS o de un e-mail de phishing. 

Además de todo esto, hay que tener en cuenta que, al forzar una petición HTTP contra un servidor, se podrían enviar cookies asociadas en las peticiones HTTP al nuevo servidor, así que hay que fortificar las cookies para que el acceso solo sea Same-Site:Strict o Same-Site-Lax, como se explica en este artículo.

Algunos consejos para evitar los Client-Side Attacks

Ahora que ya hemos hablado de algunos de los tipos de vulnerabilidades y ataques más comunes, vamos a ver unos consejos importantes para tener en cuenta a la hora de realizar nuestro desarrollo. 

• Desarrollo Seguro: En primer lugar, desarrollar de forma segura siempre debe formar parte del proceso de desarrollo ya que solventar un problema de seguridad cuando una aplicación está desplegada, es mucho más costoso y dañino para el usuario final, que analizar el código y realizar los cambios a priori. Para ello, es mejor trabajar con patrones de diseños conocidos y estudiados que resuelven problemas concretos, en lugar de reinventar la rueda constantemente, y usar soluciones lo más estandarizadas posibles.

 

Figura 10: Desarrollo de WebApps Seguras con Angular y

Desarrollo de WebApps Seguras con Spring Boot

• Despliegue Seguro:No solo hay que hacer que la seguridad esté dentro del ciclo de vida de creación del software, así como en el despliegue de las nuevas releases, así que no solo la seguridad debe estar en el código, sino en los procesos de DevOps, pasando a ser SecDevOps.

Figura 11: Docker "SecDevOps"

• Fortificación: Las reglas de la fortiticación son Mínimo Privilegio Posible, Mínima Superficie de Exposición y Defensa en Profundidad. Si aplicamos la segunda regla al desarrollo de fontends de aplicaciones web, compartimentar una aplicación, puede ser una buena forma de mitigar el impacto de una vulnerabilidad por lo que se de be optar por patrones como los MicroFrontEnds como una alternativa.

• Contenido de Terceros Controlado: En caso de utilizar librerías de terceros, hemos de ser selectivos a la hora de elegir cual implementar ya que esto puede prevenir una o varias brechas de seguridad en nuestra aplicación. Se aconseja buscar librerías respaldadas por la comunidad y en las que se realice un mantenimiento habitual. También, si utilizamos recursos almacenados en servidores CDN, es muy recomendable utilizar el Tag Integrity que nos asegura la no alteración y la integridad del recurso que estamos utilizando. 

Figura 12: Ejemplo de uso de la Tag Integrity

• Librerías vulnerables: Auditar las dependencias de nuestros proyectos es una buena práctica. Con el comando npm audit se mostrará una lista de los paquetes vulnerables que existen en nuestro proyecto y podremos ver cual de estas dependencias requieren una actualización.

• Content Security Policies: Por último y no menos importante, recomendaros encarecidamente el uso de Content Security Policy. Es el nombre de la HTTP Header que utilizan los servidores web para sacar el máximo de partido de las opciones de fortificación que tienen los navegadores para mejorar la seguridad de una aplicación o página web.

Figura 13: CSP en la web de Facebook 

También se puede implementar vía meta tag. Las CSP suelen ser difíciles de configurar para que se ajusten a todos los comportamientos de todas las webapps en todos los navegadores, pero desde luego son la mejor opción para desplegar de forma fortificada una aplicación web, aunque sea en modo Reporting como hizo Google.

Figura 14: Etiqueta CSP como meta HTTP

Conclusiones

Fortificar una WebApp implica fortificar el end-point, así que desde el servidor web debemos utilizar todas las opciones no solo para fortificar nuestro código y las aplicaciones o frameworks server-side que utilicemos para soportar nuestra arquitectura, sino que deberemos también preocuparnos de todas las opciones de fortificación de los navegadores. Estos son solo algunos ejemplos de algunos ataques que se pueden dar client-side, y el número de cosas que hay que mirar en una aplicación web para tener la fortificación mejor posible es muy alta. 

Figura 15: XSS detectado por Faast de ElevenPaths en Apple.com

Como podéis ver, un XSS se le puede escapar hasta a la propia Apple en Apple.com. Por eso, se recomienda tener cualquier WebApp expuesta en Internet, bajo un servicio de Pentesting Persistente, como el que hacemos desde ElevenPaths con el servicio Faast, donde miramos constantemente no solo las vulnerabilidades, sino también las debilidades en la fortificación del servidor y el cliente. Recuerda, si tú no auditas tu web, otro lo hará por ti... gratis.

Autor: Luis E. Álvarez, desarrollador y miembro del equipo Ideas Locas CDCO de Telefónica.

Figura 16: Contactar con Luis Eduardo Álvarez en MyPublicInbox

Google Chrome forzará la política de SameSite=Lax para proteger tus cookies contra los ataques CSRF

Los ataques Client-Side en los navegadores de Internet han ido disminuyendo un poco, pero solo un poco, debido a la cantidad de mejoras de seguridad que se han ido añadiendo para fortificar el navegador. Por desgracia, no siempre son entendidas todas las protecciones por todos los arquitectos de sitios web, ni por supuesto son configuradas en todas las aplicaciones web que visitas. Un ejemplo de ello son las políticas CSP (Content Security Policies) que tan pocos sitios aún configuran, o la política SameSite que Google Chrome ha optado por forzar por defecto.

Figura 1: Google Chrome forzará la política de SameSite=Lax
para proteger tus cookies contra los ataques CSRF

Para entender su funcionamiento hay que ver cuál es el origen de dicha política de seguridad, entendiendo cuáles son los ataques que intentan bloquear. Para ello, la recomendación es que te leas y estudies en detalle el libro de Hacking Web Applications: Cliente-Side Attacks que explica en detalle ataques como XSS, CSRF, CSSP, SSRF, XSPA & SSJS que escribió Enrique Rando (y con el que también puedes contactar vía MyPublicInbox)

Figura 2: Libro de Hacking Web Applications: Client-Side Attacks

El ataque en concreto que busca mitigar el uso de la política SameSite es el de Cross-Site Request Forguery o XSRF, utilizado para forzar acciones en aplicaciones web hechas por usuarios sin que estos sean conscientes, como vimos en votaciones por Twitter donde gente se aprovechaba de este bug para conseguir mejor posición.

CSRF en un minuto

Supongamos que un usuario tiene abierta la página de su aplicación web para ver sus fotografías, donde puede gestionarlas con unos botones de acción que envían por GET la acción. Por ejemplo, para borrar la foto podía ser algo como.

https://www.miweb.com/gestionarfoto.PHP?id=111&accion=eliminar

Lógicamente, esta acción estaría protegida por una cookie de sesión, lo que hace que si alguien conoce ese enlace, pero no tiene iniciada una sesión válida en miweb.com no enviaría la cookie correcta al servidor y por tanto no se podría ejecutar.

Figura 3: Gmail fue afectado por ataques CSRF en sus inicios

Los ataques CSRF se basan en conseguir que sea la víctima del ataque con una sesión iniciada la que envíe esa petición. Para ello el atacante solo necesita saber cuál es la URL que desea ejecutar y hacérsela llegar a la víctima para que ella voluntariamente mediante un engaño haga clic en ese enlace o involuntariamente mediante una vulnerabilidad en cliente que permita forzar la navegación de la víctima a esa URL. Así de sencillo.

¿Cómo protegernos de los ataques CSRF?

Las aproximaciones para evitar este tipo de ataques han sido varias. Primero, poner el envío de acciones como estas en métodos GET no parece la mejor de las ideas. Al ser una URL toda la información GET queda registrada, así que las aplicaciones modernas utilizan más el método POST para evitar que sea tan fácil de capturar e invocar una acción con solo conocer una URL, eso quita gran cantidad de ataques XSS, que por otro lado son mitigados también con los filtros Anti-XSS en los navegadores.

La segunda de las opciones se basa en hacer que la URL por GET no sea tan predecible, para lo que se crean los tokens Anti-CSRF que se añaden en las páginas autorizadas para poner un enlace de este tipo. Es decir, imaginemos que tenemos una herramienta de administración que tiene un panel para pintar la opción de borrar la imagen. Antes de pintarse esa opción, se solicita desde la página web unos tokens Anti-CSRF al backend, y este los entrega a esa URL del panel. Si alguien quiere invocar la URL de borrar, tiene que conocer esos tokens. Si no, el backend lo desecha.

Figura 4: Ejemplo de token Anti-CSRF en OWASP

Es decir, en la petición POST, o en la GET si así fuera, se añaden los tokens CSRF y se evita que el atacante sea capaz de predecirlos. Por supuesto, es necesario que el backend los compruebe, porque hay muchas webs que los añaden pero no los comprueban en el servidor, lo que hace que poniendo cualquier valor, cuele.

La última protección es evitar que vaya la cookie de sesión pegada a la petición. Es decir, evitar que el navegador envíe la cookie de sesión autenticada al servidor si detecta cualquier problema. Y esto es lo que evita la política de SameSite.

Protección de cookies

Como sabéis, el servidor puede establecer que una cookie que él ha generado la entregue el navegador solo a un determinado dominio, a un determinado path, solo bajo métodos HTTP, y bajo conexiones seguras. Son los famosos flags HTTPOnly, Secure y Path. Esto haría que fuera mucho más difícil robar cookies en ataques de Session Hijacking usando JavaScript o suplantación de servidores en ataques de phishing.

Set-Cookie: Elladodelmal=1; Path=/; HTTPOnly; Secure;

Pero no evitan ningún ataque CSRF, en el que el problema es que la petición al backend se hace desde otra pestaña del navegador. Es decir, desde otro origen distinto al que tiene la sesión abierta. Para ello, se creo la política SameSite. Es decir, si la cookie no se ha creado en esa pestaña, a pesar de que se haga un POST al dominio que creo la cookie, el navegador no debería sacarla del Cookie Jar y enviarla. 

Para eso, en la creación de la cookie se añade la política SameSite y el nivel de restricción, que puede ser Strict o Lax. El primero le dice al navegador que bloquee el envío de la cookie desde otra pestaña sea cuál sea el método HTTP que esté utilizando, mientras que con Lax se permite enviar la cookie si el método es GET.

Set-Cookie: Elladodelmal=1; Path=/; HTTPOnly; Secure; SameSite=Strict;

Esto es así, porque muchas aplicaciones web - especialmente redes sociales - viven de referencias en sitios de terceros y exigiría que el usuario tuviera que iniciar sesión cada vez que hiciera un clic en un enlace. Los que tienen esa forma de funcionar, las acciones importantes las configuran siempre por POST y dejan el método GET para eso, para navegaciones internas entre contenidos. Por eso se creo SameSite=Lax

Set-Cookie: Elladodelmal=1; Path=/; HTTPOnly; Secure; SameSite=Lax;

Pero... no mucha gente ha configurado en sus cookies la política Same-Site, así que Google Chrome ha optado por forzarlo de la siguiente manera.

Google Chrome Same-Site-By-Default-Cookies

A partir de la versión de Google Chrome 78 estará activada la opción que está disponible en modo test desde Google Chrome 76 que, si una cookie no tiene la política SameSite, por defecto será como si llevara la opción de SameSite=Lax. Por lo que puede que si tu web utiliza URLs GET sin SameSite para administrar cosas, tal vez te dejen de funcionar comportamientos que son comunes en tus usuarios.

Figura 5: Flags en Google Chrome 77

Lo suyo es que tengas en mente por qué se utiliza SameSite=Lax y veas si puedes mejorar la seguridad de tu web, pero si no, que sepas que Google Chrome va a forzarlo por defecto. Siempre puedes entrar en Google Chrome, y en los flags de configuración cambiar el valor de la opción Same-Site-By-Deafult-Cookies y Deshabilitarlo, pero lo mejor sería que revisaras tu web.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)