XF 1.5 Protection of Data & Internal_Data Folder Files

[Freelancer]

How can I prevent people from having access to files in the data and internal_data folder if they know the URLs? For example if some registered user forwards the exact URL to someone not authorized?

Is there a way to protect files from being accessed by unregistered users but let them be accessed by registered users?

 

[Mike]

The internal_data directory you can block all access to. We include a .htaccess for it and our Nginx config (for friendly URLs) blocks it.

The data directory is designed to be directly accessible, so you can't block it. I'd note that if someone knows the URL and wants to share the content, they can just download it and send it to people.

 

[Freelancer]

our Nginx config (for friendly URLs) blocks it

I actually have an NGINX server. I made an extra folder in the internal_data folder. Can you give me a tip how to use the NGINX config you mentioned?

 

[James]

I actually have an NGINX server. I made an extra folder in the internal_data folder. Can you give me a tip how to use the NGINX config you mentioned?

If you have friendly URLs enabled then it should block that directory as part of the same file I think Mike is saying.

https://xenforo.com/help/friendly-urls/

 

[Freelancer]

Friendly URLs are enabled and seem to work, but I can still access files in the internal_data folder directly when I paste the full URL into the browser while not logged in.

Does this excerpt from the help pages have to be added extra?

location /xf/ {
    try_files $uri $uri/ /xf/index.php?$uri&$args;
    index index.php index.html;
}

location /xf/install/data/ {
    internal;
}
location /xf/install/templates/ {
    internal;
}
location /xf/internal_data/ {
    internal;
}
location /xf/library/ {
    internal;
}

location ~ \.php$ {
    try_files $uri =404;
    fastcgi_pass    127.0.0.1:9000;
    fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include         fastcgi_params;
}

 

[Mike]

location /xf/install/data/ {
   internal;
}
location /xf/install/templates/ {
    internal;
}
location /xf/internal_data/ {
    internal;
}
location /xf/library/ {
    internal;
}

These are the lines that block access to specific directories. (You'll need to adjust them to fit your paths.)

 

[Freelancer]

Okay, if this has not been added to the NGINX config, the blocks have no effect right? That would explain why nothing is blocked.

 

[James]

Yeah if your file is empty your directories have been publicly accessible. You're best adding it ASAP.

 

[Freelancer]

So my server host has fixed this now. Thank you very much for the help.

 

[Freelancer]

Okay, now I have another problem... I can not link to download files that are in the "internal_data" folder... although logged in as user.

Scenario: I want to have downloadable files in a folder inside the "internal_data" folder (like /internal_data/download/filename.*) that are linked to the XF Resource Manager. Now when I click download it shows "404 – Not found"... What I wanted was to protect the files from direct linking and only allow registered users to download them via Resource Manager... Is this possible?

 

[Mike]

Nothing in the internal_data directory should ever be directly accessible. Anything in it has to be accessed via PHP. The data directory is the one that is directly accessible (without PHP).

If you just want to have them be accessible via the RM, doesn't uploading them into the RM solve the issue?

 

[Freelancer]

If you just want to have them be accessible via the RM, doesn't uploading them into the RM solve the issue?

That's where I started (and I should have mentioned it maybe...) But the specific files are ignored by the Resource Manager. They are Android App files that start to upload till the progress bar reaches 100% and then hang while the upload animation gif loops... I think that "com.appname.app.apk" might be a problem with XFRM... I was uploading the files into a folder as a workaround but now I am stuck. Any idea appreciated.

 

[James]

Did you report that as a bug or issue to be looked into?

As a workaround you can zip the .apk files and upload a zip?

 

[Freelancer]

Did you report that as a bug or issue to be looked into?

Not yet, as it might be more like a "missing feature" than a bug.

As a workaround you can zip the .apk files and upload a zip?

I tried that too, until realizing that if users download the apps as zip directly to their phones they might have trouble. It's not a real good solution. What I want to achieve is that users are able to download and install the apps directly with their mobile devices. Maybe this is a good suggestion for a XFRM extension to support app downloads?

 

[Mike]

We get to the root of the problem...

There's nothing that would cause a particular type of file to be rejected in the RM. It's likely that the files are either too big and you need to configure some server variables or there's something else causing the file to be rejected on the server level.

 

[Freelancer]

I can assure I double checked the XFRM settings.

The files are 32 MB and 28 MB and I allocated 40960 KB in the options and filled in the "apk" extension. With the apk extension alone the files are not recognized in the browser upload dialog. So I changed the setting to "app.apk". Then they are recognized and I can start the upload.

The progress bar stops at 100% and then hangs while the gif animation loops infinitely (at least I haven't waited longer than five minutes).

I also should mention that my board uses the HTML5 uploader instead of the flash uploader. I also uninstalled flash from my computer... I had no problems with it anywhere anytime before.

My first guess would be the somewhat exotic file name construction "com.filename.app.apk". But when I compress it into a zip it is named "com.filename.app.apk.zip" and then can be uploaded. But I need it uncompressed since users will download it straight to their phones/tablets.

But looking into the browser console I was surprised to see a SWF Alert...

The app extension list



Now it gets interesting because when I upload the uncompressed file "com.filename.app.apk" I get the following error:



If I upload "com.filename.app.apk.zip" I do not get any console error and the upload works.

 

[Mike]

Can you upload it as an attachment to a post?

When you say you're using an HTML5 uploader, do you mean an add-on? (The default, non-Flash uploader isn't really what most people mean by an HTML5 uploader.)

 

[Freelancer]

I use the https://xenforo.com/community/resources/tinhte-html5-uploader.3130/ add-on.

Tried to upload it to a post (before I copied the XFRM settings to "Attachments" options) but get the following error without a console error:



It would not upload it in the first place if the extension wasnt in the settings but I guess the after upload processing of the file gives the script a hiccup...

 

[Mike]

That would be because "app.apk" isn't really the extension -- "apk" is what's needed.

You'll need to disable that (and possibly other) add-ons to do the testing here. You have to take add-ons out of the equation.

 

[Freelancer]

XenForo me.... We found the problem...

When I use "apk" alone, the file is not recognized and can not be uploaded. When I use "app.apk" the file is recognized and can be uploaded but without "apk" it will not be processed.
So I filled in "app.apk" AND "apk" and BINGO, now it works as it should... So the conclusion is that uploading and processing seem to be two different things.

Thanks @Mike for the help.