Bezpieczeństwo z wartościami QueryString w Asp.net MVC

Question

Jak prawidłowo upewnić się, że użytkownik nie narusza wartości kwerendy lub wartości adresów URL działania? Na przykład, możesz mieć działanie Usuń komentarz na swoim CommentControllerze, który pobiera CommentID. Adres URL działania może wyglądać tak:/Komentarze/Usuń/3, aby usunąć komentarz z identyfikatorem 3.

Oczywiście nie chcesz, aby ktokolwiek mógł usunąć komentarz 3. Normalnie na właściciela komentarza lub administratora pozwolenie na to. Widziałem, jak to bezpieczeństwo było egzekwowane na różne sposoby i chciałbym wiedzieć, jak niektórzy z was to robią.

Czy wykonujesz wiele wywołań bazy danych w celu pobrania komentarza i czy autor komentarza odpowiada użytkownikowi wywołującemu akcję kasowania?

Czy zamiast tego przekazujesz identyfikator komentarza i identyfikator użytkownika do procedury składowanej, która usuwa i czy usuwa, gdzie identyfikator użytkownika i identyfikator komentarza są równe wartościom przekazanym?

Czy lepiej zaszyfrować wartości ciągu zapytania?

Answer 1

Nie musisz.

Jest to reguła kardynał programowania, szczególnie w dzisiejszych czasach, że nie ufasz żadnych danych, które pochodzi od użytkownika, przeglądarkę, klienta itp

Jest również kardynał zasada programowania, że ​​nie powinieneś chyba sam próbować implementować szyfrowania i bezpieczeństwa, chyba że naprawdę wiesz, co robisz. A nawet jeśli wiesz, co robisz, pozostaniesz tylko o krok przed tandetami. Ci inteligentni nadal będą się z ciebie śmiać.

Wykonaj dodatkowe zapytanie, aby upewnić się, że zalogowany użytkownik ma odpowiedni zestaw uprawnień. To sprawi, że życie wszystkich będzie o wiele prostsze.

Answer 2

Zrobiłem ostry rzeczy wziąć ciągu kwerendy, ścisnąć go, Base64 lub tylko hex zakodować go, tak że "commentid = 4 & userid = 12345" staje się "code = 1a2b23de12769"

Jest to w zasadzie „Bezpieczeństwo dzięki zapomnienie ", ale robi to dużo pracy dla kogoś, kto próbuje włamać się na stronę.

Answer 3

Nie możesz tego łatwo zrobić.

Mam miłe wspomnienia z witryny, która używa adresów URL akcji do usuwania.

Wszystko było dobrze, dopóki nie rozpoczęto wyszukiwania przeszukiwania intranetu.

Ooops, żegnaj dane.

Polecam rozwiązanie, w którym nie korzystasz z programów querystring do niczego, czego nie chcesz edytować.

Answer 4

Można również zezwolić tylko na żądania Post do akcji kontrolera Delete za pomocą atrybutu Accept Verbs, jak pokazano poniżej.

[AcceptVerbs(HttpVerbs.Post)] 
public ActionResult Delete(int? id) 
{ 
    //Delete 
} 

Wtedy można też użyć token zabezpieczającym jak omówiono tutaj:

http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Answer 5

Vyrotek: Metoda wejściowy nie jest ważne. GET, POST, zaszyfrowane/zaciemnione GET - bez prawdziwej różnicy.Bez względu na to, w jaki sposób aplikacja otrzymuje polecenia, aby wykonać akcję administracyjną, musi upewnić się, że użytkownik, który ją wydał, może robić to, co chce. Kontrola uprawnień musi mieć miejsce PO odebraniu polecenia i PRZED jego wykonaniu. W przeciwnym razie nie ma żadnego bezpieczeństwa.

Answer 6

Zastanów się nad wykorzystaniem techniki opisanej w artykule Stephen Walther za Tip #46 – Don’t use Delete Links because they create Security Holes która wykorzystuje [AcceptVerbs (HttpVerbs.Delete)]

Answer 7

Enrypting i deszyfrowania params zapytania jest trywialny proces i istnieją wielkie przykłady jak to zrobić przy użyciu HttpModule tutaj na StackOverflow.

: „Nie”, „nie można”, albo „To nie jest łatwe” po prostu nie są akceptowalne reakcje w dzisiejszych czasach ...