Un cookie ha il flag "sicuro" se lo dice. Teoricamente, nulla impedisce che un cookie "sicuro" venga servito da un server HTTP (non HTTPS); ma il software del tuo server potrebbe avere problemi, poiché, dal suo punto di vista, il protocollo è HTTP e un cookie sicuro ha poco senso se transita su HTTP. Il tuo server non sa di trovarsi dietro un gateway da HTTPS a HTTP. D'altra parte, il client vede una connessione HTTPS e ottenere un cookie sicuro tramite tale connessione non lo sorprenderà affatto.

Il problema con un cookie non sicuro è che il client invierà felicemente a qualsiasi server che assomiglia al server di origine. In presenza di un utente malintenzionato attivo, è necessario presumere che qualsiasi cookie non protetto possa essere dirottato dall'aggressore. A seconda della situazione esatta, questa potrebbe essere una minaccia grave, minore o inesistente.

Il flag; secure dei cookie di sessione è importante, altrimenti il ​​cookie viene inviato su http. Un utente malintenzionato potrebbe essere in grado di indurre la vittima ad aprire una connessione http anche se punti tutti i collegamenti e le risorse a https.

Normalmente funziona per impostare il flag; secure sul server delle applicazioni. Il loadbalancer invierà semplicemente la risposta all'interno della connessione https e tutto va bene per il client. Il problema principale è indicare al bilanciatore del carico di includere il cookie nella sua connessione http al server delle applicazioni. Dipende dall'implementazione concreta del load balancer se lo fa automaticamente o necessita di una configurazione.

Sì, è importante. Se il flag di sicurezza non è impostato su questi cookie, sei vulnerabile agli attacchi simili a Firesheep, il che è negativo e potrebbe avere un impatto negativo sugli utenti (ad esempio, in particolare gli utenti che si connettono tramite una connessione wireless aperta). Pertanto, ti consiglio di assicurarti che il flag di sicurezza sia impostato su quei cookie.

Da wikipedia

Un cookie protetto viene utilizzato solo quando un browser sta visitando un server tramite HTTPS, che assicurerà che il cookie sia sempre crittografato durante la trasmissione da client a server, e quindi è meno probabile che sia esposto al furto di cookie tramite intercettazioni.

Quindi la risposta è davvero: sei preoccupato per il contenuto di quei cookie inviati tramite http o sono i dati sensibile e deve essere sempre inviato tramite https.

Ebbene, se sto leggendo correttamente mi stai chiedendo se i cookie HTTP sono compatibili con le richieste HTTPS? È importante, ma i cookie HTTP e HTTPS puntano alla stessa directory o host. Quindi, quando guardi il codice del cookie impostato

  GET /index.html HTTP / 1.1Host: www.example.org  

proverei a specificare una versione http: // e una versione https: //