The first step to creating a secure online data repository is to have the
actual documents stored in a location that cannot be accessed by the public.
Here are three very different approaches:

1. Store the file in a blob field of a database. The disadvantage of this is
   that the server is put under slightly more strain than if copying a file
   directory from the file system. The advantage is that the security is probably
   the best out of the three options here.
2. Store the file in the server's file system using a large number coded
   physical filename. Like the blob field database storage this physical file is
   never directly exposed to the client and only the server application knows
   where the file is. The process of giving the client access to this file is
   covered below.
3. Rather than attempting to hide the direct file URL specified by the
   server's operating system, allow the references to be known to the client but
   create access permissions at the operating system level or hosting software
   level. It might appear that this is the simplest approach and for this reason
   it is commonly used, but I would like to raise two problems. Firstly this
   approach is not portable and that reduces security; if you are moving your
   application to another operating system human errors can easy occur relating
   to how the file permissions are configured. Secondly the username and password
   login might be difficult to integrate tightly with your web application's
   native username and password system. A good web application should have a
   single login for the entire session and you do not want to see new dialogue
   boxes appearing when trying to access certain files.

We will concentrate on how the private files are passed to the right users by
following the first and second approaches above.



If the file is stored in the database then files that are not tens of megabytes
can be retrieved to the memory of your server application code and the file
itself can be returned as the HTTP response. The user would then see the upload
options appear in much the same way that you would see if you typed direct file
reference into your browser's address bar. Your HTTP response will usually begin
with the line "Content-type: text/html" and this can be changed to the
appropriate message for the type of file being downloaded by the user, followed
by the file contents. That is the end of the story for the first approach.



For the second approach, in which the file is stored as a coded filename in the
file system, you will still need a database table that holds information about
all stored files. In particular you will need to know (1) the original physical
filename and (2) the coded physical filename on the server. The hyperlink to
download the file will not be a direct file reference but instead a reference to
your web application with the instructions to perform the following:

1. Check from your database whether the logged in user has access to the file
   in question.
2. Make a copy of the coded file to a temporary location on the server.
   Create a directory with a randomly coded name and place the file copy in this
   directory.
3. Rename the file to the original non-coded filename.

Return an HTML page as the response which includes a hyperlink to the
temporary file.

The directory creation in step 2 prevents someone from continually attempting to
download a URL using a known filename until someone permitted to download it
'opens the door'. The strength of this approach is that it is both secure and
fast and can be used with very large files. The weakness is that you will need
to add a strategy for deleting the temporary directories and files and ensure
that they are not deleted while the user is still downloading. A reasonable
approach is to simply run a delete routine every few hours.

 

By Julian Cochran

support@digitalscores.com

DigitalScores

DigitalScores is a software
development group based in Australia. Our focus is on delivering solutions that
withstand future technological change; minimizing the long-term cost of every
project we are involved with.

Bookmark/Search this post with:

| | | | | | | | | | |