A frequently misunderstood aspect of IIS is that disabling "Write" permissions from IIS Management UI actually prevents anyone from writing files to the server through IIS (such as upload files). This is clearly not the case, as the following question suggests... so is this a security hole in IIS6, or is there another explanation?
A customer have a IIS 6 web server and even with IIS Write property DISABLED, an ASPX form can upload files to the server.
The authentication is Anon (via IUSR_ user) and the IUSR_User have RWXD rights on the folder where the upload is stored.
In the properties of the IIS folder where upload is done, the Read permission is set, but Write, SourceAccerss and Browse are disabled.
Why the upload works???
Yeah, we see lots of incredulous/frantic posts like this one in microsoft.public.inetserver.iis.security because the user thinks that it must be a security bug in IIS. After all, I just disabled "Write" from IIS, so why can a remote user still write to my server?
The short answer to this question is that everything the user observed is correct and by-design. The user just failed to configure what he thinks he configured, and IIS can do nothing to save you from your own misunderstanding...
ASP.Net, IIS, and the NTFS FileSystem are all separate systems running on top of Windows. Since they can function independently from each other, they each have their own authentication, authorization, and access-control mechanisms, and they are all configured through different mechanisms in different configuration stores.
These mechanisms all have to be configured and interacting correctly in order for a logical concept, like "uploading a file", "browsing a directory", "running an ASPX page", etc to function. When they are not configured correctly, you see people asking questions about "why am I denied access", "why am I getting Forbidden", etc... but that's for another discussion another day.
Now, you may wonder why have all these different authentication/authorization/access-control mechanisms at all. After all, I just want to prevent users from writing files to my server or prevent them from reading a file - so just give me a simple "Allow/Deny" checkbox and do what I want! Isn't that what the IIS Manager UI means with the "Read" and "Write" check boxes?
Unfortunately, that is not the case. IIS, ASP.Net, and NTFS are all too configurable to give you this simplified view of life. The IIS Manager UI only configures settings at the IIS scope, so the the "Read", "Write", "Script source access", and "Directory browsing" check boxes only affect IIS-level behavior. What they translate into is:
As you can see, these access controls in IIS have nothing to do with allowing/denying uploads, so enabling "Read" while disabling "Write", "Script source access", and "Directory browsing" definitely do nothing as far as denying ASPX upload is concerned.
What do I think is actually happening in your situation?
<identity impersonate="true" />
<processModel userName="IUSR_UserName" password="IUSR_Password" />
Now, since ASPX is arbitrary code, it can do whatever it wants when it runs, including writing something to some directory. IIS configuration can only control whether this code is executed at all (i.e. does IIS allow a handler to execute the URL that represents this ASPX page).
So, how would you disable uploads in your situation? Try changing any of the above three parameters that I mentioned so that remote requests do not run with a user identity that can write to the directory in question, and uploads should stop happening.