Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disallow LDAP anonymous bind #1277

Closed
satterly opened this issue Jul 27, 2020 · 4 comments · Fixed by #1345
Closed

Disallow LDAP anonymous bind #1277

satterly opened this issue Jul 27, 2020 · 4 comments · Fixed by #1345
Labels
priority: high An urgent problem preventing use and there is no workaround security This important issue will not be marked as stale by @probot

Comments

@satterly
Copy link
Member

satterly commented Jul 27, 2020

https://stackoverflow.com/a/27873735

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.

https://tools.ietf.org/html/rfc4513#section-5.2.1.1

Operational experience shows that clients can (and frequently do)
misuse the unauthenticated authentication mechanism of the simple
Bind method (see Section 5.1.2). For example, a client program might
make a decision to grant access to non-directory information on the
basis of successfully completing a Bind operation. LDAP server
implementations may return a success response to an unauthenticated
Bind request. This may erroneously leave the client with the
impression that the server has successfully authenticated the
identity represented by the distinguished name when in reality, an
anonymous authorization state has been established. Clients that use
the results from a simple Bind operation to make authorization
decisions should actively detect unauthenticated Bind requests (by
verifying that the supplied password is not empty) and react
appropriately.

https://tools.ietf.org/html/rfc4513#section-6.3.1

@satterly satterly changed the title Disallow LDP anonymously bind Disallow LDAP anonymously bind Jul 27, 2020
@satterly satterly changed the title Disallow LDAP anonymously bind Disallow LDAP anonymous bind Jul 27, 2020
@satterly satterly added priority: high An urgent problem preventing use and there is no workaround security This important issue will not be marked as stale by @probot labels Jul 27, 2020
@CasperGN
Copy link

@satterly are you in this one referring to a login as:

username: 'admin'
password: ''

or:

username: ''
password: ''

The first is not an anonymous bind as the RFC you've linked above states. It is an unauthenticated bind as referred in section 5.1.2 (anonymous in 5.1.1):

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.

Thanks in advance for clarification.

Cheers,
Casper

@satterly
Copy link
Member Author

I was intending to modify Alerta API to reject with 401 any attempt to login using zero-length password which would prevent both of the above scenarios. Is that not the right approach?

@CasperGN
Copy link

I think 401 on blank password (maybe also check for null byte, don't know how that's parsed further on) would be sufficient to take on both anonymous bind attempts and unauthenticated binds.
Just sought clarification on which (if not both) use-cases you wanted to disallow.
Thanks for the clarification!

Cheers,
Casper

@CasperGN
Copy link

CasperGN commented Nov 5, 2020

@satterly Is this incorporated into a release yet? And also, any way I can contact you outside an issue that is open for anyone to read?

Cheers,
Casper

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: high An urgent problem preventing use and there is no workaround security This important issue will not be marked as stale by @probot
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants