Hey I didn't know about Diem, very nice!!! On Tue, Feb 2, 2010 at 2:12 AM, Thibault D <[email protected]> wrote: > 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. > >
-- 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.
