Являются ли веб-службы JSON уязвимыми для атак CSRF?

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

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

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

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

  • Все запросы GET будут безопасно и, таким образом, не будут модифицировать серверные данные.

  • Клиенты аутентифицируются через куки файлы сеанса, которые веб-служба предоставляет им после того, как они предоставляют правильную пару имени пользователя/пароля через POST с данными JSON, например. {"username":"[email protected]", "password":"my password"}.

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

EDIT: Добавлен элемент # 4.

EDIT: много хороших комментариев и ответов до сих пор, но никто не предлагал конкретную атаку CSRF, для которой этот веб-сервис уязвим.

ОТВЕТЫ

Ответ 1

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

Таким образом, единственная угроза исходит от атак CSRF на основе XHR. И они будут успешными только в том случае, если они либо

  • выполняется из одного и того же источника, поэтому в основном с вашего собственного сайта каким-то образом (например, XSS) или
  • запускается из другого источника, и сервер

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

Да. Он по-прежнему HTTP.

Являются ли запросы PUT и DELETE когда-либо уязвимыми для CSRF?

Да

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

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