Htaccess files in tree?

OpenEMR Development
1

ytiddo wrote on Thursday, May 27, 2010:

I was just writing some documentation on performing openemr upgrades, and noticed we have a .htaccess file in the tree, in the documents/ directory.

Now, I’m all for paranoia when it comes to handling of PHI, and preventing accidental misconfiguration, assuming that was the intention of the person who placed it in openemr over 5(!) years ago.

I’m really just highlighting it because if we want to place .htaccess files in the tree, there are at least three other places they should go (edi, era, freeb), and we might want to add .htaccess files covering some configuration data.

Alternately, we could yank this out of the tree. Either way, i’d like to see us establish a policy on the topic.

2

tmccormi wrote on Thursday, May 27, 2010:

I agree, on that same topic we should add a robots.txt file to protect people from themselves …
-Tony

3

anonymous wrote on Thursday, May 27, 2010:

From a security stand-point those directories and the sqlconf.php file should all be taken out of the public www directory and then referenced to a local directory on the host. The reason being is if your installation is compromised, to a point, then they would have access to the whole www directory anyways… Now, if they compromise the host… well you have bigger issues :wink:

Chris
www.ehrlive.com

4

stephen-smith wrote on Thursday, May 27, 2010:

Yes, ideally the code base would be split into “UI” files, which are directly requested by the user’s browser, “library” files which are not inside the “web root”, but are still required/included by the “UI” files, and “local” files which are written to something like /var/lib/openemr and loaded from there.  (“UI” and “library” files could be on a r/o filesystem.)

Unfortunately, that’s not what we’ve got and I don’t have the time to work on that right now.  In the meantime, .htaccess files are a stop-gap.  An example-robots.txt file would also make good sense, but it needs to be installed at http://host/robots.txt and all on the files currently in the tree are installed somwhere under http://host/openemr/.

5

bradymiller wrote on Thursday, May 27, 2010:

hey,
The LAMP stack approach is what lends itself to a cross-platform straightforward installation. I’m guessing our userbase would be much smaller without this LAMP structure. I wouldn’t remove the .htaccess file because some installations may be unknowingly relying on it; seems like it would be bad form to open up that security risk for those lost souls. Placing the .htaccess file in the other directories is up to the communiity; I don’t feel strongly either way.
-brady

6

ytiddo wrote on Thursday, May 27, 2010:

So, to bring this to a point, we don’t want to remove the .htaccess thats there, because someone MAY be relying on it.

Thats fine and dandy. I would say that for that person who MAY be relying on it, we should place one in the two other locations mentioned, AND make it clear in the installation directions that we are dropping .htaccess files in the tree; i would think the right place to document this would be on the page that gives you the cut-and-paste sections of apache config, for locking down those directories.

I’m assuming no-one will have a problem if i post a patch with these changes in it?

Justin Doiel

7

sunsetsystems wrote on Thursday, May 27, 2010:

I would vote for removing the htaccess files because they are Apache-specific and OpenEMR is otherwise generally not. Installation documentation would be the place to reference them.

But I don’t feel very strongly about it either way. If you make a patch, just be sure to test it.

Rod
www.sunsetsystems.com

8

stephen-smith wrote on Thursday, May 27, 2010:

On Thursday 27 May 2010 01:07:36 bradymiller wrote:
> The LAMP stack

Linux Apache MySQL PHP = LAMP

> approach is what lends itself to a cross-platform
> straightforward installation.

Sorry, Drupal and MediaWiki is LAMP and it still has a sane installation.  Writable directories are outside the web root unless they are intended to be accessed directly (and therefore, without access controls).  Configuration files are also stored outside the web root.  The initial configuration PAGES are inside the web root, but they recommend use Apache directives to disable access to those directories after the configuration is done.

Even if we want “explode the tarball in one place” as our preferred installation method.  (Which is a horrible method by the way.)  That doesn’t mean we shouldn’t isolate things to directories that are easily replaced with symlinks.

PS: Being unable to reply from my mail client and provide appropriate quoted context and threading is starting to annoy me.  Was there ever any traction on moving to a real mailing list?

9

drbowen wrote on Thursday, May 27, 2010:

Dear Stephen:

I have made the points previously that the configuration files should moved out of the web root (at least post installation).

Instead of .htaccess files, don’t the other LAMP projects place an “index.php” file in these directories that redirect back to the web root.  This prevents displaying the contents of the directory, is cross-platform and web server independent as well?

Prior security has depended on OpenEMR only being run on private LANs with the presumption that no one on the LAN is going to want to make a serious challenge to the security of an OpenEMR installation.  There are clearly more and more installations that are not on private LANs and presuming that the clinic office staff is always benevolent is not a very good approach to security.

Sam Bowen, MD
http://openmedsoftware.org

10

stephen-smith wrote on Thursday, May 27, 2010:

Using an index.php is only a partial fix.  It does prevent the contents of the directory from being displayed, but if the attacker knows a specific filename (or is willing to generate a lot of good guesses), the index.php won’t be used.

