Warning: I am able to write to the configuration file:

Hello all. I'm brand new to Zen Cart, and not highly skilled in web development, but I'm hoping to put up a simple shop in the linux hosted webspace I have from my domain host.

I bought the hosting from a company called easily, they call it 'Linux Advanced' and it offers the features listed here.

The issue I have is having followed a how-to on uploading the shop, and it all seems to work just fine, is that Zen Cart reports a security error with:

Warning: I am able to write to the configuration file: /web1/user25320/website/blog/cleansun/includes/configure.php. This is a potential security risk - please set the right user permissions on this file (read-only, CHMOD 644 or 444 are typical)

I have managed to establish that the hosting package I have doesn't allow me to make this change, the response I got from the hosting company was this:
"Our shared hosting does not allow for the modification of permissions as we run suExec which makes the application that you are installing run as the owner of the webspace thereby bypassing the need to modify permissions."
But then I read this post which made me worry.

What I'm understanding from this is that the web server is able to write to the shop config file. What I don't see is how this is a security risk, unless the implication is there's vulnerabilities in the shop code which could allow an attacker to cause the webserver itself to read/modify the config?

Is anyone able to explain to me in simple terms if I have a real security issue here? The VPS package the host suggested I buy for this would increase my costs in year one by over 500% which is budget we just don't have at this point.

Many thanks in advance,
Alex

Upselling to a VPS just because the host can't comply with a simple change to file permissions is a total SCAM! You're right, that's unnecessary overkill.

The warning message you're trying to cope with is a result of general wisdom that says your configure.php file, which contains critical system security information to drive your site, should be set to read-only so that if a hacker were to break into your site they would find great difficulty in changing that information inappropriately.

Changing your file's permission level from "writable" to "read-only" should be something easily offered ... EVEN for hosts running suExec.
If they're going to be so restrictive that they won't let you set the file's permissions to read-only, then it's VERY likely you're going to run into a number of further problems during your visit to their hosting services.

Thanks very much. What sort of changes could be made in the event a hacker were able to modify the configure.php though?

Could they arguably then point the shop at a different mysql db?
Would they be able to recover details of users and or orders?

Thinking around the issue, I could write a script that checked the file attributes of configure.php at a pre-defined frequency (say five minutes) and immediately take the site down if any change were noted - what do you think to that approach?

cheers,
Alex

If the file is writable and someone gains access, then yes they can change the contents of the file to point to anyplace they way, to steal information anyway they want, etc.

As for scripting your own tools, there are all kinds of things you could do. The SIMPLEST way is to just follow the advice provided. It's there for a reason.

That said, if your expert opinion is such that you feel there's no need to make the configure.php file read-only, then go turn off the WARN_CONFIG_WRITEABLE setting in your /includes/init_includes/init_header.php file. YOU ARE ASSUMING YOUR OWN RISKS BY DOING SO.

DISCLAIMER, especially for those who read this discussion later: MAKING SUCH CHANGES IS NOT RECOMMENDED, and especially not for a first-time storeowner who merely wants to blindly ignore warnings that are given for your own protection.

If the file is writable and someone gains access, then yes they can change the contents of the file to point to anyplace they way, to steal information anyway they want, etc.

As for scripting your own tools, there are all kinds of things you could do. The SIMPLEST way is to just follow the advice provided. It's there for a reason.

That said, if your expert opinion is such that you feel there's no need to make the configure.php file read-only, then go turn off the WARN_CONFIG_WRITEABLE setting in your /includes/init_includes/init_header.php file. YOU ARE ASSUMING YOUR OWN RISKS BY DOING SO.

DISCLAIMER, especially for those who read this discussion later: MAKING SUCH CHANGES IS NOT RECOMMENDED, and especially not for a first-time storeowner who merely wants to blindly ignore warnings that are given for your own protection.
FFS. I asked a fairly simple question, making it clear that I'm no expert on the subject, seeking to understand what exactly the risks would be to which I would be exposing myself.

"follow the advice given, it's there for a reason" is not a useful answer to the question "what is the reason?". Quite why you would think that I would assume anyone else were responsible for something I ultimately did is beyond me. Your sneidy comments about 'expert opinion', caps and red letters are of no use to me and are quite clearly self-serving.

If you can't or prefer not to address the actual question, please refrain from posting.

