Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
Google Chrome 4: Bypassing Javascript Filter
No hace mucho, en una de sus últimas actualizaciones silenciosas, Google Chrome introdujo, en el interfaz de usuario gráfico, la opción de bloquear Javascript en determinadas URLs. Esta es una opción que permite evitar problemas de ataques derivados de sitios maliciosos o vulnerados que buscan engañar o atacar al usuario por medio de Javascript. Por seguridad, un usuario puede decidir deshabilitar javascript en un conjunto de URLS. Sin embargo, un compañero en el SOCtano se encontró con esta sencilla forma de saltarselo.
El funcionamiento es el siguiente, supongamos esta URL http://www.java2s.com/. En ella, se puede comprobar que Javascript está habilitado y funcionando. Basta con pedirla directamente en el navegador y hacer un clic en el botón para comprobar como Javascript funciona.
Figura 1: Javascript habilitado en http://www.java2s.com/
Ahora bien, haciendo uso de la función de deshabilitar Javascript en este sitio procedemos a bloquearlo.
Figura 2: Bloqueo del sitio en Google Chrome
Una vez hecho esto, si se intenta acceder al sitio web bloqueado, se obtiene una página web en la que no se ha activado Javascript.
Figura 3: Javascript Bloqueado
Ahora cerramos el navegador - esto es importante pues si en la misma sesión se ha bloqueado ya una vez el sitio, no lo habilita más - y abrimos el sitio web dentro de un iframe y lo que se obtiene, a pesar de que la URL está bloqueada, es que se carga la página con Javascript.
Figura 4: Javascript ejecutándose a pesar de estar bloqueado
Como no queríamos actuar mal, decidimos avisar a Google para que lo parchease si quisiera antes de publicarlo. Sin embargo, parece que esto es la forma normal en que funciona. Esta es la respuesta oficial que hemos recibido.
Figura 5: Respuesta oficial
Lo que viene a decir:
"Esto funciona como debiera. Las opciones de contenido para imágenes, Javascript, Plugings, popups funcionan sólo en la barra general y no en la URL del recurso.
La idea es que se debe bloquear Javascript siempre y confiar sólo en ciertos sitios. Esto permitirá que todo el contenido Javascript incluido en esos sitios, directametne o vía iframes, sea ejecutado.
También asumimos que el usuario medio no tiene ni idea de lo que es un iframe...
Quizá una futura versión de Chrome haga filtrado de contenido basandose en la URL del recurso"
Bueno, pues ahí es nada. Así funciona este filtrado. Al no hacer la comprobación en base a la URL del recurso, cualquier iframe puede saltarse el filtro. Así, una web permitida podrá ejecutar todo el código javascript/cargar plugins/abrir popups/abrir imágenes de cualquier lugar del mundo. Así, si abres el javascript a tu sistema de webmail y alguien te manda un mail en html o entras en una web en la que se ha metido un iframe, no importa si está bloqueado, te lo comes con patatas.
En fin, que lo que más me ha gustado ha sido lo que el usuario medio no sabe lo que es un iframe... El estatus de esto es: WontFix
Figura 7: Status WontFix
Es decir, que esto va a seguir siendo así hasta una futura versión en la que quizá cambien el comportamiento del filtro... "¿de seguridad?". Estas configuraciones a medias crean una falsa sensación de seguridad que suele ser contraproducente a la larga.
UPDATE: Parece ser que han seguido en el caso y han decidido cambiar el Status a Available, han cambiado el título del bug y van a hacer algo al respecto. Bien.
Saludos Malignos!
El funcionamiento es el siguiente, supongamos esta URL http://www.java2s.com/. En ella, se puede comprobar que Javascript está habilitado y funcionando. Basta con pedirla directamente en el navegador y hacer un clic en el botón para comprobar como Javascript funciona.
Figura 1: Javascript habilitado en http://www.java2s.com/
Ahora bien, haciendo uso de la función de deshabilitar Javascript en este sitio procedemos a bloquearlo.
Figura 2: Bloqueo del sitio en Google Chrome
Una vez hecho esto, si se intenta acceder al sitio web bloqueado, se obtiene una página web en la que no se ha activado Javascript.
Figura 3: Javascript Bloqueado
Ahora cerramos el navegador - esto es importante pues si en la misma sesión se ha bloqueado ya una vez el sitio, no lo habilita más - y abrimos el sitio web dentro de un iframe y lo que se obtiene, a pesar de que la URL está bloqueada, es que se carga la página con Javascript.
Figura 4: Javascript ejecutándose a pesar de estar bloqueado
Como no queríamos actuar mal, decidimos avisar a Google para que lo parchease si quisiera antes de publicarlo. Sin embargo, parece que esto es la forma normal en que funciona. Esta es la respuesta oficial que hemos recibido.
Figura 5: Respuesta oficial
Lo que viene a decir:
"Esto funciona como debiera. Las opciones de contenido para imágenes, Javascript, Plugings, popups funcionan sólo en la barra general y no en la URL del recurso.
La idea es que se debe bloquear Javascript siempre y confiar sólo en ciertos sitios. Esto permitirá que todo el contenido Javascript incluido en esos sitios, directametne o vía iframes, sea ejecutado.
También asumimos que el usuario medio no tiene ni idea de lo que es un iframe...
Quizá una futura versión de Chrome haga filtrado de contenido basandose en la URL del recurso"
Bueno, pues ahí es nada. Así funciona este filtrado. Al no hacer la comprobación en base a la URL del recurso, cualquier iframe puede saltarse el filtro. Así, una web permitida podrá ejecutar todo el código javascript/cargar plugins/abrir popups/abrir imágenes de cualquier lugar del mundo. Así, si abres el javascript a tu sistema de webmail y alguien te manda un mail en html o entras en una web en la que se ha metido un iframe, no importa si está bloqueado, te lo comes con patatas.
En fin, que lo que más me ha gustado ha sido lo que el usuario medio no sabe lo que es un iframe... El estatus de esto es: WontFix
Figura 7: Status WontFix
Es decir, que esto va a seguir siendo así hasta una futura versión en la que quizá cambien el comportamiento del filtro... "¿de seguridad?". Estas configuraciones a medias crean una falsa sensación de seguridad que suele ser contraproducente a la larga.
UPDATE: Parece ser que han seguido en el caso y han decidido cambiar el Status a Available, han cambiado el título del bug y van a hacer algo al respecto. Bien.
Saludos Malignos!
11 comentarios:
Que casualidad, parece que has elegido el dia a drede. La ultima actualización de Google Chrome fue ayer dia 25, hahaha. Por eso les debió sentar tan mal }:)
/TS
habrá que reformular la vieja frase:
"in google we trust!"
ains...
Vaya tela... Pues ahora que han cambiado el estado ya podrían dar las gracias por avisarles. Muy "sí, sí, esto está así a propósito" y después se ponen a solucionarlo.
Un poco feo. Para mi que el tio que contesto no estaba muy por la labor.. porqué eso del usuario medio tiene tela!
Saludos
@Newlog, no van a hacer nada a corto plazo... ya si eso en alguna versión futura...
Creo que has encontrado el mismo 'bug', o algo muy parecido, al que encontró un tio ruso en Febrero, y ademas en la versión 5.
Bug report
Tambien marcado 'Wontfix".
El problema con esto es que siempre lo lee primero el "becario" borde y luego llega el tio que sabe de que va el asunto y pone las cosas en su sitio, aunque luego no hagan nada.
A mi me paso con un bug en PHP: http://bugs.php.net/bug.php?id=51068 que aun estoy esperando que lo cierren...
@anónimo, creo que se basa en el mismo problema sí, pero no estaba reportado en la versión 4 y no es sólo para el AntiXSS sino para todo el bloqueo de javascript. Pero sí, creo que la base del problema es la misma.
Saludos!
Interesante!
Lo del usuario medio manda huevos.
Así van las cosas, ciertos usuarios no quieren saber nada, mientra todo funcione ya está bien y el proveedor siempre se aprovecha de esa situación y cuando algún técnico pregunta sobre la causa de algo que cree que no está funcionando correctamente en su producto, lo normal es no asumir el error, aunque si lo sea, y se opta por salir por la tangente, ya sea justificando sobre un comportamiento ajeno o metiendo algún tecnicismo, que con un poco de suerte el que está al otro lado no se entera y tampoco va a querer o va a tener tiempo para investigar un poco sobre el tema, y este caso se adopta como que es normal y realmente no lo es y te han colado el gol.
Con esto no quiero decir que tengamos que ser perfectos, ya que todos los humanos nos equivocamos, es algo intrínseco, lo que jode es que no se reconozcan los errores, pero claro queda muy decir que se te ha pasado o te has equivocado cuando lo que quieres es vender algo de manera masiva, así que más vale mentir.
Yo valoro más que reconozcan los errores y que se tomen medidas para que en el futuro hayan menos que hayan menos pero que cuando se encuentren algunos no se reconozcan y se queden en nada; como parece lo que iba a pasar en este caso.
@maligno,
Hay un poco de malicia en el título de tu post:
No siempre se puede eludir el filtro, sólo se puede hacer en un caso específico. Por lo demás, cualquier usuario preocupado por la seguridad bloque todo en general y permite sólo lo que le interesa.
Aprovecho de preguntar (lo siento, soy un simple usuario) cómo hacer lo mismo en ie8. Trato de bloquear todo en general usando la zona de internet, y permitir sólo lo que interesa a través de las zona de confianza. Sin embargo muchas páginas no me funcionan: bancos, servicios públicos, etc. Sólo me queda bajar la seguridad en general para subirla al terminar, situación que no es útil cuando uno abre distintas páginas a la vez, y no todas de confianza. Antes, cuando usaba Firefox podía bloquear todo con NoScript, y permitir exactamente lo indispensable, y me gustaría hacer lo mismo en ie8.
Hola "Usuario principiante"
no, no hay malicia. De hecho he sido bastante polite. El filtro de contenido, como han confirmado en el expediente del seguimiento de este fallo (que no han cerrado de momento) sólo se aplica a las URL introducidas en la barra de direcciones y no a la URL del recurso.
Esto implica que, aunque hayas bloqueado todo menos una dirección, con conseguir que la dirección principal sea la autorizada, el resto de las cosas que se carguen se saltará el filtro. Internamente han puesto un ejemplo con Google y frames.
Por cierto, el fallo este, sigue también en Chrome 5.
Respecto a como se hace con IE8, bueno... seguro que si miras con cuidado las opciones encuentras como se hace ;)
Saludos "calidos".
@maligno,
Tienes razón, menos mal que no uso chrome!!
Ahora, sigo sin poder iniciar sesión en www.live.com , permitiendo todo en los sitios de confianza. Estoy pensando seriamente en volver a Firefox+NoScript !!
Publicar un comentario