Securing files from users

mpav

Joined: 2003-05-13
Posts: 1
Posted: Tue, 2003-05-13 22:17

I am not actively involved with using Gallery in anyway, but I have a friend who has been talking about this problem for a while and I would like to offer my solution and hear feedback. I am just generally interested in solving odd problems ;)

Problem: Securing files from users in a plain and simple way. Users can easily defeat many attempts at hiding files from users by using direct URL access to files.

Solution: 'Session Symlink Security' aka SSS [UNIX ONLY]

Basically, you have a file structure outside of the normally accessible web documents that you use to store your web content.

ie. /var/www <-- web docs and jsp, php, etc..
/var/files <-- secure file area for files NOT accessible via the web server. Needs to be writable by the user that the web server runs as. Setting the sticky bit would be a good idea.

When a user logs in and is properly authenticated, you have the web app create a symlink to the 'secure file area' that is made up of some random characters, such as the session ID. Upon logout, the symlink is removed.

ie. /var/www/files/SSID90290433GARBAGERANDOMDATA -> /var/files
http://site.com/files/SSID902...DATA/myfile.jpg

NOTE: Your web browser must enable the 'Follow symlinks' option for the /var/www/files directory for this to work.

You now have an area where an authenticated user can access files without having a permanent URL to access the files directly.

For more advanced options, such as ACL's, you can use symlinks for every file which a user has access, instead of just creating a symlink to an entire directory (given file and ACL info is available via db, etc). Another option would be to create a directory structure and create 'deep' symlinks for lower privileged users.

For sanity, it would make sense to have a cron job (script) go through and clean up any symlinks that were not properly removed for some reason.

Advantages:
1) Symlink creation and destruction is a very light operation on the file system.
2) This solution doesn't require using some hoaky internal proxy or other server.
3) The file access can be customized per user
4) This solution is language independant and can be extended to be used with other applications.

Disadvantages:
1) UNIX only (oh damn.)

The only way I have determined that the files could be compromised would be if someone already authenticated 'guessed' the session ID of someone who had access to 'more secure files' and the user with 'more secure access' was logged in at the same time.

I have blocked my email address from users to this forum via my user info b/c I do not want any more spam. I will try to work up a demo this weekend in php, but don't hold your breath. If you have any questions or comments, please feel free to e-mail me:

.

Matt Pavlovich

 
beckett
beckett's picture

Joined: 2002-08-16
Posts: 3474
Posted: Tue, 2003-05-13 23:17

This is the best solution for G1 I've heard to date!
(G2 will be truly secure BTW as the images are called through a PHP page which checks authentication).

 
beckett
beckett's picture

Joined: 2002-08-16
Posts: 3474
Posted: Tue, 2003-05-13 23:18

BTW... this forum is unfortunately prone to spambots... you might want to remove/muddle your email above. :roll:

-Beckett (

)

 
alindeman
alindeman's picture

Joined: 2002-10-06
Posts: 8194
Posted: Wed, 2003-05-14 01:23
Quote:
-Beckett (

)

Good advice, Beckett :) You just want that spam counter on your website to go up, eh? :wink:

 
beckett
beckett's picture

Joined: 2002-08-16
Posts: 3474
Posted: Wed, 2003-05-14 01:59

Heh... it's just a lost cause in my case. ;)

But my filtering is pretty good... my procmail misses about 1 in 30 spams... so I don't see most of them. And it's never marked a real email as spam...

 
hawkin
hawkin's picture

Joined: 2002-08-15
Posts: 45
Posted: Wed, 2003-05-14 02:30

good idea, but it will more or less disable the web browsers cache of the pictures.
With other words: give big galleries quite some heavy bandwidth usage!
(since the browser will always think the random session dir is a new directory with new image files in it that it has to download, even if it has downloaded the image befoure).

 
alindeman
alindeman's picture

Joined: 2002-10-06
Posts: 8194
Posted: Wed, 2003-05-14 02:34

Not necessarily. If you kept the random string in a session variable, it could last the whole session...

 
hawkin
hawkin's picture

Joined: 2002-08-15
Posts: 45
Posted: Wed, 2003-05-14 08:46

ofcorse.
But the client side chaching would not have much effect in one users session (one user would not browse at the same pictures through that session. One would assume the user would come back at a later stage and look at the same pictures, and then the user would have a new session variable.)

 
BorgKing
BorgKing's picture

Joined: 2002-09-12
Posts: 314
Posted: Wed, 2003-05-14 23:19

Actually, users do download a lot of the same photos in one session, especially the thumbnails, since I browse through those pages frequently in one session, looking at a photo and going back to thumbnail view.
I also prefer the setting in Internet Explorer that empties my temporary internet files when I close my browser, so I don't cache photos anyway.