isnt there an htaccess to prevent that?

Is this a joke? ?

Well I think that motion suggests the complete oposite. Please explain why you think this would be the case. Details would be great.

And a site that does not support htaccess or web.config files would also have issues with SEF right?

As well as we have the core shipped with htaccess and web.config files in the vendor folder: https://github.com/joomla/joomla-cms/tree/staging/libraries/vendor

isnt there an htaccess to prevent that?

It is only reliable on Apache servers where use of those files is enabled. That config directive is not available on IIS (there is a separate file for that, assume IIS can also enable/disable processing these though) or NGINX.

Is this a joke? ?

Based on the wording of the motion, it is considered full path disclosure if someone were to direct access libraries/vendor/joomla/application/src/AbstractWebApplication.php because executing the file will attempt to load a class that cannot be found and emit a PHP error which will contain a file path of the web server is configured in such a way that it displays errors, matching the “FPDs outside of the CMS context (i.e. files that are directly accessible because they lack a JEXEC-Check, or files triggering compile time errors) will still be covered by the policy and fixed in security releases” criteria of the motion.. The default supplied web server directives supplied by Joomla cannot be considered full mitigation for this issue as they can be disabled and do not cover all platforms. So the only reliable mechanism is to alter all files to include a PHP statement to prevent execution unless accessed through an authorized entry point. Symfony and PHPMailer definitely aren’t adding these statements, and it is a major B/C break anyway to do so so adding them on 1.x Joomla Framework packages is out of the question. So unless someone has any other good ideas, to satisfy that production vote adequately requires forking all packages to add the relevant defined or die statement.

And a site that does not support htaccess or web.config files would also have issues with SEF right?

yes but based on the number of high profile sites I see out there that are still using SEF urls WITHOUT using URL rewriting its a real problem

The default supplied web server directives supplied by Joomla cannot be considered full mitigation for this issue as they can be disabled and do not cover all platforms.

Agree. Just to be clear this is only the case when the error level is set to maximum etc. which is not the default value for Joomla nor would it make sense to be a default value for any production webserver.

We also not have to argue on issues like we allow the public to upload images to the media manager as a security issue.

Also a FPD is not like that your site is hacked the other day.

yes but based on the number of high profile sites I see out there that are still using SEF urls WITHOUT using URL rewriting its a real problem

Well maybe we should reach out to them to find the reason that they don't do url rewriting? Do you have a list of sites? Please send it to me so I can try to contact them so we see what is missing for them to enable it.

Just because something does not make sense to the educated developer doesnt mean that the same is true for the web site owner

Just to be clear this is only the case when the error level is set to maximum etc. which is not the default value for Joomla nor would it make sense to be a default value for any production webserver.

Direct access means the files are not being loaded in the context of Joomla and any values defined in its global configuration do not apply.

Basically you’re saying the mitigation for this is to use a “well configured” server, which is highly subjective, and that NGINX users have no mitigation strategy other than server level configuration changes. So, why was the vote actioned as is if the end result is going to end up as “we know it’s an issue, fix your server because we can’t fix it in Joomla”, which was the status quo before said vote.

Just because something does not make sense to the educated developer doesnt mean that the same is true for the web site owner

Agree for that reason we have sensible default values for the core and the same do the webserver developers.

When you hosting provider decided to run error level development on the production server i'm not sure whether it is on us to help them?

When you drive a car without seatbelt and something is happening no one is suing the car company but the owner of the care.

When you hosting provider decided to run error level development on the production server i'm not sure whether it is on us to help them?

You are assuming everyone pays for a good hosting provider. Many people foolishly think they can do it themselves

Basically you’re saying the mitigation for this is to use a “well configured” server, which is highly subjective, and that NGINX users have no mitigation strategy other than server level configuration changes

Well the point is that they are only affected when someone took the explicite decision to configure the webserver insecure (error reporting to development in production). When this was done I dont see us fixing this.

You are assuming everyone pays for a good hosting provider. Many people foolishly think they can do it themselves

Sure. For that reason the default value for error reporting for the webservers is not development right?

Yes i know that xampp does it but that's a local server right?

It is also not that we state that we should never fix such issues but we do not threat them as security issues anymore.

You’re missing the point. Turning off web root level .htaccess does not make a server insecure. If I deploy Apache and put all config directives in the main httpd.conf file, Joomla’s .htaccess is never going to load. So the core mitigation strategy of shipping that file and requiring it to load is not suitable, regardless of what the PHP error reporting is configured as.

