Breaking Security Defenses: How to bypass the Content Security Policy

Hola, ¿qué tal? Sí. Ah, bienvenidos a la plática. Dejen que inicien el proyector para poder comenzar. Este, ya está. Ah, bueno, esta charla va a tratar sobre el content security policy. Vamos a ver cómo evadir el content security policy. Este, y con estas técnicas ustedes van a poder pasear esta defensa de seguridad ah muy muy seguido. Ah, y bueno, en realidad hay muchas artículos en internet que te dicen técnicas de cómo puedes evadir un content security policy que tiene errores en su configuración. A veces, muchas veces la gente no lo configura bien y luego por eso puedes encontrar maneras de poder evadirlo. Este, pero con algunas de esas técnicas van a poder evadir con el security

policy, aunque esté 100% correctamente configurado, aunque no tenga error de bon configuración, sea cual se su configuración, se puede evadir. Y también vamos a ver otras técnicas este que pueden resultar útiles en otros escenarios. Ah, y ah, también ah en las diapositivas vienen varias técnicas que te pueden ser útiles para romper esta media de seguridad, pero por cuestión de tiempo no voy a alcanzar a mostrarla a todas, pero si les interesa luego pueden descargar las diapositivas, ahí pueden ver todo el material restante que le puede servir, pero que ahora no vamos a poder ver por cuestión de tiempo. Bueno, pues lo que ocurre es que el content security policy a veces no deja explotar las vulnerabilidades cuando

estamos haciendo algo, un trabajo, un PTS, algo para un cliente. A veces cuando encontramos inyecciones de contenido como cross scripting o inyección HTML, muchas veces esas vulnerabilidades no se pueden explotar porque usan un content security policy. Entonces, pues en el reporte no puedes marcar la vulneridad como explotable. Viste que la no se puede explotar o si estás haciendo un back bounty, pues ah el bog, no te van a pagar dinero porque no se explotar buenas vulnerabilidades. E este es más o menos el mensaje que recibimos cuando intentamos explotar un cross scripting que está siendo bloqueado por el con security policy. Entonces esta charla se va a tratar sobre cómo todas esas vulnerabilidades que no se pueden explotar, vamos a ver

cómo convertirlas en vulnerabilidades explotables para de que esa manera en su reporte puedan marcar la vulnerabilidad como explotable o en caso de que estén haciendo un back bounty puedan cobrar dinero. Ah, corrí unas estadísticas. Ah, hice un ah un muestreo de 300 de los sitios más visitados del mundo, cues y otras páginas de alto perfil como entidades bancarias, instituciones financieras, páginas de gobierno. Ah, hizo un estudio muestro de 300 de los sitios más visitados del mundo. De estos 300 sitios más visitados en el mundo, el 44% usan el content security policy, o sea, que más o menos la mitad de los sitios ah usan esta defensa de seguridad. Ah, y resulta que el 98% de estas páginas ah de estas

configuraciones se pueden explotar con las técnicas que vamos a ver en esta charla. Eso deja que solo no se alcance a ver toda la proyección, pero solo el 1% está bien segurado y el otro 98% se puede explotar con stacks técnicos. Ah, me presento brevemente. Ah, me llamo Rubén Piña. Me inicié un hacking hace alrededor de 20 años. Ah, y soy investigador independiente para mi blog llamado proyecto NT48. Y también he sido ponente en varias conferencias como Was Lone Stars, Hackfest Canadá, HP Florida, Bide Shadow, Visides Berlín, Dragon Yard Colombia, Buscon, Monterrey y otros. Okay, entonces primero vamos a ver el ataque desde donde esta plática va a comenzar. Hm. Okay, pues imaginemos que tenemos una

aplicación en la que encontramos una edition de contenido como un curso de scripting. Este, entonces el contexto es más o menos este. Ah, en la página tenemos [Música] una información secreta o una información ah de valor que tenga un valor. En este caso tenemos un directorio, tenemos nombres, emails, teléfonos, un directorio. Ah, y ah, imaginemos que arriba de toda esta información secreta tenemos un edition de contenido, ¿no? Entonces, ah, el ataque del que va a comenzar esta práctica es más o menos así. Ah, arriba donde tenemos la inyección de contenido, vamos a inyectar un textaria, una caja de texto. Y usualmente esa etiqueta tiene que ir cerrada, tienes que cerrarla, pero en este caso la vamos

a dejar abierta. Entonces el texta se se va va a consumir toda la información en la página porque pues la dejamos abierta, entonces el el toda la información va a aparecer adentro de la caja de texto. Se ve más o menos así. Aquí tenemos nuestra página con nuestra información secreta. Ah, y luego es cuestión de inyectar una caja de texto y no la cerramos, entonces toda la información va a aparecer dentro de la caja de texto. El siguiente paso es inyectar una etiqueta de formulario para enviar este formulario a un dominio externo ah controlado por el atacante de nosotros. Ah. Ah, y luego es cuestión de inyectar un botón de formulario y podemos usar hojas de estilo para hacer este botón

