Ci sono 2 modi per impostare il flag 'sicuro' su un cookie di sessione:
Nell'applicazione stessa, ad esempio:
<session-config>
<cookie-config>
<http-only>true</http-only>
<secure>true</secure>
</cookie-config>
</session-config>
Nella configurazione del proxy TLS come httpd.
Non riesco a trovare nessun articolo che indichi quale sia la migliore pratica.
Il più sicuro è probabile che sia 2, mentre il più logico è l'1, poiché funziona solo con HTTPS.
Nell'applicazione.
I cookie stessi sono impostati dall'applicazione e le bandiere dei cookie sono parte di ciò. I cookie possono avere diversi flag: "secure", "httponly", "samesite". Solo l'applicazione sa quali cookie devono avere quali flag. Se il tuo proxy inserisce il flag httponly e l'applicazione vuole accedere al cookie con Javascript, questo non funzionerà più. I cookie sono responsabilità dell'applicazione.
Inoltre, si desidera che l'applicazione si comporti in modo coerente, indipendentemente dal proxy utilizzato. Gli sviluppatori probabilmente non utilizzano alcun proxy durante il test dell'applicazione, ma dovrebbero comunque usare i cookie sicuri in modo che l'ambiente corrisponda strettamente alla produzione.
Raccomando che sia meglio usarli entrambi perché non causa alcun danno. Inoltre, garantisce la filosofia di Defence in Depth .
Al giorno d'oggi le persone si stanno implementando su cloud e le migrazioni vengono eseguite più spesso. Quindi, penso che non possiamo essere sicuri che la configurazione 2 che hai citato per httpd sia a posto per tutto il tempo.
Dovresti considerare che abilitare <secure>true</secure> nell'applicazione è obbligatorio. Spiegazione sotto riportata.
Spiegazione:
Scenario 1 (Assumendo l'impostazione di flag sicuri perse dal proxy TLS / httpd)
Ho testato uno scenario in cui ho attivato solo <secure>true</secure> nell'applicazione stessa e non ho configurato il flag sicuro tramite il proxy TLS (httpd).
Ora l'intestazione di risposta ha un cookie con flag di sicurezza, ho osservato che Firefox e Chrome elaborano e salvano il cookie con flag di sicurezza.
Set-Cookie: acct=tafats; domain=localhost; Secure;expires=Thu, 16-Mar-2017 15:19:48 GMT; path=/; HttpOnly
Da un punto di vista della sicurezza questo è ciò che ci si aspetta dai browser.
Questo ti protegge dai session-hijacking tentativi tramite lo sniffing dei pacchetti.
In questo caso, se l'utente malintenzionato fa clic su http://example.com , il cookie non viene inviato perché ha un flag sicuro.
Qui, <secure>true</secure> è venuto in soccorso.
Scenario 2 (Assumendo l'impostazione di flag sicuro mancata nell'applicazione ma configurata in TLS proxy / httpd)
È abbastanza buono, purché questo flag di sicurezza sia impostato tramite il proxy TLS. Ma il problema è che devi assicurarti che questa impostazione proxy TLS sia configurata per tutte le distribuzioni eseguite in qualsiasi momento.
To conclude, I recommend its better to use both of them together and ensure the philosophy of Defense in Depth.
Leggi altre domande sui tag cookies session-management