Hi And what about adding :
RewriteRule ^(uploads\/.+)$ $1 [T=application/octet-stream] It will force downloading of all file inside uploads folder (so remove php and other handlers) to web/.htaccess file ? [MA]Pascal On Mon, Feb 1, 2010 at 08:57, Flukey <[email protected]> wrote: > I agree with your latter proposal. I think having a default validator > to block certain extensions would be perfect. Furthermore, if > implemented, it would be a quick task to reflect the changes in the > documentation as instead of trying to educate users in the docs, we > can just say "By default sfValidatedFile disables files with > extensions .php etc. To override this, set the option > 'disable_default_extensions_validator'=>'false'" > > Also, to an extent, I do like the idea of adding, > > <Directory "/path/to/my/sfProject/web/uploads"> > php_flag engine off > </Directory> > > to the apache config. It's rather nice. > > On Feb 1, 9:35 am, Georg Gell <[email protected]> wrote: > > IMO a sensible way would be > > > > 1.) change the docs > > > > http://www.symfony-project.org/forms/1_4/en/02-Form-Validation#chapte... > > > > 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 fromhttp://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]<symfony-devs%[email protected]> > . > > >>>>>> For more options, visit this group athttp:// > 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]<symfony-devs%[email protected]> > . > > >>>>> For more options, visit this group athttp:// > 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]<symfony-devs%[email protected]> > . > > >>>> For more options, visit this group athttp:// > 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]<symfony-devs%[email protected]> > . > > >>> For more options, visit this group athttp:// > 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]<symfony-devs%[email protected]> > . > > >> For more options, visit this group athttp:// > 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]<symfony-devs%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en. > > -- Pascal -- 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.
