OWASP Top 10 Series: Broken Access Control - Part 1

This is the first in a series of blog posts about the OWASP Top 10. I’m writing this as much for me as for anyone else who stumbles upon this blog. It’s always a good idea to keep security top of mind when developing software. So, I decided to write a series on the OWASP Top 10 security vulnerabilities. You can find the OWASP Top 10 List here .

This is part 1 of the series, which will will focus on the #1 vulnerability as of 2021: Broken Access Control . I would highly recommend reading the entire OWASP page to gain an understanding of the nature of the vulnerability.

The OWASP page for A01 Broken Access Control describes the vulnerability as follows:

“Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user’s limits.” (https://owasp.org/Top10/A01_2021-Broken_Access_Control/#description )

There are several examples listed on the owasp.org page for the vulnerability. Today, we’ll take a look at a basic example using a simple ASP.NET Core Web application.

I’ve used Visual Studio Community 2022 to create a simple ASP.NET Core Web application with the following, default structure.

We can now run the app through Visual Studio and view it in the browser.

So far, so good. Our application is running and we can navigate to the homepage and view it in a browser. Great! Now, let’s add an Admin page in a special Admin area of the site.

Ok, let’s run our web app again. We can see that the home page still looks the same:

Ok, so we have our Admin page added and it isn’t visible from the home page. Most users won’t know it’s there, so nothing to worry about, right? Well, of course not. We don’t have any access controls whatsoever added to the site yet. So, there’s nothing stopping someone with malicious intent from accessing the Admin area of the site. All they have to do is just add “Admin” to the end of the site URL in the browser, and they have full access to the admin page.

That’s not good at all. If this were a real site, the attacker would have gained access to the admin features of the site.

So, what can we do to prevent this type of security flaw? Let’s reference the OWASP resource again. Under the “How to Prevent” secion, we see the following statement:

“Access control is only effective in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata.” (https://owasp.org/Top10/A01_2021-Broken_Access_Control/#how-to-prevent )

What this means is that, in order for access control to be truly effective, we have to put the control somewhere the attacker can’t easily reach. That means on the server. Or the “backend” if you prefer, since some cloud applications can be considered “serverless”. There’s technically still always a server or servers involved, even with “serverless” technologies, but I digress. We just always want to put access controls on the backend.

We saw in our example how easy it was to just manually add “Admin” to the end of the URL and gain access to the admin page of the site. So, let’s fix that.

I’ve added Identity capabilities to the simple ASP.NET Core Web application. I don’t have any of the backend of the identity features in place, but what this does give us is just enough access control features to add the Authorize attribute to the Admin page class.

Now, let’s start up the application and try typing “Admin” into the URL again:

This time, the user is not authenticated, so instead of being allowed to navigate to the admin page, the user is redirected to the Login page.

There you have the basic idea behind the broken access control security vulnerability and one step that can be taken to fix the security flaw. This is, of course, an extremely contrived example, just for demonstration purposes. Who wouldn’t lock down the admin features of their site, right? Think about the nature of the vulnerability though. Think about everything that might be getting passed as parameters in the query strings of your web application. Is your application safe from parameter tampering? What happens if someone starts changing the parameters in your URLs? Is your application secure enough to prevent an attacker from simply changing the parameter values? It’s worth mentioning that POST requests are just as vulnerable to these types of attacks at GET requests are.

This problem also extends beyond just authentication and authorization to application features. We need to add safeguards at the data model too. We’ll look at that in my upcoming post: “OWASP Top 10 Series: Broken Access Control - Part 2”.