Возможна ли CSRF с помощью методов PUT или DELETE?

Ответ 1

Отличный вопрос!

В идеальном мире я не могу придумать способ совершить атаку CSRF.

• Вы не можете делать запросы PUT или DELETE с использованием HTML-форм.
• Изображения, теги Script, ссылки CSS и т.д. все отправляют запросы GET на сервер.
• XmlHttpRequest и плагины браузера, такие как Flash/Silverlight/Applets, будут блокировать междоменные запросы.

Таким образом, в общем случае не должно быть возможным сделать атаку CSRF ресурсу, который поддерживает команды PUT/DELETE.

Тем не менее мир не совершенен. Может быть несколько способов, в которых такая атака может быть сделана возможной:

• Веб-платформы, такие как Rails, поддерживают "псевдо-метод". Если вы поместите скрытое поле под названием _method, установите его значение PUT или DELETE, а затем отправьте запрос GET или POST, он переопределит HTTP-глагол. Это способ поддержки PUT или DELETE из форм браузера. Если вы используете такую ​​структуру, вам придется защитить себя от CSRF, используя стандартные методы.

• Вы можете случайно настроить слабые заголовки ответов для CORS на своем сервере. Это позволит произвольным веб-сайтам делать запросы PUT и DELETE.

• В какой-то момент HTML5 планировал включить поддержку PUT и DELETE в HTML Forms. Но позже они удалили эту поддержку. Нет гарантии, что он не будет добавлен позже. Некоторые браузеры могут фактически поддерживать эти глаголы, и это может работать против вас.

• В некоторых плагинах браузера может быть ошибка, которая может позволить злоумышленнику делать запросы PUT/DELETE.

Короче говоря, я бы рекомендовал защитить ваши ресурсы, даже если они поддерживают только методы PUT и DELETE.

Ответ 2

Нет. Опираясь на HTTP-глагол, вы не можете предотвратить атаку CSRF. Все это в том, как создается ваш сайт. Вы можете использовать PUT как POST и DELETE как GET - это не имеет большого значения.

Чтобы предотвратить CSRF, выполните следующие шаги здесь:

На веб-сайтах доступны различные контрмеры CSRF:

• Требование секретного токена пользователя для всех форм и побочных URL-адресов предотвращает CSRF; сайт злоумышленника не может поставить правый токен в своих сообщениях 1
• Требование клиента предоставить данные аутентификации в том же HTTP-запросе, который используется для выполнения любой операции с безопасностью последствия (денежный перевод и т.д.).
• Ограничение срока службы файлов cookie сеанса Проверка заголовка HTTP-ссылки или (и)
• Проверка заголовка HTTP-заголовка [16]
• Обеспечение отсутствия файла clientaccesspolicy.xml, предоставляющего непреднамеренный доступ к элементам управления Silverlight [17]
• Обеспечение отсутствия файла crossdomain.xml, предоставляющего непреднамеренный доступ к Flash-фильмам [18]
• Проверка того, что заголовок запроса содержит запрос X-Requested-With. Используется Ruby on Rails (до версии 2.0) и Django (до версии 1.2.5). Эта защита оказалась небезопасной [19] в сочетании плагины браузера и перенаправления, которые могут позволить злоумышленнику предоставлять пользовательские заголовки HTTP по запросу на любой веб-сайт, следовательно разрешить кованый запрос.

Ответ 3

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

Ответ 4

Да, CSRF возможен с помощью методов PUT и DELETE, но только с включенным CORS с неограниченной политикой.

Я не согласен с Ответ Шрипати Кришнана:

XmlHttpRequest и плагины браузера, такие как Flash/Silverlight/Applets блокирует междоменные запросы

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

Если сервер не выбирает CORS, это приведет к выполнению предпродажного запроса. Это механизм, который предотвратит использование PUT или DELETE, потому что это не простой запрос (метод должен быть HEAD, GET или POST). Предположим, что правильно закрытая политика CORS (или вообще не защищена по умолчанию).

Ответ 5

CSRF действительно возможен с PUT и DELETE в зависимости от конфигурации вашего сервера.

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

Если вредоносный веб-сайт выполняет JavaScript-запрос к вашему приложению, браузер отправит стандартные файлы cookie с запросом, что позволит злоумышленнику "подделать" запрос с использованием уже прошедшего проверку сеанса. Этот веб-сайт может выполнять любые запросы, которые он хочет, включая GET, PUT, POST, DELETE и т.д.

Стандартный способ защиты от CSFR - отправить что-то вместе с запросом, который не может знать вредоносный веб-сайт. Это может быть так же просто, как и содержимое одного из файлов cookie. Хотя на запросе с вредоносного сайта будут отправляться куки файлы, он не сможет получить доступ к файлам cookie, потому что он обслуживается другим доменом, и защита браузера не позволяет ему получать доступ к куки файлам для другого домена.

Вызвать содержимое cookie "токеном". Вы можете отправить токен вместе с запросами и на сервере, убедитесь, что "токен" был правильно предоставлен перед продолжением запроса.

Следующий вопрос: как вы отправляете это значение со всеми различными запросами, поскольку DELETE особенно сложно, поскольку он не предназначен для использования какой-либо полезной нагрузки. На мой взгляд, самый чистый способ - указать заголовок запроса с токеном. Что-то вроде этого x-security-token = токена. Таким образом, вы можете посмотреть заголовки входящих запросов и отклонить те, у которых отсутствует токен.

Раньше стандартная защита ajax ограничивала то, что можно было сделать через ajax на вредоносных серверах, однако в настоящее время эта уязвимость зависит от того, как вы настроили свой сервер в отношении конфигураций управления accees. Некоторые люди открывают свой сервер, чтобы упростить возможность перекрестных доменных вызовов или для пользователей создавать свои собственные клиенты RESTful или тому подобное, но также облегчает использование вредоносного сайта, если методы предотвращения CSRF, подобные приведенным выше, не являются положить на место.