tan grande como todo el documento y luego lo hacemos invisible ah con la hoja de estilos. Entonces, en cuanto el el usuario de clic en cualquier parte de la página, le va a dar clic al botón sin darse cuenta y todo el contenido de la caja de texto se va a enviar a a la página controlada por el atacante. Este, entonces así vamos a poder robarnos toda la información que está ahí. Ah, pareciera un poquito ah mucho pedir que el usuario le tengan que dar clic a una parte de la página, pero en realidad es algo extremadamente sencillo. Este ya me lo hicieron varias veces. Este con la hoja de estilo hacemos podemos hacer el botón invisible y lo podemos

hacer todo bien grande para que no se vea el botón y le den clic en cualquier parte del documento, pero también puedo usar otras técnicas como por ejemplo puedes hacer con hoja de estilos que el botón parezca la política de las cookies. Ah, tipo aquí en el teléfono te aparece la política y ah, pues usa la mitad de la página. Entonces casi siempre todo el mundo le da clic, ¿no? Entonces en cuanto le den clic ahí pues en realidad van a estar enviando el formulario que tiene toda la el contenido de la página. Ah, también hay otras técnicas. Por ejemplo, muchas veces las páginas te piden que des un clic para verificar que eres humano.

Puedes dar tu botón de mirar ah para que aparezca un capture, entonces en cuanto un challenge. Entonces en cuanto el usuario le daba clic al al challenge, este, pues se envía el formulario con todo el contenido de la página. También puedes usar una un cuadro de diálogo de notificaciones. Mucha gente le da las notificaciones y también puede usar un una publicidad, ¿no? Muchas veces te sal un cuadro de publicidad y toda la página te aparece difuminada, borrosa, entonces tienes que cerrar el el cuadro de algo para poder ver la página. Es extremadamente fácil hacer con los de clic. Okay. Entonces, ah, ¿cómo nos protegeríamos de este ataque? Ah, pues la defensa sería usar el cont security policy. Ah, la

directiva formion restringe a dónde los formularios pueden ser enviados. Entonces, en el forma, para que el formulario no se puede enviar ningún dominio externo, para que los formularios solo se puedan enviar a al dominio en el que ya estás. Entonces, de ese modo previenen que un atacante use un formulario para excitar toda la información a un dominio externo. Ah, entonces la ambición de esta plática va a ser ah evadir formar el formulario a un dominio externo. O sea, si la página us el condicy y tiene el form que solo se puedan enviar al al mismo dominio, nosotros vamos a evadir también de seguridad para poder enviar el formulario a un dominio externo contratado por nosotros y así poder

exparar toda la información. Ah, ahora la realidad es que casi nadie usa ah form action. Este, la gente piensa que esta directiva no es la importante. Ah, pero es porque uno conocen esa tarea que acabo de mencionar que puede usar formularios para explicar la información. Entonces, la realidad es que casi nadie usa formation. Ah. porque no conocen este ataque. Así que este ataque que acabamos de ver funciona el más o menos el el 82% de las veces [Música] porque la gente no usa esta directiva, así que solo el el 17% están protegidos contra este ataque. Entonces, esta práctica se va a enfocar en este 17% para que aunque la la política esté configurada para que no se

puede enviar formularios a otro lugar, ahora sí vamos a evadir la política para que ese ataque sea ah posible pues casi siempre.

Okay, pero antes de ver cómo evadir esta política, primero vamos a ver de qué otras maneras podemos hacer daño usando formularios, de qué otra manera podemos usar los formularios para vulnerar la aplicación y comprometer la información de de las personas. ¿Qué pasa si en la página tenemos la inyección de contenido, pero no hay nada valioso ahí? ¿Qué pasa si ahí tenemos un lugar donde inyectar, pero no tenemos nada que que podamos consumir como la caja de texto para enviar a otro lugar? ¿Qué pasa si no hay nada ahí de valor? Bueno, ahorita vamos a ver una manera en la que un atacante pueda sacar provecho de esta situación y este ataque se llama inyección de

formulario. Y es más o menos así. Ah, tenemos aquí la inyección de contenido. Entonces, vamos a inyectar un formulario con dos campos, un campo de texto y un campo de tipo password, ¿no? Este, pues básicamente este aparece un login, una caja donde pones el nombre de usuario, un un campo donde pones la contraseña. y lo vamos a inyectar una una etiqueta de formulario para enviar este formulario al atacante controlado por nosotros. Ahora, este, recuerden que los navegadores tienen una funcionalidad llamada el recordar la contraseña o guardar la contraseña. Este, en la que este si tú guardas la contraseña para un sitio, cuando el navegador vea que hay un formulario de login, el navegador ah llena el login con la contraseña del

