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

我想知道人们对确保网站的“管理”部分安全的最佳做法，特别是从身份验证/访问的角度来看。

当然，有一些显而易见的事情，例如使用SSL和记录所有访问权限，但是我想知道人们在这些基本步骤的哪些位置设置了标准。

例如：

• 您是否仅依靠与普通用户相同的身份验证机制？如果没有，那该怎么办？
• 您是否在同一“应用程序域”中运行“管理”部分？
• 您采取什么步骤来使管理部分未被发现？（或者您拒绝整个“模糊”的事情）

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

• 在每个管理员密码检查中引入人为的服务器端暂停，以防止暴力攻击[Developer Art]
• 使用同一数据库表为用户和管理员使用单独的登录页面（以停止XSRF和会话窃取授予对管理区域的访问权限）[Thief Master]
• 还考虑将Web服务器本机身份验证添加到管理区域（例如，通过.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用于管理页面和普通页面，例如，将admin部分放在不同的域中。[丹尼尔·帕帕斯人]
• 如果可行，请考虑将管理站点保留在公共互联网之外的专用子网中。[约翰·哈索克]
• 在网站的管理员/正常使用环境之间移动时，请重新颁发身份验证/会话票证[Richard JP Le Guen]

这些都是很好的答案...我通常希望为管理部分添加几个附加层。尽管我在主题上使用了一些变体，但它们通常包括以下内容之一：

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

如果该网站要求常规活动和管理员都需要登录，例如论坛，则我将使用使用相同用户数据库的单独登录。这样可以确保XSRF和会话窃取不会允许攻击者访问管理区域。

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

遮盖管理路径几乎不会带来安全收益-如果某人知道有效的登录数据，则他很有可能也可以找出管理工具的路径，因为他要么对它进行了钓鱼或键盘记录，要么通过社交工程获得了该工具（这可能会揭示出路径）。

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

• 我拒绝默默无闻
• 使用两个身份验证系统而不是一个是过大的
• 尝试之间的人为暂停也应为用户完成
• 也应该为用户完成阻止失败尝试的IP
• 用户也应使用强密码
• 如果您认为验证码还行，请猜猜是什么，您也可以将其用于用户

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

如果您只对具有普通用户特权和管理员特权的用户使用一次登录，请在级别更改时重新生成其会话标识符（在cookie或GET参数等中）。特权...至少。

因此，如果我登录，请执行一些普通的用户操作，然后访问管理页面，重新生成我的会话ID。如果然后我从管理页面导航到普通用户页面，请再次重新生成我的ID。

有一个好的管理员密码。

不 "123456"，但字母，数字和特殊字符足够长的时间序列，比方说，15至20个字符。像"ksd83,'|4d#rrpp0%27&lq(go43$sd{3>"。

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

以下是一些其他要考虑的事项：

1. 要考虑的一种选择（尤其是在管理管理员的计算机或技术上胜任的情况下）是使用基于SSL证书的内容进行客户端身份验证。RSA密钥卡和诸如此类的东西也可以用于增加安全性。
2. 如果您完全使用Cookie（可能是用于身份验证/会话令牌），则可能要确保将Cookie仅发送到管理页面。这可以通过1/2层妥协或XSS来窃取Cookie，从而减轻对网站造成的风险。通过使admin部分位于不同的主机名或域上以及通过cookie设置安全标志，可以轻松完成此操作。
3. 通过IP进行限制也很聪明，如果您在整个Internet上都有用户，并且可以加入一个受信任的VPN，您仍然可以这样做。

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

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

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

自然，编辑阶段仅应在本地Intranet和/或使用VPN上可用。

这似乎有点过大，并且可能不是所有使用情况的最简单解决方案，但绝对是最可靠的处理方式。

请注意，诸如“具有强壮的管理员密码”之类的东西不错，但是仍然使您的管理员对各种智能行为保持开放。

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

• 很多关于身份验证的建议。我想您应该考虑使用OpenId / Facebook身份验证作为登录名。（与您相比，他们很可能会在身份验证安全上花费更多的资源）

• 保存更改以及更新数据库中的值。这样，您可以回滚用户X或日期X和Y之间的更改。

我没有注意到有人提到管理员密码的存储/验证。请请不要以纯文本形式存储密码，最好甚至不要使用任何可以反转的东西-使用盐腌 MD5哈希之类的东西，以便至少在有人碰巧检索他们没有的“密码”的情况下任何非常有用的东西，除非他们也有您的食盐方案。

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

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

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

但这不是很好，哈。

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

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

完成后，将显示用户名和密码字段。