What to Do

Define a boundary between public and restricted content in both the URL namespace and the filesystem namespace.

Why

Defining a boundary between public and restricted content simplifies the task of user authorization and is generally less prone to error. When the content is separated, server configuration can be used to automatically apply authorization rules without relying on the developer to explicitly add checks in the code.

When

Consider using this guideline when your application restricts access to specific resources. For instance, anonymous users are granted access to some, but not all of the application while authenticated users are granted access based on their role.

How

Defining the boundary requires:

1. Determine roles. Define the various types of user and their rights. Build a security policy that documents the rights required to access each page of your application.

2. Determine pages that should require SSL. This would include pages that transmit credentials, unprotected authentication cookies, or sensitive user information such as credit card or social security numbers. Such pages should be transmitted using SSL only.

   It should be noted that the Forms Authentication cookie is unprotected in the sense that it is vulnerable to HTTP Replay Attacks. As such, any page in a Forms Auth ASP.Net application that requires an authenticated user should only be accessible via SSL.

3. Structure the URL namespace. Structure the application URL namespace to first separate the pages that require SSL from those that do not. Then define separate directories according to the various roles defined for your application. For instance you might have the following directories under your application root:

   //secure/usr/secure/admin

4. Use absolute URLs to transition to or from the sensitive portion of the namespace: Relative links use the same protocol (HTTP or HTTPS) as the current page. This can result in broken links that point to pages within your application that require SSL. It can also lead to unnecessary use of SSL, which does have an associated performance hit.

   The fix for both of these issues is to use absolute URLs that explicitly specify the protocol instead of relative URLs. An example redirection using an absolute URL is shown below.

   private void btnLogon_Click(object sender, System.EventArgs e){
   // Form an absolute path using the server name and v-dir
   namestring serverName =
    HttpUtility.UrlEncode(Request.ServerVariables["SERVER_NAME"]);
   string vdirName = Request.ApplicationPath;
   Response.Redirect(https://+serverName+vdirName+"/Restricted/Login.aspx");}

5. Use URL Authorization Restrict Access: Use an <authorization> element to ensure that only authenticated users can access secure pages. Place this element beneath the closing </system.web> tag, as shown here.

   <!-- The secure folder is for authenticated and SSL access only. -->
   <location path="Secure" >
     <system.web>
       <authorization>
         <deny users="?" />
       </authorization>
     </system.web>
   </location>

   Additionally, the following configuration ensures that unauthenticated users are allowed to access pages in the application's root directory. Place this configuration in the main <system.web> element.

   <system.web>
     <!-- The virtual directory root folder contains general pages.
          Unauthenticated users can view them and they do not need
           to be secured with SSL. -->
     <authorization>
       <allow users="*" />
     </authorization>
   </system.web>

   Note: If you use this type of site structure, your application must not rely on the user's identity on the non-SSL pages. In the preceding configuration, no forms authentication ticket is sent for requests for non-SSL pages. As a result, the user is considered anonymous. This has implications for related features, such as personalization, that require the user name.

Problem Example

MyApp is a financial tool that generates reports based on sensitive data. It allows the user to upload the financial data and download the report. Since the application is small, all of its content is located within the same directory. The access control is enforced by the web application through checking the required permissions before a given call is executed.

Since both data and code is within the same directory, it may be possible for an attacker to gain access to the raw financial data.

Solution Example

MyApp is a financial tool that generates reports based on some sensitive data. It allows the user to upload the financial data and download the report. The application has a dedicated /data/ directory for the financial data. Access to contents within the /data/ directory is handled by the server hosting MyApp, making it much more difficult for an unauthorized user to gain access.

Adapted from Microsoft patterns & practices guidance.