At afsløre dine primære nøgler (især hvis de er forudsigelige) er en sårbarhed kaldet Insecure Direct Object Reference.
Ved at have en URL (eller en anden klient leveret param) som denne:
http://www.domain.com/myaccount?userid=12
Du giver dine slutbrugere mulighed for at rode med disse variabler og videregive alle data, som de kan lide. Modforanstaltningen til at afbøde denne sårbarhed er at oprette indirekte objektreferencer i stedet for. Det lyder måske som en stor ændring, men det behøver det ikke nødvendigvis at være. Du behøver ikke gå og genindtaste alle dine tabeller eller noget, du kan gøre det bare ved at være smart med dine data ved at bruge et indirekte referencekort.
Overvej dette:Du har en bruger, der foretager et køb på dit websted. Og når det er tid til at betale, bliver de præsenteret for en drop-down af deres kreditkortnumre, som du har "registreret". Hvis du ser på koden til rullemenuen, ser du, at kreditkortnumrene er knyttet til tasterne 8055, 9044 og 10099.
Brugeren ser måske på dette og tror, at de ligner meget auto-inkrementering primære nøgler (brugeren ville sandsynligvis have ret). Så han begynder at prøve andre nøgler for at se, om han kan betale med en andens kort.
Nu teknisk set skulle du have kode på serversiden, der sikrer, at det valgte kort er en del af brugerens konto, og at de kan bruge det. Dette er et konstrueret eksempel. For nu vil vi antage, at dette ikke er tilfældet, eller at dette er en anden form for form, der måske ikke har den slags serversidekontrol.
Så hvordan forhindrer vi slutbrugeren i at vælge en nøgle, der ikke burde være tilgængelig for dem?
I stedet for at vise dem en direkte reference til posten i DB, så giv dem en indirekte reference.
I stedet for at lægge DB-nøglerne ind i rullemenuen, vil vi oprette et array på serveren og fylde det i brugerens session.
Array cards = new Array(3);
cards[0] = 8055;
cards[1] = 9044;
cards[2] = 10099;
I rullemenuen giver vi nu referencen til indekset for det array, hvor kortet er gemt. Så i stedet for at se de faktiske nøgler, vil slutbrugeren se værdierne 0, 1 og 2, hvis de ser kilden.
Når formularen indsendes, vil en af disse værdier blive videregivet. Så får vi arrayet ud af brugerens session og bruger indekset til at få værdien. Den faktiske nøgle har aldrig forladt serveren.
Og brugeren kan indtaste forskellige værdier hele dagen lang, hvis han vil, men han vil aldrig nogensinde få et andet resultat end sine egne kort, uanset den server-side adgangskontrol, der er på plads.
Husk dog, at når du bruger det indsendte indeks for at få værdien ud, at hvis brugeren roder med det, kan du få nogle undtagelser (ArrayOutOfBounds, InvalidIndex, uanset hvad). Så pak de ting ind i en try/catch, så du kan undertrykke disse fejl og logge fejlene for at lede efter cracking-forsøg.
Håber dette hjælper.
For at læse mere om Insecure Direct Object References, tjek OWASP Top 10. Det er risikonummer A4. https://www.owasp.org/index.php/Top_10_2010-A4 -Insecure_Direct_Object_References