Jaki jest sens nagłówka X-Requested-With?

Question

Jaki jest sens nagłówka X-Requested-With?

JQuery i inne frameworki dodają następujący nagłówek:

X-Requested-With: XMLHttpRequest

Dlaczego jest to potrzebne? Dlaczego serwer chciałby traktować żądania AJAX inaczej niż zwykłe żądania?

UPDATE : właśnie znalazłem prawdziwy przykład używając tego nagłówka: https://core.spreedly.com/manual/payment-methods/adding-with-js . Jeśli procesor płatności jest żądany bez AJAX, przekierowuje z powrotem do oryginału strona po zakończeniu. Gdy jest wymagane z AJAX, nie jest wykonywane przekierowanie.

243

jquery ajax http-headers cors

Author: R andom, 2013-07-04

Source

3 answers

Upewnij się, że przeczytałeś odpowiedź SilverlightFox. Podkreśla ważniejszy powód.

Powodem jest głównie to, że jeśli znasz źródło żądania, możesz chcieć go trochę dostosować.

Na przykład powiedzmy, że masz stronę internetową, która ma wiele przepisów. Używasz niestandardowego frameworka jQuery do przesuwania przepisów do kontenera na podstawie klikniętego łącza. Link może być www.example.com/recipe/apple_pie

Teraz normalnie zwraca pełną stronę, nagłówek, stopkę, zawartość przepisu i reklamy. Ale jeśli ktoś przegląda Twoją stronę, niektóre z tych części są już załadowane. Możesz więc użyć AJAX, aby uzyskać przepis wybrany przez użytkownika, ale aby zaoszczędzić czas i przepustowość, nie ładuj nagłówka / stopki / reklam.

Teraz możesz po prostu napisać drugorzędny punkt końcowy dla danych, takich jak www.example.com/recipe_only/apple_pie, ale jest to trudniejsze do utrzymania i udostępnienia innym ludziom.

Ale łatwiej jest po prostu wykryć, że jest to żądanie ajax, które składa żądanie, a następnie zwraca tylko część danych. W ten sposób użytkownik marnuje mniej przepustowości, a strona wydaje się bardziej responsywna.

Frameworki po prostu dodają nagłówek, ponieważ niektórzy mogą uznać za przydatne śledzenie, które żądania są Ajaxem, a które nie. Ale to całkowicie zależy od dewelopera, aby używać takich technik.

Jest właściwie podobny do nagłówka Accept-Language. Przeglądarka może zażądać strony internetowej proszę pokazać mi rosyjską wersję tej strony bez konieczności wstawiania /ru / lub podobnego w adresie URL.

26

Author: EWit,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-10-24 07:36:09

Niektóre frameworki używają tego nagłówka do wykrywania żądań xhr, np. grails spring security używa tego nagłówka do identyfikowania żądań xhr i udzielania odpowiedzi json lub html jako odpowiedzi.

Większość bibliotek Ajax (Prototype, JQuery i Dojo od wersji 2.1) zawiera nagłówek X-Requested-With, który wskazuje, że żądanie zostało wykonane przez XMLHttpRequest zamiast być wywołane przez kliknięcie zwykłego hiperłącza lub przycisku Wyślij formularz.

Źródło: http://grails-plugins.github.io/grails-spring-security-core/guide/helperClasses.html

10

Author: Koray Güclü,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-01-28 09:00:02

score 274 · Accepted Answer

Dobrym powodem jest bezpieczeństwo - może to zapobiec atakom CSRF , ponieważ tego nagłówka nie można dodać do domeny AJAX request cross bez zgody serwera za pośrednictwem CORS .

Tylko następujące nagłówki są dozwolone cross domain:

Accept

Accept-Language

Content-Language

Last-Event-ID

Content-Type

Wszelkie inne powodują, że żądanie "przed lotem" jest wystawiane w przeglądarkach obsługiwanych przez CORS.

Bez CORS nie jest możliwe dodanie X-Requested-With do żądania cross domain XHR.

Jeśli serwer sprawdza, czy ten nagłówek jest obecny, wie, że żądanie nie zostało zainicjowane z domeny atakującego próbującego złożyć żądanie w imieniu Użytkownika za pomocą JavaScript. Sprawdza to również, czy żądanie nie zostało wysłane ze zwykłego formularza HTML, z którego trudniej jest zweryfikować, że nie jest to cross domain bez użycia tokenów. (Jednak sprawdzanie nagłówek Origin może być opcją w obsługiwanych przeglądarkach, chociaż stare przeglądarki będą podatne na ataki.)

Odkryto nowe obejście lampy błyskowej

Możesz chcieć połączyć to z tokenem , ponieważ Flash działający na Safari na OSX może ustawić ten nagłówek, jeśli istnieje krok przekierowania. Wygląda na to, że działał również na Chrome , ale teraz jest naprawiony. więcej szczegółów tutaj w tym różne wersje, których to dotyczy.

OWASP Polecam połączenie tego z sprawdzeniem pochodzenia i Referer :

Ta technika obrony jest szczegółowo omówiona w punkcie 4.3 Solidna ochrona przed fałszowaniem żądań między placówkami. Jednak obejścia ta obrona za pomocą Flasha została udokumentowana już w 2008 roku i ponownie jako ostatnio jako 2015 przez Mathiasa Karlssona, aby wykorzystać wadę CSRF w Vimeo. Ale uważamy, że atak Flash nie może sfałszować pochodzenia lub Nagłówków Referer więc sprawdzając oba z nich wierzymy, że to kombinacja kontroli powinna zapobiegać atakom Flash bypass CSRF. (Uwaga: Jeśli ktoś może potwierdzić lub obalić to przekonanie, daj nam znać, abyśmy można zaktualizować ten artykuł)

Jednak z już omówionych powodów sprawdzanie pochodzenia może być trudne.

Update

Napisał bardziej dogłębny post na blogu CORS, CSRF i X-Requested-z TUTAJ .