Защита ajax-приложения от Cross Site Request атак (CSRF)

[@TimID]

Вопрос сразу и «в лоб», а зачем Вы потенциально опасное действие «dropme» передаете в виде адреса или параметра GET (если используется mod-rewrite)?
Не лучше ли воспользоваться POST-запросом? Тогда и «встраивание» в img не будет работать.

[@piromanlynx]

Делать можно и POST-ом, но это не спасёт от post запроса с помощью ajax с другого сайта.

[@piromanlynx]

Спасибо! только где он пишется? что то я не вижу этого в коде библиотеке и похоже на дефолтное значение которое подсовывает Ваш браузер…

[@TheShock]

afaik, если создать <form> в iframe и там сделать submit, то ошибки same origin policy не будет.

[@barmaley_exe]

От фреймов не спасёт.

[@piromanlynx]

Я то это знаю, но тем не менее многие этого не знают и так делают.

+Данная библиотека защищает не только от опасных действий но и от вытаскивания контента страницы ( например с персональными данными пользователя), например в iframe или в div с помощью $('div.hidden').load('http://example.com/profile/');.

[@TheShock]

Данные нельзя вытащить согласно запрету «same origin policy»

[@sectus]

Ну… нельзя так категорично рассуждать. Если есть возможность и она себя зарекомендовала, то почему бы ей не пользоваться?

[@sectus]

Ну вот, так всегда:
> Методом GET нельзя менять состояние.
> Нарушать *базовые* правила можно…

[@volhovec]

Мне кажется, что с удалением не совсем в кассу пример. Как ни удаляй (аякс либо с перезагрузкой страницы) данные, всё равно было бы неплохо проверить в сессии есть ли у пользователя права на удаление будь это личный эккаунт либо любая другая запись.

[@piromanlynx]

Так смысл такой атаки заключается в том что на действие у пользователя есть всё права и он в данный момент авторизован и выполняет это под своим логином и из своей сессии.

Если у пользователя есть действие для удаления собственного аккаунта и права на это, но нет защиты от Cross Site Request — злоумышленнику ничего не мешает это сделать

[@volhovec]

И он одновременно лезет в том же браузере на сайт злоумышленника который производит атаку? Это накладывает ряд ограничений. Тут наиболее уязвимы сайты связанные с соц сетями на атаку от себе подобных, либо какие нибудь аггрегаторы спец предложений туроператоров. Для которых модель поведения типичного пользователя включает вариант открытия сразу нескольких сайтов параллельно, т.о. чтобы и «жертва» и «атакующий» были открыты одновременно.

[@SergeiStartsev]

К слову, это довольно распространенная ситуация и здесь вовсе необязательно, чтобы все сайты были явно открыты у пользователя, есть такая штука как куки и храниться они могут долго.

[@sectus]

Два минуса для такого решения:

1. Даёт только снижение уровня угрозы, а не защиту. Всё ещё остаётся возможность просто подсунуть ссылку пользователю.
2. Увеличивается нагрузка.

[@zerkms]

А почему не использовать токен, как это делается обычно?

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

[@zona7o]

Если я вас правильно понял, автор отказывается от токена в силу:

Есть готовое приложение в котором уже более 100 ссылок на различные страницы и действия, они выполнены в коде в виде , а не в виде вызова функции с передачей url, соответственно править придется более 100 мест. Есть риск что то забыть.

[@zerkms]

А, и вправду.

Позволю себе перефразировать: вместо того, чтобы использовать проверенные временем решения — давайте выдумаем что-нибудь новое, а то с проверенными можем ошибиться

[@piromanlynx]

Это не новое — это ровно то же токен, только токен передается не в тексте url, а в заголоке.

[@zerkms]

Ох, пардон, прочитал невнимательно код :-S Почему-то думал что там просто передаётся флажок :-( Простите

[@Nikitian]

Разве x-requested-with недостаточно?

[@torrison]

СОГЛАСЕН — Проверка HTTP_REFERER — простое и удобное решение!

А в остальном — совершенству нет предела)

Спасибо за интересный пост!)

[@torrison]

Согласен, от роботов защищаться надо и token нужен.

Итого:

Безопасный AJAX:

1) HTTP_REFERER
2) token
3) Защита от роботов

Верно?

[@Raz0r]

TL;DR использовать токены

[@torrison]

А есть у кого-то класс или библиотека, для легкой организации этих трех китов?

Если есть альтруисты, предлагаю поделиться с хабраюзерами)

[@Argnist88]

Вот интересно, есть ли где-нибудь полный перечень того, что должен знать web разработчик о безопасности разрабатываемого приложения? Просто, чтобы идти по пунктам и проверять реализовано ли у тебя и ничего не забыть.