Quanto dovrei preoccuparmi di nascondere gli ID del mio database negli URL?

Question

Quanto dovrei preoccuparmi di nascondere gli ID del mio database negli URL?

#1 da (4 voti)
#2 da (3 voti)

1

Continuo a trovare domande e articoli su Internet che suggeriscono che non è una buona pratica che gli ID dei tuoi record di database siano visibili al pubblico. Tuttavia non ho mai preso sul serio me stesso né ho (nella mia carriera professionale) imbattersi in un'applicazione che ha tentato attivamente di nascondere gli ID. Recentemente ho lavorato a un'applicazione MVC e ho i miei URL pubblici nel seguente formato:

/Book/55/title-of-book

Dovrei sforzarmi di cambiare la parte Id dell'URL (55) in un hash di qualche tipo? Ad esempio, ecco come Reddit ha i suoi URL:

/r/subreddit/comments/36v4kb/title_of_article/

Se dovessi mantenere gli ID nascosti nei miei URL, dovrei anche toglierli da tutti i posti in cui appaiono pubblicamente nel mio codice e apportare modifiche al mio database. Non è un compito facile, ma non ho problemi a farlo se è considerato una buona pratica.

Quali sono i vantaggi di tenere gli ID nascosti e quali sono i modi migliori per ignorarli?

web-development security

posta Alternatex 22.05.2015 - 21:37

fonte

2 risposte

3

Penso che il più grande vantaggio di nascondere gli ID e presentare una stringa simile a un hash, invece, è impedire che i record vengano raccolti semplicemente incrementando il valore. Questo non è tanto un problema di sicurezza, ma un deterrente per aspiranti raccoglitori di dati che potrebbero voler raccogliere o indicizzare dati dal vostro servizio.

Per quanto riguarda l'implementazione di questo, sarebbe meglio generare un ID casuale quando viene creato l'oggetto dati piuttosto che eseguire una sorta di hashing su un ID numerico incrementale ogni volta che viene servito.

risposta data 22.05.2015 - 21:45

fonte

Leggi altre domande sui tag web-development security

Evita errori numerici nel metodo Naive Bayes "Sweep" un vettore di puntatori

score 4 · Accepted Answer

Il pattern /Book/55/title-of-book ha un vantaggio importante: contiene il titolo del libro, che è utile per SEO, ma anche l'ID, che:

Non cambierà (a meno che non cambi il tipo di ID, diciamo uniqueid invece di int ).
È l'unica cosa necessaria per individuare la risorsa corrispondente. Questo è importante quando hai bisogno di un URI più corto, specialmente quando l'URI deve essere digitato a mano. Preferisco piuttosto inserire http://example.com/book/55 di http://example.com/book/a90K3DYb7 .
Potrebbe essere più facile indicizzare e analizzare (anche se probabilmente sarebbe l'ottimizzazione prematura nel 99,9% dei casi).

Detto questo, gli ID auto-incrementati hanno quei problemi:

Se l'ultimo libro aggiunto ha un ID 55, non è difficile dedurre che ci siano circa 55 libri nel sistema. Ciò potrebbe avere un impatto negativo sui tuoi clienti, soprattutto se il tuo reparto marketing dichiara di avere il più grande database di libri (o di avere decine di migliaia di libri).
È possibile enumerare i libri uno per uno. Questo potrebbe non essere quello che desideri: potresti preferire che i tuoi utenti passino attraverso il motore di ricerca o altre parti del sito web per trovare un libro specifico. Potresti anche voler rendere più difficile per i robot ottenere ogni pagina per ogni libro.
Con l'enumerazione dei libri, è possibile determinare quanti sono stati rimossi o nascosti al pubblico. Ad esempio, questo è un problema che ho nel mio blog: dal momento che gli URI contengono l'ID auto-incrementato, chiunque può capire tramite la scansione di tutti gli articoli che sono stati rimossi o mai rilasciati (vale a dire che rimangono come bozze).