how to secure documents in server

[RAZZ]

Hello, Can anyone suggest me solution?

I Need to manage different types of documents (doc,xls,ppt etc) in
server. I have folder structure to maintain these documents in server.

Say folder1 is having all doc files; folder2 is having all xls files
and so on.


Now these documents should not be able to get access through the url
by directly typing path.
E-g if I try to access directly www.mywebsite.com/folder1/xyz.doc it
will open the document in browser itself.
At the same time these documents should be access only through our
website once they are login. But without login also if you know the
path you can get these documents how should I avoid it?

How can I provide security to these documents in server?

 

[GArlington]

Hello, Can anyone suggest me solution?

I Need to manage different types of documents (doc,xls,ppt etc) in
server. I have folder structure to maintain these documents in server.

Say folder1 is having all doc files; folder2 is having all xls files
and so on.

Now these documents should not be able to get access through the url
by directly typing path.
E-g if I try to access directlywww.mywebsite.com/folder1/xyz.docit
will open the document in browser itself.
At the same time these documents should be access only through our
website once they are login. But without login also if you know the
path you can get these documents how should I avoid it?

How can I provide security to these documents in server?

Depending on webserver your should look at .htacceess for Apache or
httpd.ini for IIS...

 

[RAJ]

Depending on webserver your should look at .htacceess for Apache or
httpd.ini for IIS...

well we are using yahoo server and it doesn't allow .htaccess to
upload or manipulate by developers
so is there any other way? i just want that doc or xls files should
not be able to open directly unless person has properly login.

 

[Captain Paralytic]

well we are using yahoo server and it doesn't allow .htaccess to
upload or manipulate by developers
so is there any other way? i just want that doc or xls files should
not be able to open directly unless person has properly login.- Hide quoted text -

- Show quoted text -

You're not going to be able to do much on yahoo server I'm afraid. The
most common way to do this is to store the files outside of the web
root and use a php script to deliver the file.

I suggest you change hosts. There are much better value ones out there.

 

[RAZZ]

You're not going to be able to do much on yahoo server I'm afraid. The
most common way to do this is to store the files outside of the web
root and use a php script to deliver the file.

I suggest you change hosts. There are much better value ones out there.

thank you for response can you suggest me bit in details regarding
"storing files outside of the web root and use a php script to deliver
the file"?

 

[Captain Paralytic]

thank you for response can you suggest me bit in details regarding
"storing files outside of the web root and use a php script to deliver
the file"?

Actually another way to do it is to store the files in a BLOB field in
a database and delivering them from there. Here is a tutorial for that
and you could adapt it for the file system version:
http://www.php-mysql-tutorial.com/php-mysql-upload.php

 

[RAZZ]

Actually another way to do it is to store the files in a BLOB field in
a database and delivering them from there. Here is a tutorial for that
and you could adapt it for the file system version:http://www.php-mysql-tutorial.com/php-mysql-upload.php

That was really very good option but i have documents or doc files
which contains images and tables while downloading text are fine but
images and tables are coming in some encrypted format?

 

[Captain Paralytic]

That was really very good option but i have documents or doc files
which contains images and tables while downloading  text are fine but
images and tables are coming in some encrypted format?

I don't understand??? What difference does it make what the document
contains? A binary file is a binary file is a binary file! It can
contain anything whatsoever???

 

[The Natural Philosopher]

Hello, Can anyone suggest me solution?

I Need to manage different types of documents (doc,xls,ppt etc) in
server. I have folder structure to maintain these documents in server.

Say folder1 is having all doc files; folder2 is having all xls files
and so on.


Now these documents should not be able to get access through the url
by directly typing path.
E-g if I try to access directly www.mywebsite.com/folder1/xyz.doc it
will open the document in browser itself.
At the same time these documents should be access only through our
website once they are login. But without login also if you know the
path you can get these documents how should I avoid it?

How can I provide security to these documents in server?

Pur ALL thes documents as large BLOB objects in a database: thats one
easy place to store them and one access methodd needed to restrict
access to what you want.

 

[The Natural Philosopher]

That was really very good option but i have documents or doc files
which contains images and tables while downloading text are fine but
images and tables are coming in some encrypted format?

As ling as they are encapuslated IN the file, that doesn't matter. a
data base will store any file.

 

[Bart Van der Donck]

Actually another way to do it is to store the files in a BLOB field in
a database and delivering them from there. Here is a tutorial for that
and you could adapt it for the file system version:
http://www.php-mysql-tutorial.com/php-mysql-upload.php

I'm surprised this document doesn't mention how disastrous it can be
for the performance of a database. Only use for tiny binary data and a
limited amount of records, I'ld say... I would even vote to dismiss
LONGBLOB; it often creates more problems than it solves.

 

[Pugi!]

I do not know the details of your provider or host but if you can
store your documents outside of your documentroot, no one can access
your files directly. You can use php to store them and retrieve them.
I store the filename and mimetype in database (and some other
information), files are stored in a directory outside documentroot
where apache has read/write access (because users are allowed to
upload documents) (in my case the documents are even stored on another
server with NFS share). Once you obtained the filename and mimetype
from database and path from config file:

header("Cache-Control: max-age=60");
header('Content-type: ' . $filemime);
header("Content-Disposition: attachment; filename=\"" . $filename .
"\"");
readfile($filepath . $filename);

