REFERER как защита от CSRF

[pento]

Всем привет!
Анализируя очерендное веб-приложение на предмет уязвимостей, столкнулся с тем, что проверяется REFERER перед обработкой данный критичных операций. Конретно проверяется протокол + хост.При этом других защитных мер от CSRF нет. Вопрос, можно ли обойти подобную защиту? Погуглив, нашёл только варианты с Flash и то старых версий.

[warlok]

Можно конечно, подделав рефер на нужный тебе. Например через RefControl (плагин для мазилы) ну или самому состряпать скриптик что впринципе и войдет в сплойт для твоей CSRF баги.

[pento]

Можно конечно, подделав рефер на нужный тебе. Например через RefControl (плагин для мазилы) ну или самому сострямать скриптик что впринципе и войдет в сплойт для твоей CSRF баги.
Хммм, я поясню. CSRF - уязвимость, где веб-браузер жертвы посылает злонамеренный HTTP-запрос. То есть подобных плугинов у жертвы, само собой, нет. Старые варианты по сути эксплуатировали уязвимости браузера (IE) и flash-дополнения.

[warlok]

CSRF - уязвимость, где веб-браузер жертвы посылает злонамеренный HTTP-запрос
хм, а разве если ты сам подделываеш и отсылаеш запрос (например на добавление нового админа или смены пароля) неявляеться CSRF ? а так получаеться что нужно копать в сторону подделки рефера на js, а так я чесно незнаю даж как реализовать.

[Shred]

jQuery Ajax Header пробовал?
http://docs.jquery.com/Ajax
http://snipplr.com/view/9869/set-jquery-ajax-header/

[[Raz0r]]

Если имеется CSRF без XSS, то защита с помощью проверки referer является довольно надежной, хотя подделка этого заголовка в обычных условиях труда не составляет.

[pento]

']Если имеется CSRF без XSS, то защита с помощью проверки referer является довольно надежной, хотя подделка этого заголовка в обычных условиях труда не составляет.
В том-то и прикол, что бы без XSS :) А что значит обычные условия?
Просто основным методом защиты от CSRF является использование токенов, то есть фактически подписывание запросов. Проверка REFERER обычно упоминается всколзь и делается упор на то, что он является не совсем надёжным фактором подтверждения отправителя HTTP-запроса. Ну и упоминаются ранее мной озвученные методы его подмены, но те баги уже зафиксены вроде как.

[pento]

хм, а разве если ты сам подделываеш и отсылаеш запрос (например на добавление нового админа или смены пароля) неявляеться CSRF ? а так получаеться что нужно копать в сторону подделки рефера на js, а так я чесно незнаю даж как реализовать.
Рекомендую почитать http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

[pento]

jQuery Ajax Header пробовал?
http://docs.jquery.com/Ajax
http://snipplr.com/view/9869/set-jquery-ajax-header/
Хммм, по идеи аякс не должен такое позволять делать, но посмотрю.
Спасибо.

[[Raz0r]]

Под обычными условиями я имел в виду, что referer можно изменить, отправляя запрос самому, но не при автоматическом обращении браузера по разным адресам, указанных в атрибуте src тэгов iframe, img и т.д.
он является не совсем надёжным фактором подтверждения отправителя HTTP-запроса
Действительно так, например, в ситуации, когда у обычного пользователя и администратора есть доступ к одной странице, но ее функционал зависит от привилегий пользователя, то защита по referer не спасет, здесь применимы только токены.

[pento]

']Под обычными условиями я имел в виду, что referer можно изменить, отправляя запрос самому,...
Ну это и так понятно :) У меня была ещё надежда, что там проверка на реферер вида поиск подстроки имени хоста в реферере. Тогда возможно было бы зарегать домен вида victim.com.evil.ch и на него уже пользователя заманивать и слать запросы...

[diehard]

Страница бредятины. pento, если проверка реферера, то csrf не пройдет.

[[Raz0r]]

Ну это и так понятно :) У меня была ещё надежда, что там проверка на реферер вида поиск подстроки имени хоста в реферере. Тогда возможно было бы зарегать домен вида victim.com.evil.ch и на него уже пользователя заманивать и слать запросы...
В таком случае можно бы было и не в имени домена:
http://attacker.com/www.victim.com/admin.php?csrf