Cyber Crime: Programmers Are (Part Of) The Problem
When I say programmers are the problem, I don’t necessarily mean it’s our fault.
A lot of the time we programmers aren’t even aware of the security risks we can introduce into systems. We are just happy to get stuff working, adding a few bells and whistles if we can. Worrying about security is for the network and hardware guys, keeping the servers patched and any loopholes closed.
As programmers, should we really concern ourselves with cyber security?
Although attacks on web applications account for only 8 percent of overall reported incidents, attacks on web applications accounted for over 40 percent of incidents resulting in a data breach, and were the single-biggest source of data loss.
(Verizon Data Breach Incident Report 2016)
That is a pretty damning quote. In other words, if hackers want to steal data, web applications are the go-to weak link. But why is this?
Let me introduce you to Josh.
Josh works for a smallish software consultancy, specializing in data driven, web based applications — pretty standard stuff. He happily creates software that carries out the functions that the clients ask for. He performs demos throughout the lifecycle of his projects, making sure they are on track. Everyone loves what he does. Josh is a good developer.
Why Being A Good Programmer Is Not Enough
“For with much wisdom comes much sorrow; the more knowledge, the more grief.”
The writer of Ecclesiastes got it spot on here — I wonder was he a developer at heart? As web development technology has advanced over the years, from static web sites to web applications that have the look and feel of desktop software, developers have been able to create increasingly more powerful and impressive software.
However, this has come at a cost. From my experience of working on projects, sometimes we strive on in our solutions and don’t take the time to let other good practices catch up. We get something working and think ‘Great! Let’s roll that out!’ before going back and assessing the various alternative scenarios that could possibly play out.
Let’s catch up with our new friend, Josh…
Josh is working on a new web application for a pushy client; the type of client that wants everything done yesterday. The feature under development at the moment is to allow an authenticated administrator to print out a report of user activity — pretty easy stuff. Josh has decided not to reinvent the wheel and has opted to use an external 3rd party service for authentication. He thinks this is a smart idea.
Josh is working from a local coffee shop and the wifi is a bit ropey, so he has problems running his web application locally on his laptop because he can’t communicate with the authentication service. However, he puts in a little hack that he read about that will allow him to bypass this. He checks the HTTP Referer header and if it’s from ‘localhost’ then the system will assume he’s an administrator. He’s pretty happy with this — he knows no one will be browsing from the production server even if he forgets to remove the hack.
As developers, we sometimes have our blinkers on and assume that the systems we develop will only ever be used by the users they were designed for. Call it naivety or stupidity — but we go into this little bubble where we only ever think that the happy path will be the only path that’s exercised in our software. We really do make too many assumptions, don’t we?
No System Is 100% Secure
“The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards.”
As developers, we should should perform this routine more often: pause, step back and ask — “What else could happen here?”. We need to take time and analyse the different eventualities that could arise, while assessing the risks of the various outcomes. If the risk is acceptable then all is okay; otherwise we need to take measures to mitigate the risk.
Little do we know that there are bad people lurking in the cyber shadows who’ll also be using our software — not just the normal everyday users we designed it for. These shadow figures don’t just use browsers, but they have other tools to dig under the surface of our systems. for the most part, I’m sure most of the time they think their Christmases have all come at once!
“86% of all websites tested by WhiteHat Sentinel had at least one serious vulnerability, and most of the time, far more than one.”
WhiteHat Security Statistics Report 2015
Back to Josh…
The client needs the new report to be rolled out ASAP. It’s only a couple of days before the month end and it’s of the utmost importance to get this into the hands of the department admins. Josh goes about committing his code to the source control, triggering a build of the software and a continuous deployment to the staging server. The client takes five minutes to check the new features work with the test database and gives the thumbs up for deployment to production. Another job well done for Josh and the team — who is up for a beer to celebrate?
Little did Josh know, but one of the customers of his client had their account disabled for not paying their subscription. This particular customer didn’t take too kindly to having their access denied, and decided to take matters into their own hands. If THEY couldn’t get access, then they were going to make life difficult for OTHER customers too. They started to poke around and try a few little hacks.
How To Make The Problem ‘Better’
As has already been mentioned, we can’t really fix the problem because no system is ever totally secure. All we can do is try to make it better — or perhaps less worse. We’ve already agreed that we should pause, analyse and assess. However, if we aren’t aware of what could happen then there’s not much point in this exercise.
As programmers, we need to study and read around our subject an awful lot more. We need to make it our responsibility to be the best we can and to provide our customers (whoever they may be) with quality software that is functionally correct and secure. This means being well-rounded — not necessarily security gurus, but at the bare minimum we should be aware.
Josh first got word that things weren’t right when the logs started to show some extra activity, especially alert reports from the 3rd party authentication service. After further investigation, he found that there was also some admin activity that didn’t match up with normal user activity. For example, a lot of end of month reports were being generated mid month. Something just wasn’t right.
Invest In Training
“Companies spend millions of dollars on firewalls, encryption and secure access devices, and it’s money wasted, because none of these measures address the weakest link in the security chain.”
For too many years, I let my skill set depend on whatever I was working on at the time in whichever company I was employed by. I love learning (my wife says it’s “my thing”), so as a young software developer I relished working with new technologies and learning from my more experienced colleagues.
However, I soon realised that this only got me so far. If I wanted to move to the next level, I had to look elsewhere in order to boost my skill set and keep improving. We are so fortunate to have a multitude of online material nowadays — we are spoilt for choice! Udemy, Coding School, Pluralsight, Treehouse — so many excellent resources.
Therefore, as programmers we need to man up and take the bull by the horns. Not only do we need to know about the ins and outs of our particular languages of choice, we also need to know about design, architecture, testing, performance, and UX among other things. However, if we are honest bottom of this list is usually security.
Josh was sure there was some unwanted activity on the new web application but couldn’t trace how the attackers were getting access. He spent a couple of days investigating and reading up on web application security and realised just how little he knew. As he read an article on how attackers can manipulate HTTP headers, it suddenly clicked with him: the Referer header! He downloaded an http proxy tool and tried manipulating the header before the request was sent over the wire to the server. He changed it to ‘localhost’ and would you believe it — the system treated him as though he was logged in as an administrator! So simple — yet he hadn’t realised this was possible. If only he had known!
Businesses Need To Take Responsibility
“If you spend more on coffee than on IT security, you will be hacked. What’s more, you deserve to be hacked.”
Okay, okay — I’ve been a little bit unfair to programmers in this article, almost laying the blame at our feet. Well, let’s redress the balance. Programmers are not entirely to blame. Our employers (that is, software houses and consultancies) need to invest in us a bit more and bootstrap the skills required to do our jobs right.
Software businesses need to take security seriously, in the knowledge that they could be held responsible for any data breaches or damages. An option some businesses choose is to hire a security analyst who carries out reviews on code, web application penetration tests and advises programmers on best practices.
By the time other staff were arriving the next morning, Josh already had a build ready for deployment to production. He had removed the security loophole and emailed his superiors and informed them of the error on his part. As part of continuous improvement, he suggested training could be offered to development staff, especially around application security.
Realistic Expectations On Projects
One of the biggest factors for security being overlooked is the pressure on project deliverables. Somewhat like writing unit and integration tests, security reviews are one of the easier parts of a project to shave off when time is limited. The eternal question is why should anything be dropped? Would we be happy for a construction business to leave the roof of a house off in order to have the building ready on time?
Once again, I put the blame for this on development teams and business management. One of the big lessons I have found it most difficult to learn was setting realistic expectations with project stakeholders. Personally, I always wanted to please by committing to deadlines that made the client or my line manager happy, even though I knew the dates were pretty unrealistic. I have got better at this, but I still tend to lean towards unrealistic rather than realistic expectations.
On the other side, the business and the various stakeholders in the project need to give their support to the development teams. If the development team feel they can be upfront and honest about the delivery date, then it’s better for everybody. However, if they feel that they are going to get a grilling every time the dates slip, then they will find some clever way of hiding the facts.
At the next group development meeting, Josh aired his views about the pressures that the teams are under in terms of delivery dates. He has suggested trying different methods of estimating, even going as far as investigating having no estimates at all. He’s excited to see what happens and looking forward to the upcoming security training!
Five Simple Security Loopholes To Watch Out For
As programmers, here are a few things we can be aware of while coding. It won’t make you an expert, but at least you’ll have some awareness.
- Never Trust What Comes From The Client Side
Attackers can easily bypass client side validation, even going as far as changing values of ‘hidden’ fields that are posted back to servers. Where you have hidden fields, or disabled fields, or any type of client side validation — never trust what comes back to the server. Always perform server side validation.
Attacker will always look for weaknesses around login functionality. Never pass usernames or passwords back to the server in the URL. Always post them in the request body and where possible use HTTPS, even for the requested login page. Be careful of ‘Remember Me’ cookies — don’t forget that cookies can be sniffed out by attackers.
3. Session Management
Sessions usually depend on tokens being passed between client and server. These tokens can easily be seen by anyone looking at the HTTPS headers. Always make sure they are not meaningful in anyway i.e. the attacker can’t guess what other tokens might be. Otherwise other users could have their sessions hijacked, perhaps even an administrator.
4. SQL Injection
With the use of ORMs and improved databases, SQL injection is perhaps not as prevalent as it once was. However, programmers being programmers, we sometimes take shortcuts and hard code SQL queries. This leaves our systems open to attackers to craft malicious SQL in order to get data from our databases. Where possible, always use parameterised queries to combat this.
The size, scale and frequency of DDoS attacks continues to grow at alarming rate. If someone wants to take down your site, there are a multitude of tools out there that even young kids could use. In days gone by, this would have taken a lot of engineering and devops effort to sort out. However, today there are very good web application firewalls (WAFs) available that can handle even the most vicious of DDoS attacks e.g. CloudFlare.
Programmers! Let’s get on the ball. I want us to up our game. If I’ve been a bit tough on you here, it’s because we’re in this together and I want us to level up. We need to cement security into our projects instead of making it optional. We need to read more, we need to take courses, we need to experiment. We will never catch up with hackers, but we need to stay as close to them as possible. To do that, we need to learn their tricks. We need to become like them. You literally need to become a hacker.
Call To Action
If you want to learn the right strategies to keep your web application safe, check out my web application security checklist. I’ll also send you some step-by-step tutorials on how you can learn some hacker tricks!