我个人认为你做得很好。只要您的底层登录方法是安全的，就可以根据需要添加尽可能多的隐藏层。

我曾与一些客户合作过，他们想要您想要实现的确切目标。我一直使用以下两种方法之一：

• 跨站点登录表单：具有.html提交到example.com/private/login.php. 登录表单有一个hidden带有一些随机生成令牌的字段。

当然，任何人都可以分发同一个.html文件，但这并不重要，因为我们的主要安全方法是登录过程本身；用户名和密码。

任何请求都example.com/private被拒绝，404并显示给访问者。但是，当POST收到具有正确凭据的请求时，会启动一个会话，该网站正常工作。

这种方法的好处是它给了你合理的推诿。如果有人掌握了该.html文件，他们可以尝试登录，但他们仍然会得到404. 没有证据表明该文件与实际工作网站有关。

• URL 中的额外密码：与您的方法几乎相同，但额外的身份验证令牌在 URL 中。任何请求都example.com/private被拒绝，404并向访问者显示 a。但是，当example.com/private/login.php?token=Zz37vQQCnLTpe527xeFfFEG9收到正确的登录表单时，会查看登录表单。

大多数客户喜欢这种方法，因为他们能够为该 URL 添加书签。但是，这种方法的缺点是它不会授予您合理的否认性。任何知道该 URL 的人都可以证明该网站上有一个有效的登录表单。

老实说，我喜欢你的方法，我想有一天我可能会使用它。

重要提示：以上所有内容仅在您确保您的登录方法安全之后才适用。

您的方法在功能上等同于要求使用两个密码进行身份验证，Referer其中之一。更常见的变体是使用秘密 URL，即使“特殊字符串”成为私有站点路径的一部分。在 URL 中包含秘密字符串可能包括一些额外的细节需要考虑（例如，用户可以为它添加书签，这意味着该字符串被写入用户机器上一个不那么隐藏的文件中），但也会带来一些好处（例如，用户可以为它添加书签，使其与各种浏览器兼容，而不仅仅是带有扩展名的 Firefox）。对于可用性，我倾向于认为 URL 本身中的秘密字符串是一个更好的权衡，但这是你的决定。

我希望您为您的完整网站使用 HTTPS。实际上，如果您对公共站点和私有站点都使用纯 HTTP，那么被动窃听者可能会观察您与私有站点的通信，从而泄露您的密码和所有秘密。这不好。

如果您只对私有站点使用 HTTPS，那么您有一个侦听端口 443 的服务器，攻击者可以很清楚地看到它（就像在其上尝试连接一样简单）。如果主要的公共站点是仅 HTTP 的，攻击者很快就会明白有一个私有站点（人们不会为了好玩而购买和设置 SSL 服务器证书）。如果您希望您的私人站点不被检测到，那么您也必须对公共站点使用 HTTPS（出于各种原因，有些人普遍推荐它，并非所有这些都是技术性的）。

我不知道 RefControl 扩展的确切行为，但您需要确保它Referer仅将您的特殊字符串发送到您网站的HTTPS版本，而不是HTTP（如果存在）。再说一次，我个人会觉得在 URL 中使用秘密字符串更安全，因为至少我知道它什么时候会被发送，什么时候不会被发送。

如果您不希望有人知道有一个网络服务器，example.com除非请求了一些特殊的 URL，那么您必须在 IP 防火墙级别将其作为规则实施。它必须查找到达端口 80 的 SYN 数据包，并查看有效负载以查看它是对允许 URL 的有效 HTTP 请求。如果没有，那么只需丢弃数据包。

否则，如果对错误 URL 的请求通过服务器，服务器会通过建立 TCP 连接（并以 404 响应）来宣布其存在。

如果你在 Linux 上，你可以使用iptablesstring 模块来做这种事情。

看看这里：https : //stackoverflow.com/questions/4628157/allow-connections-to-only-a-specific-url-via-https-with-iptables-m-recent-pot

是的，没关系。只要密码层是安全的，添加更多的隐藏层就会有所帮助。

其他一些技巧（混合搭配）：

• 使登录页面只能通过 AJAX POST 请求访问（要登录，您可以在 JS 控制台中制作 POST 请求）
• 仅当您example.com/trigger?pwd=abcd在最后一分钟内访问过（这也是 404 页面）时才起作用。
• 使 URL 成为日期和时间的函数。在 JS 控制台中很容易计算但很难猜到的东西