Unikaj narażania kluczy głównych w źródle aplikacji internetowej?

Question

Często napotykam aplikacje internetowe, które ujawniają klucze podstawowe bazy danych za pośrednictwem formularzy, takich jak pola wyboru. Czasami widzę dopasowanie javascript przeciwko int lub guid magicznej wartości, która przełącza logikę.

Jest to najlepsza praktyka, aby uniknąć przeciekania wszystkich wewnętrznych identyfikatorów wierszy w aplikacji internetowej, aby uniemożliwić osobom postronnym zrozumienie zbyt dużej części systemu i ewentualnie użycie go w celu wykorzystania systemu. Jeśli tak, jaki jest najlepszy sposób rozwiązania tego problemu?

Czy należy ujawnić inną wartość aplikacji internetowej, którą można przetłumaczyć z powrotem na klucz podstawowy?

Dzięki

Edytuj

w idealnym świecie aplikacja będzie w 100% bezpieczne, więc nie ma znaczenia, jeśli zasłonięty rzeczy. Oczywiście tak nie jest, więc czy powinniśmy zachować ostrożność i nie ujawniać tych informacji?

Niektórzy zwracają uwagę, że Stackoverflow prawdopodobnie ujawnia klucz w Url, który prawdopodobnie jest w porządku. Czy jednak są inne względy dotyczące aplikacji dla przedsiębiorstw?

Answer 1

Nie zgadzam się ze stanowiskiem, że wystawiając kluczy podstawowych jest problem. Może to stanowić problem, jeśli sprawisz, że będą one widoczne dla użytkowników, ponieważ mają nadane znaczenie poza systemem, czego zazwyczaj próbujesz uniknąć.

Jednak aby używać identyfikatorów jako wartości elementów listy kombi? Idź po to, mówię. Po co przekładać tłumaczenie na jakąś pośrednią wartość? Możesz nie mieć unikalnego klucza do użycia. Takie tłumaczenie wprowadza większy potencjał błędów.

Tylko nie zaniedbuj zabezpieczeń.

Jeśli mówisz, że przedstawiasz użytkownikowi 6 elementów (ID od 1 do 6), nigdy nie zakładaj, że odzyskasz tylko te wartości od użytkownika. Ktoś może spróbować złamać zabezpieczenia, wysyłając ponownie ID 7, więc nadal musisz sprawdzić, czy to, co otrzymasz, jest dozwolone.

Ale unikając tego w całości? Nie ma mowy. Nie ma potrzeby.

Jako komentarz do innej odpowiedzi powiedz, spójrz na adres URL tutaj. Obejmuje to bez wątpienia klucz podstawowy do pytania w bazie danych SO. Wystawianie kluczy do zastosowań technicznych jest całkowicie w porządku.

Ponadto, jeśli zamiast tego używasz wartości zastępczej, niekoniecznie jest to bardziej bezpieczne.

Answer 2

Tak na wszystkie Twoje pytania. Zgadzam się z Twoimi twierdzeniami, że powinieneś "ujawnić inną wartość aplikacji internetowej, którą można przetłumaczyć z powrotem na klucz podstawowy"

Możesz otworzyć się na potencjalne problemy inaczej.

Edit

odniesieniu do komentarza, że ​​„nie ma powodu, aby przyjąć karę za trafienie klawiszy trywialne. Spójrz na adres URL przeglądarki teraz, założę widać klucza!”.

Rozumiem, co mówisz i, tak, widzę klucz w adresie URL i zgadzam się, że prawdopodobnie odnosi się do bazy danych PK. W takich wypadkach przyznaję, że prawdopodobnie jest OK, jeśli nie ma lepszej alternatywy.

Wciąż wolałbym ujawnić coś innego niż PK - coś o wartości semantycznej. Tytuł pytania znajduje się również w adresie URL, ale ponieważ trudno byłoby to zweryfikować jako unikalny (lub przekazać między użytkownikami werbalnie), nie można go używać niezawodnie na własną rękę.