It not only downloads the file but also asks if you want to open it
with the associated program (MS Word or OO Writer for *.doc, ...)

Pugi!

 

[J.O. Aho]

Hello, Can anyone suggest me solution?

There been those who already mentioned to store the files outside the web
servers "document root", this is the most secure method (of course depending
on the security of the script/application that supplies the file, in worst
case this can endanger the security of the whole server).

..htaccess and similar web server restrictions has the draw back that not
everyone offers this and it can be easy to do it the wrong way when
unexperienced with web server configuration.

The idea of storing binary files in a database is quite good, but it will
affect the sql server in a negative way, specially the larger the binary files
are.

A fourth method is to encrypt the files and store them in the "document root",
and the special download script decodes the file when downloaded by someone
with access to get the decrypted file. (this can be combined with all the
other methods too), this way someone accessing the file directly can't use it.

A lot simpler way is to rename the files to something quite random (md5 hash
the name, don't forget to salt it), store the hashed filename in a database
table where you have the original filename too. The download script in this
case will take an argument of the original filename, look in the database for
the hashed name, provides the file to the user (with header you send it as the
original name), this way you can't get the file with direct download unless
you know the hashed file name. If you combine this one with the previous
method, you should have a quite good false security on the files.

 

[The Natural Philosopher]

The idea of storing binary files in a database is quite good, but it
will affect the sql server in a negative way, specially the larger the
binary files are.

Ok, why should it take longer to pull a large file out of one locatin in
a database than one location in a filesssytem?

IME the things that slow databases down are not getting data out of
them, its performing complex relational queries.

 

[Paul Lautman]

I'm surprised this document doesn't mention how disastrous it can be
for the performance of a database.

It doesn't because it isn't

Only use for tiny binary data and a
limited amount of records, I'ld say... I would even vote to dismiss
LONGBLOB; it often creates more problems than it solves.

I usually chunk the files into BLOBs

 

[Michael Fesser]

..oO(The Natural Philosopher)

Ok, why should it take longer to pull a large file out of one locatin in
a database than one location in a filesssytem?

Just think about what steps are required in order to get a file 1) from
a DBMS, 2) from a location outside the doc root, 3) directly with a URL:

1. Storage file -> DBMS -> Socket -> Script -> Webserver -> Browser
2. File -> Script -> Webserver -> Browser
3. File -> Webserver -> Browser

IME the things that slow databases down are not getting data out of
them, its performing complex relational queries.

The DB also has to access the disk. Additional overhead is caused by the
SQL processing itself and the transfer of the data to the requesting
script.

Micha

 

[Paul Lautman]

Ok, why should it take longer to pull a large file out of one locatin
in a database than one location in a filesssytem?

IME the things that slow databases down are not getting data out of
them, its performing complex relational queries.

I have tested this and I have found it slightly slower to get files from a
database table than from the file system. Then again, it is slightly slower
building pages dynamically with php/MySQL than it is to serve fixed html
pages. So basically, when I find that storing files in a database is the
best way to handle the application I am writing, that's the way I do it.

 

[Jerry Stuckle]

I'm surprised this document doesn't mention how disastrous it can be
for the performance of a database. Only use for tiny binary data and a
limited amount of records, I'ld say... I would even vote to dismiss
LONGBLOB; it often creates more problems than it solves.

You're just using the database for what it's made for - storing and
accessing data. It's not at all disastrous - in fact, if you get enough
files in the database, performance may actually improve over that file
system's.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================

 

[Jerry Stuckle]

There been those who already mentioned to store the files outside the
web servers "document root", this is the most secure method (of course
depending on the security of the script/application that supplies the
file, in worst case this can endanger the security of the whole server).

.htaccess and similar web server restrictions has the draw back that not
everyone offers this and it can be easy to do it the wrong way when
unexperienced with web server configuration.

The idea of storing binary files in a database is quite good, but it
will affect the sql server in a negative way, specially the larger the
binary files are.

A common misconception by those who haven't used databases for storing
large amounts of data. Properly configured, the database will have
excellent performance.

A fourth method is to encrypt the files and store them in the "document
root", and the special download script decodes the file when downloaded
by someone with access to get the decrypted file. (this can be combined
with all the other methods too), this way someone accessing the file
directly can't use it.

A lot simpler way is to rename the files to something quite random (md5
hash the name, don't forget to salt it), store the hashed filename in a
database table where you have the original filename too. The download
script in this case will take an argument of the original filename, look
in the database for the hashed name, provides the file to the user (with
header you send it as the original name), this way you can't get the
file with direct download unless you know the hashed file name. If you
combine this one with the previous method, you should have a quite good
false security on the files.

Even worse performance than storing the data in the database in the
first place. More overhead for the scripting language, while no
significant savings on the database end.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================

 

[Jerry Stuckle]

I have tested this and I have found it slightly slower to get files from a
database table than from the file system. Then again, it is slightly slower
building pages dynamically with php/MySQL than it is to serve fixed html
pages. So basically, when I find that storing files in a database is the
best way to handle the application I am writing, that's the way I do it.

Paul,

But try putting 100K files in a directory on the file system and see how
much it slows things down. Whereas the database will hardly notice any
performance decrease.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================