Evitare riferimenti diretti agli oggetti

6

Dire che volevo evitare di esporre una chiave primaria del database in un URL; in qualche modo devo crittografare la chiave, in modo che l'url esponga solo elementi di uno spazio cifrato non numerabile. Che tipo di crittografia dovrei usare?

NB. Sono consapevole che questo non è l'intero processo sicuro. Ovviamente dovrei convalidare il tentativo di accesso a tale URL. Sto chiedendo come usare la crittografia per aggiungere uno strato di offuscamento che impedisce l'enumerazione degli oggetti.

    
posta jl6 12.04.2013 - 18:46
fonte

4 risposte

5

Il riferimento diretto agli oggetti è un nome davvero brutto per: mancanza di controlli di autorizzazione . Conoscere l'ID non è davvero il problema. Il problema è che ogni record nel database deve avere le informazioni sulla proprietà e si dovrebbe applicare questa proprietà mantenendo le informazioni sull'utente in una sessione.

I migliori crittografi sanno quando la crittografia non è necessaria, e un sistema più strong può essere usato al suo posto.

    
risposta data 12.04.2013 - 18:52
fonte
2

La crittografia sull'ID del record non ha alcun significato. Potevano ancora riprodurre l'ID a meno che non fosse legato a una chiave di sessione. La domanda più grande però è perché una chiave primaria viene passata in un URL? Se stai monitorando lo stato della sessione, dovrebbe essere possibile lavorare con il lato del server di dati senza doverlo passare avanti e indietro. Puoi anche usare cose come POST per evitare di doverlo inserire nell'URL, anche se qualche identificatore deve essere passato al client.

Se l'ID è sensibile, imposta una mappatura monouso nel DB in modo da poter passare un token anziché un ID significativo. In questo modo non può essere interrotto e può essere risolto dal server solo per il periodo di tempo scelto dall'utente dall'utente scelto.

    
risposta data 12.04.2013 - 19:16
fonte
1

Esistono due metodi generali per evitare riferimenti a oggetti diretti insicuri.

Come @Rook dice che il modo migliore è Controllare l'autorizzazione su tutte le richieste :), questo è il posto giusto per risolvere il problema.

Se, per qualche ragione, non puoi farlo o vuoi un ulteriore livello di protezione potresti prendere in considerazione la creazione di una mappa di accesso, in modo che il riferimento presentato agli utenti non sia diretto e non possa essere modificato per dare accesso ai dati di altri utenti.

Per illustrare questo concetto. Diciamo che abbiamo un ID del database che va A1..A10000, che sono record per un numero di utenti. Quando l'utente accede o accede alla pagina che mostra loro questi dati, eseguiamo una query di database che restituisce tutti i record a cui dovrebbe avere accesso. Quindi sul server creiamo una tabella di mappatura

es

1 - > A1000

2 --- > A1005

etc

Quindi, quando forniamo l'ID all'utente, forniamo loro l'ID mappato (ad es. 1, 2) e non l'ID diretto (ad esempio A1000, A1005).

Quindi quando un utente fa una richiesta all'applicazione può solo richiedere gli ID a cui ha accesso e non la propria appartenenza ad altri utenti (poiché il riferimento diretto all'oggetto non è esposto ..)

    
risposta data 12.04.2013 - 21:53
fonte
1

Sebbene il controllo dell'accesso ai dati sia il modo migliore per affrontarlo, potrebbe non essere sempre possibile. In tali situazioni (e in aggiunta al controllo dell'accesso ai dati), è possibile implementare l'offuscamento utilizzando una mappa di accesso nel database (che potrebbe richiedere un po 'di spazio, a seconda di cosa si sta offuscando). Oppure puoi usare una crittografia simmetrica per generare il riferimento indiretto.

Suggerirei di usare AES e non DES o tripleDES. AES è più veloce di tripleDES. DES è obsoleto. Se stai usando .net controlla questo per un'implementazione: link

    
risposta data 12.04.2016 - 18:43
fonte

Leggi altre domande sui tag