Уязвимы ли веб-сервисы JSON для атак CSRF?

Я создаю веб-службу, которая использует исключительно JSON для своего содержимого запроса и ответа (т.е. полезные нагрузки, не закодированные в форме).

Уязвима ли веб-служба для атаки CSRF, если верно следующее?

1. Любой POSTзапрос без объекта JSON верхнего уровня, например, {"foo":"bar"}будет отклонен с 400. Например, POSTзапрос с содержимым 42будет таким образом отклонен.

2. Любой POSTзапрос с типом содержимого, отличным от типа, application/jsonбудет отклонен с 400. Например, POSTзапрос с типом содержимого application/x-www-form-urlencodedбудет таким образом отклонен.

3. Все запросы GET будут безопасными и, следовательно, не будут изменять какие-либо данные на стороне сервера.

4. Клиенты аутентифицируются с помощью файла cookie сеанса, который веб-служба предоставляет им после того, как они предоставят правильную пару имени пользователя и пароля через POST с данными JSON, например {"username":"user@example.com", "password":"my password"}.

Вспомогательные вопросы: Аре PUTи DELETEзапросы всегда уязвимы для CSRF? Я спрашиваю, потому что кажется, что большинство (всех?) Браузеров запрещают эти методы в формах HTML.

РЕДАКТИРОВАТЬ: добавлен пункт №4.

РЕДАКТИРОВАТЬ: Пока много хороших комментариев и ответов, но никто не предлагал конкретную CSRF-атаку, для которой этот веб-сервис уязвим.

Ковка произвольных запросов CSRF с типами произвольной медиа эффективно возможно только с XHR, так как метод формы ограничивается получить и POST и А тело сообщения POST формы имеют также ограничиваются три форматов application/x-www-form-urlencoded, multipart/form-dataиtext/plain . Однако с кодировкой данных формы по- text/plainпрежнему можно подделывать запросы, содержащие действительные данные JSON .

Таким образом, единственная угроза исходит от атак CSRF на основе XHR. И они будут успешными только в том случае, если они из одного и того же происхождения, то есть в основном с вашего собственного сайта (например, XSS). Будьте осторожны, чтобы не ошибиться, отключив CORS (т.е. не установив Access-Control-Allow-Origin: *) в качестве защиты. CORS просто не дает клиентам прочитать ответ. Весь запрос по-прежнему отправляется и обрабатывается сервером.

Да, это возможно. Вы можете настроить сервер злоумышленника, который будет отправлять 307 редирект на целевой сервер на машину жертвы. Вам необходимо использовать flash для отправки POST вместо использования формы.

Ссылка: https://bugzilla.mozilla.org/show_bug.cgi?id=1436241

Он также работает в Chrome.

С помощью Ajax можно выполнять CSRF на сервисах Restful на основе JSON. Я тестировал это в приложении (используя как Chrome, так и Firefox). Вы должны изменить contentType на text / plain и dataType на JSON, чтобы избежать предварительного запроса. Затем вы можете отправить запрос, но для отправки данных сеанса вам необходимо установить флаг withCredentials в вашем запросе ajax. Я обсуждаю это более подробно здесь (ссылки включены):

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

У меня есть некоторые сомнения относительно пункта 3. Хотя его можно считать безопасным, поскольку он не изменяет данные на стороне сервера, данные все же можно прочитать, и существует риск их кражи.

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

Уязвима ли веб-служба для атаки CSRF, если верно следующее?

Да. Это все еще HTTP.

Уязвимы ли запросы PUT и DELETE для CSRF?

да

кажется, что большинство (все?) браузеры запрещают эти методы в формах HTML

Вы думаете, что браузер - единственный способ сделать HTTP-запрос?