mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-09-30 03:01:21 +02:00
jmoore-skild
f62e907e9f
A settings restore could substitute the instance'"'"'s authentication source. auth.py reads the LDAP config live from the settings table on every login, and none of ldap_server_url, ldap_user_filter, ldap_auto_provision or ldap_default_group is credential-shaped, so the secret-key hints never saw them and only the four auth-policy keys were protected. ldap_enabled was covered by the companion-credential rule instead, and that rule asks the wrong question. It judges availability - "will the integration still work?" - and an anonymous bind works, so a payload that simply OMITS ldap_bind_password skips the refusal and has its toggle written. Omitting the credential is exactly what an attacker authoring the file would do: they own the directory being pointed at, so they need no bind credential from us. Left unrefused, a backup repository anyone can write to yields admin: point ldap_server_url at your own directory, set ldap_auto_provision and ldap_default_group=Administrators, and the next login on a fresh username is provisioned into the admin group. Overwrite-off is enough on an instance that never configured LDAP - there are no rows to skip. Refused by prefix so a key added to the LDAP schema later is refused by default, and matched case-insensitively because the key comes from the backup JSON rather than from our own writer. ldap_enabled leaves _COMPANION_CREDENTIALS rather than sitting there as dead code, since _is_protected_setting_key runs first. The two tests asserting an anonymous bind was a false positive are inverted - they encoded the hole - and the refusal reuses the existing settingsAuthSkipped note, which already points at Settings > Authentication.