OJS, OCS and OMP are all web-based applications that allow users to create accounts and upload content, including files, to the web server. As such, the security of each application must be taken seriously - by the developer (that’s PKP), and by the end-user (that could be you, your university, or another hosting service such as PKP Publishing Services). In this FAQ entry, we address:
- The steps PKP takes to develop secure software, and how you can help
- Best practices for deploying PKP software securely
- Recommended practices for appropriate file management and “internet hygiene” as a user of the system
- Other common questions or caveats
1) The steps PKP takes to develop secure software, and how you can help
PKP follows standard best practices for web security, including consistent use of escaping to avoid XSS attacks, tokens to prevent CSRF attacks, etc. We stay abreast of recent trends in security, and wherever possible, use best-of-breed third-party tools with large communities of support. Our software includes structures to permit authorization policy recombination, ensuring that sensitive content is not exposed beyond the amount required for a scholarly workflow. We are responsive to bug reports, security audits, and community inquiries and welcome any such contributions. We disclose serious security issues, when they are discovered, via each applications’ software download page:
OJS: https://pkp.sfu.ca/ojs/ojs_download/
OMP: https://pkp.sfu.ca/omp/omp_download/
OCS: https://pkp.sfu.ca/ocs/ocs_download/
OHS: https://pkp.sfu.ca/ohs/ohs_download/
The small number of these, historically, is testament to our caution in keeping our software secure.
We welcome code contributions via our Github code repositories, or privately via our support email. When contributing to PKP software, be sure to follow the guidelines and recommendations on our wiki. Code contributions are subject to a peer review process before merging, and this review includes considerations for security.
2) Best practices for deploying PKP software securely
A secure deployment of OJS can be best achieved by using the following recommendations, which are described in docs/README in every download of OJS:
- Dedicate a database to OJS; use unique credentials to access it. Configure this database to perform automated backups on a regular basis. Perform a manual backup when upgrading or performing maintenance.
- Configure OJS (config.inc.php) to use SHA1 hashing rather than MD5.
- Enable captcha or recaptcha in your config.inc.php file, and test that they are working. This will prevent most spam user registrations.
- Configure OJS (config.inc.php) to use force_ssl_login so that authenticated users communicate with the server via HTTPS. (You will also have to properly create and configure an SSL certificate to do this properly.)
- Install OJS so that the files directory is NOT a subdirectory of the OJS installation and cannot be accessed directly via the web server.
- Restrict file permissions as much as possible.
- Deploy and test a proper backup mechanism. The backup mechanism should back up the database, the OJS system files, and the OJS submission files directory (the “files_dir” parameter in config.inc.php. Ideally, you should make both on-site and off-site backups.
- Ensure that your web server environment is regularly updated, in particular with any and all security patches.
If these steps are followed, you will substantially reduce the risk of falling prey to common hacking techniques. We strongly urge you to review your existing configurations and ensure these steps have been followed.
3) Recommended practices for appropriate file management and “internet hygiene” as a user of the system
As an author, reviewer, or editor in OJS you deal with submission files from people you don’t know on a daily basis, and there are some basic precautions that you will want to take to mitigate the possibility of being compromised via one of these files. These steps don’t differ from how you would deal with email or other daily life on the internet, but are worth outlining in general form here.
Make sure you have antivirus software installed, and that it is up to date;
Make sure your operating system and all software (especially Word and Excel) are kept up to date, ideally by turning on any auto-update features available to you;
Make sure you have a backup solution available for your work computers;
Practice good password management: don’t use the same username/password in OJS as you would for any other online account, and don’t use an easy to guess password;
Treat everything that you get online with the knowledge that you received it from someone you don’t know, and act likewise. If a submission appears to be suspicious for any reason (strange email address, suspiciously generic title or abstract, etc.), treat the included files with an additional level of diligence.
4) Other common questions or caveats
Below are some general questions we have answered more than a few times in the past, along with some responses. We will add to this list as we receive questions over time.
Q: Do you announce security vulnerabilities, and if so, where?
A: We do. PKP announces all valid security vulnerabilities, and their respective fixes when available, via the community forum; our news blog; via Facebook and Twitter; and on our application download pages. All fixes are also published in our Github code repository. In the event that a third party discloses a security vulnerability, we request that a public disclosure isn’t made until a fix is available, at which time we work with the third party to notify the public of the vulnerability, and the fix.
Q: I believe I have found a security vulnerability. How can I report it?
A: Please send a detailed description of the vulnerability to our support email: pkp.contact@gmail.com. We will respond to you as quickly as possible with an evaluation of the vulnerability. If it is in fact a vulnerability within OJS (ie. not a hack due to a general server/software misconfiguration, or a vulnerability in another software application, or something dressed up to look like a vulnerability, which believe me we do see on occasion), we will proceed with next steps: identifying and publishing a fix, and then disclosing the issue and fix to the public.
Another option is to submit an issue (and, if available, a patch in the form of a pull request) via Github.
Q: My journal has a ton of spam registrations. Is there anything I can do about this?
A: Yes - you can enable OJS’ captcha settings, which are found in your config.inc.php file. There is a regular captcha, and an implementation of Google’s Recaptcha which requires its own private/public keys (which you can get from Google - see the config.inc.php file for further instructions).
Q: How’s your security record?
A: Very good. We have had to disclose only 5 security vulnerabilities in our released OJS code since the original 1.0 release in 2002, for example. You can see all verified vulnerability disclosures, plus all record of their publicly released fixes, linked clearly on our various download pages:
OJS: https://pkp.sfu.ca/ojs/ojs_download/
OMP: https://pkp.sfu.ca/omp/omp_download/
OCS: https://pkp.sfu.ca/ocs/ocs_download/
OHS: https://pkp.sfu.ca/ohs/ohs_download/
If you have any further questions, please post them here and we will address them!