我的服务器上安装了许多应用程序，它们使用 webui 前端来控制应用程序。
由于我是服务器的唯一用户，我通常将这些应用程序绑定到 127.0.0.1。
由于服务绑定到本地主机，我假设我可以禁用这些应用程序的身份验证（通常是用户名+密码），因为我本地机器之外的任何人都无法访问这些服务。
我使用 SSH 隧道访问服务；所以本质上它让我可以从任何机器访问服务器的本地服务。
一个例子：我安装了 BitTorrent Sync。该应用程序使用我绑定到 127.0.0.1 的 webui。然后我禁用此 webui 的用户名+密码身份验证，并使用远程位置的 SSH 隧道访问它。
我的问题是，这安全吗？启用应用程序的身份验证方案会更好吗？（我认为不是，因为它绑定了本地主机）。攻击者是否有可能以某种方式欺骗 127.0.0.1 并获得访问权限？
他们可以尝试欺骗 127.0.0.1（我不确定网卡是否会接受它，他们不应该，但谁知道每个设置是否都能正确处理这个问题），但即使他们可以，他们也不会得到只要是webui就响应。这可能是 UDP 连接的问题，但 Web 请求不是 UDP。
更大的担忧是，如果攻击者获得了对您服务器的某种级别的本地访问权限，那么他们将能够更轻松地访问您的服务。例如，如果他们可以在您的服务器上获得某种类型的代理，那么他们将拥有完全访问权限，因为他们将能够充当 localhost。
如果他们获得了对服务器的完全访问权限，那么您可能无论如何都会被淹没，但是对服务的身份验证，特别是如果它一直被用于保护数据存储本身，可能会限制受损服务器的损害。
有一种鲜为人知的攻击称为 DNS 重新绑定，可用于利用此类情况。这是 Robert "RSnake" Hansen 的一段很棒的视频，解释了它的基础知识。看它。现在。
...好的，完成了吗？因此，情况如下：假设您有一个用于运行私有服务的 Web UI，127.0.0.1:80而没有任何类型的身份验证来保护它。让我们假设服务不关心主机头。在大多数情况下，您将在那里运行的服务类型不会，至少默认情况下不会。
进入邪恶的家伙。他在他的服务器上设置了一个网页，123.123.123.123:80并将他的域名绑定www.evil.com到 IP。然后他给你发了一封电子邮件："Hey, check out this cool website I found: http://www.evil.com/"。而你，对发生的事情一无所知，打开链接。该页面向您展示了一个有趣的猫视频，但在后台它实际上执行了一个 XHR 请求，强制域名重新绑定到您的本地 IP 地址，127.0.0.1.
现在有一个网页，http://www.evil.com/上面运行着 Evil Guy 的脚本，但域名实际上指向您的私人 Web UI。这意味着页面上的脚本可以完全访问您的内部工具。通常同源策略会阻止这种访问，但现在协议、域名和端口匹配，所以它无能为力。所以，你完蛋了。
解决方案：使用身份验证。或者确保您的 Web 服务尊重主机标头并在接收到未知主机的请求时失败。或者，只是为了确定，两者都做。
攻击者是否有可能以某种方式欺骗 127.0.0.1 并获得访问权限？
不是我知道的。
但是，在您的机器上运行的任何应用程序都可能能够访问绑定到localhost. 运行恶意或受损应用程序可能超出您的威胁模型，但值得指出。如果有人确实可以访问您的计算机，那么您的种子可能会发生什么可能是无关紧要的。
称为反向路径过滤的 Linux 内核功能丢弃或记录来自接口（在这种情况下为网络）上的数据包，其中回复应该在不同的接口上（在这种情况下为环回）。
典型的服务器环境对于在该服务器上运行的用户和服务有很多权限级别。无论在该服务器上具有本地访问权限，都可以访问您的环回和在其上运行的未经身份验证的服务。访客帐户可能具有最小的文件权限，但在访问本地服务时，它与任何其他用户具有相同的权限。
在桌面用户环境中，如果您在 localhost 上有一个 Web 应用程序，那么拦截您的明文 HTTP 通信的人（您肯定有一些）可以将 JavaScript 注入其中，然后像代理一样使用您的浏览器访问您的网络和到本地主机。当您在访问的任何 Web 应用程序上成为 XSS 的受害者或者您的本地应用程序易受 CSRF 攻击时，同样适用。这在最近流行的一个名为“我如何入侵你的路由器”的故事中得到了有趣的说明。还有其他本地服务，例如 SMTP，它们使用文本通信，可以通过 XSS 和 CSRF 访问。Man-In-The-Browser 场景也将获取您的本地数据。