One of the best features of IIS7 is Request Filtering (RF). RF actually came about due to the old UrlScan security tool which helped lock down previous versions of IIS.

RF can help restrict things such as:

* Double Encoded Requests
* High Bit Characters
* File Extensions
* Request Limits
* etc

As we've been doing a lot of work with IIS7 lately we've been putting Request Filtering into play. A client we picked up last year were wanting some "things" done, and one of these was a move from their current hosting company to the Rackspace Cloud and in the process we moved them from Windows 2003 Server and SQL Server 2005 to Windows 2008 Server and SQL Server 2008.

Everything appeared to be looking good. We had run through most of our tests but discovered an issue with file uploads that happen to go through a Flash interface.

My first thoughts were a permissions issue. We really tie down security on Windows boxes and we'd already come across a prior case whereby we didn't give the IIS Service account write permissions to the ColdFusion temporary file upload location.

===SIDE NOTE===

On a Windows server, we run both ColdFusion and IIS under their own user accounts. This allows us to heighten security rather than have both services use the Local System account which has way more power than either service needs.

As such you have to set specific permissions on directories/files such as the ColdFusion/JRun folder and your webroot.

CFRoot
 - ColdFusion (Full Control)
CFRoot/lib/wsconfig
 - IIS (Read/Write)

Webroot
 - ColdFusion (Full Control)
 - IIS (Full Control)

However, if your application also has the ability to upload files, then by default ColdFusion will first upload these files to CFroot/runtime/servers/coldfusion/SERVER-INF/temp/wwwroot-temp (Server Config) or jrun/servers/<server>/SERVER-INF/tmp/wwwroot-temp (Multi-server)

It will then move the uploaded file(s) to the location you have specified in your <CFFILE> tag.

Where you run into an issue here is that on Windows, when a file is moved from one location to another on the *same* volume, it retains the permissions of the source folder. As such, because we didn't give the IIS account permissions on the ColdFusion temporary file upload location, it will NOT have permissions once it is copied into your webroot.

The fix is simply to give the IIS service account permissions on the ColdFusion temporary file upload location

===END SIDE NOTE===

However, file permissions wasn't the issue.

I then looked at whether I could directly access the page the Flash file was trying to call. I could (albeit with some errors, none of which were relevant to the issue at hand).

There were no relevant errors in the ColdFusion logs, so I had a look at the IIS logs and I spotted something:

<!---\\\\ THIS IS THE LINE REPRESENTING THE FAILED UPLOAD FROM THE FLASH CLIENT \\\\--->
2010-10-11 15:22:54 127.0.0.1 POST /upload.cfm;jsessionid=e230d63f26e10948e22d503ff131507c203c - 80 - 127.0.0.1 Shockwave+Flash 404 7 0 1

<!---\\\ THIS IS THE LINE REPRESENTING ME CALLING THE PAGE DIRECTLY IN THE BROWSER \\\--->
2010-10-11 15:30:36 127.0.0.1 GET /upload.cfm - 80 - 127.0.0.1 Mozilla/5.0+(Windows;+U;+Windows+NT+6.1;+en-US;+rv:1.9.2.10)+Gecko/20100914+Firefox/3.6.10 200 0 0 89

The Flash request is returning a 404 NOT FOUND, yet requesting the page in the browser gives us a 200 OK.

Can you spot the problem? *hint* what does request filtering do?

We are using Request Filtering to only allow certain file extensions, i.e. .cfm, .cfc, etc

When the Flash file submits to the upload.cfm page it is tagging on the jsessionid to the request, and because of the way jsessionid is appended, IIS thinks the file name is actually upload.cfm;jsessionid=e230d63f26e10948e22d503ff131507c203c and not just upload.cfm and therefore rejects the request, returning a 404 NOT FOUND.

Two quick and easy solutions and one with a little more work

1) Remove the request filtering of file extensions (bad choice)

2) We get the Flash file to call upload.cfm?r=1 which it appends the jsessionid to, giving upload.cfm?r=1;jsessionid=e230d63f26e10948e22d503ff131507c203c which DOES work as IIS can safely detect the file extension.

3) You could also use IIS7's URL re-writing functions to strip off the jsessionid

As I wanted an easy fix, I went with 2 but will look at 3 for moving forward.