Anna, Scrum Master: Sorry to start the day with a bit of unpleasantness, but Janne at Delta-Q called me late yesterday. He says there was a hitch last week with the online store we’re working on. Now he knows what the problem is. Judging by the e-mails coming in from customers, it seems that personal information and passwords have been leaking ...
Jonas, developer: Oh no!
Anna: Now he wants to meet the people working on the site. He believes that either we’ve left something open, or else it’s even worse ...
Simon, developer: Are you saying that he believes that we ...? Anna is grim-faced. She nods gravely.
Hand on heart – what’s your own approach to security?
Total security is an unobtainable fantasy: there are no absolute measures of safety of the sort “if you do this, absolutely nothing can happen.” That’s how it is with everything in life. Compare, for example, your life as a road-user – it is built around your daily application of a balanced risk assessment where, for instance, you weigh up the protection afforded by your bicycle helmet against the dangers posed by drunk drivers.
Similarly, your life as a software developer or computer user must be based on a balanced risk assessment where you make trade-offs:
You do not have to solve all the security problems in your product, but you must
- Understand the risks you take
- understand that you are taking them
When we write robust and intelligible code, we get fewer security problems. Unfortunately, most developers will probably agree that they often have to hand over products that they are not entirely happy with – a consequence of the fact that management prioritises speed of production over long-term freedom from problems.
With luck, the worst thing that happens is that a colleague smirks at your clumsy code or groans at your substandard structure when debugging the code later on. If you are unlucky, it’ll be worse – you might, for instance, have created a vulnerability that someone with malicious intent can exploit.
Here we can gain inspiration from the Software Craftsmanship movement and stress the importance of professional responsibility. Developers with professional pride should not have to accept deadlines so tight that there’s insufficient time to do a good job!
Software Craftsmanship
The Software Craftsmanship movement aims to promote professionality in the field of software development, focusing on wellcrafted software, knowledge sharing and cooperation.Read more at (http://manifesto.softwarecraftsmanship.org)[http://manifesto.softwarecraftsmanship.org]
Studies have shown that 60–80 % of all attacks are possible because we do not validate that the data is in the correct format, even if it was input directly by the user. The principle is never to trust data that comes from somewhere other than our own system and that we can keep track of.
All data input must therefore be validated in some way. One principle is to locate any defects or abnormalities, but then you constantly have to add new rules as the intruders become more skilful. It is actually better to define what authentic and accurate data should look like.
Also remember that even if you validate data on the client side, you need to revalidate it on the server side. A malicious user can circumvent validation in clients and send bad data straight to the server.
Some simple examples:
Examples of vulnerabilities
- Web forms where the hacker, for example, can enter JavaScript instead of his surname (and can thereby create CrossSite Scripting).
- When the user enters SQL code to dump data in a field where you can search for products (so-called SQL injection).