usuario automáticamente. El navegador no pide ningún tipo de confirmación para el usuario. El navegador no te dice este, ¿quieres que se llene automáticamente el formulario? Ah, no, no te muestra nada, no te pregunta nada, simplemente lo llena automáticamente en cuando encuentra un login. Este, entonces el ataque se ve más o menos así. Imagíos que aquí tenemos la página que es vulnerable. En este caso no tenemos aquí nada de información valiosa. Entonces, ah, lo que hacemos es vemos que tenemos aquí una inyección de contenido. Ah, y lo que hacemos es inyectar a un campo de usuario y un campo de password, algo así. Entonces, en cuanto al usuario entre esta página, el navegador automáticamente va a llenar este formulario con las

credenciales de autenticación del usuario. Ah, sin ningún tipo de confirmación. Ah, luego es cuestión de usar el atributo hiden, ese atributo de aquí y el formulario hace invisible, entonces el usuario ya no puede ver nada y aunque el formulario sea invisible, aún así el navegador va a llenar formulario de llorina. Ah, entonces esto va a ser completamente transparente para el usuario. Luego es cuestión de inyectar un un botón de enviar ah con un poquito de hoja de estilo para hacerlo ah tan grande como todo el documento y luego lo haces invisible. Entonces, en cualquier momento que el usuario de clic en cualquier parte de la página, sus credenciales van a ser enviadas a otro lugar.

Ahora, parece un poquito el el problema con el la función de recordar contraseña es que no se no puede ser deshabilitada por la aplicación tipo aunque la aplicación tenga el auto complete off para que los se llenen automáticamente, esto no funciona para los para los formularios de autenticación, para el formulario de login. El auto complete se usa para cosas como números de teléfono, ah, direcciones, diccionarios de correo, nombres, cosas así. Pero el campo de login es ah otra cosa diferente, es es una funcionalidad distinta. Esa funcionalidad se llama el manejador de contraseñas y el manejador de contraseñas no puede deshabilitar, no puede ser deshabilitado por la aplicación. Eso quiere decir que si si la aplicación tiene un campo de login,

ah, no hay manera de decir al navegador que no lo llene automáticamente. Ah, del lado del desarrollador. Ahora, del lado del usuario, este, cuando una persona compra un teléfono nuevo o cuando tienes una compu nueva o la que vas a formatear, este, y abres Chrome, Chrome te pide que inicie sesión para que puedas usar tus tus datos en en múltiples dispositivos. Entonces, en cuanto alguien o en cuanto la persona inicia sesión en Chrome, el manejador de contraseñas se activa automáticamente para todas las páginas. Este, esta función es extremadamente usada, pues casi casi toda la gente que usa Chrome, el teléfono de la compu, tienen su cuenta linkada al navegador. Entonces este al hacer esto, esto hace que Chrome

guarde las contraseñas para todos los sitios, para todos los sitios que se visitan. Entonces es extremamente común que la gente utilice este esta funcionalidad, lo cual quiere decir que sus datos pueden ser infiltrados porque Chrome va llenar de formulario automáticamente. De hecho, Chrome también, Google Chrome hizo un comercial en el que recomiendan a los usuarios que utilizan esta funcionalidad porque dicen que incrementa la seguridad de tus cuentas, porque si utilizas el el recuérdame puedes ah usar contraseñas bien grandes, bien largas como de 30 40 caracteres con números, símbolos, letras mayores que las minúsculas. puede tener conas bien complicadas y únicas para cada sitio. Ah, entonces Chrome hizo un navegador que le pide a la gente que use esta

funcionalidad para aumentar su seguridad, pero gracias a esto pues puedes puedes excitar la simulación de quer usuario. Este es otra manera en la que pueden usar fulmarios para explotar una aplicación. En caso de que la página no tenga nada valioso, pues te puedes robar las credenciales de los usuarios. Entonces, a la hora que tú pongas esto en tu reporte, puedes lo puedes marcar como explotable porque pues casi prácticamente todo el mundo usa el el iniciar sesión en Chrome, el ligar tu cuenta de Chrome. Ahora vamos a ver otras técnicas útiles para cuando no podemos correr scripts de hace security policy. Este y este ataque se llama inyección de marcado de incompleto. E este era un ataque muy poderoso,

bueno, un ataque relativamente poderoso que se podía usar en situaciones donde tenías un crosside scripting, pero no puedes correr scripts porque pues la ejecución de scripts está bloqueada por el policy, por ejemplo. Entonces, este era un ataque que era útil cuando no puedes correr scripts y ah pues ahora los navegadores modernos como Microsoft Edge, Google Chrome, Safari, no sé, este tienen tienen ah defensas ah en el el navegador trae defensas que bloquea este ataque que ahorita voy a exponer. Ah, pues esta defensa no está en la aplicación, está en el en el navegador, viene con el navegador web. Entonces estas esta tá se volvió inservible. Ah, y con esta parte ah logré evadir la la

