XF 2.3 How do I secure uploaded content from being directly accessed on the web?

zoldos

zoldos

Well-known member
So I found out that sites like "Primeyes" (not sure if it's still on-line) and other A.I. powered sites/utilities have the ability to view and maybe even index uploaded content/media on my forum without being logged on even though everything is member's only, and people must be logged in to access such things.

I tested it myself and confirmed this. Also, if someone knows the exact URL of a picture/video/zip, etc., then anyone on the web with this URL can view the content on my forum, member or not. An example is the media sharing feature in XFMG. If you give a "direct link" (from the share widget) to someone, they can then directly access the content without any account or login.

This is unacceptable for me as my site is private and adults only, and I don't allow sharing of posted content in this manner. I tried putting the entire XF folder under a domain level protected directory, which fixed it, but broke my site (lots of stuff, mainly any FA icons and moods wouldn't load, and my third party chat broke as well).

I was told I can do something with .htaccess file to prevent direct access attempts to the media/attachments folder(s). I don't know how to do this, but I did attempt a few tests that failed (I didn't get any errors, and my site still worked), but the content was still viewable without logging in.

Can anyone help? Thanks!
 
Sort by date Sort by votes
Afraid I don't run the XFMG add-on with any of my sites, so can't comment on the extra functionality that might bring around media assets. However for a vanilla XF forum a few notes which may be of use to others reading this ...

