Recently I was at a client site and was maddened to learn that the client required the use of URLScan with IIS 6.0. Let’s remember IIS 6.0 was mostly re-written with security being the front-runner. That’s right this is not the IIS (i.e. 4.0 or 5.0) of years past that were a cesspool breading ground for vulnerabilities. Now back to my original complaint about URLScan coupled with IIS 6.0. It wasn’t the fact that URLScan was being used that irked me to no end; instead it was the fact the the “InfoSec” team deemed it necessary to use the default configuration. However, I had done my homework and presented the following two links for their InfoSec team to review: IIS 6.0 Makes URLScan Almost Obsolete and UrlScan Security Tool.
I applaud the client as they were definitely security conscious. Although, there’s a balance between security and usability that this site definitely did not comprehend. The main argument from their InfoSec team was the concern over “AllowDotInPath”. After presenting the aforementioned material to their resident security head we were allowed to move forward with commenting out the various items that were unneeded or caused problems. I never received any gratitude for pointing out these issues nor would the security head admit to being incorrect on their stance. I was later told one vendor had to re-write an entire module for their code to work with URLScan, due to the “AllowDotInPath” issue. I recommended that the InfoSec team create a IIS 6.0 only configuration file when using URLScan with IIS 6.0. Otherwise, they’re bound to run into issues further down the line.