You’re missing the point. Turning off web root level .htaccess does not make a server insecure.

I have not said that. I only said when you configure (and i don't care where) that your production server runs on error level development you are doing something wrong.

Yes i know that xampp does it but that's a local server right?

Not necessarily

Well the point is that they are only affected when someone took the explicite decision to configure the webserver insecure (error reporting to development in production). When this was done I dont see us fixing this.

1. isnt it the display_errors thats the issue not the error level
2. show me where on the php.net web site does it say that it is insecure

Then JSST needs to publish a plain English post explaining the policy. The motion’s wording clearly indicates that direct access of files outside Joomla is considered FPD, yet your response on this thread seems to imply that this is only met if a server is “properly secured”. What is the actual criteria then for considering this FPD a security bug?

Then JSST needs to publish a plain English post explaining the policy.

As mention in the mail i sended you today this is being worked on to reflect that on the policies. Wording for non native people is hard but we try our best to get it right.

Any help on for any of you would be awesome. As you both are native speakers.

I still stand by my stance that the published motion wording means that it is FPD if Composer files are direct accessed and that the only reliable mitigation strategy is the same defined or die check in all other Joomla files. Otherwise, without actually understanding what it is that the project is trying to say with that motion, I don’t have any way of giving feedback on what it should say.

You know how to contact me or David via Mail or Glip so we get things right and clearly for all documented..

I still stand by my stance that the published motion wording means that it is FPD if Composer files are direct accessed and that the only reliable mitigation strategy is the same defined or die check in all other Joomla files. Otherwise, without actually understanding what it is that the project is trying to say with that motion, I don’t have any way of giving feedback on what it should say.

That feedback you gave is already very good. Thanks! So we can make sure that this is reflected in the final wording used.

The motion’s wording clearly indicates that direct access of files outside Joomla is considered FPD, yet your response on this thread seems to imply that this is only met if a server is “properly secured”. What is the actual criteria then for considering this FPD a security bug?

That was the idea.

without actually understanding what it is that the project is trying to say with that motion, I don’t have any way of giving feedback on what it should say.

Ditto

You know how to contact me or David

As do you

I can write a small script that adds _JEXEC...BLA..BLA after the <?php tag on all these files. But is that even a solution

@dgrammatiko no because then you are forking all those libraries

In addition to it being a fork and an extra maintenance burden, it has to be added to the right spot in the file. You can't put the defined or die check before a namespace statement, so it's not "just" adding it after the open tag.

You can't put the defined or die check before a namespace statement, so it's not "just" adding it after the open tag.

Still doable but I guess this path is not the appropriate

You know how to contact me or David
As do you

Sure but I don't want to bother you on anything where I need a native speaker. I do that to often already I guess ;)

But when you or others think that there is a thing that might be a problem with me not being a native speaker or something needs to be clarified I can only offer that you can contact me that same I would contact you the other way around :)

FPDs outside of the CMS context (i.e. files that are directly accessible because they lack a JEXEC-Check, or files triggering compile time errors) will still be covered by the policy and fixed in security releases.

so what does that mean as clearly @mbabker and I read it one way which you say is wrong (which does kind of worry me about the validity of the vote).

please give a real world example and then we can work from there.

I think a good description is done by Michael a few posts above:

“properly secured” server

Meaning not intentional changed settings that are never intended for production usage.

When you get a FPD up and running on a site with properly production settings of the server for example error reporting than we would still look into them from the JSST.

That would the idea behind the vote held be in my word. Does that make sense and clear things up a bit?

(which does kind of worry me about the validity of the vote).

Well it was discussed with the department coordinators in the meeting. So we not directly voted on the text posted but the vote was based on a clear discussion mention various aspects.

I'm not a lawyer but to me personally that is totally valid and might just be thing about the words.

“properly secured” server

Meaning not intentional changed settings that are never intended for production usage.

As defined by who and where.

It still needs a real world example for clarity

Ok added you remarks to the to do list for the team will keep you posed here with the results. Thanks for your feedback on this ?

For reference the default php settings on siteground are
error_reporting 30709 ( E_ALL but not E_NOTICE or E_WARNING)
display_errors on

IIRC it’s pretty close to that for all WHM/cPanel systems by default.

Ok and .htaccess support is enabled by default too right?
Joomla even warns you in the installer when display errors is on too.

