it-swarm-eu.dev

Qualsiasi motivo per NON impostare tutti i cookie per l'uso httponly e sicuro

Supponendo che un sito utilizzi sempre tutti gli HTTPS (LB reindirizza le porte da 80 a 443), c'è qualche motivo per non forzare tutti i cookie impostati dall'applicazione a utilizzare ENTRAMBI secure AND httponly?

Attualmente, ad esempio, una scansione PCI indicherà solo jsessionid come non utilizzando l'attributo secure, ma domani potrebbe essere l'altro, quindi sto cercando di anticiparlo.

35
user2145893

Sì, ci sono casi in cui non desideri HTTP SOLO o SICURO.

Solo per HTTP, è possibile che javascript interagisca con il cookie. Forse tieni traccia dello stato della pagina in un cookie, scrivi sul cookie con JS e leggi da JS. Inoltre vedo spesso CSRF implementato con un cookie non solo http.

Per il cookie sicuro, non mi aspetto che i cookie non abbiano mai l'attributo sicuro, tranne per questi due casi:

  1. gli ambienti di sviluppo spesso non hanno o devono avere certificati TLS (anche se forse dovrebbero)
  2. per tenere traccia delle attività originate su http. È anche possibile utilizzare il bilanciamento del carico per impostare un cookie non sicuro prima che rispedisca il reindirizzamento. Quindi l'analisi delle applicazioni può tracciare quali URL sono entrati come HTTP.

In pratica, se stai gestendo un sito https, imposta sempre il cookie sicuro e se non conosci i requisiti JS, sempre errore sul lato con HTTPONLY impostato .

AGGIORNAMENTO AI COMMENTI DELL'INDIRIZZO

Si discute molto sull'opportunità o meno di utilizzare TLS in produzione. Ha pubblicato la domanda qui:

Devo sviluppare con TLS attivato o disattivato?

38
Jonathan

Per quanto riguarda httponly stai essenzialmente chiedendo se si tratta di 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, cosa che si interrompe se il cookie è solo http.

Per quanto riguarda secure: poiché secondo la tua descrizione il sito utilizza https tutto il tempo non è dannoso avere tutti i cookie secure.

20
Steffen Ullrich

Flag protetto

Considerando che l'applicazione è in esecuzione su HTTPS, ovvero LB reindirizza tutto il traffico della porta 80 su 443, è comunque necessario abilitare il flag sicuro alla luce del seguente scenario.

  1. Supponiamo che ci sia un errore di sviluppo a seguito del quale un collegamento ipertestuale contiene il collegamento HTTP (ad es. http://example.com/some_page.php ) invece dell'HTTPS (ad es. https://example.com/some_page.php ) link.
  2. Il browser richiede la risorsa Web su HTTP e invia il cookie insieme ad esso a causa dell'assenza del flag sicuro.
  3. La richiesta raggiunge l'LB che reindirizza il traffico alla porta 443, ovvero tramite HTTPS.
  4. Il browser riavvia la richiesta ma questa volta su HTTPS con il valore del cookie.

Pertanto, sebbene l'LB sia configurato per reindirizzare il traffico non sicuro della porta 80 verso il traffico sicuro della porta 443, un attacco MiTM riuscito potrebbe aver luogo a step 2 comportando la rappresentazione di un utente rubando i cookie sensibili. Inoltre, verificare che i collegamenti ipertestuali e i reindirizzamenti siano correttamente 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 esserci possibili scenari in cui un MiTM fruttuoso potrebbe essere eseguito a causa dell'assenza della bandiera sicura.

Flag httponly

Questa è una bandiera il cui significato rimane indipendente da 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 un attacco Cross-Site Scripting (XSS) riuscito. Quando il flag httponly non è impostato sul valore del cookie, il javascript dannoso iniettato 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 ad esempio a server remoti , impersonando con successo un utente legittimo. Quindi il flag httponly dovrebbe essere sempre impostato su tutti i cookie o almeno su quelli sensibili.

9
Tony Thomas

Ti darò un esempio pratico di un cookie non httponly.

Quando un visitatore arriva sul mio sito, ci sono due cookie spinti in gola.

phpsession -> secure httponly samesite:lax
cookie_law -> secure samesite:lax

Il cookie_law contiene un oggetto cookie con codifica JSON codificato base64 che memorizza le impostazioni dei cookie.

Il mio javascript legge quei cookie per determinare il caricamento di analisi, adwords dipendenti dall'autorizzazione o dallo stato.
Il mio javascript utilizza anche 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 caricamento durante il rendering degli script a causa di più livelli di cache. Ecco perché ho scelto di lasciare il httponly da quel cookie.

Il javascript necessita dell'accesso per poterlo leggere.

5
Tschallacka

solo http: Talvolta le preferenze dell'utente (dimensione del carattere, tema, lingua, ...) vengono impostate e applicate sul lato client. Questo è il caso più comune per cui non è necessario impostare solo http.

secure: Dato che il sito/l'app insiste su HTTPS non c'è motivo di non usare la bandiera sicura. Se il sito/l'app deve offrire l'accesso tramite HTTP e hai bisogno di dettagli per passare da un contesto crittografato a nessun contesto (forse di nuovo le preferenze di visualizzazione dell'utente), devi lasciarlo spento.

Anche se al momento imponi l'accesso HTTPS, potrebbe non sembrare importante, in questo caso dovresti consentire errori: la tua app potrebbe essere ridistribuita con impostazioni errate, oppure i tuoi utenti potrebbero trovarsi soggetti a un MItM (qualcosa di dannoso o un proxy mal configurato ) che ha un effetto simile e, con questo flag, le cose falliscono (dal punto di vista della sicurezza) smettendo di funzionare invece di lavorare in modo insicuro.

Generale: Poiché si tratta di misure di sicurezza, per quanto minori possano sembrare, impostare sempre entrambe, a meno che non si abbia un motivo specifico per non farlo, piuttosto che non restare mai inadempienti a meno che non si ritenga necessario.

3
David Spillett