Supponendo che un sito stia utilizzando tutto il HTTPS tutto il tempo (LB reindirizza la porta da 80 a 443), c'è qualche ragione per non forzare tutti i cookie impostati dall'applicazione ad utilizzare ENTRAMBI secure AND httponly ?
Attualmente, ad esempio, una scansione PCI contrassegna solo jsessionid come non utilizzando l'attributo secure , ma domani potrebbe essere l'altro, quindi sto cercando di anticiparlo.
Sì, ci sono casi in cui non vuoi HTTP SOLO o SICURO.
Solo per HTTP, potresti voler che javascript interagisca con il cookie. Forse si tiene traccia dello stato della pagina in un cookie, si scrive nel cookie con JS e si legge da JS. Inoltre vedo spesso CSRF implementato con un cookie non http-only.
Per il cookie sicuro, non mi aspetto che nessun cookie abbia mai l'attributo sicuro tranne per questi due casi:
In pratica, se stai utilizzando un sito https, imposta sempre il cookie sicuro , e se non conosci i requisiti JS, sempre errore sul lato con HTTPONLY impostato .
UPDATE TO ADDRESS COMMENTS
Molti discorsi sull'opportunità o meno di utilizzare TLS in produzione. Ha postato la domanda qui:
Per quanto riguarda httponly , stai essenzialmente chiedendo se sono casi d'uso in cui un cookie deve essere letto o impostato da Javascript. In genere, alcune impostazioni dell'interfaccia utente (scelta della lingua ...) vengono conservate in questo modo che si interromperà se il cookie è httponly.
Come per secure : poiché secondo la tua descrizione il sito utilizza https tutto il tempo non danneggia per avere tutti i cookie secure .
Flag sicuro
Considerando che l'applicazione è in esecuzione su HTTPS, cioè LB reindirizza tutto il traffico sulla porta 80 su 443, è comunque necessario abilitare il flag di sicurezza alla luce del seguente scenario.
Quindi, sebbene il LB sia configurato per reindirizzare il traffico non sicuro della porta 80 sul traffico sicuro della porta 443, un attacco MiTM riuscito potrebbe aver luogo a step 2 risultante nella rappresentazione di un utente rubando i cookie sensibili. Inoltre, verificare che i collegamenti ipertestuali e i reindirizzamenti siano opportunamente codificati è un'attività relativamente più faticosa rispetto all'abilitazione del flag sicuro sui cookie sensibili. Per concludere, sebbene sia impostato un reindirizzamento a livello di LB, potrebbero verificarsi scenari in cui un MiTM fruttuoso potrebbe essere eseguito a causa dell'assenza del flag di sicurezza.
link
Questa è una bandiera il cui significato rimane indipendente dalla Transport Layer Security (SSL / TLS). Il flag httponly viene utilizzato per impedire a javascript di accedere a cookie sensibili come i cookie di sessione in caso di successo dell'attacco XSS (Cross-Site Scripting). Quando il flag http non è impostato sul valore del cookie, il javascript dannoso inserito nell'applicazione a causa di un difetto a livello di applicazione potrebbe finire per sabotare la riservatezza, l'integrità e la disponibilità degli account utente leggendo i cookie di sessione e inviandoli a server remoti per esempio , in tal modo impersonando con successo un utente legittimo. Quindi il flag httponly dovrebbe sempre essere impostato su tutti i cookie o almeno su quelli sensibili.
Ti darò un esempio pratico di un cookie non httponly.
Quando un visitatore viene sul mio sito ci sono due biscotti spinti giù nella sua gola.
phpsession -> secure httponly samesite:lax
cookie_law -> secure samesite:lax
Il cookie_law contiene un oggetto cookie codificato json con codifica base64 che memorizza le impostazioni dei cookie.
Il mio javascript legge quei cookie per determinare il caricamento di analisi, adwords dipendenti dal permesso o dallo stato.
Anche il mio javascript usa quel cookie per far funzionare l'editor delle impostazioni dei cookie.
Se imposto il flag httponly sui cookie, javascript non può leggerlo. E non posso usare php per determinare lo stato del carico durante il rendering degli script a causa di più livelli di memorizzazione nella cache. Ecco perché ho scelto di lasciare httponly da quel cookie.
Il javascript richiede l'accesso per poterlo leggere.
link A volte le preferenze dell'utente (dimensione carattere, tema, lingua, ...) sono impostate e applicate sul lato client. Questo è il caso più comune per aver bisogno di loro non impostare solo http.
secure: poiché il sito / l'applicazione insiste su HTTPS, non c'è alcun motivo non per utilizzare il flag di sicurezza. Se il sito / l'app deve offrire l'accesso tramite HTTP e hai bisogno di dettagli per passare tra contesti crittografati / non (forse le preferenze di visualizzazione dell'utente di nuovo), allora devi lasciarlo spento.
Anche se sembra non avere importanza poiché attualmente imponi l'accesso HTTPS, dovresti consentire errori in quanto: la tua app potrebbe essere ridistribuita con impostazioni errate, oppure i tuoi utenti potrebbero trovarsi soggetti a un MItM (qualcosa di malevolo o un proxy mal configurato) che ha un effetto simile e con questo flag le cose non sono sicure (da un punto di vista della sicurezza) interrompendo il lavoro piuttosto che lavorando in modo non sicuro.
Generale: Poiché sono misure di sicurezza, per quanto minori possano sembrare, impostale sempre entrambi, a meno che tu non abbia una ragione specifica per non farlo, piuttosto che lasciare che vengano disattivate a meno che tu non sia necessario.