L'oscuramento / offuscamento degli ID di database rivolti al pubblico è davvero una "best practice"?

Non penso che sia così importante, ma ci sono alcuni scenari in cui potrebbe importare a seconda delle altre decisioni che prendi.

Ad esempio, se dovessi esporre un ID ordine generato in sequenza e hai un attacco di social engineering con qualcuno che chiama l'assistenza clienti e dici "hey, ho appena speso $ 2000 su un nuovo computer e voi ragazzi mi avete mandato un altro l'ordine di un uomo per un cavo da 15 $, ora sono fuori da $ 2000 "potresti passare molto tempo a cercare di controllare il problema prima di concludere che è falso o di inviare il falso a un nuovo computer.

Ci sono variazioni simili, meno sofisticate, ma imbarazzanti sul tema; se un malintenzionato incrementa un ID ordine un link inviato a una ricevuta e se non vengono effettuate ulteriori convalide per verificare che la persona che ha fatto clic sul link abbia il diritto di visualizzare l'ID ordine, improvvisamente stai esponendo involontariamente informazioni sui clienti privati alla persona sbagliata.

In questi casi, se i numeri non sono sequenziali, l'esposizione è leggermente mitigata perché è più probabile che l'indovinazione produca risultati interessanti. D'altra parte, ora è necessario un modo conveniente per fare riferimento a un ID ordine nelle interazioni di assistenza clienti che non comporterà lunghe conversazioni avanti e indietro con le interazioni con i clienti telefoniche mentre il vostro rappresentante cerca di distinguere tra B, PD e T nell'ordine numero BPT2015D.

Direi che è un modo per chiamare questa offuscazione una "best practice", ma in alcuni scenari, può ridurre la facilità di sfruttare un'altra debolezza nel codice di convalida o di autorizzazione. D'altra parte, non importa se qualcuno sa che hai scritto post sul blog n. 1 o n. 2559. Se l'ID non è una informazione preziosa, anche con conoscenze aggiuntive, allora l'argomento che offuscamento è una buona pratica ha meno peso.

Esiste un secondo potenziale argomento, ovvero che l'identificatore del database può sposarti a una particolare implementazione (o istanza) del database e quando la tua azienda viene comprata o prende in mano un concorrente e ora devi unire due sistemi legacy, o il CEO esce a bere con il rappresentante di DynoCoreBase e decide che trasferirai tutti i tuoi dati nella versione 13h di DynoCoreBase e vuole che tutte le chiavi primarie siano guid, e devi creare una sorta di livello di mappatura per tradurre vecchio Gli ID ai nuovi ID in modo che i vecchi URL non si interrompano, ma se questi scenari contano per te dipendono molto più dalla natura della tua azienda (e dal coinvolgimento del cliente con questi ID) che da qualsiasi best practice generale.

Questa è la mia opinione su questo:

Mentre "la sicurezza attraverso l'oscurità" ovviamente non è sufficiente, l'oscurità può aiutare la sicurezza, anche se solo un po '. Devi decidere se quel poco di psuedo-security vale lo sforzo extra necessario per implementare qualcosa di simile nella tua applicazione.

C'è un altro motivo al di fuori della sicurezza che posso pensare di implementare:

Privacy

Diciamo che abbiamo a che fare con ID utente nell'URL. Se l'ID utente di Joe è 100 e l'ID utente di Mario è 101 , è probabilmente ovvio che l'account di Joe è stato creato per primo. Anche se questo potrebbe non essere rilevante nella maggior parte delle applicazioni, potrebbe essere importante per alcuni. Questo è un esempio di privacy stricly attraverso l'oscurità, quindi a meno che non si disponga di un sistema molto sofisticato di offuscamento degli ID utente, potrebbe essere abbastanza facile dissolversi e capire se l'utente con id 3Js9kW3hTs7sa120 ha ha un account più lungo dell'utente con id Q8Hs73kks0hEg .

Dal link a cui ho fatto riferimento:

The first is that given the URL for some object, you can figure out the URLs for objects that were created around it. This exposes the number of objects in your database to possible competitors or other people you might not want having this information (as famously demonstrated by the Allies guessing German tank production levels by looking at the serial numbers.)

L'utilizzo di un ID di incremento automatico espone pubblicamente il numero di oggetti nel database e può esporre quali sono stati creati per primi e quali sono più recenti. Questa informazione può rivelare il fatto che un'azienda è nuova o non sta facendo bene. Ad esempio: supponiamo che ordini un libro e che l'ID ordine sia 1 . Potrebbe essere evidente che il tuo ordine è stato il primo nel sistema, che può essere snervante. Diciamo che torni indietro e ne ordini un altro e il tuo ID ordine è 9 . Questo dà via le informazioni che solo 7 ordini sono stati collocati nel periodo di tempo tra i due ordini. Questa potrebbe essere una preziosa informazione per i concorrenti. In questo caso, l'ID di incremento automatico numerico probabilmente è meglio offuscato.

