Hacking Gitlab Duo: Remote Prompt Injection, Malicious Prompt Smuggling, Client-Side Attacks & Private Code Stealing.

Esta misma semana se ha publicado un trabajo de investigación sobre vulnerabilidades del GitLab Duo que es muy interesante por muchos aspectos, y por utilizar muchas de las técnicas de las que cada día hablamos más en el mundo del Hacking de Productos & Servicios hechos con IA. En este caso, los investigadores de Legit han demostrado cómo se podía utilizar GitLab Duo para atacar a otros usuarios con librerías infectadas y construir malware, para inyectar código malicioso en los resultados de GitLab Duo y para robar código privado, muy interesante técnicamente toda la investigación.

Figura 1: Hacking Gitlab Duo - Remote Prompt Injection,

Malicious Prompt Smuggling, Client-Side Attacks

& Private Code Stealing.

El artículo completo lo podéis leer en "Remote Prompt Injection in GitLab Duo Leads to Source Code Theft", y aquí tenéis una explicación del trabajo que os he resumido - y ampliado - para ver si soy capaz de explicarlo con claridad.

Figura 2: Remote Prompt Injection in GitLab Duo Leads to Source Code Theft

GitLab Duo es el asistente con IA de la plataforma GitLab que te ayuda a trabajar con tu repositorio de código, y que está disponible para todos los usuarios. Utiliza, por supuesto, una arquitectura de DeepReasoning, así que permite realizar tareas complejas, escribir código, puede manipular documentación, y para hacer bien el trabajo, cuenta con su Memory.

Figura 3: Hacker & Developer in the Age of GenAI LLM Apps & Services

Para entender el ataque bien, os recomiendo que leáis antes el artículo de "GenAI Apps & Services: Cómo explotar arquitecturas RAG con Plugins Inseguros" porque tiene algunas similitudes en cuanto al ataque. En este artículo teníamos un servicio representado por ChatGPT, y le dábamos capacidades para hacer cosas sobre datos conectados (ficheros en One-Drive), y aplicaciones (enviar correos electrónicos). Si no había un entorno aislado multiusuario, un atacante podría ver los prompts de otro usuario, o los ficheros a los que tuviera acceso el modelo de IA, en ese caso, ChatGPT. 

Hacking Gitlab Duo:

En el ejemplo de GitLab Duo, el investigador hace un ataque de Prompt Injection que pone en el código fuente de un programa como un comentario, y con un simple "Explain this code" o hacer cualquier acción sobre ese código, se puede ver cómo GitLab Duo lo procesa.

Figura 4: El Prompt Injection está en un comentario.

Cuando se le pide a GitLab Duo que explique el código

se puede ver que se ejecutan las órdenes del Prompt.

Visto esto, para enviar estos ataques a otro usuario lo que hace es proponer un cambio en el un código de otro usuario, y en los comentarios introducir el Remote Prompt Injection, que en este caso inicial se trata de meter una librería de código maliciosa, por ejemplo, para robar los usuarios y contraseñas de un proceso de Login.

Figura 5: Prompt Injection para meter una

librería Javascript maliciosa.

Cuando la víctima dueña del código solicite a GitLab Duo cualquier comando sobre el código que está visualizando del cambio propuesto, el Prompt Injection se ejecutará, y realizará un Memory Poisoning, dejando en la memoria que si en el futuro se solicita, por ejemplo, una página de Login, meta esa librería maliciosa. 

Figura 6: Técnicas para Prompt Smuggling

Para hacer este ataque mucho más invisible para la víctima, el atacante hace uso de técnicas de Prompt Smuggling para saltar los posibles guardarraíles del modelo usando trucos como los vistos en el artículo "Cómo saltarse los AI Guardrails con Invisible Characters & Adversarial Prompts para hacer Prompt Injection & Jailbreak Smuggling" , además de para hacer menos visible el Prompt en el código y el panel que pueda ver la víctima.

Figura 7: Prompt codificado en los cambios con texto en blanco.

Solo se ve cuando se selecciona en GitLab

Como se puede ver en la imagen anterior, en la parte de Changes queda en color blanco (codificado en KaTeX), y además queda en Unicode usando codificación Base16 para meter los Prompts Maliciosos.

Figura 8: El Prompt Injection queda codificado en el historial

