jQuery X-Requested-With 标头有什么意义?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/17478731/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-26 19:10:27  来源:igfitidea点击:

What's the point of the X-Requested-With header?

jqueryajaxhttp-headerscors

提问by Gili

JQuery and other frameworks add the following header:

JQuery 和其他框架添加以下标头:

X-Requested-With: XMLHttpRequest

X-Requested-With: XMLHttpRequest

Why is this needed? Why would a server want to treat AJAX requests differently than normal requests?

为什么需要这个?为什么服务器要以不同于普通请求的方式处理 AJAX 请求?

UPDATE: I just found a real-life example using this header: https://core.spreedly.com/manual/payment-methods/adding-with-js. If the payment processor is requested without AJAX, it redirects back to the original website when it's done. When it is requested with AJAX, no redirection is done.

更新:我刚刚找到了一个使用此标题的真实示例:https: //core.spreedly.com/manual/payment-methods/adding-with-js。如果在没有 AJAX 的情况下请求支付处理器,它会在完成后重定向回原始网站。当使用 AJAX 请求时,不会进行重定向。

回答by SilverlightFox

A good reason is for security - this can prevent CSRFattacks because this header cannot be added to the AJAX request cross domain without the consent of the server via CORS.

一个很好的理由是为了安全——这可以防止CSRF攻击,因为在没有服务器同意的情况下,不能通过CORS将此标头添加到 AJAX 请求跨域。

Only the following headers are allowed cross domain:

仅允许以下标头跨域:

  • Accept
  • Accept-Language
  • Content-Language
  • Last-Event-ID
  • Content-Type
  • 接受
  • 接受语言
  • 内容语言
  • 上次事件 ID
  • 内容类型

any others cause a "pre-flight" request to be issued in CORS supported browsers.

任何其他原因导致在支持 CORS 的浏览器中发出“飞行前”请求。

Without CORS it is not possible to add X-Requested-Withto a cross domain XHR request.

没有 CORS,就不可能添加X-Requested-With到跨域 XHR 请求。

If the server is checking that this header is present, it knows that the request didn't initiate from an attacker's domain attempting to make a request on behalf of the user with JavaScript. This also checks that the request wasn't POSTed from a regular HTML form, of which it is harder to verify it is not cross domain without the use of tokens. (However, checking the Originheadercould be an option in supported browsers, although you will leave old browsers vulnerable.)

如果服务器正在检查此标头是否存在,则它知道该请求不是从试图代表用户使用 JavaScript 发出请求的攻击者的域发起的。这也检查请求不是从常规 HTML 表单发布的,如果不使用令牌,则很难验证它不是跨域的。(但是,在受支持的浏览器中检查Origin标题可能是一个选项,尽管您会使旧浏览器容易受到攻击。)

New Flash bypass discovered

发现新的 Flash 绕过

You may wish to combine this with a token, because Flash running on Safari on OSX can set this header if there's a redirect step. It appears it also worked on Chrome, but is now remediated. More details hereincluding different versions affected.

您可能希望将其与令牌结合使用,因为如果有重定向步骤,在 OSX 上的 Safari 上运行的 Flash可以设置此标头。它似乎也适用于 Chrome,但现在已修复。此处更多详细信息,包括受影响的不同版本。

OWASP Recommend combining this with an Origin and Referer check:

OWASP 建议将此与 Origin 和 Referer 检查相结合

This defense technique is specifically discussed in section 4.3 of Robust Defenses for Cross-Site Request Forgery. However, bypasses of this defense using Flash were documented as early as 2008 and again as recently as 2015 by Mathias Karlsson to exploit a CSRF flaw in Vimeo. But, we believe that the Flash attack can't spoof the Origin or Referer headers so by checking both of them we believe this combination of checks should prevent Flash bypass CSRF attacks. (NOTE: If anyone can confirm or refute this belief, please let us know so we can update this article)

