Authorization

Examine how your application authorizes its users. Also examine how your application is authorized inside the database and how access to system-level resources is controlled. Authorization vulnerabilities can result in information disclosure, data tampering, and elevation of privileges. A defense in depth strategy is the key security principle that you can apply to the authorization strategy of your application. Table 5.3 highlights the most common authorization vulnerabilities.

Table 5.3: Common Authorization Vulnerabilities

Vulnerability	Implications
Reliance on a single gatekeeper	If the gatekeeper is bypassed or is improperly configured, a user gains unauthorized access.
Failing to lock down system resources against application identities	An attacker can coerce the application into accessing restricted system resources.
Failing to limit database access to specified stored procedures	An attacker mounts a SQL injection attack to retrieve, manipulate, or destroy data.
Inadequate separation of privileges	There is no accountability or ability to perform per user authorization.

Review the following questions to help validate the authorization strategy of your application design:

• How do you authorize end users?

• How do you authorize the application in the database?

• How do you restrict access to system-level resources?

How Do You Authorize End Users?

You should consider authorization from two perspectives at design time. First, consider end-user authorization. Which users can access which resources and perform which operations? Secondly, how do you prevent malicious users from using the application to access system level resources? Review the following questions to validate the authorization strategy of your application:

• Do you use a defense in depth strategy?

  Make sure that your design does not rely on a single gatekeeper to enforce access control. Consider what happens if this gatekeeper fails or if an attack manages to bypass it.

• Which gatekeepers are used?

  Options include IIS Web permissions, NTFS permissions, ASP.NET file authorization (which applies only with Windows authentication), URL authorization, and principal permission demands. If certain types are not used, make sure you know the reasons why not.

• Do you use a role-based approach?

  If so, how are the role lists maintained and how secure are the administration interfaces that are required to do this?

• Do your roles provide adequate privilege separation?

  Does your design provide the right degree of granularity so that the privileges that are associated with distinct user roles are adequately separated? Avoid situations where roles are granted elevated privileges just to satisfy the requirements of certain users. Consider adding new roles instead.

How Do You Authorize the Application in the Database?

The accounts that your application uses to connect to the database should have restricted capabilities that are sufficient for the application requirements, but no more.

• Does the application access the database using stored procedures?

  This is recommended because the login of the application can only be granted permissions to access the specified stored procedures. The login can be restricted from performing direct create/read/update/delete (CRUD) operations against the database.

  This benefits security, and performance and future maintainability also benefit.

For more information about database authorization approaches, see Chapter 14, "Building Secure Data Access."

How Do You Restrict Access to System-Level Resources?

When you design your application, consider the restrictions that will be placed on the application in terms of which system-level resources it can access. The application should only be granted access to the minimum required resources. This is a risk mitigation strategy that limits damage if an application is compromised. Consider the following issues:

• Does your design use code access security?

  Code access security provides a resource constraint model that can prevent code (and Web applications) from accessing specific types of system-level resources. When you use code access security, it inevitably influences your design. Identify whether or not you want to include code access security in your design plans, and then design accordingly by isolating and sandboxing privileged code and placing resource access code in its own separate assemblies.

• What identities does your application use?

  Your design should identify all of the identities that the application uses, including the process identity, and any impersonated identities, including anonymous Internet user accounts and service identities. The design should also indicate to which resources these identities require access.

  At deployment time, the appropriate ACLs can be configured on system-level resources to ensure that the identities of the application only have access to the resources they require.

For more information about designing for code access security, see Chapter 9, "Using Code Access Security with ASP.NET."