Ujawnianie identyfikatorów baz danych - zagrożenie bezpieczeństwa?

Słyszałem, że ujawnianie identyfikatorów baz danych (na przykład w adresach URL) jest zagrożeniem dla bezpieczeństwa, ale nie rozumiem, dlaczego.

Jakieś opinie lub linki na temat tego, dlaczego jest to ryzyko lub dlaczego tak nie jest?

EDYCJA: oczywiście dostęp jest ograniczony, np. Jeśli nie widzisz zasobu foo?id=123, pojawi się strona błędu. W przeciwnym razie sam adres URL powinien być tajny.

EDYTUJ: jeśli adres URL jest tajny, prawdopodobnie będzie zawierał wygenerowany token, który ma ograniczony czas życia, np. Ważny przez 1 godzinę i może być użyty tylko raz.

EDYTUJ (miesiące później): moją obecną preferowaną praktyką jest używanie UUIDS do identyfikatorów i ujawnianie ich. Jeśli używam numerów sekwencyjnych (zwykle dla wydajności na niektórych bazach danych) jako identyfikatorów, lubię generować token UUID dla każdego wpisu jako klucz alternatywny i ujawniać to.

Istnieje ryzyko związane z ujawnianiem identyfikatorów baz danych. Z drugiej strony projektowanie aplikacji internetowych bez ich ujawniania byłoby niezwykle uciążliwe. Dlatego ważne jest, aby rozumieć ryzyko i uważać, aby im zaradzić.

Pierwszym zagrożeniem jest to, co OWASP nazwał „niezabezpieczonymi bezpośrednimi odniesieniami do obiektów”. Jeśli ktoś odkryje identyfikator jednostki, a Twoja aplikacja nie ma wystarczających mechanizmów kontroli autoryzacji, aby temu zapobiec, może zrobić rzeczy, których nie zamierzałeś.

Oto kilka dobrych zasad, których należy przestrzegać:

1. Użyj zabezpieczeń opartych na rolach, aby kontrolować dostęp do operacji. Sposób, w jaki to się robi, zależy od wybranej platformy i struktury, ale wiele z nich obsługuje deklaratywny model zabezpieczeń, który automatycznie przekierowuje przeglądarki do etapu uwierzytelniania, gdy działanie wymaga pewnych uprawnień.
2. Użyj zabezpieczeń programistycznych, aby kontrolować dostęp do obiektu. Jest to trudniejsze do zrobienia na poziomie struktury. Częściej jest to coś, co musisz wpisać do swojego kodu i dlatego jest bardziej podatne na błędy. To sprawdzenie wykracza poza sprawdzanie oparte na rolach, zapewniając nie tylko, że użytkownik ma uprawnienia do operacji, ale także ma niezbędne uprawnienia do konkretnego modyfikowanego obiektu. W systemie opartym na rolach łatwo jest sprawdzić, czy tylko menedżerowie mogą dawać podwyżki, ale poza tym należy upewnić się, że pracownik należy do działu konkretnego menedżera.

Istnieją schematy ukrywania prawdziwego identyfikatora przed użytkownikiem końcowym (np. Mapowanie między rzeczywistym identyfikatorem a tymczasowym, specyficznym dla użytkownika identyfikatorem na serwerze), ale argumentowałbym, że jest to forma zabezpieczenia przez zaciemnienie. Chcę skupić się na zachowaniu prawdziwych tajemnic kryptograficznych, a nie na próbach ukrycia danych aplikacji. W kontekście sieciowym jest to również sprzeczne z szeroko stosowanym projektem REST, w którym identyfikatory często pojawiają się w adresach URL w celu adresowania zasobu, który podlega kontroli dostępu.

Kolejnym wyzwaniem jest przewidywanie lub odkrycie identyfikatorów. Najłatwiejszym sposobem dla atakującego na wykrycie nieautoryzowanego obiektu jest odgadnięcie go na podstawie sekwencji numeracji. Poniższe wskazówki mogą pomóc złagodzić ten problem:

3. Ujawnij tylko nieprzewidywalne identyfikatory. Ze względu na wydajność możesz użyć numerów sekwencyjnych w relacjach klucza obcego w bazie danych, ale każda jednostka, do której chcesz się odwoływać z aplikacji internetowej, powinna również mieć nieprzewidywalny identyfikator zastępczy. To jedyne, które powinno być kiedykolwiek ujawnione klientowi. Używanie do tego losowych identyfikatorów UUID jest praktycznym rozwiązaniem do przypisywania tych kluczy zastępczych, nawet jeśli nie są one bezpieczne kryptograficznie.

4. Jednak jednym z miejsc, w których kryptograficznie nieprzewidywalne identyfikatory są konieczne, są identyfikatory sesji lub inne tokeny uwierzytelniające, w których sam identyfikator uwierzytelnia żądanie. Powinny one zostać wygenerowane przez kryptograficzną RNG.

Chociaż nie jest to zagrożenie dla bezpieczeństwa danych, jest to absolutnie zagrożenie bezpieczeństwa analityki biznesowej, ponieważ ujawnia zarówno rozmiar danych, jak i prędkość. Widziałem, jak szkodzi to firmom i szczegółowo opisałem ten anty-wzorzec. Chyba że budujesz eksperyment, a nie biznes, zdecydowanie sugeruję, aby Twoje prywatne identyfikatory nie były widoczne dla opinii publicznej. https://medium.com/lightrail/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e

To zależy od tego, co oznaczają identyfikatory.

Rozważ witrynę, która ze względu na konkurencję nie chce ujawniać liczby członków, których ma, ale używając identyfikatorów sekwencyjnych i tak ujawnia to w adresie URL: http://some.domain.name/user?id=3933

Z drugiej strony, jeśli zamiast tego użyli nazwy logowania użytkownika: http://some.domain.name/user?id=some , nie ujawnili niczego, czego użytkownik jeszcze nie znał.

Ogólna myśl jest następująca: „Ujawniaj każdemu jak najmniej informacji o wewnętrznym działaniu aplikacji”.

Ujawnienie identyfikatora bazy danych liczy się jako ujawnienie niektórych informacji.

Powodem tego jest to, że hakerzy mogą wykorzystać dowolne informacje o wewnętrznych działaniach aplikacji, aby Cię zaatakować, lub użytkownik może zmienić adres URL, aby dostać się do bazy danych, której nie powinien widzieć?

Używamy identyfikatorów GUID do identyfikatorów baz danych. Wyciekanie ich jest o wiele mniej niebezpieczne.

Jeśli używasz identyfikatorów całkowitych w swojej bazie danych, możesz ułatwić użytkownikom zobaczenie danych, których nie powinni, zmieniając zmienne qs.

Np. Użytkownik może łatwo zmienić parametr id w tych pytaniach i zobaczyć / zmodyfikować dane, których nie powinien http: // someurl? Id = 1

Kiedy wysyłasz identyfikatory bazy danych do swojego klienta, jesteś zmuszony sprawdzić bezpieczeństwo w obu przypadkach. Jeśli zachowasz identyfikator w swojej sesji internetowej, możesz wybrać, czy chcesz / musisz to zrobić, co oznacza potencjalnie mniejsze przetwarzanie.

Ciągle próbujesz delegować pewne rzeczy do swojej kontroli dostępu;) To może być w Twojej aplikacji, ale nigdy w całej mojej karierze nie widziałem tak spójnego systemu zaplecza. Większość z nich ma modele bezpieczeństwa, które zostały zaprojektowane do użytku poza siecią, a do niektórych dodano pośmiertnie dodatkowe role, a niektóre z nich zostały przykręcone poza podstawowym modelem zabezpieczeń (ponieważ rola została dodana w innym kontekście operacyjnym, powiedzmy przed siecią).

Używamy więc syntetycznych identyfikatorów lokalnych sesji, ponieważ ukrywają one tyle, ile tylko możemy.

Istnieje również kwestia pól kluczy innych niż całkowite, co może mieć miejsce w przypadku wartości wyliczanych i podobnych. Możesz spróbować oczyścić te dane, ale jest szansa, że ​​skończysz jak małe stoły upuszczające bobby .