seguridad de los navegadores. Ah, ades básicamente fue como resucitar esos ataques para que vuelvan a hacer, para que se puedan volver a usar, a pesar de que estaban muertos por los navegadores modernos. El ataque se ve más o menos así.

Ah, okay. Imaginemos que aquí tenemos datos secretos en la página. Tenemos aquí ah nombres, emails, teléfonos. Ah, un directorio, ¿no? Vamos a ver. Y y acá arriba tenemos nuestra injection de contenido ah bloqueada por el concur policy. No podemos correr scripts. Entonces el ataque se veía más o menos así. Aquí está la inyección de contenido. Ah, inyectamos una etiqueta de hoja de estilos. Entonces, aquí la etiqueta hoja de estilos tiene el atributo donde se pone la URL de donde se va a llamar los hoja de estilos. Ah, entonces a esta URL le va a cargar una hoja de estilos que está en un dominio externo controlado por el atacante. Ah, y veamos que la URL del atributo

está delimitada por una comilla al final. Entonces, la la las comillas delimitan ah el valor de la URL ah a donde se va a hacer la petición para descargar el hoja de estilos. Entonces, el ataque solo es cuestión de quitar la comilla. Ah, entonces ahora la URL se va a tragar todo el contenido de la página. Como no cerramos a la comilla, ah el navegador va a comenzar a leer la URL y luego va a comenzar a leer todos los datos de la página. Entonces, la URL ahora contiene todos los datos de la página y cuando se haga la petición a la página del atacante, todo el contenido va a ser filtrado por la por la URL.

Este, ahora ese tag que tú funciona en Firefox. Aquí vemos que hacemos una una petición get. Se hace una petición get para llamar hoja de estilos. Aquí vemos que en la URL se está enviando todo el contenido de la página y Firefo nos da un 200. Okay. Dice que no hay ningún problema, pero los navegadores modernos ahora tienen protecciones contra este ataque. Por ejemplo, aquí vemos en en Google Chrome que se hace una aplicación, se hace una petición, pero la petición está bloqueada. Ah, porque Chrome detecta que en la URL hay código HTML. Ah, más precisamente utiliza cuando las etiquetas ah, las etiquetas de mercado, este, y las nuevas líneas. Ah, Chroma asume que hay código HTML en

la URL. Entonces parece que todo el contenido de la página, todo el código de la página está siendo exfiltrado por una petición. Este, entonces en este caso, la petición ser bloqueada. Ah, Microsoft Edge también bloquea estas peticiones. Aquí tenemos que tenemos los ah las etiquetas de marcado. Ah, y Edge está bloqueando bloqueando la petición. Entonces, vamos a ver cómo evadir estas esas validaciones ah para ah para poder explicar el código de la página por una URL. Entonces, son son tres ataques distintos. Ah, y la primera técnica es un ataque de codificación a UTF16. Ah, okay. Primero vamos a ver qué es esta. Esto le confunde un poquito a las personas. Entonces, tengo otra diapositiva donde vamos a

explicar que es un un ataque de codificación.

Este, okay, hay diferentes ah tipos de codificación de caracteres. Por ejemplo, está el aski, que cuando el navegador va a mostrar texto, pues comienza a leer comienza leer bytes, que son números, y luego los números ah se representan que son convertidos a letra para que el usuario pueda leer pues el contenido de un archivo. tipo el 41 se se traduce en una A, el 42 se traduce de una B, al 43 se traduce de una C. Ah, pero hay diferentes tipos de codificaciones, tipo hay codificaciones en que los números representan letras diferentes. Entonces, por ejemplo, cuando en Naski tenemos el 5C que se que que se traduce en una diagonal inversa, tipo en en una

cuidificación en de japonés, el 5C se traduce en un símbolo de yeno. Entonces, ah, a la hora que el el navegador muestra el texto del documento, este ah el en el documento se especifica que qué codificaciones estamos usando. Entonces, tipo, si usamos ASKI, cuando el navegador le da un BD 5C, vamos dar en ese caso, pero si usamos otra codificación, el 5C podría convertirse en un en un carácter diferente, que en este caso sería una llena.

Entonces, el ataque es más o menos así. Este, ah, tipo, si usaremos una etiqueta de iframe para cargar una página, ah, se puede usar el protocolo HTPS, pero también hay otros protocolos que pueden usarse, tipo puede mostrar el protocolo data. Ah, una URL data te sirve para ah ah definir todo el contenido del documento en la URL. Entonces, cuando el navegador ve una una URL de tipo data, ah, va a sacar todo el contenido del documento ah de la URL, o sea, todo el todo el documento está definido adentro de la URL. Ah. Entonces, ah, una URL data consta de tres partes. La primera parte es el tipo de archivo. En este caso le decimos

