Group items tagged

Securing Non-ASP.NET Files

ASP.NET handles requests for file extensions that are normally associated with ASP.NET, while IIS handles requests for all other file extensions. By default this means common file extensions such as .aspx and .asmx are processed by ASP.NET. This processing includes authentication and authorization to ASP.NET files. Sometimes though, a developer wants non-ASP.NET resources to be processed by ASP.NET. One reason for processing non-ASP.NET files through ASP.NET is to allow ASP.NET authentication and authorization to control access to these types of files. The combination of IIS6 on Windows Server 2003 and ASP.NET 2.0 provides the most flexibility for running the ASP.NET pipeline as part of processing a request for a non-ASP.NET resource. IIS6 includes support that allows ASP.NET 2.0 to perform authentication and authorization steps, and to then hand off the remainder of the processing of a non-ASP.NET resource back to IIS6. For example, it is possible to authenticate access to an ASP page using ASP.NET forms authentication, authorize access with ASP.NET's Url authorization and still allow the ASP ISAPI extension (asp.dll) to execute the ASP page. This support is possible because IIS6 introduced a new server support function for ISAPI extensions: HSE_REQ_EXEC_URL. Assume that a directory structure contains a mix of both ASP and ASP.NET files. The ASP.NET pages are used to log a user in with forms authentication, while the ASP pages represent the rest of the application. Using the IIS6 MMC, right-click on directory and create an application (this is the same step that is necessary when setting up a standard ASP.NET application). After an application has been created, click on the Configuration button that is located on the Directory property page. This will cause the Application Configuration dialog to be displayed. New to IIS6 is a feature called wildcard application mapping. The bottom of the Application Configuration dialog allows you to configure this feature. First determine the path for the ASP.NET ISAPI extension that processes ASP.NET files such as .aspx files. You can find this path by looking at the extensions that are listed in the Application Extensions list shown in the top half of the Application Configuration dialog. Click on the row in the list that maps the .aspx extension, and select the Edit button. In the dialog that pops up, highlight the text in the Executable textbox and copy it to the clipboard. Then cancel out of the dialog. Next, click the Insert button that is in the bottom half of the Application Configuration dialog. A dialog box titled Add/Edit Application Extension Mapping will be displayed. In the Executable text box, enter the path to the ASP.NET ISAPI extension that you copied to the clipboard earlier. The end result should look something like the screenshot below.

Click OK to close out all of the dialogs. Now whenever a request is made for any file, the request will first be processed by ASP.NET. If the web.config for your ASP.NET application has enabled forms authentication, an unauthenticated request for a .asp file will first trigger a redirect to the login page configured for forms authentication. After a user has successfully logged in, they will be redirected back to the original .asp page. When the now-authenticated user requests the .asp page, ASP.NET will first run through the FormsAuthenticationModule to verify that the forms authentication cookie exists and is still valid. If this check passes, ASP.NET will hand processing of the .asp page back to IIS6, at which point IIS6 will pass the request on to the ISAPI extension that normally process .asp pages. In this case the extension is asp.dll and the ASP page will then run to completion. The reason ASP.NET will pass the request back to IIS6 is that non-ASP.NET resources will fall through the list of configured <httpHandlers> to the following entry: <add path="*" verb="GET,HEAD,POST" type="System.Web.DefaultHttpHandler" validate="True" /> The DefaultHttpHandler is responsible for handing requests back to IIS6 for further processing.