Please see https://pkp.sfu.ca/ojs/README, https://pkp.sfu.ca/omp/README, or https://pkp.sfu.ca/ocs/README to ensure that the software install directory and /files folder are configured securely on your server.
In general, the /files folder should not be web accessible and should be placed outside of the main software install directory. The software application will manage access to private submission files based on user roles and permissions (i.e. Editors will have access to all submission files, whereas authors will only be able to access their own submission files).
In addition, to ensure security the /files folder should not be readable by other users on the server. Only the webserver should have the necessary read/write permissions so that OJS, OMP, or OCS can read existing files and add new files to the folder, e.g.
drwxrwx--- 6 ojs www 204B 11 Sep 2017 files/
It is recommended that you install an SSL certificate for your OJS, OMP, or OCS install and ensure that your site always uses the HTTPS protocol to manage user registration, login, and to present content to readers. Once your SSL certificate has been installed and is confirmed to be working (i.e. you can access your site via https://myjournal.org) you can configure your site to always use HTTPS by using the following setting in config.inc.php:
; Force SSL connections site-wide
force_ssl = On
You should also set the base URL to use the HTTPS version of your journal, press, or conference:
; The canonical URL to the OJS installation
base_url = "https://myjournal.org"
To ensure that password reset requests from users produce random, secure passwords, ensure that you set a long, random salt in config.inc.php:
; The unique salt to use for generating password reset hashes
salt = "sdlkjfhleiqwrfgbksdlkjgbelruywoeiyt7384gdqlywqvlwjf"
Section Contributed by Kenton Good
A secure deployment of PKP software can be best achieved by using the following recommendations, which are described in docs/README in every download of the software:
If these steps are followed, you will substantially reduce the risk of falling prey to common hacking techniques. If already running OJS, OMP, or OCS, we strongly urge you to review your existing configurations and ensure these steps have been followed.
Authors, reviewers, and editors deal with submission files from people they 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.
Section Contributed by Kenton Good
Using SSL/TLS encryption to secure your site brings advantages in security, privacy, censorship protection, search engine findability, and data integrity.
Google announced in 2014 that https would be treated as a ranking signal meaning web sites that are served under https will be more findable within the Google index than those served under http.
A certificate enables a secure connection from the user’s Web browser to the server hosting your site. Installing a certificate for your site can not be done within the OJS, OMP, or OCS software and will require technical expertise or assistance at the server level. When considering a software host, determining their level of certificate support is an important consideration.
A good start is asking your hosting service provider if they have an existing solution for supporting TLS or SSL certificates – Your hosting provider may be able to create/issue an TLS or SSL certificate for you. If you do not have shell access to your installation this may be the only way to go about adding SSL/TLS protection for your site.
Purchasing a certificate may be an option available to you as well. Commercial businesses that provide certificates are called Certificate Authorities (CA). Wikipedia provides a listing of CA providers by market share. In addition to providing certificates that enable encryption, traditional CA issued certificates offer several advantages including customer vetting to help validate customer identity, and wildcard certificates. Depending on what features you select with your purchase, CA issued certificates can cost $100s per year and must be renewed before expiry.
Let’s Encrypt is a popular option for obtaining subscription as well. Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. It is a service provided by the Internet Security Research Group (ISRG). Certificates are provided for free, with some limitations:
Required step to generate a certificate if you are going to be purchasing a certificate from a CA that is not Let’s Encrypt. In terms of how to do this, this varies from one Linux distribution to the next, some common Linux examples can be found here:
When you purchase a certificate from a CA, you will typically purchase a certificate that lasts between 1 to 3 years. Certificates are set to expire and will need to be renewed resulting in a new expense at the time of renewal. Let’s Encrypt certificates expire every 90 days. The Let’s Encrypt software (certbot) can be configured to automatically renew certificates before they expire. Meaning once installed you should have minimal maintenance moving forward. Automation is done with cron or systemd.
There are a number of configuration steps you can take to combat SPAM and other forms of malicious registration activity on your site.
Configure a CAPTCHA and enable it for user registration, notifications and commenting. We strongly advise using Google’s ReCAPTCHA. (Older OJS 2 versions include a PHP captcha, but that has proven to be less secure than ReCaptcha.)
If you are using OJS older than 2.4.8-3, you will not be able to use the most recent version of ReCAPTCHA (v2), and your ReCAPTCHA will not work properly after March 31 2018. Upgrading is strongly recommended.
To configure ReCAPTCHA:
[captcha] section of config.inc.php:recaptcha_public_key = 123456abcdef
Recaptcha_private_key = abcdef123456
Don’t forget to test this setup by registering a test account and confirming that a) the ReCAPTCHA appears and b) the ReCAPTCHA properly validates.
OJS, OMP, and OCS can be configured so that an email account validation step must be completed for all new user accounts before they can log in and interact with the system. To do this, uncomment and configure the following lines in config.inc.php:
; If enabled, email addresses must be validated before login is possible.
require_validation = On
; Maximum number of days before an unvalidated account expires and is deleted
validation_timeout = 14
The above configuration will require all new registrations to click on a link and validate their account before being able to log in; and will auto-prune any non-validated accounts after 14 days.
If you have been the target a SPAM bot, enabling the above procedures may not be enough: you may already have a fair number of SPAM accounts in your system. The only way to “delete” users is to merge the problem account into another account using the Merge Users option. (This effectively deletes the problem user. Any submissions, editorial history, etc. from the problem user is merged into the other user account.)
This tool can be used via the UI, but it’s slow (and only OJS/OCS 2 currently have an option to merge more than one user at a time). A more effective method is to use the command-line tool:
$ php tools/mergeUsers.php username1 username2
… where username1 is the user that will be merged into, and username2 is the user to be deleted. As it is, this tool only works on one merge at a time, but it can be scripted. An example php script would be:
<?php
$names = file('/tmp/names.txt', FILE_SKIP_EMPTY_LINES);
foreach ($names as $member_name => $member) {
echo exec ("php /ojswebroot/tools/mergeUsers.php admin-user " .escapeshellcmd($member));
}
?>
The script expects all spam accounts to be identified by username and listed in a names.txt file, one name per line, like so:
spamuserOne
spamUserTwo
spamUserThree
…
The names.txt file has to be stored somewhere on the server and the location referenced by the script (eg. “/tmp/names.txt”). The script should also specify the location of the mergeUsers.php script (eg. “/ojswebroot/tools/mergeUsers.php”), and also the user into which all of these accounts should be merged (eg. “admin-user” - this must be an existing account). Update those parameters to suit your environment. And also: don’t store this script, or the names.txt file, in a web-accessible location!
Section Contributed by Kenton Good, and adapted from the PKP Community Forum
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.
Do you announce security vulnerabilities, and if so, where?
We do. PKP announces all valid security vulnerabilities, and their respective fixes when available, via the community forum1; our news blog4; via Facebook2 and Twitter1; and on our application download pages. All fixes are also published in our Github code repository1. 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.
I believe I have found a security vulnerability. How can I report it?
Please send a detailed description of the vulnerability to our support email: support@publicknowledgeproject.org. We will respond to you as quickly as possible with an evaluation of the vulnerability. If it is in fact a vulnerability within OJS, OMP, or OCS (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.
My journal has a ton of spam registrations. Is there anything I can do about this?
Yes - you can enable your site’s 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). You can also turn on email validation in your config.inc.php file to enforce registrants to verify their account via an email link. Non-validated accounts will be automatically deleted after a number of days, which you can set. See require_validation and validation_timeout in the config file.