Questo dipende interamente da ciò che stai facendo con il nome utente memorizzato nel cookie. Se ti fidi automaticamente che il nome utente fornito dal cookie è valido, allora stai invitando in modo efficace la rappresentazione degli utenti da parte di hacker.

Se, d'altro canto, stai semplicemente memorizzando il nome utente in modo che possano avere automaticamente il nome utente inserito la volta successiva che accedono al login, è perfettamente corretto dal momento che un nome utente non è informazione segreta.

Se, per qualche motivo, è necessario utilizzare un cookie per memorizzare l'autenticazione, l'approccio preferito è utilizzare un identificatore di sessione generato in modo casuale che viene tracciato sul server e può essere scaduto.

Se la memoria lato server non è disponibile, il server può crittografare il nome utente e una data di scadenza (e facoltativamente un IP dal quale sono connessi) con una chiave simmetrica (come AES) e quindi trasferire quel valore crittografato al cookie. Il server può quindi verificare il cookie in un secondo momento senza che un utente malintenzionato possa modificarlo. Lo svantaggio principale di questo approccio è che una volta emesso un cookie, non può essere invalidato se l'utente vuole disconnettere tutte le sessioni (perché, ad esempio, il loro computer è stato rubato.)

Credo che la domanda sia: perché dovresti farlo?

Se stai memorizzando il nome utente in un cookie per bypassare un passaggio in cui desideri estrarre tali informazioni dal database quindi ti stai lasciando aperto ai rischi se ti fidi ciecamente che l'utente sia se stesso.

Tutto ciò che si trova in un cookie è

1. leggibile dall'utente
2. può essere modificato dall'utente

Le variabili che l'utente ha la possibilità di modificare non dovrebbero essere attendibili EVER indipendentemente dal fatto che siano memorizzate nel browser (cookie), inviate dall'utente attraverso un modulo (variabile POST o GET) o se possono essere manipolate nella barra degli indirizzi (variabili GET).

Se stai memorizzando i cookie (come fanno alcuni siti) per ricordare un utente quando ritornano, allora hai bisogno di hash la variabile con un salt e passare quella variabile salata hash (con qualcosa come un timestamp e qualcosa che ti piace una chiave privata tutto hash insieme). Ciò rende molto più difficile per l'aggressore ottenere un falso positivo sulla manipolazione dei cookie, poiché è necessario avere accesso al codice e presentare il timestamp esatto per avere una corrispondenza nel database (vedi sotto).

Informazioni sulle SESSIONI

Alcune implementazioni di SESSIONS nei linguaggi di programmazione come PHP saranno predefinite memorizza le variabili SESSION nei cookie . Pertanto, qualsiasi informazione che non vorreste che l'utente vedesse non dovrebbe essere archiviata come variabile di sessione senza essere hash o codificata in qualche modo o modo perché, per impostazione predefinita, in alcune lingue viene trasmessa al browser e fornisce qualsiasi potenziale informazioni sugli attaccanti sulla modalità (convenzione di denominazione e struttura) memorizzate le vostre variabili.

A condizione che ti aspetti di accedere solo da una macchina, una buona pratica sarebbe:

1. Salva la variabile una tantum salata con hash in una tabella relazionale nel database insieme a una corrispondenza specifica dell'utente (come un ID) e una data / ora. Ci deve essere solo variabile in questa tabella memorizzata per utente. Questo fungerà da ultima visita al sito da questo browser. Le sessioni durano fino a quando i timeout della sessione lo consentono. Questo esiste solo per l'ultima pagina della loro ultima sessione e può esistere nella pagina in cui la loro sessione è stata terminata da loro (diciamo che si disconnettono). Se si sceglie di riattivare l'ultima sessione (a condizione che non si siano scollegati), archiviare il session_ID nella tabella relazionale insieme a questa variabile di una volta, poiché chiunque stia setacciando il proprio traffico probabilmente ha già il proprio session_id. Dovevano sapere che questa chiave una tantum per l'utente del sito era ciò che era necessario per renderlo leggermente più semplice al momento del reso.
2. Dopo aver recuperato il cookie memorizzato, pulirlo (tag strip, preventivi, qualsiasi cosa da utilizzare come attacco di iniezione), controllarlo per assicurarsi che sia conforme al formato previsto (se ti aspetti un hash MD5, non accettare un numero, non accettare SHA, ecc.)
3. Eseguire una query di verifica incrociata sul database che verifica il conteggio di 1 per la variabile ora pulita rispetto a un record esistente nella tabella relazionale.
4. Se hai ricevuto il conteggio di 1, THEN esegui una query pulita sul database per ottenere ulteriori informazioni sull'utente, perché ora l'utente sarebbe * attendibile * o per lo meno la variabile era in una sola volta in uso nel tuo sistema. Se ricevi un conteggio di 0 significa che è inesistente e non affidabile. Se ricevi un conteggio di più di uno, ciò significa che non stai memorizzando correttamente gli hash nel database poiché ogni nuova sessione dovrebbe avere il proprio hash speciale.

