Какой смысл в заголовке X-Requested-With?

Question

Какой смысл в заголовке X-Requested-With?

133

JQuery и другие фреймворки добавляют следующий заголовок:

X-Requested-With: XMLHttpRequest

Зачем это нужно? Почему сервер хочет обрабатывать запросы AJAX иначе, чем обычные запросы?

UPDATE. Я просто нашел пример в реальном времени, используя этот заголовок: https://core.spreedly.com/manual/payment-methods/adding-with-js. Если процессор платежей запрашивается без AJAX, он перенаправляет обратно на исходный веб-сайт, когда он будет выполнен. Когда он запрашивается с AJAX, перенаправление не выполняется.

Gili 04 июль 2013, в 21:48

Источник

5

«[Когда] запрашивается без AJAX, он перенаправляется обратно на исходный веб-сайт, когда это сделано. Когда его запрашивают с помощью AJAX, перенаправление не выполняется». -> Именно поэтому вы хотели бы сделать это. :)
Robert Christian 08 апр. 2014, в 19:32
0

stackoverflow.com/questions/3315914/...
Ciro Santilli 新疆改造中心六四事件法轮功 15 май 2016, в 08:01

Теги:

jquery

ajax

http-headers

cors

3 ответа

16

Убедитесь, что вы прочитали ответ SilverlightFox. Это подчеркивает более важную причину.

Причина в том, что, если вы знаете источник запроса, вы можете немного его настроить.

Например, скажем, у вас есть веб-сайт с множеством рецептов. И вы используете настраиваемую среду jQuery для перетаскивания рецептов в контейнер на основе ссылки, которую они нажимают. Ссылка может быть www.example.com/recipe/apple_pie

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

Теперь вы можете просто написать вторичную конечную точку для данных типа www.example.com/recipe_only/apple_pie, но это сложнее поддерживать и делиться с другими людьми.

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

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

На самом деле это похоже на заголовок Accept-Language. Браузер может запросить веб-сайт, пожалуйста, покажите мне английскую версию этого веб-сайта без необходимости вставлять/ru/или подобное в URL-адрес.

EWit 04 июль 2013, в 23:46

25

Вау, это звучит как ужасный кошмар обслуживания. Если вы хотите вернуть другое представление одной и той же страницы, вы должны указать другой тип контента для заголовка Accept . Использование собственного заголовка для этого звучит как неправильный путь.
Gili 06 июль 2013, в 01:52

5

Некоторые фреймворки используют этот заголовок для обнаружения запросов xhr, например. grails spring использует этот заголовок для идентификации запроса xhr и дает ответ json или html-ответ в качестве ответа.

Большинство библиотек Ajax (Prototype, JQuery и Dojo от версии 2.1) включают заголовок X-Requested-With, который указывает, что запрос был сделан с помощью XMLHttpRequest вместо запуска, щелкнув регулярную гиперссылку или отправить форму кнопка.

Источник: http://grails-plugins.github.io/grails-spring-security-core/guide/helperClasses.html

Koray Güclü 28 янв. 2015, в 10:21

Ещё вопросы

«[Когда] запрашивается без AJAX, он перенаправляется обратно на исходный веб-сайт, когда это сделано. Когда его запрашивают с помощью AJAX, перенаправление не выполняется». -> Именно поэтому вы хотели бы сделать это. :)
Вау, это звучит как ужасный кошмар обслуживания. Если вы хотите вернуть другое представление одной и той же страницы, вы должны указать другой тип контента для заголовка Accept . Использование собственного заголовка для этого звучит как неправильный путь.

SilverlightFox · Accepted Answer · 2014-03-20T13-24-00.000Z

Хорошая причина для безопасности - это может предотвратить атаки CSRF, потому что этот заголовок не может быть добавлен в кросс-домен запроса AJAX без согласие сервера через CORS.

Разрешены только следующие заголовки:

Принять

Accept-Language

Content-Language

Last-Event-ID

Content-Type

любые другие вызывают запрос "перед полетом" в браузерах, поддерживаемых CORS.

Без CORS невозможно добавить X-Requested-With к запросу XHR с кросс-доменом.

