Hi, as I am still running across symfony pages that have their dev env in production I want to bring this up to dev-list notice. Any thoughts of integrating a combination of Ant's and my idea? I really think that enabling _dev on production should be a conscious step. .: Fabian
-----Original Message----- Sent: Thursday, 17. January 2008 20:47 To: symfony-users@googlegroups.com Subject: [symfony-users] Re: Listing your page as using symfony a security
issue?
On 1/17/08 2:34 PM, "Fabian Lange" <Fabian.La...@web.de> wrote:
> And what about building in more security by default?
> e.g. accepting just localhost connections by default in the _dev frontends > (which have to be consciously be modified to enable remote logins?)
I think this is a great idea. Taking it a step further it would be if there was a built in mechanism to allow access to the dev by ip as well easily within the configuration. Its not a big hassle to code yourself but itd be nice if all you had to do was flip a cute little yaml switch :-)
Fabian Lange wrote: > Hi, > as I am still running across symfony pages that have their dev env in > production I want to bring this up to dev-list notice. Any thoughts of > integrating a combination of Ant's and my idea? > I really think that enabling _dev on production should be a conscious step.
I vote for having IP's (well, CIDR's preferably) defined somewhere for limting access to the dev controller.
I would advise, by default, it allowed 127.0.0.1/32. Maybe if there is no /, it should assume a /32 mask. Also, it would be nice if it supported the syntax: 192.168.0.0/255.255.255.0 as not everyone knows that that means /24.
I put the following by default in the htaccess files of my symfony applications to limit access to _dev-files to my machine only:
<FilesMatch "_dev\.php$"> Order Deny,Allow Deny from all Allow from 127.0.0.1 </FilesMatch>
In the "Allow from" line you can also put multiple IPs or masks.
I don't think this should be configurable in a yaml file because yaml it is too error-prone for security-related options: One whitespace character too much and the configuration line is ignored.
Michel
On 1/23/08, Ian P. Christian <poo...@pookey.co.uk> wrote:
> Fabian Lange wrote: > > Hi, > > as I am still running across symfony pages that have their dev env in > > production I want to bring this up to dev-list notice. Any thoughts of > > integrating a combination of Ant's and my idea? > > I really think that enabling _dev on production should be a conscious step.
> I vote for having IP's (well, CIDR's preferably) defined somewhere for > limting access to the dev controller.
> I would advise, by default, it allowed 127.0.0.1/32. Maybe if there is > no /, it should assume a /32 mask. Also, it would be nice if it > supported the syntax: > 192.168.0.0/255.255.255.0 > as not everyone knows that that means /24.
> I put the following by default in the htaccess files of my symfony > applications to limit access to _dev-files to my machine only: > <snip> > I don't think this should be configurable in a yaml file because yaml > it is too error-prone for security-related options: One whitespace > character too much and the configuration line is ignored.
You're right - YAML is bloody awful when it comes to validation and stuff...
I do however think that secure by default is a good idea in this case. Whilst your snipped of apache config makes sense, what about IIS, and lighty and.. others.
If someone edits the config files, and messes up the format of it - atleast we have tired to protect them. At the moment, it's a far too common issue for people to launch with it. I've found peoples passwords for remote services in the debug toolbar output before - *something* needs to be done ot mitigate this problem IMO - and default IP restrictions seem like the most sensible bet to me.
The other option, is to have the development controllers name randomly generated - although this solution really is quite a horrible idea I think, and I blame the beer. ;)
On Jan 23, 9:09 pm, "Ian P. Christian" <poo...@pookey.co.uk> wrote:
> You're right - YAML is bloody awful when it comes to validation and stuff...
It just means, like any serious developer, that you have to be really
aware of what you are doing. Having it default to the most secure
option will ensure that you have to conciously change it to something
else, and so have to pay attention to what you are doing (and test it
as well).
> I do however think that secure by default is a good idea in this case.
> Whilst your snipped of apache config makes sense, what about IIS, and
> lighty and.. others.
Indeed. Having it built into symfony makes more sense than doing it on
the webserver level. And since symfony uses YAML as configuration
syntax, YAML it should be for this as well.
> If someone edits the config files, and messes up the format of it -
> atleast we have tired to protect them. At the moment, it's a far too
> common issue for people to launch with it. I've found peoples passwords
> for remote services in the debug toolbar output before - *something*
> needs to be done ot mitigate this problem IMO - and default IP
> restrictions seem like the most sensible bet to me.
Even I, and I consider myself a quite experienced developer, have
launched sites with the _dev in there as well. I seem to forget to add
those files to the rsync_exclude.txt files for some reason. Having a
good deployment document of course will prevent this, but having an
extra built-in security layer will at least prevent from accidental
deployments leading to security vulnerabilities.
> The other option, is to have the development controllers name randomly
> generated - although this solution really is quite a horrible idea I
> think, and I blame the beer. ;)
That idea is horrible and even with beer this should never even have
come up in your mind ;)
> Hi,
> as I am still running across symfony pages that have their dev env in
> production I want to bring this up to dev-list notice. Any thoughts of
> integrating a combination of Ant's and my idea?
> I really think that enabling _dev on production should be a conscious step.
> .: Fabian
> -----Original Message-----
> Sent: Thursday, 17. January 2008 20:47
> To: symfony-users@googlegroups.com
> Subject: [symfony-users] Re: Listing your page as using symfony a security
> issue?
> On 1/17/08 2:34 PM, "Fabian Lange" <Fabian.La...@web.de> wrote:
> > And what about building in more security by default?
> > e.g. accepting just localhost connections by default in the _dev frontends
> > (which have to be consciously be modified to enable remote logins?)
> I think this is a great idea. Taking it a step further it would be if there
> was a built in mechanism to allow access to the dev by ip as well easily
> within the configuration. Its not a big hassle to code yourself but itd be
> nice if all you had to do was flip a cute little yaml switch :-)
> > Maybe we could create something like a sfAdvancedSecurityPlugin ? > > But symfony should be secure by default..
Maybe that should be integrated by default into the freeze or sync task which will secure the application by adding appropriate htaccess/filters and remove the dev stuff ? and make an nonsecure option to the task that will disable the secure deployment to a nonsecure one but the developer will be aware of it !
Sadri Sahraoui wrote: > On Jan 24, 2008 6:53 PM, Lukas Kahwe Smith <m...@pooteeweet.org> wrote:
>> On 24.01.2008, at 16:48, Matthias N. wrote:
>>> On 24 Jan., 16:46, "Matthias N." <matthias.nothh...@googlemail.com> >>> wrote: >>>> Just wanted to remember that we already have a small wiki page about >>>> that topic:http://trac.symfony-project.com/wiki/SecuringDevFrontend >>> Maybe we could create something like a sfAdvancedSecurityPlugin ? >>> But symfony should be secure by default..
> Maybe that should be integrated by default into the freeze or sync > task which will secure the application by adding appropriate > htaccess/filters and remove the dev stuff ? and make an nonsecure > option to the task that will disable the secure deployment to a > nonsecure one but the developer will be aware of it !
The *_dev.php are excluded by the sync command by default but not all people use this task to deploy their project.
|
