Czy zasłanianie / zaciemnianie publicznie dostępnych baz danych jest naprawdę „najlepszą praktyką”?

Słyszałem ludzi, którzy tu i tam wykładają w Internecie, że najlepszą praktyką jest ukrywanie publicznych identyfikatorów baz danych w aplikacjach internetowych. Przypuszczam, że mają one głównie na myśli w formie i adresach URL, ale nigdy nie czytałem na ten temat nic więcej niż kęsa.

EDYCJA : Oczywiście teraz, gdy o to pytam, znajduję pewne zasoby na ten temat:

• /programming/2374538/obscuring-database-ids
• /programming/1895685/should-i-obscure-primary-key-values
• http://joshua.schachter.org/2007/01/autoincrement.html

Te linki zaspokoiły moją ciekawość, ale posty SO nie mają zbyt wielu głosów i niekoniecznie są skoncentrowane wokół tematu w tym kontekście, więc nie jestem pewien, co z tego zrobić, a niektórzy twierdzą, że trzeci link jest fałszywy. Pozostawiam resztę mojego postu nienaruszoną:

Rozumiem różnice między niejasnością a bezpieczeństwem, a także to, jak mogą one ze sobą współpracować, ale nie wyobrażam sobie, dlaczego byłoby to konieczne.

Czy jest w tym jakaś prawda, czy to tylko paranoja, czy też jest to całkowicie nieprawdziwe?

Mogę wymyślić sposoby, aby to zrobić, ale oczywiście dodaje dużo złożoności do kodu aplikacji. W jakich okolicznościach byłoby to przydatne? Jeśli to jest coś, co ludzie często robić, jak jest to zwykle stosowane? Mieszasz identyfikatory? Coś innego? Wygląda na to, że dużo pracy wymaga niewiele większego bezpieczeństwa. Nie szukam prawdziwych rozwiązań, chcę tylko dowiedzieć się, jak / dlaczego ludzie robiliby to w prawdziwym świecie.

Czy to naprawdę uważa się za „najlepszą praktykę”, czy jest to jedynie mikrooptymalizacja o niewielkiej wartości?

UWAGA : Myślę, że kilku ludzi mogło mieć błędny pomysł: nie sugeruję, że trudne do odgadnięcia identyfikatory byłyby jedynym mechanizmem bezpieczeństwa, oczywiście byłyby to zwykłe kontrole dostępu. Załóżmy, że są na miejscu, a sama znajomość identyfikatora lub hashowanego identyfikatora rekordu nie wystarczy, aby udzielić dostępu.

Nie sądzę, żeby to było tak ważne, ale istnieją pewne scenariusze, w których może to mieć znaczenie w zależności od innych podejmowanych decyzji.

Na przykład, jeśli chcesz ujawnić identyfikator zamówienia, który jest generowany sekwencyjnie, i miałeś atak inżynierii społecznej z kimś, kto dzwoni do obsługi klienta i mówi: „hej, właśnie wydałem 2000 $ na nowy komputer, a wy wysłaliście mi zamówienie innego faceta na kabel 15 $, teraz nie mam 2000 $ ”, możesz poświęcić dużo czasu na sprawdzenie problemu, zanim dojdziesz do wniosku, że jest on fałszywy lub wyślesz fałszywemu nowy komputer.

Istnieją podobne, mniej wyrafinowane, ale krępujące wariacje na temat; jeśli złoczyńca poda identyfikator zamówienia e-mailem z linkiem do paragonu i jeśli nie zostaną wykonane żadne dodatkowe weryfikacje w celu zweryfikowania, czy osoba, która kliknęła link, ma prawo wyświetlić identyfikator zamówienia, nagle nieświadomie ujawniasz informacje o prywatnym kliencie niewłaściwej osobie.

W takich przypadkach, jeśli liczby nie są sekwencyjne, ekspozycja jest nieco zmniejszona, ponieważ zgadywanie ma mniejsze szanse na uzyskanie interesujących wyników. Z drugiej strony, teraz potrzebujesz wygodnego sposobu odwoływania się do identyfikatora zamówienia w kontaktach z obsługą klienta, które nie będą skutkować długimi rozmowami z klientem przy telefonicznych interakcjach z klientem, podczas gdy twój przedstawiciel próbuje rozróżnić B, PD i T w numerze zamówienia BPT2015D.

Powiedziałbym, że trudno jest nazwać to zaciemnianie „najlepszą praktyką”, ale w niektórych scenariuszach może to zmniejszyć łatwość wykorzystania kolejnej słabości kodu weryfikacyjnego lub autoryzacyjnego. Z drugiej strony tak naprawdę nie ma znaczenia, czy ktoś wie, że napisałeś post na blogu nr 1 czy 2559. Jeśli identyfikator nie jest cenną informacją, nawet przy dodatkowej wiedzy, argument, że zaciemnianie go jest najlepszą praktyką, ma mniejsze znaczenie.

