Security Considerations

1. web-exploitable vulnerabilities
2. employee-exploitable vulnerabilities
3. locking down access to only what your staff need
4. good password policies
5. remote access to the backend
6. Mysql setup / passwords.
7. antivirus
8. firewalling
9. dependencies/packages

1 web-exploitable things. e.g. weaknesses in the career portal. I don't use the career portal - never have - it's incredibly useful but also the most obvious weakness - it's a web front-end to a critical system (good that you're taking nightly offsite backups!). I export an XML feed to a wordpress jobs plugin instead. This doesn't make opencats particularly more vulnerable than any other product but there are precautions you need to take.

• Cross-site scripting vulnerabilities and dodgy attachments. Cross-site scripting is mitigated for the front-end. Can you upload a php or python script as an executable? There is configuration described here for an effective htaccess file to prevent dangerous file attachments (scripts) from being uploaded (instead of cv's, or passport photos). https://github.com/opencats/OpenCATS/wi ... .htaccess)

**if you didn't set your directory permissions properly and htaccess restrictions when you installed the app, you might find that I can upload anything to your opencats install, and then am able to execute it on your webserver :shock: ..so make sure your directories have the right owners and permissions and that htaccess is blocking someone browsing your directory structure from the web.

2. employee-exploitable vulnerabilities. The backend of opencats has more forms to fill, more vulnerabilities etc - there is a known deserialisation vulnerability that is as yet unpatched at the backend (exploitable by employees only). The POC patch for this is here, not yet in the release; https://github.com/opencats/OpenCATS/pull/534 I'm never entirely convinced by back-end vulnerabilities, after all employees could just as easily delete all your candidates and vacancies if they have normal access.. so whilst this is a fix, it's not being rushed out.

3. locking down access - or "the rule of 'Least Privilege'" as my day-job corporate calls it - users should really only have the access they need for their job. As this applies to opencats - there is an access control feature available (in config.php) - and users can be assigned access levels and different parts of the app can be locked out for their role. Again - depending on the size and trust within the company this may or may not be a feature worth deploying. For example - I've disabled candidate/client export across the board. It's not through the ACL system, I just commented out the option. We don't need that exported, so I've removed the feature. Otherwise personally I don't have ACL restrictions deployed.

4. good password policies. Of course change the default password! make sure it or any other password isn't easily guessable.. or used on any other site.

5. remote access to the backend.

Whilst I'm not aware of any exploit allowing web-based users gain access to the backend - there's nothing preventing a malicious person running a dictionary attack if they find the backend webpage. There's no opencats logging for failed login attempts..

Your SSL certificate is good, and I used to protect the web-accessible backend with Apache Basic HTTP authentication.. simple and then it will log failed login attempts to the apache error log. You could/should then run something like fail2ban to monitor your apache logs to automatically block remote users who repeatedly get a username/password wrong.

That's still a good solution but now I have all backend access only accessible via a vpn tunnel for remote users. Again - depends on your needs and how much effort you want to put in. btw - i use wireguard vpn - very good, simple to setup, works on multiple clients - windows, android, linux etc. Primarily I changed to allow remote employees to use ip softphones whilst working from home so the change wasn't driven by an weakness in Basic Auth.

6. Mysql usernames / passwords. make sure the database password is unique and suitably complicated.It's not an encryptable thing really - again it's more important that the database and opencats table are only accessible by the admin account and an opencats account. Do you have old 'test accounts' hanging around? Do you restrict the opencats account to localhost? Can I reach an open port for mysql from the web and try to exploit that? Does the opencats account have more rights than you want it to have?

7. antivirus You have users documents being uploaded daily from anywhere around the world - please have some antivirus product scan your uploads and attachments directories at least daily.. If you're running linux, you can setup clamav to scan automatically and block/alert if it find anything.

8. firewall if you're running on aws or docker or your own server - the only web-accessible ports should be 80 and 443. Lock the rest down! I don't want anyone to try and directly log into mysql from the web!

9. test packages in the default build that are explotable. The automatic build includes test packages that are needed for the Travis CI integration, if these are reachable publicly, they can be exploited. *need to update this with a list of subdirectories that can safely be removed, AND update the build info to script their removal from future builds before release.

Finally - you've got a backup process exporting the mysql database, make sure you're including the opencats directory as well - all those cv's/resume's in the attachments directory need to be backed up, too.

I'm not trying to worry you about opencats in particular, these are all 'good basic steps' if you're using any application in the core of your business that is also exposed to the web. If you're the only person using it, and it's running on a server under the desk that has no remote access.. you probably don't need quite as much!