A Glance at Web Application Security

Applies To

The Information provided in this article applies to the following technologies:

Windows Server 2003 family OS, IIS 6.0, .Net Framework 2.0 & Asp.Net 2.0

Introduction

Web application security involves implementing protective measures against potential threats, malicious or unintentional, that exploit exposed vulnerabilities. Security is best implemented using the defence-in-depth technique by applying protective measures at network, host, and web application levels. This article will focus on security at the application level by exploring IIS and ASP.net authentication, authorization and secure communication.

Authenticating user credentials

Authentication is the process of matching user credentials against a predefined set of data. Its aim is twofold: first, to deny access to intruders and second to identify authenticated users so that they are given appropriate privileges to resources. User credentials can be authenticated through IIS at the Web server level and through Asp.net at the application level. In addition, for distributed Web applications, authentication can occur, for example, via Enterprise Services and a Database Server.

 

Figure 1. Web application authentication architecture

User Authentication through IIS

The types of authentication provided by Internet Information Server (IIS) version 6.0 are the following:

Anonymous
It consists in an authentication method used for public web sites where access is granted to all users, which are identified by IIS with the IUSR_ComputerName Internet guest account. To maximize security IIS can be configured to use a different account to authenticate anonymous users.

Basic
Allows IIS to authenticate Base64 encoded users' credentials, sent through the Internet, against valid Windows or domain user accounts that are given the privilege to logon locally. It is compatible with most Web browsers and not appropriate where a high level of security is paramount unless used in combination with an Secure Socket Layer connection.

Client Certificate Mapping
This type of authentication allows IIS to validate client certificates, through SSL, against certificates held in the Web server and mapped to user accounts by using one of the following:

• One-to-one mapping. By using this method a personal user certificate issued by a Certificate Authority and integrated with a Web browser is validated by IIS against a certificate of the user stored on the Web server and mapped to his Windows user account.
• Many-to-one mapping. With this method client certificates that fulfill a specific requirement, such as being issued from the same CA for example, are validated against the certificate of a single user account held on the Web server and mapped to a specific Windows user account.
• Directory services client certificate mapping. In an Active Directory Domain IIS can be configured to authenticate certificates of users stored in directory services to the certificate held in the Web server and mapped to a user account. This method can only be enabled, at the Master properties level, for all the web sites in the Web server and disables the use of both one-to-one and many-to-one mappings for the entire Web server.

Digest
It is an authentication method that allows IIS to validate the hash of a user's credential against the hash of the user's domain account. Accounts for users that use digest authentication must have their password stored in clear text in Active Directory. This can be easily configured by using the Active Directory Users and Computers snap-in. This authentication method is supported only by latest browsers such as Internet Explorer 5 or later.

Integrated Windows
It is a highly secure authentication method suitable for an Intranet environment where IIS authenticates users based on their Kerberos domain logon credentials. This authentication method is supported only by latest browsers such as Internet Explorer 5 or later.

.Net Passport
Enabling this authentication method allows a user to be authenticated through a centralized authentication service offered by Microsoft. The authenticated user is issued a Passport ticket that is stored in an http cookie in his computer; IIS uses this ticket to grant the user access to the specific Web site.

All authentication methods are configured through the IIS snap-in. To enable an authentication method:

1. Open the IIS snap-in, right click the desired Web site and from the appearing context menu click properties.
2. On the appearing window, choose the Directory Security tab.
3. To enable Certificate Mappings click the Edit button under the Secure communications panel.
4. For the rest of the authentication methods click the Edit button under the Authentication and access control panel.

User Authentication through Asp.net

Asp.net applications can also be configured to require authentication through the following authentication providers:

Windows Authentication
It allows Web applications to authenticate remote or local users based on their domain or windows credentials. It uses Kerberos or NTLM security tokens to authenticate users who have already logged on to the domain and it prompts for a domain user name and password for users who need to log on remotely. By default Web applications are configured to use this provider through this entry in their Web Configuration (Web.config) file:

