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

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

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

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

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

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

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

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

Рекомендую почитать http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

Хммм, по идеи аякс не должен такое позволять делать, но посмотрю.
Спасибо.

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