Oggi ho trovato un sito interessante che mostra il valore del tuo cookie direttamente sulla pagina, quindi se modifico il valore del cookie posso usare XSS da solo.
per esempio <span id=statistics>Last visit: Cookie_Value_Of_Something</span>
Quindi la mia domanda è, pensi che questo sia vulnerabile o posso sfruttarlo?
Finora mi sembra inutile.
Per sfruttare questo difetto, l'utente malintenzionato dovrebbe manipolare il cookie dell'utente. E questo è possibile solo se è in grado di sfruttare un'altra vulnerabilità che gli consente di impostare il cookie con il carico utile XSS come uno può solo impostare i cookie all'interno del dominio il Set-Cookie originato da :
The user agent will reject cookies unless the Domain attribute specifies a scope for the cookie that would include the origin server. For example, the user agent will accept a cookie with a Domain attribute of "example.com" or of "foo.example.com" from foo.example.com, but the user agent will not accept a cookie with a Domain attribute of "bar.example.com" or of "baz.foo.example.com".
E oltre a compromettere il server, ci sono due possibili vettori di attacco per manipolare il valore del cookie: l'hacker riesce a iniettare l'exploit nel valore che viene impostato come valore del cookie dallo script dell'autore del sito, ad esempio, un utente fornito i valori sono usati per il valore del cookie. Oppure l'attaccante ha accesso a un sottodominio ed è in grado di impostare un cookie per il super-dominio in cui risiede lo script vulnerabile che stampa il valore del cookie. Entrambi i vettori possono essere eseguiti utilizzando Forgery di richiesta tra siti .
Non è sfruttabile di per sé, ma è un potenziale percorso di escalation per un utente malintenzionato che passa dalla fissazione dei cookie a XSS completo.
In particolare:
Se il sito è in esecuzione su un nome host con domini vicini, qualsiasi attacco XSS su quei vicini significa che un cookie può essere scritto nel dominio padre condiviso, trasformandosi in un attacco XSS sul sito. per esempio. da untrusted-uploads.example.com possono scrivere un cookie con dominio example.com , che verrà letto da trusted-www.example.com .
Se il sito è in esecuzione su https://www.example.com/ , un utente malintenzionato può ancora spoofare un sito a http://www.example.com/ . Qualsiasi set di cookie da lì sarà leggibile da https - lo script in https non rileva che il cookie non è stato creato con secure . Quindi cookie-XSS rende inefficace l'HTTPS (eccetto dove è stato sventato da Strict Transport Security, ma non è una difesa completa).
Non è possibile (*) per uno script (lato server o client) per rilevare che i domain , path , secure o httponly flags sul cookie corrispondono ai valori attesi, il che significa non è possibile rilevare in modo affidabile l'iniezione di cookie al di fuori del proprio sito.
(*: ci sono potenziali hack in cui si tenta di sovrascrivere un cookie impostandone uno nuovo con i flag desiderati, ma in definitiva non è completamente affidabile poiché lo script dell'attaccante potrebbe essere eseguito contemporaneamente).
Flash una volta era vulnerabile all'iniezione di CRLF (IE era anche vulnerabile), e questo potrebbe essere stato utilizzato per impostare l'intestazione della richiesta HTTP Cookie: per sfruttare XSS basato su cookie. Ma questo non è più il caso. Non è possibile impostare un cookie su un altro dominio. Se potessi impostare cookie per altri domini, renderebbe molto difficile (se non impossibile)
È inutile. A causa della politica della stessa origine, il testo di una pagina non può essere letto da altri siti, proprio come i cookie.
È che è leggibile da un utente malintenzionato che esegue un attacco MITM, ma lo sono anche i cookie (a meno che la connessione non sia HTTPS).
L'unico vettore di attacco reale esisterebbe in una situazione in cui esiste un'altra vulnerabilità. Ad esempio, se si potesse caricare uno script eseguibile come ad esempio un codice PHP, è possibile manipolare il cookie utilizzando tale script per iniettare JavaScript nella sessione degli utenti. Dovresti anche eseguire il solito social engineering per convincere l'utente a visitare lo script caricato.
Dipende da quale cookie è stato pubblicato.
Alcuni siti scrivono dati di terze parti in valori di cookie (dai un'occhiata al cookie reg_ext_ref di Facebook per l'utente anonimo, è il referrer completo). Può credere che alcuni siti memorizzino l'ultima query di ricerca che l'utente ha digitato o qualcosa del genere (ea volte puoi falsificare l'ultima query con GET-params). Quindi, se viene emesso almeno uno dei cookie simili, dovresti provare a sfruttarlo.
Non sto dicendo che il tuo caso sia un buon vettore di attacco, merita solo qualche indagine.