XODA directory /files unprotected

apps
#1

I installed XODA and it seems to work fine. Intuitive UI, simple to use, great.

But when I type the following URL:
http://subdomain.domain.com/files
in my browser the content of that directory is shown (in the standard courier lettertype browsers show this normally). /files is the directory where XODA starts uploading the files.

[size=small][font=Courier]Index of /files

  Name                    Last modified      Size  Description
  Parent Directory                             -   [/font][/size]

.htaccess file (http://subdomain.domain.com/.htaccess) has the following content:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /?action=$1 [L,QSA]

I have the feeling that the problem has to do with .htaccess (failing to include subdirectories) but I’m not sure (and don’t know any solutions).

Is there someone with suggestions?
Tnx.

#2

What is it that you want? You neglected to mention that. Otherwise let me explain the .htaccess file. Those instructions indicate that if the request is not for a directory and is not for a file then /?action=$1 is used instead of what was requested. In other words there are no instructions to avoid displaying the contents of a directory (when there is no index file present).

#3

Hi, riviere!
This turned out to be a bug.
The mistake not really to have tested it was made most probably because of the official recommendations (set the ROOT_DIR as absolute path, e.g. ‘/home/riviere/xoda/files/’) or to protect the relative path with “.htaccess/.htpasswd”.
The solution for your problem would be to adhere to the official recommendations or to add ‘Options All -Indexes’ to the ‘.htaccess’-file.
Please note that we have a forum which acts as official support platform. This is why asking for support here may cause significant delays in the answers.
Thank you! :slight_smile:

@Atropos7
Even if it doesn’t look like this on a quick view, there are instructions to avoid displaying the contents of a directory. They are in the PHP though and displaying the content of a directory is in deed not supposed to happen.

#4

Hi Betso,
Thanks for your fast response. Next time I will switch over to the official support forum. I didn’t know it was there :-))

I think it’s working now!
I made a new (test) subdomain, installed xoda again, changed the directory to
/home/riviere/files/
The files directory was created somewhere in my Dreamhost account, but I want the files to be within my subdomain.
So I started again with:
/home/riviere/subdomain.domain.com/files/
and the files are now stored within the domain, so that is fine.
But now I can see the files again when I use the URL:
http://subdomain.domain.com/files/
Adding the ‘Options All - Indexes’ to the .htaccess seems to do the trick. I can’t see the /files directory any more (but do not know how to test it properly)

The following line in the manual:
"You should set a directory outside your web directory to be ROOT_DIR!"
is probably not clear for me. I understand now that ‘/files/’ is not the correct ROOT_DIR.
But /home/riviere/subdomain.domain.com/files/ is probably also not allowed.

For me it doesn’t make sense to place the files in the Dreamhost space ‘/home/riviere/…’ instead of the subdomain (or directory on a domain).

Thanks again for your solutions. And for creating (and sharing) Xoda! Its great!

#5

It is.

Why?
This is a safe (and also recommended by the DreamHost staff) way to protect your files against potential security flaws (like the one you discovered).
My suggestion in the previous post was to use /home/riviere/xoda/files/. Try this (set it in config.php) and see how it behaves. :slight_smile:

#6

Thanks Betso for your reply. After writing the last part I went away from my computer, trying to get some sleep. And that are the moments to think about what is said. And I figured out that the way you handle the files/directories are a safe way to do it. So I already planned to change the location of the files as you mentioned. And it works great. So my Xoda is alive and working fine.
The reason I didn’t want this at first was more a practical one. If all my used applications were using the Dreamhost space for files and directories it ends up to be a mess. But security is importent enough to change my opinion on that. And because Xoda is the first application I use that stores files in the Dreamhost space it will be ok. Thanks again for helping me understand how Xoda is working.

#7

Actually I don’t know how DreamHost considers the files managed by XODA: if they count to the unlimited web space or to the 50 GB of “backup space”. But you should know that this is not related to the path you store the files. You could place the files in your home directory and let them be managed by a web application (like XODA) or you could place them in your web path (and protect them with .htaccess/.htpasswd). Either way is legitimate and the interpretation whether this is own backup or a web site should be made by DreamHost independently of your choice for the ROOT_DIR.
Thanks for the nice words and enjoy XODA! :slight_smile:

#8

Storing files related to your web site outside of its main directory for security purposes is totally OK (and, in fact, encouraged). What we take issue with is storing files unrelated to your web site(s) on the web server — they’ve got a limited amount of storage, so we’d rather you use a backups user for that (Users > Backups User). Those are set up on machines with much more storage available.

#9

Thank you for this clarification, Andrew!
I didn’t know that you use another server for the backups users.
Would it be then possible to make the One-Click Install for XODA available primary for a backup user (and only optionally for the web user)? This might help DreamHost but also users.
Thanks and take care! :slight_smile:

#10

The programming is genius. Very well thought out and the code is clean and well written. I am finding the username and md5 encrypted password information is containted in the config.php file that resides in the web folder. Is it possible that the config.php file can be located outside the web directory as well? A fake config.php file that references the real config.php file outside the web folder? I would sleep better if the username and password information could be split out and stored in the root as well. Any security precautions or permissions to apply to the config.php file in the meanwile?

#11

Thank you for the wonderful words, Rickkee!
Relocating config.php is a great idea even though it doesn’t output anything if called directly. I will let it be “defined” in a future version (e.g. in index.php) which will make relocation more easily done.
As of now, you could do the following: find the ocurrence of the string ‘config.php’ in index.php and functions.php and replace it with ‘/full/path/to/your/config.php’. This should do the trick.
You could also change its permissions to -rw---- (0600) making sure that the owner is whoever user the webserver is being run by. I don’t consider this one a great protection strategy though.
Thanks for the great idea! :slight_smile:

#12

Just to note something, you can hide the indexes of your folder via .htacces:

Options -Indexes

Put that at the top of your .htaccess, and no one will be able to see the contents of any folders unless they hit a file directly.

#13

Thanks a lot for the suggestion! :slight_smile:

#14

Hey thanks for the tip!
I needed to get 750 users into the system, fast and it was going to take a while doing this by hand and letting the program convert the passwords to MD5, So I found an excel spreadsheet that will convert passwords to the MD5 format. A little messing around with MSWord merge, paste into the config.php file and I was done in no time. I am happy to report the system can handle 750 users, at least from a login perspective. I was afraid it might choke on a $3.95 a month webserver but its flying…Will know more when we turn the users loose with it on Friday.
You can get the Excel -> MD5 converter spreadsheet here:
http://filedb.experts-exchange.com/incoming/2008/05_w20/24543/md5.xls

#15

Thanks for this very valuable information, Rickkee!

Btw., how did the relocation of config.php work?