Ok and .htaccess support is enabled by default too right?

yes that is correct

Joomla even warns you in the installer when display errors is on too.

But without any real information on any consequences AND that's assuming you use the joomla installer and not the one from softaculous or any other script that a host will use.

The reason for mentioning this is related to your previous comments about "properly configured servers" and my question about php.net

Ok and .htaccess support is enabled by default too right?

yes that is correct

So why is than the E_ALL a problem here? I still would not recommend it to be enabled on production servers but it is up to the webhosts to take that decision.

Joomla even warns you in the installer when display errors is on too.

But without any real information on any consequences AND that's assuming you use the joomla installer and not the one from softaculous or any other script that a host will use.

Can you come up with a short notice about display errors on?

As for the Software installers it us supporting or promoting that installers? I dont think so. When we where a car company and someone replaced the motor electronics by something else who is the person in charge to make sure every error, warning and message from the motor is communicated to the user?

The reason for mentioning this is related to your previous comments about "properly configured servers" and my question about php.net

We might have to define the term properly configured server i guess. Do you think you have a good definition where we can start such a definition from?

Can you come up with a short notice about display errors on?

Not really as I don't have a problem with it

As for the Software installers it us supporting or promoting that installers? I dont think so. When we where a car company and someone replaced the motor electronics by something else who is the person in charge to make sure every error, warning and message from the motor is communicated to the user?

That's not a good analogy. In addition we would be foolish to stick our heads in the sand and ignore the scenario of hosts own installers. Remember the past and present official providers of joomla.com both use their own installers as does joomla's own hosting provider.

We might have to define the term properly configured server i guess.

As you seem to disagree with a large host then I guess you will have to define it. But this is another good example of what @nikosdion mentioned over the weekend of the gap between core developers and the typical user

Can you come up with a short notice about display errors on?

Not really as I don't have a problem with it

You mention that there is no info about consequences?

As for the Software installers it us supporting or promoting that installers? I dont think so. When we where a car company and someone replaced the motor electronics by something else who is the person in charge to make sure every error, warning and message from the motor is communicated to the user?

That's not a good analogy. In addition we would be foolish to stick our heads in the sand and ignore the scenario of hosts own installers. Remember the past and present official providers of joomla.com both use their own installers as does joomla's own hosting provider.

Did i say we should ignore it?

We might have to define the term properly configured server i guess.

As you seem to disagree with a large host then I guess you will have to define it. But this is another good example of what @nikosdion mentioned over the weekend of the gap between core developers and the typical user

Where did i say i disagre with a large host? I only said that i personally would not recommend E_ALL in production.

As far as i know all large hosts support htaccess files so they are covered as we ship with htaccess and web.config files? So what is the point?

As for the disconnect of core developers Nicolas and i agree. And we both started to work on to fill that gap already.

I am giving up and blaming "lost in translation" issues

I have no idea why I was at-mentioned but I came here to find people talking crazy about nonsense on a public forum. Is this really how you want Joomla and yourselves to be perceived?!

You are engaged in a conversation about the technical details of an unrealistic solution to fixing a questionable and largely imaginary problem without even thinking about what is the problem we are trying to solve, when it occurs, what is its impact and what are the pragmatic mitigations.

The problem you're trying to solve is that IF someone is using a server that does not understand / honor user server configuration files (.htaccess, web.config) AND PHP error reporting is set to at least E_WARNING THEN you the full server filesystem path is disclosed.

First of all, I'd argue that the path disclosure is a low priority security issue but that's beside the point. We consider it a problem, I accept that.

Second, what is the proportion of servers which don't support user server configuration files? 10%? 20%? 0.1%? Unless you have a number for that you're all talking nonsense.

Third, out of these servers how many have a PHP error reporting level which would lead to a path disclosure? Remember, we're not interested about our development servers which have debugging turned all the way to 11, we're talking about real world sites.

Fourth, how many of these servers run sites where the site owner has not changed the hosting settings or installed a .user.ini file which sets error reporting to E_NONE? Mind you that my anecdotal evidence – doing support for Admin Tools – is that we're talking about something well below 1% of real world Joomla sites.

Fifth, the vast majority of real world hosts support .user.ini files which can be used to set the PHP reporting level for the entire libraries folder to E_NONE. Why don't we just do that as a secondary, pragmatic mitigation?

