2015-04-29 146 views
0

我真的只是想从安全角度看下面的建议有多愚蠢。授予从一个网站到另一个网站的安全访问

我有两个网站。一个是管理门户,另一个是会员门户。

在管理门户中,管理员可以检索成员列表,我需要为管理员提供登录到成员门户的功能,而无需输入成员登录凭证。

两者都是IIS内部的独立网站,因此这个讨论可以说它们位于不同的服务器上。

这两个网站都访问相同的SQL Server数据库。

我在想管理员可以点击“Login as Member”链接创建一个随机代码字符串并将其与成员编号一起保存到数据库中。

我可以将代码和成员编号作为查询字符串参数传递给成员门户。

然后,成员门户将读取这些值并在数据库中检查它们以验证代码字符串是否存在以及是否与正在传递的成员编号匹配。然后,我可以登录该成员并在数据库中设置一个标志,以将代码设置为正在使用,因此对于将来的请求无效。

我想绕过这个黑客需要成功猜测随机代码,并将其传递到该代码旁边的相应成员编号,并将该组合标记为未使用的数据库中。

这看起来似乎不太可能,因为在生成的代码和正在使用的代码之间只经过了几秒钟。

如有必要,我可以随时检查请求的IP地址,因为管理门户的用户都共享相同的固定IP地址。

那么你认为上述方法可以经得起安全审查的审查,还是需要走SSO路线?

+0

什么类型的安全审查?登录后是否可以访问财务,医疗,社会安全号码等?如果您使用的是短期GUID并且正在检查IP地址,那么比将大量代码发送到电子邮件地址的密码恢复方法更安全。此外,它是否足够安全取决于管理员所在的环境的安全程度。当他们离开办公桌时,他们是否锁定桌面?进入大楼是否受到控制?等IT安全依赖于大量的物理安全... –

+0

此外,它可能会假设,但你打算使用HTTPS? –

+0

谢谢托尼 - 是的HTTPS将被用于此次讨论,我期待确定提出的方法是否会被视为安全,假设其他元素是安全的,如管理员锁定计算机,楼宇控制等。 – BugLover

回答

2

您的方法非常合理。我可以证实,因为我只是为了这个原因而实施了这样的解决方案。我们分析了选项和曝光。实施后,我们的申请通过了PCI Complaince Audit

原因:

  • SSL是Esential!防止嗅探器。必要。如果没有加密,嗅探器可以检测到您的GUID,并可以有一个窗口使用它)

  • 正如托尼指出,的GUID实际上是不可猜测

  • Guid 标记到期应该在24小时内过期

建议:

  • 检查,对IP是好的。但不要被它欺骗成一种安全感。任何人都可以在标头中伪造IP 。为了安全对XSSCSRF使用AntiForgery tokens

的防伪标记是用__RequestVerificationToken这几乎是很难猜测为您的GUID填充你的HTTPHeaders一个cookie。

  • 考虑使用已建立的身份验证框架,如.NET Identity 2和多租户。

已建立的框架负担加密您的密码。 MS框架,如简单会员身份融入现代ASP.NET框架,给你的功能非常强大的基础,依靠。

如果您使用的是像传统ASP或.NET 2.0这样的旧框架,那么classic Membership Provider更合适。

如果要创建新的MVC利用实体框架 5个应用,我强烈建议使用标识2.1

  • 考虑多租户。虽然您的解决方案没有任何问题,但如果管理员和用户共享成员资格提供程序,您的解决方案将更加清晰。管理员可以登录主站点并从数据库“获取”令牌。然后没有曝光。
+1

谢谢 - 这真是很好的建议,非常感谢 – BugLover

2

假设为管理员使用HTTPS和适当的物理和IT安全流程和程序,此方法应该足够。它比大多数金融网站密码重置更安全,通常只需要一个被盗用的电子邮件帐户和一些个人信息来重置密码。如果您也检查始发客户端请求的IP地址范围,则黑客必须已经可以访问您的系统或网络。此外,如果您将代码设置为GUID,则(实际上)不可能有人猜测。

您可以通过在每次发生此事件(或至少每次因失败密钥而导致每次失败时)在数据库中存储记录来添加一层检查黑客攻击的尝试,并且每次运行检查时都会看到如果它发生得太频繁(比如过去一小时100次,或者某个事情 - 正确的数字取决于你期望它发生的频率)。如果发生频率过高,请让IT人员发送警报并进行恢复,以便用户必须手动输入凭据。

声明:我不是任何安全专家,所以我会很乐意推迟声称这种状态的任何人。由于缺乏答案,我在这里沉重。

+0

非常有用,并感谢让球滚动的回复 – BugLover

+0

非常好的一点。关于检查用户“钓鱼”钥匙的部分是一个有趣的问题。未经授权方重复访问您的网站,应视为DOS攻击。阴险的问题。 –

相关问题