Istnieje drugi potencjalny argument, że identyfikator bazy danych może poślubić cię do konkretnej implementacji bazy danych (lub instancji), a kiedy twoja firma zostanie wykupiona lub przejmie konkurenta, a teraz musisz połączyć dwa starsze systemy lub CEO wychodzi do picia z przedstawicielem DynoCoreBase i postanawiają, że teraz przeniesiesz wszystkie swoje dane do DynoCoreBase w wersji 13h i chce, aby wszystkie klucze podstawowe były przewodnikami, i musisz stworzyć jakąś warstwę mapowania, aby przetłumaczyć stare identyfikatory na nowe Identyfikatory, aby stare adresy URL nie ulegały zepsuciu, ale to, czy te scenariusze są dla Ciebie ważne, zależy bardziej o charakterze Twojej firmy (i zaangażowaniu klientów w te identyfikatory) niż od wszelkich ogólnych dobrych praktyk.

Oto moje zdanie na ten temat:

Chociaż „bezpieczeństwo przez zaciemnienie” oczywiście nie wystarcza, zaciemnienie może pomóc w bezpieczeństwie, nawet jeśli tylko trochę. Musisz zdecydować, czy ta odrobina bezpieczeństwa psuedo jest warta dodatkowego wysiłku, jaki zajmuje wdrożenie tego typu aplikacji.

Istnieje inny powód poza bezpieczeństwem, który mogę wymyślić, aby to zaimplementować:

Prywatność

Załóżmy, że mamy do czynienia z identyfikatorami użytkowników w adresie URL. Jeśli identyfikator użytkownika Joe to 100i identyfikator użytkownika Bob 101to prawdopodobnie jest oczywiste, że konto Joe zostało utworzone jako pierwsze. Chociaż może to nie mieć znaczenia w większości aplikacji, może mieć znaczenie dla niektórych. Jest to przykład prywatności ściśle ze względu na niejasność, więc jeśli nie masz bardzo zaawansowanego systemu zaciemniania identyfikatorów użytkowników, może być łatwo rozwiązać i dowiedzieć się, czy użytkownik o identyfikatorze 3Js9kW3hTs7sa120ma konto dłuższe niż użytkownik o identyfikatorze Q8Hs73kks0hEg.

Z linku, do którego odwoływałem się:

Po pierwsze, biorąc pod uwagę adres URL dla jakiegoś obiektu, możesz dowiedzieć się, jakie są adresy URL obiektów, które zostały wokół niego utworzone. To ujawnia liczbę obiektów w bazie danych potencjalnym konkurentom lub innym osobom, które mogą nie chcieć mieć tych informacji (jak to dobrze pokazali alianci zgadując poziomy produkcji niemieckich czołgów, patrząc na numery seryjne).

Użycie identyfikatora automatycznego przyrostu publicznie ujawnia liczbę obiektów w bazie danych i może ujawnić, które zostały utworzone jako pierwsze, a które są nowsze. Informacje te mogą ujawnić fakt, że firma jest nowa lub nawet nie radzi sobie dobrze. Na przykład: załóżmy, że zamawiasz książkę, a Twój identyfikator zamówienia to 1. Może się wydawać, że twoje zamówienie było pierwsze w systemie, co może być niepokojące. Powiedzmy, że wracasz i zamawiasz inny, a Twój identyfikator zamówienia to 9. Daje to informację, że tylko 7 zamówień zostało złożonych w ramach czasowych między dwoma zamówieniami. Może to być cenna informacja dla konkurentów. W takim przypadku numeryczny identyfikator automatycznego przyrostu jest prawdopodobnie lepiej zaciemniony.

Słowo „Niewyraźny” jest tutaj prawdopodobnie nieco mylące i może prowadzić do myślenia o „zaciemnieniu” lub „częściowym ukryciu”.

Zaleca się, aby nigdy nie włączać żadnych generowanych wewnętrznie kluczy bazy danych jako części publicznego adresu URL, jeśli te rekordy bazy danych zawierają jakiekolwiek poufne dane.

Po prostu zbyt łatwo grać liczbami w adresie URL i uzyskiwać dostęp do innych rekordów.

Przejdę do głównego nurtu i powiem wam, że używanie losowego, długiego identyfikatora jest moim zdaniem całkiem przyzwoitą formą bezpieczeństwa.

Każdemu, kto ma dostęp do tych danych, należy wyjaśnić, że są one tak samo wrażliwe jak hasło. I oczywiście ma tę wadę, że jeśli pójdzie w dzicz, zmiana może być trudniejsza.

