I completely agree with you. I agree with others that is not a symfony bug, however, it is most certainly a security problem which the majority (including experienced developers) would not know about.
A lot of developers have adopted sfForms because of the security features, built in validators, CSRF protection etc. To an extent, they've put a lot of trust into the security of it without realising that they need to take some initiative themselves. "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 onby default, like template escaping or CSRF protection." Absolutely. On Jan 31, 6:21 pm, Éric Rogé <[email protected]> wrote: > > 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.