<system.web>
        <authentication mode="Windows"/>
</system.web>

This entry in the Web.config file instructs ASP.Net to deny access to unauthenticated users:

<authorization>
        <deny users="?"/>
</authorization>

To deny access to all users the following declarative entry is used:

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

The following entry denies, access to the Web application, to all users except the administrators role:

<authorization>
       <allow roles="ComputerName\Administrators"/>
       <deny users="*"/>
</authorization>

Forms Authentication
It enables ASP.Net to authenticate user credentials gathered through a custom login form. The following configuration entry in the Web application's Web.config file enables the Forms authentication provider:

<system.web>
<authentication mode="Forms">
        <forms loginUrl="~\Login.aspx" name="FRM_Authentication">
        </forms>
</authentication>
</system.web>

According to the configuration entry above when an authenticated user requests access to the Web application the Login.aspx form is served instead, by ASP.Net, for the user to submit his credentials. Once the user is authenticated the page he requested originally is displayed and a session cookie, with a default timeout, is stored in the user's computer.

User credentials can be stored in the Web.config file, during development or when little functionality for accounts management by the user is required, below is an example:

<credentials passwordFormat="Clear|SHA1|MD5" >
      <user name="USER1" password="hashed_or_clear_password"/>
      <user name="USER2"  password="hashed_or_clear_password"/>
</credentials>

Using Membership for authentication
The System.Web.Security namespace of the .Net Framework 2.0 contains the Membership class used to facilitate the management and validation of user credentials. The Membership class requires a membership provider to communicate with a data source. Membership providers are classes that are used to communicate with data sources. The .Net Framework 2.0 supplies the SqlMembershipProvider ActiveDirectoryMembershipProvider classes; custom membership providers can be defined by inheriting from the MembershipProvider base abstract class in the namespace above. The following changes in the Web.config of a Web application file enable Membership with Forms authentication:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">

     <connectionStrings>

       <add name="SqlConnection1" connectionString="Data

      Source=MSSQLEXPRESS;Integrated

      Security=SSPI;Initial Catalog=aspnetdb;" />

     </connectionStrings>

 

     <system.web>

       <authentication mode="Forms" >

         <forms loginUrl="login.aspx"

           name="FRM_Authentication" />

       </authentication>

       <authorization>

         <deny users="?" />

       </authorization>

       <membership defaultProvider="SqlProvider" userIsOnlineTimeWindow="15">

         <providers>

           <clear />

           <add

             name="SqlProvider"

             type="System.Web.Security.SqlMembershipProvider"

             connectionStringName="SqlConnection1"

             applicationName="TEST_APP"

             enablePasswordRetrieval="false"

             enablePasswordReset="true"

             requiresQuestionAndAnswer="true"

             requiresUniqueEmail="true"

             passwordFormat="Hashed" />

         </providers>

       </membership>

     </system.web>  

</configuration>

Creating the Login page
The Login page specified in the <forms> element can be created from scratch or more easily by using the Login controls that ship with Visual Studio 2005 and the .Net Framework 2.0.    

Passport Authentication
Microsoft Passport is a central authentication service that sites can register and use at a fee. For a Web application to use the Passport service the Passport SDK must be downloaded and installed in the Web server. This configuration entry in the Web application's Web.config file will enable Authentication through the Passport provider:

<system.web>

<authentication mode="Passport"/>

</system.web>

Asp.net authentication can be disabled by omitting the <authentication> configuration entry in the Web.config file or by listing the following entry in the same file:

<system.web>

    <authentication mode="None">

    </authentication>

</system.web>

Web applications can be configured painlessly through the Asp.net configuration snap-in that comes as an extension to the IIS configuration snap-in with the .Net Framework 2.0 as shown in figure 4:

 
 
Figure 4. The Asp.Net snap-in configuration Settings window in IIS

Implementing Authorization

Authorization is the process of verifying that users and applications have the appropriate set of privileges to resources. Once the resources that constitute the application, such as: files, folders, business objects, data on Databases etc., are identified authorization can be implemented using:

