Client vs. Server Validation

How many times have we thrown a vulnerability over to the development team assuming they understand what the issue is? How many times have we sat with the development team to show them what we do? This isn’t a point of showing how to attack to build up the next generation of security people. Instead, it is focused on showing the development team how at attacker looks at their application so they better understand the issue identified. 

Let’s walk through a really simple scenario

You have an insufficient authorization issue where a user is able to modify one of the values being passed to allow access to a record they shouldn’t have access to. When this type of issue is generalized and sent to the development team there are a few different options that could be followed.

Often times, the first attempt at mitigating this is to add some JavaScript to the UI to stop the user from modifying the value. Maybe the field is now read-only in the browser.

If this is the only step taken, there is most likely a breakdown of understanding how the vulnerability works. I can already hear everyone in security screaming for server side validation. I get it, as that is the right response. That doesn’t mean that the development team knows this. Sure, maybe you do some sort of annual training that mentions this, but that doesn’t mean that information is sticking. When it comes to looking at the issue, the first visual representation is at the UI. It would make sense that the first inclination would be to block this at the UI.

This also speaks to a lack of understanding how the application is working at the raw level. Not to say that we don’t know there are GETS, POSTS, UPDATES, DELETES, and PUTS going on behind the scenes, but we are not thinking about them as that is not how we typically use the application.

This is where it is important for the development teams, and that is everyone involved in developing the application, understand the very fundamentals of how the applications work and how security looks at the application.

What does this mean?

Well with my security hat on, I look at any application through the lens of a proxy server. In my case, I prefer to use Burp Suite, but there are others that are very popular as well. While I will use the application through the UI, my real curiosity around security happens through the proxy. This is because I can see the raw request and response that is occurring. I am no longer restricted by the browser in anyway and I can talk directly to the server with no interruptions.

I have free reign to manipulate all the data that is being sent to the server. When you understand this capability, and that anyone can do it, it can open your eyes to how we want to remedy the situation. We quickly see that by adding anything client side through JavaScript to limit input is futile because it can be so easily bypassed. Now, when I see an insufficient authorization issue pop up due to manipulating a field in the post, I quickly recognize that there is a need for server side validation to occur.

When the development teams understand how security bugs are identified and exploited they are better prepared for handling future issues put into their backlog. As a matter of fact, it will lead to more items beiing identified within those teams, before it even makes it to security. This isn’t about creating a team of hackers or digging deep into the depths of exploitation. It can start as simply showing the high level process of using a proxy to interact with the application.