IIS Insider - September 2002

By Brett Hill

How To Send Query String Information For Redirection

Q: In our original web server configuration, we had a page called browse.asp in several folders. To simplify our design, we now have only one browse.asp in a single folder. However, the server still receives requests from users looking for the browse.asp page in one of it's previous locations. I want to redirect those requests to the new location for browse.asp. Using IIS built in redirection, this seems fairly simple, however query string information seems to get lost in the process. For example, we setup a redirect for https://servername/oldfolder/browse.asp to https://servername/newfolder/browse.asp. The user sends the server the url as https://servername/oldfolder/browse.asp?cat=135. This is properly redirected, but without the query string. Is there anyway of having IIS send query string information from the originally requested url?

A: You have quite a lot of flexibility with IIS in terms of how you instruct IIS to redirect URL's. One of the lesser known but very useful features of IIS gives you the ability to use variables in the redirection to gain a high level of control over exactly what is passed to the new URL. For example, in your situation, right click on the old browse.asp, and on the File tab, select Redirection to URL and enter https://servername/newfolder/browse.asp$Q. This uses the built-in server redirection variable $Q to send the query string portion of the original URL to the new location. Below is the table of available query strings as detailed in the online IIS 5 help files and in the Microsoft Knowledge Base (KB) article, Q313074.

Differences Between In and Out of Process In the Event of a Buffer Overflow Attack

Q: Is it possible to clarify the difference between the differences of running

applications in process vs running them out of process, as pertains to what happens if an application is comprised by a buffer overflow attack?

A: I have always found the term in process to be a little bit confusing. All applications are in a process, so in reality, there is no such thing as an application that runs out of process. Nevertheless, we hear these terms a lot in reference to IIS applications, so what do they mean? In IIS 4 and 5.x, there is a process named inetinfo. When a web application runs in in process, the application is running inside the inetinfo process. For IIS 4 applications, applications are run in the inetinfo process by default.

It follows the out of process applications that are not run in inetinfo. Out of process applications are hosted in a process named MTX for IIS 4 and dllhost for IIS 5.x.

All processes run in the security context of a user account. The Inetinfo process runs as the System account. MTX (IIS 4) and dllhost (IIS5.x) run as the IWAM_<servername> account.

Now we have all the pieces in place to answer your question. In the event of a successful buffer overflow attack, the attacker may be able to run code in the security context of the process that hosted the failed application. Therefore, if your application runs in process (in the inetinfo process), the attacker would be in the System context which has widespread rights on the server. If the application runs out of process in MTX or dllhost, the attacker would be in the context of the IWAM account which is intended to have very limited rights on the server.

It is important to note that IIS 5's default configuration runs all applications out of process in the Medium (pooled out of process) application protection setting. This is far more secure than running application in process for the reasons given above. Highly publicized buffer overflow attacks on IIS 5 that resulted in access to the server through the System account were configured to be more vulnerable than the default settings. Additional security can be achieved by running the IIS Lockdown tool, which applies restrictions to the IWAM and the IUSER account.

By the way, IIS 6 (part of Windows Server 2003) is configured in such a way that in it's default worker process isolation mode, there is no possibility of a buffer overflow attack providing access to the server with a high privilege account.

How To Use Previous Log Files After Recreating the Site

Q: I have a question regarding the IIS metabase file. When you create a new web site on your IIS 5 server, a log folder is created for the web site. IIS increments the folder name. This is to avoid the possibility of misnaming or corrupting the log folders, which is fine. However, in the event you have to remove and re-install a 'site', you lose the old metadata. Specifically, you lose the log folder location. It is now the last, incremented log folder. [eg. If the previous addition was W3SVC8, then the current logfolder is now W3SVC9] . Is there any way to edit the metabase so that IIS will point the site properties to the old logfolder name?

A: You've described an interesting problem, but you've made an assumption that needs to be clarified. Yes, IIS does create a log file folder, typically in the c:\windows\winnt\logfiles directory. Also, as you astutely observed, if you delete and re-create a web site, the log file folder name will change. However, IIS does not increment the file folder name for the sake of avoiding conflicts with a prior set of log files. Rather, the folder name for the log files is based on the site number, sometimes called the instance number, of the web site in the metabase. Every site you create has a unique number and every time you create a new web site, the number is incremented. You can see this clearly using MetaEdit where the web sites are shown as the folders (metabase keys in this case) 1, 2, 3, where 1 is typically the Default Web Site, 2 is the Administration Web Site, etc. (see Figure 1 below).

Figure 1   As seen in MetaEdit

Therefore, if you have sites 1, 2, 3, and delete site 2, and then create a new web site from the IIS console in order to recreate the old one, IIS assigns the next highest site number which in this case would be 5. The log files would then be placed for in a folder named w3svc5 instead of w3svc3.

Once created, it is best not to change the site ID since other keys (such as the site root path) refer to it. In this situation, you can just copy the log files from the old log file folder to the new one.

However, if you've used a script to create your web site instead of the user interface, you can specify the site ID you would like to use for your replacement web site. In this way, you can achieve your desired goal. You will find a script called mkw3site.vbs in the \Inetpub\Adminscripts folder, which is installed by default. Open that script in Notepad or another text editor to see what syntax is used, and you'll find that one of the arguments is Sitenumber. This allows you to create a web site at the site number that you specify, instead of the next incremented site number as determined by the IIS console.

Submit your questions to the IIS Insider. A response is not guaranteed. However, selected questions along with the answers will be posted in a future IIS Insider column.

For a list of previous months questions and answers on IIS Insider columns, click here.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is," without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.