保护网站管理部分的最佳做法是什么？

Question

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

当然有明显的事情,比如使用SSL和记录所有访问权限,但我想知道上面这些基本步骤的位置,人们会考虑设置这个栏.

例如:

• 您是否只依赖于普通用户使用的相同身份验证机制？如果不是,那是什么？
• 您是否在同一个"应用程序域"中运行"管理"部分？
• 您采取了哪些措施来使管理部分未被发现？(或者你拒绝整个'默默无闻'的事情)

---

到目前为止,来自回答者的建议包括:

• 在每个管理员密码检查中引入一个人为的服务器端暂停,以防止暴力攻击[开发者艺术]
• 使用相同的数据库表为用户和管理员使用单独的登录页面(停止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]
• 限制管理员的创建 - 例如,管理员无法更改或创建其他管理员帐户.使用锁定的'superadmin'客户端.[JoeGeeky]
• 考虑客户端SSL证书或RSA类型密钥卡(电子令牌)[Daniel Papasian]
• 如果使用cookie进行身份验证,请为管理员和普通页面使用单独的cookie,例如将管理部分放在不同的域中.[Daniel Papasian]
• 如果可行,请考虑将管理站点保留在公共互联网上的私有子网上.[约翰哈茨克]
• 在网站的管理/正常使用情况之间移动时重新颁发身份验证/会话票据[Richard JP Le Guen]

Answer 1

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

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

模糊管理路径几乎不会产生任何安全性 - 如果有人知道有效的登录数据,他很可能也能找到管理工具的路径,因为他要么对其进行网络钓鱼,要么通过社交工程对其进行键盘管理(这可能会揭示出来道路,也).

蛮力保护,例如在3次登录失败后阻止用户的IP或在登录失败后需要CAPTCHA(不是第一次登录,因为这对于合法用户来说非常烦人)也可能有用.

Answer 2

这些都是很好的答案......我通常喜欢为我的管理部分添加一些额外的图层.虽然我在主题上使用了一些变体,但它们通常包含以下内容之一:

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

Answer 3

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

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