June 9th, 2003, 12:21 AM
The thing is, (much like catch just said) URLScan filters the URL BEFORE it is interpreted by IIS. So while doing your own url/input validation at the web app level is crucial, URLScan aims to protect at the web server level, in other words, from IIS flaws themselves: web app input validation would NOT have prevented from unicode or double decode attacks, while URLScan would have.
forget using URLcsan, all that input validation can be writen into your web app, if you do it via the web app you have control over what happens when the tests pick up somthing bad. However URL scan will only prevent cirtain kinds of vulnerabilities it will not stop the changing between accounts within a web app by changing id=1 to id=2 in a url (that is only an example it will depend how a web is writen is it is vulnerable). To prevent that kind of attack, all information that determines the state of the user should not be held on the client side.
To sum up, there is more to web app security than just testing what is with the url.
Of course, such tools can be disruptive if configured incorrectly (muhc like a firewall per say), like Slarty mentionned. It still remains a great tool if configured correctly. Furthermore, for someone serving static content only, there's little chance of "interferance", making it a rather straight forward process...
Credit travels up, blame travels down -- The Boss