secure webserver and CMS layout

Discussion corner for Developers of Serendipity.
Post Reply
phade
Posts: 1
Joined: Tue Jan 23, 2018 5:42 am

secure webserver and CMS layout

Post by phade » Tue Jan 23, 2018 6:03 am

Hi,

since Spectre and Meltdown everybody should have understood, thats its important to have a kernel and user space that cannot influence each other and that, as consequence, every CMS and blog software should also carefully separate its files, directories and permissions.

The FAQ for s9y states under https://docs.s9y.org/docs/faq/index.html:
"In usual environments, your FTP user should be within the same group like your webserver user, so that you are able to modify files with the right umask. However, some providers might not think about that and thus deny you access to your own files."

Well, "usual" cannot be more wrong. Its far more secure to have a webserver running under a different user and group than the ftpuser.

Core files, like the blog's programm data, should only belong to the ftpuser, should only be writable by the ftpuser and readable by the webservers user. Only a few files and directories really need to be writable by the webserver itself (like temporary data).

Even if there might be a bug in whatever software package or plugin (might not even be a bug in s9y, but in another software packages residing on the same webserver) or whatever user password got lost, contents or files could only be changed under some places and the core files of s9y could not me modified at all.

In consequence its important the change the directory structure of s9y, rewrite the update mechanisms (by using ftp, sftp or scp to "localhost"), even WordPress understood this years ago.

BTW: its also a security problem, if the config file resides inside the document root.
Good provider have at least one directory accessible for the customer only via (s)ftp that could be read by the webserver locally and is outside the documentroot, so it cannot be accessed at all directly via the web. s9y should at least have the posibilty to store its config file there. Good systems seperate their files even more.

titanofold
Posts: 1
Joined: Thu Jan 25, 2018 4:00 pm

Re: secure webserver and CMS layout

Post by titanofold » Thu Jan 25, 2018 4:05 pm

I had made the same observation as I was getting Serendipity set up for the first time a couple days ago.

Roundcubemail has a dedicated folder (public_html) that's intended to be the document root.

User avatar
onli
Regular
Posts: 2132
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: secure webserver and CMS layout

Post by onli » Thu Feb 22, 2018 11:56 am

Though I generally agree, it's not that easy.

Think about it feature-wise. What is needed is a way to upgrade plugins. For that you need to have a webserver that is able to overwrite plugin files. The moment you have that all other security measures in that direction are unimportant, it just does not matter whether an attacker that gets access via the webserver can write to core files or plugin files. Is there a solution for that?

We also have a plugin for updating the core, for that to work s9y needs to be able to overwrite its own files. I'd argue that making upgrades easier is more secure than making upgrades hard by the more complicated security config, overall.

I agree that the architecture could be changed to have a directory level before the rest of the application, and make that the space for the config file. On the other hand, supporting the upgrade scheme for that is likely to be error-prone, and it has to work in every apache webserver configuration. Note that by default the files are access-protected right now.

But if there are clever solutions for those issues, get in touch, participate in the development, I'll happily merge PRs and help discuss changes beforehand.

User avatar
garvinhicking
Core Developer
Posts: 30009
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: secure webserver and CMS layout

Post by garvinhicking » Mon Mar 12, 2018 2:04 pm

One thing to keep in mind too is that most PHP applications need to write temporary data; with an exploit, as soon as a single file can be written on a webserver (even temporary data with a temporary directory) you can inject malicious code into those files, no matter where they are, and usually then load/execute that code. So even if you restrict all but one directory from being writable, you can still be attacked, but you lose all features that onli described; so adjusting the webserver not being able to write to certain files is rather more security by obscurity but wouldn't really prevent an attacker from executing his injected code...

Having said that, if we can actually improve things and I am misreading it, I'm very much open to specific suggestions, too! :-)
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

Post Reply