Invio del cookie di sessione all'interno del corpo della risposta HTTP

Question

Invio del cookie di sessione all'interno del corpo della risposta HTTP

#1 da (3 voti)

5

È noto che la pratica sicura di impostare un cookie di sessione utilizza Set-Cookie header con Secure e HttpOnly flags. Ma ci sono problemi di sicurezza con l'invio di cookie all'interno del corpo di risposta HTTP (e richiesta)? Ad esempio, in questo modo:

HTTP/1.1 200 OK
Date: Wed, 07 Sep 2016 09:23:37 GMT
.........
.........
.........

sessioncookie=abcdefgh

E se impostassi un cookie usando Set-cookie AND inviassi anche il corpo della risposta HTTP nella stessa risposta HTTP, sarebbe in qualche modo inferiore la sicurezza?

cookies web-application session-management

posta ChildinTime 26.09.2016 - 16:04

fonte

1 risposta

Leggi altre domande sui tag cookies web-application session-management

è possibile estrarre un "hint hint" di qualche tipo da un altro hash? Importanza di Tool-Stealth per l'Internal Audit del team rosso

score 3 · Answer 1

Impostazione dei cookie nel corpo

Non puoi impostare cookie nel corpo della risposta (i browser non guardano lì per i cookie), né può il tuo browser presenti cookie nel corpo della richiesta (il server non guarderà lì). I cookie per definizione sono contenuti nell'intestazione HTTP (vedi RFC 6265 ).

Inserimento di dati protetti nel corpo

Puoi certamente inviare altri dati di sessione o token nella richiesta o nel corpo della risposta (ad esempio è comune passare un token CSRF nel corpo), ma se lo fai non sono cookie. Se questa è una buona idea è una domanda diversa.

La maggior parte dei dati è OK nel corpo, dopotutto è l'unica parte che l'utente può vedere ea volte l'utente deve visualizzare i dati sensibili.

Tuttavia, alcuni dati non sono OK nel corpo. Qualunque cosa tu voglia rendere non disponibile ad un attacco XSS, per esempio, non deve essere nel corpo, e dovrebbe essere contenuto in un Cookie Http-only in modo che non possa essere letto dal DOM .

Detto questo, alcuni dati sono meglio nel corpo! Ad esempio, tutto ciò che non si desidera visualizzare i registri IIS predefiniti deve essere inserito nel corpo. Tutto ciò che non vuoi includere in una sessione in corso di richiesta forgiata (a.k.a CSRF) dovrebbe essere incluso nel corpo e non come cookie.

Impostazione dei dati in entrambi

Non è necessariamente un problema di sicurezza impostare un token sia in un cookie che nel corpo. In effetti, questo è esattamente il modello richiesto dalla Riduzione del doppio di cookie CSRF .

D'altra parte, se stai solo passando l'ID di sessione nel corpo per il diavolo, ed è un duplicato di un HttpSolo cookie , quindi hai annullato tutti i vantaggi dell'utilizzo del flag HttpOnly, poiché lo stesso valore può essere letto dal DOM.

Inoltre, ecco qualcosa di veramente divertente: se il sito imposta un cookie HttpOnly dal lato server, e lo stesso valore del cookie viene passato tramite il corpo della pagina e impostato tramite script client, il browser finirà con due cookie con lo stesso nome! Questa condizione dovrebbe essere evitata perché non esiste alcuna specifica HTTP che indichi quale cookie debba essere presentato in questo caso e il comportamento del browser varierà.