Wątek przeniesiony 2020-07-02 10:00 z C# i .NET przez cerrato.

Czy trzymanie Id na froncie jest dobrą praktyką?

0

Powiedzmy, że mam aplikację publiczną, w której po zalogowaniu ktoś widzi listę użytkowników.
Imię Nazwisko. Na ekranie jest pod polem hidden ukryte również Id użytkownika, które później wykorzystywane jest w bazie danych.
Id to jest również wykorzystane np przy wywołaniu funkcji Edytuj czy Usuń, gdzie jest przekazywane jako argument do metody serwera żeby ten wiedział jakiego user edytujemy/usuwamy.

Czy to jest dobra praktyka? Chodzi mi o to, że te Idki pojawiają się (nawet jeśli pod polem hidden) na frontendzie.

0
hercules napisał(a):

Id to jest również wykorzystane np przy wywołaniu funkcji Edytuj czy Usuń, gdzie jest przekazywane jako argument do metody serwera żeby ten wiedział jakiego user edytujemy/usuwamy.

Skoro ID jest trzymane na froncie to pomyśl co się stanie w przypadku kiedy to ID ktoś zmieni np. przed użyciem metody Usuń.

0

Dokładnie o tym pomyślałem dlatego zadaję to pytanie.
Jak w takim razie identyfikować usera do edycji? Jak skomunikować front z API pod tym względem jeśli nie po Id?

2

Musisz weryfikować kto robi daną operacje i czy może to zrobić. A kolejna rzecz, żeby trudniej było hackować to użyj Guid'a jako ID

4

Samo w sobie wysłanie takich danych do użytkownika to nie problem, jeśli zrobi się zabezpieczenie. Można ograniczyć użytkownikowi możliwość edycji danych do id, które pobrał (zapamiętać w sesji).

6

Tak czy inaczej potrzebujesz tych ID do edycji danych. Jak użyjesz innych danych z formularza do API to user też to może zrobić. Możesz (powinieneś) ograniczyć dostęp użytkownikowi maksymalnie jak to tylko potrzebne i sprawdzać uprawnienia na backendzie. Ale jak użytkownik ma dostęp do jakichś danych, funkcjonalności (jak użytkownik nie powinien robić edycji danych to należy mu to zablokować w uprawnieniach), to nie jesteś w stanie zabezpieczyć się przed tym, żeby nie zrobił sobie krzywdy na własne życzenie.

6

Trzymanie ID na froncie jest jak najbardziej normalną praktyką, ponieważ jak było już wcześniej wspomniane inaczej nie wiedziałbyś jakiego użytkownika usunąć/edytować. Warunkiem jest odpowiednie zabezpieczenie aplikacji. Czyli np. tylko zalogowany użytkownik z danym ID może dokonywać operacji na tym użytkowniku, lub użytkownik z odpowiednimi uprawnieniami (np. admin).

0

Rozumiem, dziękuję :)

3

A to użytkownik nie ma żadnego klucza potencjalnego oprócz bazodanowego IDka? Jak się loguje, też IDkiem z bazy danych?

2

Jeśli chcesz swoje ID z bazy danych ukryć na frontendzie - to spotkałem się z takim rozwiązaniem, że nie wysyłamy ID do użytkownika, tylko je hashujemy / zmieniamy na coś tymczasowo pośredniego i wysyłamy to do użytkownika z odpowiednim czasem życia. Użytkownik wysyłając nam zmapowane ID, pozwala nam zweryfikować czy temu użytkownikowi przypisaliśmy tymczasowo taki ID. Po weryfikacji, po prostu przy następnej sesji użytkownik dostanie coś innego.

2

Musisz mieć Id. Innej opcji nie ma. Tak było, jest i będzie. Ale powinieneś się też zabezpieczyć. Możliwie na kilka sposobów:

  • Antiforgery token
  • Badanie po stronie serwera, czy zalogowany użytkownik może wykonać tą akcję (usunąć właśnie ten rekord o tym id)
2

Czy to jest dobra praktyka? Chodzi mi o to, że te Idki pojawiają się (nawet jeśli pod polem hidden) na frontendzie.

Tak, jest to dobra praktyka. Zresztą zobacz tu na forum albo stackoverflow, wszędzie widzisz IDki w URLach do profili userów, do postów, komentarzy itp..

0
qbns napisał(a):

Zresztą zobacz tu na forum albo stackoverflow, wszędzie widzisz IDki w URLach do profili userów, do postów, komentarzy itp..

Dla odmiany zobacz na URLe w Wikipedii.

0

Jest normalne.
Trzeba tylko zabezpieczyć system odpowiednimi uprawnieniami.
Jeśli z jakiegoś powodu potrzebujesz wystawić na front albo do urla jakieś bardziej wrażliwe dane to możesz je zaszyfrować AESem

2

To zależy.
Domyślnie raczej nie powinniśmy pokazywać autonumerowanych ID (sekwencji), bo:

  • ułatwiamy ataku, (w życiu jest takm że zawsze ktoś gdzieś w końcu jakiegoś checka nie zrobi),
  • ekspenujemy informacje, które możemy chcieć ukryć (lub nasi klienci) - ile jest użytkowników, ile mamy produktów, ile sprzedajemy itp...

Generalnie bezpieczny default to losowy UID.

ID z sekwencji używam raczej ... do zabawy - jak robię kolejne TodoMVC oraz jeśli z biznesu wynika, że i tak jest to informacja eksponowana na zewnątrz.

2

Też bym sobie zrobił jakieś tłumaczenie ID w bazie/systemie na/do ID na froncie. Do klienta przesyłasz ID/token w stylu "5344rf367CE", ale jednocześnie gdzieś w bazie trzymasz informację, że ten klucz odpowiada userowi o ID=352. Nawet jeśli ktoś będzie chciał wykorzystać jakiegoś SQL Injection czy znajdzie inną dziurę, to SELECT * WHERE ID=5344rf367CE nic mu nie zwróci, bo nie ma takiego ID w bazie.

0

A nie możesz jak człowiek po zalogowaniu użytkownika do systemu stworzyc mu unikalny token a potem przetrzymywac go w sesji i za jego pomoca wyciagac id gdzies pod spodem?

1 użytkowników online, w tym zalogowanych: 0, gości: 1