Comment 1 for bug 259776

There were multiple CVEs in previous versions of OBM (typical web/PHP/input santizing issues: XSS, SQL injection), mostly affecting previous 1.x series, what steps are taken in the package to ensure the scripts aren't publicly exposed?

I would expect OBM to only be used by some key people in a company, from the company intranet, and with login/password; would I have to configure a SQL/PHP app, I might:
- restrict access to the service by IP address
- add some web server/Apache level filtering (e.g. require HTTP auth, or SSL client certs)

Grepping the source, I didn't see much escaping going on; nor parametrized SQL queries. I only found some stripslashes() and single quoting which is rather light.

I also looked for command executions from the PHP scripts, and found that the LDAP password will be updated by exec()ing $path/../auto/changePasswd.pl, is this mode of operation supported in the .deb packages? It seems the password is passed on the command line:
        $cmd = $cmd_ldap_passwd.$parameters.' --login '.$login.' --domain '.$domain_id.' --type '.$password_encryption." --passwd '".$new_pass."' --no-old";
this allows local users to see the new password.

I was a bit scared to see what other commands are defined:
// Automate commands
$cmd_halt = "sudo /sbin/halt";

As I understand it, if you install the package it will immediately be available from the web at /obm with login/password admin/admin. Shouldn't there be some debconf prompting to ask for an admin password before putting the service up?