Evitare di esporre le chiavi primarie nella sorgente di un'app Web?

Question

Spesso mi imbatto in applicazioni Web che espongono chiavi primarie del database interno tramite moduli come caselle di selezione. E occasionalmente vedo la corrispondenza javascript con un valore magico int o guid che cambia la logica.

È consigliabile evitare perdite di tutti gli identificatori interni delle righe nell'applicazione Web per impedire agli estranei di comprendere troppo il proprio sistema e utilizzarlo eventualmente per sfruttare il proprio sistema. Se sì, qual è il modo migliore per risolvere questo problema?

Se si espone un altro valore all'app Web che può essere nuovamente tradotto nella chiave primaria?

Grazie

Modifica

In un mondo perfetto la vostra applicazione sarebbe sicura al 100% in modo che non avrebbe importanza se oscurato le cose. Ovviamente non è così, dovremmo avere degli errori sul lato della cautela e non esporre queste informazioni?

Alcuni hanno sottolineato che StackOverflow sta probabilmente esponendo una chiave nell'URL che probabilmente sta bene. Tuttavia sono considerazioni diverse per le applicazioni aziendali?

Answer 1

non sono d'accordo con la posizione che esporre le chiavi primarie è un problema. Può essere un problema se li rendi visibili agli utenti perché a loro viene dato un significato al di fuori del sistema, che di solito è quello che stai cercando di evitare.

Tuttavia, per utilizzare gli ID come valore per gli elementi della casella combinata? Vai per questo dico. Qual è il punto nel fare una traduzione da e verso un valore intermedio? Potresti non avere una chiave univoca da usare. Una tale traduzione introduce più potenziale per i bug.

Basta non trascurare la sicurezza.

Se si dice che l'utente presenta 6 elementi (ID da 1 a 6), non assumere mai che si otterranno tali valori solo dall'utente. Qualcuno potrebbe provare a violare la sicurezza inviando l'ID 7, quindi è ancora necessario verificare che ciò che si ottiene sia consentito.

Ma evitando tutto questo? Non c'è modo. Non c'è bisogno.

Come commento su un'altra risposta dice, guarda l'URL qui. Ciò include ciò che è senza dubbio la chiave primaria per la domanda nel database SO. È assolutamente bene esporre le chiavi per usi tecnici.

Inoltre, se si utilizza un valore surrogato, non è necessariamente più sicuro.

Answer 2

Sì a tutte le vostre domande. Sono d'accordo con le tue affermazioni che devi "esporre un altro valore all'app web che può essere convertita alla chiave primaria"

Altrimenti puoi aprirti a potenziali problemi.

Modifica

quanto riguarda il commento che "non v'è alcun motivo per prendere il colpo penalità per chiavi banali. Guarda nella URL del browser in questo momento, scommetto che si vede una chiave!".

Capisco cosa stai dicendo e, sì, vedo la chiave nell'URL SO e sono d'accordo che probabilmente si riferisce a un database PK. Concedo in casi come questi è probabilmente OK se non c'è un'alternativa migliore.

Preferisco ancora esporre qualcosa di diverso da un PK - qualcosa con valore semantico. Il titolo della domanda è anche nell'URL, ma poiché sarebbe difficile da verificare come univoco (o passare tra gli utenti verbalmente) non può essere utilizzato in modo affidabile per conto proprio.

Osservando gli URL "tag" tuttavia (ad esempio https://stackoverflow.com/questions/tagged/java+j2ee), i PK non sono esposti e vengono invece utilizzati i nomi dei tag. Personalmente, preferisco quell'approccio e mi impegnerei per questo.

Volevo anche aggiungere che i dati a cui punta un PK a volte possono cambiare nel tempo. Ho lavorato su un sistema in cui una tabella era piena di informazioni provenienti da un processo offline, cioè statistiche mensili in cui il contenuto della tabella DB è caduto alla fine del mese e si è ripopolato con nuovi dati.

Se i dati vengono aggiunti al db in un ordine diverso, i PK per specifici punti di dati cambieranno e tutti i segnalibri salvati dal mese precedente a tali dati ora puntano a un diverso insieme di dati.

Questa è un'istanza in cui l'esposizione di un PK "interrompe" un'applicazione non correlata alla sicurezza dell'app. Non così con una chiave generata.

Answer 3

Sì, l'esposizione delle chiavi è un'informazione che può essere utilizzata come attacco. Soprattutto se sono prevedibili.

Utilizzare una chiave/colonna diversa se si ritiene che l'informazione sia sensibile.

Ad esempio, per evitare di mostrare come possono gli utenti di avere, prendere in considerazione:

site.com/user/123 vs site.com/user/username

Answer 4

Come sempre, "dipende". Se qualcuno può ottenere valore (ad esempio) sapendo quante transazioni stai eseguendo per (ora/giorno/mese) e stai esponendo un ID transazione come un numero monotonicamente crescente, allora questo è un rischio.

Come altri hanno già detto, per un elenco a discesa di valori, di solito nessun problema.

Answer 5

L'esposizione di altri valori rispetto alla chiave primaria non ti eviterà l'onere di controllare la sicurezza. Infatti, se la tua sicurezza ha dei buchi, gli utenti "cattivi" potrebbero comunque accedere agli oggetti a cui non sono destinati cambiando il valore nell'URL. Potrebbero avere meno indizi su quali valori usare, ma scegliendo in modo casuale i valori, potrebbero essere fortunati.

Se si desidera migliorare la sicurezza in questo modo, sarà necessario utilizzare grosse stringhe casuali (per rendere difficile l'indovinello) nell'url, anziché l'id e utilizzare una tabella di riferimento indiretto corrispondente al valore casuale con l'id valido nel sfondo.

Penso che non valga la pena la maggior parte del tempo.

Detto questo, è utile per i casi in cui si desidera "sicurezza per oscurità", come ad esempio quando si espongono pagine per modificare le password degli utenti, che non richiedono alcun accesso (per gli utenti che hanno perso la password). In questo tipo di caso, è necessario associare una data di validità limite alla propria chiave.

Answer 6

Una chiave primaria non è la stessa cosa di una chiave surrogata o di una chiave interna, sebbene ci sia qualche sovrapposizione. L'opposto di una chiave interna è una chiave naturale. Ci sono molte volte in cui una chiave naturale viene utilizzata come chiave primaria.Non c'è, in generale, alcun motivo per nascondere una chiave naturale, a meno che non si tratti di problemi di privacy.

La tua vera domanda è, penso, se le chiavi interne debbano essere esposte agli utenti. La risposta è, dipende". Per la maggior parte delle comunità di utenti, l'esposizione della chiave interna comporta l'utilizzo della chiave come chiave naturale. Questo può, e di solito avviene, creare confusione quando il mapping one-to-one tra la chiave interna e l'oggetto della riga della tabella si interrompe.

Questa interruzione può verificarsi solo a causa della cattiva gestione dei dati. Nella maggior parte dei casi, tuttavia, è necessario pianificare un errore nella gestione dei dati nel mondo reale. Non pianificheresti un sistema di approvvigionamento idrico che si guasta ogni volta che si verifica un malfunzionamento dell'acqua. Non si pianifica un sistema di informazioni che si rompe ogni volta che si verifica un errore nella gestione dei dati.

Detto questo, la maggior parte dei progettisti di database in questi giorni lavora per i fornitori di software e non vede i problemi causati da errori di gestione dei dati da parte degli utenti dei loro prodotti.