Giving each web site user an individual account allows you to uniquely identify users of your web site and validate that they are who they claim to be. Knowing a user’s identity allows the web site to change to reflect the needs and interests of each user. As web sites normally contain multiple sections designed for users in different roles from general public to high level system administrators, you can also use this identification to manage access to the different resources on the web site that each users needs.

On an internal corporate intranet, there may be pages containing sensitive reports and data that should only be seen by specific departments or senior managers and not every employee of the company. In most cases, only certain administrators would have full access to change setting of the web site with other users perhaps being granted less change ability. In all these cases, we need to restrict these options for most users while allowing them to others. Authorization lets you ensure a user can access everything they need on a web site and perform desired tasks, but no more.

For example, on a e-commerce site, you would want customers to browse products, add products to a cart, and order those products. Once ordered they should be able to track their order, and possibly modify the order before shipping. However you also might want new customers to speak to a customer service agent before allowing them to change an order. In no case would you want any customer able to view, change, or cancel orders of other customers.

As a web developer, an important security aspect of a site them comes in ensuring that users do not have access to actions they should not perform. The consequences of not protecting it can be serious. 

Let’s look at an overview of authorization and how to implement it in ASP.NET.

What is Authorization?

Giving unique accounts to individuals allows us identify who accesses our web site. Trusting the site knows who an individual is authentication and was previously discussed.

Once we know the user, we can tailor the site for that user, and customize the web site to reflect information that we know about the user. This can vary from simple aspects such as a web site stating, “Hi Bill,” when I log in. 

Most commerce sites can save my credit card, address, and other information I need to place an order. This means I don’t need to enter the same information each time, which makes it easier for me to place and order and therefore more likely to order from them. Web sites can also take this further using my history and habits to suggest related products that I might be interested in or similar articles that I might enjoy reading. I might also be able to set preferences in colors, preferred categories, or other settings the site can use.

That may provide helpful benefits to the site’s users, but authorization focuses on using the unique identity of the user to to determine what actions the user can perform. It lets the web site determine if a user should have the ability to access different sections of a web site, be able to access data, or be able to make changes to data. 

This use of the identity will be the primary focus of this article as we look at methods of protecting portions of your web site, focusing on ASP.NET.

Controlling Access Using Groups and Roles

While it is possible to provide unique rights and responsibilities for each user to a web site, this quickly becomes unmanageable as the number of users grow. Quickly, the chance of mistakes increases with each new user needing custom setup. If any change in the site required new rights or settings, then each user account would need to be updated possibly requiring manual updates to hundreds or thousands of accounts.

For this reason. users are normally grouped together with those having similar rights or needs. The groups are often sometimes referred to as roles since the role of the user in a site often defines the groups used. For each group the site administrator can define access and restrictions within the web application. 

You then assign users to these groups and the user will take on the rights and restrictions assigned to that group. The rights can be taken away simply by removing the user from the group. Most systems support a user being in more than one group at the same time as a user may have multiple roles.

Users in multiple roles requires a method of dealing with cases where the settings of two groups conflict. For example take a user that is a member of two groups. One group allows the user to create a new blog post and the second denies this ability to the user. The web site must handle this conflict in a consistent and predictable way. In almost every case, the best practice allows no rights by default, adds only specifically listed rights, and to let deny override other settings. In that case the group denying the right would override the group denying access.

A modification of splitting users into groups based around roles would be to create groups based on the activity. In the first case, you might have “authors,” “editors,” “publishers,” etc. In the second you might have groups for “create article,” “edit article,” “delete article,” “publish article.” This method gives more flexibility in exchange for managing more groups.

Protecting Pages in ASP.NET Web Sites

Your first concern should be protecting the web pages on your site. I focus on ASP.NET for the specifics in this article, but most web frameworks use similar concepts though not the same files and commands. Depending on the system there are three approaches to secure and ASP.NET web site: 

1. ASP.NET routing
2. ASP.NET web forms
3. ASP.NET MVC

Protecting Web Forms ASP.NET Sites

ASP.NET routing and ASP.NET web forms utilize the web.config file to secure web page access. A basic configuration to secure access a resource on a web site would look similar to the following:

<configuration>  
   <location path="adminhome.aspx">  
      <system.web>  
         <authorization>  
           <allow roles="admin"/>  
           <deny users="*"/>  
         </authorization>  
      </system.web>  
   </location>  
</configuration>

The location element of this XML snippet defines the path to the file, folder, or route that we’re dealing with. Here we’re specifying this applies to the adminhome.aspx page specified. This could also give a folder on the site and would apply to that folder. If you specify no path attribute the configuration settings apply to the current directory of this web.config file and all child directories.

The authorization element contains the settings used to set up who has access and who is denied access to the object specified in the path element. The rules are checked starting with the first rule in order until a match is found. The allow element specifies roles and/or users who will be granted access to the resource. Similarly the deny element specifies users and roles that will not be allowed to access the resource.

In this example, the <allow admin role/> rule will be checked first. If the user is in the admin role, then they are granted access and nothing more needs to be checked. If the user isn’t in that role, then ASP.NET continues to the next rule. Here, that <deny users="*"/> rule would deny all users. This example therefore would allow users in the admin role access. All other users would be denied access.

