The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Securing static files within a web application

I'm a bit stuck on this one.  Any thoughts would be appreciated. 

I'm in the process of developing small scale web application for document collaboration and sharing.  The site consists of standard user level security with a few roles.  Without getting into the details, what I'm trying to do is protect documents that are uploaded into the system (mostly office docs; .doc, .xls, etc.).  By protect I'm referring to authenticating that the currently logged in user has access to view such a document.  As with many web applications I'm authenticating and tracking a user on each page of the application via a cookie.  This is fine for pages within the system but for static files I'm not sure how to authenticate. 

Each document that is uploaded has a corresponding record in a Files table.  I thin build the URL to the static documents like this{GUID}/{FILENAME} where GUID is a key in my Files  table and FILENAME is the corresponding file (ie. "SomeDocument.doc") in the same record.  For a page that contains a link to a document, I authenticate the user on that page but the direct link to the document itself (ie. could be copied and pasted into a browser and the file will load regardless of whether the user has access or not. 

I'm basically using security by obscurity, as in most users won't be able to guess/determine the GUID/Filename combination.  But it's not totally secure. 

Any other solutions?
Friday, March 17, 2006
You could try building an HttpModule or ISAPI filter that intercepts each request (regardless of if the endpoint is a web page or document) and check security there.
Friday, March 17, 2006
One way would be to have the files spit out by your application, and not by the web server directly.

So put them in a directory that's outside of the document root. Then have a page of your application which accepts the filename as a parameter (make sure you filter for ..). Figure out what file type it is, and send the appropriate headers. Then print out the contents of the file.
Friday, March 17, 2006
+1 to JW's solution.

That's the way that most sites do it.
Almost H. Anonymous Send private email
Friday, March 17, 2006
A slight improvement to JW's solution would be to take the GUID rather than the path as a parameter.
R. C. James Harlow Send private email
Friday, March 17, 2006
If you are using 2.0, there is an "App_Data" folder in the web folder tree you can use. It forbids direct web access but allows your web app to get to it. In effect, same as JW's solution.
Stacy Murray Send private email
Sunday, March 19, 2006
From a security standpoint it is better to take a GUID from the user as input and cross reference the file name from a DB than to take the filename directly from the user. You can imagine a hostile user using canonicalization flaws to try and get at files outside of your data folder. Even watching out for ".." isn't really enough. But if they just send a GUID which you use as a lookup for the actual file name from a database then they have no access to the file path itself. A much more secure solution.
Turtle Rustler
Monday, March 20, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz