![Broken Access Control
Applying the Policy:
Once the policy has been registered, you can apply the policy in your controller or the controller’s
action methods. If you were to apply the policy at the controller level, here’s how you would need to
specify the policy.
[Authorize(Policy = “AtLeast21”)]
public class SecurityController: Controller
{
//Action methods
}
As you can see, instead of specifying roles in the [Authorize] attribute, you can specify the policy that
you would like to apply. To apply a policy to an action method, you can take advantage of the Policy
property of the Authorize attribute as shown in the code.](https://image.slidesharecdn.com/securecodingauthorization-201123075904/85/Defending-broken-access-control-in-NET-12-320.jpg)
![Broken Access Control
You can then apply this policy at the controller level on the AuthorizeAttribute attribute as shown
below.
[Authorize(Policy = "EmployeeOnly")]
public IActionResult SomeMethod()
{
//Write your code here
}](https://image.slidesharecdn.com/securecodingauthorization-201123075904/85/Defending-broken-access-control-in-NET-14-320.jpg)
Defending broken access control in .NET
- 1. Defending Broken Access Control in .NET By Supriya Golla Senior Cyber Security Analyst
- 2. What will be covered? Broken Access control Difference between Authentication and Authorization Example for Authentication and Authorization Improper Authorization Consequences Access control policy types Implementing policy in .NET Prevention of IDOR Remediation for Authorization References
- 3. Broken Access Control Access control, sometimes called authorization, is how a web application grants access to content and functions to some users and not others. Authorization is a process by which a server determines if the client has permission to use a resource or access a file. • These checks are performed after authentication and govern what ‘authorized’ users are allowed to do. • Access control sounds like a simple problem but is insidiously difficult to implement correctly. • A web application’s access control model is closely tied to the content and functions that the site provides. • Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.
- 4. What is Authentication and Authorization: What You Know What You Have What You ARE Authorization is the process to determine whether the authenticated user has access to the specific resources. Broken Access Control
- 5. Broken Access Control Authentication and Authorization Difference Using Example: • Authentication should be used whenever you want to know exactly who is using or viewing your site. Web-login is University’s primary method of authentication. Students/Professor/Administrator need to authenticate to view the university information. • Authorization should be used whenever you want to control viewer access of certain pages. For example, University students are not authorized to view certain web pages dedicated to professors and administration. The authorization requirements for a site are typically defined in a website’s web.config file. Authorization verifies your rights to grant you access to resources such as information, databases, files, etc. Authorization usually comes after authentication which confirms your privileges to perform. In simple terms, it’s like giving someone official permission to do something or anything.
- 6. Broken Access Control Improper Authorization Consequences: • Privilege Escalation • Path Traversal • Sensitive data exposure • Presence of Insecure Direct Object Reference (IDOR) vulnerabilities
- 7. Broken Access Control Authorization is designed based on access control policy • Role Base Access Control (RBAC): In RBAC, access decisions are based on an individual's roles and responsibilities within the organization or user base. For instance, in a medical organization, the different roles of users may include those such as a doctor, nurse, attendant, patients, etc. Obviously, these members require different levels of access in order to perform their functions, but also the types of web transactions and their allowed context vary greatly depending on the security policy and any relevant regulations (HIPAA, Gramm-Leach-Bliley, etc.). • Discretionary Access Control (DAC): DAC is a means of restricting access to information based on the identity of users and/or membership in certain groups. Access decisions are typically based on the authorizations granted to a user based on the credentials he presented at the time of authentication (username, password, hardware/software token, etc.). • Mandatory Access Control (MAC): MAC ensures that the enforcement of organizational security policy does not rely on voluntary web application user compliance. MAC secures information by assigning sensitivity labels on information and comparing this to the level of sensitivity a user is operating at. MAC is usually appropriate for extremely secure systems, including multilevel secure military applications or mission-critical data applications. • Permission Based Access Control: The key concept in Permission Based Access Control is the abstraction of application actions into a set of permissions. A permission may be represented simply as a string-based name, for example, "READ". Access decisions are made by checking if the current user has the permission associated with the requested application action.
- 8. Broken Access Control Authorization implementation in ASP.Net: ASP.NET Core authorization provides the following different models: • Simple authorization • Role-based authorization • Policy-based authorization • Claims Based Authorization
- 9. Broken Access Control Simple authorization: Authorization in MVC is controlled through the “AuthorizeAttribute” attribute and its various parameters. At its simplest, applying the “AuthorizeAttribute” attribute to a controller or action limits access to the controller or action to any authenticated user. • Authorization components, including the AuthorizeAttribute and AllowAnonymousAttribute attributes, are found in the Microsoft.AspNetCore.Authorization namespace. • This would allow only authenticated users to the AccountController, except for the Login action, which is accessible by everyone, regardless of their authenticated or unauthenticated / anonymous status.
- 10. Broken Access Control Role-based authorization: Role-based authorization is a declarative way to restrict access to resources. You can specify the roles that the current user must be a member of to access a specified resource. The Authorize attribute enables you to restrict access to resources based on roles. It is a declarative attribute that can be applied to a controller or an action method. In the above code snippet members of the Administrator role or the PowerUser role can access the controller and the SetTime action
- 11. Broken Access Control Policy-based authorization: A policy-based security model decouples authorization and application logic and provides a flexible, reusable and extensible security model in ASP.NET Core. The policy-based security model is centered on three main concepts. These include policies, requirements, and handlers. An authorization policy consists of one or more requirements. It's registered as part of the authorization service configuration, in the Startup.ConfigureServices method: In the above example, an "AtLeast21" policy is created. It has a single requirement—that of a minimum age, which is supplied as a parameter to the requirement. An authorization handler is responsible for the evaluation of a requirement's properties. The authorization handler evaluates the requirements against a provided AuthorizationHandlerContext to determine if access is allowed.
- 12. Broken Access Control Applying the Policy: Once the policy has been registered, you can apply the policy in your controller or the controller’s action methods. If you were to apply the policy at the controller level, here’s how you would need to specify the policy. [Authorize(Policy = “AtLeast21”)] public class SecurityController: Controller { //Action methods } As you can see, instead of specifying roles in the [Authorize] attribute, you can specify the policy that you would like to apply. To apply a policy to an action method, you can take advantage of the Policy property of the Authorize attribute as shown in the code.
- 13. Broken Access Control Claims Based Authorization: Claims based authorization, at its simplest, checks the value of a claim and allows access to a resource based upon that value. For example if you want access to a night club the authorization process might be: The door security officer would evaluate the value of your date of birth claim and whether they trust the issuer (the driving license authority) before granting you access. First you need to build and register the policy. This takes place as part of the Authorization service configuration, which normally takes part in ConfigureServices() in your Startup.cs file. In this case the EmployeeOnly policy checks for the presence of an EmployeeNumber claim on the current identity. You then apply the policy using the Policy property on the AuthorizeAttribute attribute to specify the policy name;
- 14. Broken Access Control You can then apply this policy at the controller level on the AuthorizeAttribute attribute as shown below. [Authorize(Policy = "EmployeeOnly")] public IActionResult SomeMethod() { //Write your code here }
- 15. Broken Access Control Prevention to IDOR: When you have a resource (object) which can be accessed by a reference (in the sample below this is the id) then you need to ensure that the user is intended to be there.
- 16. Broken Access Control Remediation: Invalidate tokens and cookies after logout. Forced login/logout after a password change. Server-side resource restriction e.g. directories. Restrict access to all resources basis roles. Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record. Disable web server directory listing and ensure file metadata (e.g. .git) and backup files are not present within web roots. Log access control failures, alert admins when appropriate (e.g. repeated failures). Rate limit API and controller access to minimize the harm from automated attack tooling. JWT tokens should be invalidated on the server after logout. Developers and QA staff should include functional access control unit and integration tests.
- 17. References: https://owasp.org/www-project-top- ten/OWASP_Top_Ten_2017/Top_10-2017_A5-Broken_Access_Control https://cheatsheetseries.owasp.org/cheatsheets/Access_Control_Che at_Sheet.html https://docs.microsoft.com/en- us/aspnet/core/security/authorization/introduction?view=aspnetcore- 3.1 https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authoriz ation_Cheat_Sheet.html
- 18. Thank You!!!
Editor's Notes
- #4: Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.