Rimozione della stringa di cookie di Google Analytics dall'URL: buco di sicurezza?

Question

Rimozione della stringa di cookie di Google Analytics dall'URL: buco di sicurezza?

#1 da (1 voti)
#2 da (1 voti)

2

Sul nostro sito utilizziamo google analytics e dobbiamo inserire il cookie GA nell'URL poiché abbiamo un dominio a due lettere e IE impone alcune limitazioni sui cookie. Ciò significa che quando si passa da un sottodominio a questi URL lunghi si aggiunge la stringa di cookie aggiunta dopo un hash:

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

Quindi, ho aggiunto questo codice:

(* 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]);
    }
});

Dopo aver guardato un discorso a Jfokus di John Wilander dove ha menzionato uno specifico problema di sicurezza di Twitter , sono diventato un po 'nervoso.

La mia domanda è: Il mio piccolo hack potrebbe introdurre buchi di sicurezza, XSS o altri? Non pensare , quindi suppongo tu abbia sentito che prima.

Aggiornamento:

Forse dovrei chiarire la mia domanda forse un po 'poco chiara: ho sospettato che non stavo avendo lo stesso identico problema di sicurezza di Twitter, ma visto che sto facendo cose simili mi chiedo se ci sono altre vulnerabilità nel mio codice?

javascript xss

posta Peter Jaric 16.02.2012 - 13:11

fonte

2 risposte

1

Nell'esempio collegato c'è il seguente problema: Twitter ha cercato di rilevare qualsiasi cosa dopo l'hashbang e di aggiungerlo all'URL corretto. Lo hanno fatto nel modo seguente:

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

In teoria il browser ora imposterà l'URL su tutto ciò che sta dietro l'hashbang. Quindi, se l'url fosse twitter.com/#!/user/someone , l'URL verrebbe impostato su twitter.com/user/someone (in pratica si aggiunge /user/someone a twitter.com , poiché il browser si rende conto che non è stato fornito alcun protocollo / nome host). Il problema con questo approccio è che se l'URL è twitter.com/#!javascript:alert('Hello World') il browser proverà ad interpretare il codice javascript (poiché il browser non lo aggiunge ora a twitter.com, ma imposta window.location a javscript:alert('Hello World') ) . Identificherà javascript: come protocollo, quindi prova ad eseguire tutto dopo di esso in base alla definizione del protocollo.

Hanno risolto in questo modo:

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

Invece di impostare direttamente window.location (che è pericoloso come mostrato sopra) ora impostano semplicemente l'hash della posizione (tutto dopo # ) su una stringa vuota e impostano il percorso sulla proprietà pathname, che non eseguire il codice javascript. Perché? La proprietà window.location consente al protocollo di cambiare (ad esempio da http a javascript se così definito).

Quindi nel tuo caso dovresti stare bene (almeno questo attacco non funzionerà). Perché? Spoglia semplicemente tutto dopo il primo # (anche l'aggiunta di due # non aiuterà, poiché sarà divisa sul primo # ). Quindi la stringa impostata su window.location inizierà sempre con il protocollo corrente e il tuo host, e mai con javascript: , quindi il browser non tenterà mai di eseguire qualcosa.

risposta data 16.02.2012 - 14:27

fonte

Leggi altre domande sui tag javascript xss

domanda relativa ai tag implicitamente in ASN.1 Questa tecnica è un modo sicuro per confermare i dettagli del conto bancario di un utente, senza richiedere che forniscano le proprie credenziali?

score 1 · Accepted Answer

Il buco di Twitter era che non controllavano che l'URI fornito nell'identificatore di frammento fosse quello che si aspettavano che fosse (un percorso relativo alla radice). Potrebbe essere qualsiasi altro URI, incluso un sito esterno, o (cosa ha causato l'XSS), un URI non-localizzatore (ah, javascript: URI-come vorremmo non fosse mai stato inventato).

Non hai questo buco qui perché (a) stai riutilizzando lo schema e il nome host dall'URI del documento esistente, che deve necessariamente essere un URI di localizzazione, e (b) stai usando replaceState : questo aggiorna solo il percorso apparente visualizzato nella barra degli indirizzi e in realtà non naviga verso l'indirizzo di destinazione.

Potresti usare location.path+location.search come metodo alternativo per ottenere la parte del percorso root senza preoccuparti di dividere manualmente le altre parti.

Il modo in cui gestisci la re-iniezione dei cookie e la possibilità che i cookie analitici vengano facilmente falsificati / trapelati potrebbe avere altre implicazioni.