Add secure instructions to wiki on protecting the data directory if user forced to put it in web root

[cash]

As discussed in email

[cash]

I'm stuck. It does not seem possible to protect the data directory purely through deny/allow directives in a .htaccess file. The issue is that a user could upload a .htaccess and if they can guess the data directory, run scripts from their directory.

There are things that we could do to increase the security such as put checks in for users uploading .htaccess files (but we have no control over plugins) or use mod rewrite to send requests for files in the data directory elsewhere. The mod rewrite redirect should work but is not foolproof (a server misconfiguration could break mod rewrite).

Actually, the most secure option seemed to be generating a 500 error by putting invalid directives in the .htaccess file but that feels very hacky.

The problem that I'm trying to solve is making an easy to set up, secure solution for those on shared hosting. They won't be able to put the data directory outside their web server root. They probably won't be able to set Apache directives in httpd.conf or similar. That leaves them with trying to use .htaccess to protect the data directory.

I could allow them to put the data directory under their elgg directory and throw up a warning with a link to exhaustive instructions on securing the server. What I'm trying to avoid is making it easy for those on a virtual server/dedicated server to create an insecure install while giving those on shared hosting some options. The current state of things is that shared hosting people install elgg in a subdirectory and put the data directory in a parallel sub directory (probably wide open for exploitation).

[cash]

(In [svn:9088]) Refs #3453 an implementation of creating the data directory. This capability is turned off due to security concerns.

[cash]

(In [svn:9089]) Refs #3453 added $CONFIG->data_dir_override so that people can put the data directory in Elgg's root if they want to. Will add instructions to the wiki on using this and protecting the directory

[cash]

(In [svn:9095]) Fixes #3453 added link to wiki about the data directory

[ewinslow]

Can you not use AllowOverride none in .htaccess?

[cash]

no

[ewinslow]

Wanted to revisit this because I think we can do better, since the current suggestions on the wiki are still insecure.

You said mod rewrite could be broken by server misconfiguration, but doesn't this mean that Elgg would be broken too? Why is this not acceptable?

What about storing files on the filesystem using something other than the original file name (e.g. md5(originalfilename . guid . timestamp))? Then there's no way someone can upload a file that is stored as .htaccess on the filesystem, or any other magic name or extension for that matter.

[cash]

Replying to ewinslow:

Wanted to revisit this because I think we can do better, since the current suggestions on the wiki are still insecure.

I haven't had a chance to add secure instructions to the wiki. The current ones were written before I investigated this.

You said mod rewrite could be broken by server misconfiguration, but doesn't this mean that Elgg would be broken too? Why is this not acceptable?

Are you referring to "Actually, the most secure option seemed to be generating a 500 error by putting invalid directives in the .htaccess file but that feels very hacky."? It not only feels hacky but people like to fix errors and someone could accidently open up the data directory.

What about storing files on the filesystem using something other than the original file name (e.g. md5(originalfilename . guid . timestamp))? Then there's no way someone can upload a file that is stored as .htaccess on the filesystem, or any other magic name or extension for that matter.

I guess you are assuming Elgg is the only web application running on the server and that plugins aren't allowed to write to the data directory. Having a directory in web root that is writable by the web server is a bad idea unless it is locked down at the server configuration level.

[ewinslow]

I haven't had a chance to add secure instructions to the wiki. The current ones were written before I investigated this.

Do we have a ticket for this anywhere? Don't want that task to get forgotten.

I was referring to this comment:

There are things that we could do to increase the security such as ... use mod rewrite to send requests for files in the data directory elsewhere. The mod rewrite redirect should work but is not foolproof (a server misconfiguration could break mod rewrite).

A directive like this sounds like it would make things significantly more secure, even if not foolproof. Why not just go with it?

It not only feels hacky but people like to fix errors and someone could accidently open up the data directory.

I was thinking that if we did include this file with an invalid directive, the "directive" would simply be the documentation explaining what the file is for. That way it doesn't get confused for a bug. It's hacky, but if we do this in addition to the mod rewrite strategy, then it's just our fallback in case of the server misconfiguration you mentioned. I can live with that.

It sounds like all of the suggested methods have certain problems, so we definitely shouldn't rely on any one particular strategy.

Also, thanks for entertaining this discussion: I now have a much better understanding of why Elgg is probably never going to have a plugin installer. These security issues are a major hassle...

[cash]

Replying to ewinslow:

Do we have a ticket for this anywhere? Don't want that task to get forgotten.

I changed this ticket to that ;)

I was referring to this comment:

There are things that we could do to increase the security such as ... use mod rewrite to send requests for files in the data directory elsewhere. The mod rewrite redirect should work but is not foolproof (a server misconfiguration could break mod rewrite).

A directive like this sounds like it would make things significantly more secure, even if not foolproof. Why not just go with it?

I was wrong. The rules in a .htaccess file in a local directory take precendence over those in the parent directory. This fact prevents any of these ideas from working (except the incorrect directive - I think that should still "crash" Apache).

Also, thanks for entertaining this discussion: I now have a much better understanding of why Elgg is probably never going to have a plugin installer. These security issues are a major hassle...

There is the trade-off between security and functionality. Elgg has always leaned more toward security while applications like WP have leaned more toward functionality. I think Elgg needs to lean toward security because it trusts all users while WP only trusts the authors. A plugin installer is actually easier to do than a data directory for users (though still fraught with security challenges).

[brettp]

@Cash - Do you have notes on these instructions?

[cash]

Sorry for the late response. It is fairly simple if I recall. Turn off allow override in the apache config and set a deny all directive.

[tomv]

Suppose we automatically create an, possibly empty, .htaccess file in every user data folder upon user creation? This ,htaccess would have with permissions set to 444, not allow to over write. As long as 3rd party mods do not create additional folders, we are ok, are we ?

[tomv]

Maybe this works to prevent upload/rename php files in the data folder ?

RewiteEngine On
RewriteCond %{REQUEST_METHOD} ^{PUT$ [OR]
RewriteCond %{REQUEST_METHOD}} MOVE$
RewriteRule ^{elgg_data_folder/(.*)\.php elgg_data_folder/$1.nophp}

[tomv]

RewiteEngine On
RewriteCond %{REQUEST_METHOD} ^PUT$ [OR]
RewriteCond %{REQUEST_METHOD} ^MOVE$
RewriteRule ^/files/(.*)\.php /files/$1.nophp

[cash]

Tom, your suggestion to create read-only .htaccess files will work for you. It's not fool-proof though. The only way to achieve that is server level configuration.

[tomv]

We have solved it on server level.. .was thinking about those people that have to host on shared...

[cash]

​http://docs.elgg.org/wiki/Data_directory