Closed jhowe-uw closed 1 year ago
Thanks for the idea.
This is not something I'm going to implement for 2 reason:
Firstly, my goal is that for first time in stall that there are less hurdles to get started. Thus anybody setting up PLA would want to use it in a test environment first, understand how to configure/tune/tweak it, and then take that knowledge before deploying in a production setting. As part of that deployment would be the configuration as to whether allow anonymous binds (amongst other settings).
Secondly, it is the goal of the project that it doesnt implement any "security", or perception of security - that is the sole responsibility of the LDAP server (and it's ACLs). (PLA should and does report, when the LDAP servers says "No".) I dont want anybody thinking that they can secure their LDAP server through PLA, only to find that somebody got in another way and did what they shouldnt do. If your LDAP server shouldnt accept anonymous binds - because it exposes data that shouldnt be exposed, then that, IMHO, should be fixed at the source (the LDAP server). (And fixing it at the source imperically fixes it through PLA.)
We are using phpLDAPadmin version 1.2.6.2.
By default, anonymous binding is enabled by default.
I believe this exposes the system to potential data exfiltration, especially when the system has a malformed, incorrect, or has incongruent LDAP ACL policies in relation to operational constraints.
However, this is an admin tool, and as such, should be hardened on an initial deploy.
We were recently graciously tagged offline by a security researcher ( selsel ), who was so kind to point out these weaknesses in our infrastructure via a Google Dork scan ( https://www.google.com/search?q=inurl:/phpldapadmin/cmd.php).
I propose the following code change:
I believe this affects the following files:
config/config.php.example
lib/ds_ldap_pla.php
Thanks!