Чи вразливі веб-служби 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.

РЕДАГУВАТИ: Додано елемент No4.

РЕДАГУВАТИ: На сьогоднішній день є багато хороших коментарів та відповідей, але ніхто не пропонував конкретної атаки 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.

Можна зробити CSRF на послугах Restful на основі JSON, використовуючи Ajax. Я перевірив це на додатку (використовуючи як 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?