Как исправить CSRF в спецификации протокола HTTP?

Question

Какие изменения в спецификации протокола HTTP и поведении браузера потребуются для предотвращения опасных случаев подделки межсайтовых запросов?

Я не ищу предложений по исправлению своего собственного веб-приложения. Существуют миллионы уязвимых веб-приложений и форм. Было бы проще изменить HTTP и / или браузеры.

Если вы согласны с моей предпосылкой, скажите, пожалуйста, какие изменения в поведении HTTP и / или браузера необходимы. Это не конкурс, чтобы найти лучший одиночный ответ, я хочу собрать все хорошие ответы.

Пожалуйста, прочитайте и прокомментируйте пункты в моем «ответе» ниже.

Answer 1

Рой Филдинг, автор спецификации HTTP, не согласен с вашим мнением о том, что CSRF является недостатком HTTP и его необходимо исправить там. Как он написал в ответе в теме с именем Заголовок источника HTTP :

CSRF не является проблемой безопасности для Интернета. Хорошо разработанный Веб сервис должен быть способен принимать запросы, направленные любым хостом, с помощью соответствующей аутентификации, где это необходимо. Если браузеры создать проблему безопасности, потому что они позволяют сценариям автоматически прямые запросы с сохраненными учетными данными безопасности на сторонних сайты, без какого-либо вмешательства пользователя / конфигурации, то очевидное исправление в браузере.

И на самом деле CSRF-атаки были возможны с самого начала с использованием простого HTML. Внедрение современных технологий, таких как JavaScript и CSS, только внедрило новые векторы атак и методы, которые сделали подделку запросов проще и эффективнее.

Но это не изменило того факта, что законный и аутентичный запрос от клиента необязательно основан на намерении пользователя . Потому что браузеры все время отправляют запросы автоматически (например, изображения, таблицы стилей и т. Д.) И отправляют все учетные данные для аутентификации.

Опять же, CSRF-атаки происходят внутри браузера , поэтому единственное возможное исправление - это исправить его там, внутри браузера.

Но поскольку это не совсем возможно (см. Выше), приложение обязано реализовать схему, которая позволяет различать аутентичные и поддельные запросы. Всегда распространяемый CSRF-токен является такой техникой. И он хорошо работает при правильной реализации и защите от других атак (многие из них, опять же, возможны только благодаря внедрению современных технологий).

Answer 2

Я согласен с двумя другими; это может быть сделано на стороне браузера, но сделает невозможным выполнение авторизованных межсайтовых запросов. В любом случае, уровень защиты CSRF может быть добавлен довольно легко на стороне приложения (и, возможно, даже на стороне веб-сервера, чтобы избежать внесения изменений в уже существующие приложения), используя что-то вроде этого:

• Для файла cookie установлено случайное значение, известное только серверу (и, разумеется, клиенту, получающему его, но не стороннему серверу)
• Каждая форма POST должна содержать скрытое поле, значение которого должно совпадать с cookie. В противном случае отправка формы должна быть предотвращена, и пользователю должна быть возвращена страница 403.

Answer 3

Уже можно сделать:

Referer заголовок

Это более слабая форма защиты. Некоторые пользователи могут отключить referer в целях конфиденциальности, что означает, что они не смогут отправлять такие формы на вашем сайте. Также это может быть сложно реализовать в коде. Некоторые системы позволяют URL-адресу, например http://example.com?q=example.org, проходить проверку реферера для example.org. Наконец, любые уязвимости открытого перенаправления на вашем сайте могут позволить злоумышленнику отправить свою CSRF-атаку через открытое перенаправление, чтобы получить правильный заголовок referer.

Origin заголовок

Это новый заголовок. К сожалению, вы получите несоответствия между браузерами, которые его поддерживают и не поддерживают. См. Этот ответ .

Другие заголовки

Только для запросов AJAX, добавление заголовка, который не разрешен для междоменной области, например X-Requested-With, может использоваться в качестве метода предотвращения CSRF. Старые браузеры не будут отправлять междоменный домен XHR, а новые браузеры будут вместо этого отправлять предварительную проверку CORS, а затем отказываться делать основной запрос, если он явно не разрешен целевым доменом. Код на стороне сервера должен гарантировать, что заголовок все еще присутствует при получении запроса. Поскольку в формы HTML нельзя добавлять пользовательские заголовки, этот метод несовместим с ними. Однако это также означает, что он защищает от злоумышленников, использующих форму HTML в своей CSRF-атаке.

Браузеры

Браузеры, такие как Chrome , позволяют блокировать сторонние файлы cookie . Несмотря на то, что в объяснении говорится, что он будет препятствовать установке файлов cookie сторонним доменом, он также предотвращает отправку любых существующих файлов cookie для запроса. Это заблокирует «фоновые» CSRF-атаки. Тем не менее, те, которые открывают полную страницу или всплывающее окно, будут успешными, но будут более видимыми для пользователя.

Answer 4

• куки должны быть объявлены как «локальные» (по умолчанию) или «удаленные»
• браузер не должен отправлять «локальные» куки-файлы с межсайтовым запросом
• браузер никогда не должен отправлять заголовки http-auth с межсайтовым запросом
• браузер не должен отправлять межсайтовый POST или GET? Запрос без разрешения
• браузер не должен отправлять запросы адресов локальной сети с удаленной страницы без разрешения
• браузер должен сообщать и контролировать атаки, когда выполняется много межсайтовых запросов
• браузер должен отправить «Origin: (local | remote)», даже если «Referer» отключен
• другие распространенные проблемы веб-безопасности, такие как XSHM, должны быть рассмотрены в спецификации HTTP
• необходим новый протокол HTTP версии 1.2, чтобы показать, что браузер соответствует
• браузеры должны автоматически обновляться в соответствии с новыми требованиями безопасности или предупреждать пользователя

Answer 5

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

Однако это слабая форма защиты. Такая уязвимость, как разделение HTTP-ответов на стороне клиента, может быть использована для влияния на значение referer, и это произошло.

Answer 6

Принять ту же политику происхождения для местоположений отправки формы. Разрешить отправлять форму только туда, откуда она пришла.

Это, конечно, сломало бы все другие вещи.