Разве CSRF не является проблемой безопасности браузера?
Что касается атак подделки межсайтовых запросов (CSRF), если файлы cookie являются наиболее часто используемым методом проверки подлинности, почему веб-браузеры позволяют отправлять файлы cookie некоторого домена (и в этот домен) со страницы, созданной из другого домена?
Разве CSRF легко предотвратить в браузере, запретив такое поведение?
Насколько я знаю, такая проверка безопасности не реализована в веб-браузерах, но я не понимаю, почему. Я что-то не так понял?
О ЦСРФ:
Изменить: Я думаю, что куки не должны отправляться на HTTP POST в вышеуказанном случае. Такое поведение браузера меня удивляет.
6 ответов
Почему браузер не отправляет куки?
Сайт A ( http://www.sitea.com/) устанавливает cookie для пользователя.
Пользователь переходит на сайт B ( http://www.siteb.com/). Сайт B поддерживает интеграцию с сайтом A - нажмите здесь, чтобы что-то сделать на сайте A! Пользователи нажимают "здесь".
Насколько может судить браузер, пользователь принимает сознательное решение сделать запрос к сайту A, поэтому он обрабатывает его так же, как обрабатывает любой запрос к сайту A, и это включает отправку файлов cookie сайта A в запросе на сайт А.
Изменить: я думаю, что главная проблема здесь заключается в том, что вы думаете, что есть различие между куки-файлами аутентификации и другими куки-файлами. Файлы cookie могут использоваться для хранения чего угодно - пользовательских настроек, вашего последнего рекорда или токена сеанса. Браузер не знает, для чего используется каждый файл cookie. Я хочу, чтобы мои куки всегда были доступны для сайта, который их устанавливает, и я хочу, чтобы сайт принимал необходимые меры предосторожности.
Или вы говорите, что если вы ищете yahoo "gmail", а затем нажимаете на ссылку, которая ведет на http://mail.google.com/, вы не должны входить в систему, даже если вы сказали, чтобы gmail держал вас вошли в систему, потому что вы нажали на ссылку с другого сайта?
Дело не в том, что браузер отправляет cookie-файлы на внешний домен или с него, а в том, что вы прошли проверку подлинности, а сайт не проверяет источник запроса, поэтому он обрабатывает его так, как если бы запрос поступил из сайт.
Насколько браузер должен запретить это... как насчет многих ситуаций, когда межсайтовые запросы желательны?
Изменить: чтобы быть понятным, ваш файл cookie не распространяется между доменами.
Я не знаю, что браузер может многое сделать в этой ситуации, поскольку цель атаки XSRF - направить браузер в другую точку приложения, которая будет выполнять что-то плохое. К сожалению, браузер не знает, является ли запрос, на который он направлен, вредоносным или нет. Например, приведенный классический пример XSRF:
<img src="http://domain.com/do_something_bad" />
браузеру не очевидно, что происходит что-то плохое. В конце концов, как узнать разницу между этим и этим:
<img src="http://domain.com/show_picture_if_authenticated" />
Многие старые протоколы имеют большие дыры в безопасности - вспомните недавно обнаруженные уязвимости DNS. Как и в основном любая сетевая безопасность, это ответственность конечных точек; да, это отстой, что мы должны исправить это сами, но это намного сложнее исправить на уровне браузера. Есть некоторые очевидные ( выглядит чертовски подозрительно, правда?), Но всегда будут крайние случаи. (Возможно, это все-таки GD-скрипт в PHP-файле.) А как насчет запросов AJAX? И так далее...
Файлы cookie для сайта никогда не отправляются на другой сайт. Фактически, для реализации успешной CSRF-атаки злоумышленнику не требуется доступ к этим файлам cookie.
По сути, злоумышленник обманывает пользователя, который уже вошел на целевой веб-сайт, в нажатие на ссылку или загрузку изображения, которое будет что-то делать на целевом сайте с учетными данными этого пользователя.
То есть пользователь выполняет действие, а злоумышленник обманул его.
Некоторые люди говорят, что не думают, что браузер может многое сделать.
Видеть это:
http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html
Это обзор предложения о новом заголовке HTTP, чтобы помочь смягчить атаки CSRF.
Предложенное имя заголовка - "Origin", и это в основном заголовок "Referer" минус путь и т. Д.