Комментарии 31
Вопрос сразу и «в лоб», а зачем Вы потенциально опасное действие «dropme» передаете в виде адреса или параметра GET (если используется mod-rewrite)?
Не лучше ли воспользоваться POST-запросом? Тогда и «встраивание» в img не будет работать.
Не лучше ли воспользоваться POST-запросом? Тогда и «встраивание» в img не будет работать.
НЛО прилетело и опубликовало эту надпись здесь
Я то это знаю, но тем не менее многие этого не знают и так делают.
+Данная библиотека защищает не только от опасных действий но и от вытаскивания контента страницы ( например с персональными данными пользователя), например в iframe или в div с помощью $('div.hidden').load('http://example.com/profile/');.
+Данная библиотека защищает не только от опасных действий но и от вытаскивания контента страницы ( например с персональными данными пользователя), например в iframe или в div с помощью $('div.hidden').load('http://example.com/profile/');.
Ну… нельзя так категорично рассуждать. Если есть возможность и она себя зарекомендовала, то почему бы ей не пользоваться?
Мне кажется, что с удалением не совсем в кассу пример. Как ни удаляй (аякс либо с перезагрузкой страницы) данные, всё равно было бы неплохо проверить в сессии есть ли у пользователя права на удаление будь это личный эккаунт либо любая другая запись.
Так смысл такой атаки заключается в том что на действие у пользователя есть всё права и он в данный момент авторизован и выполняет это под своим логином и из своей сессии.
Если у пользователя есть действие для удаления собственного аккаунта и права на это, но нет защиты от Cross Site Request — злоумышленнику ничего не мешает это сделать
Если у пользователя есть действие для удаления собственного аккаунта и права на это, но нет защиты от Cross Site Request — злоумышленнику ничего не мешает это сделать
И он одновременно лезет в том же браузере на сайт злоумышленника который производит атаку? Это накладывает ряд ограничений. Тут наиболее уязвимы сайты связанные с соц сетями на атаку от себе подобных, либо какие нибудь аггрегаторы спец предложений туроператоров. Для которых модель поведения типичного пользователя включает вариант открытия сразу нескольких сайтов параллельно, т.о. чтобы и «жертва» и «атакующий» были открыты одновременно.
Два минуса для такого решения:
1. Даёт только снижение уровня угрозы, а не защиту. Всё ещё остаётся возможность просто подсунуть ссылку пользователю.
2. Увеличивается нагрузка.
1. Даёт только снижение уровня угрозы, а не защиту. Всё ещё остаётся возможность просто подсунуть ссылку пользователю.
2. Увеличивается нагрузка.
А почему не использовать токен, как это делается обычно?
Токен, в отличие от вашего решения, позволит защитить не только ajax, но и все другие запросы в одном стиле.
Токен, в отличие от вашего решения, позволит защитить не только ajax, но и все другие запросы в одном стиле.
Если я вас правильно понял, автор отказывается от токена в силу:
Есть готовое приложение в котором уже более 100 ссылок на различные страницы и действия, они выполнены в коде в виде , а не в виде вызова функции с передачей url, соответственно править придется более 100 мест. Есть риск что то забыть.
Разве x-requested-with недостаточно?
СОГЛАСЕН — Проверка HTTP_REFERER — простое и удобное решение!
А в остальном — совершенству нет предела)
Спасибо за интересный пост!)
А в остальном — совершенству нет предела)
Спасибо за интересный пост!)
TL;DR использовать токены
А есть у кого-то класс или библиотека, для легкой организации этих трех китов?
Если есть альтруисты, предлагаю поделиться с хабраюзерами)
Если есть альтруисты, предлагаю поделиться с хабраюзерами)
Вот интересно, есть ли где-нибудь полный перечень того, что должен знать web разработчик о безопасности разрабатываемого приложения? Просто, чтобы идти по пунктам и проверять реализовано ли у тебя и ничего не забыть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Защита ajax-приложения от Cross Site Request атак (CSRF)