Oscurare / offuscare gli ID di database rivolti al pubblico è davvero una "best practice"?

Ho sentito gente insegnare qua e là su Internet che è meglio oscurare gli ID del database pubblico nelle applicazioni web. Suppongo che significino principalmente nelle forme e negli URL, ma non ho mai letto niente di più di un boccone sull'argomento.

EDIT : Certo, ora che chiedo questo, trovo alcune risorse sull'argomento:

• /programming/2374538/obscuring-database-ids
• /programming/1895685/should-i-obscure-primary-key-values
• http://joshua.schachter.org/2007/01/autoincrement.html

Questi link hanno soddisfatto alcune delle mie curiosità, ma i post SO non hanno molti voti e non sono necessariamente centrati sull'argomento in questo contesto, quindi non sono sicuro di cosa farne, e alcuni di loro affermano che il terzo il collegamento è falso. Lascio il resto del mio post intatto:

Comprendo le differenze tra oscurità e sicurezza, nonché il modo in cui i due possono lavorare insieme, ma non riesco a immaginare perché ciò sia necessario.

C'è qualche verità in questo, è solo paranoia o è totalmente totalmente fasullo?

Posso pensare a come farlo, ma ovviamente aggiunge molta complessità al codice dell'applicazione. In quali circostanze sarebbe utile? Se questo è qualcosa che le persone fanno spesso, come viene di solito distribuito? Hashing degli identificatori? Qualcos'altro? Sembra un sacco di lavoro per non molta sicurezza in più. Non sto cercando soluzioni reali, voglio solo avere un'idea di come / perché le persone lo farebbero nel mondo reale.

È davvero considerata una "best practice" o è semplicemente una micro-ottimizzazione di scarso valore?

NOTA : penso che alcune persone potrebbero aver avuto un'idea sbagliata: non sto suggerendo che gli ID difficili da indovinare sarebbero l' unico meccanismo di sicurezza, ovviamente ci sarebbero i soliti controlli di accesso. Supponiamo che siano presenti e che la semplice conoscenza dell'ID o dell'hash di un record non sia sufficiente per consentire l'accesso.

Non credo 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 avuto un attacco di ingegneria sociale con qualcuno che ha chiamato l'assistenza clienti e ha detto "hey, ho appena speso $ 2000 su un nuovo computer e voi ragazzi mi avete inviato l'ordine di un altro ragazzo per un cavo da $ 15, ora sono fuori $ 2000 "potresti passare un sacco di tempo a cercare di controllare il problema prima di concludere che è falso o inviare al faker un nuovo computer.

Esistono variazioni simili, meno sofisticate, ma imbarazzanti sul tema; se un malintenzionato incrementa un ID ordine di un collegamento inviato via e-mail a una ricevuta e se non vengono effettuate ulteriori convalide per verificare che la persona che ha fatto clic sul collegamento abbia il diritto di visualizzare l'ID ordine, improvvisamente stai involontariamente esponendo informazioni private del cliente alla persona sbagliata.

In questi casi, se i numeri non sono sequenziali, l'esposizione è leggermente mitigata perché è meno probabile che si indovini producano risultati interessanti. D'altra parte, ora hai bisogno di un modo conveniente per fare riferimento a un ID ordine nelle interazioni dell'assistenza clienti che non si tradurrà in lunghe conversazioni avanti e indietro con interazioni con i clienti telefoniche mentre il tuo rappresentante cerca di distinguere tra B, PD e T nel numero di ordine BPT2015D.

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

C'è un secondo potenziale argomento, ovvero che l'identificatore del tuo database potrebbe sposarti a una particolare implementazione (o istanza) del database e quando la tua azienda viene acquistata o acquisisce un concorrente e ora devi unire due sistemi legacy o il CEO esce bevendo con il rappresentante di DynoCoreBase e decidono che ora trasferirai tutti i tuoi dati su DynoCoreBase versione 13h e vuole che tutte le chiavi primarie siano guide e devi creare una sorta di livello di mappatura per tradurre i vecchi ID in nuovi ID in modo che i vecchi URL non si rompano, ma se questi scenari contano per te dipendono molto più dalla natura della tua attività (e dal coinvolgimento del cliente con tali ID) che da qualsiasi best practice generale.

Questa è la mia opinione su di esso:

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

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

vita privata

Diciamo che abbiamo a che fare con gli ID utente nell'URL. Se l'ID utente di Joe è 100e l'ID utente di Bob è 101, è probabilmente ovvio che l'account di Joe sia stato creato per primo. Anche se questo potrebbe non importare nella maggior parte delle applicazioni, per alcuni potrebbe essere importante. Questo è un esempio di privacy rigorosamente attraverso l'oscurità, quindi a meno che tu non abbia un sistema molto sofisticato di offuscamento degli ID utente, potrebbe essere abbastanza facile da dissolvere e capire se l'utente con ID 3Js9kW3hTs7sa120ha avuto un account più lungo dell'utente con ID Q8Hs73kks0hEg.

