L'esposizione delle chiavi primarie (soprattutto se prevedibili) è una vulnerabilità chiamata Insecure Direct Object Reference.
Avendo un URL (o qualsiasi altro parametro fornito dal client) come questo:
http://www.domain.com/myaccount?userid=12
Dai ai tuoi utenti finali l'opportunità di pasticciare con quelle variabili e passare tutti i dati che vogliono. La contromisura per mitigare questa vulnerabilità consiste invece nel creare riferimenti a oggetti indiretti. Questo può sembrare un grande cambiamento, ma non deve esserlo necessariamente. Non devi andare a reimpostare tutte le tue tabelle o altro, puoi farlo semplicemente essendo intelligente con i tuoi dati attraverso l'uso di una mappa di riferimento indiretta.
Considera questo:hai un utente che sta effettuando un acquisto sul tuo sito. E quando è il momento di pagare, gli viene presentato un elenco a discesa dei loro numeri di carta di credito che hai "in archivio". Se guardi il codice del menu a tendina vedi che i numeri di carta di credito sono associati alle chiavi 8055, 9044 e 10099.
L'utente potrebbe guardare questo e pensare che assomiglino molto alle chiavi primarie a incremento automatico (l'utente probabilmente avrebbe ragione). Quindi inizia a provare altre chiavi per vedere se può pagare con la carta di qualcun altro.
Ora tecnicamente, dovresti avere un codice sul lato server che assicura che la carta selezionata faccia parte dell'account dell'utente e che possa usarla. Questo è un esempio forzato. Per ora assumeremo che non sia così o che questo sia un altro tipo di modulo che forse non ha quel tipo di controllo lato server.
Quindi, come possiamo impedire all'utente finale di scegliere una chiave che non dovrebbe essere a sua disposizione?
Invece di mostrare loro un riferimento diretto al record nel DB, fornisci loro un riferimento indiretto.
Invece di inserire le chiavi DB nel menu a discesa, creeremo un array sul server e lo inseriremo nella sessione dell'utente.
Array cards = new Array(3);
cards[0] = 8055;
cards[1] = 9044;
cards[2] = 10099;
Nel menu a tendina forniamo ora il riferimento all'indice dell'array in cui è memorizzata la scheda. Quindi, invece di vedere le chiavi effettive, l'utente finale vedrà i valori 0, 1 e 2, se visualizza l'origine.
Quando il modulo viene inviato, uno di questi valori verrà trasmesso. Quindi estraiamo l'array dalla sessione dell'utente e utilizziamo l'indice per ottenere il valore. La chiave attuale non ha mai lasciato il server.
E l'utente può passare valori diversi per tutto il giorno se lo desidera, ma non otterrà mai un risultato diverso dalle proprie carte, indipendentemente dal controllo di accesso lato server in atto.
Tieni presente, tuttavia, che quando si utilizza l'indice passato per ottenere il valore, se l'utente lo pasticcia è possibile ottenere alcune eccezioni (ArrayOutOfBounds, InvalidIndex, qualunque cosa). Quindi avvolgi quella roba in un try/catch in modo da poter sopprimere quegli errori e registrare gli errori per cercare tentativi di cracking.
Spero che questo aiuti.
Per saperne di più sui riferimenti diretti agli oggetti non sicuri, consulta la Top 10 di OWASP. È il numero di rischio A4. https://www.owasp.org/index.php/Top_10_2010-A4 -Insecure_Direct_Object_References