alador que es un archivo de tipo HTML. En la segunda parte es la cuificación de carácteres que le decimos al al documento qué tipo de cuidaciones estamos usando. Y la tercer la tercera parte este es el contenido del documento. Entonces en este caso el HTML ah del documento en en la tercera parte de la URL. Ah, entonces el ataque se ve más o menos así. Aquí tenemos una página con nuestros datos secretos. eh los emails, los números, todo. Y luego aquí en la arriba en la URL se ve nuestra inyección. Estamos creando un iframe con una ah URL de tipo data. Quiere decir que todo el contenido del iframe va a venir aquí en la URL. Entonces, aquí

vemos que le indicamos al al navegador que es un documento de tipo HTML. Luego le ponemos la cuificación de caracteres. Ah, el navegador por default utiliza UTF8. Y luego en la tercera parte a se pone el código del documento. Aquí viene todo el HTML. Entonces, como resultado, vemos que en la página se inyecta una cajita, un iframe donde adentro viene nuestro HTML que pusimos en la inyección. Entonces, ah, la URL está definida, está contenida por dos comillas simples, entonces es cuestión de quitar esa comida simple final. Entonces, la URL se va a tragar todo el contenido del documento. Como resultado, aquí tenemos la frame y todo el contenido del documento ah va a ser contenido por va a ser

consumido por la URL. Entonces, ahora nuestro iframe contiene todo el contenido de la página. Ahora, ahora solo es cuestión de cambiar el la cualificación. Entonces, en vez de de ponerle UTF8, vamos a cambiar de codificación para que se haga en UTF1. Entonces, como resultado, ahora todos los carácteres van a ser liquidificados en chino. Entonces, ya no vemos ah texto normal, no vemos los caracteres normales, ahora vemos ah puros carácteres chinos. Ah, entonces solo es cuestión de de inyectar una hoja de estilos. En la hoja de estilos. Ah, mandamos a a pedir una imagen. Ponemos la URL de la imagen y como vemos aquí a la URL no la cerramos con ningún paréntesis. Entonces, ahora la URL

se va a tragar todo el contenido del documento. Este el texto en vez de que liga secreto se va a convertir en chino y también todos los carácteres especiales de HTML se van a convertir a chino también. Ah, entonces ahora el navegador cuando ah haga la petición a esa URL, no va a haber ningún carácter especial, todo lo va a ver en chino. Entonces, lo voy a dejar pasar porque pues no hay HTML ahí. Aquí vemos una un una captura de pantalla en la que recibimos la petición de un navegador en la que todo el contenido de la página está siendo mandada por la URL. Solo es cuestión de de codificar a URL con un proceso un poquito

ah pues no es tan largo, pero este tiene que tiene que pasar por un proceso de recuperación para traducir todo ese chino a a carácteres asi otra vez y así obtenemos el código original de la página. Ahora, este ataque solo funciona el 19% del tiempo. Ah, porque eh las la URL de tipo data no siempre es permitida. Ah, muchas veces no la el content security policy no te deja usar URLs de tipo data, este, ah dentro de los iframes. Entonces, este ataque solo funciona el 19% del tiempo y el 80% ah es inútil. Entonces, ahora vamos a ver el segundo ataque, que este funciona el 70% del tiempo. Entonces, 19% a 70% pues es un es un es una es un buen

avance. Ah, ahora así como así como podemos usar ah las ah URLs de tipo alta adentro de iframe, también podemos usar las URL de tipo alta adentro de etiquetas de estilos. Ah, entonces aquí tenemos una hoja de estilos ah, que manda cargar una URL. Entonces este la URL es tipo data, que nos quiere decir que toda la hoja de estilos, todo el contenido de la hoja de estilos va a estar definido aquí dentro de la URL. Ah, entonces el ataque que es muy muy similar. Aquí tenemos nuestros datos secretos, tenemos todo el código HTML que queremos exfiltrar y luego inyectamos una etiqueta de estilos. Ah, y aquí en la URL ah, indicamos que que es una hoja de estilos de es un

documento tipo CSS, le pones la codificación que es un8 que es por default y luego ah en el en los hojos mandamos a llamar una imagen de una URL. La URL apunta a un dominio externo controlado por el atacante y la URL no la vamos a cerrar, ¿no? La URL se va a consumir todo el contenido de la página, ¿no? Para que se exfiltre por la petición. Ah, entonces ah, esta petición la sería bloqueada por los navegadores. Ah, porque aquí vemos que se está haciendo una petición para una URL, pero la URL contiene el código de la página. Entonces elador dice, "Wow, el código se está mandando por una por una petición." Este, entonces la bloquea. Entonces, el ataque

