Well, the nchambrier has a point. This solution would not be secure, say, deployed to a shared hosting environment. Right?
On May 21, 2008, at 2:31 PM, Fabian Lange <[EMAIL PROTECTED] > wrote: > > Hi (whatever your name is, I could not find a single message from you > stating it), > first of all: nobody can fake a 127.0.0.1. You cannot get to any > server > claiming you have this IP. > > You are right, that's why I said the comment above the check should > educate > them. However the situation is just different. They are already > deploying > unprotected non-production front controllers, exposing all their > server > details and database setup to everyone. > > There is already a big red warning in the documentation. But people > don't > read it. > I do not get your problem with PHP coming too late. Yes it is late, > and if > it is turned off then the whole source code will get emitted. But we > don't > care to hide the source code. Symfony is open source anyway :-) > I assume that even the "no-idea folks" can make php executing all > front > controllers correctly. If they are that far, symfony should be > protected by > default to expose more information the server wouldn't have exposed > otherwise. > > And last but no least: You are not giving a proposal how symfony can > help > the developer to prevent making errors. > If non production front controllers are generated (which I consider > as a > very very strong feature of symfony), then symfony should try to > prevent > some errors people could do. And the most obvious one is that these > controllers get deployed without thinking. > > .: Fabian > > > -----Original Message----- > From: [email protected] [mailto:[email protected] > ] > On Behalf Of [EMAIL PROTECTED] > Sent: Mittwoch, 21. Mai 2008 22:50 > To: symfony developers > Subject: [symfony-devs] Re: RFC - securing _dev files > > > Well, I'll give a more detailed advice... Oh and it's a -1 : > > I'm afraid that wanting a controller "secured out of the box" is an > error. > > With a check based on IP you have the feeling of security, but this is > a mistake as the IP is easy to change and fake. > > With such a solution, i'm very afraid of the side effect : instead of > having people letting public "frontend_dev.php" file on their server > and us telling them "be careful, this is dangerous", we will have > people letting not-really-protected-but-seems-to "frontend_dev.php" on > their server, and then we'll stop educating them. This will be > included in the documentation as a secure protection, and everyone > will have a feeling of security which will be simply false. > > I honestly prefer that the dev controllers stay how they are, and in > the documentation just write in big & red that "Important Security > Warning : dev controllers must not be deployed". > > No "out of the box" (which means : in PHP) solution will be really > efficient to prevent access to a file which is in the Document Root. > Such protections must be dedicated to the Web Server or the File > System, PHP comes too late in the cycle to be efficient, and holes > will still be exploitable. The only difference being that the user > will *feel* secure. > > > On 21 mai, 14:41, Kris Wallsmith <[EMAIL PROTECTED]> wrote: >> Fair enough. Fabian's suggestion seems to be the best option on the >> table. My only concerns are around when and how this array is built, >> for what controllers, etc. If this logic is buried in the >> generate:app >> task, we would be introducing hidden functionality. >> >> Introducing a generate:controller task is one option: >> >> ./symfony generate:controller --restrict=127.0.0.1 frontend dev >> >> or >> >> ./symfony generate:controller --restrict=conf/restrict_dev.txt >> frontend dev >> >> The latter option reading each non-empty line of the referenced file >> as an IP address. >> >> I'd be happy to submit a patch for this task, if it passes group >> muster. >> >> Thanks, >> Kris >> >> On May 20, 10:29 pm, Fabien Potencier <[EMAIL PROTECTED] >> >> >> >> project.com> wrote: >>> Kris Wallsmith wrote: >>>> Hm, sorry if I'm late to the conversation. How about not >>>> automatically >>>> creating a _dev.php controller along with an app? >> >>> You always need a _dev.php controller to develop your application. >>> So, >>> we need to create the file by default. >> >>> This thread is not about the best practices on how to secure the >>> _dev.php controllers because the best practices depends on your >>> SCM, Web >>> server, ... >> >>> We try to find a simple way to secure the _dev.php controllers by >>> default, so that if you happen to deploy one _dev.php controller >>> on the >>> production servers, you're secure. >> >>> I really think that the Fabian proposal is easy, non obstrusive, and >>> easy to customize. >> >>> Fabien >> >>>> Kris >> >>>> On May 20, 2:50 pm, "Ian P. Christian" <[EMAIL PROTECTED]> wrote: >>>>> Kris Wallsmith wrote: >>>>>> I typically deploy to production using a Subversion checkout. The > only >>>>>> controller I have in the repository is index.php, which is >>>>>> enforced > by >>>>>> a "*_*.php" svn:ignore property on the web directory. >>>>>> Isn't this simple enough? >>>>> No. For reasons already discussed in this thread - we want this > secure >>>>> out of the box. >> >>> -- >>> Fabien Potencier >>> Sensio CEO - symfony lead developer >>> sensiolabs.com | symfony-project.com | aide-de-camp.org >>> Tél: +33 1 40 99 80 80 > > > > --~--~---------~--~----~------------~-------~--~----~ > This message is part of the topic "RFC - securing _dev files" in the > Google Group "symfony developers" > for which you requested email updates. > To stop receiving email updates for this topic, pleas --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
