Esporre gli ID del database - rischio per la sicurezza?

Ho sentito che esporre gli ID del database (ad esempio negli URL) è un rischio per la sicurezza, ma ho difficoltà a capire il perché.

Qualche opinione o collegamento sul perché è un rischio o perché non lo è?

EDIT: ovviamente l'accesso è mirato, ad esempio se non riesci a vedere la risorsa foo?id=123otterrai una pagina di errore. Altrimenti l'URL stesso dovrebbe essere segreto.

MODIFICA: se l'URL è segreto, probabilmente conterrà un token generato che ha una durata limitata, ad esempio valido per 1 ora e può essere utilizzato solo una volta.

EDIT (mesi dopo): la mia attuale pratica preferita per questo è usare UUIDS per ID ed esporli. Se sto usando numeri sequenziali (di solito per prestazioni su alcuni DB) come ID, mi piace generare un token UUID per ogni voce come chiave alternativa ed esporlo.

Date le condizioni adeguate, l'esposizione degli identificatori non costituisce un rischio per la sicurezza. E, in pratica, sarebbe estremamente oneroso progettare un'applicazione web senza esporre identificatori.

Ecco alcune buone regole da seguire:

1. Utilizzare la sicurezza basata sui ruoli per controllare l'accesso a un'operazione. La modalità dipende dalla piattaforma e dal framework scelti, ma molti supportano un modello di sicurezza dichiarativo che reindirizzerà automaticamente i browser a un passaggio di autenticazione quando un'azione richiede una certa autorità.
2. Utilizzare la sicurezza programmatica per controllare l'accesso a un oggetto. Questo è più difficile da fare a livello di quadro. Più spesso, è qualcosa che devi scrivere nel tuo codice ed è quindi più soggetto a errori. Questo controllo va oltre il controllo basato sui ruoli garantendo non solo che l'utente disponga dell'autorizzazione per l'operazione, ma abbia anche i diritti necessari sull'oggetto specifico che viene modificato. In un sistema basato sui ruoli, è facile verificare che solo i manager possano dare rilanci, ma oltre a ciò, è necessario assicurarsi che il dipendente appartenga al reparto del manager specifico.
3. Per la maggior parte dei record del database, le condizioni 1 e 2 sono sufficienti. Ma l'aggiunta di ID imprevedibili può essere pensata come una piccola assicurazione extra, o "sicurezza in profondità", se si acquista in quella nozione. Un luogo in cui identificatori imprevedibili è una necessità, tuttavia, è negli ID di sessione o in altri token di autenticazione, in cui l'ID stesso autentica una richiesta. Questi dovrebbero essere generati da un RNG crittografico.

Pur non rappresentando un rischio per la sicurezza dei dati, questo è assolutamente un rischio per la sicurezza di business intelligence in quanto espone sia la dimensione che la velocità dei dati. Ho visto le aziende essere danneggiate da questo e ho scritto a fondo di questo anti-pattern. A meno che tu non stia solo costruendo un esperimento e non un business, ti consiglio vivamente di tenere i tuoi ID privati ​​al di fuori dell'opinione pubblica. https://medium.com/lightrail/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e

Dipende da cosa significano gli ID.

Considera un sito che per motivi competitivi non vuole rendere pubblico il numero di membri che possiede, ma utilizzando ID sequenziali lo rivela comunque nell'URL: http://some.domain.name/user?id=3933

D'altra parte, se invece hanno utilizzato il nome di accesso dell'utente: http://some.domain.name/user?id=some non hanno rivelato nulla che l'utente non conosceva già.

Il pensiero generale segue questa linea: "Rivela a chiunque poche informazioni sul funzionamento interno della tua app".

Esporre l'ID del database conta come divulgare alcune informazioni.

Le ragioni di ciò sono che gli hacker possono utilizzare qualsiasi informazione sui meccanismi interni delle tue app per attaccarti o che un utente può modificare l'URL per accedere a un database che non suppone di vedere?

Utilizziamo GUID per gli ID del database. Perdere è molto meno pericoloso.

Se stai usando ID interi nel tuo db, potresti rendere più semplice per gli utenti vedere i dati che non dovrebbero cambiare modificando le variabili qs.

Ad esempio un utente potrebbe facilmente cambiare il parametro id in questo qs e vedere / modificare i dati che non dovrebbero http: // someurl? Id = 1

Quando invii gli ID di database al tuo client sei costretto a controllare la sicurezza in entrambi i casi. Se mantieni gli ID nella tua sessione web puoi scegliere se vuoi / devi farlo, il che significa potenzialmente meno elaborazione.

Stai costantemente cercando di delegare le cose al tuo controllo di accesso;) Questo potrebbe essere il caso nella tua applicazione, ma non ho mai visto un sistema di back-end così coerente in tutta la mia carriera. La maggior parte di essi ha modelli di sicurezza progettati per un utilizzo non web e alcuni hanno avuto ruoli aggiuntivi aggiunti postumo, e alcuni di questi sono stati inseriti al di fuori del modello di sicurezza principale (poiché il ruolo è stato aggiunto in un diverso contesto operativo, ad esempio prima del web).

Quindi usiamo ID locali di sessioni sintetiche perché nascondono il più possibile.

C'è anche il problema dei campi chiave non interi, che può essere il caso di valori enumerati e simili. Puoi provare a disinfettare quei dati, ma è probabile che finirai come piccole tabelle drop bobby .