Eliminando la cadena de cookies de Google Analytics de la URL - ¿agujero de seguridad?

Question

Eliminando la cadena de cookies de Google Analytics de la URL - ¿agujero de seguridad?

#1 de bobince (1 votos)
#2 de Andreas Arnold (1 votos)

2

En nuestro sitio, usamos Google Analytics y tenemos que poner la cookie GA en la URL ya que tenemos un dominio de dos letras e IE impone algunas limitaciones de cookies. Esto significa que al pasar entre subdominios obtenemos estas URL largas con la cadena de cookie adjunta después de un hash:

http://test.ab.la#_utma=what_have_you&_utmc=something_else&so=on&so=on

Entonces, agregué este código:

(* Remove fragment (the part after #) from URL if it contains a Google Analytics cookie.
   We do this to hide the extremely long URLs that otherwise will be visible to the users.
   Will not work in IE and other browsers that do not support history.replaceState().
   Use GA's push functionality to do this to make sure the page has been tracked before
   removing cookie information.*)
_gaq.push(function() {
    if (window.history &&
        window.history.replaceState &&
        location.href.indexOf("__utma") > 0) {
        window.history.replaceState({}, "", document.location.href.split("#")[0]);
    }
});

Después de ver una charla en Jfokus por John Wilander donde mencionó un problema específico de seguridad de Twitter , me puse un poco nervioso.

Mi pregunta es: ¿Mi pequeño truco anterior introducirá algún agujero de seguridad, XSS u otros? No creo que , pero supongo que has oído eso antes.

Actualizar:

Tal vez debería aclarar mi pregunta, quizás algo poco clara: sospechaba que no tenía exactamente el mismo problema de seguridad que el de Twitter, pero como estoy haciendo cosas similares, me pregunto si hay algún otras vulnerabilidades en mi código?

xss javascript

pregunta Peter Jaric 16.02.2012 - 13:11

fuente

2 respuestas

1

En el ejemplo vinculado hay el siguiente problema: Twitter intentó detectar cualquier cosa después del hashbang y agregarlo a la URL propiamente dicha. Lo hicieron de la siguiente manera:

a = location.href.split("#!")[1]
window.location = a

En teoría, el navegador ahora establecerá la URL a todo lo que hay detrás del hashbang. Entonces, si la url fuera twitter.com/#!/user/someone , establecería la URL en twitter.com/user/someone (básicamente agregar /user/someone a twitter.com , ya que el navegador se da cuenta de que no hay un protocolo / nombre de host dado). El problema con este enfoque es que si la URL es twitter.com/#!javascript:alert('Hello World') , el navegador intentará interpretar el código javascript (ya que el navegador no lo agrega ahora a twitter.com, sino que establece window.location a javscript:alert('Hello World') ) . Identificará javascript: como el protocolo y, por lo tanto, tratará de ejecutar todo lo que sigue después de esa definición de protocolo.

Se resolvieron de esta manera:

a = location.href.split("#!")[1]
window.location.hash = ""
window.location.pathname = a

En lugar de establecer el window.location directamente (lo cual es peligroso como se muestra arriba), ahora simplemente configuran el hash de la ubicación (todo después de # ) en una cadena vacía y establecen la ruta en la propiedad de nombre de ruta, que no No ejecute el código javascript. ¿Por qué? La propiedad window.location permite que el protocolo cambie (por ejemplo, de http a javascript si está definido).

Entonces, en tu caso, deberías estar bien (al menos este ataque no funcionará). ¿Por qué? Simplemente elimine todo después de el primer # (también agregar dos # no ayudará, ya que se dividirá en el primer # ). Por lo tanto, la cadena establecida en window.location siempre comenzará con el protocolo actual y su host, y nunca con javascript: , por lo que el navegador nunca intentará ejecutar nada.

respondido por el Andreas Arnold 16.02.2012 - 14:27

fuente

Lea otras preguntas en las etiquetas xss javascript

¿El servidor / aplicación de correo electrónico debe estar protegido por una autenticación de 2 factores? ¿Qué aplicaciones deben protegerse? ¿Las instalaciones COMET son inmunes a la DoS de "lectura lenta de TCP" en Windows? (Como SignalR o WebSync)

score 1 · Accepted Answer

El agujero de Twitter fue que no comprobaron que el URI proporcionado en el identificador del fragmento era lo que esperaban que fuera (una ruta relativa a la raíz). Podría ser cualquier otro URI, incluido un sitio externo, o (lo que causó el XSS), un URI sin localización (ah, javascript: URIs: cómo todos deseamos que nunca hayas sido inventado).

No tiene este agujero aquí porque (a) está reutilizando el esquema y el nombre de host del URI del documento existente, que necesariamente debe ser un URI de ubicación, y (b) está usando replaceState : esto solo actualiza la ruta aparente que se muestra en la barra de direcciones, y en realidad no navega a la dirección de destino.

Podría usar location.path+location.search como una forma alternativa de obtener la parte de ruta de acceso sin molestarse en dividir las otras partes manualmente.

La forma en que maneja la reinyección de las cookies, y si le preocupa que las cookies de análisis sean falsificadas o filtradas fácilmente, podría tener otras implicaciones.