En este caso la demo la hace directamente con la petición del Login, así que la infección de la Memory no tiene que esperar a la petición futura.

Figura 9: El Prompt Injection se ejecuta.

Ahora, si vemos el proceso completo de GitLab Duo, se puede ver cómo ha inyectado la librería maliciosa, y cada vez que procesa el usuario y la contraseña llama a la función de esta librería que puede robar las cuentas tranquilamente.

Figura 10: El código de Login queda infectado.

Una vez que se ha completado este ataque, es posible imaginar muchos otros ejemplos. Por ejemplo pedirle que en la respuesta GitLab Duo muestre un enlace que la víctima pueda hacer clic para llevarle a una infección. 

Figura 11: Inyectando un enlace malicioso en la salida de GitLab Duo

Y por supuesto, cuando llegue la ejecución del Prompt en el GitLab Duo de la víctima, se producirá esa respuesta que se ha solicitado, tal y como se ve en la imagen siguiente.

Figura 12: Inyectado el enlace en la salida de GitLab Duo

Una vez visto este comportamiento, se pueden reproducir todos los ataques Client-Site en Web Applications, ya que tenemos un servidor - el de GitLab - desde el que enviar código a una víctima - desde Prompt inyectado -.

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

El siguiente ejemplo fue hacer HTML Injection y realizar ataques de Cross-Site Scripting (XSS), en este ejemplo para "Rickrollear" un poco.

Figura 14: Injectando HTML Injection

Com se muestra en la imagen siguiente, este ataque también funcionó, por lo que se ha utilizado el modelo LLM como forma de atacar a otros clientes.

Figura 15: Rickrolleando con GitLab Duo

La última de las PoCs es para robar el código fuente de un programa de otro usuario que está en PRIVADO. En este caso aprovecha que GitLab Duo puede usar la herramienta merge_request_reader que tiene acceso a todos los códigos - públicos y privados -, así que con este Prompt se le pide que meta el código en un parámetro en Base64 como parte de un enlace.

Figura 16: Prompt para robar código privado

Al final, usando este ataque Remote Prompt Injection se solicita a GitLab Duo que use una herramienta que tiene conectada al modelo -  y que le da permisos para acceder a datos privados - que explique un merge_request privado, y que pinte la salida como parámetro de un enlace. 

Figura 17: Enlace malicioso con el código fuente robado

Para poder hacer este ataque, ha sido necesito meter el Remote Prompt Injection en una petición de cambio enviada a un código de la víctima, utilizando las técnicas de ASCII & Malicious Prompt Smuggling. Después, cuando al víctima ha pedido cualquier comando a GitLab Duo, el Malicious Prompt se ha ejecutado y se ha creado un enlace malicioso con el código fuente del programa a robar como parámetro. Cuando la víctima hace clic en él se envía el GET Request con el código fuente en la URL al servidor controlado por el atacante.

Reflexión final

El mundo de la Inteligencia Artificial a las profesiones de cibeseguridad nos ha abierto tres nuevas disciplinas en las que tenemos que trabajar. La primera es la de utilizar los nuevos modelos de IA para hacer ataques en los procesos de Pentesting, Ethical Hacking o Red Team. La segunda disciplina es utilizar la IA como forma de aumentar las capacidades de los equipos de seguridad, para automatizar tareas en el SOC, procesos de patching por IA, detección de anomalías, forensics, y cualquier proceso del Blue Team y los equipos de CERT & CSIRT. 

Figura 18: Hackin’ AI: Creando una IA… ¿Qué puede salir mal? por Chema Alonso

Por último, lo que vemos aquí es un ejemplo de la disciplina de aprender a atacar las nueva arquitecturas basadas en modelos de IA, Agentic AI, etcétera, que es lo que recoge el OWASP Top 10 de Productos & Servicios basados en LLMs. Un campo completo para el que aprender a diseñar nuevos ataques, basados en Prompt Injection, Jailbreak, Memory Poisoning, Malicious Prompt Smuggling, Guardrails Bypass, Data Poisoning, etcetera. Todos los problemas vistos en el artículo de hoy, el equipo de GitLab ya los parcheó, que se hizo un reporte responsable, pero son un ejemplo perfecto del tipo de ataques al que nos vamos a enfrentar hoy en día. Entretenidísimos vamos a estar.