La parola "Obscure" probabilmente è leggermente fuorviante e potrebbe indurre la gente a pensare "offuscare" o "nascondere parzialmente".

La raccomandazione è che non includi mai alcuna chiave di database generata internamente come parte di un URL pubblico se questi record del database contengono dati sensibili.

È troppo facile giocare con i numeri nell'URL e accedere ad altri record.

Andrò contro il mainstream e ti dirò che usare un identificatore casuale a lungo è, a mio parere, una forma di sicurezza abbastanza decente.

Deve essere chiaro a chiunque abbia accesso a quei dati che è tanto sensibile quanto una password. E naturalmente ha lo svantaggio che se va in giro potrebbe essere più difficile da cambiare.

Ma ha un paio di vantaggi rispetto alla solita coppia di username e password. Innanzitutto, l'utente non ha scelta su di esso, quindi puoi essere certo che è praticamente impossibile indovinarlo. Non ha senso progettare un sito perfettamente sicuro quando l'amministratore sceglie il suo nome come password. Secondo, ogni elemento ha un identificatore diverso, quindi se si accede a un oggetto, questo non aiuta l'altro.

Naturalmente, più livelli di sicurezza ci sono, meglio è. Ma questo metodo da solo può essere più sicuro di un paio di credenziali.

Ci sono due aspetti: usabilità e sicurezza.

ID di sicurezza e oscuranti sono piuttosto inutili; l'importante è che l'ID non debba mai essere l'unica 'chiave' per qualsiasi risorsa non pubblica. Ciò significa che se si desidera fornire agli utenti selezionati l'accesso a una determinata pagina, basta richiedere l'ID della pagina nell'URL non è sufficiente, è necessario implementare un meccanismo di sicurezza reale come un login utente / password o l'autenticazione della chiave pubblica / privata, così come un'autorizzazione appropriata (cioè, il sistema deve essere in grado di giudicare, caso per caso, se l'utente X è autorizzato ad accedere alla risorsa Y, e agire di conseguenza).

Per quanto riguarda l'usabilità, il consiglio generale è di tenere nascoste le chiavi artificiali: non hanno alcun significato per l'utente e, rivelandole in modo ovvio, si introduce una dipendenza extra, particolarmente difficile da gestire perché vive al di fuori del regno del software - le persone scriveranno, e-mail, fax, stampa, segnalibro, ecc., quelle dell'ID, e se mai le cambierai, ti sentirai infastidito biglietti di supporto.

No , assolutamente, in modo positivo non vuoi consentire l'accesso a risorse arbitrarie solo conoscendo il loro ID interno. Questo è internet, qualunque sia la presenza infantile, criminale o semplice che si possa immaginare di esistere, esiste realmente e, prima o poi, sarà venuto sul tuo sito. A meno che tutto ciò che potresti mai servire sia completamente pubblico per tutti (e se hai anche un solo cliente, è garantito che non sia così), devi limitare l'accesso a coloro che sono effettivamente autorizzati ad averlo .

La solita soluzione consiste nell'utilizzare token di autorizzazione di qualche tipo archiviati in una sessione crittografata e controlla che verifichi se qualcosa debba essere visibile all'utente autenticato prima di inviarlo effettivamente. Può trattarsi di un vero gestore della sicurezza, come quello fornito con JDK o qualsiasi altro componente che svolge lo stesso ruolo, purché lo faccia in modo coerente. (Se esporre gli ID interni a qualcuno che è già autenticato o meno è anche una domanda interessante con vari pro e contro, ma è meno essenziale per la sicurezza.)

Il valore di fare questo è difficile da calcolare fino a quando non viene effettivamente attaccato da qualcuno che intende fare affari. Quindi di solito è la differenza tra uscire dal business e semplicemente scrollare di dosso l'ennesimo script kiddie sventato.

Ovviamente dipende da quanto siano sensibili i dati ma per la sicurezza media il minimo che vorrei fare è includere l'ID e un valore di checksum.

Genera il checksum aggiungendo sale (cioè una serie di caratteri casuali) prima e dopo l'ID e facendo un MD5 sul valore.

In ogni pagina che legge il valore ID dovrebbe generare il valore di checksum e confrontarlo con quello passato, negare la richiesta se non corrisponde.

Se un potenziale hacker è in grado di ottenere sufficienti combinazioni valide, allora potrebbe essere in grado di calcolare il valore di Salt con la forza bruta, quindi se è possibile aggiungere un altro livello di sicurezza come il controllo dell'ID utente che aiuterà anche.