Czy usługi sieciowe JSON są podatne na ataki CSRF?

Buduję usługę sieciową, która używa wyłącznie formatu JSON do obsługi żądań i odpowiedzi (tj. Żadnych ładunków zakodowanych w formularzu).

Czy usługa internetowa jest podatna na atak CSRF, jeśli spełnione są następujące warunki?

1. Każde POSTżądanie bez obiektu JSON najwyższego poziomu, np., {"foo":"bar"}Zostanie odrzucone z wartością 400. Na przykład POSTżądanie z zawartością 42zostanie w ten sposób odrzucone.

2. Każde POSTżądanie o typie treści innym niż application/jsonzostanie odrzucone z wartością 400. Na przykład POSTżądanie o typie treści application/x-www-form-urlencodedzostanie odrzucone.

3. Wszystkie żądania GET będą bezpieczne i nie będą modyfikować żadnych danych po stronie serwera.

4. Klienci są uwierzytelniani za pomocą sesyjnego pliku cookie, który serwis internetowy przekazuje im po podaniu poprawnej pary nazwa użytkownika / hasło za pośrednictwem POST z danymi JSON, np {"username":"[email protected]", "password":"my password"}.

Pytanie pomocnicze: czy PUTi DELETEżądania są kiedykolwiek podatne na CSRF? Pytam, ponieważ wydaje się, że większość (wszystkich?) Przeglądarek nie zezwala na te metody w formularzach HTML.

EDYCJA: Dodano punkt nr 4.

EDYCJA: Jak dotąd wiele dobrych komentarzy i odpowiedzi, ale nikt nie zaproponował konkretnego ataku CSRF, na który ta usługa sieciowa jest podatna.

Kucie arbitralnych żądań CSRF z typów arbitralne mediów jest skuteczne tylko możliwe XHR, ponieważ metoda formularza jest ograniczona do GET i POST oraz POST wiadomość ciało formy jest również ograniczona do trzech formatach application/x-www-form-urlencoded, multipart/form-dataoraztext/plain . Jednak dzięki kodowaniu danych formularza text/plainnadal można fałszować żądania zawierające prawidłowe dane JSON .

Więc jedyne zagrożenie pochodzi z ataków CSRF opartych na XHR. A te odniosą sukces tylko wtedy, gdy pochodzą z tego samego źródła, a więc w zasadzie jakoś z Twojej własnej witryny (np. XSS). Uważaj, aby nie pomylić wyłączenia CORS (tj. Nie ustawiania Access-Control-Allow-Origin: *) jako ochrony. CORS po prostu uniemożliwia klientom odczytanie odpowiedzi. Całe żądanie jest nadal wysyłane i przetwarzane przez serwer.

Tak to mozliwe. Możesz skonfigurować serwer atakującego, który odeśle przekierowanie 307 do serwera docelowego na zaatakowaną maszynę. Aby wysłać POST, musisz użyć Flasha zamiast formularza.

Źródła: https://bugzilla.mozilla.org/show_bug.cgi?id=1436241

Działa również w przeglądarce Chrome.

Możliwe jest wykonanie CSRF na usługach Restful opartych na JSON przy użyciu Ajax. Przetestowałem to na aplikacji (używając zarówno przeglądarki Chrome, jak i Firefox). Musisz zmienić contentType na text / plain i dataType na JSON, aby uniknąć żądania wstępnego. Następnie możesz wysłać żądanie, ale aby wysłać sessiondata, musisz ustawić flagę withCredentials w swoim żądaniu ajax. Omawiam to bardziej szczegółowo tutaj (w tym odniesienia):

http://wsecblog.blogspot.be/2016/03/csrf-with-json-post-via-ajax.html

Mam pewne wątpliwości co do punktu 3. Chociaż można go uznać za bezpieczny, ponieważ nie zmienia danych po stronie serwera, dane można nadal odczytać i istnieje ryzyko ich kradzieży.

http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/

Czy usługa internetowa jest podatna na atak CSRF, jeśli spełnione są następujące warunki?

Tak. To nadal HTTP.

Czy żądania PUT i DELETE są kiedykolwiek podatne na CSRF?

tak

wydaje się, że większość (wszystkie?) przeglądarki nie zezwalają na te metody w formularzach HTML

Czy uważasz, że przeglądarka to jedyny sposób na wysłanie żądania HTTP?