Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[4.0] Remove the FTP Layer #21507
Summary of Changes
It is time to bring Joomla into the modern era, FTP layers should not be needed with modern webhosting. This PR removes the FTP layer from:
This is tricky because there needs to be a Joomla Update or you need to build your own update server.
There are no more FTP settings available
Documentation Changes Required
normally you don't want that your software can manipulate it self. Yes we want it in some situations, f. ex. updates. The reset of the time we maybe want to write to some directories (image uploads, temp dir, cache dir, log dir). All of them doesn't have to execute code.
So if you do you server configuration right you don't want/have write access by CMS to any directory on the server, best case is it doesn't have write access at all.
In combination with restricting access to PHP files in write able directories makes it a bit hard to exploit a file upload exploit.
I disagree 100% with this PR. While philosophically I agree and in theory the idea behind it is solid, it is in disconnect with real world usage of Joomla (sadly) and what we've done to help users understand the security implications.
What we see is plenty of clients stuck on hosting which uses mod_php on Apache, itself running as www-data:www-data. This is still the default configuration of Ubuntu even in 18.04 LTS. As a result the use of the FTP layer is a one-way street for these users.
Of course it has very serious security implications. However, this is not a problem you can solve with technology alone, definitely not by simply removing this feature. It's primarily an education problem, first and foremost with (people who think they are) web hosts. They need to learn to use FastCGI or FPM. Then it's a matter of educating users to avoid hosts where the FTP layer is necessary.
I don't see us solving anything by removing the FTP layer from Joomla!. The people who need it will either stick with an old version of Joomla! or they will choose a different CMS which works on their host. Or both. They do not understand the security implications and we have done a really bad job educating them on that the last 15 years. If there is something we need to change it's educating users. Look at the results after we started warning users about old PHP versions: they are migrating to newer versions of PHP. Users are not suicidal idiots, they just don't know better unless those in the know (us) educate them.
What I would very much prefer is an approach where we educate users and ease them into removing this feature in the future.
For versions 3.x I would recommend adding a post-installation message if the FTP layer is installed informing the users about the dangers of the FTP layer.
In version 4.x we could double down on that, printing a BIG FAT RED WARNING below the header of the backend page with the same information.
I would even put the FTP layer controls in an area with a red background and a big warning above it "THESE OPTIONS MAY HAVE AN ADVERSE EFFECT ON YOUR SITE'S SECURITY".
Then in version 5.0 we can remove the FTP layer completely. Of course you could accelerate the timeline and remove the FTP layer in version 4.1. That's a decision that needs to be taken by the production department, not us random contributors on the issue tracker.
It goes without saying that the documentation would need to be updated to dissuade users from enabling the FTP layer at all.
Since the use of FTP layer is in the ANGIE application (restoration script) we do not collect that information for privacy reasons. We know empirically that the stream of FTP-related issues hasn't decreased significantly in the last 5 years. I try to educate my users but I'm basically facing the argument "Joomla! comes with an FTP layer and they don't say it's insecure so you are obviously a lazy developer who doesn't want to support it".
Well it was worth asking ;)
I guess security issues would be reduced if the user can not save their ftp username/password. Currently if they choose not to then they will be asked for it each time. So perhaps we should just remove the ability to save them and then each time they will need to enter them AND we can display an "education" message at the same time
That would be the ideal way to handle this. I'd even go one step further to show a warning before people fill in their credentials if their site is not HTTPS. Credentials sent over plain HTTP can be trivially intercepted and are a major security risk. Credentials sent over HTTPS are reasonably secure. I mean that they are only stored in the session which temporarily places them in the database or the server memory (depending on the storage backend) and wiped after the operation completes.
@brianteeman Thank you for the review. I have also cleaned up the installation/ folder now. I believe I have cleaned up now what needs to be cleaned up. If not, please tell me.
@mbabker Thank you for the review as well. I wasn't sure about the Factory change, so I have reverted that now.
What do you think the FTP layer is doing? Giving you just that option. Sending data plain-text across the wire is a security issue if you ask me.
As pointed out by @nikosdion ultimately this is a decision of the Production Team on how to proceed with this.
For the time being I will keep this PR updated, I can't guarantee to do so for 5 years
If I use the FTP Layer it only communicate clear text in the isp network (where often connections are cleartext). Depending on the ISP the connection is only localhost so snooping this traffic is really hard.
If you don't save the credentials in the config then its a security feature because the CMS any only write if you allow to do so. Not on a file upload exploit. Alternative it would be ok if we can remote update installations.
Most of compromised websites only have a problem because the webserver can write to the filesystem. If the webserver can't write the attack potential is much lower for normal sites.
Why do you think CPU designers and OS developers spent so much time in the technologies like executable-space protection? Similar reason, if you have a zone where you can't execute but write is good, if you have a zone where you can execute but can't write its good. The combination is hell.
I know many people don't think about security implication on all layers but removing such a feature is a mess. I would remove the credentials and leave the possibility to have a read only webserver.