Se il tempo è maggiore di un periodo di tempo più lungo (ad esempio 1 mese), quindi fornire tutte le credenziali come non riconosciute. Questa è una decisione esecutiva in relazione a User Experience.

Se una sessione è scaduta, fai autenticare di nuovo l'utente. Se non è scaduto, l'utente dovrebbe comunque effettuare l'accesso a meno che non sia stato attivato un evento che uccide la sessione di un utente dopo un determinato importo di inattività (il che significa che la sessione * non deve essere ancora attiva).

Nel momento in cui l'utente non registrato viene riconosciuto, quindi presentarli con una sfida e una risposta a loro nota per verificare che non si tratti di qualcuno sul loro terminale. Non fornire loro alcuna informazione che possa essere utilizzata contro il loro account nel caso in cui la loro macchina sia stata compromessa.

NON stampare MAI nulla sullo schermo direttamente, scriverlo su un database o scriverlo su disco da un utente senza pulirlo. Perfino back-end sicuro I siti Web intranet solo per LAN hanno il potenziale per essere sfruttati.

Non memorizzare informazioni come questa in un cookie. Utilizzare la cache di sessione del server (cioè $ _SESSION) per informazioni come questa. I cookie possono essere facilmente falsificati e l'ultima cosa che vuoi è un utente che impersona qualcun altro semplicemente cambiando un cookie!

I want to store the username for a web site in the cookie, is it secure?

No. Se si memorizzano informazioni su un computer degli utenti, in cui non si ha il controllo su di esso, non è sicuro. Quell'utente o chiunque altro con accesso a quel computer può modificare il contenuto di quel cookie.

Si noti che è possibile crittografare le informazioni prima di memorizzarle in un cookie e che è sempre necessario convalidare l'input dell'utente. Anche se lo hai precedentemente convalidato prima di memorizzarlo sul computer degli utenti.

Fondamentalmente: non fidarti mai dell'input dell'utente.

What an hacker can do with this info?

Se i dati nel cookie non sono crittografati e verificati, l'utente malintenzionato può provare i cosiddetti attacchi xss. Per esempio. leggi (quello che ti aspetti) il nome utente dal cookie e lo rimandi all'utente.

per es.

  Users computer                   Your server

read username from cookie   ----   
                                   Information accepted at the server


                                   Display a greeting without verifying the contents
"Hello Jane. Welcome back!"  -----

Senza verifica il reso potrebbe essere un semplice:
"Ciao" + name_from-cookie +. Bentornato! "

Ora immagina qualcuno che cambia il cookie in "Jane. qualche comando "

Il browser degli utenti, già in comunicazione con il tuo server web attendibile, proverà a visualizzarlo e proverà a visualizzare i contenuti di qualche comando .

Questo è solo un esempio in cui puoi dire "ma se qualcuno potrebbe hackerare il proprio cookie per farlo potrebbe anche aver fatto cose peggiori". Questo è vero. Ma è solo un difetto che penso potrei facilmente spiegare. Potrebbero fare cose molto peggiori.

Ottieni nomi utente dagli utenti usando altri attacchi. Tutti i cookie sono informazioni memorizzate. Quando si può fare il furting dei cookie, si è già nei guai dato che PHP ecc memorizza l'id di sessione in un cookie.

I cookie sono informazioni non affidabili, quindi non fidarti mai dei dati e sanatizzarli.

Anche quando fai qualcosa del tipo: Hai effettuato l'accesso come "". $ SESSION ['username']. ' Spero che tu non abbia utenti chiamati alert ("xss")