OJS is 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). 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
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:
The small number of these, historically, is testament to our caution in keeping our software secure.
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.