Client side access control is at hand, when the process or mechanism that enforces a users set permission is implemented on the users end of the application. The issue with this approach is, that a user has full control over their machine, and therefore the upper hand when it comes to protective mechanisms. With enough expertise and time, an attacker can almost always circumvent or disable access control that has been implemented on his end.
If the goal is to protect data on a server, then the protective mechanisms should be implemented on the server as well. There is nothing wrong with adding client side access control as an additional feature. This can have the positive effect of decreasing bogus requests to the server, but ultimately does not work as a full defense against attacks.
A typical case for this vulnerability can be a disabled (greyed-out) button in an application, that can’t be clicked. Just because the button can’t be clicked, doesn’t mean that the function behind it can’t be executed anymore. In web applications a quick look at the source often shows which request the button would issue if it where clickable and for desktop applications, a debugger can often be used to achieve the same.
For simplicities sake, we’re going to use the web application as an example, as it’s easier to understand.
The following screenshot shows the source code for the two buttons above.
The marked keyword disabled is responsible for the greyed out admin button. By simply removing it, the previously disabled button can now be clicked. Furthermore, we can see what the button will do once it is clicked, in the
As you can see, client side alone won’t be enough to protect you from attacks. That doesn’t make them a “bad” thing, as long as you don’t rely solely on them, there a valid addition to your applications security.
All showcases and their code can be found in our Github repository. Take a closer look at line 57, which contains the admin button.
Note, that simply removing the button completely doesn’t solve the underlying issue, which is that a user with the knowledge of the request can still execute it. The absence of the button or even the function does of course raise the bar to launch a successful attack, however, it does not prevent such an attack from being possible.
The final access control should be implemented in the server side function. Imagine that the admin button called an add user function, instead of a simple alert box. In this case, the server side add user function would have to check if the request was issued by an admin.