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.
źródło
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
100
i identyfikator użytkownika Bob101
to 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 identyfikatorze3Js9kW3hTs7sa120
ma konto dłuższe niż użytkownik o identyfikatorzeQ8Hs73kks0hEg
.Z linku, do którego odwoływałem się:
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 to9
. 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.źródło
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.
źródło
/account/8hdy39s1lks062dfasd4
nim, a to zamieni się na prawdziwe konto, i tak nie powinien mieć do niego dostępu.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ń.
źródło
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.
źródło
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.
źródło
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.
źródło