Open-AudIT

Hey guys,

Just a note that if register_globals is on in a PHP installation you can view any list just by defining page=add_pc to the URL. For example:

http://<site>/openaudit/list.php?page=add_pc

This is really bad! It allows for anyone with HTTP access to retrieve sensitive info (serials ect). To fix this you need to delete or comment out this line in include.php:

if ($page == "add_pc"){$use_pass = "n";}

If you are doing automated auditing thats it. This presents a bit more inconvenience to a manual submission.

-Chris

Yeah, the "password" system right now is very minimal. I've been pondering changes to this system, but have yet to decide where to go with it. I really would like user/group management which different permissions (which would solve the issue you are mentioning). I've been looking at Pear::LiveUser, but I haven't gotten around to playing with it enough to see how it works. If you have any interest in implementing this let me know.

Since we have the OpenAudit page locked down with IIS and Windows Integrated Authentication, we should be safe from anything like this, right?

Yea you should be ok. If you rely on WIA to perform authentication you are ok. I have my pages restricted with apache via .htaccess (basic HTTP authentication) so I'm not worried.

We could maybe check $_SERVER["SCRIPT_NAME"] is admin_pc_add_1.php or admin_pc_add_2.php instead. I don't think you can overwrite these variables can you?

I think those are read only variables so yea you could do that. The best solution is just to add basic http authentication into the audit script because there is still the problem that anyone can add junk data to your server...with enough submissions it can fill the database in a denial of service style attack.

[quote]The best solution is just to add basic http authentication into the audit script because there is still the problem that anyone can add junk data to your server...with enough submissions it can fill the database in a denial of service style attack.

Run the audit script as a user that has rights to read the config file. Deny read access to anyone else. That way the script can read the config but nobody else.

http://sudowin.sourceforge.net/

You can create a batch that automatically opens sudowin and runs the audit script. Voila.

sudowin, haven't seen that one before. Looks good.

[quote="cdvma"]Run the audit script as a user that has rights to read the config file. Deny read access to anyone else. That way the script can read the config but nobody else.

http://sudowin.sourceforge.net/

You can create a batch that automatically opens sudowin and runs the audit script. Voila.

[quote]You can create a batch that automatically opens sudowin and runs the audit script. Voila.

Somewhere down the line the posting pages have to be

1) Secure, and use https, otherwise you can sniff all of the details being passed via the script.

2) Authenticated, in otherwords you can only post data if you can authenticate/verify your connection.

3) Verified as making sense, both in terms of content (URLS must look like URLS, Date-times must look like date-times etc) and length.


This present several problems.

First to use https you need to pass and verify certificates, this should ideally be done only once otherwise each post to the database prompts you to verify the certificate.

Second the posting of data needs to be done using some sort of exchange of passwords, or verification of content and length, otherwise we are liable to be open to DOS attack.

Currently we do little of this, simply because we have been concerned maily with getting meaningfull results from what we have created so far.

I have one question. Do we need to put all of this in place before we post an interim release, or do we state this is a goal for the next major release.

[quote]1) Secure, and use https, otherwise you can sniff all of the details being passed via the script.
.....
First to use https you need to pass and verify certificates, this should ideally be done only once otherwise each post to the database prompts you to verify the certificate.

What about verification of data to stop buffer overflow and injection of "stuff" into the database, if we assume that the username and password has been compromised, we should still not accept the data if it is a load of garbage, designed to kill the connection.

[quote]
I'm pretty sure the current code should post to https providing the client computer trusts the Certificate authority that signed the certificate on the server.

[quote="d.l.dave"][quote]You can create a batch that automatically opens sudowin and runs the audit script. Voila.