PD: 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: Inteligencia Artificial (Hacking & Security): Links, Posts, Talks & Papers

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cómo buscar vulnerabilidades en SmartContracts, SQL Injection, XSS o bugs Python con ChatGPT

Hace poco os hablaba del estudio que arrojaba como resultados que los programadores que utilizan asistentes de código basados en inteligencia artificial son más propensos a generar código con fallos de seguridad, y además hemos visto que si pides que te hagan código sin pedirle que mire la seguridad tanto Copilot, como ChatGPT, como otros asistentes, pueden generar código "buggy". Hoy vamos a ver lo contrario, cómo pedirle que nos ayude a hacer seguro nuestro código.

Figura 1: Cómo buscar vulnerabilidades en SmartContracts,

SQL Injection, XSS o bugs Python con ChatGPT.

Imagen hecha con Dall-e 2 (A happy hacker in Picasso style)

Vamos a hacer cuatro ejemplos de corrección de su propio código, de búsqueda de vulnerabilidades, de revisión en profundidad de un código, y de generación de código seguro desde el principio. Vamos a ello.

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, 

Ejemplo 1: Un SQL Injection en el código de ChatGPT

En el ejemplo primero, le pedía una función que accediera a una base de datos para comprobar si un usuario había introducido correctamente sus credenciales, y como veíamos, nos daba un código PHP con un SQL Injection de libro.

Figura 3: Código PHP con bug de SQL Injection generado por ChatGPT

Sin embargo, si le pedimos a ChatGPT que corrija el fallo de SQL Injection, lo cierto es que lo corrige perfectamente. 

Figura 4: Le pedimos a ChatGPT que elimine el bug de SQL Injection y lo hace.

Y esto abre muchas posibilidades que podemos aprovechar para securizar nuestro código o para buscar vulnerabilidades en códigos que estemos auditando. Es decir, como una herramienta de análisis de código estático.

Ejemplo 2: Encontrar un bug de Reentrancy Attack en un SmartContract

Para ello, en este ejemplo le he pedido que me busque si este código del mundo Web3 (que es un SmartContract que tiene una vulnerabilidad de Reentrancy Attack) tiene algún fallo de seguridad, pero como veis en la conversación, no le digo si existe o si no existe, ni por supuesto qué tipo de bug puede tener. Y ChatGPT lo encuentra perfectamente.

Figura 5: ChatGPT encuentra el bug de Reentrancy Attack

Así que, ya que lo ha encontrado, vamos a suponer que es nuestro código, así que vamos a darle cariño y pedirle que lo corrija él solito y nos dé el código sin esta vulnerabilidad. 

Figura 6: ChatGPT corrige el bug de Reentrancy Attack

Y listo. En un santiamén tenemos el código correcto de este SmartContract.

Ejemplo 3: Evaluar la fortificación de un código en Pyhton conjuntamente

En la siguiente prueba le doy el código inseguro para generar un fichero temporal que devolvió en la prueba de códigos inseguros generados por CoPilot. Así que le doy el código y le pido que busque si tiene alguna vulnerabilidad esta sección de un programa en Python.

Figura 7: No ha encontrado el bug a la primera

Sorprendentemente me dice que no ve ninguna vulnerabilidad, pero como yo sí sé que hay un problema en el método utilizado para la creación del archivo temporal, le pregunto directamente si ese método no es inseguro.

Figura 8: Insistiendo a ChatGPT sobre el método que sé que es inseguro

Como podéis ver, me ha contestado que no, SI tomo las medidas de prevención adecuadas. Pero claro, como programador de una aplicación, no puedo garantizar la configuración de los permisos del sistema donde esté implantado, así que le pregunto directamente por ese punto tercero.

Figura 9: Ahora sí que ha visto el problema, y me da la solución correcta

Y en ese caso, sí, ve el problema de seguridad, y ya me recomienda utilizar una función segura para evitarlo. Un ejemplo claro que la Mayeuita de Sócrates funciona perfectamente con la Inteligenica Artificial de hoy en día. 

Ejemplo 4: Generar un código JavaScript sin XSS ni bugs de Client-Side Attacks

Como veis, se puede utilizar ChatGPT para encontrar bugs, para evaluar código, pero también se puede utilizar para pedirle que el código que te genere sea seguro. Basta con enfatizar "sin vulnerabilidades de seguridad" en la conversación para que se lo tome muy en serio. Aquí, un caso muy típico donde muchos desarrolladores se comen un Client-Side Attack en forma de XSS, de CSRF, etcétera.