Jednak patrząc na adresy URL "tagów" (tj. https://stackoverflow.com/questions/tagged/java+j2ee), PK nie są odsłonięte, a zamiast nich używane są nazwy znaczników. Osobiście wolę takie podejście i dążyłbym do tego.

Chciałem również dodać, że dane, na które wskazuje PK, mogą czasem zmieniać się z czasem. Pracowałem nad systemem, w którym tabela została wypełniona informacjami z procesu offline - tj. Statystyki miesięczne, w których zawartość tabeli bazy danych spadła pod koniec miesiąca i została ponownie wypełniona nowymi danymi.

Jeśli dane zostaną dodane do bazy danych w innej kolejności, wartości PK dla określonych punktów danych zmienią się, a wszystkie zapisane zakładki z poprzedniego miesiąca na te dane będą teraz wskazywały inny zestaw danych.

Jest to jedna z sytuacji, w której wystawienie PK spowodowałoby "przerwę" aplikacji niezwiązanej z bezpieczeństwem aplikacji. Nie tak z wygenerowanym kluczem.

Answer 3

Tak, ujawnienie kluczy jest informacją, która może zostać wykorzystana jako atak. Zwłaszcza jeśli są przewidywalne.

Użyj innego klucza/kolumny, jeśli uważasz, że informacje są poufne.

Na przykład, aby uniknąć pokazując jak może użytkownicy trzeba rozważyć:

site.com/user/123 vs site.com/user/username

Answer 4

Jak zwykle "to zależy". Jeśli ktoś może zyskać na wartości (powiedzmy), wiedząc, ile transakcji wykonujesz według (godziny/dnia/miesiąca), i ujawniasz identyfikator transakcji jako monotonnie rosnącą liczbę, to jest to ryzyko.

Jak powiedzieli inni, z rozwijanej listy wartości zwykle nie ma problemu.

Answer 5

Ujawnienie innych wartości niż klucz podstawowy nie pozwoli uniknąć obciążenia związanego z kontrolą bezpieczeństwa. Rzeczywiście, jeśli twoje bezpieczeństwo ma dziury, "źli" użytkownicy mogą nadal uzyskiwać dostęp do obiektów, do których nie są przeznaczone, zmieniając wartość w adresie URL. Mogą mieć mniej wskazówek, z których warto korzystać, ale losowo wybierają wartości, mogą mieć szczęście.

Jeśli chcesz poprawić bezpieczeństwo w ten sposób, będziesz musiał użyć dużych losowych ciągów znaków (aby utrudnić zgadywanie) w adresie URL, zamiast identyfikatora i użyć tabeli pośredniej dopasowującej losową wartość z dobrym identyfikatorem w tło.

Myślę, że nie jest to warte kłopotów przez większość czasu.

Powiedziawszy to, przydaje się w przypadkach, w których chcesz "zabezpieczyć się przez zaciemnienie", na przykład gdy ujawniasz strony w celu zmiany haseł użytkowników, nie wymagając logowania (dla użytkowników, którzy utracili swoje hasło). W takim przypadku powinieneś również powiązać datę ważności limitu z kluczem.

Answer 6

Klucz podstawowy to nie to samo, co klucz zastępczy lub klucz wewnętrzny, chociaż niektóre nakładają się. Przeciwieństwem klucza wewnętrznego jest klucz naturalny. Istnieje wiele razy, kiedy kluczem naturalnym jest klucz podstawowy.Zasadniczo nie ma powodu, aby ukrywać klucz natury, chyba że mamy do czynienia z kwestiami prywatności.

Twoje prawdziwe pytanie brzmi, myślę, o tym, czy klucze wewnętrzne powinny być wystawione na działanie użytkowników. Odpowiedź brzmi: "to zależy". W przypadku większości społeczności użytkowników ujawnienie klucza wewnętrznego spowoduje, że klucz zostanie użyty jako klucz naturalny. Może to i zwykle powoduje pewne zamieszanie, gdy rozkładanie jeden do jednego między kluczem wewnętrznym a obiektem wiersza tabeli ulega przerwaniu.

Ten podział może wystąpić tylko w wyniku niewłaściwego zarządzania danymi. W większości przypadków trzeba jednak planować pewne przypadki niewłaściwego przetwarzania danych w świecie rzeczywistym. Nie planowałbyś systemu zaopatrzenia w wodę, który zepsuje się, gdy wystąpi niedobór wody. Nie planujesz systemu informacyjnego, który rozkłada się za każdym razem, gdy dochodzi do niezgodności danych.

Po tym wszystkim większość projektantów baz danych pracuje obecnie dla dostawców oprogramowania i nie widzi problemów powodowanych przez niewłaściwe zarządzanie danymi przez użytkowników ich produktów.