@powaznyczlowiek: na świat może nie, ale wewnątrz panelu administracyjnego chciałem działać po ID ogólnie dostępne mają byc tylko slugi. To zła praktyka?
@xLibero: to nie ma nic wspólnego z wrażliwością danych tylko bezpieczeństwem, poza tym wpis jest o dobrych praktykach więc chyba należy rozpocząć od wyeliminowania tych ewidentnie złych
@powaznyczlowiek: powiedz mi jak bezpieczeństwo tutaj zwiększysz? Jak robisz jakiś update na zasobie to magicznie bez id tego zasobu działasz? ( ͡°͜ʖ͡°)
@xLibero: lol xD nie wiem czy zwiększę bezpieczeństwo bo nie wiem jak wygląda system OPa - czy stosuje jakieś rolę, autentykacje, czy idki są sekwencyjne czy to uuid/guid, czy API idzie w świat (bo to że to dla panelu administracyjnego, nic nie znaczy). No ogółem widzę takie coś to zwracam uwagę bo skoro gość się przejmuje tym jak ma id wsadzone w URL to chyba tym bardziej powinien na takie rzeczy
@powaznyczlowiek: też jestem ciekaw jak ukrycie ID zwiększa bezpieczeństwo w przypadku gdzie i tak wykonujemy operacje na obiekcie i mamy jego inny (unikalny) identyfikator
@wiesiu2: Jeżeli masz zwykły INT jako id to bez dodatkowej walidacji w formie uwierzytelniania, zgadując id możesz uzyskać dostęp do rekordu do którego nie powinieneś mieć. W przypadku GUID już jest trudniej żeby go zgadnąć.
Po drugie to możemy wyróżnić dwa rodzaje identyfikatorów: biznesowe i techniczne. Biznesowym będzie np. PESEL, NR_ZAMOWIENIA a technicznym PK z bazy. W zależności od wymagań, możemy chcieć reprezentować zasób i udostępniać operacje na nim po id
@markaron: Jedną z takich zalet ukrywania id technicznego jest agnostyczność względem tego co jest moim id. Wtedy zmiana bazy z SQL Server gdzie korzystam z GUIDa/INTa jako PK na takie MongoDB odbywa się transparentnie dla klientów API. Jeżeli wystawiłbym techniczne id w API to klienty API mają problem.
@powaznyczlowiek: ale tu przecież chodzi o to, że wystawiamy idiki i ich nie chronimy dostępem, a nie że są po prostu wystawione. Nawet masz wprost napisane, że wystawianie id publicznie jest częste
Applications frequently use the actual name or key of an object when generating web pages. Applications don’t always verify the user is authorized for the target object. This results in an insecure direct object reference flaw.
@powaznyczlowiek: Chłopie piszesz najpierw że wystawianie id z mongo to zła praktyka potem twierdzisz że jest to powiązane z bezpieczeństwem a na końcu piszesz że nie wiesz czy zwiększy to bezpieczeństwo? XD Pls stop it! A co do linka który podałeś to jasna sprawa że zasób który wystawiamy o ile nie jest to jakiś publicznie dostępny wymaga żeby klient pytający o niego był uwierzetelniony ale w tym przypadku rozmawiamy o slugach
@powaznyczlowiek: teraz mi powiedz jak swoje systemy zabezpieczasz, zgodnie z radami z linka masz ID pobieranego obiektu unikalne dla każdej sesji czy zalogowanego usera? Czy tylko dostęp do obiektu sprawdzasz na podstawie sesji zalogowanego usera?
@markaron: używanie autoinkrementowanego ID w systemach w których można w ten sposób pobierać rekordy faktycznie jest durne, ale to nie do końca jest odpowiedź na to pytanie.
Widziałam coś podobnego za dziecka... Nie mogłam spać więc spoglądałam przez okno, zauważyłam taki "obiekt" Jak na ilustracji, poruszał się powoli i byl wielki (╥﹏╥) Nikt mi nigdy nie uwierzył, a pamiętam każdy najmniejszy szczegół. #przegryw #zalesie #kosmos
/post/:id/post/slug/:slugalbo
/post?slug=slugprzy czym druga opcja musiała by wyrzucać info że nie podano query, co wy o tym myślicie?
#programowanie
/post//post/<:slug>
z tym że ja głównie uuid używam to mi się nigdy nie zdaży taki sam slug jak ID, musiałbyś sobie to zabezpieczyć
@cat_in_hat: oczywiście
@cat_in_hat: restfulowo to powinno być /posts/:id i /posts?slug={slug} (zwróć uwagę na liczbę mnogą). Jednak najlepiej zrobić tak jak Ci wygodnie.
Po drugie to możemy wyróżnić dwa rodzaje identyfikatorów: biznesowe i techniczne. Biznesowym będzie np. PESEL, NR_ZAMOWIENIA a technicznym PK z bazy. W zależności od wymagań, możemy chcieć reprezentować zasób i udostępniać operacje na nim po id
https://wiki.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References
A co do linka który podałeś to jasna sprawa że zasób który wystawiamy o ile nie jest to jakiś publicznie dostępny wymaga żeby klient pytający o niego był uwierzetelniony ale w tym przypadku rozmawiamy o slugach
@markaron: używanie autoinkrementowanego ID w systemach w których można w ten sposób pobierać rekordy faktycznie jest durne, ale to nie do końca jest odpowiedź na to pytanie.