Michael A. Peters wrote:
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.
I respectfully disagree with your position. Everything you have
described about Jane is also true of an operating system. There are
compromised machines all over the world just because installing an
operating system is so easy. No amount of packaging is going to solve
the problem created by bad software and idiots. Yet we still sell
operating systems to anyone who wants to buy one and set it up. It's the
software that needs to become more secure and robust. This may or may
not mean moving the configuration/module management system out of the
document root. Preferably we would see the flexibility of management
remain as is, with the entire software stack becoming more robust to
prevent such compromises.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