Sixth, does it REALLY make ANY sense to fork every single file in every single dependency we're pulling in through Composer to add a _JEXEC or die check? This is madness. We might just as well copy files over and be done with it like it's 2009 all over again. Yeah, I know it was meant as a joke / overreaction but the fact that we have a public issue proposing that lunacy even in jest makes the entire project look really bad.

Security is not a goal in and of itself, nor is it possible to mitigate all security issues for everybody without them ever doing anything themselves. I would argue that if someone chooses to use NginX for their site they OUGHT to know how to configure it properly otherwise their life will suck and their site will be vulnerable to all sorts of attacks. Our job in this case is to document, not try to mitigate the impossible! If someone has deliberately disabled user server configuration files / uses NginX AND disabled user PHP configuration files AND enabled full PHP error reporting they are insane. Do you really want them to use your software? They are going to invariably blame you for every stupid thing they will do.

Seventh and final point: you can always move the libraries folder outside the web root since Joomla 1.6 released ten years ago. Womp womp. This whole discussion is looking like it has nothing to do with security after all.

If you want to do something productive please spend a tenth of the time you collectively wasted in here to write some pragmatic security documentation. The current one reads like an outdated, sad joke in a language that superficially resembles English.

I want to clarify that I don't take anyone's side except this project's end users'. On a more personal note, I was angry at the project for a very long time for being mistreated. My anger was getting the best of me and I couldn't participate in any productive capacity so I went away for a while, doing my own thing, getting married, becoming a father... And I reflected. First, on the fact that I still care about Joomla. Second, on the fact that I care about its users, not Joomla in and of itself. This gave me some much needed internal clarity as to why I want to spend time I don't have on this project. I'm here to advocate for the end user and do so in a pragmatic manner. Knowing you all, you are here for the same reason.

Everyone please take a step back from their keyboards. Would you say the things you said, the way you said them, if the other person was in front of your face? Are we sure this is how we do and want to treat each other? Is it possible that a lot of what was said here was projection, not in response to what the other person actually said? Log off, calm down and don't respond tonight. I'm turning off my phone and going to get a beer from the fridge. I suggest you do too.

Hello,

Just found this thread searching how to secure Joomla 4 running on Nginx.

Is the Joomla documentation regarding Nginx up to date?
https://docs.joomla.org/Nginx

Best regards.

As for this issue here the best thing would be to follow the security advices from nginx and its community. As well as disable 'display_errors' and please set error reporting to the recommended production value.

All of this is not joomla specific and should be the case on all servers running production stuff.

spend a tenth of the time you collectively wasted in here to write some pragmatic security documentation

@nikosdion is right but we can do better than just documenting things: provide the needed files. So, what will it take to do so? Not much of development time and neither will increase the maintenance load. Let me explain:

First about the docs

• The Custom Elements have proper documentation with code snippets and live examples: https://joomla-projects.github.io/custom-elements
• It was created 3 years ago and since never had an update for maintenance, neither it needs one!
• It is modern, meaning it uses service workers and thus you can have the docs (given that you already paid a visit) even offline
• Still wondering why people turned down my proposal to move the dev docs to a similar implementation

Now about providing needed files (htaccess, nginx conf, etc)

• There are already solutions that people can go contribute the Joomla parts, eg: https://www.digitalocean.com/community/tools/nginx (this one is missing Joomla)
• Joomla can just create a simple (just some html, css and js) app that generates the the needed files (.htaccess,etc). Although this might sound like quite a task in reality is not, you can fork an existing one (vue, angular, there are plenty in the GitHub) and just adjust what the inputs and the corresponding output should be. This would also be a zero maintenance, it's a client side app, once it's confirmed that it works then will keep working without any intervention...
• Provide a better experience on the d/l page. Eg step driven, 1st d/l the Joomla.zip then create the needed files for your server, etc
• Do some PR with the big providers, Digital Ocean, Linode, Amazon, etc and then suggest those instead of the questionable smaller ones.

I know, daydreaming, let's fix everything in the PHP and of course in the runtime because we can...

@dgrammatiko I think you missed several points here. Keep in mind that Joomla already ships the .htaccess and web.config files. They don't need to be generated. We were talking about what to do a. if these files have no effect or b. you are using NginX.