So requests via the forum (like Mr Lucky's URL example above) may be blocked (depending on configured user permissions), but if you don't have your webserver configured correctly you can accidentally allow access to the actual attachment media located in the internal_data directory. URLs to that can be constructed from the thumbnail images which are accessible to the public, so URLs could leak that way. So taking a recent post of mine where I added a screenshot by way of an example. The attachment thumbnail URL is https://xenforo.com/community/data/attachments/322/322514-55453a58bfffbadd750f6e5bbe422dae.jpg from which we can deduce the actual attachment should be located at https://xenforo.com/community/internal_data/attachments/322/322514-55453a58bfffbadd750f6e5bbe422dae.data were this site miss-configured then I'd be able to download the full size image. It however is correctly configured to block access. That is the only route (other than a misconfiguration of permissions within XenForo itself) that I can think of off the top of my head for leaking images. If your webserver is really badly configured then you might have autoindexing enabled on your data and internal_data directories allowing someone to actually browse the assets. I am pretty sure that as-shipped XenForo running under Apache (which would use .htaccess files) restricts access. Running under Nginx (which it seems this site is) you'd need to add some configuration. Typically something like: location /internal_data/ { internal; } to restrict access to just internal sub-requests.

You've already suggested you are running under Apache so I wonder if the issues you are encountering are more associated with the XFMG add-on and the functionality that provides. For a conventional XF deployment the shipped .htaccess file in the internal_data directory:
Code: 
Order deny,allow
Deny from all
Should be enough to restrict access to that and all the subdirectories. Is that file and contents present in your internal_data directory?

Are the URLs you are testing ones like Mr Lucky's or ones with the internal_data directory in the path? If the former then the problem probably lies with actual XF permissions and if the latter then it's more likely a miss-configuration in the webserver.
 
Upvote 0 Downvote
Mr Lucky said:
I’m sure that should not happen.

Testing a members only attached image:

Click to expand...
Here is an example (don't worry, it's PG): https://bloodofsouls.com/data/attachments/8/8036-7f0c03a3071b4db3a22ac6f0915f0e72.jpg

As for the other replies, here is my current .htaccess:

Code: 
#   Mod_security can interfere with uploading of content such as attachments. If you
#   cannot attach files, remove the "#" from the lines below.
#<IfModule mod_security.c>
#   SecFilterEngine Off
#   SecFilterScanPOST Off
#</IfModule>
ErrorDocument 401 default
ErrorDocument 403 default
ErrorDocument 404 default
ErrorDocument 405 default
ErrorDocument 406 default
ErrorDocument 500 default
ErrorDocument 501 default
ErrorDocument 503 default
<IfModule mod_rewrite.c>
    RewriteEngine On
    #   If you are having problems with the rewrite rules, remove the "#" from the
    #   line that begins "RewriteBase" below. You will also have to change the path
    #   of the rewrite to reflect the path to your XenForo installation.
    #RewriteBase /
    #   This line may be needed to workaround HTTP Basic auth issues when using PHP as a CGI.
    #RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

#   RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?bloodofsouls.com [NC]
#   RewriteRule \.(jpg|jpeg|png|gif|mp4|mp3|webp)$ - [NC,F,L]

    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -l [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^.*$ - [NC,L]
    RewriteRule ^(data/|js/|styles/|install/|favicon\.ico|crossdomain\.xml|robots\.txt) - [NC,L]
    RewriteRule ^.*$ index.php [NC,L]
</IfModule>
You'll note I was trying something someone suggested: "# RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?blood...." but it didn't seem to work so I commented it out.

Thanks for all the help!
 
Upvote 0 Downvote
Attachments have a very long random file name, so it cannot be guessed.

AFAIK, at least for images the real path is never exposed. The images are delivered to the user by the AttachmentController (file src/XF/Pub/Controller/AttachmentController.php): you pass the attachment ID (which is stored in the database) and the controller checks the permissions and shows you the attachment. The url looks like attachments/filename.123 (or for XFMG, where another controller is responsible, images have an url like media/media-name.123/full)

Videos are handled differently. You can read about it here:

Sim

As designed Thread 'All video attachments are publicly accessible'

It seems that all video attachments are stored in the data directory rather than in internal_data - which means that they are publicly accessible, even on a private forum, unlike photos or other attachments.

If someone was to extract the video URL from the page and send it to a 3rd party who does not have access to the forum, they would still be able to view the video.

Steps to reproduce:
  1. in a forum that does not have public access, create a post with the following items attached:
    1. an image
    2. a document, such as a PDF file
    3. a video
  2. copy the URLs for...
  • Like

zoldos said:
You'll note I was trying something someone suggested: "# RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?blood...." but it didn't seem to work so I commented it out.
Click to expand...

Not every browser/user sends a referrer. If you also accept a blank referrer is might work better.
 
Last edited:
Upvote 0 Downvote
zoldos said:
Okay, thanks! Someone suggested this "issue" mainly (if not only) affects XFMG? Can anyone confirm this?
Click to expand...
As posted above: the url for an image in XFMG is something like media/media-name.123/full, not the real path on your web server.

So, I don't think anyone can guess the path of any image inside your data folder!

Regarding your .htaccess approach:

Try this in your data/attachments folder (in this case not in your web root .htaccess file!):

Code: 
RewriteEngine On

# For empty referer or referer from your website:
RewriteCond %{HTTP_REFERER} ^$ [OR]
RewriteCond %{HTTP_REFERER} ^!^http(s)?://(www\.)?bloodofsouls.com
RewriteRule ^ - [L]

# for anybody else a "forbidden":
RewriteRule ^ - [F]
 
Last edited:
Upvote 0 Downvote
P.S. fixed code above. You can also paste this code in your web root .htaccess file (as a replacement of your old code):

Code: 
# For empty referer or referer from your website - only inside data/attachments folder:
RewriteCond %{REQUEST_URI} ^/data/attachments/
RewriteCond %{HTTP_REFERER} ^$ [OR]
RewriteCond %{HTTP_REFERER} ^!^http(s)?://(www\.)?bloodofsouls.com
RewriteRule ^ - [L]
# for anybody else a "forbidden":
RewriteCond %{REQUEST_URI} ^/data/attachments/
RewriteRule ^ - [F]

(all code untested)
 
Last edited:
Upvote 0 Downvote
Just so we're not getting confused, the data/attachments folder is meant to be public as it holds all the thumbnails.

The full size images are held in the internal_data/attachments folder.

This doesn't apply to videos though, which aren't protected (full image stored in the data folder)
 
Upvote 0 Downvote
Okay, thanks!!
benFF said:
Just so we're not getting confused, the data/attachments folder is meant to be public as it holds all the thumbnails.

The full size images are held in the internal_data/attachments folder.

This doesn't apply to videos though, which aren't protected (full image stored in the data folder)
Click to expand...
Yes, I spoke to an add-on dev extensively, and now I understand about the folders and thumbnails. He assured me that as long as attachments are full size, they cannot be directly accessed, and yes, the videos are vulnerable.

Thanks for everyone's replies!
 
Upvote 0 Downvote
You must log in or register to reply here.
Back
Top Bottom