June 29, 2011 1 Comment
Today I was doing some spring cleanup on my server and as part of this I applied URLScan to my webserver to enhance the security of IIS. It’s a simple & free install and all looked good. I checked the various sites running on the server and all seemed fine. Except… for my main site. I browsed to it and I got a 404. Every page returned a 404. Hmmm. Obviously I checked to make sure I hadn’t inadvertently deleted any files on the server while I was doing my cleanup. I hadn’t. IIS running properly? Well, since this was isolated to one site , yep. So it’s something about this one site that is broken and what could it be.
Some may know that I use a modified version of Fusebox3 framework for my coding. This routes everything through a single index.cfm file using various templates & includes. This makes maintenance simple and allows for a ton of code reuse and I’m a big fan.
To start the diagnosis, I simply started with index.cfm and commented out the code which kicks off the fusebox framework. A simple <cfoutput>#now()#</cfoutput> confirmed that I was able to serve a cfm page correctly and eliminate a CF configuration problem. Next I worked my way through a couple of more templates until I got to one which made me say hmmmm. As part of this framework, I redirect users who land on
When I removed the redirect so the page stayed on mysite.com/index.cfm my layout page loaded without the 404. Very interesting.
For years, I’ve been using sesConverter (on this one site only) to convert my search engine friendly urls like:
to Coldfusion urls like
So it seems that was only files within the framework that seemed to be an issue. On a hunch, I tried
and TADA – the page loaded completely. OK. So now I knew there was an issue with sesConverter but what was it. The page at Fusium is pretty much abandoned with little information in any case. I had a look at the page code and didn’t really see anything that could be an issue.
I knew there was an issue with the url and I knew I had just installed URLScan so hmmmm what to do. Back to the URLScan site. All of the settings for URLScan are in URLScan.ini. Third setting in and I had my answer
By default, this option is set to 0. If this option is set to 0, URLScan rejects any request that contains multiple periods (.). This prevents attempts to disguise requests for dangerous file name extensions by putting a safe file name extension in the path information or query string portion of the URL. For example, if this option is set to 1, URLScan might permit a request for http://servername/BadFile.exe/SafeFile.htm because it interprets it as a request for an HTML page, when it is actually a request for an executable (.exe) file with the name of an HTML page in the PATH_INFO area. When this option is set to 0, URLScan may also deny requests for directories that contain periods.”
Since I left everything as default after the install, AllowDotInPath was set to 0 or deny. That’s a bit of a problem when your URL looks like
as the main.home will match the deny rule and URL Scan will block the request. (at least I know it’s working!) The fix was simple. Just change AllowDotInPath=0 to AllowDotInPath=1
No need to even restart IIS, The site was up and running immediately.
Note: Some may be wondering about the security of this. As it states in the note, allowing DotInPath could result in an attack like “http://servername/BadFile.exe/SafeFile.htm. While this is true, an attacker has to have a way to get that file on your server in the first place. Since my server is locked down with no FTP and no user file uploads, there really is a very small risk in continuing to use sesConverter and AllowDotInPath=1
UPDATE: Found another issue today. Or rather a few browsers did. I have a form that is filled out and before submit, I do a client side check to make sure the form is filled out correctly. If not, I pass a string to ColdFusion.Window.create to open a cfwindow with information on the missing fields
Basically it is this
ColdFusion.Window.create(“myWindow”+showreq.arguments, showreq.arguments, “#msgWindow.cfm?msg=<span style=”font-weight:bold;”>Require Fields Missing</span>” + fieldArray)
However, by default, URLScan blocks the inclusion of HTML in the url. This shows in the URLScan log as Rejected disallowed+query+string+sequence query+string – When users missed filling out a form field, instead of the nicely formatted error window, they received a 404 message (as the msgWindow.cfm was blocked) which led them to believe the page was broken, when in fact it was working, provided they filled out all the fields correctly.
So this kind of checking is something we want to keep doing as for the most part, HTML has no business in a URL. I will be re-thinking my user feedback on this and doing a bit of a rewrite but in the meantime, I needed a quick fix. Turns out URLScan.ini comes to the rescue again. Fortunately, there is a section called
; URLs listed here will always be explicitly allowed by UrlScan
; and will bypass all UrlScan checks. URLs must be listed
; with a leading ‘/’ character. For example:
and adding just the single URL to the exception rule, things got back to normal. Note that the path in the URL must be complete from the root so it may be /files/display/msgWindow.cfm or whatever.
Wonder what I’ll find next?!?