Не проблема CSRF в безопасности браузера?

Question

Что касается атак с подделкой запросов на межсайтовый запрос (CSRF), если куки-файлы наиболее часто используются методом проверки подлинности, почему веб-браузеры позволяют отправлять файлы cookie какого-либо домена (и в этот домен) со страницы, сгенерированной из другого домена?

Не может ли CSRF легко предотвращаться в браузере, запретив такое поведение?

Насколько я знаю, такая проверка безопасности не реализована в веб-браузерах, но я не понимаю, почему. У меня что-то не так?

О CSRF:

• On wikipedia
• On coding horror

Edit: Я думаю, что печенье не должно быть отправлено на HTTP POST, в описанном выше случае. Это поведение браузера меня удивляет.

Answer 1

Почему браузер не будет отправлять файлы cookie?

Сайт A (http://www.sitea.com) устанавливает cookie для пользователя. (http://www.siteb.com). Сайт B интегрируется с сайтом A - нажмите здесь, чтобы что-то сделать на сайте A! Пользователи нажимают «здесь».

Что касается браузера, пользователь принимает осознанное решение сделать запрос на сайт A, поэтому он обрабатывает его так же, как обрабатывает любой запрос на сайт A, и который включает отправку сайта. Файлы cookie в запросе на сайт А.

---

Edit: Я думаю, что главная проблема в том, что вы думаете, существует различие между печеньем аутентификации и других печеньем. Куки-файлы можно использовать для хранения любых вещей - предпочтений пользователя, последнего последнего балла или токена сеанса. Браузер не знает, для чего используется каждый cookie. I хочу мои файлы cookie всегда будут доступны на сайте, который их установил, и я хочу, чтобы сайт удостоверился, что он принимает необходимые меры предосторожности.

Или вы говорите, что если вы ищете Yahoo для «Gmail», а затем нажмите на ссылку, которая приведет вас к http://mail.google.com, вы не должны войти в систему, даже если вы сказали Gmail, чтобы держать вас вошли в , потому что вы нажали на ссылку с другого сайта?

Answer 2

Это не значит, что браузер отправляет файл cookie в или из внешнего домена, это факт, что вы прошли аутентификацию и сайт не проверяет источник запроса, поэтому он обрабатывает его так, как будто запрос пришел с сайта.

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

Редактировать: чтобы быть ясным, ваш файл cookie не отправляется через домены.

Answer 3

Я не знаю, что в этой ситуации браузер может многое сделать, поскольку точка атаки XSRF направляет браузер на другую точку приложения, которая будет выполнять что-то плохое. К сожалению, браузер не знает, является ли запрос, на который он направлен для отправки, злонамерен или нет. Например, учитывая классический пример XSRF:

<img src="http://domain.com/do_something_bad" /> 

это не очевидно для браузера, что-то плохое происходит. В конце концов, как узнать разницу между этим:

<img src="http://domain.com/show_picture_if_authenticated" /> 

Answer 4

Многие старые протоколы имеют большие дыры в безопасности - вспомните недавно обнаруженный DNS vulnerabilities. Как и в случае любой сетевой безопасности, это ответственность конечных точек; да, это отстой, что мы должны исправить это сами, но гораздо сложнее исправить ситуацию на уровне браузера. Есть некоторые очевидные (< img src = "logoff.php" > выглядит чертовски подозрительно, правда?), Но всегда будут случаи кросс. (Может быть, это скрипт GD в PHP-файле). Как насчет запросов AJAX? И так далее ...

Answer 5

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

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

I.e., пользователь выполняет действие, и злоумышленник обманул пользователя в этом.

Answer 6

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

Смотреть это:

http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html

Это обзор предложения для нового заголовка HTTP, чтобы помочь смягчить CSRF атак.

Предлагаемое название заголовка «Происхождение» и это в основном «Referer» заголовок минус путь и т.д.