Ujawnianie kluczy podstawowych (zwłaszcza jeśli są przewidywalne) to luka o nazwie Insecure Direct Object Reference.
Mając adres URL (lub dowolny inny parametr dostarczony przez klienta) w taki sposób:
http://www.domain.com/myaccount?userid=12
Dajesz swoim użytkownikom końcowym możliwość manipulowania tymi zmiennymi i przekazywania dowolnych danych, które im się podobają. Środkiem zaradczym w celu złagodzenia tej luki jest utworzenie w zamian pośrednich odwołań do obiektów. Może to brzmieć jak duża zmiana, ale niekoniecznie musi tak być. Nie musisz przepisywać wszystkich swoich tabel ani nic, możesz to zrobić po prostu sprytnie posługując się danymi za pomocą pośredniej mapy odniesienia.
Rozważ to:masz użytkownika, który dokonuje zakupu w Twojej witrynie. A kiedy nadejdzie czas, aby zapłacić, zostaną im przedstawione listy z numerami ich kart kredytowych, które masz „w aktach”. Jeśli spojrzysz na kod listy rozwijanej, zobaczysz, że numery kart kredytowych są powiązane z kluczami 8055, 9044 i 10099.
Użytkownik może spojrzeć na to i pomyśleć, że przypominają one klucze podstawowe z automatycznym przyrostem (prawdopodobnie użytkownik miałby rację). Zaczyna więc próbować innych kluczy, aby sprawdzić, czy może zapłacić cudzą kartą.
Teraz technicznie powinieneś mieć kod po stronie serwera, który zapewnia, że wybrana karta jest częścią konta użytkownika i że może z niej korzystać. To jest wymyślony przykład. Na razie założymy, że tak nie jest lub że jest to inny rodzaj formularza, który być może nie ma tego rodzaju kontroli po stronie serwera.
Jak więc uniemożliwić użytkownikowi końcowemu wybranie klucza, który nie powinien być dla niego dostępny?
Zamiast pokazywać im bezpośrednie odniesienie do rekordu w DB, daj im pośrednie odniesienie.
Zamiast umieszczać klucze DB w menu rozwijanym, utworzymy tablicę na serwerze i umieścimy ją w sesji użytkownika.
Array cards = new Array(3);
cards[0] = 8055;
cards[1] = 9044;
cards[2] = 10099;
Na liście rozwijanej podajemy teraz odniesienie do indeksu tablicy, w której przechowywana jest karta. Więc zamiast widzieć rzeczywiste klucze, użytkownik końcowy zobaczy wartości 0, 1 i 2, jeśli zobaczy źródło.
Po przesłaniu formularza jedna z tych wartości zostanie przekazana. Następnie pobieramy tablicę z sesji użytkownika i używamy indeksu, aby uzyskać wartość. Rzeczywisty klucz nigdy nie opuścił serwera.
A użytkownik może przekazywać różne wartości przez cały dzień, jeśli chce, ale nigdy, przenigdy, nie uzyska wyniku innego niż jego własne karty, niezależnie od zastosowanej kontroli dostępu po stronie serwera.
Pamiętaj jednak, że podczas korzystania z przekazanego indeksu w celu uzyskania wartości, jeśli użytkownik zrobi z nim bałagan, możesz uzyskać pewne wyjątki (ArrayOutOfBounds, InvalidIndex, cokolwiek). Więc zapakuj te rzeczy w try/catch, abyś mógł pominąć te błędy i rejestrować awarie w poszukiwaniu prób złamania.
Mam nadzieję, że to pomoże.
Aby dowiedzieć się więcej o Insecure Direct Object References, zajrzyj do OWASP Top 10. To ryzyko o numerze A4. https://www.owasp.org/index.php/Top_10_2010-A4 -Insecure_Direct_Object_References
