document.cookie e il suo ambito

Naviga le tue risposte
3

C'è una certa confusione di base che ho.

Una vittima non sospetta visita un sito Web vulnerabile, vulnerable.com e accede lì. vulnerable.com , post login, invia una risposta che ha il seguente set di header HTTP,

Access-Control-Allow-Credentials: True
Access-Control-Allow-Origin: vulnerablesite.com

Diciamo che il cookie di sessione è limitato al solo percorso /home.html (che potrebbe non avere molto senso, ma assumiamo solo questo per il gusto di questa discussione) e non ha il flag HTTPOnly impostato.

Ora nello stesso browser apre una nuova scheda e visita vulnerablesite.com/some_page.html Un utente malintenzionato identifica un XSS memorizzato in vulnerablesite.com/some_page.html e decide di sfruttarlo per ottenere l'accesso al cookie di sessione dell'utente su vulnerable.com .

Per fare ciò, l'utente malintenzionato inietta uno script AJAX in vulnerablesite.com/some_page.html , quindi quando la vittima visita la pagina, farà una richiesta AJAX a vulnerable.com/home.html . Ora questa richiesta avrà sicuramente esito positivo (nessun motivo per non farlo e anche perché Access-Control-Allow-Credentials era true) e la risposta ricevuta sarà anche leggibile dallo script AJAX dell'attaccante (poiché Access-Control-Allow-Origin è stato impostato su vulnerablesite.com , quindi nessuna violazione della stessa politica di origine)

Quando lo script AJAX dell'attaccante dice xhr.response, questo oggetto risposta conserverà sicuramente la pagina /home.html .

La confusione principale riguarda il percorso e gli attributi del dominio del cookie. Domande

  1. Quindi, in questo caso, quando lo script dell'attaccante dice document.cookie ora, l'attaccante sarà in grado di leggere il cookie di sessione della vittima?
  2. perché il cookie ha come ambito /home.html , qualsiasi richiesta fatta a /home.html trasporterà questo cookie. Ma perché la risposta a /home.html non sta facendo assolutamente un set-cookie, quando è ajax dell'attaccante dire document.cookie cosa verrà letto esattamente?
  3. non hanno idea di quale sarebbe l'attributo di dominio del cookie in questo caso e in che modo inciderà sulla lettura del cookie in comunque se lo farà lo stesso.
posta qre0ct 09.09.2016 - 12:09
fonte

2 risposte

4

So in this case when the attacker's script says document.cookie now, will the attacker be able to read the session cookie of the victim?

No, la richiesta AJAX può essere inviata e letta a causa del difetto XSS, tuttavia i cookie dalla richiesta AJAX non possono. document.cookie mostrerà solo i cookie disponibili per la pagina iniziale sfruttata ( some_page.html ).

because the cookie is scoped to /home.html, any request made to /home.html will carry this cookie along. But because the response to /home.html is not doing a set-cookie at all, when attacker's ajax say document.cookie what will exactly be read?

Anche in questo caso, document.cookie sarà nel contesto di some_page.html su vulnerablesite.com , quindi non sarà in grado di leggere l'ambito del cookie per /home.html su vulnerable.com .

Anche se home.html stava impostando i cookie, il recupero dell'intestazione set-cookie sarebbe vietato dalla maggior parte dei browser .

have no idea about what the domain attribute would be of the cookie in this case and how will it impact the reading of the cookie in anyway if at all it will.

Il dominio sarà impostato su vulnerable.com come cookie solo host . Pertanto non può essere letto ad es. foo.vulnerable.com .

Nota su CORS

Non dimenticare che un'origine deve avere un protocollo . Pertanto 

Access-Control-Allow-Origin: vulnerablesite.com

Dovrebbe essere ad es. 

Access-Control-Allow-Origin: https://vulnerablesite.com
    
risposta data 09.09.2016 - 12:42
fonte
5

Se i domini erano uguali, quindi i cookie erano impostati su http://example.com/home/ , e non avevano impostato solo HTTP, ma c'era una vulnerabilità XSS in http://example.com/vulnerable/ , quindi i cookie sono accessibili all'utente malintenzionato - possono iniettare un iframe nella pagina e utilizzare uno script simile a document.getElementsByTagName("iframe")[0].contentDocument.cookie per accedere ai cookie.

Se i domini sono diversi, come sembrano essere nella tua domanda, allora no, l'accesso ai cookie non è possibile. Tutto il Access-Control-Allow-Credentials: true fa è dire al browser che è corretto includere le credenziali (cookie e autenticazione di base HTTP) nella richiesta - non espone tali credenziali al richiedente (a meno che il sito Web non sia per qualche motivo includendo i dettagli del cookie nella risposta, che ci sono pochissime buone ragioni per fare).

Tuttavia, essere in grado di accedere al valore reale del cookie non è necessario per poterlo sfruttare. L'utente malintenzionato effettua richieste autenticate come utente e è in grado di ignorare qualsiasi protezione CSRF (Cross Site Request Forgery) leggendo il token CSRF dal documento HTML restituito dalla prima richiesta. Ciò significa che, a condizione che tutti gli endpoint restituiscano le intestazioni CORS pertinenti (incluso Access-Control-Allow-Methods se alcuni endpoint richiedono POST piuttosto che GET), l'utente malintenzionato può effettuare le stesse richieste tramite AJAX come sarebbe stato possibile sul proprio computer con accesso al cookie di sessione.

    
risposta data 09.09.2016 - 13:59
fonte

Leggi altre domande sui tag

È sicuro usare una parte della chiave come IV in AES? È meglio scegliere una password casuale meno vulnerabile?