IMO a sensible way would be 1.) change the docs
http://www.symfony-project.org/forms/1_4/en/02-Form-Validation#chapter_02_file_upload If I understand this code correctly, a file with extension .php will be saved in the upload directory with a .phtml extension. (Firefox uploads a .php file with content-type application/x-httpd-php, and sfValidatedFile::getExtension returns .phtml for this). And on ubuntu, .phtml will be executed as php, I don't now about other OSs, but I would expect the same. This is not what a user of the symfony framework would expect, being pampered by the symfony team's statement: [quote from http://www.symfony-project.org/jobeet/1_4/Doctrine/en/01] This Book is different ... You are probably used to reading warnings like: "For a real application, don't forget to add validation and proper error handling." or "Security is left as an exercise to the reader." ... In this book, you will never see statements like those as we will write tests, error handling, validation code, and be sure we develop a secure application. That's because symfony is about code, but also about best practices and how to develop professional applications for the enterprise. ... All the code you will read in this book is code you could use for a real project. We encourage you to copy and paste snippets of code or steal whole chunks. [/quote] I think the docs should reflect that attitude, and show that a security problem might be waiting. Perfect would be a copy and paste extension list which are not acceptable for not experienced developers. 2.) Change the sfValidatorFile to reject by default some extensions (taken from a config value, which will be set when creating new projects, thus no BC issues for existing projects). This means that unexperienced developers are more protected then now (yes, I now, the extension list will not cover all possiblities), and the experienced developers can easily change the config setting. And add a good exception message that tells the developer why a file upload dos not work ;-) If 2.) is implemented, 1.) should be removed again. Georg Am 01.02.2010 01:27, schrieb Tom Boutell: > Ahem, I meant stable branch (: > > On Sun, Jan 31, 2010 at 7:20 PM, Sid Bachtiar <[email protected]> wrote: >> When I said block, I mean it can be allowed just by setting an option >> like 'allow_dot_prefix_files' => true. >> >> On Mon, Feb 1, 2010 at 1:15 PM, Tom Boutell <[email protected]> wrote: >>> In Symfony 2.0, maybe. In a backwards-compatible patch to Symfony 1.4, >>> no. There's nothing wrong with uploading dotfiles, or any files at >>> all, if that is what the developer truly intends to allow. >>> >>> On Sun, Jan 31, 2010 at 7:03 PM, Sid Bachtiar <[email protected]> >>> wrote: >>>> Why can't we just block a file that begins with dot by default? >>>> >>>> On Mon, Feb 1, 2010 at 12:58 PM, Tom Boutell <[email protected]> wrote: >>>>> Oops! Laurent is correct. We should NOT do this because it can be >>>>> trivially overridden by simply uploading a file called .htaccess to >>>>> shut it off. There is nothing worse than a security measure that >>>>> doesn't actually work, because people trust it and stop doing their >>>>> homework. >>>>> >>>>> Allowing users to upload any file extension they want is never smart - >>>>> you should always have an approved list of extensions that you accept, >>>>> and ideally sniff file types by actual content rather than extension >>>>> (but Macs do provide extensions too these days, so life isn't quite as >>>>> painful as it used to be). >>>>> >>>>> It might make sense for Symfony's file upload handling to reject .php >>>>> files by default, but where does that end? Some servers are configured >>>>> to block PHP code in .html files too, yet uploading HTML files is >>>>> often desirable. >>>>> >>>>> File extensions are not the end of it either! What if the browser is >>>>> really a script that stuffs in a relative path as the filename? Your >>>>> code shouldn't trust that and overwrite the contents of your site. >>>>> >>>>> The Symfony documentation could call more attention to the fact that >>>>> the user's filename (not just extension!) should never be trusted. And >>>>> it might be nice to have a standard validator available for rejecting >>>>> anything that isn't a web-friendly image file (GIF, JPEG, PNG) since >>>>> that is such a common case. Such a validator could check the actual >>>>> contents of the file easily with the imagesize() function, which is >>>>> standard in PHP, and force the appropriate file extension as well as >>>>> forcing the filename to \w+ only, perhaps optionally suggesting a >>>>> nonconflicting filename if the file already exists. >>>>> >>>>> But in the general case, what is "safe" depends on what you're trying >>>>> to do. If you're writing a pure-PHP file sync tool to get around the >>>>> lack of a shell on Rackspace Cloud and you've already checked for an >>>>> appropriate password, uploading PHP files right on top of the main app >>>>> folder might be exactly what you want to do (and yes, we do this on >>>>> one site right now). >>>>> >>>>> Symfony can help you avoid stepping in open manhole covers but you >>>>> still shouldn't walk along dark alleys wearing an ipod and mirror >>>>> shades at 2am (: >>>>> >>>>> On Sun, Jan 31, 2010 at 11:36 AM, 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. >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Tom Boutell >>>>> P'unk Avenue >>>>> 215 755 1330 >>>>> punkave.com >>>>> window.punkave.com >>>>> >>>>> -- >>>>> 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. >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Blue Horn Ltd - System Development >>>> http://bluehorn.co.nz >>>> >>>> -- >>>> 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. >>>> >>>> >>> >>> >>> >>> -- >>> Tom Boutell >>> P'unk Avenue >>> 215 755 1330 >>> punkave.com >>> window.punkave.com >>> >>> -- >>> 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. >>> >>> >> >> >> >> -- >> Blue Horn Ltd - System Development >> http://bluehorn.co.nz >> >> -- >> 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. >> >> > > > -- 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.
