prevent IIS from executing scripts in a specific directory

Question

I have a php web application that allows file uploads to a specific directory.

I would like to prevent the execution of any file that is uploaded into that directory whether it is ASP, PHP, or anything else that may be supported by IIS. I'm already blocking the upload of asp and php files at the application layer, but as a measure of defense in depth against a possible error in that validation code I would like to add a configuration to IIS to prevent execution of these files.

Is there a way to do that in IIS?

Answer 1

First of all -- this really depends on your server configuration -- if such modifications are allowed to be performed on directory level (section is not locked on parent/server level).

In order to disable execution of specific file extension yo need to know the handler name that is responsible for this. On each system this name can be different, especially for PHP, since it is not standard handler (created by user with admin rights). For example (web.config that needs to be placed in such folder):

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <remove name="PHP 5" />
        </handlers>
    </system.webServer>
</configuration>

The above will remove handler named "PHP 5" that is responsible for handling *.php files on my PC. With *.asp handler this should be easier since it has standard name, but it can easily be changed if required.

Another approach -- remove ALL handlers altogether. In this case you do not need to know handler names. This has one serious drawback -- you will not be able to serve anything from this folder and subfolders, even static files.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <clear />
        </handlers>
    </system.webServer>
</configuration>

To bypass this drawback you can create URL rewriting rule and forward all requests to such files to your special script that will actually serve those files (script will have access to those files, so no problems here). The downside -- it can be quite complex (depends on number of file types it will be handling) + will produce a bit of unnecessary processing overhead (how big -- depends on your script, how you will code it).

3rd approach seems to be more optimal (really depends on your other requirements) -- we will remove ALL handlers and will add the one that serves static files back .. so images/html/css/js etc should still work if requested from such folder:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <clear />
            <add name="StaticFile" path="*" verb="*" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" resourceType="Either" requireAccess="Read" />
        </handlers>
    </system.webServer>
</configuration>

If you still require some other standard handlers to be available in this folder .. then you will have to add them back in a similar manner.

Answer 2

One good and easy way to prevent execution of certain file extensions under an specific folder is to use the "Request filtering" feature of IIS to prevent accessing them altogether.

Go to the folder in IIS and in the "File Name Extensions" tab of the "Request filtering" feature, add "Deny file extension" rules for the file extensions that you want to lock.

That will generate this sections in the web.config file for that folder:

<system.webServer>
    <security>
        <requestFiltering>
            <fileExtensions>
                <add fileExtension=".aspx" allowed="false" />
                <add fileExtension=".php" allowed="false" />
                <add fileExtension=".asp" allowed="false" />
            </fileExtensions>
        </requestFiltering>
    </security>
</system.webServer>

In this example we block the access to .php, .asp and .aspx files. So if someone tries to access any file with this extensions in your folder they will get a 404 status code (as if the file doesn't exist).

That would be a good way to prevent execution in a fast and simple way.

Answer 3

Assuming that you want the uploaded files to be served as static content (or else you could just save the uploads outside the root folder of your application):

Inside your root web.config (which can't be overwritten by users), use this (as suggested by Javier G., but with allowOverride=false):

  <location path="upload" allowOverride="false">
    <system.webServer>
      <handlers accessPolicy="Read" />
    </system.webServer>
  </location>

Or this (as suggesteed by LazyOne, but with allowOverride=false):

  <location path="upload" allowOverride="false">
    <system.webServer>
      <handlers accessPolicy="Read">
        <clear />
        <add name="StaticFile" path="*" verb="*" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" resourceType="Either" requireAccess="Read" />
      </handlers>
    </system.webServer>
  </location>

If you don't use allowOverride=false, anyone can upload a web.config in your open folder, and override your handlers configuration, so that they will be able to run scripts again. See this link for exploit example.

Answer 4

Just to add to the posted solution for others who might be running into the same issue: None of those worked for me until I figured out that the handlers were locked at the top level. I'm not a server admin or even close to it, so that took me a little while. Until the applicationHost.config file was edited to allow overrides, including even an empty <handler> section in a lower level web.config file was enough to break everything from that level down. Works great now, though.

Answer 5

Add this Web.config to your uploads directory (or even better, to the parent Web.config inside a location path="whatever" tag)

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <handlers accessPolicy="Read"/>
  </system.webServer>
</configuration>

This tells IIS that handlers (such as PHP) may only read, and not execute, therefore showing a 404 for executable scripts.