Support

The correct approach is to follow the “How to determine which exceptions are required” troubleshooting documentation page.

If you get lost somewhere, we can do this together. In this case, I will need you to reproduce the problem. On that page with the problem, open your browser's developer tools (on Windows and Linux hit the F12 key). Go to the Network tab and reload the page. You will see a number of resources on your site which are red and when you click on them it tells you that the HTTP status was 403. Tell me their URLs so I can help you create the necessary exceptions.

I believe that you will need to add a few folders into the “Allow direct access, except .php files, to these directories” option in the .htaccess Maker. I believe that you need to add exceptions for both the file where the PDF files are stored, and the folder where the embeddable PDF reader's JavaScript files are stored in (assuming they are not under the media folder).

You're welcome! If you get stuck somewhere, give us a holler!

If only this .php file is needed add

plugins/edocman/viewpdf/ospdfjs/web/viewer.php

to the “Allow direct access to these files” option.

However, I suspect that there are more files this reader pulls up. So, if that fails, do add

plugins/edocman/viewpdf/ospdfjs/web

to the “Allow direct access, including .php files, to these directories” option.

"Please change permission of files in folder: "root -> plugins -> edocman -> viewpdf -> ospdfjs -> web" and "root -> edocmanviewer" to 777

Jesus wept! No, do NOT change the permissions to 0777. For the reasons see the old, but always relevant, article I wrote back in 2010: https://www.dionysopoulos.me/777-the-number-of-the-beast.html.

Using 0777 permissions to address a read permissions issue is never, ever the right solution. If it was a permissions issue the far more sane, and infinitely more secure, 0644 would still do the trick. Having someone recommend 0777 permissions tells me that this someone understands neither how UNIX permissions work, nor the absolute basics of web site security. I am immediately skeptical about this extension given that its developer has failed at Security 101 in his reply to you…

Do you have other tips on determining what additional files may used by the viewer? Reading through the viewer.php file I do see a few .js files called, but they are in the same directory as viewer.php, which was added as an exception. Do I need to add these .js files individually?

No, you do not need to whitelist specific files. As long as you have their containing folder (or any of its parent folders) to the folders where any file access except .php is allowed then they are allowed to be loaded.

Do you see anything else that throws a 403 or 404 in the Network tab of your browser tools when you try loading the PDF viewer?

Moreover, do you see any other messages in the Console tab which indicate that the browser's security settings, or a Content-Security-Policy header, may be blocking the execution of some JavaScript?

The first 404 we have is for an SVG file. If that file actually exists add document-library to the “Allow direct access, except .php files, to these directories” option.

The next 403 has a URL as a URL parameter. This is blocked by “Protect against common file injection attacks”. Turn that off.

You do not have a problem with CSP (Content-Security-Policy). The CSP you get for the .php file is unsafe-url which allows everything. The CSP you get for the SVG file is correctly set to strict-origin-when-cross-origin to block external scripts loaded by the SVG file (SVG files can run JavaScript).

Does disabling this feature, open our site other malicious attacks? Are there alternative methods that the developer of this extension could employ to avoid using a URL as a URL parameter?

Philosophically speaking, yes, it does.

This feature blocks any URL GET parameter which looks like a URL. The idea behind it is that there are some kinds of attacks which hinge on the local inclusion, or parsing, of a remote resource passed to the script as a URL.

For example, there are some (badly designed) scripts which will include whatever random JavaScript, or SVG file you give them as a URL parameter into the generated HTML. This allows the attacker to host the actual hacking code on their server and trick you into running it with a URL on your site, making phishing trivial.

As another example, it's possible that a script needs to parse an image and there's a known but unfixed bug in PHP, usually because the site is using an end-of-life PHP version and the bug is in a third party library which has not (yet) received a fix in the Long Term Support Linux distribution the server is running. Therefore, an attacker could host a malicious, suitably crafted image on their own server and access a specially crafted URL on your site to run arbitrary code on your site's server.

You might wonder, but why are we not explicitly allowing URLs on your own site? The thing is, Joomla (and WordPress, and Drupal, and really any kind of CMS, e-commerce solution, etc) is not a sealed system. It allows user uploads. It is possible for someone to upload something malicious which, by itself, doesn't look malicious (or cannot be correctly assessed without a VERY expensive, very well trained security professional tearing it to bits) but can become malicious using a variation of the vulnerabilities I described above. Therefore, just because something is hosted on your server doesn't make it automatically safe and for this reason we can't allow it by default. Putting an option to allow that kind of behaviour is equivalent in most cases to turning off the entire feature altogether, hence the lack of such an option either.

So, there you have it.

The correct (as in: secure) way to handle use cases like yours —displaying a PDF from a known-good location— is to pass an identifier to a CMS extension (Joomla component, Joomla module, WordPress plugin, etc). The CMS extension will look it up in the database and correlate it with a known-good resource. It will then construct the HTML with the URL to the safe resource and serve it to the browser. Of course, this requires the developer to not be lazy, understand what they are doing, and above everything else write their code defensively. Unfortunately, 90% of the Joomla extensions and 99.9% of the WordPress plugins I have seen are a far cry from being anywhere near the same universe as defensive coding.

You're welcome, Eric!