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.