Ma jednak kilka zalet w stosunku do zwykłej pary nazwy użytkownika i hasła. Po pierwsze, użytkownik nie ma wyboru, więc możesz być pewien, że zgadnięcie jest w zasadzie niemożliwe. Nie ma sensu projektować całkowicie bezpiecznej witryny, gdy administrator wybiera swoje imię jako hasło. Po drugie, każdy element ma inny identyfikator, więc jeśli jeden uzyska dostęp do jednego elementu, nie pomoże to w drugim.

Oczywiście im więcej warstw bezpieczeństwa, tym lepiej. Ale sama metoda może być bezpieczniejsza niż kilka poświadczeń.

Są dwa aspekty: użyteczność i bezpieczeństwo.

Pod względem bezpieczeństwa, zaciemniające identyfikatory są raczej bezcelowe; ważne jest to, że identyfikator nigdy nie może być jedynym „kluczem” do jakiegokolwiek niepublicznego zasobu. Oznacza to, że jeśli chcesz dać wybranym użytkownikom dostęp do określonej strony, samo podanie identyfikatora strony w adresie URL nie wystarczy, musisz wdrożyć rzeczywisty mechanizm bezpieczeństwa, taki jak nazwa użytkownika / hasło lub uwierzytelnienie klucza publicznego / prywatnego, a także odpowiednią autoryzację (to znaczy, system musi być w stanie ocenić na podstawie poszczególnych przypadków, czy użytkownik X może uzyskać dostęp do zasobu Y i podjąć odpowiednie działania).

Jeśli chodzi o użyteczność, ogólną radą jest ukrywanie sztucznych kluczy: nie mają one żadnego znaczenia dla użytkownika, a ujawniając je w oczywisty sposób, wprowadzasz dodatkową zależność, szczególnie trudną do opanowania, ponieważ żyje na zewnątrz królestwo oprogramowania - ludzie będą zapisywać, e-mailem, faksem, drukować, zakładki itp., te identyfikatory, a jeśli kiedykolwiek je zmienisz, czeka cię irytujące zgłoszenie do pomocy technicznej.

Nie , absolutnie, pozytywnie nie chcesz zezwalać na dostęp do dowolnych zasobów tylko poprzez znajomość ich wewnętrznego identyfikatora. To jest Internet, każda złośliwa, przestępcza lub zwykła dziecinna obecność, którą możesz sobie wyobrazić, faktycznie istnieje , a wcześniej czy później pojawią się na Twojej stronie. O ile wszystko, co kiedykolwiek mógłbyś służyć, nie jest całkowicie jawne dla wszystkich (a jeśli masz choć jednego klienta, to z pewnością tak nie jest), musisz ograniczyć dostęp do tych osób, które są do tego upoważnione.

Zwykłym rozwiązaniem jest użycie pewnego rodzaju tokenów autoryzacyjnych przechowywanych w zaszyfrowanej sesji i sprawdzenie, czy coś ma być widoczne dla uwierzytelnionego użytkownika przed jego wysłaniem. Może to być rzeczywisty menedżer bezpieczeństwa, taki jak ten, który jest dostarczany z JDK, lub dowolnym innym komponentem, który spełnia tę samą rolę, o ile konsekwentnie to robi. (Czy ujawnienie wewnętrznych identyfikatorów komuś, kto jest już uwierzytelniony, czy nie, jest również interesującym pytaniem z różnymi zaletami i wadami, ale jest mniej istotne z punktu widzenia bezpieczeństwa).

Wartość tego jest trudna do obliczenia, dopóki nie zostaniesz zaatakowany przez kogoś, kto chce robić interesy. Wtedy zwykle jest to różnica między wyjściem z biznesu a po prostu zlekceważeniem kolejnego udaremnionego dzieciaka ze scenariusza.

Oczywiście zależy to od tego, jak wrażliwe są dane, ale dla średniego bezpieczeństwa, minimum, jakie bym zrobił, to podać identyfikator i wartość sumy kontrolnej.

Wygeneruj sumę kontrolną, dodając sól (tj. Zbiór losowych znaków) przed i po identyfikatorze i wykonując MD5 na wartości.

Na każdej stronie, która odczytuje wartość identyfikatora, powinna wygenerować wartość sumy kontrolnej i porównać ją z przekazaną, odrzucić żądanie, jeśli się nie zgadza.

Jeśli potencjalny haker jest w stanie uzyskać wystarczającą liczbę prawidłowych kombinacji, może być w stanie wypracować wartość Soli za pomocą brutalnej siły, więc jeśli możesz dodać kolejną warstwę bezpieczeństwa, na przykład sprawdzanie ID użytkownika, który również pomoże.