ASP/ASP.NET Best way to handle write permissions?

Question

Say you have a public ASP.NET (or Classic ASP) application on IIS with a script/page that needs to write or update files in a specific folder that is located within the web publishing folder tree.

1) What is the proper way to set this up?

My main concern is that I want to let the ASP/ASP.NET apps write to a folder, but I don't want regular http users to be able to PUT files into it.

score 5 · Accepted Answer · answered Jun 03 '09 at 06:38

First let me start by saying, I'm a pretty big believer that there is almost always a better solution than writing stuff out to disk. Whether it's writting the data to a database, or feeding web services, writing out to disk should be the last option.
That being said there are some valid reasons, but this is sort of tricky and dependent on why the app needs to write out the files.

Having the data written outside of where code is running from is an absolute requirement. Allowing end users to write to a path where the ASPX/asp engines can interpret/execute code is bad for obvious reasons.

Some other things that impact this are:

Whether you're running the worker process under a domain account or the standard network service. It's important to realize that when you grant the IIS_WPG group write access to a folder, any ASP.NET application running under the default account on the server may write files to that folder. This is a less than ideal configuration on servers where muliple applications run especially when the applications are untrusted and/or running in an ISP/shared hosting environment.
Whether the generated files need to be web available or not. If your application is just writting out some non-web viewable files, simply creating the directory, granting the rights, and configuring the application to read/write to the correct place is all you need. If the application needs to write out web viewable files, (this comes up fairly commonly in content management scenarios) you need to create a virtual directory (without execute code/scripts rights) that maps to your writable directory.
Whether or not you're working in a load balanced / web farm environment. If your application is operating in a farmed environment and needs to write files to disk for some reason, you're presented with a whole new problem. How do you keep user generated files on webserver1 in sync with the files generated on webserver2? Doing it via some convoluted syncronization script is painful at best and riddled with race/syncro issues. The best way of implementing this is to create a share on a third server (idealy a cluster with some redundancy) and store the data there. If you're running your worker processes under domain accounts (Security Best Practice), you can even map to the share in the application without having a user/pass anywhere in the code or web.config (makes audit/security people happy). IIS also has the ability to map virtual directories to UNC paths, so this won't impact your ability to make this content web viewable.

Thanks for your thoughts. All very important points. In our case, the html files written are really a legacy cache system cos they used to take too long to generate dynamically. My concern really was that I wanted the Web App to write the files, but was afraid setting the directory to be writable by IIS meant that users might also be allowed to write there (via HTTP PUT's). — Matias Nino, Jun 04 '09 at 04:09
In that case just creating the directory (outside the web app dir), setting permissions, configuring the app to write there, and mapping a quick virtual directory is all you need. You need not worry about HTTP PUT's from users, access to the PUT verb in IIS is controlled via the Write checkbox in the IIS Manager UI (Home) Directory Tab. — Dominic D, Jun 04 '09 at 04:32

score 2 · Answer 2 · answered Mar 02 '11 at 21:08

The App_Data Folder

To improve the security of the data used by your ASP.NET application, a new subfolder named App_Data has been added for ASP.NET applications. Files stored in the App_Data folder are not returned in response to direct HTTP requests, which makes the App_Data folder the recommended location for data stored with your application, including .mdf (SQL Server Express Edition), .mdb (Microsoft Access), or XML files. Note that when using the App_Data folder to store your application data, the identity of your application has read and write permissions to the App_Data folder.

What's new in ASP.NET Data Access

score 1 · Answer 3 · answered May 29 '09 at 15:01

Probably betting to look over on stackoverflow.com...

Best practice is to put that folder OUTSIDE of your document root and have your app read from the file system. Otherwise, make the folder read-only except to the ASP[.NET] user and control the write priviliges with your app's internal authorizations.

score 1 · Answer 4 · edited Dec 10 '11 at 09:22

1

App_Data is, by default, writable but not readable. The server seems to resist any attempt to change this. Thus, it is better to make a completely new folder and change the permissions on it to NOT EXECUTABLE and READABLE and WRITABLE.

edited Dec 10 '11 at 09:22

Chopper3

100,240
9
106
238

answered Dec 04 '11 at 19:57

harborsparrow

11
1

It's a good answer, but please try to include the full answer here instead of linking to your own blog. – pauska Dec 05 '11 at 10:16
Removed link as user chose not to. – Chopper3 Dec 10 '11 at 09:22

ASP/ASP.NET Best way to handle write permissions?

4 Answers4