Quanto sono pericolosi i riferimenti diretti alle chiavi del database?

Question

Quanto sono pericolosi i riferimenti diretti alle chiavi del database?

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

8

Un nota OWASP suggerisce che i riferimenti diretti agli oggetti sono considerati insicuri in alcuni contesti. Hanno definito "riferimento diretto all'oggetto" come segue:

“A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter.”

Qualcuno suggerisce una soluzione a questo problema:

An object reference map is first populated with a list of authorized values which are temporarily stored in the session. When the user requests a field (ex: color=654321), the application does a lookup in this map from the session to determine the appropriate column name. If the value does not exist in this limited map, the user is not authorized. Reference maps should not be global (i.e. include every possible value), they are temporary maps/dictionaries that are only ever populated with authorized values.

Tuttavia, qualcun altro sostiene sul Wiki che i DOR sono davvero insicuri solo per i file, le directory. Quella persona aggiunge:

There is no way to practically DOR all database primary keys in a real enterprise or post-enterprise system.

La mia domanda è: quanto sono insicuri i riferimenti diretti agli oggetti alle chiavi primarie del database? Potete fornire esempi concreti di vulnerabilità? Con quale frequenza le persone vanno a lunghezze straordinarie (come suggerito dalla prima persona) per mascherare TUTTE le chiavi del database?

databases owasp

posta user2398029 31.03.2013 - 23:06

fonte

2 risposte

3

Ci sono molti fattori di cui preoccuparsi quando esponi gli ID al pubblico. Credo che la cosa più importante sia evitare i crawler. Se so che /page.php?id=1 visualizzerà le informazioni relative a un record nel database, quindi /page.php?id=2 deve visualizzare le informazioni del prossimo record in ordine, e /page.php?id=3 è il successivo e così via, quindi posso leggere tutte le informazioni sul tavolo, potenzialmente ottenendo l'accesso a cose che non dovevo, ad esempio, per i messaggi sotto una sezione protetta da password su un forum.

Ma se l'ID è effettivamente crittografato usando una cifratura sconosciuta per me, non posso più navigare tra i record del database così facilmente, dovrò ottenere gli ID dalle pagine a cui ho accesso e come risultato avrò accesso solo alle informazioni che dovrei.

Ho un caso in cui dovresti essere in grado di vedere il profilo di un personaggio del gioco, ma non devi raggiungere questa pagina da solo. Devi solo vederlo se il proprietario del personaggio ti fornisce l'URL. Questo URL contiene una frase crittografata, contenente l'ID crittografato, i controlli CRC per evitare bruteforce e persino una data di scadenza per se stessa.

risposta data 01.04.2013 - 09:00

fonte

Leggi altre domande sui tag databases owasp

È questo il modo di implementare il CTR attorno a un sistema che implementa solo CBC, CFB, CTS, ECB e OFB? Esiste la ripetizione nella routine di hash di Solaris 11? Posso aggiungerne un po '?

score 10 · Accepted Answer

Il problema non riguarda tanto i riferimenti diretti agli oggetti quanto i insicuri riferimenti agli oggetti diretti. Ad esempio, supponiamo di avere uno script che visualizza un messaggio privato e che lo script accetta un ID come parametro. Se visualizzi l'elenco per il tuo utente, vedrai i link ai messaggi a cui hai accesso. Ma se puoi modificare quell'ID nel parametro e usarlo per visualizzare altri messaggi arbitrari, allora questo costituisce un riferimento ad oggetti diretti non sicuri.

Alcuni ritengono che la creazione di un meccanismo che associ gli ID specifici degli utenti agli oggetti sia più sicuro, poiché richiede in modo intrinseco di considerare il controllo degli accessi.

Nascondere le chiavi del database non è esattamente richiesto , ma rende la vita più difficile se un utente malintenzionato tenta di fare riferimento a ID interni in un attacco. Riferimenti diretti a nomi di file e altri identificativi interni di questo tipo possono consentire agli aggressori di mappare la struttura interna del server, che potrebbe essere utile in altri attacchi. Invita anche i problemi di path injection e directory traversal.