¿Cómo protege pushState contra posibles falsificaciones de contenido?

Question

Como se ve en GitHub's blog, han implementado la función HTML5's JavaScript pushState para la exploración de árbol (para navegadores modernos), que trae navegación AJAX without Hash Bangs.

El código es simple:

$('#slider a').click(function() { 
    history.pushState({ path: this.path }, '', this.href) 
    $.get(this.href, function(data) { 
    $('#slider').slideTo(data) 
    }) 
    return false 
}) 

Esta muy elegantemente les permite:

1. Solicitud de los justos el nuevo contenido a través de AJAX en lugar de una página completa
2. animar la transición
3. Y cambiar los navegadores URL (no solo el #, como Twitter hace — twitter.com/stackexchange → twitter.com/#!/stackexchange)

Mi pregunta es, ¿cómo evitar que JavaScript contra el uso de pushState por un sitio a imitar a otra, lo que resulta en un contundente phishing attack?

Por lo menos, parece que el dominio no se puede cambiar, pero ¿qué hay de las múltiples rutas dentro de un sitio, potencialmente por múltiples proveedores de contenido no relacionados y desconfiados? ¿Podría una ruta (I.E. /joe) imitar esencialmente otra (pushState /jane) y proporcionar contenido imitativo, con fines posiblemente maliciosos?

Answer 1

Según entiendo, esto es perfectamente coherente con Same Origin Policy que rige XMLHttpRequest, configuración de cookies y varias otras funciones del navegador. La suposición es que si está en el mismo dominio + protocolo + puerto, es un recurso confiable. Usualmente, como desarrollador web, eso es lo que quiere (y necesita) para que sus scripts AJAX funcionen y sus cookies sean legibles en todo su sitio. Si está ejecutando un sitio donde los usuarios pueden publicar contenido, es su trabajo, no el del navegador, para asegurarse de que no puedan phishing o keylogue los visitantes de los demás.

Aquí hay algunos más detail on what the FireFox folks are thinking about pushState - no parece que esto sea un problema para ellos. Hay otra discusión de possible pushState security hole here, pero es una preocupación diferente, acerca de poder ocultar una cadena de consulta maliciosa al final de la URL de otra persona.

Answer 2

Como nrabinowitz ha declarado y en términos más sencillos: está limitado al mismo dominio, al igual que las llamadas ajax y las cookies. Por lo tanto, es completamente seguro, aunque un poco astuto para el usuario final.

nosotros (los desarrolladores) hemos estado haciendo esto para siempre con etiquetas de hash para siempre, pero es mejor porque:

1. Se ve más limpio.
2. Al volver a visitar un enlace profundo, puede visualizar datos html reales para respaldar cosas como SEO y Facebook Open Graph (ambos envían arañas para escanear el html de su página).
3. Los servidores no tienen acceso a los datos de las etiquetas hash, por lo que no los ve en los registros de su servidor, por lo que ayudan a algunos con los análisis.
4. Ayuda a corregir problemas de etiquetas hash. Por ejemplo, tuve una reescritura Nginx para redirigir a los usuarios que visitan mi aplicación a la misma url https.Funciona en todos los navegadores, pero Safari lo redirigirá al dominio sin el hash (¡tan molesto!)