2012-04-14 72 views
4

我在想我是否可以使用User.Identity.Name来查询我的数据库中的数据。
例如:“User.Identity.Name”安全吗?

UsersBLL.GetPersonalInformation(string username) 

User.Identity.Name的值传递给该方法是一个好主意?
User.Identity.Name的值可以被劫持吗?

回答

2

它会被劫持吗?是的,例如,由于insufficient transport layer protection(该链接中的工作示例)会话劫持,但这对于会员提供商实施本身并不构成风险。

而不是围绕传递用户名,我会坚持到ID:

var user = Membership.GetUser(); 
var userId = (Guid?)user.ProviderUserKey; 

我认为取决于aspnet_Users用户表(假定,同样,你使用的是默认成员资格提供任何表),正在使用该ID作为外键而不是用户名。至少我希望是这样!

+0

我没有使用会员系统,只是我自己的数据库,是的,我使用ID作为外键。但我使用用户名为我的方法,以避免再往返数据库,这是一个不好的做法?我应该通过userid吗?我应该查询用户标识并将其缓存以备后用? – Adir 2012-04-16 08:47:49

+0

这是一个内部实现,你不会以便于劫持的方式公开它,只要你仍然使用正确的访问控制,它应该没问题。 – 2012-04-16 22:19:49

4

User.Identity.Name与其他任何方式一样安全。是否有可能劫持它?也许,如果你不使用SSL,而且你没有加密你的认证机制,但是如果你使用的是SSL并且使用了加密的FormsAuthentication或者Windows身份验证,你应该没问题。

基本上,如果你遵循良好的安全措施,它应该是完全安全的。至少不会比识别用户的其他方式更安全。

编辑:

这是假设你是不是键控你的表上的用户名,而是由会员用户ID,你的代码只是查找按名成员表中的用户ID。

如果您在用户名上键入表格,则需要考虑一些安全问题。其中之一就是Henk在他的回答中提到的。如果您不允许更改用户名或重复使用,那么这不是问题。

+0

添加它将您的应用程序从底层的身份验证机制中屏蔽掉。例如,您可以从Kerberos切换到2-Way SSL或来自地狱的声明,并且您的应用程序不需要太多更改。 – ixe013 2012-04-14 15:21:49