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

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

Is a web service vulnerable to CSRF attack if the following are true?

Any POST request without a top-level JSON object, e.g., {"foo":"bar"}, will be rejected with a 400. For example, a POST request with the content 42 would be thus rejected.

Any POST request with a content-type other than application/json will be rejected with a 400. For example, a POST request with content-type application/x-www-form-urlencoded would be thus rejected.

All GET requests will be Safe, and thus not modify any server-side data.

Clients are authenticated via a session cookie, which the web service gives them after they provide a correct username/password pair via a POST with JSON data, e.g. {"username":"[email protected]", "password":"my password"}.

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

РЕДАКТИРОВАТЬ: Добавлен элемент № 4.

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

 Brandt Solovij13 июн. 2012 г., 07:09
токенизировать ваши запросы через парные значения сеанса и cookie, очистить любые директивы, которые вы запускаете через отправленный JSON, добавить соль для дополнительного вкуса
 McGarnagle13 июн. 2012 г., 07:39
Я не думаю, что здесь достаточно информации, чтобы дать хороший ответ. Какой метод аутентификации вы используете? Кто является предполагаемыми потребителями веб-сервиса (т. Е. Пользователями сайта на том же хосте, что и ваш сервис?)
 eskatos06 окт. 2014 г., 19:15
 Cheekysoft13 июн. 2012 г., 12:54
Все ваши текущие проверки совершенно разумны и ограничивают поверхность атаки, но на самом деле они не затрагивают ничего, связанного с уязвимостью CSRF.
 djsmith19 мая 2015 г., 16:16
@ DavidBala & # x17E; ic Какой вектор? Если вы говорите об AJAX, политика того же происхождения предотвратит это.

Ответы на вопрос(5)

Решение Вопроса

медиа фактически возможна только с XHR, потому чтометод формы ограничен GET и POST итело сообщения формы POST также ограничено тремя форматамиapplication/x-www-form-urlencoded, multipart/form-data, and text/plain, Тем не мение,с кодировкой данных формыtext/plain it is still possible to forge requests containing valid JSON data.

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

run from the same origin, so basically from your own site somehow (e. g. XSS), or run from a different origin and your server allows such cross-origin requests.

Если вы можете устранить оба, ваш веб-сервис не уязвим для CSRF. По крайней мере, не те, которые выполняются через веб-браузер.

 11 июл. 2014 г., 12:52
Этот ответ верен до сегодняшнего дня, но, вероятно, скоро ошибется. W3C рассматривает возможность добавления enctype = "application / json" к стандарту HTML:darobin.github.io/formic/specs/json  Так что не полагайтесь на тип тела POST для длительной безопасности, используйте токен анти-CSRF.
 29 янв. 2015 г., 14:48
Похоже, проект был опубликован:w3.org/TR/html-json-forms
 02 июн. 2013 г., 22:54
Как я прокомментировал ваш связанный ответ, я утверждаю, что text / plain действительно может использоваться для подделки JSON, если серверу не требуется application / json, используя методы, аналогичныеpentestmonkey.net/blog/csrf-xml-post-request.
 22 мар. 2015 г., 12:08
Похоже, что проект предотвращает эту атаку. Раздел 5 указывает, чтоapplication/json Формы сообщений должны соответствовать той же политике происхождения, что означает, что атака не сильнее, чем XHR.
 11 июл. 2014 г., 18:11
@LordOfThePigs Создание действительного JSON уже возможно сtext/plain.

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

Are PUT and DELETE requests ever vulnerable to CSRF?

да

it seems that most (all?) browsers disallow these methods in HTML forms

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

 04 дек. 2013 г., 23:49
Google снова не работает? Оставляя в стороне вещи с типом контента, старые версии Flash (более поздние версии flash имеют модель кросс-домиановского управления - но она отличается от HTML5) - как насчет контрабанды с помощью jar -pseudo-flaw.net/content/web-browsers/corrupted-jars (Java выполняется в активном контексте, но может вызывать JavaScript в пассивном контексте). Затем существуют атаки повторного связывания DNS и атаки MITM.
 djsmith06 дек. 2013 г., 16:00
Плагины браузера могут читать ваш файл CSRF и отправлять любой заголовок, который они хотят, так что даже стандартные механизмы принудительного применения CSRF уязвимы для вредоносного плагина браузера.
 djsmith13 июн. 2012 г., 14:34
Тот факт, что служба использует HTTP, не делает ее уязвимой для CSRF. Можете ли вы определить фактический вектор атаки CSRF, к которому эта служба, как описано, уязвима? И, конечно же, я не думаю, что браузер - это единственный способ сделать HTTP-запрос, но браузер - это наиболее распространенный (только?) Способ заставить пользователя сделать поддельный межсайтовый запрос, который он не сделал. ожидать.
 02 мар. 2013 г., 16:15
@symcbean: Не могли бы вы опубликовать ссылки или иным образом защитить свой ответ? Я не голосовал по этому ответу, я хотел бы, чтобы вы сначала ответили. Благодарю.
 djsmith13 июн. 2012 г., 15:11
Другими словами, покажите мне конкретный вектор атаки CSRF, который использует PUT, чтобы заставить пользователя отправить запрос PUT в мой веб-сервис (как описано). Я считаю, что это невозможно.

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

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

 07 мар. 2018 г., 23:38
В этом нет необходимости. Если сервер читает запросы открытого текста как JSON, формы, закодированной как открытый текст, достаточно, чтобы подделать такой запрос, как упоминал Гамбо. Серверы API должны просто отклонять запросы открытого текста.

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

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

Это также работает на Chrome.

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

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

 07 мар. 2018 г., 23:35
По словам самого автора, & # x201C;I don't think any modern browsers have this flaw anymore& # X201D ;.
 07 мая 2015 г., 04:46
Это работает только в том случае, если объект верхнего уровня, возвращаемый API, является массивом JSON, поскольку Javascript позволяет переопределить конструктор Array. Объект верхнего уровня безопасен. Больше наflask.pocoo.org/docs/0.10/security/#json-security.

Ваш ответ на вопрос