Nella mia app Angolare, utilizzo l'id MongoDB negli URL. Ci sono rischi per la sicurezza a questo?
Dovrei usare un contatore invece, e poi nel mio DB ho una sorta di collezione che collega questo contatore all'ID reale? Quindi invece di mysite.com/story/56ede7fsdfdsfdsfs2a7283 vorrei usare mysite.com/story/32 ?
Non riesco a pensare a nessun rischio reale per la sicurezza di esporre l'ID mongoDB (rispetto ad altri counter id), oltre a esporre il tempo di creazione in base al server agli utenti. Avere la chiave primaria di mongo contro qualche altra chiave univoca (come un contatore) non dovrebbe fare la differenza in termini di esposizione.
Certo, dovresti essere consapevole che il mongo _id è composto da:
- a 4-byte value representing the seconds since the Unix epoch,
- a 3-byte machine identifier,
- a 2-byte process id, and
- a 3-byte counter, starting with a random value.
e forse non vuoi esporre alcune di queste informazioni ai tuoi utenti (come il tempo di creazione).
Quindi quando hai l'id 56ede7f0dfdsfdsfs2a7283 (che ha una cifra non esadecimale in s e sembra che manchi una cifra esadecimale alla fine - dovrebbe essere 12 byte o 24 esadecimale (0-9a -f) cifre, quindi ho sostituito il 's' con '0'), posso dire da 56ede7f0 che è stato creato a 2016-03-19T23:59:44.000Z . (Vedi ad esempio: link o prova: ObjectId("56ede7f0dfd0fd0f20a72830").getTimestamp() nella shell).
La OWASP indica che il semplice fatto di avere qualsiasi tipo di identificatore diretto può essere negativo, come spiegato in I 10 principali riferimenti agli oggetti diretti 2007 non sicuri e Le 10 voci di riferimento 10-A4-Insecure Direct Direct . Un utente malintenzionato in grado di capire come sfruttare tale riferimento diretto avrà molto più potere di quanto dovrebbe.
OWASP consiglia di utilizzare un valore di indice, come richiesto qui, ma è possibile che vengano forniti con i propri problemi. Dare agli aggressori un modo semplice e facile per accedere in modo sequenziale a tutti i dati può consentire loro di leggere, aggiornare o persino cancellare facilmente l'intero database se trovano un exploit di autenticazione o privilegio di escalation.
Nel mondo reale, tali eventi sono accaduti prima. Come diversi dump di indirizzi e-mail ottenuti dai servizi utilizzando una semplice chiave primaria in una pagina di reimpostazione della password. O sistematicamente avendo tutti i loro messaggi cancellati dal servizio. L'elenco può continuare, ma il punto è se si decide di utilizzare un campo di incremento automatico come chiave primaria, assicurarsi che tutte le pagine che utilizzano quell'ID convalidino la richiesta per assicurarsi che ( a) l'utente ha un'autorizzazione sufficiente e (b) la richiesta non è stata falsificata, probabilmente includendo i token di falsificazione delle richieste tra siti, valori essenzialmente nonce che verificano che la richiesta sia legittima.
Questo espone le meta informazioni nell'ID MongoDB come indicato nella risposta da dr jimbob che è un problema di sicurezza in alcuni aspetti.
Un altro modo per pubblicare questa domanda è
What is the best practice for not exposing meta information about the entries in my DB in links and URIs?
La risposta a questa domanda è semplice: Utilizzare un campo identificativo univoco per la voce che non è legato a nessuna meta informazione. Questi possono essere generati facilmente, confrontati con altre voci e, se viene trovata una collisione, generarne un'altra. È quindi possibile memorizzarlo in un hash / indice / qualsiasi sistema utilizzato da MongoDB per trovare questi documenti più velocemente.
Tuttavia questo non riguarda le persone che li condividono sui social media, quindi assicurati che il tuo modello di sicurezza tenga conto di ciò e impedisca alle persone di vedere cose che non dovrebbero.
Invio di informazioni nell'URL
Un URL potrebbe essere accessibile anche a una persona che non dovrebbe avere accesso alla pagina effettiva a cui conduce. Dopo che tutti gli URL possono essere visualizzati in collegamenti su tutto il Web o perdite tramite le intestazioni di referer. Pertanto non dovrebbero esserci informazioni sensibili nell'URL.
L'ID Mongo contiene informazioni sul tempo di creazione dell'oggetto (dalla prima parte). Il contatore contiene solo informazioni su in quale ordine sono stati creati gli oggetti.
Il contatore fornisce anche informazioni su quanti oggetti ci sono in totale (vedi il problema dei carri armati tedeschi ). Ma lo è anche l'ID Mongo, poiché l'ultima parte è un contatore globale. Inizia da un numero casuale, quindi trasmette meno informazioni, ma un utente malintenzionato con molti URL può comunque stimare il numero totale di documenti.
Attacchi di enumerazione
Se gli URL sono sequenziali, è facile per un utente malintenzionato ottenere un elenco di tutte le risorse. Questo è chiamato un attacco di enumerazione.
Per il contatore questo è ovviamente facile da fare. Per l'ID Mongo è più difficile, dal momento che devi indovinare in quale millisecondo sono stati creati gli oggetti. Se hai una vaga idea su che ora vengono creati gli oggetti, puoi ancora forzarla.
Conclusione
Se sei preoccupato di rivelare informazioni sui tuoi documenti negli URL o di consentire agli utenti di enumerare tutti i documenti, entrambi gli approcci sono piuttosto negativi. Se non lo sei, entrambi gli approcci vanno bene.
Una terza soluzione
Se i problemi sopra ti preoccupano, puoi usare un ID casuale . Usa uno spazio ampio per ridurre la probabilità di collisioni e gestisci gli errori in modo che le cose non si interrompano se sei sfortunato.
L'ID potrebbe essere memorizzato come _id (puoi sovrascrivere il valore predefinito) o in un campo chiamato url_id o qualcosa del genere. Metti un indice hash univoco su di esso per velocizzare le ricerche.
Leggi altre domande sui tag mongodb web-application