There are a few special characters to specify common groups. We saw the * user above, which specifies all users. The ? user refers to anonymous users, that is any user that has not currently logged in. Multiple users and roles can be specified separating them with a comma. Users and roles can be mixed in the same rule such as:

<allow roles="siteadmin,editors" users="bob">

Protecting ASP.NET MVC Sites

ASP.NET MVC focuses on controllers and actions on those controllers instead of files. This changes the method of securing access to an ASP.NET MVC site. By default, all actions and controllers can be accessed by all users, just as in WebForms. You still use the same role and user attributes, but no longer set these within the web.config file. 

Instead you apply an [Authorize] attribute to your controllers and actions directly. As an example if you have an AdminController that should only be accessed by members of the admin role, you can do that by adding the users and/or roles to the tag. Note this acts as a allow with an implied deny for all not specifically allowed.

[Authorize(Roles = "siteadmin")]  
public class AdminController : Controller  
{
...

The same * and ? options for all users and anonymous users are also available for this attribute. You can apply the rules specifically to an individual action on the controller to restrict only those actions. Attributes specified on an action will override those specified for the entire controller.

[Authorize(Roles = "siteadmin")]  
public ActionResult AdminView()  
{
...

If you do not specify any roles or users with the [Authorize] attribute, then it will allow any authenticated user to log in. This allows you to only allow access to actions or controllers for users that are specifically logged into the system. 

ASP.NET 4 added an [AllowAnonymous] attribute that allows you to override this for an action within a controller. You can find it used in any new default ASP.NET MVC Internet Projects to manage access to the AccountController controller.

Managing Pages Used by Multiple Roles

Once you have protected access to the folders, files, actions, and routes on your site, you next need to look at ensuring proper access within server code itself. Some pages are simple to secure in that only a single role should access or see them at all and those users have the ability to do anything provided on the page.

For many pages, different roles may access the same page, but have different rights and abilities once on the page. In these cases, take care not to show links to actions, URLs, or files the current user does not have the right to access. 

There is no value in showing the link to the administration area to a user without admin access or a "Refund Order" button to a user who doesn’t have that ability. Even if the button or link is inactive, it provides potential information to an attacker. It can also cause confusion for the site’s legitimate users. If the link is active, but then requests a login, you’ve provided an attacker with a page to target, and again possibly confused a legitimate user of the site.

Server code behind a page accessed by users in multiple roles should always validate the rights of the user before performing an action. If both admins and anonymous users can access a page, you should validate the user is in an admin role before performing actions only the admin role can do. The user could attempt an action they should not be able to perform either through clicking of a link that shouldn’t have been shown, experimentation, or a deliberate hacking attempt. 

Again always assume the least privilege and require explicit granting through group membership, roles, or other elements before performing secured functions.

Also take care if the action is passed as a parameter to a page. Take a URL that completes an order in the form of UpdateOrder.aspx?order=33&action=delete. Image a hacker tried accessing other actions at random until discovering UpdateOrder.aspx?order=33&action=refund would credit the charge for the order back without canceling the order. Never rely of a link being hidden or not shown as the sole defense mechanism against unauthorized actions.

Security Aspects of User Sessions

While the authentication aspect differs from the authorization element discussed here, they are interrelated. First, at the login session usually are set with a timeout in the configuration. In ASP.NET, this is set in the web.config file in the <authentication> section.

<forms loginUrl="~/Auth/LogOn.aspx" timeout="30" slidingExpiration="true" />

This would set the timeout for a user to 30 minutes. The slidingExpiration attribute determines if a request resets this counter back to zero. With it set false, then a user would be required to log back in every thirty minutes even if actively using the site that entire time.

Also be aware of the risk of session hijacking. Most web frameworks use a unique identifier for the user once authenticated, normally stored in a cookie. If this cookie isn’t protected in some way then anyone who can view the user’s traffic can use that cookie to pass themselves off as the original user. 

The FireSheep Firefox extension demonstrated this and provided a simple method to perform this interception and impersonation. You can only prevent this by using SSL encryption of the entire web browser session or at least protecting the cookie containing the data with SSL encryption.

You can protect against this using SSL only cookies for the authentication token representing the logged in user. This ensures the cookie is only sent when the page is accessed by SSL. 

In ASP.NET, you can enforce this by setting the requireSSL="true" attribute on the <forms/> portion of the web.config when using forms authentication. For greater protection, you can also set the <httpCookies requireSSL="true" /> item in your web.config to set all cookies to by SSL only by default.

Conclusion

The use of web sites by many users with different needs and responsibilities requires methods to prevent unauthorized access to sensitive data and functionality. You can use the unique identity of a user to determine which rights the user has and enforce those rights within your web application.

You begin by ensuring that pages and actions within your web application are restricted to only those users who should have the ability to work with them. 

For pages accessed by users in multiple roles you should take care to validate the user has the right to perform requested actions before performing them. Since identity of the user defines their access, you should also take care to ensure that others cannot impersonate a user with more rights. 

Combining these steps will go a long way toward protecting your web application.