Defaming journals by taking advantage of user profile image

Feature Requests
,
1

Hello all,
Unfortunately, a single-user/organization/company or whatever has attacked a lot of our journals (OJS2&3) by registering and then uploading an inappropriate image profile. This has also been reported before.
This is not a hack or attack by definition, but, is taken very seriously by the non-technical users and journal offices and even indexing libraries. They don’t care how this happens or if it is possible in all online portals and forums; they just don’t want it to happen to them.

What I did was:

  1. deleted the images and the user from database
  2. modified the source-code to prevent uploading image profiles
  3. changed some url access rules on the server

But, this is not enough and evil users can still register and sabotage the website. captcha is not useful because this is deliberately done by a user and not a robot

Suggestions are:

  1. creating a user access history page in OJS, so the manager can track down which users registered today or changed their profile …
  2. approval of individual content changes (like changing profile pictures or biographical statements) by the manager
  3. moving the public folder out of the root folder (like files folder) and mediate the access through website url instead of exact path. only logged-in users should be able to see others’ profile and images.

Any ideas or similar experiences?

2

When you say it is not enough to delete the offending content, and to prevent new image uploads, what specific concerns remain?

Did you block just the user profile image, or did you block the user profile image and disable the TinyMCE jbimages plugin as well?

If both are disabled, there should be no way for a user to upload a public-facing image.

3

Just put the files folder in the root. They cant do anything then. Even mine was defaced once, but then i kept the folder outside and it has been safe then. Cheers.

4

There are a couple of distinct issues here:

  • Sites where the private files folder is accessible from the web root pose a security risk. (The attacker uploads a executable submission, and then asks the webserver to run it.) This is mitigated by appropriately configuring the installation per the README.
  • Even secure sites allow users to upload their own profile image, and some users are submitting inappropriate images. (The content generally includes text claiming to have “hacked” the server.)

The second case is what @alirezaaa is describing.

5

Oh, thats new to me. I will tc as well then. Oh I read it again. Sorry my mistake in inferring the context. Gotcha. Thanks @alirezaaa

6

I have edited the profile tpl files and removed the section for uploading image profiles; but I am not sure if such susceptibility exists in other journal pages (the ability to upload an image in public folder whether from website interface or other methods and then get the exact path).

I have some pictures and logos on homepage content which is set from TinyMCE in settings page so I don’t want to disable it. instead, I deleted bio and changed affiliation to textbox field. I completely mutilated the profile page :frowning:

7

Ok, I understand. Unless you actually disable the jbimages TinyMCE plugin (at least for untrusted users) the techincal possibility to upload a public-facing image will remain (though it will be quite hidden from the casual users).

8

Hi all! We are soliciting feedback and proposals for hacking claims via image uploads on this Github discussion. Feedback would be welcome.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like