Dispongo di un servizio di bilanciamento del carico che termina le richieste https a http e pertanto i miei server di backend le vedono come http. Di conseguenza, tutti i miei cookie sono impostati senza un contrassegno sicuro quando si visualizzano i cookie sulla versione https di questo sito. Questo importa comunque dal momento che mixiamo http e https? Amazon.com e molti altri siti di e-commerce di grandi dimensioni sembrano avere cookie non protetti anche su https.
Un cookie ha il flag "sicuro" se lo dice. In teoria, nulla impedisce che un cookie "sicuro" venga servito da un server HTTP (non HTTPS); ma il tuo software server potrebbe essere problematico, dal momento che, dal suo punto di vista, il protocollo è HTTP e un cookie sicuro ha poco senso se transita su HTTP. Il tuo server non sa che si trova dietro un gateway HTTPS-to-HTTP. D'altro canto, 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 lo invierà felicemente a qualsiasi server che assomigli al server di origine. In presenza di un aggressore attivo, è necessario presumere che qualsiasi cookie non sicuro possa essere dirottato dall'attaccante. A seconda della tua situazione esatta, questa potrebbe essere una minaccia maggiore, minore o inesistente.
Il flag di sicurezza dei cookie di sessione è importante, perché 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 link e le risorse a https.
Normalmente funziona per impostare il flag; secure sul server delle applicazioni. Il loadbalancer ha appena restituito la risposta all'interno della connessione https e tutto va bene per il client. Il problema principale è dire al bilanciamento del carico di includere il cookie nella sua connessione http al server delle applicazioni. Dipende dall'implementazione concreta del bilanciamento del carico, indipendentemente dal fatto che lo faccia automaticamente o che abbia bisogno di qualche configurazione.
Sì, conta. Se il flag di sicurezza non è impostato su tali cookie, sei vulnerabile agli attacchi di tipo 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 tali cookie.
From wikipedia
A secure cookie is only used when a browser is visiting a server via HTTPS, that will make sure that cookie is always encrypted when transmitting from client to server, and therefore less likely to be exposed to cookie theft via eavesdropping.
Quindi la risposta è che sei preoccupato del contenuto di quei cookie inviati su http o dei dati sensibili e dovresti sempre essere inviato su https.
Bene, se sto leggendo correttamente stai chiedendo se i cookie HTTP sono compatibili con le richieste HTTPS? È importante, ma i cookie HTTP e i cookie HTTPS puntano alla stessa directory o host. Quindi quando guardi il codice del cookie impostato
GET /index.html HTTP/1.1
Host: www.example.org
Vorrei provare a specificare una versione http: // e https: // versione