OpenCATS 0.9.4-3

Free, Open-Source Applicant Tracking System including job-board. Entirely customisable!

General discussion of OpenCATS

Moderators: RussH, cptr13

Forum rules: Just remember to play nicely once you walk through the door. You can disagree with us, or any other commenters in this forum, but keep comments directed to the topic at hand.
By donster22
#5068
Hi Good Morning,

I have OpenCats setup and working nicely but I'm just looking at security and privacy policies for my website and I'm not sure I understand a couple of things, if someone could offer some guidance?

I have an SSL certificate in place for the site which is hosted on AWS so I know that traffic to and from OpenCATS is encrypted but what about the database itself? I have a cron job which it exports it every night to my own server but is it encrypted? It doesn't seem to ask for a password and I can reimport it easily enough.

also, when we install OpenCATS it has a user "cats" and a password "password" is this connected to any security because it explicitly tells me not to change those parameters.

Thanks for any pointers. I've done a bit of Googling and found that mysql is encrypted but it also suggested MariaDB is not so i'm properly confused.

If there is no encryption on the database, how do other people deal with this?

Cheers, Don
User avatar
By RussH
#5069
Hey Don,

good post.. There's not enough consideration given to security in most installs.. and opencats can be more or less secure depending on how much inconvenience you want to put up with.
(I should probably make this a wiki page on github)

really - you need to look at (and this is an 'off the top of my head' list);
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


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!


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!

If anyone else has additional security measures, feel free to reply and share...
By donster22
#5070
Hi Russ.

That's one of the most comprehensive answers I've ever had on a forum.. thank you!

I shall work through those points tomorrow.

It's just me and my database so no employees to worry about and I don't have the career portal enabled so it sounds like I've removed quite a few problems from the start.

I only have HTTPS and SSH enabled, my passwords are complex and the server is running on AWS which is up to date.

I like the VPN solution. That would make me feel more comfortable.

I do need to upgrade to the php7 version and I'll brush up on my database knowledge but it sounds like I'm on the right track.

Last question for the day? The database password.... is that the "password" detailed in the database settings during setup (user cats)?

Cheers

Oh, also I need to backup attachments. Oops.
By donster22
#5071
quick update if anyone is interested.
I have implemented Russ's advice and also moved my database to Amazon RDS. It's also only accessible from a EC2 instance in the same VPC where OpenCATS is installed and that only accepts connections from my IP address (soon to be a VPN connection). RDS backs up regularly and has redundancies too.
Won't suit everyone but I think I'm happy with where this is at now from a numpty user's perspective (me).
Cheers.
User avatar
By RussH
#5079
Good to hear. From other folks here on the forum, looks like I need to update the documentation a little bit, too!
User avatar
By RussH
#5097
If any other person wants to contribute updates to the documentation project... it'd be very appreciated :D

I recently migrated my OpenCATS from a local Ubunt[…]

Thank you Russ. I was wondering if people had foun[…]

Browser Plugin - Google Forum

Hi @RussH this is still active, does it wo[…]