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

82

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?

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.
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.
Wszystkie żądania GET będą bezpieczne i nie będą modyfikować żadnych danych po stronie serwera.
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":"user@example.com", "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.

http security csrf

— djsmith
źródło

tokenizuj swoje żądania za pomocą sparowanych wartości sesji i plików cookie, oczyszczaj wszelkie dyrektywy, które uruchamiasz za pośrednictwem przesłanego kodu JSON, dodaj sól, aby uzyskać dodatkowy smak

— Brandt Solovij

Myślę, że nie ma tu wystarczających informacji, aby podać dobrą odpowiedź. Jakiej metody uwierzytelniania używasz? Kim są

— docelowi

1

Wszystkie Twoje bieżące walidacje są całkowicie rozsądne i ograniczają powierzchnię ataku, ale tak naprawdę nie odnoszą się do niczego, co ma związek z tym, czym jest luka w zabezpieczeniach CSRF.

— Cheekysoft

2

Zobacz security.stackexchange.com/questions/10227/csrf-with-json-post

— eskatos

2

@ DavidBalažic Jaki wektor? Jeśli mówisz o AJAX, zapobiegną temu zasady tego samego pochodzenia.

— djsmith

73

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.

— Gumbo
źródło

9

Jak skomentowałem twoją połączoną odpowiedź, zapewniam, że tekst / zwykły może rzeczywiście być używany do fałszowania JSON, jeśli serwer nie wymaga application / json, używając technik podobnych do pentestmonkey.net/blog/csrf-xml-post-request .

8

Ta odpowiedź jest poprawna do dzisiaj, ale prawdopodobnie wkrótce będzie błędna. W3C rozważa dodanie enctype = "application / json" do standardu HTML: darobin.github.io/formic/specs/json Więc nie polegaj na typie treści POST dla trwałego bezpieczeństwa, użyj tokena anty-CSRF.

— LordOfThePigs,

@LordOfThePigs Wykuwanie prawidłowego JSON jest już możliwe z tekstem / zwykłym .

— Gumbo,

@Gumbo jest poprawne, ale obecnie nie możesz ustawić typu kodowania, application/jsonktóry jest używany do powstrzymywania ataków CSRF w tej odpowiedzi. Proponowany standard pozwoli ci ustawić enctype na application/json, co spowoduje pokonanie kontroli typu zawartości przedstawionej w odpowiedzi i otworzy aplikację na CSRF.

— LordOfThePigs,

10

Wygląda na to, że projekt poprzedza ten atak. Sekcja 5 określa, że application/jsonposty formularza muszą być zgodne z tą samą polityką pochodzenia, co oznacza, że atak nie jest silniejszy niż XHR.

— James_pic

3

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.

— Timothy Leung
źródło

1

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

— Filip Waeytens
źródło

To jest niepotrzebne. Jeśli serwer odczytuje żądania w postaci zwykłego tekstu jako JSON, formularz zakodowany jako zwykły tekst wystarczy do sfałszowania takiego żądania, jak wspomniał Gumbo. Serwery API powinny po prostu odrzucać żądania w postaci zwykłego tekstu.

— Franklin Yu

-1

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/

— panteo
źródło

1

Działa to tylko wtedy, gdy obiekt najwyższego poziomu zwracany przez interfejs API jest tablicą JSON, ponieważ JavaScript umożliwia zastąpienie konstruktora Array. Obiekt najwyższego poziomu jest bezpieczny. Więcej na flask.pocoo.org/docs/0.10/security/#json-security .

— btubbs

Według samego autora „ Myślę, że żadna z nowoczesnych przeglądarek nie ma już tej wady ”.

— Franklin Yu

-6

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?

— symcbean
źródło

3

Tylko dlatego, że usługa korzysta z protokołu HTTP, nie czyni jej podatną na CSRF. Czy potrafisz zidentyfikować rzeczywisty wektor ataku CSRF, na który ta usługa, zgodnie z opisem, jest podatna? I oczywiście nie sądzę, aby przeglądarka była jedynym sposobem na wykonanie żądania HTTP, ale przeglądarka jest najczęściej (tylko?), Że użytkownik jest nakłaniany do wykonania fałszywego żądania między witrynami, którego nie zrobił oczekiwać.

— djsmith

Innymi słowy, pokaż mi konkretny wektor ataku CSRF, który wykorzystuje PUT, aby nakłonić użytkownika do wysłania żądania PUT do mojej usługi internetowej (zgodnie z opisem). Uważam, że to niemożliwe.

— djsmith

@symcbean: Czy możesz opublikować referencje lub w inny sposób obronić swoją odpowiedź? Nie głosowałem na tę odpowiedź. Chciałbym, żebyś najpierw włączył się. Dzięki.

— dotancohen

Czy Google znowu nie działa? Pomijając kwestię treści, starsze wersje Flasha (nowsze wersje Flasha mają model kontroli cross-domian - ale różni się od HTML5) - a co z przemytem słoików - pseudo-flaw.net/content/web-browsers/corrupted -jars (Java wykonuje się w aktywnym kontekście, ale może wywoływać javascript w kontekście pasywnym). Potem są ataki rebinding DNS i ataki MITM

— symcbean

Wtyczki przeglądarki mogą odczytywać plik cookie CSRF i wysyłać dowolny nagłówek, więc nawet standardowe mechanizmy wymuszające CSRF defacto są podatne na złośliwą wtyczkę przeglądarki.

— djsmith