Secure way to store files in web server?

问题:

I want my files to be secure in my web server. Only authenticated users to access those files should be able to access those files. I thought of storing files in database as "Long BLOB" but it supports only upto 2MB of data. The file size may exceed beyond 50MB. is there any other better way to secure the files? please help me.thanks in advance.

回答1:

Don't store them in a database. Put them in your web directory and secure them using .htaccess.

If you want to authenticate via other means, then store the files in a directory that isn't web-accessible but is readable by the user php runs as.

回答2:

A few options come to mind.

If you are using Apache you can use htaccess to password protect directories. (first googled link : http://www.javascriptkit.com/howto/htaccess3.shtml)

or Store the files above the web server. Create a script in php that will allow authorised users to access them.

If you want to do it Via FTP, and you are running cpanel you may be able to create new ftp accounts. check yourdomain.com/cpanel to determine if you have it installed.

回答3:

Storing files in DB is very bad practice. Very good practice to store only information about file. Name, extension. Files save on server like $id.$ext. It will be a good architecture. And when user download file, he take file with name in DB.
Sorry for my english.

回答4:

Discussion

If you opt to keep high value downloadable content files directly on the filesystem, the best thing to do is to keep them outside of the webroot. Then, your application will have to solve the problem of creating URLs (url encoding when necessary) for content (PDF's, Word Docs, Songs, etc..).

Generally, this can be achieved by using a query to retrieve the file path, then using the file path to send content to the user (with header() etc ..) when he or she clicks on an anchor (all of this without the user ever seeing the true, server side file path).

If you do not want user A sharing URLs for high value downloadable content to user B, then your application must somehow make the links exclusively tied to user A. What can be done? Where should I start?

Obviously, you want to make sure user A is logged in during a session before he or she can download a file. What is not so obvious is how to prevent a logged in user B from using a URL sent from user A (to user B) to download A's digital content.

Using $_SESSION to store the logged in user's ID (numerical, or string) and making that part of the eventual query (assuming content is tied to user purchases or something) will prevent a logged in user B from downloading things they have not purchased, but you will still incur the resource hit for processing the SQL empty set for items they have not purchased. This sounds like a good step two.

What about step one? Is there something that can prevent the need to do a query to begin with?

Well, let us see. In HTML forms, one might use a XSRF token in a hidden field to verify that a submitted form actually originated from the web server that receives the POST/GET request. One token is used for the entire form.

Given a page of user specific things to download (anchors), one could embed a single token (the same token, but different per page request) into each anchor's href attribute in the form of a query string parameter and store a copy of this token in $_SESSION.

Now, when a logged in user B attempts to use a logged in user A's shared URL, the whole thing fails because user A and user B have different sessions (or, no session at all), and thus different tokens. In other words, "My link is the same as yours, but different." Anchors would be tied to the session, not just to the page, user, or content.

With that system in place, PHP can determine if a request for content is valid without getting the database involved (by comparing the submitted token to the one in $_SESSION). What is more, a time limit can be established in $_SESSION to limit the duration/lifetime of a valid XSRF token. Just use the time() function and basic math. Sixty minutes might be an ideal token lifetime for an anchor in this situation. Have the user login again if the token for a clicked anchor has expired.

Summary

If you use files on a filesystem and store the paths in the database, make sure you do the following (at minimum), too.

1. Apply proper file permissions to your content directory (outside of webroot).
2. Use random names for uploaded files.
3. Check for duplicate file names before saving a file from an upload.
4. Only logged in users should be able to download high value content.
5. Have an effective $_SESSION system that deters session fixation.
6. Make URLs for high value downloadable content are unique per page by using hashed XSRF tokens.
7. XSRF tokens cover more scenarios when they have a terminal life time.
8. Make SQL queries for user content based on the logged in user's ID, not the product exclusively.
9. Filter and validate all user input.
10. Use prepared statements with SQL queries.

回答5:

Downloadable files can be stored in htaccess protected folder/s. A script like the one below can be used to generate dynamic links for downloadable files.

for ex. Secure download links. http://codecanyon.net/item/secure-download-links/309295

回答6:

The best way is to store the file reference in Database. The file itself will be stored in the server filesystem. The complexity of this is making sure there is reference integrity between the database file reference and the existing file in the server filesystem. Some database such as sql server 2008 have feature that maintain the integrity of the file references to the actual file itself.

Other than that securing the file itself in the server depends on the OS where permissions can be configured to the specific folder where the file reside.

回答7:

If the files are purely static you could use read-only or WORM media to store the data files or indeed run the complete web server from a "LiveCD". It's certainly not suited to everyone's needs but for limited cases where the integrity of the data is paramount it works.