This is a good start. But mime types are not the real issue - web servers decide what to do with a file based on extensions. Telling people to check mime types is confusing. And your server's configuration determines what's dangerous, really. Some servers are configured to run PHP code in .html files. (No, this is not a default most places)
I think the Symfony validators' focus on mime types confuses the core security issue. Don't trust the filename provided by the user, ever. Grab the stem, preg_replace to get rid of anything that isn't \w+, sniff the actual content type or use the provided file extension purely as a clue to that, and then choose an appropriate extension yourself from a whitelist of types that your users are supposed to be uploading. On Mon, Feb 8, 2010 at 9:23 AM, Flukey <[email protected]> wrote: > A few correction :-) I hope you don't mind. > > "When it comes to security, the very first rule is that all data sent > by users should be validated before being stored on the server. > > Experience shows that some developers give poor, little or no > attention at all to validating file uploads. > > This is mostly due to laziness. However, sometimes the purpose is to > build a more flexible form. Example: a CV upload field that accepts > any file extension. > > This is a huge security mistake. > > Why? Because these files by default are stored in the uploads > directory which is publically accessible. > > If one of your users succeeds in uploading a php file, such as > attack.php through one of your forms, then he will be able to run the > script just by using the http//your-sf-project.com/uploads/attack.php > uri. > > If the aforementioned php file contained malicious code then the > hacker could get access to your database settings, user details, > delete data etc. Therefore it is absolutely critical that uploaded > files are validated. > > First step: check all of your file upload fields > > Have a look at the file validation documentation. Do all of your > validators have customised mime_types or a mime_categories option ? > You should also prevent your forms from accepting the .htaccess mime > type. > Second step: disable php execution in the "uploads" directory > > If you have access to the httpd.conf file, add the following rule to > your virtualhost: > > <VirtualHost *:80> > > ... > ... > <Directory "/path/to/my/sfProject/web/uploads"> > php_flag engine off > </Directory> > </VirtualHost > > > If you don’t have access to the httpd.conf of your host, add a > new .htaccess file in your /path/to/my/sfProject/web/uploads > directory: > > php_flag engine off" > > On Feb 8, 3:09 pm, Éric Rogé <[email protected]> wrote: >> I've added a new todo on Symfony Check >> :http://symfony-check.org/permalink/protect-yourself-against-user-uplo... >> >> 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. > > -- 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.
