I've added a new todo on Symfony Check : http://symfony-check.org/permalink/protect-yourself-against-user-uploaded-files
My english can be pretty sloppy sometimes, corrections are welcome. On Feb 1, 3:15 pm, Tom Boutell <[email protected]> wrote: > I'm not suggesting that web/uploads shouldn't be 777. Like cache/, it > wouldn't be much use for its intended purpose if it wasn't. > > The issue here is managing what can be uploaded responsibly, and the > way to do that might be by adding some conspicuous and convenient > validators now in Symfony 1.4 for common cases (image files), and > perhaps by forcing the developer to specify an explicit list of mime > types in Symfony 2.0 or else nothing is accepted (but please don't > break perfectly good Symfony 1.4 code today over it). > > (Regarding the use of 777, itself, it would be nice if Symfony allowed > some alternate definition of "writable enough for the web server." But > that's a separate issue mostly of concern in traditional "shared > hosting" environments where Symfony shouldn't be used anyway. Anybody > not taking advantage of $20/month virtual machine hosting from > servergrove or slicehost or linode by now really needs to do their > homework.) > > On Mon, Feb 1, 2010 at 2:08 AM, Fabien Potencier > > > > > > <[email protected]> wrote: > > On 2/1/10 12:58 AM, Tom Boutell 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. > > > Wait, all this ONLY "works" if and only if the webserver has write access to > > these directories/files, right? ... which is not the case by default, right? > > > Fabien > > >> 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. > > > -- > > 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.