Figura 10: Código de JavaScritp con su entrada escapada para evitar XSS

Y como le hemos pedido que lo haga de forma segura, pues ha hecho un código en el que no deja meter código que pueda ser inyectado, mientras que si no le pides que se preocupe de la seguridad, te puede dar un código bastante buggy.

Conclusiones de estas pruebas

Así que, como decía en el vídeo que hice para explicar esto, no se trata de no utilizar los asistentes de Inteligencia Artificial para hacer código, sino de saber sacarles partido.

@chema_alonso ¿Generan código inseguro los asistentes de inteligencia artificial? #ai #ia #bug #sqli #copilot #chatgpt #seguridad #aprendoentiktok #aprendocontiktok ♬ Terminator 2: Judgment Day Theme - Everrune

ChatGPT, Copilot y todos los que irán apareciendo, son una herramienta de gran utilidad para:

1. Descubrir vulnerabilidades: Lo que es bueno para los pentesters y auditores.
2. Securizar código existente y revisarlo en profundidad: Lo que es bueno para QA y DevOps.
3. Generar código de forma rápida y segura: Lo que es bueno para los desarrolladores.

En definitiva, más vale que vayas aceptando que tu trabajo en el futuro va a requerir de saber sacarle el máximo partido a la Inteligencia Artificial igual que en el pasado tuviste que aprender a sacarle partido a Internet.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Copilot y su código inseguro o cómo la IA aprende a programar (también) metiendo "Bugs"

A estas alturas ya prácticamente todo el mundo sabe qué es Copilot, la Inteligencia Artificial (IA) de OpenAI y GitHub que genera código fuente de forma automática en varios lenguajes de programación. Además, ahora ya está accesible de forma gratuita para todos los desarrolladores y así echarles una mano durante el proceso de programación. 

Figura 1: Copilot y su código inseguro o cómo la IA

aprende a programar (también) metiendo "Bugs"

Que Copilot sea capaz de generar código es un hito increíble dentro del mundo de la IA (uno más, mañana tendremos otro nuevo). Y además es el primer paso que acerca a la IA a la auto programación y por lo tanto a generación propia de programas, es decir, autorreplicación (¿alguien ha dicho reproducción?).

Pero la seguridad del código también importa

Hoy vamos a centrarnos en un punto de vista importante, más allá de la eficiencia, la utilidad o incluso la metafísica que rodea a la generación de código. Estamos hablando de la seguridad o vulnerabilidad del código generado. Este tema del código inseguro generado por Copilot no es nuevo, ya en octubre de 2021 la NYU presentó un artículo contundente, donde indicaba que el 40% del código generado por Copilot es inseguro. La prueba se realizó contra 1.692 programas en diferentes escenarios y usando MITRE TOP 25 CWE como base para comprobar la fiabilidad del código. 

Figura 2: Papers sobre el código inseguro que genera Copilot

Y esto es realmente preocupante, este porcentaje es demasiado alto como para que Copilot se convierta en una herramienta utilizada por millones de desarrolladores de todo el mundo. No es sólo cuestión de programar bien, sino también seguro. Y por ese motivo escribimos este libro llamado “Machine Learning aplicado a la Ciberseguridad”, de 0xWord, donde explicamos la importancia de la ciberseguridad dentro de la detección de amenazas utilizando Inteligencia Artificial:

Figura 3: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

La raíz del problema

Copilot está basado en una familia de modelos NLP de OpenAI Codex. El núcleo del modelo es el famoso GPT-3 el cual funciona como base del lenguaje. Pero claro, tenemos que enseñarle a programar. Por lo tanto, la parte de "fine tunning", es decir, ajustar el modelo a la salida que queremos, tenemos que entrenarlo con ejemplos de programación. Por este motivo la fase de "fine tunning" se realizó directamente aprendiendo del código publicado en GitHub. Y claro, este código no siempre está optimizado para evitar problemas de seguridad como SQL Injection, XSS, etcétera.

Figura 4: Configuración de todo el proceso de análisis de

código inseguro realizado en el paper de la Figura 2

