> First, please use the [email protected] email address for > reporting security issues. I wouldn't see a zero day exploit here. Too > late, okay.
Sorry, I didn't knew this address. > The real solution is, as always, validate user input. One more time, letting the user upload any kind of file he wants can be a design choice. And if you read the "Php is turned on in unusual files extensions" section of my initial post, you'll see that even perfectly well written forms can be exposed. > I think this is up to the developer to take care of this. Overestimating developer security skills is a risk that can't be taken in a framework. When it comes to security, it should be just turned on by default, like template escaping or CSRF protection. I've discover this vulnerability in one of my own (unreleased) frontend form with public access. I'm not a Symfony beginner anymore and neither is the Diem project team. It's an easy trap to fall in. I didn't even knew CSRF attacks before discovering Symfony few years ago. And It's one of the reasons why I've adopted it: "Wow, a good framework written by folks pretty more experimented that I am. If I use it, my projects will be protected against vulnerabilities I'm not even aware of.". Users rely on Symfony for these kind of security things, handling them by default is one the core features of the framework. > And what if you don't use Apache? Symfony already has a .htaccess file and the documentation is already Apache centric. Other server users are already used to it. > Or if .htaccess are not allowed in your Apache configuration? The only other solution I see is to add the rule in the httpd.conf configuration documentation. Drawbacks : - On shared hosting environment, users don't have access to httpd.conf - It's not possible to add the fix in existing projects in a future release. Users will have to update the config file by themselves and I'm afraid that many of them won't do it - Symfony printed books readers won't have access to this update A probably dumb suggestion: using both solutions. Adding the rule in a new .htaccess file AND in the httpd.conf documentation. Ok, yes, it's redundant. But that way, we could reach all apache users. Of course it'd need some explanations in a blog post, in the changelog and in the documentation. Does it feel like nonsense to you ? On Jan 31, 5:36 pm, Laurent Bachelier <[email protected]> wrote: > What prevents me from uploading an .htaccess file and overriding the > configuration? > The real solution is, as always, validate user input. > > On Jan 30, 5:08 pm, Éric Rogé <[email protected]> wrote: > > > > > <Directory "/path/to/my/sfProject/web/uploads"> > > php_flag engine off > > </Directory> > > > The fix could release in a .htaccess added to the uploads directory. I > > think it should be easiest way for many symfony users. -- 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.
