Korzystanie MVC3 za AntiForgeryToken w HTTP GET, aby uniknąć luki JavaScript CSRF

Question

In regards to this Haacked blog, jestem niezdecydowany do wprowadzenia proponowanych rozwiązań GET porywanie anty-JSON od

1. zalecanych rozwiązań do łagodzenia JSON porwanie obejmować zakaz REST- pełne JSON POSTs do pobrania danych

2. Alternatywne rozwiązanie (pakowanie obiektów) powoduje problemy z kontrolkami stron trzecich, do których nie mam dostępu z kodem źródłowym.

3. Nie mogę znaleźć implementacji sprawdzonej przez społeczność, która implementuje rozwiązanie alternatywne (wymienione poniżej) dotyczące tworzenia tokena zabezpieczającego lub bezpiecznego dostarczania go na stronie internetowej. Nie będę też twierdził, że jestem wystarczającym ekspertem, aby zrealizować własną implementację.

4. nagłówków stron odsyłających nie można powoływać

Tło

This blog opisuje CSRF kwestię dotyczącą JSON porwania i zaleca stosowanie metody POST JSON, aby uzyskać dane. Ponieważ korzystanie z danych POST HTTP do GET nie jest w pełni zajęte REST, szukałem bardziej RESTfull rozwiązania, które umożliwia REST akcje na sesję lub na stronę.

Inną techniką łagodzenia jest zawijanie danych JSON w obiekcie as described here. Obawiam się, że może to tylko opóźnić kwestię, dopóki nie zostanie znaleziona inna technika.

alternatywna Realizacja

Dla mnie wydaje się naturalne, aby rozszerzyć stosowanie ASP.NET MVC's AntiForgeryToken z jQuery HTTP GET dla mojego JSON.

Na przykład jeśli dostanę jakieś poufne dane, zgodnie z linku Haacked powyżej, następujący kod jest podatny:

$.getJSON('[url]', { [parameters] }, function(json) { 
    // callback function code 
}); 

Zgadzam się, że to nie jest Restfull aby uzyskać dane za pomocą zalecanego POST obejścia. Moją myślą jest wysłanie tokena weryfikacyjnego w adresie URL. W ten sposób osoba atakująca w stylu CSRF nie będzie znała pełnego adresu URL. W pamięci podręcznej lub bez pamięci podręcznej nie będą mogli uzyskać danych.

Poniżej znajdują się dwa przykłady tego, jak można wykonać zapytanie JSON GET. Nie jestem pewien, która implementacja jest najskuteczniejsza, ale można się domyślić, że pierwsza z nich jest bezpieczniejsza, ponieważ błędne serwery proxy buforują te dane, przez co są podatne na atakowanie.

http://localhost:54607/Home/AdminBalances/ENCODEDTOKEN-TOKEN-HERE

lub

http://localhost:54607/Home/AdminBalances?ENCODEDTOKEN-TOKEN-HERE

... który równie dobrze może być MVC3 za AntiForgeryToken albo wariant (see swt) tego rozporządzenia. Ten token zostałby ustawiony jako wartość wbudowana w dowolnym formacie adresu URL wybranym powyżej.Pytania

Przykładowe które uniemożliwiają mi toczenia moje własne rozwiązanie

1. Jaki format adresu URL (powyżej) należy użyć do sprawdzania GET JSON (ukośnik, questionmark, etc) Czy pełnomocnik odpowiedzi na http://localhost:54607/Home/AdminBalances z danymi http://localhost:54607/Home/AdminBalances?ENCODEDTOKEN-TOKEN-HERE?

2. Jak dostarczyłbyś zakodowany token na stronę? Inline lub jako zmienna strony?

3. Jak skomponowałbyś token? Zbudowany w AntiforgeryToken lub w jakiś inny sposób?

4. AntiForgeryToken używa pliku cookie. Czy w tym przypadku użyjemy/będziemy w tym celu pliku cookie? Tylko HTTP? A co z SSL w połączeniu z HTTP Only?

5. Jak ustawić nagłówki pamięci podręcznej? Wszystko, co jest specjalne dla Google Web Accelerator (na przykład)

6. Jakie są konsekwencje po prostu dokonaniu zgłoszenia SSL JSON?

7. Czy zwrócona tablica JSON nadal jest opakowana w obiekt tylko ze względu na bezpieczeństwo?

8. Jak będzie to rozwiązanie współdziałanie z proponowanych templating and databinding funkcji Microsoft

powyższe pytania są przyczyny nie będę rozwijał i robi to samodzielnie. Nie wspominając o prawdopodobnych więcej pytaniach, o których nie myślałem, a mimo to ryzykuję.

Answer 1

Asp.net MVC AntiForgeryToken nie będzie działać poprzez HTTP GET, ponieważ opiera się na ciasteczka, które opierają się na HTTP POST (używa „Double Submit Cookies” technikę opisaną w OWASP XSRF Prevention Cheat Sheet). Możesz również dodatkowo zabezpieczyć pliki cookie wysyłane do klienta, ustawiając je jako httponly, aby nie można było ich sfałszować za pomocą skryptu.

W this document można znaleźć różne techniki, które można wykorzystać do zapobiegania XSRF. Wygląda na to, że opisywana przez Ciebie metoda byłaby zgodna z podejściem 1. Ale mamy problem z odzyskaniem sesji na serwerze podczas korzystania z żądania HTTP HTTP Ajax, ponieważ pliki cookie nie są wysyłane wraz z żądaniem. Więc musisz dodać identyfikator sesji do adresu URL akcji (inaczej sesje cookieless, które są łatwiejsze do przejęcia). Aby więc przeprowadzić atak, osoba atakująca musi znać tylko poprawny adres URL, aby wykonać żądanie GET.

Być może dobrym rozwiązaniem byłoby przechowywanie danych sesji za pomocą klucza z certyfikatu SSL użytkownika (na przykład certyfikatu thumb-print). W ten sposób tylko właściciel certyfikatu SSL może uzyskać dostęp do swojej sesji. W ten sposób nie musisz używać plików cookie i nie musisz wysyłać identyfikatorów sesji za pomocą parametrów ciągu zapytania.

W każdym razie, jeśli nie chcesz używać HTTP POST w Asp.net MVC, musisz wdrożyć własną ochronę XSRF.

Answer 2

Przyszedłem do tego problemu, a rozwiązanie nie było tak banalne, jakkolwiek istnieje fantastyczny blog, na którym można zacząć, można go używać z get i post ajax.

http://johan.driessen.se/posts/Updated-Anti-XSRF-Validation-for-ASP.NET-MVC-4-RC

Jeśli umieścić następujące w globalnej przestrzeni nazw wszystkich poście/dostaje mogą skorzystać mającą przeciw fałszowaniu żeton i nie trzeba modyfikować ajax połączeń. Utwórz element wejściowy na wspólnej stronie.

<form id="__AjaxAntiForgeryForm" action="#" method="post">@Html.AntiForgeryToken()</form> 

Następujący javascript odczyta tokken zapobiegający fałszowaniu i doda go do nagłówka żądania.

// Wire up the global jQuery ajaxSend event handler. 
$(document).ajaxSend(namespace.ajax.globalSendHandler); 

// <summary> 
// Global handler for all ajax send events. 
// </summary> 
namespace.ajax.globalSendHandler = function (event, xhr, ajaxOptions) { 
    // Add the anti forgery token 
    xhr.setRequestHeader('__RequestVerificationToken', $("#__AjaxAntiForgeryForm input[name=__RequestVerificationToken]").val()); 
};