You're not reading DrByte's post correctly. He gave the information you needed to remove the Warning msg. -- but -- for those reading this thread in the future, the text in Red is to make it plain the information is to be used at one's own risk.

Frankly, I don't understand how you first say; "not highly skilled in web development" and then state; "I could write a script that checked the file attributes of configure.php at a pre-defined frequency (say five minutes) and immediately take the site down if any change were noted". How is it that you cannot change permissions but can write a script to that would use a Cron command?

One would think your first priority is to get the permission problem solved, and ask later about why it is a good security protocol. Changing the two config files to use permissions of 444 should be available to you within your FTP program and/or the Control Panel provided by your Hoster. If not then perhaps you have Shell access and can easily change permissions way? And if none of those options are available and your Hoster won't take the 2 minutes to make the changes, might be a good time to switch Hosters. Changing permissions is a very simple thing and if your Hoster won't help with that, but instead try to upsell you to a Hosting package you neither need nor want, imagine the situation you'll be in if a big problem comes up.

Thanks. I had already identified how to suppress said warning message, and indeed posted a link on how to do that in my first post.

I do lack web development skills almost completely, however I can write simple code using a tool called autohotkey which I have used extensively to automate various processes. That in conjunction with cURL and or filezilla would easily allow me to return file attributes and if necessary take appropriate action such as renaming/removing key files to take the site down.

The point I'm making is that under the current hosting package I have I cannot change the file attributes using FTP, and it does not allow me SSH access. I understand the recommendation to go somewhere I can do that, just not the reasoning behind it - what I was asking for was some background into how this file being writeable by the webserver would expose the site to compromise - this suggests to me that the webserver can be persuaded to run arbitrary code, I'm having difficulty understanding how this could be.

I imagine I could raise a ticket with the current host to have the permissions of the files in question set by them, but of course I'd need to finalise the config first, and with my somewhat haphazard trial and error approach I imagine I'll have to mess with those files quite a little bit before I get it setup right.

Cheers,
Alex

Copy this code into a new file after changing 'admin' to your Admin dir. name.

Save it as 'chmod.php' and upload to your site, same place as where Zen Cart 'index.php' is.

Load the file into your Browser using http://yoursite.com/chmod.php

When you see the words: Completed, delete the 'chmod.php' file. Change back what you changed before, to remove the error msg., and you should be good to go.

"what I was asking for was some background into how this file being writeable by the webserver would expose the site to compromise - this suggests to me that the webserver can be persuaded to run arbitrary code"

Any site can be hacked but by making the 2 config files 'not writable' the security of them is made much stronger. Same as why we lock our Doors or why the Hood latch for you car is inside the car. Wasn't that way many years ago but it was determined that by putting the Hood latch "inside" the car, security for your engine was vastly improved.

Website Rob:

by making the 2 config files 'not writable' the security of them is made much stronger.I'm curious, how exactly does it make any difference to a site's security?

I'm surprized you would ask that?

Along with the security examples I gave earlier, let me restate what the good DrByte already said.

"If the file is writable and someone gains access, then yes they can change the contents of the file to point to anyplace they want, to steal information anyway they want, etc."

If we can agree that any script configure file(s) being writable is a security vulnerable, then logically, making permissions non-writable can only make things more secure; for the whole site. When permissions are as secure as they can be or should be, for every dir. and file on the site, the odds of getting hacked are greatly diminished. Regardless of Zen Cart being the only script used or not, script configure files are a major point of attack for many hackers or their Bots. Making them secure as possible just makes sense, no?

Website Rob:

If we can agree that any script configure file(s) being writable is a security vulnerable ...But that's my question. Does it?

Website Rob:

Along with the security examples I gave earlier ...Door locks and hood latches aren't examples of online security, they're woefully inadequate metaphors for it. Or am I missing something?

Since your web server's operating system should prevent any external read and write access to php scripts, and somebody with internal access could change the permissions anyway - you gave them a script above to do that - how do the permissions on these specific files create a security vulnerability.

I'm open to the possibility that they do. Just wondering how?

Like any good Lawyer or Teacher, you are asking questions you already know the answers to.

I suggest that if you are concerned about the current built-in security of Zen Cart that you start a new thread and let's get this thread back to the original question / problem.