Shulou(Shulou.com)06/02 Report--

In terms of the security of the application pool, we must ensure that the w3wp.exe worker process can read the IIS configuration data, because this is the basis for the w3wp.exe worker process to work properly. The w3wp.exe worker process must be able to read the IIS settings of the Web site it serves. This means that the w3wp.exe worker process must have Read access to most of the content configured in the applicationHost.config file. The problem is that if each application pool can read the entire configuration file, all the information in the configuration file is exposed to each application pool. Therefore, we must ensure that in terms of the overall content in the applicationHost.config file, each application pool is not allowed to have Read or Write permissions on the overall content. Otherwise, some users can gain access to sensitive information.

To solve this problem, the IIS development team proposed a method that allows the w3wp.exe worker process to read all the settings related to it, but at the same time does not need to access the information of other applications or sensitive global settings data, so that complete configuration isolation can be achieved between different application tools.

When the application pool starts for the first time, Windows Process Activation Service (WAS) only gets the information about the application pool and creates a temporary folder under the C:\ inetpub\ temp\ appPools\ directory, sets the ACL for the application pool, and then saves the information in this temporary folder. The following figure shows the folder where the WCF.Inventory.config file is saved.

Most of the data in the .config file is the same as the data in the applicationHost.config file, but the Web site information from any other application pool is not saved. There is no need to save Web site information from other application pools in the .config file, because the w3wp.exe worker process is managed by WAS, and the w3wp.exe worker process does not need to use its own information.

If the data related to the file changes, the temporary file will be updated; otherwise, the file will be kept in the above directory until IIS stops running. If we delete this file, IIS will not be able to perform the functions of the application pool properly, all operations related to the application pool will fail, and this problem can be resolved only after IIS restarts and the deleted file is regenerated. If we just recycle the application pool, the deleted file will not be regenerated, so the problem cannot be solved. Therefore, unless you must use these files when locating errors, and you can really understand the functions and ways of these files, it is best not to manipulate these files.

The entire process of creating temporary files in IIS 7.0is completely new, ensuring that malicious code in an application pool cannot read sensitive configuration data from the application pool.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.