1

I have an ASP.NET website serving up private PDF documents. The PDFs are stored unencrypted on a share on the internal network. The user logs in and navigates to the download page. The web server validates that the user has access to the file, loads it from the share and transmits it in the response.

Is this the "right" way, a secure way to deliver these documents? For instance, if the PDFs were stored in a directory on the website itself, that would be a bit time security risk. As I mentioned, they're not in the website directory. But what else should I be aware of with this setup to keep these documents secure?

John
  • 45
  • 4
  • Not sure how you manage "logins". But in any case, it would be still better to support password protected PDFs. – Novice User May 10 '13 at 17:22

1 Answers1

1

You need to be aware of (at least) the following:

  • If your documents are in a publicly-accessible folder, they're not private. This includes simple protections such as checking the referer, which are trivial to juke
  • If your documents are in a folder above the HTTP root, it is one step better; if they're encrypted and only one script can read them, even better.
  • If you have an include vuln on your site, expect people to be able to read them
  • Expect people to read them and plan accordingly - build audit so you know who has read stuff and, more importantly, when.

There are plenty of good ways to do so. A Stack question (https://stackoverflow.com/a/4993279/2167834) has a few good methods - 3 and 4 are particularly nice, especially if you have the possibility to store your files on S3 (and take advantage of the AWS token credentials).

Community
  • 1
Sébastien Renauld
  • 685
  • 3
  • 8
  • The documents are on a share on the internal network. They're not even on the web server. It's complied ASP.NET. I don't think you can execute arbitrary code server-side, am I wrong? – John May 10 '13 at 15:46
  • @John: by include vuln, I did not necessarily mean arbitrary exec. Suppose you have an ASP .NET piece of code that reads files without sanitizing the input filename - feed it ../ and watch the script go up one directory. This is common - far too common. – Sébastien Renauld May 10 '13 at 15:57
  • Gotcha. In this case, I'm reading file paths that I set in the database and they don't change. How would I go about sanitizing file names? – John May 10 '13 at 16:20
  • You don't sanitize - you concatenate as normal and then you check if the real path (there must be a function similar to PHP's `realpath`) is within the directory that you expect it to be. If you have a path that returns C:\ when you expect it to be in C:\myfolder\mydocs, you know something is wrong. – Sébastien Renauld May 10 '13 at 16:23
  • Gotcha. I did something similar to that once, only pulling files from the directory the script was supposed to as a double check. – John May 10 '13 at 16:37
  • @John: Side note, by the way, it is not because a program is compiled that it is automatically safe. Buffer overflows are the obvious counter-argument. – Sébastien Renauld May 10 '13 at 16:43