Con riferimento ad alcuni documenti di sicurezza che ho letto, ho scoperto che un cookie con il set di flag sicuro può essere inviato dal client solo tramite connessioni che utilizzano HTTPS, non HTTP, ma il cookie stesso può essere impostato dal server con un flag sicuro da una connessione HTTP non sicura. Perché è consentito?
I cookie sicuri possono essere impostati su canali non sicuri (ad es. HTTP) come da sezione 4.1.2.5 di RFC 6265 . Indica esplicitamente che il flag di sicurezza fornisce solo riservatezza e non integrità, poiché un cookie con segnalazioni di sicurezza può ancora essere impostato da un canale non sicuro, sovrascrivendo qualsiasi valore precedentemente impostato (tramite un canale sicuro o altro):
The Secure attribute limits the scope of the cookie to "secure" channels (where "secure" is defined by the user agent). When a cookie has the Secure attribute, the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTP over Transport Layer Security (TLS) [RFC2818]).
Although seemingly useful for protecting cookies from active network attackers, the Secure attribute protects only the cookie's confidentiality. An active network attacker can overwrite Secure cookies from an insecure channel, disrupting their integrity (see Section 8.6 for more details).
Sezione 8.6 fornisce diversi esempi, ma non li copio-incollare qui a causa di come lunga la sezione è.
Per quanto riguarda il motivo, non c'è un caso d'uso chiaro di cui io sia a conoscenza. Sospetto che l'RFC sia stato scritto dal punto di vista di avere solo l'obiettivo di proteggere la riservatezza, e quindi impedire l'accettazione dei cookie protetti da Secure quando impostati su HTTP era una restrizione non necessaria per quell'obiettivo. La mia ipotesi sarebbe che la motivazione fosse "se forniamo questa funzionalità, la gente può presumere che l'integrità dei cookie sia protetta dal flag Secure, e non vogliamo che le persone facciano quell'assunzione".
Detto questo, il fatto che i dati possano essere impostati su un canale non sicuro in qualche modo nega il concetto di inviare solo il valore del cookie su un canale sicuro, quindi la sensibilità della decisione è discutibile. La RFC menziona almeno che perdi la riservatezza se lo fai.
Citando rfc2965 che era stato reso obsoleto da rfc6265 che il polinomio ha menzionato:
Secure
OPTIONAL. The Secure attribute (with no value) directs the user agent to use only (unspecified) secure means to contact the origin server whenever it sends back this cookie, to protect the confidentially and authenticity of the information in the cookie.
The user agent (possibly with user interaction) MAY determine what level of security it considers appropriate for "secure" cookies. The Secure attribute should be considered security advice from the server to the user agent, indicating that it is in the session's interest to protect the cookie contents. When it sends a "secure" cookie back to a server, the user agent SHOULD use no less than the same level of security as was used when it received the cookie from the server.
(sottolineatura mia)
La mia interpretazione è che volevano che il server si occupasse della sicurezza sulla strada verso il cliente e che avesse modo di dire al cliente che avrebbe dovuto fare lo stesso.
In effetti il risultato è dubbio come accennato nella risposta di Polynomial.
Attualmente sul Web dobbiamo accettare che molti browser e i loro utenti tenteranno di solito di accedere alle risorse Web tramite connessioni non protette (HTTP).
Come tale c'è un po 'di spazio in RFC per quanto riguarda i cookie con Secure la bandiera del cookie può essere impostata. In particolare, sì, è consentito impostare i cookie con il flag di sicurezza anche se lo si fa tramite una connessione HTTP.
Il flag di sicurezza può servire solo al server per aumentare la sicurezza, quindi non c'è motivo di impedire che funzioni da un punto di vista tecnico o di sicurezza, anche se questo non vuol dire che sia una buona idea farlo. Dal punto di vista dell'efficienza, potrebbe essere ragionevole rispondere alle richieste di accesso con le necessarie informazioni di autenticazione (in un cookie con il flag di sicurezza) e quindi reindirizzare l'utente su HTTPS in cui verrà effettivamente inviato il nuovo cookie di autenticazione.
A questo punto è possibile che anche le intestazioni HSTS siano state inviate, quindi il browser non tenterà di utilizzare nuovamente HTTP in futuro, attenuando così i futuri attacchi di sovrascrittura dei cookie.
Ora avresti ragione nel pensare che a questo punto un utente malintenzionato avrebbe potuto intercettare i dati del cookie iniziale e quindi usarlo per impersonare l'utente. Questo è meno che ideale. Ma lo è anche in base all'utente che si connette al sito tramite HTTP e riceve un'intestazione HSTS senza che un utente malintenzionato manchi o estrae questa intestazione. Ecco perché abbiamo pre-caricamento HSTS. A tal fine, il precaricamento del flag di sicurezza dei cookie potrebbe essere un concetto interessante!
Si può presumere che dopo aver impostato il cookie, l'unico rischio per l'utente in termini di attacchi di rete è che il browser non ha istruzioni HSTS per il dominio in questione. Quindi un utente malintenzionato costringe l'utente a rimuovere l'autenticazione (magari bloccando il traffico SSL e aspettando che l'utente tenti di digitare nuovamente l'indirizzo dove probabilmente avvierà una connessione HTTP), intercetta le credenziali di autenticazione e / o il token, rimuove la sicurezza segnala e garantisce che il reindirizzamento HTTPS non si verifica per il client (mentre potenzialmente lo negozia al server se necessario).
Ciò potrebbe essere utile per la sicurezza in determinate situazioni, in pratica se la tua connessione Internet è stata manomessa a causa della mancanza della crittografia HTTPS. Tuttavia, nella maggior parte dei casi rilevanti l'iniezione di cookie è in basso nell'elenco di problemi rispetto alle altre funzionalità compromesse.
Il protocollo HTTP non offre al momento un modo per il client di fornire metadati relativi al cookie.
Ad esempio, se un cookie è impostato con path=/ , e successivamente un cookie viene impostato con path=/narrow-scope Quindi se visiti il sito, visitando un /narrow-scope URL, vengono inviati entrambi i cookie: Cookie: name=valueA, name=valueB .
Il server non può sapere quale percorso specifico è stato utilizzato per ogni cookie. Solo che i metadati tra loro sono diversi altrimenti sarebbero considerati lo stesso cookie (con lo stesso name )
Allo stesso modo, non è possibile contrassegnare i cookie come se il flag Secure sia impostato o HttpOnly . Nessun metadata è passato dal client al server.
Per impedire a una pagina HTTP di impostare un cookie sicuro, si otterrebbero due possibilità:
Tutti i cookie forniti da HTTP non sono accessibili quando si visita la pagina HTTPS. Questa sarebbe un'interruzione significativa della compatibilità.
O I metadati vengono aggiunti al valore di Cookie fornito dal client in modo che il server possa sapere alcune cose a riguardo. Ad esempio, il server potrebbe voler distinguere i cookie impostati tramite JavaScript. O come dici tu, se è stato impostato su HTTPS o HTTP.
Questo sarebbe un grande cambiamento, e non c'è molta richiesta per questo. Inoltre nella maggior parte dei casi non corrisponde a una funzione di sicurezza.
In definitiva, la soluzione corretta è obbligare gli utenti a utilizzare le connessioni HTTPS .
La domanda su dove è documentato questo RFC è stata sufficientemente risposta.
Come per altre funzionalità di sicurezza, questa particolare caratteristica ("cookie sicuro") ha un solo scopo: evitare che uno spettatore / uno sniffer ottenga il tuo cookie.
Non intende essere una panacea contro tutti i possibili tipi di attacchi ai cookie, ma solo questo attacco molto specifico:
Possiamo supporre che 1., 2. e 3. siano più difficili da attaccare, quindi 4./5.
L'utente può essere addestrato a verificare che un modulo di accesso visualizzi un URL HTTPS e una "bandiera verde" accanto all'URL, a seconda del browser. Nel momento in cui inserisci le tue credenziali, un utente saggio può ragionevolmente aspettarsi di prestare attenzione all'URL, in questi giorni. (Questo è il modo in cui funziona il solito attacco di posta spam, ingannandoli per inserire il loro nome utente / pw su un URL arbitrario - un argomento per un altro giorno.)
È molto difficile attaccare a meno che il server non sia bacato: il server sa perfettamente se la connessione è HTTP o HTTPS, quindi creerà una sessione solo se arriva su HTTPS. Un sistema molto importante non sarà comunque in grado di ascoltarlo su HTTP.
Le richieste regolari non devono essere attaccate. Andranno su una connessione HTTPS sicura e andrà tutto bene.
Fare in modo che un browser si connetta a URL arbitrari è piuttosto facile: basta posizionare un tag da qualche parte o sparare ad alcuni AJAX se è possibile. E alcuni server possono scaricare le immagini statiche e tali comunque da una connessione non sicura per salvare la CPU, quindi un utente malintenzionato non dovrà assolutamente eseguire alcuna operazione.
Quindi, questo scenario è evitato dal cookie sicuro. Il cookie passerà solo su HTTPS, quindi l'utente malintenzionato non può annusare il cookie.
Certo, ci sono un sacco di altri vettori di attacco per ottenere ancora il cookie (man-in-the-middle contro HTTPS, leggendolo invece da Javascript (impedito dal flag "httponly"), facendo una richiesta HTTPS ad un sito web dell'attaccante con un cookie troppo lassista (prevenuto da politiche di origine originale o impostando correttamente il dominio dei cookie sul lato server) e così via).
Si noti che è difficile da proteggere contro 4. È abbastanza facile fare una richiesta del browser qualsiasi URL arbitrario. Si noti che non è necessario richiedere effettivamente un valido URL, è sufficiente che il browser invii la richiesta HTTP (incluso il cookie); non ti interessa il risultato, ed è impossibile per il server impedire al browser di inviare la richiesta non sicura in primo luogo, tranne che non ascoltando affatto su HTTP, cioè non avendo la porta TCP / IP aperta. Ma anche questo non è abbastanza; se l'utente passa attraverso un proxy (comune nelle intranet aziendali), il browser invierà comunque la richiesta HTTP al proxy (su HTTP) e un utente malintenzionato che annusa tra il browser e il proxy ha ancora il cookie, anche se il il server attuale non ha mai accettato la connessione TCP / IP.
Il cookie "sicuro" è pensato per proteggere da un problema molto specifico che altrimenti sarebbe impossibile da proteggere.
Non è pensato per essere protetto da un server bacato, pigro o mal configurato che invia il cookie su un canale non protetto in primo luogo.
Farlo in questo modo (vale a dire, una funzione contro un attacco specifico) è una buona cosa, ed è ciò che fa la maggior parte delle funzionalità di sicurezza. Ci si aspetta che ragionino su quali tipi di attacchi una funzione come questa protegge non ; e questo ragionamento è piuttosto semplice perché l'ambito della funzionalità è limitato.