Análisis descriptivo después de la implementación de la ISO 9001:2015

One of the most basic security concerns is making sure that only the correct users are allowed to access the system. This is where the concepts of authentication and authoriza-tion come into play.

Authentication ensures that a user has supplied the proper credentials to access a sys-tem. Once a user logs in (typically by providing a username and password, or maybe some other token such as an SSH key or a cryptographic token) then they are authenticated.

Authorization takes place after authentication and involves making a decision as to whether a given user has permission to do something with the system, such as viewing a page or editing a record. When a user accesses a resource not available to others, they have been specifically authorized to do so.

8.1.1 Restricting access with the AuthorizeAttribute

ASP.NETMVC ships with a filter attribute called AuthorizeAttribute that provides a simple way to implement authorization rules out of the box. Used in conjunction with an authentication scheme, this attribute can be used to ensure that only certain users can access particular controller actions.

By default, new ASP.NETMVC projects created with the Internet Application proj-ect template use the forms authentication scheme to enable authentication, which is defined in the system.web/authentication section of the web.config:

<authentication mode="Forms">

<forms loginUrl="~/Account/LogOn" timeout="2880" />

</authentication>

With forms authentication enabled, if the user attempts to access an authorized resource, they’ll be redirected to the loginUrl in order to enter a username and password.

With authentication enabled, we can apply the AuthorizeAttribute to controller actions (or even entire controllers) to restrict access to them. If the user isn’t permitted to access the action, the AuthorizeAttribute will transmit an HTTP status code of 401

Windows authentication

As an alternative to forms authentication, ASP.NET also supports Windows authenti-cation, which can be enabled by changing <authentication mode="Forms"> to

<authentication mode="Windows"> in the web.config.

Windows authentication will attempt to authenticate the user using their Windows login credentials, and it’s best suited to intranet applications where the user is logged on to the same domain in which the application resides. In fact, this is the default authentication scheme for ASP.NET MVC’s Intranet Application project template.

Unauthorized to the browser, indicating that the request has been refused. Applica-tions using forms authentication will then redirect the browser to the login page, and users may only proceed once they have been authenticated.

The simplest use of AuthorizeAttribute only requires that the current user be authenticated:

[Authorize]

public ActionResult About() {

return View();

}

Unauthenticated users will be prevented from accessing this action, but any authenti-cated user will be allowed access.

To restrict an action further, we can specify users or roles that AuthorizeAttribute requires. These roles or users are passed to the attribute using a comma-delimited list of strings containing either the usernames or the roles allowed:

[Authorize(Users = "admin")]

public ActionResult Admins() {

return View();

}

In this case, only the user with the username “admin” will be allowed to access this action.

Hard-coding a username like this may be too explicit—users come and go, and the duties of a given user may change during their time using the application. Instead of requiring a specific user, it usually makes sense to require a role:

[Authorize(Roles = "admins, developers")]

public ActionResult Developers() {

return View();

}

Access to the Developers action will only be allowed to users in the admins or developers roles—all other users (authenticated or not) will be issued a 401 response code and, using ASP.NET’s forms authentication, will be redirected to the login page.

Role-based authentication

Role-based authentication can require some additional configuration depending on which authentication scheme you’re using.

If you’re using Windows authentication, the roles will automatically be looked up from your Active Directory group membership. However, if you’re using forms authentication, you’ll likely need to use a membership provider (which can be configured in the web.config) to specify how user information (such as roles) should be looked up and stored.

The default Intranet Application project template for ASP.NET MVC will use a SQL Express database to store role membership.

Now that you’ve seen a few examples of how AuthorizeAttribute is used, let’s talk about how it works.

8.1.2 AuthorizeAttribute—how it works

Internally, the AuthorizeAttribute is implemented as an IAuthorizationFilter that performs several checks before deciding whether or not the user is authorized to access the current controller action. The decision process made by the attribute is shown in figure 8.1.

Current user authencated?

User not authorized Has a list of usernames

been specified?

Is the current user’s name in the list?

Has a list of roles been specified?

User is authorized

Is the user a member of one of the roles?

No No

Yes

No Yes

Yes

No

Yes

Yes No

Figure 8.1 The AuthorizeAttribute checks whether the user is authenticated, if the user is on a username whitelist, and what the user’s role membership is before deciding if a user is authorized to view the requested action.

Because the AuthorizeAttribute implements the IAuthorizationFilter interface, it must contain a method called OnAuthorization that receives a reference to an AuthorizationContext that represents the current request.

Once this method is invoked by the framework, the attribute retrieves a refer-ence to the current IPrincipal that corresponds to the user making the current request. If the user has not yet been authenticated, it cancels the request by setting the AuthorizationContext’s Result property to an HttpUnauthorizedResult. This prevents the controller action from being invoked and sends an HTTP 401 to the browser, which in turn causes the appropriate logon prompt to be displayed.

When Users or Roles is specified, the AuthorizeAttribute ensures that the cur-rent user’s username is in the allowed usernames or that the user is a member of one of the granted roles. Alternatively, if neither users nor roles are specified, the user is allowed to proceed.

In addition to these checks, the AuthorizeAttribute also ensures that output caching is disabled for any actions to which the attribute has been applied. This ensures that an unauthorized user doesn’t end up seeing the cached version of a page that was previously accessed by an authorized user.

The AuthorizeAttribute can be used in a few ways:

■ If AuthorizeAttribute is applied to a controller, it’s applied to every action in that controller.

■ If multiple AuthorizeAttributes are applied to an action, all checks occur and the user must be authorized by all of them.

There are several other IAuthorizationFilter implementations in ASP.NETMVC; all are used to short-circuit the normal response to protect against undesired requests.

Chapter 16 will cover filters in depth, but let’s look at five filters that deal specifically with security:

■ AuthorizeAttribute—You’ve already learned about this one

■ ChildActionOnlyAttribute—Ensures that an action method can only be invoked from another action (typically from a view using Html.Action)—it can’t be invoked directly

■ RequireHttpsAttribute—Ensures that an action can only be accessed through a secure connection

■ ValidateAntiForgeryTokenAttribute—Ensures that a valid anti-forgery token has been specified (you’ll see more about this in section 8.2)

■ ValidateInputAttribute—Indicates whether or not ASP.NET should validate user input for potentially unsafe contents

You’ve seen how AuthorizeAttribute can help manage authentication and authori-zation, so now let’s turn our attention to other, more insidious attack vectors.

Although authentication and authorization checks prevent hapless visitors from accessing secure areas, you still must protect your application from hackers and thieves who attempt to exploit vulnerabilities inherent in web applications. In the rest

of this chapter, we’ll look at several common attacks and vulnerabilities and at how you can defend against them.