es cambiar la codificación de UTF8 a UTF16. Ah, así que como codificamos el código de la imagen para que esté codificado en UTF16. Ah, y todo el código de la página a la hora que se decodifique se va a decodificar en chino. Es como la petición ya no tiene en la petición no se ve ningún carácter especial, se ven puros carácteres en chino. Entonces, como en la petición no hay código HTML, ah, el navegador lo va a dejar pasar. Y este ataque es ah funcional es 70% del tiempo porque las URL data sí son permitidas ah para ser usadas dentro de etiquetas de estilo con hojas de estilo. Y ahora vamos a ver la tercera técnica y

esta función sea cual sea la configuración. Este, aunque la configuración esté sea super estricta y bloquee absolutamente todo, aún así se va a poder ah esa técnica funciona en cualquier página, sea cual sea la configuración. Ah, esta no es la técnica de la cual hablé hablé el principio. Ah, vamos a esta técnica y lo vamos a mostrar una técnica. Tipo, aquí tenemos una página en la que tenemos información valiosa, tipo una un token para antigros request forgery o cualquier información que nos gustaría poder expiltar de la cuenta de un usuario. Y arriba tenemos nuestra inyección de contenido. Entonces, la idea sería inyectar una etiqueta, un link, un hipervínculo, este, una etiqueta A. Ah, y luego tenemos el atributo GREF,

donde ponemos la URL a la que va a navegar el navegador cuando demos clic en ese hipervínculo. Entonces, de igual manera, ah, aquí tenemos que la URL está contenida por una comilla. Nos quitamos la comilla. Y ahora ah toda la la URL va a consumir el código de la página, ¿no? Ahora todo el código de la página ah es parte de la URL, todo está en rosa. Este, ahora si ah un usuario hace clic en este enlace, al navegador va a deshabilitar el enlace. El enlace va a ser desactivado por el navegador porque el navegador va a detectar que el navegador está siendo ah navegado hacia una URL y que esa URL contiene el código

de la página. Entonces, Chrome y Microsoft van a y Safari, no sé, van a a desactivar este enlace. Por más que le des click no va a funcionar. Entonces el bypass es extremadamente sencillo, es un B de browser. inyectamos un atributo target para que el link sea abierto en otra pestaña. Entonces, en vez de que el link sea abierto en la misma pestaña, el navegador va a abrir una pestaña extra ah donde cargar esta URL. Y nada más por el hecho de hacer eso, ah, el link va a ser funcionar otra vez. Entonces el enlace no funciona, pero si le indica alador que abra el enlace en otra pestaña extra, ah, el link ya va a funcionar.

Ah, entonces puede usar código de estilos para hacer el enlace ah del que abarque todo el tamaño del documento y también lo puede hacer emisible. Entonces, en cuanto el usuario de el el navegador de clic en cualquier parte, ah, el el navegador va a ser una petición a un amigo del atacante que va a exfiltrar todo el contenido HTML de la página. Ah, luego puede hacer una redirección car usario a la misma página en la que estaba y todo va a ser invisible. Ah, luego también hay una cuera técnica, pero por cuestión de tiempo ahorita no la voy a poder exponer. Este, aparte de esa técnica no la no la encontré yo. Ah, pero si si les interesa

la pueden buscar después en las diapositivas, pues me lo voy a saltar. Y ahora llegamos a la parte final de la página de la plática en la que vamos a ver cómo evadir el content security policy, aunque los formularios no puedan ser enviados a ningún otro dominio. Tipo, sería útil mencionar que hay una una cabecera HTP que se llama la cabecera. Entonces, si tenemos aquí un dominio, un dominio, si tenemos aquí un enlace, un link, un hipervínculo ah que apunta hacker.com diagonal de inicio. En cuanto el usuario de clic en el en el enlace, ah, el navegador ah va a ser va a ser navegado hacia esta URL. Nos va a ser una petición HTTP que se ve

más o menos así. Es una petición de tipo GET que pide un recurso. Ah, le ponemos el host y luego el navegador también va a mandar otra cabeada que se llama reverter. La cabecera Feder le dice a Arcur solicitado a de dónde viene el navegador, o sea, desde dónde ah en qué página estaba el usuario. Cuando le dio clic a ese enlace, el refer te da la URL de dónde viene el navegador. Cuando intentamos hacer una petición para crear una imagen, ah, se hace lo mismo. Ah, se manda el navegador hace una petición HCTP que manda a pedir la imagen, solicita la imagen y luego se envía la caifera referer que te dice desde qué página se está mandando pedir

la imagen. Este, disculpe, se está se movió el proyector. Entonces, el ataque más o menos va más o menos así.

Si ya el ataque va se va más o menos así. Imaginemos que la página vulnerable se llama vulnerable.ASASPX. Y luego el parámetro vulnerable se llama XSS y ahí tenemos nuestra inyección de código. Entonces, la página vulnerable.x se ve más o menos así. Tenemos información secreta, tenemos código HTML este que queremos exfiltrar y arriba tenemos nuestra inyección de contenido, ¿no? O sea, el parámetro X es ese. Entonces este primero se inyecta una caja de texto ah, que es el textaria, la caja de texto y la caja de texto se va a tragar todo el sistema de la página, ¿no? Entonces luego esa caja de texto se puede enviar a otro lugar. Este, luego se inyecta un botón de

