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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
