C'è un modo per sapere che un cookie è "Solo HTTP" sulla prima richiesta utente?

0

Mentre stavo leggendo la sessione articolo di riparazione su OWASP , stavo pensando che l'unico modo per il mio server rifiutare un cookie impostato da uno script canaglia sarebbe per il mio server sapere che il browser ha inviato una richiesta senza il flag Solo HTTP. Solo i cookie inviati al server non includono nulla più del nome del cookie e il suo valore ... Tutti i metadati sono persi.

Ciò che ha spinto questa domanda sono i loro esempi # 2 e # 3 in cui mostrano URL che assomigliano a questo:

http://website.kom/<script>document.cookie=”sessionid=abcd”;</script>
http://website.kon/<meta http-equiv=Set-Cookie content=”sessionid=abcd”>

Personalmente, non capisco come possa funzionare anche lontanamente. Ci sono browser o server che sono guasti? Perché un tag nell'URL dovrebbe essere accettato dal browser o dal server?!

Quindi penso che sapere che il browser avesse il cookie come HTTP-Only sarebbe utile, ma al momento non riesco a capire come un hacker possa impostare un cookie (che non sarebbe HTTP-Only) assumendo che non sia possibile violazione del mio codice server.

Immagino che l'unico modo in cui possa funzionare è se l'hacker dovesse trovare un XSS nel mio codice client o server. Sarebbe corretto?

    
posta Alexis Wilke 05.08.2018 - 02:40
fonte

1 risposta

1

Dato il tipo di attacco a cui ti riferisci, ... XSS sarebbe il vettore più probabile per lo sfruttamento.

Come ho accennato nel mio commento, l'esempio specifico che viene mostrato viene spesso utilizzato come attacco contro 404 pagine che mostrano un frammento dell'URL nel corpo della pagina senza disinfettare il contenuto HTML. Quindi sì ... questo è un tipo di attacco XSS perfettamente normale, ma non è il browser che è rotto.

L'XSS sarebbe l'unico modo per un attacco di fissazione della sessione? Probabilmente no. Se un utente malintenzionato è riuscito a eseguire prima un attacco Man-in-the-Middle (MITM) e inietta il proprio ID sessione prima di accedere, consentirebbe loro di continuare a utilizzare quella sessione dal proprio computer remoto dopo l'attacco.

MITM è più difficile da eseguire rispetto all'XSS ... ma è ancora possibile. E se il vettore per stabilire la fissazione della sessione fosse MITM, controllare HTTP solo sul cookie sarebbe inefficace, poiché il cookie potrebbe essere stato modificato sul filo.

La migliore protezione contro questo vettore sarebbe TLS e l'educazione degli utenti per impedire loro di fare clic sugli errori dei certificati.

    
risposta data 05.08.2018 - 04:08
fonte

Leggi altre domande sui tag