ASP.NET MVC - atak CSRF

Istnieje rodzaj ataku, na który jesteśmy podatni i który często przeoczamy, jest to Fałszerstwo żądań między witrynami lub CSRF, jest to odpowiedzialne za nakłonienie naszej aplikacji do odbierania danych, które nie pochodzą z domeny, w której jest hostowana.
Ten rodzaj ataku jest dość szkodliwy, ponieważ powoduje, że użytkownik, który został oszukany, używa swojego uwierzytelnienia do wprowadzenia danych do naszej bazy danych, wyobraź sobie, że przy tego rodzaju ataku udaje się wprowadzić użytkownika administracyjnego lub być może fałszywe wiadomości do naszej sekcji aktualności .
Jak wyjaśniliśmy, ten atak nakłania naszą aplikację do odbierania danych, które nie pochodzą od niej samej, w tym celu wykorzystuje sposób, w jaki protokoły działają jak HTTP i jego różne metody, w ten sposób atakujący może: utwórz formularz i wskaż naszego kontrolera.
Aby zilustrować ten atak, spójrzmy na następujący kontroler, który jest podatny na tego typu atak:

Tutaj widzimy, w jaki sposób uzyskujemy dane bezpośrednio z naszego formularza i nie jest to złe, jedynym problemem jest to, że nie mówimy naszej aplikacji, że musi zweryfikować swoje pochodzenie, dzięki temu atakujący może wygenerować skrypt podobny do następującego:

POWIĘKSZAĆ

Tutaj jest jasne, co się dzieje, podczas ładowania tej strony wysyłany jest formularz, który wskazuje na konkretny rekord w bazie danych, ten formularz wskazuje na prawidłowy kontroler, więc jeśli uwierzytelniony użytkownik zostanie skierowany na tę stronę, prawdopodobnie jesteśmy w trochę wiązania.
Pomimo tego, jak fatalistyczny może to być, tego ataku można uniknąć, w tym celu musimy tylko wykonać kilka walidacji, które zagwarantują, że otrzymane dane pochodzą z naszej aplikacji, w tym celu możemy użyć niektórych z tych technik:
Odniesienie do domenyPolega to na sprawdzeniu, z której domeny pochodzi żądanie, dzięki temu gwarantujemy, że pochodzi ona tylko z domeny, w której hostowana jest nasza aplikacja, jedynym problemem lub wadą jest to, że jeśli przeprowadzimy migrację naszej aplikacji domenowej, być może będziemy musieli odbudować walidację w przypadku nie zrobiliśmy dynamicznego. Możliwe jest również utworzenie fałszywego odniesienia, wykorzystując luki w aplikacjach, takie jak Adobe flash.
Wygenerowany tokenZ tą opcją robimy, że w naszym formularzu a znak który jest unikalny dla każdego użytkownika, więc nasza aplikacja przy odbiorze formularzy sprawdza, czy token jest taki sam, w ten sposób pozwala na akceptację danych lub nie. Jest to najczęściej używana opcja, ponieważ jest bardzo łatwa do wdrożenia i ma niewiele wad lub nie ma ich wcale.
W przypadku wygenerowanego tokena ASP.NET MVC zawiera kilka metod, które mogą nam pomóc, głównym z nich jest @ Html.AntiForgeryToken () który generuje tajny klucz, za pomocą którego nasza aplikacja może walidować formularze.
Widzimy wtedy, że obszarów jest więcej niż nam się wydaje i że musimy zadbać w naszych aplikacjach, więc musimy się informować i być świadomym, w jaki sposób dochodzi do ataków, aby opracować sposoby ich uniknięcia.