Hi all Good catch Eric Roger, and thanks for the report. Please, next time you find a security issue on Diem demo site, firstly notify the team. We fix it quickly, and then you make the issue public. That's the way security issues are generally handled.
Cheers, Thibault On Feb 1, 1:50 pm, Pascal <[email protected]> wrote: > 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:// > > ... > > read more » -- 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.
