logo标签列表

网站管理员区域保护的最佳实践是什么？

securityauthentication
100

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

当然有一些明显的事情，比如使用SSL和记录所有访问，但我想知道人们认为除了这些基本步骤之外还要采取哪些措施。

例如：

  • 您是否只依赖于与普通用户相同的身份验证机制？如果不是，是什么？
  • 您是否在同一个“应用程序域”中运行管理员部分？
  • 您采取什么措施使管理部分难以发现？（或者您拒绝整个“模糊性”问题）

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

  • 在每个管理员密码检查中引入人工服务器端暂停，以防止暴力攻击 [Developer Art]
  • 使用单独的登录页面为用户和管理员，使用相同的DB表格（以防止XSRF和会话窃取授予访问管理员区域) [Thief Master]
  • 考虑在管理区域中添加Web服务器本地身份验证（例如通过.htaccess） [Thief Master]
  • 考虑在管理员登录尝试失败后阻止用户IP [Thief Master]
  • 在管理员登录尝试失败后添加验证码 [Thief Master]
  • 为用户和管理员提供同样强大的机制（使用上述技术），例如不要特别对待管理员 [Lo'oris]
  • 考虑第二级身份验证（例如客户端证书，智能卡，卡片空间等） [JoeGeeky]
  • 仅允许来自可信IP /域名的访问，如果可能，请在基本HTTP管道中添加检查（例如通过HttpModules） [JoeGeeky]
  • [ASP.NET]锁定IPrincipal＆amp; Principal（使其不可变且不可枚举） [JoeGeeky]
  • 联合权限提升-例如电子邮件其他管理员，当任何管理员的权限得到升级时。
  • 考虑为管理员设置细粒度权限，例如，不基于角色的权限，而是为每个管理员定义单独的操作权限。
  • 限制创建管理员账户，例如，管理员不能更改或创建其他管理员账户。使用受限的“超级管理员”客户端进行此操作。
  • 考虑使用客户端端SSL证书或RSA类型的电子令牌（电子口令）。
  • 如果使用cookies进行认证，请为管理员和普通页面使用单独的cookies，例如将管理员部分放在不同的域名下。
  • 如果可行，考虑将管理员站点保持在私有子网上，远离公共互联网。
  • 当移动网站的使用场景从管理员切换到正常用户时，重新发布授权/会话票据。
3
这只是一个想法，但最好保护管理部分的方法是不要将其放在公共互联网上。您可以选择仅将管理员站点保留在私有子网中。 - John Hartsock
1
你指定的这些想法中，哪一个不适合应用于所有用户，而不仅仅是管理员？ - Vivian River
不要包含那个非常错误的“强密码”建议（实际上是一个非常弱的密码）。 - o0'.
@Lohoris - 我真的不明白你为什么要对这个问题进行负投票。你是因为我总结了某人的建议而你不同意吗？也许对相关答案进行负投票会更有建设性。:/ 你能具体说明你有什么问题吗？ - UpTheCreek
我冒昧地删除了那个建议，毕竟这是社区维基。 - o0'.
显示剩余3条评论
11个回答
22

这些都是不错的答案......我通常会为我的管理部分添加几个额外的层。虽然我使用了一些变化，但它们通常包括以下之一：

  • 第二级身份验证：这可能包括客户端证书（例如x509证书）、智能卡、卡空间等...
  • 域/IP限制：在这种情况下，只有来自受信任/可验证域的客户端，例如内部子网，才被允许进入管理区域。远程管理员通常通过可信VPN入口点进行，因此他们的会话是可验证的，并且通常还受到RSA密钥的保护。如果您正在使用ASP.NET，则可以通过HTTP模块轻松执行这些检查，如果安全检查未满足，则阻止您的应用程序收到任何请求。
  • 锁定的IPrincipal和基于Principal的授权：创建自定义原则是一种常见做法，尽管一个常见的错误是使它们可修改和/或权利可枚举。尽管这不仅是一个管理员问题，但它更重要，因为这里用户可能具有提升的权利。确保它们是不可变的并且不可枚举。此外，请确保所有授权评估都基于主体进行。
  • 联合权利提升：当任何帐户获得一定数量的权限时，所有管理员和安全官员将立即通过电子邮件收到通知。这确保了如果攻击者提升了权限，我们会立即知道。这些权限通常围绕特权权限、查看隐私保护信息和/或财务信息（例如信用卡）。
  • 谨慎授权，即使是管理员也是如此：最后，对于一些商店来说，这可能会更为复杂。授权权限应该尽可能地保密，并且应围绕真实的功能行为。典型的基于角色的安全(RBS)方法往往具有群组意识。从安全角度来看，这不是最佳模式。与其像“用户管理器”这样的'群组'，不如尝试进一步细分（例如创建用户、授权用户、提升/撤销访问权限等）。虽然这在管理方面可能需要更多的开销，但这可以让您灵活地仅分配大型管理组所需的权限。如果访问权受到威胁，至少他们可能无法获得所有权利。我喜欢将此包装在由.NET和Java支持的代码访问安全(CAS)权限中，但这超出了本答案的范围。还有一件事……在一个应用程序中，管理员不能管理其他管理员账户的更改，或者让用户成为管理员。这只能通过一个只有几个人可以访问的锁定客户端完成。
    • 21
    如果网站需要普通活动和管理员登录，例如论坛，我将使用不同的登录，这些登录使用相同的用户数据库。这确保了XSRF和会话劫持不能让攻击者访问管理区域。
    此外，如果管理员部分在单独的子目录中，则使用Web服务器身份验证（例如Apache中的.htaccess）保护该部分可能是一个好主意-然后某人需要该密码和用户密码。
    混淆管理员路径几乎没有安全性收益-如果有人知道有效的登录数据，他很可能也能够找到管理员工具的路径，因为他要么钓鱼，要么按键记录你，或者通过社交工程获得它（这可能也会揭示路径）。
    诸如阻止用户的IP在3次失败的登录后或在登录失败后要求CAPTCHA（不适用于第一次登录，因为那只是对合法用户极其恼人）之类的暴力保护也可能有用。
    在第一段中，这是否意味着最好将项目放在单独的文件夹中？ - ßiansor Å. Ålmerol
    9
    • 我拒绝模糊不清
    • 使用两个身份验证系统而不是一个是过度的
    • 人为地在尝试之间加入暂停时间也应该用于用户
    • 阻止失败尝试的IP地址也应该用于用户
    • 用户也应该使用强密码
    • 如果你认为验证码可以接受，那么你也可以为用户使用它们

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

    6
    谢谢回答。就个人而言，我有不同的看法，例如：用户会喜欢像“ksd83,'|4d#rrpp0%27&lq(go43$sd{3>'”这样的密码吗？此外，重置由于忘记密码而触发的IP阻止是否会产生不必要的管理/客户服务工作？我认为不同的风险水平需要采取不同的方法。 - UpTheCreek
    1
    管理员密码应该是复杂的，但不要过于复杂，否则即使管理员也会忘记它并将其写在某个地方（这将迫使他违反每一个安全规则）。暂时阻止尝试失败的IP是相当标准的做法，vbulletin这样做，phpbb这样做，用户已经习惯了。 - o0'.
    我并不想去查看phpbb或vbulletin的安全最佳实践 ;) - UpTheCreek
    @UpTheCreek 当然，我同意！我只是在质疑这个“重置IP块是否会产生不必要的管理员/客户服务工作，因为一些合法用户由于健忘而触发了它”。<--我认为这不会成为问题，因为用户已经习惯了这样的功能。 - o0'.
    3
    如果您仅对同时具有普通用户权限和管理员权限的用户使用单个登录，则在特权级别发生更改时重新生成其会话标识符（无论是在cookie中还是GET参数或其他位置...） 至少要这样做。

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

    请问您能否解释一下这是实现了什么功能？ - Denis Pshenov
    http://security.stackexchange.com/questions/1246/session-hijacking-regenerate-session-id - Richard JP Le Guen
    1
    我认为这并不会像你想的那样有所帮助。因为如果攻击者能够在普通用户页面中获取您当前的会话ID，他可以使用它来访问管理员页面并生成自己的新会话ID。如果我错了，请纠正我。 - Denis Pshenov
    1
    但攻击者无法在没有密码的情况下访问管理员页面。在身份验证之前，权限级别不会发生变化。未能重新生成会话ID意味着他们可以重复使用以不安全方式创建的会话来绕过身份验证。 - Richard JP Le Guen
    现在明白了。我原来以为你描述的是用户在正常/管理员上下文之间切换时不必重新登录的情况。 - Denis Pshenov
    2

    设置一个强密码。

    不要使用 "123456" 这样的简单密码，而是使用足够长的字母、数字和特殊字符组成的序列，比如 15-20 个字符。例如："ksd83,'|4d#rrpp0%27&lq(go43$sd{3>"。

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

    那没有任何作用。在另一个请求等待的时候，您可以请求另一个密码。 - Andreas Bonini
    6
    这很愚蠢：一个太复杂以至于难以记忆的密码会被记录在某个地方（或保存），这会比让你使用一个真正好的密码更糟糕（即一个你能记住而不是复制粘贴的密码）。请记住，易于记忆的密码也可以是安全的。 - o0'.
    4
    哦，我希望我能将这个糟糕的东西投票到石器时代，它非常愚蠢，非常错误...我讨厌像这样传播错误信息的人。 - o0'.
    1
    @Lo'oris：你到底不同意什么？ - user151323
    2
    我已经写在上面的注释里了，就像那样。 - o0'.
    显示剩余3条评论
    1

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

    1. 如果您管理管理员的计算机或他们具备技术能力，可以考虑使用基于SSL证书的客户端身份验证。还可以使用RSA密钥令牌等增加安全性。
    2. 如果您使用cookie（例如用于身份验证/会话令牌），则可能希望确保cookie仅发送到管理员页面。这有助于通过层1/2妥协或XSS窃取cookie对您的站点造成的风险。这可以通过将管理员部分放在不同的主机名或域上以及设置cookie的安全标志来轻松完成。
    3. 按IP地址限制也很明智，如果您的用户遍布互联网，则仍然可以这样做，只要有可信的VPN供他们加入即可。
    1
    我们使用Windows身份验证来进行管理员访问。这是保护管理员区域最实用的方式，同时将身份验证与适用于普通终端用户的身份验证分开。系统管理员管理管理员用户访问凭据，并强制执行域用户帐户的密码策略。
    -1

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

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

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

    这可能看起来有点过度，对于所有使用情况来说可能不是最简单的解决方案，但绝对是最强大的方法。

    请注意，“拥有强密码”之类的事情很好，但仍然会让您的管理员面临各种聪明的攻击。

    我认为这只在纯粹的CMS/发布情况下有用/实用，其中您正在推送内容而不是处理数据。 - UpTheCreek
    也许是这样，但我知道（并且见过）有些情况下这也用于处理和用户输入。对于一个单独的农场和分离的编辑服务器来说，这是毫无疑问的。对于多个农场，您需要将站点输入放入队列（DB或其他方式），并使用外部过程进行处理并复制到“编辑”服务器/DB中。这使您可以更好地控制系统中的内容。然而，实施起来比较复杂。 - Nir Levy
    -2

    这非常取决于您想要保护什么类型的数据（法律要求等）。

    • 许多建议都是关于身份验证的...我认为您只需考虑使用OpenId / Facebook身份验证作为登录方式。（他们很可能会在身份验证安全性方面投入更多资源）

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

    1
    Facebook认证用于网站的管理员部分...你真的认为这是个好主意吗？对于普通用户来说，是的...但对于_管理员部分_来说呢？对我来说感觉有点危险。 - Richard JP Le Guen
    我不确定，但我认为这个网站只运行openid身份验证。我认为Facebook身份验证和OpenID在理论上没有什么大的区别。但我没有阅读任何许可协议或类似文件。 - Carl Bergquist
    1
    使用OpenID进行管理员身份验证是一个非常糟糕的想法，而且大多数情况下回滚是不可能的，坏人已经进入了您的系统...回滚什么？ - Aristos
    随意解释为什么你认为它不好。如果以管理员身份登录可以完全访问数据库和备份，那么回滚肯定很困难，但在这种情况下，你已经输了。我的建议是针对cmsisch网站的。 - Carl Bergquist
    -3

    我没有注意到有人提到管理员密码的存储/验证。请不要以明文形式存储密码，最好甚至不要使用可逆转的东西 - 使用类似于salted MD5哈希的东西，这样至少如果有人恰好检索到存储的“密码”，他们就没有什么非常有用的东西，除非他们也知道你的盐方案。

    2
    -1 用于 md5。即使忽略了 md5 的其他问题，你也不想为密码使用快速哈希。bcrypt 将是更好的选择。 - Kzqai
    网页内容由stack overflow 提供, 点击上面的
    可以查看英文原文，
    原文链接