保护网站管理部分的最佳做法是什么？ [关闭]答案

【问题标题】：What are best practices for securing the admin section of a website? [closed]保护网站管理部分的最佳做法是什么？ [关闭]
【发布时间】：2014-05-29 06:39:33
【问题描述】：

我想知道人们认为保护网站管理部分的最佳做法是什么，特别是从身份验证/访问的角度来看。

当然有一些显而易见的事情，例如使用 SSL 和记录所有访问，但我想知道在这些基本步骤之上人们认为应该设置什么标准。

例如：

您是否仅仅依赖于与普通用户相同的身份验证机制？如果不是，那是什么？
您是否在同一个“应用程序域”中运行管理部分？
您采取了哪些步骤来使管理部分不被发现？（或者你是否拒绝整个“默默无闻”的事情）

到目前为止，回答者的建议包括：

在每个管理员密码检查中引入人工服务器端暂停，以防止暴力攻击[开发人员艺术]
使用相同的 DB 表为用户和管理员使用单独的登录页面（以阻止 XSRF 和会话窃取授予对管理区域的访问权限）[Thief Master]
考虑将网络服务器本机身份验证添加到管理区域（例如通过 .htaccess）[Thief Master]
考虑在多次失败的管理员登录尝试后阻止用户 IP [Thief Master]
在管理员登录尝试失败后添加验证码[Thief Master]
为用户和管理员提供同样强大的机制（使用上述技术）（例如，不要特别对待管理员）[Lo'oris]
考虑二级身份验证（例如客户端证书、智能卡、卡空间等）[JoeGeeky]
仅允许来自受信任的 IP/域的访问，如果可能，将检查添加到基本 HTTP 管道（通过例如 HttpModules）。 [JoeGeeky]
[ASP.NET] 锁定 IPrincipal 和 Principal（使它们不可变且不可枚举）[JoeGeeky]
联邦权限提升 - 例如当任何管理员的权限升级时，向其他管理员发送电子邮件。 [JoeGeeky]
考虑管理员的细粒度权限 - 例如而不是基于角色的权限，为每个管理员定义个人操作的权限[JoeGeeky]
限制创建管理员 - 例如管理员不能更改或创建其他管理员帐户。为此，请使用锁定的“超级管理员”客户端。 [JoeGeeky]
考虑客户端 SSL 证书，或 RSA 类型密钥卡（电子令牌）[Daniel Papasian]
如果使用 cookie 进行身份验证，请为管理页面和普通页面使用单独的 cookie，例如将管理部分放在不同的域上。 [丹尼尔·帕帕西恩]
如果可行，请考虑将管理站点保留在私有子网上，远离公共 Internet。 [约翰·哈特索克]
在网站的管理员/正常使用上下文之间移动时重新签发身份验证/会话票证[Richard JP Le Guen]

【问题讨论】：

只是一个想法。保护管理部分的最佳方法可能是不要将它放在公共互联网上。您可以选择仅将管理站点保留在私有子网上。
您指定的以下哪些想法不适用于所有用户，而不仅仅是管理员？
您可能想查看webloginproject.com 的 WebLoginProject，它是一个协作登录系统，旨在防止 XSS、SQL 注入、会话固定和 CSRF 漏洞的安全。它有 ASP 和 PHP 的源代码，它是多语言的，而且看起来很酷。许多开发人员正在努力修复漏洞，所以这可能是尽可能接近安全的。
-1 包含非常错误的“强密码”（实际上是一个非常弱密码）建议
@Lohoris - 我真的不明白你为什么不赞成这个问题。您是否因为我总结了您不同意的某人的建议而投反对票？也许对相关答案投反对票会更具建设性。 :/ 你能具体说明你有什么问题吗？

标签： security authentication

【解决方案1】：

如果网站需要登录才能进行常规活动和管理员，例如一个论坛，我会使用使用相同用户数据库的单独登录名。这可确保 XSRF 和会话窃取不会允许攻击者访问管理区域。

此外，如果 admin 部分位于单独的子目录中，使用网络服务器的身份验证（例如 Apache 中的 .htaccess）保护该部分可能是一个好主意 - 那么有人需要该密码和用户密码。

隐藏管理员路径几乎不会带来任何安全收益 - 如果有人知道有效的登录数据，他很可能也能够找到管理员工具的路径，因为他要么通过网络钓鱼或键盘记录你，要么通过社会工程获得它（这将可能也会揭示路径）。

在 3 次登录失败后阻止用户的 IP 或在登录失败后要求验证码（不适用于第一次登录，因为这对合法用户来说非常烦人）等暴力保护也可能有用。

【讨论】：

在第一段中，如果项目在单独的文件夹中，这是否意味着更好？

【解决方案2】：

这些都是很好的答案...我通常喜欢为我的管理部分添加几个额外的层。虽然我在一个主题上使用了一些变体，但它们通常包括以下之一：

二级身份验证：这可能包括客户端证书（例如 x509 证书）、智能卡、卡空间等......
域/IP 限制：在这种情况下，只有来自受信任/可验证域的客户端；例如内部子网；被允许进入管理区域。远程管理员经常通过受信任的 VPN 入口点，因此他们的会话是可验证的，并且通常也受到 RSA 密钥的保护。如果您使用的是 ASP.NET，则可以通过 HTTP 模块轻松地在 HTTP 管道中执行这些检查，如果安全检查未得到满足，这将阻止您的应用程序接收任何请求。
锁定 IPrincipal 和基于 Principal 的授权：创建自定义原则是一种常见做法，尽管常见错误是使它们可修改和/或权限可枚举。虽然它不仅仅是一个管理问题，但它更重要，因为这里是用户可能拥有提升权限的地方。确保它们是不可变的且不可枚举的。此外，请确保所有授权评估均基于委托人进行。
联合权限提升：当任何帐户获得选定数量的权限时，所有管理员和安全人员都会立即通过电子邮件收到通知。这确保了如果攻击者提升了我们立即知道的权限。这些权利通常围绕特权、查看受隐私保护的信息和/或财务信息（例如信用卡）的权利。
谨慎地发布权利，即使对管理员也是如此：最后，这对于某些商店来说可能更高级一些。授权权应尽可能谨慎，并应围绕真实的功能行为。典型的基于角色的安全 (RBS) 方法往往具有组心态。从安全角度来看，这不是最好的模式。而不是像“用户管理器”这样的“组”，尝试进一步分解它（例如创建用户、授权用户、提升/撤销访问权限等。 ..）。这在管理方面可能会产生更多开销，但这使您可以灵活地仅分配更大的管理员组实际需要的权限。如果访问受到损害，至少他们可能无法获得所有权利。我喜欢将其包装在 .NET 和 Java 支持的代码访问安全 (CAS) 权限中，但这超出了此答案的范围。还有一件事......在一个应用程序中，管理员无法管理更改其他管理员帐户，或使用户成为管理员。这只能通过只有几个人可以访问的锁定客户端来完成。

【讨论】：

【解决方案3】：

我拒绝默默无闻
使用两个身份验证系统而不是一个是大材小用
尝试之间的人为暂停也应该为用户完成
也应为用户阻止尝试失败的 IP
用户也应该使用强密码
如果您认为验证码没问题，猜猜看，您也可以将它们用于用户

是的，写完之后，我意识到这个答案可以概括为“管理员登录没什么特别的，它们都是应该用于任何登录的安全功能”。

【讨论】：

感谢您的回答。就我个人而言，我倾向于不同意，例如：用户会对像 'ksd83,'|4d#rrpp0%27&lq(go43$sd{3>' 这样的密码感到满意吗？而且，是否重置有效用户触发的 IP 块健忘会产生不必要的管理/客户服务工作？我个人认为不同级别的风险证明不同的方法是合理的
管理员密码应该很复杂，但不能过于复杂，否则即使管理员也不会记住它，并将其写在某个地方（你会强迫他无视所有安全规则）。尝试失败时暂时屏蔽 IP 是很标准的，vbulletin 做，phpbb 做 IIRC，用户习惯了。
我真的不想向 phpbb 或 vbulletin 寻求安全最佳实践；）
@UpTheCreek 当然，我同意！我只是在质疑这个“不会重置有效用户因健忘而触发的IP块会生成不必要的管理员/客户服务工作”

【解决方案4】：

如果您确实只为同时拥有普通用户权限和管理员权限的用户使用单一登录，则在发生更改时重新生成他们的会话标识符（无论是在 cookie 中还是在 GET 参数中或其他任何东西中...）特权级别……至少。

所以，如果我登录，做一堆普通用户的事情，然后访问一个管理页面，重新生成我的会话 ID。如果我随后从管理页面导航到普通用户页面，请再次重新生成我的 ID。

【讨论】：

你能解释一下这是什么实现的吗？
security.stackexchange.com/questions/1246/…
我相信这不会像你想象的那样有帮助。因为如果攻击者能够在普通用户页面中获取您当前的会话 ID，他可以使用它来访问管理页面并为自己生成一个新的会话 ID。如果我错了，请纠正我。
但是攻击者在没有密码的情况下无法访问管理页面。在进行身份验证之前，权限级别不会发生变化。未能重新生成会话 ID 意味着他们可以重新使用不安全创建的会话来绕过身份验证。
现在知道了。我在想你描述了一个场景，用户在普通/管理上下文之间切换时不必重新登录。

【解决方案5】：

有一个好的管理员密码。

不是"123456"，而是一个足够长的字母、数字和特殊字符序列，比如 15-20 个字符。喜欢"ksd83,'|4d#rrpp0%27&lq(go43$sd{3>"。

为每个密码检查添加暂停以防止暴力攻击。

【讨论】：

您能解释一下什么是“暂停”吗？您是指做一些类似 Thread.Sleep(5000) 的事情来消磨一些时间吗？
这很愚蠢：一个太复杂而无法记住的密码会被写在某个地方（或保存），因此比您允许一个非常好的密码（即一个将要输入的密码）更糟糕因为你记得它而不是复制粘贴）。
哦，我希望我能把这个废话投到石器时代，这是如此愚蠢，如此错误......我讨厌人们传播诸如此类的错误信息。
@Lo'oris：你到底有什么不同意的？
我已经把它写在......就像......上面的评论？

【解决方案6】：

还有一些其他需要考虑的事项：

要考虑的一个选项是使用基于 SSL 证书的客户端身份验证，特别是如果您管理管理员的计算机或他们在技术上胜任的情况下。 RSA 钥匙扣等也可用于增加安全性。
如果您完全使用 cookie - 可能用于身份验证/会话令牌 - 您可能希望确保 cookie 仅发送到管理页面。这有助于减轻通过窃取 cookie、第 1/2 层妥协或 XSS 对您的站点构成的风险。这可以通过将管理部分放在不同的主机名或域上以及使用 cookie 设置安全标志来轻松完成。
通过 IP 进行限制也很聪明，如果您的用户遍布整个互联网，您仍然可以这样做，前提是他们可以加入受信任的 VPN。

【讨论】：

【解决方案7】：

我们使用Windows Authentication 进行管理员访问。这是保护管理区域的最实用方法，同时将身份验证与适用于一般最终用户的身份验证分开。系统管理员管理 Admin 用户访问凭据并对域用户帐户实施密码策略。

【讨论】：

【解决方案8】：

严格的方法是拥有两个完全不同的“场”，包括数据库、服务器和所有数据，并将数据从一个场移动到另一个场。大多数现代、大规模的系统都使用这种方法（Vignette、SharePoint 等）。它通常被称为具有不同的阶段“编辑阶段”->“预览阶段”->“交付阶段”。这种方法让您可以像对待代码一样对待内容/配置（dev->qa->prod）。

如果您不那么偏执，您可以拥有一个数据库，但在“编辑”服务器上只有您的管理部分可用。我的意思是，只有编辑脚本/文件放在编辑服务器上。

当然，编辑阶段只能在本地 Intranet 和/或使用 VPN 时使用。

这可能看起来有点矫枉过正，可能不是所有用例的最简单的解决方案，但它绝对是最强大的做事方式。

请注意，“拥有强大的管理员密码”之类的东西很好，但仍然让您的管理员对各种智能攻击保持开放。

【讨论】：

我认为这仅在您推送内容而不是处理数据的纯 CMS/发布情况下才有用/实用。
也许吧，但我知道（并看到）在处理和用户输入方面也这样做的情况。对于具有单独编辑服务器的单个农场来说，这是不费吹灰之力的。对于多个农场，您所做的是将来自站点的输入放入队列（数据库或其他），并通过使用外部过程进行处理并复制到“编辑”服务器/数据库中。这使您可以更好地控制进入系统的内容。但是，实现起来很复杂。

【解决方案9】：

这在很大程度上取决于您要保护哪种数据（法律要求等）。

很多建议都是关于身份验证的。我认为你应该考虑使用 OpenId / Facebook 身份验证作为登录名。（他们很可能会在身份验证安全上花费比您更多的资源）
保存更改以及更新数据库中的值。这样您就可以回滚来自用户 X 或日期 X 和 Y 之间的更改。

【讨论】：

网站管理部分的 Facebook 身份验证...您真的认为这是个好主意吗？对于一般用户，是的...但是对于管理部分？对我来说感觉有点危险......
我不确定。但我认为这个网站只运行 openid 身份验证。而且我认为facebook身份验证和openid之间没有任何（理论上）大的区别。但我没有阅读任何许可协议或类似的内容。
管理员身份验证的openid非常糟糕，而且大多数时候回滚是不可能的，而且坏人已经在你的系统中准备好了......什么回滚？
欢迎解释为什么你认为它不好。好吧，如果以管理员身份登录可以让您完全访问数据库和备份，那么肯定很难回滚，但在这种情况下，您都准备好了。我的建议是针对 cmsisch 网站的。

【解决方案10】：

我没有注意到有人提到管理员密码的存储/验证。请不要以纯文本形式存储 PW，最好不要存储可以反转的东西 - 使用类似 salted MD5 哈希的东西，这样至少如果有人碰巧检索到存储的“密码”，他们不会’没有任何非常有用的东西，除非他们也有你的盐计划。

【讨论】：

-1 用于 md5。您不想要密码的快速散列，甚至超出 md5ing 的其他问题。 bcrypt 会是更好的选择。

【解决方案11】：

添加管理员知道的密码字段和安全问题，例如你的第一个女朋友叫什么名字，或者每次查看管理面板时随机提问。

也许您总是可以将管理部分放在一个大目录中，例如

http://domain.com/sub/sub/sub/sub/sub/index.php

但这不是很好哈哈。

也许您可以在主页中包含一个查询字符串，例如：

http://domain.com/index.php?display=true

完成后，会出现用户名和密码字段。

【讨论】：