What Filter Requires A User To Be Logged In And Denies Access To Anonymous Users?

Read Time: 12 mins Languages:

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

On an internal corporate intranet, at that place may exist pages containing sensitive reports and information that should only be seen by specific departments or senior managers and non every employee of the company. In well-nigh cases, only certain administrators would have full access to modify setting of the web site with other users peradventure beingness granted less alter ability. In all these cases, we demand to restrict these options for almost users while assuasive them to others. Authorization lets you ensure a user can access everything they need on a spider web site and perform desired tasks, but no more.

For example, on a eastward-commerce site, yous would desire customers to browse products, add products to a cart, and order those products. Once ordered they should be able to track their social club, and perchance modify the club before aircraft. However you also might want new customers to speak to a client service agent before allowing them to change an order. In no instance would y'all want any customer able to view, modify, or cancel orders of other customers.

Every bit a spider web developer, an of import security aspect of a site them comes in ensuring that users do not take access to deportment they should not perform. The consequences of not protecting information technology can be serious.

Let'due south look at an overview of authorisation and how to implement it in ASP.Cyberspace.

What is Authorization?

Giving unique accounts to individuals allows us identify who accesses our spider 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 Neb," when I log in.

Most commerce sites can save my credit card, address, and other information I need to place an society. 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 gild from them. Web sites can also take this further using my history and habits to suggest related products that I might exist interested in or similar manufactures that I might bask reading. I might also be able to fix preferences in colors, preferred categories, or other settings the site tin can apply.

That may provide helpful benefits to the site's users, but say-so 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 power to access dissimilar sections of a web site, exist able to access data, or be able to make changes to information.

This utilise of the identity will be the principal focus of this article as we look at methods of protecting portions of your spider web site, focusing on ASP.Net.

Decision-making 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 equally the number of users grow. Apace, the take a 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 perhaps requiring manual updates to hundreds or thousands of accounts.

For this reason. users are unremarkably grouped together with those having similar rights or needs. The groups are oftentimes 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.

Yous 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 existence in more than one group at the aforementioned time every bit 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 instance take a user that is a fellow member of 2 groups. One grouping allows the user to create a new blog mail service and the 2nd denies this ability to the user. The web site must handle this conflict in a consistent and anticipated manner. In nigh every example, the best practise allows no rights by default, adds simply specifically listed rights, and to permit deny override other settings. In that case the group denying the right would override the grouping denying admission.

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 2nd you might have groups for "create article," "edit article," "delete commodity," "publish article." This method gives more flexibility in exchange for managing more than groups.

Protecting Pages in ASP.NET Spider web Sites

Your kickoff business should exist protecting the web pages on your site. I focus on ASP.Cyberspace for the specifics in this article, but most web frameworks apply similar concepts though not the same files and commands. Depending on the system at that place are three approaches to secure and ASP.Net spider web site:

ASP.NET routing
ASP.Net web forms
ASP.NET MVC

Protecting Web Forms ASP.Cyberspace Sites

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

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

The location chemical element of this XML snippet defines the path to the file, folder, or route that nosotros're dealing with. Here we're specifying this applies to the adminhome.aspx page specified. This could likewise requite a binder on the site and would use 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 chemical element contains the settings used to gear 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 club until a match is found. The permit chemical element specifies roles and/or users who volition exist granted admission to the resource. Similarly the deny chemical element specifies users and roles that will not be allowed to admission the resource.

In this example, the <allow admin role/> dominion will exist checked first. If the user is in the admin role, then they are granted access and nix more needs to exist checked. If the user isn't in that part, then ASP.NET continues to the next dominion. 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. Nosotros saw the * user higher up, 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 exist mixed in the same rule such every bit:

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

Protecting ASP.NET MVC Sites

ASP.Internet MVC focuses on controllers and deportment on those controllers instead of files. This changes the method of securing access to an ASP.Cyberspace MVC site. By default, all actions and controllers can be accessed past all users, just as in WebForms. You even so apply the same office and user attributes, but no longer set these within the spider web.config file.

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

[Qualify(Roles = "siteadmin")]   public course AdminController : Controller   { ...

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

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

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

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

Managing Pages Used by Multiple Roles

Once you take protected admission 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 simply a unmarried part should access or run into them at all and those users have the ability to do annihilation provided on the page.

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

In that location is no value in showing the link to the administration area to a user without admin access or a "Refund Guild" button to a user who doesn't have that ability. Even if the push or link is inactive, it provides potential information to an attacker. Information technology tin can also cause confusion for the site'south legitimate users. If the link is active, only then requests a login, yous've provided an attacker with a page to target, and over again peradventure dislocated 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 activeness. If both admins and anonymous users tin access a page, you should validate the user is in an admin function before performing actions only the admin role can do. The user could attempt an action they should non exist able to perform either through clicking of a link that shouldn't have been shown, experimentation, or a deliberate hacking effort.

Once again e'er presume the least privilege and require explicit granting through group membership, roles, or other elements before performing secured functions.

As well take care if the action is passed as a parameter to a folio. Have a URL that completes an guild in the form of UpdateOrder.aspx?order=33&action=delete. Image a hacker tried accessing other deportment at random until discovering UpdateOrder.aspx?order=33&action=refund would credit the charge for the social club back without canceling the guild. Never rely of a link being hidden or non shown as the sole defence force mechanism confronting unauthorized deportment.

Security Aspects of User Sessions

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

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

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

As well exist enlightened of the gamble of session hijacking. Near spider web frameworks use a unique identifier for the user in one case authenticated, usually stored in a cookie. If this cookie isn't protected in some way then anyone who tin view the user'southward traffic tin employ that cookie to laissez passer themselves off as the original user.

The FireSheep Firefox extension demonstrated this and provided a uncomplicated method to perform this interception and impersonation. You tin 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 but sent when the page is accessed by SSL.

In ASP.Net, yous 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 lot tin as well set the <httpCookies requireSSL="true" /> item in your web.config to set all cookies to by SSL only by default.

Decision

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

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

For pages accessed by users in multiple roles yous 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, y'all should too have care to ensure that others cannot impersonate a user with more rights.

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

Did you find this mail useful?

I started with an Atari 400 figurer, which inspired me to pursue a degree in Computer science. I worked in networks and web development most of my professional career and currently manage the computer network and figurer security for a college in Tennessee. I primarily develop in ASP.NET, merely also work with PHP and Rail on occasion.