Progettazione e sicurezza dell'API: perché nascondere gli ID interni?

Question

Ho sentito alcune persone dire che non dovresti mai esporre i tuoi ID interni al mondo esterno (ad esempio una chiave primaria auto_increment'ng).

Alcuni suggeriscono avere una sorta di colonna UUID che si utilizza invece per le ricerche.

mi chiedo veramente perché questo sarebbe stato suggerito e se è veramente importante.

Utilizzando un uuid invece è fondamentalmente solo offuscando l'id. Qual e il punto? L'unica cosa che posso pensare è che gli interi autoincrementanti indicano ovviamente l'ordine dei miei oggetti db. Importa se un utente esterno sa che una cosa è stata creata prima/dopo un'altra?

O è puramente che offuscare gli ID impedisce di "indovinare" a diverse operazioni su oggetti specifici?

Questo è anche un problema che dovrei pensare a quando si progetta un'API rivestimento esterno?

Answer 1

Qualsiasi informazione che fornisci all'utente malintenzionato sulla tua applicazione e sul suo layout può e sarà utilizzata contro la tua applicazione. Uno dei problemi che dobbiamo affrontare nella sicurezza delle applicazioni (web) è che le decisioni progettuali apparentemente innocue prese durante l'infanzia di un progetto diventano tacchi d'Achille quando il progetto si ingrandisce. Lasciando un congetture attaccante make informato circa l'ordine di entità può tornare a ritorcersi contro di te in seguito, modi un po 'non collegati:

1. L'ID dell'entità inevitabilmente essere passato come parametro a un certo punto della tua applicazione . Ciò consentirà agli hacker di essere in grado di alimentare gli argomenti delle applicazioni a cui normalmente non avrebbero accesso. Sono stato personalmente in grado di visualizzare i dettagli dell'ordine (sul sito di un rivenditore molto popolare) che non avevo alcuna visione aziendale, come argomento URL non meno. Ho semplicemente alimentato i numeri sequenziali dell'app dal mio ordine legittimo.

2. Conoscere i limiti o almeno la progressione dei valori dei campi di chiave primaria è un foraggio di valore inestimabile per gli attacchi di SQL injection, ambito di cui non riesco a trattare qui.

3. I valori chiave vengono utilizzati non solo nei sistemi RDBMS, ma anche in altri sistemi di mappatura Key-Value. Immagina se l'ordine dei cookie JSESSION_ID potesse essere predeterminato o indovinato? Tutti con i pollici opponibili ripeteranno le sessioni nelle app Web.

E molti altri che sono sicuro che altri ppl qui verranno fuori.

Seal Team 6 non significa necessariamente che ci sono 6 squadre di tenuta. Mantiene solo il nemico indovinando. E il tempo trascorso a indovinare da un potenziale aggressore è più denaro in tasca in qualsiasi modo lo si affetta.

Answer 2

Come molti problemi relativi alla sicurezza, è una risposta sottile: il kolossus offre una buona panoramica.

Aiuta a capire in che modo un utente malintenzionato potrebbe compromettere la propria API e il numero di violazioni della sicurezza.

La maggior parte delle violazioni della sicurezza sono causate da errori o sviste e gli aggressori cercano quelle. Un utente malintenzionato che sta tentando di compromettere la tua API tenterà innanzitutto di raccogliere informazioni su di esso - poiché si tratta di un'API, presumibilmente si pubblicherà una documentazione dettagliata sull'utilizzo.Un utente malintenzionato utilizzerà questo documento e tenterà in molti modi diversi di rendere il tuo sito in crash (e quindi di esporre più informazioni, se è fortunato), o reagire in modi che non avevi previsto. Devi presumere che l'attaccante abbia un sacco di tempo e scriverà il suo attacco per provare ogni singola strada - come un ladro con un tempo infinito, che gira per casa tua provando ogni porta e finestra, con un grimaldello che impara da ogni tentativo

Quindi, se la tua API espone un metodo come getUserInfo(userid) e userID è un numero intero, l'utente malintenzionato scriverà uno script per iterare da 0 in su per scoprire quanti utenti hai. Proveranno numeri negativi e max(INT) + 1. La tua applicazione potrebbe trapelare informazioni in tutti questi casi e, se lo sviluppatore ha dimenticato di gestire determinati errori, potrebbe esporre più dati di quelli previsti.

Se l'API include la logica per limitare l'accesso a determinati dati, ad es. hai il permesso di eseguire getUserInfo per gli utenti nella tua lista di amici - l'attaccante potrebbe essere fortunato con alcuni numeri a causa di un bug o di una svista, e saprà che le informazioni che sta ottenendo si riferiscono a un utente valido, quindi possono costruire un modello del modo in cui è progettata la tua applicazione. È l'equivalente di un ladro, sapendo che tutte le serrature provengono da un unico produttore, quindi devono solo portare con sé quel grimaldello.

Di per sé, questo può non essere di alcun vantaggio per l'attaccante - ma rende la loro vita un po 'più facile.

Dato lo sforzo di utilizzare UUID o un altro identificatore privo di significato, è probabilmente la pena rendere le cose più difficili per l'aggressore. Ovviamente non è la considerazione più importante - probabilmente non fa le 5 cose che dovresti fare per proteggere la tua API dagli aggressori - ma aiuta.

Answer 3

Grandi risposte, aggiungerò un altro motivo per cui non si desidera esporre l'ID incrementale automatico interno.
Come azienda competitiva, posso facilmente capire quanti nuovi utenti/ordini/ecc si ottengono ogni settimana/giorno/ora. Devo solo creare un utente e/o un ordine e sottrarre il nuovo ID da quello che ho ottenuto l'ultima volta.
Quindi, non solo per motivi di sicurezza, sono anche ragioni di business.