If the files are meant to be served directly, without access controls beyond what the web server enforces, they can be in the web root.  If the files must have access control based on the roles/permissions managed by the web application (OpenEMR), then they must be outside of the web root (or the web server must be configured to refuse direct access to them), and a php file used to “serve” them (check access control, write correct HTTP headers, sendfile()).  Otherwise, security is compromised.

Since no one seems to currently have the time to rearrange the tree to remove the sensitive directories from the webroot, we should (at least) make sure our installation documentation tells the user what directories they must protect via their web server.  If we want to provide redirector index.php’s or .htaccess files, we should provide them in all the sensitive directories and document them in (at least) the installation guide.  Consistentcy is key.  I think ytiddo has time to prepare a small patch to either remove the existing .htaccess or add additonal ones.

11

bradymiller wrote on Friday, May 28, 2010:

Sam,
You wanted to move the sql.conf file outside of the web directory, because you felt it was a security flaw. I then asked how a hacker would obtain the information in it, and you didn’t know. Perhaps we should focus on known security holes, rather than changing things because they “seem” like they would be a security flaw.

Stephen,
Here’s drupals installation instructions:
http://drupal.org/getting-started/6/install/download
And here’s drupals .htaccess that they park in the main directory:
http://drupalcode.org/viewvc/drupal/drupal/.htaccess?view=log
Some other sueful info:
http://drupal.org/node/244642
I did a quick install, and interestingly everything stayed within the drupal folder in the web directory…
Perhaps you’d like to reconsider your above statement, because it seems to me everything gets parked in the web directory.

The apache protection of the documents, edi, and era directories are desribed in step 6 of the installation instruction set, the INSTALL guide, and the installation instruction sets on the wiki…(the ubuntu package will even do this automatically on install) but agree it would be useful to document this requirement clearer because of the consequences.

To migrate the entire codebase so it’s “properly” organized doesn’t seem like a good use of resources. If your interested in spending some time on security issues, I’d rec fixing stuff that is known to be a security flaw (the sql-injection and cross scripting issues), which are described in bug tracker ids 2987498- 2987507. Also these projects would be working towards known security fixes:
http://www.openmedsoftware.org/wiki/Active_Projects#Clean_up_use_of_the_extract.28.29_function_on_post_and_get_variable_.28faking_them_as_globals.29
http://www.openmedsoftware.org/wiki/Active_Projects#Clean_up_magic_quotes.2C_prevent_sql-injection.2C_and_prepare_for_PHP6

-brady

12

bradymiller wrote on Friday, May 28, 2010:

Sam,
I do like that index.php idea, though, so at least won’t show the directory. Would need it in every patient directory. Could also have it email and send the the admin warning via messages module a huge warning that something is very screwed up.
-brady

13

bradymiller wrote on Friday, May 28, 2010:

Stephen and Justin,
Now that I’ve looked at Drupal, would it be useful to use their .htaccess method in the root to block the confidential directories and even standardize php5 settings rather than putting in each sensitive directory. Then could we only need to ensure apache is set to use .htaccess files?
-brady

14

drbowen wrote on Friday, May 28, 2010:

“You wanted to move the sql.conf file outside of the web directory, because you felt it was a security flaw. I then asked how a hacker would obtain the information in it, and you didn’t know. Perhaps we should focus on known security holes, rather than changing things because they “seem” like they would be a security flaw.”

Brady, just because I personally don’t have the skill to do this doesn’t mean it can’t be done.  As noted by Stephen above he apparently knows how and I am sure many others do also.

Every major LAMP based project that I have installed give security tips on how to batten down the hatches for production servers on the web.  They always strongly recommend moving  the MySQL connection information out of the webroot and give instructions on how to do this.  After the install is complete they recommend deleting all the installation commands.  The projects that I have looked at generally have not moved the confidential directories out of the webroot but have used some method of controlling access to these directories.  As Stephen notes moving these directories out of the webroot would be more secure.

The XOOPs confidential directories were used to create a PayPal phishing scheme in the oemr.org site.  This was accomplished by causing the Apache web server to insert the malicious script into one of the the oemr.org confidential directories.  The script was introduced to the Apache web server by putting it into the OpenEMR demo login text box and faking an attempt at logging in.  This was a cross-site scripting attack.  Rod Roark helped ameliorate this problem by placing some lines at the beginning of the globals.php file to prevent this particular attack and so far we haven’t had any more known successful attempts.

There are a number of computer science students at North Carolina State University who have been identifying security holes in OpenEMR and this is in the wiki as noted by Brady above. I think they identified 140 such instances in OpenEMR.  Dr. Laurie Williams at NCSU has been working on the security issues of health care programs and OpenEMR is one of the programs see and her students have been focusing on.

There is an interesting article by Dr. Williiams and her group, that these security issues are not addressed by the CCHIT certification process and that these security issues are rampant among all EHR / EMR programs:

http://www.google.com/url?sa=t&source=web&ct=res&cd=2&ved=0CBcQFjAB&url=ftp%3A%2F%2Fftp.csc.ncsu.edu%2Fpub%2Ftech%2F2010%2FTR-2010-1.pdf&rct=j&q=openemr+security+ncsu.edu&ei=Qrz_S_WwBMXflgfikcj4CQ&usg=AFQjCNEAgeaPopXPxG0WAZqDL0tx0U6-LA&sig2=W9kMXED0j9QHCWzL5T5C2A

As a group we had decided to focus on the Meaningful Use Certification Project first and then come back in a second wave and work on the known security problems.    We haven’t had the resources to take on both projects and systematically go through the list.   If you have the interest and the resources to do so, going through this list and helping with these security issues would be a big benefit to the OpenEMR project.

Sam Bowen, MD
http://openmedsoftware.org

15

richsiy wrote on Friday, May 28, 2010:

A file under web root can be obtained using the following example linux command:

wget  openemr.com/interface/forms/physical_exam/info.txt

Hope this help.

16

anonymous wrote on Friday, May 28, 2010:

I couldn’t have agreed with Dr. Bowen’s response more. To further emphasize the type of attack that can be prevalent; remember that PHP is server side scripting. With that being said any weakness such as one directory (tmp or cache) can result in a post of a .php file that can then read the config file and echo it back to the browser.

For instance if they were to create a simple php script such as this and then get it in the cache, edi, era, or tmp directory (which woulnd’t be hard since I believe the setup documentation calls for this to be either apache or world writable):

$out = ‘less …/library/sqlconf.php’;
echo ‘<pre>’.$out.’</pre>’;

The whole sqlconf.php file can then be echoed to the browser or dealt with in any other way. Of course there are other ways of this example but this is just for you to get the drift.

Chris
www.ehrlive.com

17

bradymiller wrote on Friday, May 28, 2010:

richsiy,
This won’t work on the library/sqlconf.php file.

Clucena,
Your proposed script could theoretically read in every file on the server(ie does not need to be in the web directory) that has access by the web browser, so the sqlconf.php file would be safe nowhere on the server computer…

Sam and Clucena,
Please point to specific project examples. Stephen’s claim that drupal moves stuff out of the web directory does not appear correct, so again I’ll pay attention when real life examples are produced. I simply want to avoid wasting time on witchcraft. For example, Drupal, put the sql settings within the webroot…
http://drupalcode.org/viewvc/drupal/drupal/sites/default/default.settings.php?revision=1.45&view=markup

And Sam my point was that if a developer plans to spend time on security issues, then fix the ones that are known to exist…

-brady

18

anonymous wrote on Friday, May 28, 2010:

Brady,

Actually, it wouldn’t be able to read anything outside the public web directory, especially if it’s chrooted… which I would hope that each person who install openemr creates a specific user for openemr administration and chroot that user to that particular public web directory. The also incorporate suphp or phpsuexec… of course this is getting into advanced apache/linux administration.

P.S. For the windows users out there using Xampp…. you’re screwed either way… because you have an unsecure version of WAMP and your using WINDOWS as a web server….

But Brady, you are correct when you say that Drupal, Wordpress, Joomla, etc… don’t have such security methods and don’t readily install directories outside the web root. But then again, they don’t have to comply with HIPAA and secure electronic patient health information (ePHI). I think we can all agree that moving such information outside root only helps secure the openemr installation.

Chris
www.ehrlive.com

19

bradymiller wrote on Friday, May 28, 2010:

Chris,

But the malicious script would be run through the web browser (ie. www-data or whatever), of which also needs to be able to have access to the sql_conf.php script…

Regarding your HIPAA scare argument, Drupal is way more secure than OpenEMR (if we emulated their security and techniques, we’d be golden: http://drupal.org/security/secure-configuration). Last time I checked HIPAA didn’t have a rule stating, “thou must move the sql config file out of the webroot”. You need to focus on the big picture here, all your chroot stuff for a theoretical security issue is for naught if you haven’t fixed the known security flaws.

-brady

20

anonymous wrote on Friday, May 28, 2010:

Brady,

I think you are missing the point. The security flaws/issues pertaining to OpenEMR dealing with whatever it may be, from code design to sql injections and cross-site/script hijacking is to gain access to data or the root dir (mostly nowadays it’s just to change the index.html or .php in order to get some kudos).

In either case, the worst case scenario that you would want is for an attacker to gain access to the web root and nothing more (meaning not the MySQL data, era, edi, or documents folders where ePHI exists). So to mitigate that risk (keyword “mitigate” because we will never in our lifetime be able to plug-up every single security whole in OpenEMR or any program for the matter); we should at least project that data to the minimum in the case of the OpenEMR web root being compromised through one of it’s many security flaws (not trying to bash the code, its just a fact of life that every program out there will have vulnerabilities).

That’s is what I am at least trying to point out that we can mitigate to a further point the risk of ePHI information getting into the wrong hands. I am very well aware that HIPAA does not explicitly state that we must have ePHI outside of the web root; but it does state that we should take all reasonable actions to protect ePHI from unprivileged access… and that’s exactly what this will do.

Thanks,
Chris
www.ehrlive.com