.Net Roles. Users are restricted access to code through Imperative and declarative Role Based Security demands. This means that a users membership to a role is checked by the runtime before a permission is given to call a method or run a piece of code. Applications run within the security context of purpose-built accounts that have the appropriate privileges to resources.

 

Figure 5. Web application Authorization architecture

File permissions. Access to files and folders is restricted through NTFS permissions.   Applications impersonate authenticated users or run as default fixed windows accounts to gain access to resources. Permissions for files and folders are configured through the Access Control List of the resource.

Authorization using IIS 6.0

The following permissions are configurable through IIS version 6.0:

Web access permissions. IIS allows us to configure access permissions for a Web site, Web directory or file. These access permissions do not need an authenticated user identity to be applied; permissions set at this level apply to all users regardless of authentication method or role membership. The configurable permissions are the following:

• Script source access: available when read or write options are enabled, it allows the users' request to read or write to a source code.
• Read: With this permission users have access to a Web site, Web directory or file.
• Write: This permission allows users to make changes to individual files, and  files in a Web site or Web directory.  
• Directory browsing: When this permission is enabled and a default start page for a Web site is not defined IIS serves the directory listing.

Figure 6. Access permissions in IIS 6.0

Execute permissions. These settings enable administrators to define whether scripts and executables are allowed to run in a Web site or Web directory. The following settings are configurable in this category:

• None: This setting prevents any scripts or executables from running.
• Scripts only: with this setting enabled server side scripts mapped to a script engine are allowed to run in the configured Web site or Web directory .
• Scripts and executables: this setting enables server side scripts mapped to a script engine and executable to run in the configured Web site or Web directory.

IIS 6.0 URL authorization
By configuring IIS 6.0 to work with Authorization Manager (Azman) in Microsoft Windows Server 2003 we can enable user access control to Web applications through URL authorization. This means that access requests to a specific URL in IIS version 6.0 can be restricted through .Net role membership of users.

Authorization in ASP.Net

ASP.Net provides the following configurable authorization methods:

File Authorization
This applies only to applications that are configured to use windows authentication. ASP.Net uses the FileAuthorizationModule class in the System.Web.Security namespace to check if authenticated users have necessary access permissions to a file. Access permissions, which are NTFS permissions, are controlled by configuring the ACL attached to a file or folder.

URL Authorization
This authorization method applies to any ASP.Net application regardless of which authentication method is configured to use. Authorization is performed through the URLAuthorizationModule class. Access permissions to resources are configured through entries in the Web.config files for the following resources:

Web application directories. Authorization is configured by allowing or denying access to all users, specific users or users who are members of a .NET role. The syntax used is the following:

<authorization>

  <{allow|deny} verbs users/>

  <{allow|deny} verbs roles/>

</authorization>  

Base on the above syntax, to allow access to all users we use the following entry:

<authorization>

    <allow users="*"/>

</authorization>

The following entry denies access to all users:

<authorization>

       <deny users="*"/>

</authorization>

To allow access only to specific users we use the following syntax:

<authorization>

             <allow users= "USER1, USER2, USER3"/>

             <deny users="?"/>

</authorization>

Allowing access only to users by role membership takes the following syntax:

<authorization>

   <allow roles="DomainName/Role_A"/>

   <allow roles="Role_A"/>

   <deny users="?"/>

</authorization>

We can also configure access to specific users and roles based on HTTP request verbs such as: HEAD, GET, POST, DEBUG by using the following entry:

<authorization>

   <allow verbs="HEAD, GET, POST, DEBUG" roles="DomainName/Role_A"/>

   <allow verbs="GET,POST" roles="Role_A"/>

   <deny users="?"/>

 </authorization>

Files and Folders. Access to specific files and folders is configured by specifying the path to the file or folder through the <location> element within the <configuration><configuration/> section. The syntax for the <location> element is the following:

<location allowOverride="true|false" path="resource_path"> </location>

