问题描述

我有这段代码根据 LDAP 目录对我的用户进行身份验证.如果密码不正确，它会返回 false，但如果密码留空，它仍然会验证用户身份.任何想法为什么会发生这种情况?

I have this code authenticating my users against an LDAP directory. It returns false when there is an incorrect password, but if the password is left blank, it authenticates the user anyways. Any ideas why that might occur?

if (@ldap_bind($ds, $user_dn, $password) || sha1($password) == '484h84h4hf4Ffwj49393393j93j') 
{
    $valid = true;
}
else $valid = false;

推荐答案

如果您提供一个空密码，那么它向目录服务器表明您正在执行匿名简单绑定.此行为在 RFC 2251 第 4.2.2 节中有所描述:

If you provide an empty password, then it indicates to the directory server that you are performing an anonymous simple bind. This behavior is described in RFC 2251 section 4.2.2:

 If no authentication is to be performed, then the simple
 authentication option MUST be chosen, and the password be of zero
 length.  (This is often done by LDAPv2 clients.)  Typically the DN is
 also of zero length.

这可能是 LDAP 客户端中一个非常常见的安全漏洞，因为如果他们不验证用户是否提供了非空密码但尝试绑定非空 DN 和空密码，那么他们可以看到它成功，当服务器未绑定为提供的 DN 指定的用户而是匿名绑定时.因为这是 LDAP 客户端中常见的安全问题，所以一些服务器拒绝使用非空 DN 但空密码的绑定请求，最新的 LDAPv3 规范鼓励这种行为，如 RFC 4513 第 5.1.2 节所示:

This may be a pretty common security hole in LDAP clients because if they do not verify that the user provided a non-empty password but try to bind with a non-empty DN and an empty password then they can see that it succeeds, when the server didn't bind as the user specified by the provided DN but rather bound anonymously. Because this is such a common security problem in LDAP clients, some servers reject bind requests with a non-empty DN but an empty password, and this behavior is encouraged by the most recent LDAPv3 specifications, as indicated in RFC 4513 section 5.1.2:

 An LDAP client may use the unauthenticated authentication mechanism
 of the simple Bind method to establish an anonymous authorization
 state by sending a Bind request with a name value (a distinguished
 name in LDAP string form [RFC4514] of non-zero length) and specifying
 the simple authentication choice containing a password value of zero
 length.

 The distinguished name value provided by the client is intended to be
 used for trace (e.g., logging) purposes only.  The value is not to be
 authenticated or otherwise validated (including verification that the
 DN refers to an existing directory object).  The value is not to be
 used (directly or indirectly) for authorization purposes.

 Unauthenticated Bind operations can have significant security issues
 (see Section 6.3.1).  In particular, users intending to perform
 Name/Password Authentication may inadvertently provide an empty
 password and thus cause poorly implemented clients to request
 Unauthenticated access.  Clients SHOULD be implemented to require
 user selection of the Unauthenticated Authentication Mechanism by
 means other than user input of an empty password.  Clients SHOULD
 disallow an empty password input to a Name/Password Authentication
 user interface.  Additionally, Servers SHOULD by default fail
 Unauthenticated Bind requests with a resultCode of
 unwillingToPerform.

听起来您的服务器没有这样做.如果它可以选择这样做，那么我强烈建议将其打开.但无论如何，使用简单绑定操作来验证用户凭据的精心设计的 LDAP 客户端应该在尝试使用它绑定到服务器之前绝对验证用户提供了一个非空字符串.

It sounds like your server doesn't do that. If it has the option to do that, then I would strongly recommend turning it on. But at any rate, a well-designed LDAP client that uses simple bind operations to verify user credentials should absolutely verify that the user provided a non-empty string before attempting to use it to bind to the server.

这篇关于LDAP 绑定似乎返回 true，密码为空的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！