[OJS 3.x] Misuse of profile image may cause legal action

Hello all, @asmecher, @NateWr ,

I didn’t want to bump this topic, but it’s a matter that needs to be addressed somehow.

We received an “invasion” warning from network security services, about a user boasting having hacked our server. All they did was post a PNG on their profile with the content saying they hacked us (ojs/public/site/images/username/file-name.png, for example!).

Unfortunately, OJS can be misused and cause a lot of trouble (including prosecution for hosting illegal content). If a SPAM user posts a pornographic image on their profile and disseminates the link in their social media, our server becomes a target, which attacks our institution’s image.

So, we are legally responsible for anything users do or are allowed to do in our domain.

OJS could allow us to disable user profile image upload, or remove this from user profile, so that this kind of disturbed behavior is prevented. Also, most users don’t use that field, in our experience.

Nonetheless, this could be allowed in the article page, during publication, which would be more secure as only authorized content would be published. It could be published in the abstract page, with author info, in the metadata sidebar. So, the photo would be of all authors, and not just the author that submitted the article.

Hello all, @asmecher , @NateWr ,

I found the Control Public Files plugin and installed it.
However, this doesn’t prevent users from uploading a fake photo, so we commented the specific line on the user public form template.

Yeah, we don’t consider this a security exploit, just a hazard of running an application on the web. I can do the same thing, for example, in Twitter. But I think that some people have shut this off. @ctgraham did you have a plugin that disabled the user profile image?

we commented the specific line on the user public form template.

This will hide the function and may deter some malicious users. But it won’t prevent a file from being uploaded. For this, you would want to modify the ProfileTabHandler::uploadProfileImage() method, or write a small plugin that used the LoadHandler hook to identify such requests and block them.

We do not have a plugin that blocks user image uploads, but we are seeing some renewed abuse of spam accounts uploading images as a “hack”.

In OJS 2.x the journal manager could login as the user to remove the spurious image, but in OJS 3.x that ability is no longer present, so we’re thinking about a way to make this self-service for the journal managers again.

Hi all,

Since OJS/OMP/OPS 3.2.0, you can turn off profile image uploads using a configuration file setting. See: Need help for hacking problem in OJS - #4 by asmecher

Alec Smecher
Public Knowledge Project Team

Hello all, @asmecher , @NateWr ,

Thanks for all the replies.
I installed the controlPublicFiles plugin. It’s available in the plugin gallery.

Would setting public_user_dir_size = 0 prevent admins and editorial teams to upload files?

We understand this as not being a hacking situation. However, we are becoming increasingly concerned with possible legal actions when dealing with sensitive content. There is a rise in legal actions against public institutions regarding hosting that should not be published. Unfortunately, misuse is the most common problem of the Web.

Hi @ramon,

A service provider getting sued without an opportunity to remove an offending image first seems unlikely, but if you want to avoid the potential of liability totally, I suggest disabling the feature.

Alec Smecher
Public Knowledge Project Team

Would setting public_user_dir_size = 0 prevent admins and editorial teams to upload files?

Yes, it also wouldn’t have any effect on the public user profile image. (see my next post) The controlPublicFiles public only handles files uploaded through the TinyMCE editor.

The following code put into a plugin should block uploads requests for the user’s public profile image:

HookRegistry::register('LoadComponentHandler', function($hookName, $args) {
    $component = $args[0];
    $op = $args[1];

    if ($component === 'tab.user.ProfileTabHandler' && $op === 'uploadProfileImage') {

Sorry, I misunderstood the the question about public_user_dir_size. Setting that to 0 should block the public profile image upload, too. It will effect all public images, though, which include those an admin or editor can upload through TinyMCE.