At Code+Create we have a couple of up and coming developers who are being put through their paces and being subjected to several relatively intense training sessions and constant code reviews.
Whenever I provide support on helping them code new functionality, I scrutinise every little line of code (much to their annoyance I’m sure!)
80% of the time they are able to code a solution that works. The code they write has a purpose, be it calculating, fetching or saving data, and the pair will high 5 one another a job well done on beating the programming challenge… Because they did, didn’t they?
One thing I’m teaching is how very easy it is to develop a piece of code that works the way you want it too, but can also potentially be used in ways you either don’t want it to, or ways which you haven’t even thought about.
Let’s use a simple example. Imagine a sales department consisting of 2 teams, and each team has 5 team members. Members of the first team cannot and should not see the sales figures of the other team. Now, when a person logs into their system, they have a link on their dashboard which takes them to their own teams collective sales figures. It looks a little something like this:
On closer inspection, clicking this button takes the user to a URL that looks like this:
This is both intended and expected behaviour, by the developer, for the user to wish to be taken to this URL and is also given the user friendly button to take them there.
BUT what happens if an inquisitive mind spots the URL specifically states “team1” at the end… What happens if that same person decides to tweak the URL manually, and change it to “team2”?
As a quick side note, the featured image on this blog is a real log file taken from one of our applications that clearly shows how common it is for would-be potential hackers to try and find an open or otherwise hidden end point that would grant them access to your system.
Well, that all depends on a number of things, including if there is a team2 in the system, and if the developer has considered applying a logical permission check that fires prior to request being completed.
Scenario 1 – no protective or precautionary checks are made, then the user is able to see all of the sales data from team2… not good.
Scenario 2 – prior to loading any data, the request is inspected as to the requestor. Who are they? What team do they belong to? Should they be asking for team2 if they are a member of team1?
This a very basic example, but the scary thing is how easy it is for us as developers to make these kind of mistakes. The worst part of all this, is technically the code works, is valid, and will pass any kind of tests in place.
It takes a human mind to stop and think “hang on… what if?”.
This whole “what if” is exactly what I’m trying to teach and highlight as being just as important as learning to code.
In the near future I plan to do a demonstration on exactly what information could be extracted from other systems, simply by asking for it, that the developers may have not ever considered possible.