views:

174

answers:

4

Ok, I am using a GoDaddy web hosting plan on a Windows platform. This was not my choice -- it has to do with a different part of the actual site using ASP.NET (also not my choice). I have a SQL database with a bunch of entries with some non-sensitive customer information. The primary key on this is an AutoIncrement integer, and I have a series of PDF files that match up with each of those integers (ie 555.pdf, 7891.pdf, etc).

My goal is to restrict direct access to these files, I want users to have to go through a search and login process (PHP) first. Originally I planned to put the files above the PUBLIC_HTML folder, but GoDaddy refuses to give me root access without a dedicated server ($20 a month from them). The next thing I looked into was HTACCESS. I was going to restrict access to the files to only PHP scripts by only allowing access to the Server's IP Address (or localhost/127.0.0.1). Unfortunately this doesn't work because GoDaddy does not run Apache on its Windows servers.

I could put the files into BLOBs in the database, but that gets really messy when I need to work with them quickly (plus I have had some trouble with that approach).

Any suggestions to restrict access to the files only to a PHP script (readfile())?

A: 

You can simply hide them. It's security-through-obscurity, but it sounds like your best option if you can't either keep them out of the web-root, or find a way to tell the server not to serve them directly.

So stick them in some randomly-named directory:

asd8b8asd8327bh/123.pdf
asd8b8asd8327bh/124.pdf
asd8b8asd8327bh/125.pdf
...

Then write yourself a little PHP script that will send appropriate headers, and pass the file contents through.

for example:

<?PHP
//pdf.php
$id = $_GET['id'];

//make sure nobody is doing anything sneaky. is_numeric() might do the trick if the IDs are always integers.
if (!some_validation_passes($id)){
  die();
}
<?php

header('Content-type: application/pdf');
header('Content-Disposition: attachment; filename="'.$id.'.pdf"');
readfile('asd8b8asd8327bh'.$id.'pdf');

Now, the above is really no better than just serving the files directly (yet), since people can still increment the id parameter in the query string.

But you ought to be able to figure out how to handle authorization pretty easily.

timdev
This is security through obscurity. In other words, not secure.
Borealid
@Borealid You say that as if I didn't explicitly qualify my answer in the first line. Not to get into a debate about security through obscurity but "This is software. In other words, not secure". Or "This is a password system, and therefore insecure". In fact, now that I think about it, my solution is about as secure as a strong password, assuming no unrelated hole lets an attacker list directories.
timdev
A: 

Make a folder web inaccessable via chmod. PHP will still be able to include/require whatever is on the server, but users will not be able to navigate to the files ever.

Example: This is set to 770, IE User and Group can Read/Write/Execute, Other can do nothing. http://robertsquared.com//tryToAccessMe/butyoucant.php

Robert
This answer is wrong. Barring a SuExec/CGI configuration, PHP uses the web server's permissions. If the file is inaccessible to the web server, it is also inaccessible to PHP.
Borealid
I have a folder set to 770 and I am able to include, but am unable to directly navigate in my browser.
Robert
Also I think you misunderstood, the web server still has permissions, user and group have permissions in 770, others do not. So this gives PHP full access to files, web browser will get nothing.
Robert
@Robert - I don't understand how I could chmod into the system if it is not a linux system!?
altexpape
If you're not on a linux system look up equivalent security settings for the Windows environment.
Robert
+1  A: 

Because PHP uses the web server user's permissions, there is no way to restrict access to the files without either:

  • Placing them outside the DOCROOT
  • Changing the web server configuration to disallow access to those files
  • Changing the file so it will be interpreted by the web server, thus hiding its contents

Putting them in a database counts as outside the DOCROOT. For the third option, you could make the PDFs PHP files, but honestly, that would be pretty convoluted.

I recommend you contact GoDaddy and see if they have some way to configure per-directory file permissions.

Borealid
Clever. Assuming OP can't do anything to the server, I like your third option, coupled with the basic code I outlined.
timdev
+1  A: 

Since you can't put the files anywhere but in your public_html directory, you'll have to go for the feared/hated "security by obscurity" method

  1. Create a randomly named sub-directory to store the files in: public_html/RANDOMGARBAGE

  2. Make sure the directory is not browseable. Disable directory browsing (if you can), and put a default document (index.html?) in there as well, so even if browsing is on, you won't get the directory listing.

  3. Don't store your files with guessable names. Instead of storing them with the database ID, store them with a salted+hashed name instead: $crypted_filename = sha1($real_filename . 'some hard-to-guess salt text'); (of course, make this more complex if you need to). Store the original filename in your database. So you end up with something like:

    public_html/RANDOMGARBAGE/5bf1fd927dfb8679496a2e6cf00cbe50c1c87145 public_html/RANDOMGARBAGE/7ec1f0eb9119d48eb6a3176ca47380c6496304c8

  4. Serve up the files via a PHP script - never link to the hashed filename directly

    Download

which then does:

<?php

    $fileID = (int)$_GET['fileID'];

    $crypted_file = sha1($fileID . 'some hard-to-guess salt text');

    $full_path = 'public_html/RANDOMGARBAGE/' . $crypted_file;
    if (is_readable($full_path)) {
         if(user_is_allowed_to_see_this_file()) {
             /// send file to user with readfile()
             header("Content-disposition: attachment; filename=$ORIGINAL_FILENAME");
             readfile($full_path);
         } else {
             die("Permission denied");
         }
    } else {
        /// handle problems here
        die("Uh-oh. Can't find/read file");
    }

This way the user will never see what your "s00per seekrit" filename is, they'll just see their browser hit ...php?fileID=37 and start a download of secret file.pdf

On top of this, you can occasionally rename the special sub-directory to something else on a regular basis, as well as change the salt text (which then requires you update all the hashed filenames with the new sha1 values).

Marc B