Step 5: Protect Web Services in Windows

Step 5: Protect Web Services in Windows

A considerable number of large and medium-sized enterprises are using Windows Server and. Net architecture to build enterprise Web services and applications. Therefore, Web Services and Web applications are usually supervised by ASP. NET and IIS. Protecting Web Services and Web applications is a configuration environment issue rather than a programming issue. For example, SSL/TLS encryption is the best way to ensure confidentiality. Activate it for your application. The simple way is to configure IIS properly and then access it with a URL prefixed with https.

ASP. NET Security Configuration mainly involves editing a Hierarchical XML document set. At the top of the tree is machine. config, where global settings for all ASP. NET applications running on this machine are well set. Under the global configuration file is the web. config file, which contains the settings for each individual ASP. NET application. This article will discuss how to configure CAS, identity authentication, counterfeiting and authorization in these files to ensure the safe operation of Web Services.

1. Configure CAS for ASP. NET

Although CAS is mainly used to protect system clients from malicious Mobile Code intrusion, it is still associated with the deployment of Web Services and Web applications on servers. For example, a server may host more than one individual, ASP authorized by a group or organization.. NET applications; in this case, CAS helps reduce the risk that applications owned by one entity are disturbed by applications owned by another entity, it also facilitates the risk of server operating system interference.

However, you should note that by default, the CAS Policy grants a complete set of assemblies to ASP. NET applications. Because they run from a local machine. Obviously, you should fix this When configuring your application .. The NET Framework defines many different trust levels: Full, High, Medium, Low, and Minimal. You can use them to determine the permissions granted to ASP. NET applications. In addition to the first of these policies, they are specified in the configuration file web_hightrust.config and web_mediumtrust.config. All other policies are located in the configuration subdirectory under the. NET Framework root directory. To authorize a special ASP. NET application a medium trust level, you must give its web. config file the following structure:

<configuration>
<system.web>
<trust level="Medium"/>
</system.web>
</configuration>

2. Run with minimum privilege

The "Worker Process" that processes a single ASP. NET Request runs in the Windows environment where the account is ASPNET. This special account has a restricted Windows privilege set. to control this damage, you should give it to ASP. NET applications. However, for a working process, it is possible to execute it under the same account-SYSTEM account as IIS. If you want this to happen, the machine. config file you wrote should be like this:

<configuration>
<processModel userName="System" password="AutoGenerate"/>
</configuration>

To make this change take effect, you must restart IIS Management Service and WWW Publishing Service.

One possible reason for this is that, in order to obtain an access token for a Windows user for a counterfeit purpose, your ASP. NET code can call LogonUser from the Win32 API. However, this violates the basic security principles of least privilege and significantly increases the damage caused by successful attacks. Therefore, you should consider it carefully before doing so.

3. Identity Authentication

ASP. NET provides four typical authentication methods: None, Windows, Forms, and Passport. Each authentication method is configured in the web. config file of the application's root file. For example, to completely disable ASP. NET Identity Authentication-suitable for public websites that do not require user logon, you need a configuration file:

<configuration>
<system.web>
<authentication mode="None"/>
</system.web>
</configuration>

Remember the interaction between IIS identity authentication and ASP. NET identity authentication. Both of them must be correctly configured to achieve the expected results. Normally.. NET, or in IIS and ASP. none, Forms, and Passport in NET use the anonymous mode.

In IIS and ASP. NET. The advantage of using Windows identity authentication is that the password does not need to be sent over the network, but the client application provides IIS with information about the current Login User identity, so that the information is forwarded to your ASP.. NET application. The disadvantage of this method is that it depends on the Windows operating system on the client and server. Forms-based identity authentication is a more suitable method for Internet-based systems, but in this case, SSL/TLS is used to ensure that the creden provided by users are encrypted, this is very necessary.

4. Counterfeiting

No matter whether Windows identity authentication is selected or not, ASP. NET Identity Authentication does not specify the user environment where the ASP. NET application is running. If you want your application to run in any account, not just the ASPNET account environment, you must impersonate your identity.

Assume that the requested user has been authorized by IIS as a valid Windows user, which is completed by the following web. config content:

<configuration>
<system.web>
<identity impersonate="true"/>
</system.web>
</configuration>

This causes the ASP. NET application to impersonate the user sending the request. However, if IIS is set to anonymous identity authentication, in IIS, ASP. NET Applications impersonate any user account, and these accounts have been configured to be anonymous.

If you want your ASP. NET application to impersonate a specific user, this is simple:

<configuration>
<system.web>
<identity impersonate="true" userName="Foo\bar" password="baz"/>
</system.web>
</configuration>

The obvious danger here is that user creden。 exist in plain text in web. config. It is possible to avoid this risk. We store encrypted user creden。 in the Registry and reference them from the web. config element.

<identity impersonate="true"
  userName="registry:HKLM\Software\MyApp\AspNet,Name",
  password="registry:HKLM\Software\MyApp\AspNet,Password"/>

In this example, aspnet_setreg.exe must be used to encrypt user creden。 and store encrypted user creden。 in the registry.

5. Authorization

When you apply Windows authorization in ASP. NET, the authorized user must have the necessary NTFS permission to access a given resource. This is called file authorization ). ASP. NET supports other more flexible authorization types, known as URL authorization ). Unlike file authorization, this is configured through the web. config file of the application. It allocates Applications Based on ASP. NET identity authentication, rather than based on the permissions of a licensed Windows account. An example of simple URL Authorization configuration is as follows:

<configuration>
<authorization>
<allow verbs="GET" users="Fred,Joe"/>
<deny verbs="POST" users="Fred,Joe"/>
<allow roles="Developers"/>
<deny users="*"/>
</authorization>
</configuration>

This example allows the user Fred and Joe to submit the http get request to the application to obtain any resources in the website managed by the web. config file. However, if an http post request is sent, the requests will be rejected to access these resources. Anyone (except Fred or Joe) who acts as a developer is allowed to access the website without restriction, but all other users are denied access to any resources. The order of these elements is very important, because the first match will be used by ASP. NET. At last, it is clear that you usually need to lock the website, because by default, the machine. config file includes the following Configuration:

<authorization>
<allow users="*"/>
</authorization>