Zapobieganie manipulacjom adresu URL za pomocą MVC?

Question

Wszelkie dobre strategie, fragmenty kodu itp. W celu zapobiegania manipulowaniu adresami URL?

Na przykład mam ten adres URL, http://localhost/profile/edit/5 id może być łatwo zmieniony na cokolwiek, a zatem ludzie mogą edytować profile, które też nie powinny.

Oto kilka pomysłów myślałem, ale wszystkie mają tam wady:

1. zmienić swój system, aby używać kluczy podstawowych GUID - sprawia, że ​​prawie niemożliwe do odgadnięcia kluczy - ale ludzie wciąż mogą wziąć GUID z jednej części aplikacji i użyj go później w innym adresie URL.

2. Użyj TempData do przechowywania kluczy - zapobiega wysyłaniu adresów URL wokół \ used później.

3. Wykonaj kontrole w kontrolerze przed wyświetleniem strony - oznacza to, że musisz wprowadzić kod "adminy" wszędzie, gdzie sprawdza operacje.

Co najlepiej zrobić? Jeden z tych czy coś innego?

Answer 1

Numer 3 to poprawna czynność. Server-Side Security Validation jest zawsze tym, czego potrzebujesz, ponieważ jest to mechanizm, który całkowicie kontrolujesz i na którym możesz polegać.

Numer 1 to Zabezpieczenia przez przypadek, a jeśli ktoś przypadkowo umieści swój adres URL gdzieś (jak ludzie często robią z Session-ID podczas kopiowania/wklejania linków), twoje "Bezpieczeństwo" jest zepsute.

Numer 2 wydaje się słabym zabezpieczeniem - jeśli przejdzie się przez kłopoty, lepiej wdrożyć odpowiednie zabezpieczenia. Dzięki temu ludzie mogą dodawać zakładki do strony.

Answer 2

Adres URL używany do uzyskania dostępu do Twojej witryny to dane od klienta, a gdy chodzi o bezpieczeństwo, zawsze powinieneś traktować dane klienta jako wrogie.

Niestety, nie ma srebrnych kul, aby poradzić sobie z tym problemem. Będziesz musiał zaimplementować ograniczenia dostępu w całej aplikacji.

Answer 3

Nie należy ustawiać adresów URL jako "odpornych na manipulacje" w celu ochrony podstawowych funkcji. Poza tym: większość stron internetowych sprawia, że ​​adresy URL są bardziej czytelne, jak na przykład http://stackoverflow.com/questions/741653/preventing-url-manipulation-attacks-with-mvc - zaciemnianie byłoby krokiem do tyłu.

Zamiast sprawdzać uprawnienia w kontrolerach i zgłaszać wyjątki, jeśli użytkownik nie ma uprawnień do edycji profilu 6. Jeśli nie chcesz mieć "czeków" wszędzie, może możesz je umieścić w postaci ActionFilter lub utwórz pewną metodę pomocniczą, taką jak CurrentUser.FindProfileToEditById(profileId) (która zgłasza wyjątek, jeśli akcja nie jest dozwolona) zamiast Profile.FindById(id).

Jeśli chcesz korzystać z ogólnej usługi, w której nie masz "bieżącego użytkownika", możesz użyć identyfikatora GUID (na przykład Doodle na przykład) - jednak na różne sposoby będzie to stanowić zagrożenie dla bezpieczeństwa (Facebook miał to wydać z ich albumami fotograficznymi).

Answer 4

Używam niestandardowych filtrów autoryzacji, aby wdrożyć kontrolę dostępu opartą na rolach i właścicielach. Standardowy filtr AuthorizationFilter umożliwia określenie nazwanych ról lub użytkowników, którzy mogą uzyskać dostęp do akcji. Rozszerzyłem to, aby umożliwić ci określenie, czy bieżący użytkownik może mieć dostęp, jeśli jest "właścicielem" danych.Mam dwa dodatkowe filtry, RoleOrOwnerAuthorizationFilter i RoleOrOwnerAssociatedAuthorizationFilter. Pierwsze sprawdzanie, czy parametrem konfigurowalnym (zwykle id) przekazanym w RouteData jest identyfikator bieżącego użytkownika w tabeli moich użytkowników lub czy bieżący użytkownik znajduje się w którejkolwiek z wymienionych ról. Jeśli tak, sprawdzenie powiedzie się, jeśli nie, zwróci widok błędu autoryzacji.

Druga pozwala mi określić tabelę łączenia i parametry używane do powiązania parametru w RouteData z kolumną tabeli łączenia i bieżącym użytkownikiem z inną kolumną w tabeli łączenia. Jeśli istnieje pozycja pasująca zarówno do wartości parametru, jak i do użytkownika, dochodzę do wniosku, że użytkownik jest powiązany z danymi i może mieć do nich dostęp. Umożliwia także dostęp, jeśli masz określoną rolę. Między trzema różnymi atrybutami mam prawie wszystkie moje potrzeby kontroli dostępu, co oznacza, że ​​stosuję zabezpieczenia po prostu dekorując odpowiednio skonfigurowanym atrybutem.