Resolve security misunderstandings with end-user public file uploads

[asmecher]

Description of the issue

There are two features that allow end users to upload files inside the public files directory:

• User profile image uploads
• TinyMCE image uploads (e.g. for the user's Biography field)

In the wild, people have registered for accounts in OJS/OMP/OPS and used these features to upload images claiming to have hacked the site. These have caused IT departments to overreact, believing a hack has occurred.

There are numerous support forum threads discussing this:

• https://forum.pkp.sfu.ca/t/ojs-2-4-8-suspected-hacking-incident/31292
• https://forum.pkp.sfu.ca/t/need-help-for-hacking-problem-in-ojs/60951
• https://forum.pkp.sfu.ca/t/ojs-3-0-2-hacked/32632/5
• https://forum.pkp.sfu.ca/t/problems-with-hacking-to-my-site-ojs/38776
• https://forum.pkp.sfu.ca/t/profile-upload-issues/45840
• https://forum.pkp.sfu.ca/t/defaming-journals-by-taking-advantage-of-user-profile-image/47314
• https://forum.pkp.sfu.ca/t/defacement-ojs-3-1/38541
• https://forum.pkp.sfu.ca/t/how-to-prevent-malware/67021
• https://forum.pkp.sfu.ca/t/hacked-public-dir-not-files-using-tiny-mce/33621
• https://forum.pkp.sfu.ca/t/how-to-prevent-direct-access-folder-and-file-through-url/73705
• https://forum.pkp.sfu.ca/t/help-with-hacked-site/33357

PKP has discussed the issue in a blog post. However, we are still receiving reports.

Work-arounds

There are several work-arounds available:

• Control Public Files plugin, which allows role-based control over TinyMCE image uploads: https://github.com/pkp/controlPublicFiles
• Setting public_user_dir_size to 0 in config.inc.php to disable TinyMCE-based user image uploads

However, user image upload capability is a useful feature and disabling it is not a good solution.

Information Needed

What is the difference between OJS/OMP/OPS's image upload feature, which is causing worry among IT administrators, and other image uploads (like a Twitter profile image or a Discourse forum image) that do not raise these concerns?

Candidates:

• Is it the user-specified image filename?
• Is it the image file being served directly from the filesystem?
• Is it the IT department's unfamiliarity with OJS?
• Is it the lack of hot-linking protection (see e.g. this document)?
• Something else?

Related Issues

• Change web root from application root directory for security #1832
• There was a Bugzilla issue filed long ago (which I cannot find) that proposed removing the public files directory entirely, favouring PHP-mediated access to "public" content in the files directory.

[NateWr]

The TinyMCE image upload feature uses the public files API endpoint. This endpoint is open to any registered user. So while the TinyMCE editor is the source of most of these files, in theory any registered user can upload a file to it. They do not need to use TinyMCE.

As Alec said, I think our three main use cases are:

1. Many journal managers use the TinyMCE uploads in about the journal, editorial team, and other journal content areas.
2. Some journals use the TinyMCE uploads in user biographies. This is mostly for authors, I think, but may include editors.
3. In the future, we want to use the user profile images in the editorial backend. This would be for editorial staff (managers, subeditors, assistants).

I'd like to explore some sensible default settings for the public files which will limit misuse while keeping the feature available for these use cases. For example, can we limit public file uploads to certain user roles? Should we require email addresses to be validated by default (configuration option is off by default now)? Do we require some meaningful activity (like author with at least one submission passed desk rejection) before allowing access?

[mfelczak]

For me, OJS/OMP/OPS are conceptually different from public platforms like forums and blogs. All published content in OJS/OMP/OPS is reviewed and approved to some extent by an Editor. The notable exception here is image upload by anonymous users since images are immediately published and available via a public URL. There's no means for OJS/OMP/OPS users to flag inappropriate images or for JMs/PMs to monitor, moderate or remove images once they've been uploaded.

My vote would be to remove the ability of anonymous users to publish images via a public URL and to align this feature set with the moderation requirements at the core of OJS/OMP/OPS that require oversight for content that is publicly published.

At the moment there are no reader-facing features that rely on anonymous profile photos. If we want to continue to support anonymous profile photos, these could still be selectively displayed on pages that require them, e.g. user profile page, but via a user session as opposed to a public URL.

For trusted roles, including JMs and Editors, there would still be a benefit to not using public URLs for profile photos. For example, Editors may want to use profile photos internally as visual cues for managing submission assignments, but this wouldn't imply that these team photos should be publicly accessible. Typically this sort of private/public distinction is managed and set by each user in the user profile settings.

For Author verification, email address validation seems insufficient to me since it'll still be easy for anonymous users to complete this step.

[NateWr]

anonymous users

How should we distinguish between an "anonymous" user and a trusted user?

[mfelczak]

Hi @NateWr, could we adopt a role-based approach as you suggest? JMs, Editors, Assistants as trusted roles and Authors as untrusted by default until certain conditions are met, e.g. initial pre-review step completed by an Editor? Since it's possible for anonymous users to register as Authors and Reviewers it seems like trust needs to be established before additional workflow actions are granted.

[NateWr]

That makes sense to me. From a performance perspective, I'm thinking we want to have a column in the user table, trusted, that is null. Then we can trigger a switch from untrusted to trusted at certain moments. The admin can edit the user to set it to false or true. Then we'd have the following events:

1. When an "accept" editorial decision is recorded, the author is set to true if they are not already set to false.
2. When a reviewer accepts or declines a review request, the reviewer is set to true if they are not already set to false.

We would need to do some more research to figure out how to handle the accept decision in OPS. But we could trigger this when the article is moderated or published.

This would probably be a good use-case for our new events system, since we can have one event listener respond to several events with the same action.

Some other considerations:

• We'll need to update the user profile form to only show profile image to trusted, enabled users.
• An upgrade migration will need to calculate which users are trusted and set that flag.

@asmecher I get the sense that you've been keen not to go too far down this route. What do you think about this proposal?

[ctgraham]

Internal and community interest in exposing the profiles of editors (read: trusted users) was enough for Pitt to author and maintain the Editorial Bio plugin. Notably, the author profile image was a specific feature request. We use the role assignment of Manager or Editor as proxy for this trust in the plugin. I concur that "trusted" users ought to be able to upload images for public use, and that images in the context of discussions and submissions would be better stored in the private files area.

[tmrozewski-york]

My vote would be to remove the ability of anonymous users to publish images via a public URL and to align this feature set with the moderation requirements at the core of OJS/OMP/OPS that require oversight for content that is publicly published.

From my perspective providing admin support to editors for a couple dozen journals: there's very little (if any) reason for any user who isn't an Editor or Journal Manager to upload an image via the TinyMCE editor. I reported this bug (which led to this issue being created) and the instances of this vulnerability that led me to report this involved using the Comments to the Editors field in the submission process. Again, images are absolutely not required there. If an image is vital to a submission, it can be included as a submission file.

For this reason, I think it would be most effective to restrict adding images via TinyMCE to Editors and Journal Managers. No need to introduce the new concepts of anonymous vs. trusted users.

[dagosalas]

I think that, with the implementation of the Library (and the latest update that allows file replacement), file uploading from the editor should be limited to editors only.
In OMP, I (as an editor) use it to add the authors' images in the biography.

If an important point is the profile picture (which I don't see the use of yet) you can use Gravatar, which has a public picture that is compatible with several sites.

[jonasraoni]

Another thing that came to my mind... If a user uploads sensitive content (let's say a pirate movie) through the submission files, even though the files are not publicly accessible (unless the user share his login and turn it into a kind of Google Drive), is the host responsible for storing it? 🤔

[asmecher]

I think that's out of scope for this discussion -- this is just about public files.

[shantanu198713]

During the uploading of the image by the user in the public directory, a URL is generated and the full path to the public folder is provided. By using this path one can directly access the uploaded image.
I think it should be hidden and the image/file should be renamed during uploading.
And there should be limited access for users of this type of access.

[asmecher]

By using this path one can directly access the uploaded image

This is the intended function of the feature. Do you have a different proposal?

And there should be limited access for users of this type of access.

This ability is provided by the plugin linked in the description above (https://github.com/pkp/controlPublicFiles).

[HusnaKarisma]

Hello i was install (https://github.com/pkp/controlPublicFiles), but i don't know where the config page to use this plugin please help ! thank u

[asmecher]

@HusnaKarisma, the best place to get support is on our support forum: https://forum.pkp.sfu.ca

[ctgraham]

The largest pain point for us is that there is no way for a Manager or Editor (or even the user themselves) to delete a file uploaded to the public files. This means that when a user abuses uploads, only a system administrator with read/write directly to the filesystem is able to remediate the unwanted content.

[NateWr]

I may be drifting away from the original issue, here, but I have long wanted to turn the Publisher Library into a more generic file manager. The TinyMCE editor could upload to and make use of images in that library. Then editors could discover and delete files that aren't used anymore.

For the library to serve this purpose some work would need to be done to improve its UI, as well as clearly distinguish between public and private files.

[marcbria]

Pues perdonad si no es una propuesta popular, pero yo cortaría por lo sano y solo dejaría subir imágenes de perfil a:

• los autores cuyos artículos han sido admitidos a revisión.
• los revisores que hayan realizado ya alguna revisión.

A su vez, no veo ninguna necesidad de ofrecer la posibilidad de cargar imágenes via tinyMCE en campos de texto a roles que no sean del staff de la revista.

Para mi es mucho más importante que OJS se perciba como una aplicación segura (se que lo es, pero los rumores son tóxicos) que permitir a un usuario subir una imagen en la bio (funcionalidad que, por cierto, nunca he visto usar bien).

[ctgraham]

Haz clic aquí, y ahora has visto un buen uso de la funcionalidad.

[marcbria]

Si es un buen uso, pero eso son páginas construidas por usuarios confiables (editor o staff).
Lo que digo es que yo retiraría esa opción a los usuarios que NO lo son.

Como decía "retirar la funcionalidad a todo usuario que NO sea el staff de la revista" o que no tenga cierto grado de verisimilitud (autor con artículo real o revisor con revisión asignada).

¿Estaríamos de acuerdo con esto?

[ctgraham]

Claro que sí.

[jnugent]

Hi everyone, I'm not sure if this discussion is still relevant, but I wanted to mention that while the TinyMCE image upload uses the API, the "profile image upload" field on the public profile page does not. This means that while the controlPublicFiles plugin can prevent image uploads in TinyMCE, malicious users are still capable of defacing the site via the regular profile picture upload.

[bkawula]

We're dealing with this problem too, where we keep getting panicked emails from central IT departments from various institutions. The controlPublicFiles plugin works, but doesn't solve the problem. Also, it needs to be enabled and configured at the journal level vs system wide and inherited by the journals. I think simply disabling all image uploads for anyone with only a reader / author / reviewer role would 100% solve this problem. I've never seen a journal that uses an author's profile picture.

[bkawula]

So we decided to try blocking direct access to images as outline here: https://techexpert.tips/apache/apache-blocking-direct-access-image/ This leaves the option to upload images available for all users and counters the approach that these "hackers" are taking where they're just looking to have a public link with the journal's domain.

I'm assuming that any images uploaded through the profile pic form, or any of the text boxes at the reader / author / reviewer level are never displayed anywhere publicly on the site.

[NateWr]

I'm assuming that any images uploaded through the profile pic form, or any of the text boxes at the reader / author / reviewer level are never displayed anywhere publicly on the site.

Not in the core application or any of our official themes. However, some custom themes display them in author bios. Also, in the future, we expect to use these as avatars in the editorial workflow, similar to how GitHub uses avatars to display assignments. These will most likely only be used with editorial roles.

[jnugent]

The approach that Bartek is attempting here will still work in this case, because any embedded image will still have a referring document. Preventing the display of images with no referrer will stop "hackers" from sending unsolicited links to editors.