FORUMS


The Form Tools forums are no longer active, but the old posts have been archived here. Please see the Help page on how to get help / report issues.

Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Security of Data and files
#1
I noticed that anyone can get to the directory of uploaded files if they know the name of the folder. What is the best way to secure that data so that the public can't view the files?

I was thinking about adding a .htaccess file.... but then I suppose one would have to enter a username and password when they wanted to see the files (these are images in this case).

The other option I could see is changing the uploaded files directory to something that is hard to guess, and then adding an index.html file to it, so they can't see the images. The only way for them to see the files (photos) would be to actually guess the name of the images.

Anyone else have any suggestions?

Also... how secure is the rest of the data (non files)? I would assume that the only way to access it is through a script and obtaining the username and password to the database?

Thanks,
Alex
Reply
#2
Hi, Alex.

I can't speak on behalf of Ben but I'll try to address this in broad terms since I'm of the belief that security should be applied through layers; it's never one thing.

The first thing I'd do with any Form Tools installation is obfuscate the installation directory (either on the public root or in it's own subdomain). Naturally, this depends on the application you have in mind. In my case, staff and sysadmins need only ever access the Control Panel; I never expose it to the public and setup .htaccess rules accordingly.

Something like:

Code:
Order deny,allow
Deny from all
AuthName "htaccess password prompt"
AuthUserFile /path/to/.htpasswd
AuthType Basic
Require valid-user
# Allowed IP Address(es)
Allow from 127.0.0.1
Satisfy Any

Always place files requiring public access (e.g. forms) outside of the FT directory (this includes upload directories). Always ensure any form you set-up for accepting uploads has strict client- and server-side validation (e.g. never allow PHP files to be uploaded). You get the idea.

Never expose the FT directory in your robots.txt file for excluding webcrawlers; use .htaccess for this.

One thing I'm curious to get Ben's take on (and this is more a feature request) is to include the following line on all include files that only ever need to be accessed locally be the host:

PHP Code:
<?php if (eregi("name_of_file.php"$_SERVER['PHP_SELF'])) die('This page is not directly accessible'); 

Probably extraneous but, again, it adds an extra layer of protection; the FT config file should probably include this (contains your db credentials). It essentially tells the server to never execute the script unless it's accessed locally by the host.

I could go on but that's how I'd approach things in a broad sense.
Reply
#3
Thanks for the reply!

Although I am still somewhat of a beginner to all of this, I think I've got a grasp of what you are saying.

My main concern right now is that one would be able to view the images that are uploaded by the people that submit the forms (non-employees).

Several employees will have logins to the formtools application where they are given a read only view of the submitted data. An important part of that data are the images.

If I place the htaccess file that you suggest, in the upload folder (whatever it may be called, to hide it's location, won't the user be prompted for additional credentials when viewing that table of data, so it can display the photos? It wouldn't be a big deal for me, but I'm never going to be able to get my users to remember TWO sets of logins!

What do you think? I'm just crossing my fingers for something easier.

Also, I have set the file types to only allow gif and jpg uploads... Is that sufficient, or is there something else I need to
do to prevent someone from uploading a php script??

Thanks for your time!
Alex


(May 3rd, 2011, 12:27 AM)crunchers Wrote: Hi, Alex.

I can't speak on behalf of Ben but I'll try to address this in broad terms since I'm of the belief that security should be applied through layers; it's never one thing.

The first thing I'd do with any Form Tools installation is obfuscate the installation directory (either on the public root or in it's own subdomain). Naturally, this depends on the application you have in mind. In my case, staff and sysadmins need only ever access the Control Panel; I never expose it to the public and setup .htaccess rules accordingly.

Something like:

Code:
Order deny,allow
Deny from all
AuthName "htaccess password prompt"
AuthUserFile /path/to/.htpasswd
AuthType Basic
Require valid-user
# Allowed IP Address(es)
Allow from 127.0.0.1
Satisfy Any

Always place files requiring public access (e.g. forms) outside of the FT directory (this includes upload directories). Always ensure any form you set-up for accepting uploads has strict client- and server-side validation (e.g. never allow PHP files to be uploaded). You get the idea.

Never expose the FT directory in your robots.txt file for excluding webcrawlers; use .htaccess for this.

One thing I'm curious to get Ben's take on (and this is more a feature request) is to include the following line on all include files that only ever need to be accessed locally be the host:

PHP Code:
<?php if (eregi("name_of_file.php"$_SERVER['PHP_SELF'])) die('This page is not directly accessible'); 

Probably extraneous but, again, it adds an extra layer of protection; the FT config file should probably include this (contains your db credentials). It essentially tells the server to never execute the script unless it's accessed locally by the host.