Copilot no sólo se entrena con código fuente de Github, también tiene otras fuentes Open Source los cuales pueden contener bugs, referencias a APIs inseguras, etcétera. Es decir, el dataset que le “enseña” a programar contiene todos estos problemas, bugs, vulnerabilidades, etcétera. Copilot programa de manera insegura porque la mayoría de nosotros programamos de esa forma, no es un error de Copilot, es un problema nuestro.

El problema persiste un año después …

Recientemente GitHub ha publicado un estudio donde nos cuenta la experiencia después de un año de usar Copilot. Se entrevistó a unos 2.000 programadores que han estado utilizándolo de manera habitual durante un año. El resultado es que la mayoría, entre el 60% y 75% se mostraron contentos, menos frustrados y más satisfechos con su trabajo utilizando Copilot. Esto es en parte porque Copilot elimina el tiempo perdido buscando “soluciones en Internet" (es decir, en Stack Overflow) o centrándose en otras partes menos repetitivas del código. Pero este nuevo estudio no dice nada sobre la seguridad del código generado.

Figura 5: Libro Hacking de Aplicaciones Web: SQL Injection
de Enrique Rando y Chema Alonso

GitHub sí que menciona que sigue mejorando el modelo intentando excluir todo el código inseguro o no eficiente que genera. Eso sí, recomienda analizar siempre todo el código generado y que sea siempre el programador el que tenga la última palabra. Pero hoy día podemos comprobar que todavía tiene bastantes problemas de seguridad.

Hemos seleccionado la base de datos de Sonar donde podemos encontrar muchos ejemplos de código inseguro en varios lenguajes, pero vamos a centrarnos en Python y en concreto en tres bastante sencillos que son auto explicativos (sólo tenemos que ver la parte de Sonar que dice “Noncompliant Code Example” (ejemplo de código no conforme) y compararlo con la salida de Copilot. Pero el paper que hemos mencionado antes tiene en detalle todo un estudio completo comprobando las vulnerabilidades entre varios lenguajes de programación por si quieres comprobarlo mejor.

EJEMPLO 1: https://rules.sonarsource.com/python/type/Vulnerability/RSPEC-5144

Figura 6: Ejemplo vulnerabilidad a peticiones desde el lado del servidor

Copilot:

Figura 7: Salida generada por Copilot

EJEMPLO 2: https://rules.sonarsource.com/python/type/Vulnerability/RSPEC-5445

Figura 8: Ejemplo vulnerabilidad a la hora de crear ficheros temporales

Copilot

Figura 9: Salida generada por Copilot.

EJEMPLO 3: https://rules.sonarsource.com/python/type/Vulnerability/RSPEC-4426

Figura 10: Parámetros correctos a la hora de generar llaves criptográficas

Copilot:

Figura 11: Salida generada por Copilot.

Estos son sólo tres ejemplos muy sencillos, pero puedes simplemente acceder a la web de Sonar e ir comprobando uno a uno todos los ejemplos que ofrecen en su web.

Conclusiones

Copilot es una fantástica herramienta, que estamos seguros será de gran ayuda al programador. Pero también puede ser un gran problema de seguridad si no se entrena de la manera adecuada para generar el código más seguro posible. Esta herramienta cada vez más será utilizada por desarrolladores de todo el mundo y por lo tanto debe de ofrecer el código más seguro y optimizado posible. 

Para ello será necesario ir etiquetando todas las salidas inseguras del código generado (esto podría ser una buena “feature” para Github, reportar código inseguro de Copilot desde el mismo plugin de VStudio por ejemplo) y de esta forma crear un entrenamiento más adecuado a la seguridad del código. De momento, si usas Copilot, debemos utilizar alguna herramienta de análisis de código para comprobar que el código generado no tiene vulnerabilidades.

Figura 12: Libro de "Hacking Web Technologies Silver Edition" 3ª Edición

de 0xWord, escrito por Enrique Rando, Pablo Gonzalez, Ricardo Martin,

Chema Alonso y Amador Aparicio.

Si ya nos cuesta escribir código seguro (los problemas actuales de seguridad lo demuestran) lo que nos faltaba es una herramienta que automatizara la programación y encima de forma insegura ;). Estamos seguros que poco a poco este problema se irá solucionado, pero de momento, mucho cuidado.

Saludos,  

Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", también de "Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades. Puedes contactar con Fran Ramirez en MyPublicInbox.

 Contactar con Fran Ramírez en MyPublicInbox

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)