Bill's Security Tips

Home  [Bill's Home]

Web security

The following is a demonstration of the Web.config file in ASP.NET.

In this case the Web.config file in the folder contains the details of the login, such as three user names and passwords:

<authentication mode="Forms">
<forms name="testing" loginUrl="login.aspx" protection="All" timeout="30" path="/">
<credentials passwordFormat="Clear">
<user name="fred" password="pass1"/>
<user name="bert" password="pass2"/>
<user name="napier" password="pass"/>


<deny users="?"/>
<compilation debug="true"/></system.web>

and the code on the button event on the Login form is:

protected void Button1_Click1(object sender, EventArgs e)
// authenticate user: this sample authenticates
// against users in your app domain's web.config file
if (FormsAuthentication.Authenticate(this.userName.Value, UserPass.Value))
FormsAuthentication.RedirectFromLoginPage(userName.Value, PersistCookie.Checked);
// Response.Redirect("security01.aspx");
this.lbMessage.Text = "Invalid Login";


The Web.config file is used to defined the security of a Web service, which are XML-based so that the developer can change settings without an application rebuild. It is extensible so that new configuration parameters can be added, along with handlers which consume them. Also, each Web application folder can have its own Web.config file, which defines the security for the application folder and all its children (which inherit the configuration information from their parents). The security configuration is initially loaded when the application is first used, and then cached for all future accesses. Any subsequent changes are automatically detected, and applied. An important security factor is that the Web.config file cannot be viewed through a Web browser, as shown in Figure 1.


Figure 1 Security

An example Web.config file is:


<?xml version="1.0" encoding="utf-8" ?>




          Set compilation debug="true" to enable ASPX debugging. 

           Otherwise, setting this value to

          false will improve runtime performance of this application.








          Set customErrors mode="On" or "RemoteOnly" to enable custom error

           messages, "Off" to disable.

          Add <error> tags for each of the errors you want to handle.


          "On" Always display custom (friendly) messages.

          "Off" Always display detailed ASP.NET error information.

          "RemoteOnly" Display custom messages only to users not running







          This section sets the authentication policies of the application.

           Possible modes are "Windows", "Forms", "Passport" and "None"

          "None" No authentication is performed.

          "Windows" IIS performs authentication (Basic, Digest, or Integrated

           Windows) according to its settings for the application.

           Anonymous access must be disabled in IIS.

           "Forms" You provide a custom form (Web page) for users to enter their

           credentials, and then you authenticate them in your application. A

           user credential token is stored in a cookie.

           "Passport" Authentication is performed via a centralized

           authentication service provided by Microsoft that offers a single

           logon and core profile services for member sites.


    <authentication mode="Windows" />



          This section sets the authorization policies of the application. You

        can allow or deny access to application resources by user or role.  

           Wildcards: "*" mean everyone, "?" means anonymous(unauthenticated)




        <allow users="*" /> <!-- Allow all users -->

            <!--  <allow     users="[comma separated list of users]"

                             roles="[comma separated list of roles]"/>

                  <deny      users="[comma separated list of users]"

                             roles="[comma separated list of roles]"/>




          Application-level tracing enables trace log output for every page

           within an application. Set trace enabled="true" to enable application

           trace logging.  If pageOutput="true", the trace information will be

           displayed at the bottom of each page.  Otherwise, you can view the

           application trace log by browsing the "trace.axd" page from your web

           application root.










          By default ASP.NET uses cookies to identify which requests belong to a

           particular session. If cookies are not available, a session can be

           tracked by adding a session identifier to the URL. o disable cookies,

           set sessionState cookieless="true".





            sqlConnectionString="data source=;Trusted_Connection=yes"





          This section sets the globalization settings of the application.









The main configuration settings are contained within the <configuration> and </configuration> root tags. These include:


·         <authentication />. This tag is used to define the authentication policies of the application. It can be set to Windows, Forms, Passport, or None. For example <authentication mode="Windows" />.

·         <authorization />. This tag is used to define the authorization polices of the Web service. The users attribute can be set with wildcards such as * (for everyone and anonymous) and ? (unauthenticated) wildcards. An example is <allow users="*" />.

·         <compilation />. This tag is used to define the compilation language and whether it can be debugged. A true for the debugging option allows the PDB infromation to be inserted into the compiled page. An example is <compilation defaultLanguage="c#" debug="true" /> which sets the default language to C# and enables debugging for the Web service.

·         <customErrors />. This tag is used for custom error messages. To enable these, the On or RemoteOnly modes are used, otherwise it is Off. An example is <customErrors mode="RemoteOnly" />.

·         <globalization />. This tag is used to defined the globalization settings for a Web service. An example is  <globalization requestEncoding="utf-8" responseEncoding="utf-8" />.

·         <trace />. This tag is used to define application-level tracing of the Web service, and enables a trace log. A setting of True enable application trace logging. An example is <trace enabled="true" />.

11.1.1  Web service security

The two key elements for securing a Web service are defined by the <authentication /> and <authorization /> tags. For authentication, the authentication providers are defined, along with IIS authentication schemes. The authentication providers are:


·         Windows [Default]. With this method, the authentication process uses IIS to authentication the client. Once it has authenticates the client, it passes a security token to the Web service. For example:


     <authentication mode="Windows" />


·         Forms. With this method, the authentication mode uses an HTML log-in form to authenticate the client, which are then passed to the Web server for authentication. On a successful authentication, the server issues a cookie to the client, which is then used by the client to access the Web service. Any service which does not have a cookie, will redirect the user to a login screen. An example to define the form is:


<authentication mode="Forms">

    <forms name="Test" loginUrl="login.aspx" />



·         Passport. With this method, a centralized authentication service is used to define access, with a single logon and profile services for member sites. This is typically used to register sites with a single passport, and grants a site-specific key. This key is then used to encrypt and decrypt query strings between the site and the logon server. An example to define the password authentication is:


<authentication mode="Passport" />


·         None. This is used when there is no authentication, or where there us customized authentication. An example to define this is:


     <authentication mode="None" />


Along with this it is possible to define authentication for specific users and roles.

     For authorization, specific users and roles can be defined for given access, which is a specific allow or deny.


For example to disallow a user named “Fred” and allow the Administrator group:



    <deny users="Fred"/>

    <allow role="Administrator" />



Along with this a wildcard can be used for the roles and users. The * defines everyone and the ? for anonymous users, such as:



    <deny users="*" />

    <allow users="Fred" />