In the above syntax the optional allowOverride attribute takes a boolean true or false value and it specifies whether the configuration is ovveridable by configurations in child Web.config files. The path in the other hand specifies the specific file or folder the configuration applies to. A missing path attribute denotes the current directory and all child directories.
     
To authorize access to specific users to a file named Specific.aspx, for example, we use the following configuration entry:

<configuration>

  <location allowOverride="false" path="Specific.aspx">

    <system.web>

      <authorization>

        <allow users="USER1,USER2,USER3"/>

      </authorization>

    </system.web>

  </location>

</configuration>

Multiple <location> sections can be defined in the same configuration file. The following example depicts such an instance:

<configuration>

  <location>

    <system.web>

<authentication mode="windows"/>

      <authorization>

        <deny users="?"/>

      </authorization>

    </system.web>

  </location>

 

  <location allowOverride="false" path="Specific.aspx">

    <system.web>

      <authorization>

        <allow users="USER1,USER2,USER3"/>

        <deny users="*"/>

      </authorization>

    </system.web>

  </location>

</configuration>

Web Communication security

The Secure Socket Layer (SSL) protocol is used whenever we need to secure communication between a Web server and a Web client. SSL consists of an ISAPI Filter that listens for client HTTPS (Secure HTTP) requests on TCP port 443. SSL secures communication through asymmetric and symmetric encryption of data. This is achieved by establishing a secure communication session between the client browser and the SSL enabled Web server through a series of handshakes that allow the exchange of public and session keys for data encryption. The following diagram illustrates such a scenario:

 

Figure 7. Sharing confidential Information using SSL

Configuring SSL on a Web Site

The first step in configuring SSL on a Web site is obtaining the x.509 certificate. This certificate can be obtained from a commercial Certificate Authority (CA) such as Verisign or Twathe, at a fee, for public Web sites or from an Enterprise CA for private Web sites. Alternatively, for testing purposes, we can use the certificate creation command line tool Makecert.exe to generate X.509 Certificates that we can use with SSL.

Installing the digital certificate
For each Web site that we require to share confidential information through SSL we need to obtain and install a digital certificate. To install the certificate for a Web site we use the IIS Certificate Wizard in IIS as shown in figure 8:

 

Figure 8. The IIS Certificate Wizard

To access the IIS Certificate Wizard :

1. Open the Internet Information Service Manager snap-in from the administrative tools folder; right-click the Web site of your choice and from the shown context menu click on properties.
2. Select the Directory Security tab from the displayed tabbed window and click on the Server Certificate button on the Secure communications panel.
3. The displayed wizard offers different options for installing a certificate; the same wizard is used for renewing and deleting an existing certificate.

Requiring a secure session

IIS allows us to configure secure communication for an entire Web site, for specific Web directories or for individual files. To enable access to a Web site, directory or file through secure channel:

1. Open the Internet Information Service Manager snap-in from the administrative tools folder; right-click the Web site, Web directory or file of your choice and from the shown context menu click on properties.
2. Select the Directory Security tab from the displayed tabbed window and click on the Edit button on the Secure communications panel; the Secure Communications window gets displayed.
3. Check the Require secure channel (SSL) check box on the Secure Communications window as shown below in figure 9.

Even though IIS allow us to require Secure Channel for an entire Web site in practice this is not advisable as it seriously hinders Web server performance. It is also not advisable for SSL enabled Web directories and files to contain image files as their ciphering is processor intensive.

The protocol used, at the client side, to access an SSL enabled Web resource is HTTPS ; for HTTP requests IIS serves the 403.4 - Forbidden: SSL required error message.

 

Figure 9. Requiring secure communication

The require 128-bit encryption optional check box, in figure 9 above, allows for increased security against cryptographic cracking by using a larger encryption key size.

Conclusion

Web application security involves implementing protective measures against potential threats that exploit exposed vulnerabilities at network, host and application levels. This article glanced at a small portion of the whole process by concentrating on authentication, authorization and data confidentiality.