Який сенс заголовка X-Requested-With?


224

JQuery та інші рамки додають такий заголовок:

X-Requested-With: XMLHttpRequest

Для чого це потрібно? Чому сервер хоче обробляти запити AJAX інакше, ніж звичайні запити?

ОНОВЛЕННЯ : Я щойно знайшов приклад із реального життя за допомогою цього заголовка: https://core.spreedly.com/manual/payment-methods/adding-with-js . Якщо платіжний процесор запитується без AJAX, він переспрямовує назад на початковий веб-сайт, коли це буде зроблено. Коли він запитується за допомогою AJAX, перенаправлення не робиться.


7
"[Коли] запитується без AJAX, він переспрямовує назад на початковий веб-сайт, коли це робиться. Коли він запитується з AJAX, перенаправлення не робиться." -> Саме тому ви б хотіли це зробити. :)
— Роберт Крістіан

Відповіді:


257

Важливою причиною є безпека - це може запобігти атакам CSRF, оскільки цей заголовок не може бути доданий до міждоменного запиту AJAX без згоди сервера через CORS .

Між доменними заголовками дозволено використовувати лише такі заголовки:

  • Прийміть
  • Прийняти мову
  • Мова вмісту
  • Ідентифікатор останньої події
  • Тип вмісту

будь-які інші викликають запит "перед польотом" у веб-переглядачах, що підтримуються CORS.

Без CORS неможливо додати X-Requested-Withзапит XHR для міждоменного домену.

Якщо сервер перевіряє наявність цього заголовка, він знає, що запит не ініціювався з домену зловмисника, який намагався зробити запит від імені користувача за допомогою JavaScript. Це також перевіряє, що запит не був POSTed із звичайної форми HTML, важче переконатися, що він не є крос-доменом без використання лексем. (Однак перевірка Originзаголовка може бути варіантом у підтримуваних браузерах, хоча старі браузери залишатимуть себе вразливими .)

Виявлено новий обхід Flash

Ви можете поєднати це з маркером , оскільки Flash, що працює на Safari на OSX, може встановити цей заголовок, якщо є крок переспрямування . Здається, він також працював на Chrome , але зараз його відновлено. Більш детальна інформація, включаючи різні версії, на які постраждали.

OWASP рекомендую поєднувати це з чеком Origin and Referer :

Ця техніка захисту спеціально обговорюється в розділі 4.3 «Надійна захист» для підробки міжміських запитів. Однак обходи цієї оборони за допомогою Flash були задокументовані ще в 2008 році і знову зовсім недавно в 2015 році Матіасом Карлссоном для використання вад CSRF у Vimeo. Але ми вважаємо, що Flash-атака не може підробити заголовки Origin або Referer, тому перевіряючи їх обоє, ми вважаємо, що ця комбінація перевірок повинна запобігати Flash-обходу CSRF-атак. (ПРИМІТКА. Якщо хтось може підтвердити або спростувати це переконання, будь ласка, повідомте нам про це, щоб ми могли оновити цю статтю)

Однак з причин, про які вже йшлося, перевірка Origin може бути хитрою.

Оновлення

Тут написана більш поглиблена публікація про CORS, CSRF та X-Requested-With .


14
Я не розумію. Що заважає зловмиснику створювати запит і додавати також X-Requested-Withзаголовок?
— Грег

13
@Greg: Веб-переглядач - він не дозволить перехрестити домен.
— SilverlightFox

2
О, я не розумів, що жодна конфігурація CORS не потрібна, якщо ви знаходитесь в одному домені. Це очевидно, хоча коли ти думаєш про це. Дякую !
— Грег

10
@ vol7ron: Ніщо не зупиняє їх, але тоді вони не матимуть файлів cookie жертви у запиті, який перемагає об'єкт, який їх робить. Щоб CSRF досяг успіху, зловмиснику знадобиться браузер автоматично приєднувати файли cookie із запитом, тому без браузера немає атаки CSRF.
— SilverlightFox

3
@ vol7ron: Колишній. CSRF - це заплутана депутатська проблема. Веб-переглядач є заплутаним заступником і його "обманюють" надсилати файли cookie на запит, який користувач не зробив сам.
— SilverlightFox

25

Обов’язково прочитайте відповідь SilverlightFox. Це підкреслює більш важливу причину.

Причина, головним чином, полягає в тому, що якщо ви знаєте джерело запиту, ви можете трохи налаштувати його.

Наприклад, скажімо, що у вас є веб-сайт, який має багато рецептів. І ви використовуєте користувацьку рамку jQuery для переміщення рецептів у контейнер на основі посилання, яке вони клацають. Посилання може бутиwww.example.com/recipe/apple_pie

Зараз зазвичай це повертає повну сторінку, заголовок, колонтитул, вміст рецептів та оголошення. Але якщо хтось переглядає ваш веб-сайт, частина цих частин уже завантажена. Таким чином, ви можете використовувати AJAX, щоб отримати рецепт, який користувач обрав, але для економії часу та пропускної здатності не завантажуйте заголовок / колонтитул / оголошення.

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

Але простіше просто виявити, що це запит ajax, який робить запит, а потім повертає лише частину даних. Таким чином користувач витрачає меншу пропускну здатність, і сайт виглядає більш чуйним.

Каркаси просто додають заголовок, тому що деяким може бути корисним відслідковувати, які запити є ajax, а які ні. Але цілком залежить від розробника використовувати такі методи.

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


30
Нічого собі, це звучить як жахливий кошмар з обслуговування. Якщо ви хочете повернути інше представлення однієї сторінки, вам слід надати інший тип вмісту в Acceptзаголовку. Використання нестандартного заголовка для цього звучить як неправильний шлях.
— Гілі

10

Деякі фреймворки використовують цей заголовок для виявлення запитів xhr, наприклад, захист пружини весілля використовує цей заголовок для ідентифікації запиту xhr та надання відповіді json або html-відповіді як відповіді.

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

Джерело: http://grails-plugins.github.io/grails-spring-security-core/guide/helperClasses.html

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.