I could go on but that's how I'd approach things in a broad sense.

Reply
#4
Hi, Alex.

To be honest, I'm still learning myself. Putting the password access issue aside for a moment, some basic things you could do is create an htaccess file in the uploads folder and prevent index listing and script execution:

Code:
Options -Indexes
AddHandler cgi-script .php .phtml .pl .py .jsp .asp .htm .shtml .sh .cgi

As well as preventing unauthorised script execution, staff members would now have to know the the image file name in order to view any of the said pictures uploaded to this directory.

Furthermore, since you're only allowing pictures to be uploaded, you can restrict other files as follows:

Code:
<Files ^(*.jpeg|*.jpg|*.png|*.gif|*.png)>
order deny,allow
deny from all
</Files>

Also, try assigning the uploads directory 775 permissions instead of 777.

The best solution is to see if you can move the uploads directory outside of the WWW root (depends largely on webhost and setup).

Everything else you've described in terms of set-up sounds fine; Formtools provides a lot of the logic and necessary helper functions for dealing with uploads.

It's always a trade-off between security and accessibility but the above tips should help provide you with a good baseline.
Reply
#5
Thanks, all good ideas!

I just thought of one this morning... what about setting a .htaccess file to only allow access from certain IP addresses. Since everyone accessing it will be at one location that uses static IP addresses, that should work fine, right?!

Alex
Reply
#6
Hey all,

2.1.0 (the current available version) contains an index.html in that folder. All that that does is prevent the browser from displaying the contents of the folder. It's low-fi, but it solves the immediate problem.

Alex, using .htaccess is definitely better from a security point of view, but like you said, it would require users to be perpetually entering their login credentials - plus you'd need to go through the legwork of setting up the actual permissions. It all depends on your situation and your judgment. If the content being uploaded is very sensitive, then yes - password-protecting the whole folder with .htaccess would make sense. Also, you might want to consider using a custom upload folder which would be harder for a hacker to guess (e.g /uploads59115 or something random).

The other possibility (depending on how security-conscious you feel you need to be) is to specify an upload folder that's above the actual webroot. This will break any links to the files in the user interface (since they won't be accessible via an http:// location), but the files will still be properly uploaded to the server. No-one without server permissions would be able to access the files.

- Ben
Reply
#7
(May 3rd, 2011, 3:21 PM)alexh Wrote: Thanks, all good ideas!

I just thought of one this morning... what about setting a .htaccess file to only allow access from certain IP addresses. Since everyone accessing it will be at one location that uses static IP addresses, that should work fine, right?!

Alex

Provided the IP address @your office is static (which you say it is), then for sure. That's certainly how I'd approach it, Alex.

As Ben reiterated from my earlier post, moving the uploads directory outside of the public root would be the best solution. If you can't, the above guidelines will work fine.

Ben: Good idea re:index.html/forbidden directory access.

Reply
#8
Oh by the way, guys: a few weeks back we had Form Tools go through a security review by Acunetix. Only a few minor issues were found, which have all been fixed in 2.1.0.

Nothing terribly major was spotted - but the long listing on the folder that you mention Alex was among them. Hence the 2.1.0 fix. Smile

Anyway, just FYI!

- Ben
Reply
#9
Gotcha.

Yeah, the first thing I did was place a index.html file in the uploads folder. I was going to change the name of the folder, but I wanted to make sure that it wouldn't screw anything up.. and make sure that I knew exactly where and how many times I had to make that change on the back end.

Unfortunately I don't think I can move that folder below the webroot because then the users who log in, won't be able to view the photos in the table display.. or when the edit or view the entries. (I'd be happy to explain exactly what I'm trying to accomplish with this tool if you want to PM me).

Again - thanks for all your help!

Alex

(May 3rd, 2011, 8:16 PM)Ben Wrote: Hey all,

2.1.0 (the current available version) contains an index.html in that folder. All that that does is prevent the browser from displaying the contents of the folder. It's low-fi, but it solves the immediate problem.

Alex, using .htaccess is definitely better from a security point of view, but like you said, it would require users to be perpetually entering their login credentials - plus you'd need to go through the legwork of setting up the actual permissions. It all depends on your situation and your judgment. If the content being uploaded is very sensitive, then yes - password-protecting the whole folder with .htaccess would make sense. Also, you might want to consider using a custom upload folder which would be harder for a hacker to guess (e.g /uploads59115 or something random).

The other possibility (depending on how security-conscious you feel you need to be) is to specify an upload folder that's above the actual webroot. This will break any links to the files in the user interface (since they won't be accessible via an http:// location), but the files will still be properly uploaded to the server. No-one without server permissions would be able to access the files.

- Ben

Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)