I am supporting a classic asp application developed by another developer. This application will be public facing. Before making it public our network team ran a Security Scan and found some issues. One of the issue mentioned by them is as follows:
Fix Microsoft IIS ISAPI Extension Enumerate Root Web Server Directory Vulnerability
and they provided following steps to resolve this:
You can configure IIS 7 to check for the existence of a file before returning an error message.
Go to Handler Mappings
For all enabled IISAPI mappings, Edit ->
Request Restrictions -> Check 'Invoke handler only if request is
mapped to: File'
Disable all unused mappings.
This will address the
following issue: Microsoft IIS ISAPI Extension Enumerate Root Web
Server Directory Vulnerability (HTTP-IIS- 0013).
I am not familiar with Classic ASP but I checked Handler mapping and tried the steps mentioned above. Following are my questions:
Is there an easy way to identify handlers which are not being used?
there are 50+ handlers do I need to click each one of those to invoke handler only if request is mapped to: File
Can this all be handled from Web.config?
Instead of changing the mappings you should be able to turn off detailed error messages for remote users.
In IIS manager select your website, click on error pages, edit feature settings, choose detailed errors for local requests and custom error pages for remote requests.
Related
Using IIS 7 with a deployed dotnetcore 2.1 or 3.1 web API alone in an application pool, we discovered while looking at Process Monitor on the server, the w3wp.exe workers were logging many errors where they were apparently looking for a web.config. They checked every route in the api's route. The expected behavior was that the w3wp.exe (an IIS worker) would "hand off" the request to the dotnetcore application's routing, which would find the endpoint, but instead, it appeared to be also checking for a web.config. The process monitor revealed w3wp.exe QueryOpen NAME NOT FOUND and PATH NOT FOUND errors.
I looked at a few articles and concluded it was a problem with web.config inheritance, and there must be some setting in IIS or a dotnetcore configuration that was dictating the behavior of checking each API route path as if it were a virtual directory folder system that might contain a new web.config. The benefit would be that you could have a different web.config in a sub-application, but we didn't want that benefit and we didn't want these IIS workers blowing up the logs with thousands of these errors throughout the day. We found an insanely simple solution that an IIS admin might say "duh" but will hopefully save someone out there some time.
We found the answer on an old blog.iis.net post about web.config inheritance (https://blogs.iis.net/steveschofield/control-web-config-inheritance-with-iis-7-asp-net-options). There is a configuration called allowsubdirconfig that directs the w3wp.exe worker to check subdirectories for a web.config file. Here's how you change it in IIS applicationhost.config that can be found through IIS Manager:
Go to configuration editor
Go to system.applicationHost => sites => virtual directory defaults
Set allowSubDirConfig to False
We also discovered that Microsoft recommends you use this setting for hosting dotnetcore applications on IIS
Skipping the additional file operations can significantly improve
performance of websites that have a very large set of randomly
accessed static content.
https://learn.microsoft.com/en-us/previous-versions//dn529134(v=vs.85)?redirectedfrom=MSDN
Keep in mind, if you use this setting, you'll need to come up with a solution to separate applications that use or don't use the setting.
Related issue with MVC:
ASP.NET MVC security and IIS allowSubDirConfig configuration
Using the instructions in this link and the "How to Deploy Klondike"
github instructions I have installed the Klondike release on my local IIS (Version 10.0.15063.0). At first it looked promising, but then I realized that the main page is showing "loading..." rather than the Klondike URL. See image:
Additionally the when I click the API page tab, the site navigates to http://localhost:8081/api which returns a 404.0 HTTP error. This error may not seem very surprising as the site's directory does not contain an api directory. However, I have reverse engineering a working server with Klondike configured on it and it also does not have the api directory. Here is an image of the 404.0 error:
Additionally, when I try to nuget pushto localhost:8081, it results with the error in the image here (note, the red blocked out text is the apikey).
Finally, I have left the handleLocalRequestsAsAdmin is set to true, but even though I am on localhost, it does not show me the "LocalAdministrator" link. I believe that all these symptoms are linked to the same issue.
I have tried the following with no affect on the behavior:
Putting this site in c:\inetpub\wwwroot and also in C:\Klondike;
Using different port numbers, such as 8081 and 80;
Putting a 127.0.0.1 alias in my hosts file and binding the value in IIS to the host name; and
Installed the Debugging tools for Windows install as was suggested on the github site and set the debuggingToolsPath to its path.
(at this point, I'm just guessing at the issue)
The settings I have changed in settings.config file are as follows:
packagesPath = C:\Klondike\App_Data\Packages
Left lucenePath = empty string (I also tried this with a value of C:\Klondike\App_Data\Lucene with no affect.
symbolsPath = C:\Klondike\App_Data\Symbols
debuggingToolsPath = C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
ignorePackageFiles = "true"
I have not changed any values in the web.config file from the default web.config release values.
Thank you for any help that you can provide.
I ran into the same problem, although I was installing Klondike on a remote server rather than locally, but still IIS 10. The problem might be you don't have all the IIS components installed or enabled. More specifically, .NET or one of its required components might not be installed or enabled. If you look at the error on the /api link - it has to do with the MapRequestHandler and Static file handler in IIS - this indicates IIS doesn't know how to handle the request, which is an indicator you might be missing the ExtensionlessUrlHandler in IIS, as well as other components. To solve the problem, go to Start -> Control Panel -> Turn Windows features on or off (varies per system, might be under "Programs and Features"), then find the IIS Application Development Features. These might be listed under Internet Information Services -> World Wide Web Services, or Web Server (IIS) -> Web Server, depending on your system. Once you find these Application Development Features, make sure you have an ASP.NET option checked - you might just want to check all the options. Below is screenshot of what it looks like on my system. You might want to reboot after adding those features - not sure if a reboot is required, but it doesn't hurt. After you enable those features, you might start to run into all kinds of file permission errors when running the Klondike app - you might want to just remove Klondike and reinstall it from the zip file. I have a feeling it Klondike doesn't run cleanly the first time it has problems, as it needs to create an App_Data folder with sub directories.
I'm trying to get a site working on IIS7 with classic ASP and having problems. I've created a directory and added both Network Service and IIS_IUSRS with full control. I've also changed the anonymous authentication to the application pool identity, but still no joy. I really have no idea what to try next.
Have you made sure that Classic ASP is installed? It's an extra option which can be here: Control Panel/Programs/Windows Features/Internet Information Services/Www services/Application Development Features/ASP.
hi i am comletly new to iis and asp.net i am trying to setup bugNET on a godaddy server. i created a virtual directory and once i tried to launch the site i get this error:
Parser Error Message: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
here is complete detail of what i did.
hosting: godaddy
created virtual directory (child folder of root) - named: devbunk with these settings (anonymous access, directory browsing)
that is all i can do to with iis on godaddy.
the error tells me that i need to turn the virtual directory as an application. godaddy doesnt let me do that... how do i do it? btw, i have iis7 setup.
You can configure this with Godaddy Hosting Control Center. log in to godaddy hosting center.
Go to Content >> IIS Management.
Click on the pencil icon to edit your selected directory.
you will get a popped up screen with three check boxes. You need to check the one that says "Set Application Root".
Click Ok and your directory will be configured as an application in IIS.
Hope this helps you and feel free to ping me if you need more info.
You need godaddy to do that, usually hosters do offer the ability to convert a regular folder as an application through their Control Panel, so if you have access to one search for that option. Other hosters give access through IIS Manager and Web Deploy to convert folders to applications as well, but it boils down to "you need your hoster to do that".
There are no ways for you to do that through Web.config or FTP or etc. I think Front Page Server Extensions did had a way as well. The best thing is contact your hoster and ask them what is the right way of doing this. Usually all hosters will allow you to create as many applications as you need as long as they run the same .net version.
Check the properties on Web.Config to ensure "Copy to Output Directory" is set to "Do not copy"
I'm running into a problem setting up my development environment. I've been working on ColdFusion and .NET applications up until recently I haven't needed to touch IIS. Now, I have to set up a classic ASP application for some one-off work.
I added a virtual directory in IIS and pointed it at the actual codebase on my local machine. I then set the security to low (for ISAPI extensions, i.e. ASP) and allowed for script execution. For some reason though, if I hit any .asp page it says the page cannot be found. However, HTML and static files load up just fine.
EDIT: URLScan fix seems to have done it. Fired up the app in another browser (i.e. not IE6), and I'm getting better error reporting. Looks like we're missing some includes, but it is executing the scripts. Thanks!
You need to make sure that the "Active Server Pages" web service extension is set to an allowed status.
Check out: http://classicasp.aspfaq.com/general/why-does-iis-hang-and/or-stop-serving-asp-pages.html
Also, you should be aware that a virtual directory may affect the include file paths in the asp pages themselves. If the original asp application does not use a virtual directory, then your local copy shouldn't either.
Take a look at your URL scan settings and see if .asp is an allowed file extension
On my XP machine the relevant file is located at C:\WINDOWS\system32\inetsrv\urlscan\urlscan.ini