Если сервер проверяет наличие этого заголовка, он знает, что запрос не инициировал из домена злоумышленника попытку сделать запрос от имени пользователя с помощью JavaScript. Это также проверяет, что запрос не был отправлен из обычной HTML-формы, из которых сложнее проверить, что это не перекрестный домен без использования токенов. (Тем не менее проверка заголовка Origin может быть опцией в поддерживаемых браузерах хотя вы оставите старые браузеры уязвимы.)

Обнаружен новый обход флагов

Вы можете пожелать объединить это с токеном, поскольку Flash, работающий в Safari на OSX может установите этот заголовок, если есть шаг перенаправления. Он выглядит он также работал в Chrome, но теперь исправлен. Подробнее здесь, включая различные версии.

OWASP Рекомендовать сочетать это с проверкой Origin and Referer:

Этот метод защиты специально обсуждается в разделе 4.3 Надежная защита для кросс-сайта. Однако обход эта защита с использованием Flash была зарегистрирована еще в 2008 году и снова как недавно в 2015 году Матиас Карлссон использовал недостаток CSRF в Вимео. Но мы считаем, что Flash-атака не может подделать Origin или Заголовки отправителей, поэтому, проверяя их оба, мы считаем, что это комбинация проверок должна предотвращать атаки CSRF с помощью обхода байпаса. (ЗАМЕТКА: Если кто-то может подтвердить или опровергнуть это убеждение, сообщите нам, чтобы мы может обновить эту статью)

Однако по причинам, которые уже обсуждались, проверка Origin может быть сложной.

Update

Написано более подробное сообщение в блоге CORS, CSRF и X-Requested-With здесь.

Я не понимаю Что мешает злоумышленнику создать запрос и добавить заголовок X-Requested-With ?
@Greg: браузер - он не разрешает междоменный.
О, я не знал, что конфигурация CORS не понадобится, если вы находитесь в одном домене. Это очевидно, хотя, когда вы думаете об этом. Спасибо !
Это все еще очень раздражает, потому что нарушает простую настройку CORS, которая не требует предварительного запроса OPTIONS, если нет дополнительных заголовков. Я считаю это ошибкой, и мне пришлось патчить jQuery, чтобы не добавлять его.
@SilverlightFox, так что же мешает кому-то делать запросы вне браузера?
@ vol7ron: Ничто не останавливает их, но тогда у них не будет печенья их жертвы в запросе, который побеждает объект их выполнения. Для успешного выполнения CSRF злоумышленнику потребуется браузер, который автоматически прикрепляет файлы cookie с запросом, поэтому без использования браузера атака CSRF невозможна.
@ SilverlightFox, нет, я говорю о том, что кажется, что безопасность обеспечивается не на сервере, а на клиенте. Является ли смысл предотвращать запуск клиентом неверного внешнего кода или запретить клиенту доступ к контенту, к которому ему нельзя разрешить доступ? Это имеет смысл для первого вопроса, но последний должен применяться на уровне сервера, а не доверять браузеру - любой может раскошелиться / создать браузер и снять ограничения безопасности.
@ vol7ron: бывший. CSRF - запутанная депутатская проблема. Браузер - запутанный заместитель и «обманут», отправляя куки-файлы для запроса, который пользователь не сделал самостоятельно.
Кстати, вы можете изменить значение заголовка X-Requested-With в jQuery.ajax с помощью параметра «header», чтобы сделать его более безопасным. Затем проверьте это значение на стороне сервера. api.jquery.com/jquery.ajax
Зачем нам нужны токены CSRF в дополнение к этому? Не будет ли проверка этого заголовка достаточной для предотвращения CSRF?
@ciro Нет, если только во Flash (или подобном плагине) нет другой ошибки, которая позволяет устанавливать произвольные заголовки, обходя обычные ограничения браузера.
Где эти разрешенные заголовки задокументированы? Я вижу только черный список на w3.org/TR/XMLHttpRequest/#the-setrequestheader%28%29-method и xhr.spec.whatwg.org/#the-setrequestheader%28%29-method
@CiroSantilli Панамские документы, четвертое событие Фалуньгун: Я верю, что здесь , хотя я верю, что во время реализации были сделаны некоторые изменения для поддержки других заголовков, таких как Last-Event-ID .