Nginx inode 信息泄露
Nginx Inode Information Leakage
我在 Burp Suite 响应部分遇到了一个我以前从未见过或注意到的词。 ETag。
我对这是什么做了一些研究，但不幸的是我什么都不懂，因为我对工作的理论部分不了解。
随着时间的推移，我会了解什么是ETag。不过我现在想问的有点不一样。
Burp Suiterequest中的两个值是：
If-Modified-Since: Wed, 30 Dec 2020 08:46:04 GMT
If-None-Match: W / "5f ***** c-d **" (I hid it on purpose)
响应中的这个：
ETag: "5f ***** c-d **"
注：Server: nginx / 1.14.0 (Ubuntu)
这是漏洞吗？如果是漏洞，攻击者如何利用它？
我很好奇这是否真的是可报告的事情。
inode 是服务器的内部文件特定的信息，因此很多安全扫描软件会将此报告为漏洞。
但是，关于如何将其转化为真正的 hack，您在网络上可以找到的信息非常少。它可能有助于发现文件 A 与文件 B 是 hard-link（同一文件，在同一文件系统上），仅此而已。
Apache 曾一度将文件的索引节点作为 ETag header 值的一部分（可配置且可以禁用）。自 2.4 版以来，Apache 默认停止了此包含。
NGINX 本身从不使用文件的索引节点作为其 ETag header.
的一部分
但是，安全扫描软件仍会将 NGINX 报告为泄漏 inode 信息，因为他们永远不知道它是代理旧的 Apache 还是其他实际泄漏 inode 信息的软件。
因此，如果您是 运行 NGINX-only 设置，则可以说这是误报。
如果你不这样做，你仍然可以说它是误报，因为“好的，这是服务器内部的，但没有人能够用它做任何事情”。
我在 Burp Suite 响应部分遇到了一个我以前从未见过或注意到的词。 ETag。 我对这是什么做了一些研究，但不幸的是我什么都不懂，因为我对工作的理论部分不了解。
随着时间的推移，我会了解什么是ETag。不过我现在想问的有点不一样。
Burp Suiterequest中的两个值是：
If-Modified-Since: Wed, 30 Dec 2020 08:46:04 GMT
If-None-Match: W / "5f ***** c-d **" (I hid it on purpose)
响应中的这个：
ETag: "5f ***** c-d **"
注：Server: nginx / 1.14.0 (Ubuntu)
这是漏洞吗？如果是漏洞，攻击者如何利用它？
我很好奇这是否真的是可报告的事情。
inode 是服务器的内部文件特定的信息，因此很多安全扫描软件会将此报告为漏洞。
但是，关于如何将其转化为真正的 hack，您在网络上可以找到的信息非常少。它可能有助于发现文件 A 与文件 B 是 hard-link（同一文件，在同一文件系统上），仅此而已。
Apache 曾一度将文件的索引节点作为 ETag header 值的一部分（可配置且可以禁用）。自 2.4 版以来，Apache 默认停止了此包含。
NGINX 本身从不使用文件的索引节点作为其 ETag header.
但是，安全扫描软件仍会将 NGINX 报告为泄漏 inode 信息，因为他们永远不知道它是代理旧的 Apache 还是其他实际泄漏 inode 信息的软件。
因此，如果您是 运行 NGINX-only 设置，则可以说这是误报。 如果你不这样做，你仍然可以说它是误报，因为“好的，这是服务器内部的，但没有人能够用它做任何事情”。