Common Permission Mistakes

[00:00:00]
>> Kyle Cook: So now is where we finally kind of start to get to dive into making some of these changes, but first we need to actually talk about what the common mistakes are that we have inside of our codebase. Some of the main issues you find in these more simple permission systems is that you have checks scattered throughout your entire codebase that all check the exact same thing. In our current implementation, for example, we have checks for permissions inside of our different pages, we have checks inside of our data access layer, we even have checks directly inside some of our different components, and they're all checking the exact same thing in 345 different places.

[00:00:29]
So this is a really easy place for bugs to come in. If we update in one place and we fail to update in another place, we're going to have a bug because it's only working correctly in one location. This kind of leads into the next point. You have missing permission checks. It's very easy when you're ad hoc doing your permissions to forget to put one in either the client or the server, and now you have either permission issues or things not showing up like they're supposed to.

[00:00:50]
And again, you get inconsistent logic because as you're copy pasting things and changing things, you may forget to change them or copy paste them correctly in one location or the other, which again leads to permission issues. Now I've kind of talked in depth about all these different things, so we'll scroll down a little bit further and we'll just kind of move on to fixing this particular section.

[00:01:08]
So the vulnerable pages in our application I have listed right here, and these are pages that don't have any permission checks at all, and you can access these pages even if you're not supposed to have access. I'll show you a great example of this. We're currently logged in as an admin engineering user. Let's go to one of these marketing documents and I'm just going to copy the link for a document on a marketing project.

[00:01:27]
This is something that a normal engineering user would not have access to. So we'll log in as a normal engineering user. This is the lowest level of permissions, and if I paste in that URL and I hit enter, you can see I can access that document inside that project that I definitely should not have permission to access. This is something that's really easy to accidentally do because you're not showing this in the sidebar anywhere, so you don't navigate to it manually, but it's very easy to accidentally forget to add these permissions for navigating to things manually with the URL.

[00:01:53]
For example, I could also access the new page for the document by just manually typing in new here, and now I can access the new document page. Now if I tried to create something new, luckily we are locked down on the server. Actually we're not even locked down on the server. I lied. So you can see there's lots of permission issues inside this application as it is currently. So we want to fix all of those different vulnerable pages that we have inside of our application, and we also want to fix where we have different incorrect permissions.

[00:02:17]
There's certain places inside of our application right here actually, viewers should not be able to create documents. I just showcased that they're able to, even though they shouldn't have that permission. So the main thing is fixing these vulnerable pages and fixing any incorrect permissions, and again, they're all labeled with that fixed colon comment, so they're easy for us to find. A really simple example, you'll actually see this a lot, is for example, this document details page.

[00:02:38]
This is just a page for viewing a document inside of a project. We want to first check to make sure the user has access to that project. And the check for this is looking relatively complex, but essentially what we're doing is first checking we have a user. If we don't, obviously redirect them to the login page. We also want to check if the role is admin, then they have access to everything, so they're perfectly fine.

[00:02:57]
But if they're not an admin user, we then want to make sure that the project department is either null or equal to the user's department, because that's kind of the logic we have for projects. They must either be a null department project or it must match their user's department. So that's what we need to implement essentially everywhere inside of our application. So I'm actually just going to copy that because we're going to be using this in many places.

[00:03:16]
Let's go ahead and just try to implement one of these particular fixes. We'll go into the page here. This is our project view page, and if you scroll up to the top, you can see we have our project document page, and right here is our fixed comment for not checking if the user has access to the project. So I'll paste down that code that we had and we'll just make sure that we go through and read exactly what it's doing.

[00:03:35]
We'll need access to the user, so I will move that user check up here. There we go. So to be able to have access to a project, you first of all must be assigned in user. You also can either be an admin user, which is what this check is, or the project has no department assigned to it. It's a global department, or the user's department is equal to the project's current department. This alone will actually fix our problem of that link issue that we had.

[00:03:59]
So if we go back into our example and I try to view the project's view page as someone that doesn't have access to this, we should get redirected back to the login page. So if I just try to access this, it redirected us back to the login page since we're already logged in, it then redirected us back to the project we have access to, so you can see it properly redirected us from a project we did not have access to, to a project we do.