Robert Cummings wrote:
* snip *

No. It is not.
The web root should be read only.

Please cite references as to why it should be read only. Please explain why the feature exists if it should not be so.

The feature exists because the web server runs as a standard user, and standard users have permission to directories they have write permission to.

In a properly administered web server, the apache user only has read permission to the contents of the web root.

I could make the same argument that making use of a webserver opens you up to any vulnerability in the webserver that may provide access to the entire filesystem. The intended purpose of the webserver is not to allow such access when configured properly, and so it is an exceptional circumstance when such security is compromised.

These compromises do happen, which is why the web root should be read only to the web server and any data the web server has write access to should be validated before it is used.

And the operating system?

Operating system doesn't matter.
The web server should not have write permission to directories/files within the web root.

It isn't hard to do.

It's hard to create a helpful application when fort knox is your delivery location. I'm not saying there's a problem with Fort Knoxes in the world, but this isn't necessary for everyone. if it were we wouldn't have banks, we wouldn't have credit unions, we'd all be going to Fort Knox to make our deposits and withdrawals. One size does NOT fit all.

I'm sick and tired of owned boxes spamming me.
It's been so bad at time I though my spam filters were crap, and I looked at the large number of messages they did catch.

I'm tired of XSS attacks. I run with scripting disabled for most sites, which makes the web a pain in the arse because most web pages out there are done by clueless hacks who expect me to allow them to send arbitrary code to be executed on my machine.

Very often these XSS attacks are the result of compromised boxes.

Yes, people need to run secure web servers. Yes, application developers need to take security into consideration before uploading their project for public consumption.

Kind of scenario that happens all the time:

Jane, a non technical person, has a soft spot for the Desert Tortoise. She buys a cheap web account and sets up a blog on it. She gives an account to her friend betty.

Betty's webmail account is compromised by an XSS attack (happens all the time, even has happened to gmail). Now the attacker has access to Betty's mail including her password. He logs on to Betty's account and modifies a blog, adding an image that isn't an image, and either successfully now has an XSS attack on Jane's blog, or possibly have even rooted the server Jane's account is with through a local exploit he was able to get the apache server to run because he was able to upload a perl or php script inside the web root.

Just as an example, I was looking for a simplistic blog to add to my website. The install script didn't even work because it used system and exec calls which many servers (including mine) do not allow.

This is a problem with your setup. I make use of exec() calls often enough when within a Linux environment. If this is a known parameter of the application, then it is not incorrect to use exec(). It is common to build upon existing shell binaries.

Vast majority of stuff can be done with pure php via php modules and extensions. Allowing exec() or system() is extremely dangerous.

Yes, I do allow it for my squirrelmail install, but fixing that is on my todo list.

A specific instance of a poorly designed application does not stand as the model for all applications. There are countless examples of bad programming and exploits at pretty much every level of a system. These do not suggest we should not use computers.

No, but it does suggest we need to think about security, such as not having web server writeable files in the web root and not having the web server write files it then parses as php (extremely common practice for app configuration files) - especially when it is cake to use a database or flat file (IE xml) for configuration, allowing parsing of the values read to make sure they are sane and avoiding addition of declarations you don't want.

So with some hand waving and fluttering of your eyes you've eliminated (or at least completely ignored) all the Windows machines in the world.

No. I haven't.
For years, the LaTeX community had a package manager for Windows installs that was in fact superior to any TeX package management on any UN*X environment I ever saw.

Now with TeXLive tlmgr there is finally good TeX package management for every OS.

There are far more php users than TeX users, there is no good reason why such a package manager does not already exist for php in the Windows environment. It would be an excellent addition to the WAMP stack.

The Windows PHP community not getting their act together is not an excuse for sloppy insecure default installs, especially since there is nothing about Windows that prevents a proper install.

If Jane from the example above can't read and follow simple instructions to install a blog on her Desert Tortoise conservation site, she either needs to read a book or hire someone to can. By making things "easy" for her, you are not doing her a service, you are doing her a dis-service because her install is now vulnerable, and she probably doesn't even comprehend why.

Her site may end up being blocked by browsers for having identified malware, she won't even understand why, and will just wipe everything and start over with the same insecure setup that got her into trouble in the first place.

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to