代码之家  ›  专栏  ›  技术社区  ›  Colin Newell

是否有不同的方法来进行已经构建和审核的ASP.Net表单身份验证?

  •  4
  • Colin Newell  · 技术社区  · 15 年前

    像很多人一样,我使用了asp.net表单身份验证,因为它已经编写好了,并且编写了我们自己的安全代码,我们被告知这通常是个坏主意。

    鉴于目前ASP.Net存在的问题,我认为现在是寻找替代方案的好时机。

    据我所知,微软倾向于在客户端存储东西,因为它使在服务器场上操作更容易,而不需要数据库访问调用。

    不过,我并不真正关心服务器场,我只想拥有一个不透明的cookie,这表明我对呼叫者缺乏信任。

    有没有一个已经被证明是可靠的体面的解决方案?

    更新: 来澄清我的问题。我说的是表单身份验证中要替换的身份验证令牌部分后端很容易替换,您可以很容易地实现存储用户和角色的接口。也可以使用现有的类库 http://www.memberprotect.net/ 这里已经提到过了。

    我想将流程的前端部分更改为使用不向客户提供任何杠杆的令牌坚持现有的后端基础设施是有用的,但不是必需的。

    4 回复  |  直到 15 年前
        1
  •  4
  •   scottt732    15 年前

    我一直在研究一个HttpModule,它基本上可以满足您的需求当生成FormsAuthenticationCookie和FormsAuthenticatedTicket时,在将响应发送到客户端之前(即,在处理登录页/操作的回发期间),有关cookie&ticket的所有详细信息都存储在服务器上此外,来自票证的用户数据被移动到服务器(如果存在),并替换为票证中其他属性的salted sha-512散列,以及用作票证服务器端存储的密钥的guid。

    cookie&tickets的验证将客户端提供的所有内容(可选地包括其IP地址)与发布时已知的所有属性进行比较。如果有任何内容不匹配,则在formsauthenticationmodule启动之前将它们从请求中移除。如果一切都匹配,服务器的用户数据将被卡在formsauthticket中,以防您有任何依赖于它的模块或代码。都是透明的此外,它还可以检测可疑和公然恶意的请求,并在处理过程中插入随机延迟。它还有一些显式的填充oracle解决方案。

    演示应用程序实际上允许您在服务器上创建/修改cookie&ticket值,服务器使用机器密钥为您加密ticket。这样,您就可以向自己证明,除非您将确切的数据集写入服务器(在正常情况下应该是不可能的),否则无法创建绕过服务器验证的ticket/cookie。

    -斯科特

        2
  •  1
  •   eglasius    15 年前

    如果您的密钥在web.config中,并且攻击者能够找到它,那么它们就差不多完成了。

    如果不是这样(他们没有从您的.config获取密钥),那么afaik填充oracle不应该允许他们签署新的身份验证票证本文解释了利用cbc模式进行加密的能力,最后是一点垃圾这应该足以使它成为一个无效的签名。

    至于他们使用该工具获取密钥的视频,则是针对dotnetnuke安装的默认的dotnetnuke在web.config中有这些键。

    实现解决方案,如果不使用webresource.axd和scriptresource.axd,请将密钥保留在网站级web.config之外禁用这些处理程序,并在ms发布修补程序后立即应用它。

        3
  •  0
  •   Capital G    15 年前

    我只建议您看看InetSolution的MemberProtect产品,它是一个为银行和金融服务行业设计的安全组件,但广泛适用于在ASP.NET上设计的任何站点或在.NET平台上构建的应用程序它提供了对用户信息加密的支持,以及从简单到高级的许多认证方法,并且各种方法和功能被设计成开发者认为合适的,因此它不是一个罐头解决方案,而是非常灵活的解决方案。这可能是件好事,也可能不是好事,这取决于具体情况这也是一个非常坚实的基础上,建立新的基于会员的网站和应用程序一般。

    你可以在 http://www.memberprotect.net

    我是memberprotect的开发人员,在inetsolution工作:)

        4
  •  0
  •   Dan Puzey    15 年前

    这不是一个没有价值的问题,但我不得不说,我认为你的逻辑是可疑的。考虑其他身份验证解决方案并不是一个坏主意,但新公布的asp.net漏洞不应迫使您放弃当前(可能正在工作)的解决方案。我也不完全确定这一评论的相关性是什么:

    据我所知,微软倾向于在客户端存储东西,因为它使在服务器场上操作更容易,而不需要数据库访问调用。

    使您认为ASP.NET窗体身份验证比其他解决方案更容易被破坏的漏洞是什么?

    MS Advisory的详细信息似乎表明,几乎所有其他身份验证系统都可能同样容易受到攻击。例如,任何使用 web.config 如果攻击成功,则存储设置的文件仍将对世界开放其设置。

    这里真正的解决方案不是更改安全性,而是将已发布的解决方案应用于该问题您可能会切换身份验证提供程序,但却发现您仍然易受攻击,而且您的努力毫无收获。

    关于令牌/会话:您必须 某物 让客户端进行身份验证(无论您是否将其称为令牌),导致当前安全问题的并不是进程的这一部分:而是服务器响应某些调用的方式,使此机密易受攻击。

    推荐文章