X-Requested-With 标头有什么意义？

Question

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

X-请求-使用：XMLHttpRequest

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

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

Answer 1

一个很好的理由是为了安全 - 这可以防止 CSRF 攻击，因为未经服务器通过 CORS 同意，无法将此标头添加到 AJAX 跨域请求中。

仅允许以下标头跨源：

• 接受
• 接受语言
• 内容语言
• 最后事件 ID
• 内容类型

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

如果没有 CORS，则无法将

X-Requested-With

添加到跨域 XHR 请求。

如果服务器检查此标头是否存在，则它知道该请求不是从尝试使用 JavaScript 代表用户发出请求的攻击者域发起的。这还会检查请求是否不是从常规 HTML 表单发布的，如果不使用令牌，很难验证它不是跨域。 （但是，检查

Origin

标头可能是受支持的浏览器中的一个选项，尽管您会让旧浏览器容易受到攻击。）

发现新的 Flash 绕过方法

您可能希望将其与令牌结合使用，因为在 OSX 上的 Safari 上运行的 Flash 可以在存在重定向步骤时设置此标头。看来 它也适用于 Chrome ，但现已修复。 更多详细信息请点击这里，包括受影响的不同版本。

OWASP 建议将此与 Origin 和 Referer 检查结合起来：

这种防御技术在 4.3 节中有具体讨论 针对跨站点请求伪造的强大防御。然而，绕过 这种使用 Flash 的防御早在 2008 年就已被记录下来，并再次于 最近，2015 年，Mathias Karlsson 开发了 Vimeo 中的 CSRF 缺陷。 但是，我们相信 Flash 攻击无法欺骗 Origin 或 Referer 标头因此通过检查它们我们相信这一点 检查组合应该可以防止 Flash 绕过 CSRF 攻击。 （笔记： 如果有人可以证实或反驳这一信念，请告诉我们，以便我们 可以更新这篇文章）

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

更新

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

Answer 2

请务必阅读 SilverlightFox 的答案。凸显了一个更重要的原因。

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

例如，假设您有一个包含许多食谱的网站。您可以使用自定义 jQuery 框架根据菜谱单击的链接将菜谱滑入容器中。 链接可能是

www.example.com/recipe/apple_pie

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

现在您可以为数据编写辅助端点，例如

www.example.com/recipe_only/apple_pie

，但这更难维护和与其他人共享。

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

框架只是添加标头，因为有些人可能会发现跟踪哪些请求是 ajax 哪些不是很有用。但这完全取决于开发人员是否使用此类技术。

它实际上有点类似于

Accept-Language

标题。浏览器可以请求网站请显示该网站的俄语版本，而无需在 URL 中插入 /ru/ 或类似内容。

Answer 3

一些框架使用此标头来检测 xhr 请求，例如grails spring security 使用此标头来识别 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