rklrkl
commented
1 year ago Just thought of something else - assuming a miscreant has found a way to get in as an admin user into the WordPress interface, then they could simply (ha!) disable the plugin, do their nefarious stuff and then re-enable the plugin before they leave. Hence, I think at least trying to disable the plugin from the Web interface should be trapped and require the same password I mentioned that protected the rsyslog settings/Clear Log button.
Trinity12nl
For auditability, it would be useful if Simple History had some configuration options to enable remote logging. This is usually done to an rsyslog server, so you'd enter the name/IP of the rsyslog server, the port number (usually 514) and whether it was TCP or UDP (usually it's UDP). I think the problem might be stopping an admin user from changing those settings and disabling the remote logging. It's the same reason that the "Clear Log" button is dangerous and severely hampers the auditability of Simply History - once someone gets in as admin, they can clear the log at the end of a session and hide all evidence of current and past sessions (not just their own sessions either!).
Maybe the remote logging settings (and "Clear Log" button) should have a password field on them as well - the password would be added on first-time setup of the remote logging. Note that you probably still want to log to the local database as well (since you can't query the remote logging server to get previous entries) - the "Clear Log" button (hopefully now password-protected) would only apply to the local DB logs of course.