Dal link a cui ho fatto riferimento:

Il primo è che, dato l'URL di alcuni oggetti, puoi capire gli URL degli oggetti che sono stati creati attorno ad esso. Questo espone il numero di oggetti nel tuo database a possibili concorrenti o altre persone che potresti non desiderare avere queste informazioni (come è noto dagli alleati che indovinano i livelli di produzione di carri armati tedeschi osservando i numeri di serie).

L'uso 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. Queste informazioni possono rivelare il fatto che un'azienda è nuova o che non sta andando bene. Ad esempio: supponiamo che ordini un libro e il tuo ID ordine lo sia 1. Potrebbe essere evidente che il tuo ordine è stato il primo nel sistema, il che può essere snervante. Diciamo che torni indietro e ne ordini un altro e il tuo ID ordine è 9. Ciò fornisce le informazioni secondo cui solo 7 ordini sono stati inseriti nell'intervallo di tempo tra i due ordini. Questa potrebbe essere un'informazione preziosa per i concorrenti. In questo caso, l'id di incremento automatico numerico è probabilmente meglio offuscato.

La parola "Oscuro" probabilmente qui è leggermente fuorviante e può indurre la gente a pensare "offuscata" o "parzialmente nascosta".

La raccomandazione è di non includere mai alcuna chiave di database generata internamente come parte di un URL pubblico se questi record di 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 lungo e casuale è secondo me una forma di sicurezza abbastanza decente.

Deve essere chiarito a chiunque abbia accesso a tali dati che è tanto sensibile quanto una password. E, naturalmente, ha lo svantaggio che se va in natura potrebbe essere più difficile cambiare.

Ma ha un paio di vantaggi rispetto alla solita coppia di username e password. Innanzitutto, l'utente non ha scelta, quindi puoi essere certo che sia praticamente impossibile indovinarlo. Non ha senso progettare un sito perfettamente sicuro quando l'amministratore sceglie il suo nome come password. In secondo luogo, ogni articolo ha un identificatore diverso, quindi se uno ha accesso a un oggetto, questo non aiuta con l'altro.

Certo, 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.

Gli ID oscuranti per la sicurezza 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 consentire agli utenti selezionati di accedere a una determinata pagina, non è sufficiente richiedere l'ID della pagina nell'URL, è necessario implementare un meccanismo di sicurezza effettivo come un login nome utente / password o autenticazione chiave pubblica / privata, nonché un'autorizzazione adeguata (vale a dire, il sistema deve essere in grado di giudicare caso per caso se l'utente X può accedere alla risorsa Y e agire di conseguenza).

Per quanto riguarda l'usabilità, il consiglio generale è quello di tenere nascoste le chiavi artificiali: non hanno alcun significato per l'utente e, rivelandole in modi ovvi, si introduce una dipendenza aggiuntiva, una che è particolarmente difficile da gestire perché vive fuori il regno del software - la gente sarà scrivere, e-mail, fax, stampa, segnalibri, ecc, quelli ID di, e se mai li cambia, siete dentro per alcuni biglietti di sostegno fastidiosi.

No , assolutamente, assolutamente non vuoi consentire l'accesso a risorse arbitrarie solo conoscendo il loro ID interno. Questo è internet, qualunque sia dannoso, penale, o semplice presenza infantile si potrebbe immaginare di esistere, in realtà esiste , e prima o poi dovranno venire al vostro sito. A meno che tutto ciò che potresti mai servire sia completamente pubblico per tutti (e se hai anche un solo cliente, questo è garantito per non essere il caso), devi limitare l'accesso a coloro che sono effettivamente autorizzati ad averlo.

La solita soluzione consiste nell'utilizzare i token di autorizzazione di qualche tipo archiviati in una sessione crittografata e verifica che qualcosa sia visibile all'utente autenticato prima di inviarlo effettivamente. Questo può essere un vero gestore della sicurezza, come quello fornito con JDK o qualsiasi altro componente che ricopre 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 farlo è difficile da calcolare fino a quando non si viene effettivamente attaccati da qualcuno che significa affari. Quindi di solito è la differenza tra uscire dal mercato e scrollarsi di dosso l'ennesimo enigmatico copione.

Ovviamente dipende da quanto sono sensibili i dati, ma per sicurezza media il minimo che farei è includere l'ID e un valore di checksum.

Generare il checksum aggiungendo salt (ovvero una raccolta di caratteri casuali) prima e dopo l'ID e facendo un MD5 sul valore.

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

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