enviar y un botón de enviar, un botón de tipo submit ahí con estilo puede hacer que el botón sea invisible y enorme o puede ser lo que sea. Este, y luego ah se inyecta una etiqueta de formulario ah que va a enviar el contenido acá del texto y este formulario se va a enviar a la misma página en la que ya estamos, ¿no? Entonces, tenemos una una página vulnerable, inyectamos una caja de texto y esa caja de texto va a ser enviada a esta misma página en la que ya estamos. Pues aquí no hay ningún problema porque es el mismo dominio, ¿no? Este el navegador aunque te el con security policy te va a dejar enviar el

formulario porque pues está está siendo enviada al mismo lugar en el que está, no es ninguna página externa. Y luego la última parte es ah inyectar un ah otro parámetro que es el parámetro XSS, ¿no? Ah, que es el parámetro vulnerable. Entonces ah este parámetro vulnerable va a tener una inyección que va a ser inyectada en la misma página, ¿no? Por por la por el mismo parámetro vulnerable. Ah, esta nueva inyección es una etiqueta de imagen. Se ve más o menos así. Ah, es es una imagen que manda a pedir una imagen de un dominio extraño controlado por el atacante y se pone el atributo refery para que mande la cabeza Referer. Entonces, cuando esta imagen ah

se pida por este se pida al usuario, el navegador va a enviar la cabeza y va a indicar desde dónde se está pidiendo la imagen y se va a enviar a pues toda la URL donde el usuario está. Entonces, el ataque ya que lo juntas más o menos así, ¿no? Tenemos aquí una página que tiene todos los datos secretos. tenemos ah pues un datos privados. Ah, luego aquí arriba tenemos nuestro nuestra inyección. Entonces, lo que vamos a hacer va a ser a inyectar una caja de texto para que la caja de texto consuma todo el código de la página. Luego se va inyectamos nuestro botón de enviar. Y aquí podemos ver que la etiqueta de

formulario está usando el método get. Eso quiere decir que todo el contenido del formulario se va a enviar por la URL. Entonces, en cuanto le demos clic al botón enviar, ah, la información va a ser enviada a la misma página en la que ya estamos, pero la información se va a enviar por la URL porque usamos el método get. Entonces ahora la URL contiene todo ah el código del documento. Entonces luego cuando se inyecta la imagen que pide una imagen en un dominio externo controlado por el atacante, a la hora que el navegador haga la petición HTP para pedir la imagen, se va a enviar la cafa, la cabecera referir. Entonces se va a enviar la URL a de

donde se hizo la petición y como ahora todo el código está en la URL, ah, vamos a poder ah se se vamos a poder filtrar todo el continuo del documento. Aquí tenemos un un screenshot este donde pues recibimos una conexión que está pidiendo una imagen y luego vemos que se envió la etiqueta referer y luego en la etiqueta referer se ve toda la URL y ahora como toda la URL este contiene ah pues los otros del formulario, vamos a poder ver todo el contenido que se exiltró en la petición. Ah, a veces hay diferentes maneras de poder exfiltrar la URL. Este, ah, tipo a veces cuando dice security policy dice que las que no se pueden

cargar imágenes de medios externos. Entonces, en ese caso, podemos cargar fuentes, podemos cargar scripts, podemos cargar estilos, podemos cargar archivos de audio, este si las imágenes no son permitidas y en caso de que nada sea permitido, podemos hacer una redirección con una etiqueta meta. Entonces ah en cuanto con la etiqueta meta, el navegador va a ser redirigido a la página del atacante y en la en las cabeceras de la petición se va a ver el referer que revela todo el contenido de la URL, ¿no? Donde está el a los datos envies por el formulario. Este, en caso de que nada funciona, podemos hacer un un link. Ah. Y ahora ah, de todas las de de todas las

páginas que usan Forum Action, que eran bien poquitas, que era como el 17%, este, de las que están ahí configuradas, el 91% lo tiene en self para que los formularios se puedan enviar a al mismo dominio. Entonces, quiere decir que que si podemos enviar un formulario al mismo dominio, podemos usar el método de get para que todo se demande por la URL y luego podemos obtener la URL a por la cabeza refer y este tal que funciona el 91% del tiempo. Este, eso quiere decir que ah de todas las aplicaciones cuyo formation fue roto e en todas las aplicaciones que usan con security policy, el 98% de ellas aún así pueden ser explotadas con esos

ataques, lo cual quiere decir que ah casi siempre casi casi siempre van a poder explotar su vulnerabilidad con esta técnica, aunque el Security Policy est configur

Ah, creo que tenemos tiempo para hacer un un demo. M.