这种防御技术在跨站点请求伪造的鲁棒防御的第 4.3 节中有专门讨论。然而,早在 2008 年和 2015 年,Mathias Karlsson 就利用 Flash 绕过了这种防御,利用 Vimeo 中的 CSRF 缺陷再次记录了下来。但是,我们认为 Flash 攻击不能欺骗 Origin 或 Referer 标头,因此通过检查这两个标头,我们相信这种检查组合应该可以防止 Flash 绕过 CSRF 攻击。(注意:如果有人可以证实或反驳这一信念,请告诉我们,以便我们更新这篇文章)

However, for the reasons already discussed checking Origin can be tricky.

但是,由于已经讨论过的原因,检查 Origin 可能很棘手。

Update

更新

Written a more in depth blog post on CORS, CSRF and X-Requested-With here.

在这里写了一篇关于CORS、CSRF 和 X-Requested-With的更深入的博客文章。

回答by EWit

Make sure you read SilverlightFox's answer. It highlights a more important reason.

请务必阅读 SilverlightFox 的回答。它突出了一个更重要的原因。

The reason is mostly that if you know the source of a request you may want to customize it a little bit.

原因主要是如果您知道请求的来源,您可能希望对其进行一些自定义。

For instance lets say you have a website which has many recipes. And you use a custom jQuery framework to slide recipes into a container based on a link they click. The link may be www.example.com/recipe/apple_pie

例如,假设您有一个包含许多食谱的网站。并且您使用自定义 jQuery 框架根据他们单击的链接将食谱滑入容器。链接可能是www.example.com/recipe/apple_pie

Now normally that returns a full page, header, footer, recipe content and ads. But if someone is browsing your website some of those parts are already loaded. So you can use an AJAX to get the recipe the user has selected but to save time and bandwidth don't load the header/footer/ads.

现在通常会返回一个完整的页面、页眉、页脚、食谱内容和广告。但是,如果有人正在浏览您的网站,其中一些部分已经加载。因此,您可以使用 AJAX 来获取用户选择的配方,但为了节省时间和带宽,请不要加载页眉/页脚/广告。

Now you can just write a secondary endpoint for the data like www.example.com/recipe_only/apple_piebut that's harder to maintain and share to other people.

现在您可以为数据编写一个辅助端点,www.example.com/recipe_only/apple_pie但这样更难维护和共享给其他人。

But it's easier to just detect that it is an ajax request making the request and then returning only a part of the data. That way the user wastes less bandwidth and the site appears more responsive.

但是更容易检测到它是一个 ajax 请求发出请求然后只返回数据的一部分。这样,用户浪费的带宽更少,站点的响应速度也会更快。

The frameworks just add the header because some may find it useful to keep track of which requests are ajax and which are not. But it's entirely dependent on the developer to use such techniques.

框架只是添加标头,因为有些人可能会发现跟踪哪些请求是 ajax 哪些不是很有用。但是它完全依赖于开发人员使用这些技术。

It's actually kind of similar to the Accept-Languageheader. A browser can request a website please show me a Russian version of this website without having to insert /ru/ or similar in the URL.

它实际上有点类似于Accept-Language标题。浏览器可以请求一个网站,请向我展示该网站的俄文版本,而无需在 URL 中插入 /ru/ 或类似内容。

回答by Koray Güclü

Some frameworks are using this header to detect xhr requests e.g. grails spring security is using this header to identify xhr request and give either a json response or html response as response.

一些框架使用这个头来检测 xhr 请求,例如 grails spring security 使用这个头来识别 xhr 请求并给出一个 json 响应或 html 响应作为响应。

Most Ajax libraries (Prototype, JQuery, and Dojo as of v2.1) include an X-Requested-With header that indicates that the request was made by XMLHttpRequest instead of being triggered by clicking a regular hyperlink or form submit button.

大多数 Ajax 库(Prototype、JQuery 和 Dojo 从 v2.1 开始)都包含一个 X-Requested-With 标头,它指示请求是由 XMLHttpRequest 发出的,而不是通过单击常规超链接或表单提交按钮触发的。

Source: http://grails-plugins.github.io/grails-spring-security-core/guide/helperClasses.html

来源:http: //grails-plugins.github.io/grails-spring-security-core/guide/helperClasses.html