Sicurezza dei cookie HTML

TL; DR: utilizza le sessioni su SSL

Hai ragione, questa è una brutta cosa. La regola generale di sicurezza in un'applicazione, mai fidarsi dell'utente , si applica qui. Il problema, è uno sviluppatore web pigro, crederà che un cookie non contenga come input dell'utente.

Questo non potrebbe essere più lontano dal caso. È eccezionalmente facile apportare modifiche a qualsiasi dato inviato al server dal client, sia che si tratti di un input diretto dell'utente o di un cookie.

Ci sono molti casi d'uso per i cookie, e svolgono un ruolo chiave nella sicurezza web, ma in questo caso, sembra che siano sicuri quanto un elemento di forma nascosta.

Quindi come risolvi questo? Sessions. Una sessione memorizza anche i dati come cookie, ma a differenza dei cookie, è solo una lunga stringa. Questo serve come metodo sicuro (con un avvertimento) per consentire al server di identificare un utente. Con ogni richiesta HTTP, l'ID di sessione è incluso. Una volta che il server ha associato una sessione con un client, i dati relativi alla sessione vengono memorizzati sul server. Il server sa quale sessione accedere in base all'ID inviato dal client.

Un id di sessione è migliore per alcuni motivi, il server controlla i dati associati alla sessione, non al client. Ad esempio, è possibile memorizzare il totale del carrello come variabile di sessione. Se il cliente ha avuto accesso diretto a questo, potrebbe modificare l'importo che paga dopo aver inviato l'ordine di acquisto, ma prima che la sua carta venga addebitata.

È possibile memorizzare in modo sicuro il livello di privilegio di un utente come variabile di sessione, in cui sarebbe pericoloso farlo anche come cookie normale.

Ora alle avvertenze. Un ID di sessione non è ancora sicuro al 100%. Se dovessi accedere al tuo sito su una rete pubblica, la mia autenticazione sarebbe andata a buon fine e tu mi forniresti un ID di sessione. Ora, chiunque conosca questo id può usarlo per inviare richieste HTTP come me. Questo è il dirottamento di sessione. Esistono anche alcuni attacchi temporali e tali che tentano di ridurre l'entropia che esiste nell'id della sessione.

Devi consentire a un utente di accedere o comunicare in modo sicuro con il tuo server tramite una connessione SSL / TLS. Ciò ridurrà notevolmente le possibilità di un attacco MITM o di un dirottamento di sessione. Se è anche possibile reimpostare l'id di sessione e richiedere all'utente di aver inserito le proprie credenziali entro un determinato periodo di tempo. Ad esempio, si spera che la tua banca ti costringa a effettuare il login dopo un certo periodo di tempo.

Ecco alcuni esempi di codice in php per l'utilizzo delle sessioni

session_start() // You must include this at the top of every page basically
                // I know, its odd, just go with it

$_SESSION['username'] = $user // How you could save the username to a session

session_unset() // Clear out the session (logout the user). If you really care
                // about security you will overwrite each session var first 

Quello che ho capito dalla tua domanda è che ottieni un cookie come user_id=123 e se lo cambi in user_id=456 ti viene immediatamente registrato come un altro utente.

Un modo possibile per impedire ai client di alterare i cookie è firmarli crittograficamente. Nel valore del cookie si includono sia il valore effettivo sia un hash del valore e una chiave segreta. Solo le persone che hanno la chiave segreta possono quindi modificare i cookie.

È difficile da implementare in modo sicuro da solo, quindi sarebbe meglio se questa funzionalità fosse supportata dal framework che stai utilizzando.