In the first case (the server ignores .htaccess and web.config files) the futility of having a tool to generate said files which are already shipped with Joomla is tautological and doesn't merit further discussion. Even in this case, I did say that there is a practical solution. Just create a .user.ini file in the libraries folder with the line error_reporting = E_NONE and possible display_errors=0. Sure, if the server is sabotaged and doesn't heed these files either you're screwed. But I'd say that in this case your experience on that server with any CMS (especially WordPress which has a hard dependency on .htaccess files) would suck. I'm not even sure that even a static HTML site -- e.g. one generated offline with Jekyll -- would be plausible on that kind of server.

In the second case (NginX) a web app to generate a configuration file is far from being simple or practical. This should have special weight coming from someone who maintains such a solution (NginX Conf Maker for Admin Tools Professional) for the better part of ten years. I could go on in length about the problems you will encounter but I'll highlight the top two problems that keep popping up when I'm doing support.

Such a tool would need to generate a server configuration file that cannot be included automatically, nor should it be included from the site's root. It needs to be copied into the NginX server's configuration, in the server block for the current site. This requires the user to know what they're doing because they can brick their site. It also requires root access on the server which immediately raises concerns about how practical it is (trust me, I know this from bitter experience). And that's without taking into account that commercial hosting only gives you partial access to some of your site's configuration...

The second problem is that the NginX configuration file is very sensitive on the order of directives. You can't tell people to just add something at the bottom. You essentially need to generate the entire server configuration block. However, this requires knowing how PHP is set up on the server. You also need to take into account URL rewriting, security enhancement and whatnot. This is a far cry from being an easy task. You have never tried to do that, I have been doing that as a living for nearly ten years. Sure, you can try, but don't be upset when people start flaming you for breaking their servers ?

In any case, creating an NginX configuration maker application is a serious overkill in the context of this discussion. All you need to do is document that the libraries folder must not be web accessible and offer sample code to do that. For example:

location ~ /libraries {
   deny all;
   return 404;
}

The person using an NginX server either knows where to put it or can ask their host.

Again, this documentation is about going the extra mile because the .user.ini file would still protect the users against the full path disclosure issue we're discussing. NginX always uses PHP through FastCGI therefore .user.ini files are supported (unless the server admin explicitly disabled them because they want to control the php.ini centrally, in which case we do need to document the obvious i.e. error reporting and display must be turned off on a production server).

Sometimes the best solutions are the simplest. Oftentimes I wish I could go back ten years and tell myself that same thing; it'd have saved me a lot of grief.

Quick Update on this. As mention in the latest JSST report:

Path policy wording
As can be seen and read up in that issue here there is the need for more clarification on the new path policy that the production department decided on to make it clear what is meant by that new policy. This process has now been started with the department coordinators team and there will be an updated explanation on the motion / policy soon. Just to make one thing clear we do not nor have intend at any time to fork any composer libraries for that reason.

https://volunteers.joomla.org/teams/security-strike-team/reports/1245-first-informal-jsst-meeting-2020-2020-01

Will update here when we get the final wording / note within the department coordinators.

As discussed with the production chat @marcodings is working on an update to the motion.

To avoid a repeat of the confusion can I request that a native english speaker is involved in that.

Feel free to contact marco about that so we get it right :)

@zero-24 I wasn't suggesting myself as there are plenty of native english speakers. :) And @marcodings doesnt respond to my emails anyway so won't waste my time :(

To be fair i can not do that myself so we have to wait for another native speaker.

It's been six months - is there any update

Well we took action already an created the repos and the first forks have already been done. I have requested an update on the texts now multible times, but got no feedback in return, will try to bring it up again but I dont expect anything over the holiday season. :(

Well we took action already an created the repos and the first forks have already been done.

Just to make one thing clear we do not nor have intend at any time to fork any composer libraries for that reason.

/me even more confused

Well "forks" for dead projects that we still have to maintain for 3.x. As explained above. In our case lessphp and phpmailer: https://github.com/joomla-backports

Thats the whole point and intention of the motion as well as that org and the repos, make sure that our dependencies that does not live as long as our release cicle is are kept working as good as possible.

Well we took action already an created the repos and the first forks have already been done.

Just to make one thing clear we do not nor have intend at any time to fork any composer libraries for that reason.

/me even more confused

That text was in response to path policy stuff where michael noted that on some hosters the htaccess and web.config does not work and we stated that just for that reason (adding defined or die statments) there was and still is no intention to fork any composer lib.

Looks like thjis one has run its course and can be closed

Agree with @brianteeman, I'm closing this issue to avoid it stays open forever. Please re-open it if further actions needed.