Last post Sep 23, 2010 07:33 PM by dwrogers
Sep 20, 2010 09:36 AM|timrobinson33|LINK
Tried this on my windows 2003 server. It only checked web apps that were physically located inside c:\inetpub\wwwroot
I have since tried it on another windows 2003 server and it seemed to pick them all up, but I can't say for sure since I've lost confidence in it
If you do run it on a production server, my advice would be to check carefully through the output to make sure it has picked up _all_ your web apps.
Sep 20, 2010 10:33 AM|mbanavige|LINK
The tool does scan apps even if those apps are not physically located inside the wwwroot folder.
But... If you create a virtual folder for your app under a physical subfolder of your root web then it appears to get missed in the scan.
Do you perhaps have a configuration similar to what i posted here:
FYI: DetectCustomErrorsDisabled3 not scanning virtual folders under physical subfolders.
Sep 20, 2010 10:38 AM|timrobinson33|LINK
OK after spending the last hour working out how to debug an obsolete buggy scripting language, I have found that the error was down to a broken junction point inside one of the virtual directories. This (presumably along with any other file access error)
will cause the script to simply exit with no message or any indication that anything was wrong.
If you are going to use this script, I would suggest you add some kind of print statement around line 81 to indicate that the script has at least run to completion although note that the "on error resume next" at the top means that it could still have missed
parts of the tree without reporting any error.
Seriously guys, vbscript was probably the worst scripting language in the world 10 years ago and this kind of crap isn't doing you any favours. If there's any kind of unexpected problem running a security scan tool, it should print a reasonable error message,
not just quit silently
Sep 23, 2010 07:33 PM|dwrogers|LINK
Amen. I have a site with a subfolder that has restricted access. The script fails silently. This should have been written in a modern language. The easy fix appears to be inserting
ON ERROR RESUME NEXT
before line 130, as in:
ON ERROR RESUME NEXT ' the statement following could have an access error
FOR EACH dir IN objFileSys.GetFolder(Path).SubFolders