In che modo pushState protegge da potenziali contraffazioni di contenuti?

Question

Come visto in GitHub's blog, hanno implementato la funzione HTML5's JavaScript pushState per la navigazione ad albero (per i browser moderni), portando la navigazione AJAX without Hash Bangs.

Il codice è semplice:

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

Questo permette loro molto elegantemente a:

1. Richiesta il proprio l'nuovi contenuti attraverso AJAX invece di una pagina intera
2. animare la transizione
3. E cambiare l'URL del browser (non solo lo #, come Twitter fa — twitter.com/stackexchange → twitter.com/#!/stackexchange)

La mia domanda è, come si fa a prevenire JavaScript contro l'uso di pushState da un sito web di imitare un altro, con un conseguente convincente phishing attack?

Per lo meno sembra che il dominio non possa essere modificato, ma per quanto riguarda i percorsi multipli all'interno di un sito, potenzialmente da più fornitori di contenuti indipendenti e non fidati? Potrebbe un percorso (I.E. /joe) essenzialmente imitare un altro (pushState /jane) e fornire contenuto imitativo, con possibili scopi dannosi?

Answer 1

La mia comprensione è che questo è perfettamente coerente con lo Same Origin Policy che regola XMLHttpRequest, l'impostazione dei cookie e varie altre funzioni del browser. L'ipotesi è che se si trova sullo stesso dominio + protocollo + porta, è una risorsa attendibile. Di solito, come sviluppatore web, è quello che vuoi (e hai bisogno) affinché i tuoi script AJAX possano funzionare e i tuoi cookie siano leggibili sul tuo sito. Se stai eseguendo un sito in cui gli utenti possono pubblicare contenuti, è il tuo lavoro, non quello del browser, per assicurarti che non possano phish o keylog i rispettivi visitatori.

Ecco alcuni altri detail on what the FireFox folks are thinking about pushState - non sembra che questo sia un problema per loro. C'è un'altra discussione su un possible pushState security hole here, ma è una preoccupazione diversa, riguardo alla possibilità di nascondere una querystring dannosa alla fine dell'URL di qualcun altro.

Answer 2

Come nrabinowitz ha dichiarato e in termini più profani: è limitato allo stesso dominio, proprio come le chiamate e i cookie di un jax. Quindi è completamente sicuro, anche se un po 'subdolo per l'utente finale.

Us (sviluppatori) fatto questo per sempre con i tag hash per sempre ma è meglio perché:

1. Sembra più pulito.
2. In caso di rivisitazione di un link diretto, puoi effettivamente visualizzare dati html reali per supportare cose come SEO e Facebook Open Graph (entrambi inviano gli spider per scape l'html della tua pagina).
3. I server non hanno accesso ai dati dei tag hash in modo che non vengano visualizzati nei registri del server, quindi sono utili per l'analisi.
4. Aiuta a risolvere i problemi dei tag hash. Ad esempio, ho avuto una riscrittura Nginx per reindirizzare gli utenti che visitano la mia app allo stesso URL https.Funziona su tutti i browser, ma Safari che ti reindirizza al solo dominio senza l'hash (così fastidioso!)