Aquí tenemos nuestra página con con nuestros datos secretos. En este caso tenemos ah unos números de teléfono. Ah, aquí tenemos nuestra inyección. Entonces, inyectamos covers HTML. Aquí vemos que pudimos subrayar todo el el contenido de la página. Tenemos una inyección. Entonces, el ataque se ve más o menos así. Tenemos una caja de texto ah que se puede hacer invisible. También tenemos un un botón de tipo enviar submit. Ah, para enviar esta caja de texto con estilo hacemos el botón de enviar completamente invisible. Luego e eh inyectamos un segundo parámetro en una segunda división de nuestro parámetro que básicamente manda llamar a pedir una imagen que está en un dominio controlado por el atacante y le ponemos que mande la cabeza a la

hora de pedir esta imagen. Ponemos ah la política de seguridad y luego este ponemos que el formulario se envíe la misma página por el método get. Entonces con con GET todo el formulario se se envía por la URL y como le enviamos en la misma página el formulario va a poder ser enviado. Ahora, eso es cosa de ah juntar todo nuestro ataque. Lo copiamos. Lo copiamos. Ah, y luego vamos a vamos a iniciar un servidor web que va a a esperar a la petición por esa imagen. Aquí estamos escuchando en el cuerpo en el puerto 444.

En astro inyección vamos a mandar nuestro ataque, lo vamos a a pegar ahí o se lo vamos a enviar a nuestra víctima. A la hora que la víctima abre el link. Ah, la caja de texto. Ahora tiene todo el código de la página. También se inyecta una imagen, se inyecta un botón invisible. Entonces, en cuanto al usuario de clic en el botón, del lado derecho recibimos una petición. está pidiendo ah una imagen. Aquí tenemos conexión recibida. Ah, y aquí en en el cabecita de referiltrar toda la URL donde viene el navegador y esa URL ahora tiene todo el contenido de del documento.

Okay, esas son las otras técnicas que no vamos a poder ver porque ya se nos acabó el tiempo, pero les sugiero mucho que la chequen porque son superútiles. Es la tercer técnico. Entonces, para concluir, tenemos tres conclusiones. que la aplicación es explotable si no usa la directiva Form Action para [Música] proteger los formularios. La gran la gran mayoría de los sitios lo usan from action, entonces el 8% del tiempo puedes explotar la aplicación como si no estuviera protegida. Ahora, aunque use la directiva Form Action, pueden ser otras, ¿no? Aunque aún si Form Action está en self, ah, todavía se puede usar formularios para enviar el el formulario a otro dominio y ese es en el 87% de los casos.

Ah, si la si la aplicación no tiene nada información ahí, puedes usar el el el login para extción de los usuarios. Y eso es altamente probable que ocurra porque mucha gente usa la función de de iniciar sesión en Chrome y cuando los format cuando el formulario ni siquiera puede ser enviado a la misma página porque está en on puedes usar los ataques de de malcabello completo ah para llevarse la información. Ah. Ah. Esta algunos de esos ataques fueron publicados en 2011, pero cuando yo los encontré no estaba no estaba no sabía que ya habían sido publicados. Ah, pero eso fue en el 2011, así casi como 20 años y nadie ha dicho nada al respecto. Entonces, creo que estuvo bien

hablar de esto. Y eso es todo. Si quieren encontrar el artículo escrito donde lleno todo detalladamente, está en la página 48.org. o pueden buscarla en mi exonedo. Muchas gracias. E un gran aplauso para Rubén, una de las conferencias que ha tenido POC en este PS 2025. Gracias, Rubén. Así que nos da tiempo para unas rápidas preguntas. ¿Alguien tiene alguna pregunta sobre la exposición de Rubén? Sí, claro. Hola. Eh, bueno, me causa curiosidad, cuando cambiaste la codificación de 8 a 16, sí, eso se podría haber logrado también insertando la etiqueta meta para definir el charset. O lo lo que pasa es que ah el el navegador ah solo le hace caso a la etiqueta meta si en la respuesta del servidor no está

definido el la cuification del content type, tipo cuando el servidor ah manda la respuesta con todas las cabeceras, hay una cabecera que se llama content type en la que usualmente viene definido a el en la codificación de caracteres. Entonces, casi siempre está definido ahí. Si está definido ahí, ah, el navegador le va a dar prioridad a la cabecera y la etiqueta meta la va a ignorar. Entonces, para eso habría que encontrar un servidor que no regrese, que no tenga la cabeza de content type, pero casi siempre está ahí. Entonces, pues básicamente tienes que abrir un para poder cambiar de la acuidificación. Gracias. Sí. ¿Alguien más tiene alguna pregunta sobre la exposición de Rubén? No. Pues entonces un aplauso a Rubén,

por favor.

Y vamos a estar preparando ahorita la presentación de nuestro amigo Bob, que