Salvataggio di un ID su un cookie. Punto di vista della sicurezza?

Question

Salvataggio di un ID su un cookie. Punto di vista della sicurezza?

#1 da (1 voti)
#2 da (0 voti)

1

Sto sviluppando un sito Web ASP.NET MVC 5, che un utente può selezionare alcuni filtri, in base a quei riempitori che il server elabora un risultato e l'utente può effettuare un ordine e pagare per esso.

Nella mia tabella Order memorizzo i filtri (5 colonne), Id(PK) , e ho bisogno di memorizzare OrderId in cookie per tracciarlo, so che è una cattiva pratica da esporre e memorizza PK sul lato client, quindi creo un'altra colonna chiamata OrderId . Anche questo order id deve essere unico e una lettura amichevole (quindi un GUID è scarto qui), ho pensato di ottenere DateTime("yyyyMMddhhmmssffff") e concat con altro filtro per rendere questo ID, ma penso che sia un'opzione debole perché un utente malintenzionato potrebbe trovare facilmente il modello.

Qual è l'opzione che devo affrontare con questa situazione? Posso cancellare questo OrderID prima di salvare il cookie? E riguardo il salvataggio del codice semplice su DB? La convalida dei cookie è di 24 ore.

privacy cookies web-application

posta gog 01.06.2015 - 19:47

fonte

2 risposte

0

Non hai mai bisogno di usare i cookie.

Inserisci l'ID ordine nella stringa di query (riscrivi i collegamenti alle pagine per includerlo).

Sul lato server convalidare la richiesta memorizzando l'IP del client. Non consentire a computer con IP diversi di accedere allo stesso ordine.

risposta data 02.06.2015 - 05:29

fonte

Leggi altre domande sui tag privacy cookies web-application

Che cosa significa il campo della versione della chiave privata EC? VPN per l'anonimato degli utenti IP multipli

score 1 · Accepted Answer

A seconda della sensibilità dei dati, suggerirei i seguenti elementi, disposti dal meno sicuro al più sicuro.

Non fare nulla: in base al contenuto della tua domanda, probabilmente sceglierei questa opzione. Un filtro di ricerca non è associato a un utente (apparentemente) e probabilmente non espone nulla di particolarmente interessante. Potresti anche esporre il PK direttamente senza troppa preoccupazione, a meno che quei filtri non possano esporre dati sensibili. Conosco molti sistemi che utilizzano altri mezzi per proteggere i filtri (e tutti gli altri dati), in particolare utilizzando un ID di sessione effettivo in modo che il filtro possa essere visto solo dagli utenti autorizzati a vederlo.

Randomize PK: crea il PK un numero casuale invece di un numero automatico. Ciò impedisce alle persone di indovinare i PK contando avanti e indietro. Ciò rende più difficile trovare un filtro valido. Lo userei se il filtro non contiene alcun dato sensibile; rendi non banale per un utente malintenzionato trovare un filtro casuale. Vorrei utilizzare uno spazio numerico casuale di grandi dimensioni, ad esempio numeri a 64, 128 o 256 bit. Usalo se vuoi semplicemente evitare che le persone "sniffano" il tuo database per valori interessanti.

Firma PK: collega un nonce o un MAC a ciascun PK, in modo che sia necessario il nonce e il PK per recuperare il valore. Ciò impedisce modifiche casuali del PK sul client. Convalidare che il MAC o il nonce corrisponde al valore atteso. Questo dovrebbe scoraggiare gli hacker occasionali, specialmente se i dati sono particolarmente poco interessanti e non contengono informazioni personali.

Encrypt PK: crittografa semplicemente il cookie prima di inviarlo. Questa è la prima raccomandazione nella lista che suggerisce che il PK non sia inviato direttamente al cliente, e io utilizzerei questo metodo solo per identificare personalmente le informazioni, o se l'esposizione del filtro provocherebbe potenziali frodi. Vorrei anche combinare questo passaggio con la firma e la randomizzazione per una soluzione solida.