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.
