源映射HTTP请求未发送cookie头

Question

关于源映射，我在Chromium（版本181620）中遇到了奇怪的行为。 在我的应用程序中，我使用了压缩后的jquery，在登录后，我开始看到服务器日志文件中的“jquery.min.map”的HTTP请求。这些请求缺少cookie头（所有其他请求都没有问题）。 这些请求甚至在开发者工具的网络选项卡中也无法显示（这并不太困扰我）。

关键是，此应用程序中的js文件只应该对已登录的客户端可用，因此在此设置中，源映射要么无法正常工作，要么必须将源映射的位置更改为公共目录。

我的问题是：这是期望的行为（意思是-源映射请求不应发送cookie），还是Chromium中的一个错误？

- maX

Answer 1

String InspectorFrontendHost::loadResourceSynchronously(const String& url) 的实现位于 InspectorFrontendHost.cpp，用于加载 sourcemap 资源，它使用了 DoNotAllowStoredCredentials 标志，我相信这会导致您观察到的行为。

这种方法具有潜在的危险性，因此该标志存在是为了让我们（你）处于安全的一面，避免泄漏敏感数据。

顺便提一句，在生产环境中仅向已登录用户（即不来自无 cookie 域）提供 jquery.min.js 并不是一个很好的部署方式。我不确定你的想法，但如果你确实需要避免向未访问你网站的客户端提供文件，可以检查 HTTP 请求头中的 Referer。

- Alexander Pavlov

---

谢谢您的回答，我只是想确认这种行为是否是有意的。 我知道从无cookie域提供静态文件会更好，但在这种情况下，jquery只是一个例子，并不需要以这种方式提供。我们只需要保护公司客户的自己的脚本，因此我们不会向外界公开任何特定于客户的内部信息。 顺便说一句，检查引荐者并不是我们正在寻找的安全级别。 - maX

好的，我现在明白了。解决这个问题的一个方法可能是采用安全性通过混淆的方法：在您的资源名称中使用随机的多位Base36（或其他）字符串化值，这应该是绝对不可能猜测的。它们只能通过编译后的JS源代码获得，这将受到登录保护。 - Alexander Pavlov

小心使用安全性通过混淆的方法 - 除非您正在使用https，否则任何人都可以通过嗅探流量获取URL。此外，我不明白传递cookie如何危险：脚本可以访问任何它想要的域，并发送cookies。 - zaius

@zaius：(a) 你对嗅探的看法是正确的；我在建议时考虑的是“非关联”的人。如果他们进行有针对性的攻击，他们肯定可以这样做。但是，如果脚本内容没有通过https传输，他们也可以嗅探到它。(b) 是的，脚本可以这样做，但是如果DevTools被黑客攻击，后果可能会很严重（尽管我并不是说一定会发生 :))。 - Alexander Pavlov

地图文件本身不包含代码，因此将它们放入公共目录中不应该是一个安全问题。我想要的只是澄清我观察到的行为是否是有意的，这似乎基本上是有意的。 - maX

@AlexanderPavlov - 两个都是好观点。我没有想到地图是在开发工具的上下文中运行而不是页面中。 - zaius

Answer 2

我遇到了这个问题，并且对为什么某些身份验证 cookie 在请求我们应用程序的 .js.map 文件时未被发送感到好奇。

在使用 Chrome 71.0.3578.98 进行测试时，如果 SameSite cookie atttribute 设置为 strict 或 lax，Chrome 将不会在请求 .js.map 文件时发送该 cookie。当没有 sameSite 限制时，cookie 将被发送。

我不知道有关预期行为的任何规范。

- Elliott Beach

---

请参阅 https://bugs.chromium.org/p/chromium/issues/detail?id=920648&q=sameSite&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified 上的讨论，该讨论与sameSite有关。 - Elliott Beach