That’s a pretty controlled environment. OJS supports a tremendous number of server permutations:
Windows vs. *NIX-likes
MySQL vs. PostgreSQL
mod_php vs. CGI/FastCGI
Apache vs. IIS vs. lighttpd
…not to mention a tremendous number of variants, like SELinux and suPHP, and the many generations of different versions of each.
We’re a small team and a toolset to check deployments across the variants would probably take a significant fraction of our resources to do with confidence.
Regards,
Alec Smecher
Public Knowledge Project Team
All I am suggesting is a utility that checks the read write status against an existing OJS site at first.
Check location of cache folders against uploaded file location
Attempt an upload of a PHP file and see if it completes and try to read it back. If not, try to read back with the .txt extension, etc
Attempt to write to the other folders that should be marked read only.
Attempt to read directly from file locations where articles are stored.
And so on.
Keep it simple at first and see where it goes.
Hi,
I am not an IT people but I was using OJS for a journal I edit … for the paper submittal and reviewing
process mostly … unfortunately a hacker upload a .php file as a manuscript (in
2013)
I did not notice
Another hacker used this .php to hack the site!
The problem is possibly due to the fact we did not updated our version of OJS
since 2007!
…
Can you confirm it will not be possible today to upload a .php file instead of a
.doc or a .pdf?
Can I get a safe version of OJS today?
Can I easily upload ongoing manuscripts and reviews into it?
If I do not have an OJS version that blocks .php or .exe upload IT people in my university will not install it … and my journal will be a dead thing …
Thanks for letting us know.
Yours sincerely,
Bruno Granier
Carnets Geol.
I’ve removed the code you posted as it was flooding the forum.
OJS does not restrict file types for upload. This is done so that journals can include code as submissions.
The problem in your configuration is that your files_dir, the area where submission files are stored, was apparently publicly available via the web server. The installation form and README documentation cautions against doing this. Not only do you risk executable uploads being run on the server, but you also risk exposing legitimate pre-publication documents for download without access control. The files_dir must be kept outside of the web root, or protected using a mechanism like a .htaccess file.
OJS is safe to use if you follow the “Recommended Configuration” described in docs/README.
Regards,
Alec Smecher
Public Knowledge Project Team
In order to allow only doc, docx, and pdf extension files, and force other files than those ones to be converted into text file follow me.
Find below code from /lib/pkp/classes/file/FileManager.inc.php
For more security, rename files folder and located it somewhere else out the main directory. Also, disallow index to make it inaccessible directly from http.
As long as your files directory is outside the web root or protected from direct access e.g. using a .htaccess file, as recommended in the installation documentation, no changes are needed to prevent remote execution and OJS is safe from attack by malicious uploads.
I see no downside to the changes you’ve written, except that the .txt extension may cause confusion, but note that I don’t think the stristr test does what you intend as written. I believe you’d be able to upload a file called e.g. myFile.doc.phtml and it would not get caught by your check.
Regards,
Alec Smecher
Public Knowledge Project Team
@asmecher no you cannot upload “myFile.doc.phtml”, if you do upload it converts the extension to txt. I have tested it on ojs 2.74. Because the script below gets the last extension if there is two extensions.
function parseFileExtension($fileName) {
$fileParts = explode('.', $fileName);
if (is_array($fileParts)) {
$fileExtension = $fileParts[count($fileParts) - 1];
}
for a quick test run this php code in phpfiddle.
<?php
$fileName = "myFile.doc.phtml";
$fileParts = explode('.', $fileName);
if (is_array($fileParts)) {
$fileExtension = $fileParts[count($fileParts) - 1];
}
echo 'Original uploaded file s extension is '.$fileExtension;
echo '----------------';
if (!isset($fileExtension) || !stristr($fileExtension, 'doc') || !stristr($fileExtension, 'docx') || !stristr($fileExtension, 'pdf') || strlen($fileExtension) > 6 || !preg_match('/^\w+$/', $fileExtension)) {
$fileExtension = 'txt';
}
echo 'Converted file s extension is '.$fileExtension;
?>
You may be right – I haven’t checked this in detail. In any case, I’d recommend changing the way you’re using stristr so that the return value is checked more specifically. In any case, we’re unlikely to integrate a change like this because systems configured to expose files_dir contents still aren’t “safe” from a scholarly perspective even if malicious uploads are otherwise mitigated. OJS cannot protect files from direct download, including e.g. author uploads that haven’t been anonymized for peer review.
The best solution is to keep the files_dir outside the web root or protect it e.g. with .htaccess, as described in the documentation.
Regards,
Alec Smecher
Public Knowledge Project Team
Of course the best way is your guide, I agree. And I dont ask you to integrate my coding with core OJS. However, for journals that does not require any files except the manuscript itself - I mean additional supportive files such as dataset, figure, graphics, etc - my way is also applicable. Because the manuscript itself can be just in doc, docx, or pdf format. I just shared this code thinking that majority of journals just require the manuscript itself, but not additional files.