Hi,
I'm also thinking that this issue is not a symfony related one. This
problem could be transfered on any other "php project" imho.
I go along with Nicolas opinion, claiming that this is a education
topic for the developer.
I really do not understand how symfony should protect this issue with
a generic approach.
It is a totally different case than in the CSRF form protection. This
is really an wide spread attack, which could be fought against in a
common way.
But how should symfony know that a uploaded yml or php file (or
whatever) is a bad file?
Imagine a "paste it"- like application, where users are able to upload
complete source files and the system parses and displays its content!
How would you protect those uploads?
You only could protect those uploads project dependant to cover all
the according requirements.
But why not create a special security related forms plugin
(sfSecuredFormsPlugin, sfExtraSecuredFormsPlugin,
sfParanoidSecuredFormsPlugin or something), where all special checked
and validated widgets are added to (maybe a small hint to this plugin
in the forms doc chapter)? This would be better than adding those
logic into the core.
Frank
Am 01.02.2010 um 17:57 schrieb Tom Boutell:
On Mon, Feb 1, 2010 at 10:08 AM, Florian MAURY <[email protected]
> wrote:
Sorry, you haven't read well my post : I never said you can't delete
it : I said, you can't overwrite it ;)
You're right, my mistake. The .htaccess file would be an effective
block as far as it goes.
The thing is it only
protects Apache. I think Symfony should minize its dependency to
Apache.
I agree. It makes more sense for Symfony's validators to do a better
job of helping developers avoid such mistakes at the PHP level.
Moreover, VM can't be an argument to develop not correctly (in terms
of security) : a VM may "protect" a 777 file or dir against shared-
hosted clients, but it is not protecting at all against intrusion of
the system (via a PHP script or an exploit on an other part of the
server (SSH, Mail server, whatever)). An intruder can the corrupt
the
cache, or delete any file in the upload dir from any local user in
the
system (not only root) who can access the symfony root. You may rely
on permissions of the parent directories ; i don't.
I too would prefer it if Symfony offered a way to configure the
permissions and ownership it attempts to set for things that are
supposed to be "writable by the website" and things that are meant to
be "readable but not writable by the website" rather than making broad
assumptions like "777 is the way to go," even if that has to be the
default for broad acceptance of Symfony as something that can be
installed by relatively inexperienced developers without too much
grief.
I actually submitted such a patch a long time back. A better version
would probably put these settings in properties.ini, the system does
need to see them very early.
777 is drastically safer in a VM environment but yes, there could be
exploits elsewhere in the OS.
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected]
.
For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
.
--
You received this message because you are subscribed to the Google Groups "symfony
developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en.
